Where to manage the most sensitive content you hav

问题:

Do any version control systems allow you to specify line level security restrictions rather than file level? I know it would be horrible to maintain. If I wanted to never allow certain strings into the database should I be looking into the notion of hooks and manage all the very sensitive information in that hook layer? How do hooks get replicated from system to system?

Update: Maybe the best way to manage this is to pgp encrypt the sensitive data and those who cannot decrypt it will be left in the dark. Any thoughts on that? Probably not a best practice from a security standpoint.

回答1:

We had the same problem and decided to solve it by setting up a second repository.

This originated when I needed to store our configuration management files in version control, which contained sensitive information. It made sense to store the sensitive data from our applications in there as well.

We originally used svn externals and git submodules to include the sensitive data, but later found it less troublesome to just simlink to another location.

I also find it helpful to add the proper ignores to prevent the same files ever getting checked in to the development repository. Since doing this we have not had anyone accidentally check in anything sensitive.

It helps try an keep the sensitive information contained in a concise set of config files -- I would not spread it out, put it one place and guard that place.

回答2:

Perhaps you should separate out the worrisome strings, lines, and functions into a separate file (or better yet files). That way you can just manage the file(s) in question.

回答3:

Do any version control systems allow you to specify line level security restrictions rather than file level?

Does any Operating System allow you to specify line level security restrictions rather than file level? Probably only at the NSA (and friends).

You're best bet is to encrypt any file containing sensitive information before adding it to version control. This also protects it from accidental display, e.g. git diff while someone is looking over your shoulder.

回答4:

Subversion doesn't allow it, and I don't think any others do.

回答5:

You could run separate repositories and maintain stricter controls on the repository with the sensitive data.