Борьба с утечками приватной информации в публичные репозитории

[Anton Koldaev]

Привет,

Какие методы борьбы с появлением приватных данных в опубликованных коллегами репозиториях вы знаете?

Я начну с простых правил:

• никаких приватных данных в открытом виде в любых репозиториях;
• периодическое обновление ключей и паролей;
• внимательная проверка приватного репозитория, включая всю историю изменений на наличие актуальных приватных данных перед конвертацией его в публичный;
• мониторинг своих репозиториев на присутствие приватных данных (есть готовые решения?)
• еще?

--
Best regards,
Koldaev Anton

[Кирилл Ширинкин]

В контексте chef - храню всё в encrypted data bag, в репозитории ничего таким образом не появляется впринципе

четверг, 31 июля 2014 г., 16:47:17 UTC+2 пользователь iRoller написал:

[Timur Batyrshin]

Помимо всего прочего, есть такой вариант:

Код пишет один человек или группа (в т.ч. и рецепты, например), а пользуется ей другая.

Но это, наверное, внутри одной организации не очень хорошо работать будет, нужно какое-то логическое разделение.

четверг, 31 июля 2014 г., 18:47:17 UTC+4 пользователь iRoller написал:

[Дмитрий Цап]

В качестве альтернативы и для удобства шифрования, также используем git-crypt

[Ilya Zharskiy]

четверг, 31 июля 2014 г., 18:47:17 UTC+4 пользователь iRoller написал:

Привет,

Это похоже на лечение симптомов, вместо профилактики болезни.

Самое простое и изящное решение - не хранить в репе с сырцами никакую auth-информацию.

Дисциплинировать разработчиков помогает использование фреймворков - там все конфиг-файлы жёстко регламентированы.

.gitignore и хуки - в качестве страховки.

Конфигами должны управлять другие инструменты - Config Management, которые в идеале отделены от Source Code Management.

Софт ставится через пакетный менеджер, пакет собирается с неизменным (gitignore) skeleton-конфигом.

Конфиги test/dev/production серверов никуда не уходят с серверов, т.к. лежат в другой папке файловой системы (/etc)

и версионируются в другую репу (в простейшем случае - etckeeper).

Таким образом, это  единственно идеологически правильное решение - раздельное хранение и версионирование кода и конфигов.

Правила сборки пакетов, соответственно должны учитывать соответствие версии кода и версии конфига.

Это прямо во второй главе Continuous Delivery (за авторством Jez Humble и David Farley) написано:

___________________________________________________

Chapter 2 Configuration Management
Don’t Check Passwords into Source Control or Hard-Code Them
in Your Application
Operations staff will remove your eyes with a spoon if they catch you doing this.
Don’t give them the pleasure. If you must store your password somewhere other than the inside of your head, you could try putting them in your home directory in an encrypted form.
One egregious variation of this technique is to have the password for one layer of your application stored somewhere in the code or filesystem in the layer that accesses it. Passwords should always be entered by the user performing the deployment. There are several acceptable ways to handle authentication for a multilayer system. You could use certificates, a directory service, or a single sign-on system.

___________________________________________________

P.S. Здесь: https://help.github.com/articles/remove-sensitive-data

упомянуто вот это: https://github.com/rtyley/bfg-repo-cleaner

[Сергей Пермяков]

Используем сhef-vault для хренения секретов.

четверг, 31 июля 2014 г., 17:47:17 UTC+3 пользователь iRoller написал:

[Max Voloshin]

+ есть новый проект от HashiCorp: https://vaultproject.io/