Где управлять наиболее конфиденциальным контентом, находящимся под контролем версий?

Позволяют ли какие-либо системы контроля версий указывать ограничения безопасности на уровне строк, а не на уровне файлов? Я знаю, что это было бы ужасно поддерживать. Если бы я хотел никогда не допускать определенных строк в базу данных, должен ли я изучать понятие крючков и управлять всей очень конфиденциальной информацией на этом уровне крючков? Как хуки реплицируются из системы в систему?

Обновление: Возможно, лучший способ справиться с этим — зашифровать конфиденциальные данные с помощью pgp, и те, кто не сможет их расшифровать, останутся в неведении. Есть мысли по этому поводу? Вероятно, это не лучшая практика с точки зрения безопасности.


git security version-control svn mercurial
person ojblass    schedule 07.06.2009    source источник
comment
Я изменил тег, чтобы добавить другие известные системы контроля версий.   -  person Osama Al-Maadeed    schedule 07.06.2009

Ответы (5)


arrow_upward
5
arrow_downward

У нас была такая же проблема, и мы решили решить ее, настроив второй репозиторий.

Это произошло, когда мне нужно было сохранить наши файлы управления конфигурацией в системе управления версиями, которые содержали конфиденциальную информацию. . Там же имело смысл хранить конфиденциальные данные из наших приложений.

Первоначально мы использовали внешние файлы svn и git submodules, чтобы включить конфиденциальные данные, но позже обнаружил, что проще просто сделать ссылку на другое место.

Я также считаю полезным добавить соответствующие игнорирования, чтобы предотвратить регистрацию одних и тех же файлов в репозитории разработки. С тех пор у нас не было ни одного случая, чтобы кто-нибудь случайно проверил что-либо конфиденциальное.

Это помогает сохранить конфиденциальную информацию, содержащуюся в кратком наборе конфигурационных файлов — я бы не стал разбрасывать ее, поместить в одно место и охранять это место.

person csexton    schedule 08.06.2009
comment
Отличный ответ. Он отступает от цели ОП по решению реальной проблемы и предлагает альтернативу. Фактический вопрос, похоже, больше связан с контролем над различными наборами данных и их допуском в/из определенных репозиториев. Идя дальше, если вам требуется конфиденциальная информация контроля версий, то для этого должен быть должным образом защищенный репозиторий. Затем у вас есть один репозиторий, в котором вы игнорируете конфиденциальные данные (разрабатываемый/общедоступный), и один, в котором вы можете вносить изменения в конфиденциальные данные. - person maxwellb; 14.06.2009

arrow_upward
2
arrow_downward

Возможно, вам следует выделить тревожные строки, строки и функции в отдельный файл (или, что еще лучше, в файлы). Таким образом, вы можете просто управлять файлами, о которых идет речь.

person C. Ross    schedule 07.06.2009
comment
Я склонен согласиться, но по мере того, как системы контроля версий становятся вирусными и распространяются, это управление становится чем-то вроде аборта. - person ojblass; 08.06.2009
comment
Я не уверен, что понимаю, что ты имеешь в виду под абортом. Также как системы контроля версий становятся вирусными? - person C. Ross; 08.06.2009
comment
Я предполагаю, что это яичница: аберрация/аборт - person Cheekysoft; 08.06.2009

arrow_upward
2
arrow_downward

Позволяют ли какие-либо системы контроля версий указывать ограничения безопасности на уровне строк, а не на уровне файлов?

Позволяет ли какая-либо операционная система указывать ограничения безопасности на уровне строк, а не на уровне файлов? Наверное, только в АНБ (и у друзей).

Лучше всего зашифровать любой файл, содержащий конфиденциальную информацию, прежде чем добавлять его в систему контроля версий. Это также защищает его от случайного отображения, например. git diff, пока кто-то смотрит через ваше плечо.

person pgs    schedule 08.06.2009

arrow_upward
1
arrow_downward

Subversion не позволяет этого, и я не думаю, что другие делают.

person Osama Al-Maadeed    schedule 07.06.2009

arrow_upward
1
arrow_downward

Вы можете запускать отдельные репозитории и поддерживать более строгий контроль над репозиторием с конфиденциальными данными.

person kbyrd    schedule 07.06.2009
comment
по мере распространения репозиториев у меня возникают проблемы с пониманием того, что именно находится под моим контролем. Мой выбор подрывной деятельности был частично обусловлен тем, что она более централизована. Разбить его в другой репозиторий, вероятно, лучший вариант, который у меня есть. Я подумал, что, может быть, pgp зашифрует конфиденциальную информацию и позволит ей выйти, куда бы она ни пошла. - person ojblass; 08.06.2009