Як обробляти конфіденційні дані під час використання Github та Heroku?


49

Я ще не звикла з тим, як працює Git (І цікаво, чи хтось, крім Лінуса;)).

Якщо ви використовуєте Heroku для розміщення вашої програми, вам потрібно перевірити свій код у Git repo. Якщо ви працюєте над проектом з відкритим кодом, ви, швидше за все, поділитесь цим репо на Github чи інших хостах Git.

Деякі речі не слід перевіряти в публічному репо; паролі бази даних, ключі API, сертифікати тощо ... Але ці речі все-таки повинні бути частиною репортажу Git, оскільки ви використовуєте його для надсилання коду до Heroku.

Як працювати з цим випадком використання?

Примітка. Я знаю, що Heroku або PHPFog можуть використовувати змінні сервери, щоб обійти цю проблему. Моє запитання більше про те, як "приховати" частини коду.


3
Я б почав із приватного репо. Тоді, залежно від того, наскільки я їй довіряю, я можу .gitignore мої конфігураційні файли, які містять конфіденційні дані та лише версії їх локально. (Місцевий - це не зовнішнє центральне місце, яке може бути домашнім сервером або хто його знає)
Rig

Відповіді:


30

Кращим методом збереження паролів / ключів api в таємниці на heroku є встановлення значень конфігурації через додаток командного рядка heroku. Наступний приклад, взятий із статті про центр heroku dev

(Наведений нижче приклад, і вся моя відповідь стосується додатків рейок)

$ cd myapp
$ heroku config:add S3_KEY=8N029N81 S3_SECRET=9s83109d3+583493190
Adding config vars and restarting myapp... done, v14
S3_KEY:     8N029N81
S3_SECRET:  9s83109d3+583493190

Потім посилайтеся на ці значення конфігурації у своєму коді за допомогою змінної ENV []

AWS::S3::Base.establish_connection!(
  :access_key_id     => ENV['S3_KEY'],
  :secret_access_key => ENV['S3_SECRET']
)

Таким чином ваші чутливі паролі не зберігаються у сховищі git. (Примітка. Під час запуску програми локально встановіть ці значення у своєму .bashrcфайлі

Крім того, я не впевнений, який тип програми ви запускаєте, але в Rails heroku не використовує файл database.yml, він просто встановлює ім’я / пароль вашої бази даних відповідно до налаштувань програми. Таким чином, ви можете уникнути збереження цих облікових даних у git

Крім того, якщо ви запускаєте власну програму і хочете, щоб вона залишалася приватною, відмінною альтернативою github є бітбукет, який пропонує безкоштовні приватні сховища.


17

Кілька ідей ... Криптографія відкритого ключа - це найбільш гнучка відповідь.

Заплутаність (лише для коду)

Що стосується частин коду, які ви хочете приховати, чи можете ви розмістити їх в іншому проекті, скласти їх і зареєструвати лише скомпільований код, а не джерело? Це не шифрування і не підходить для шифрування паролів або ключів. Люди все ще можуть реверсувати інженер ваш скомпільований код, але вони не отримують джерело.

Приватний сховище GIT

Чи має бути це загальнодоступне сховище git?

Зберігання сервера

Чи можете ви зберегти цю інформацію в захищеному файлі в домашній каталозі облікового запису користувача, під яким працює програма? Я скопіював би спосіб, коли ssh робить це за допомогою ~ / .ssh / id_rsa та chmod 600. Якщо цього не вдалося, може бути використана змінна середовища. Вам потрібно десь на сервері зберігати якийсь ключ, інакше ви не можете захистити що-небудь.

Симетрична криптографія (тільки для вас)

Якщо ви єдиний розробник, ви можете покласти ключ на сервер і мати той самий ключ на вашому пристрої та використовувати симетричну схему шифрування для захисту деяких даних, таких як пароль або сертифікат. Обмін симетричним ключем з друзями стає безладним.

Асиметрична криптографія (для декількох розробників)

Якщо іншим розробникам потрібно перевірити секретні речі у сховищі публічних git, для цієї речі була зроблена криптографія з відкритим ключем / приватним ключем (несиметрична). Встановіть приватний ключ на свій сервер (не перевіряйте його в контролі джерела!) Та генеруйте з нього відкритий ключ. Зашифруйте свої секретні дані за допомогою відкритого ключа сервера. Тільки сервер може розшифрувати ці дані за допомогою свого приватного ключа. Ви навіть можете перевірити відкритий ключ у контролі джерела, щоб інші люди могли зашифрувати дані, використовуючи той самий відкритий ключ, і лише сервер може розшифрувати його.

Інструмент

Openssl - це, мабуть, єдиний інструмент криптографії, який вам коли-небудь знадобиться. Не пишіть власний алгоритм криптографії чи власну реалізацію опублікованого алгоритму.

Замикаючі думки

Якщо "сервер" - це веб-сервер, який використовує https, то ви вже повинні мати якусь захищену сховище ключів на сервері для зберігання приватного ключа. Це начебто вражає те, що хостинг-компанія не буде робити надбавки для це. Можливо, у них є деякі підказки, як інші вирішують завдання, з яким ви стикаєтесь?


Щоб додати, WRT на стороні зберігання сервера - я не знаю, чи можете ви це зробити з Heroku, але я бачив установки, де сценарій запускається з гачка після отримання та / або щось на зразок Capistrano на сервері розгортання для скопіюйте файл бази даних розгортання у потрібне місце. Це дозволяє повністю зберігати файл бази даних від репо-репортажу та мати автоматичний механізм для забезпечення такої інформації.
Шауна

Навіть приватні репортажі GIT повинні захищати конфіденційні дані. Про всяк випадок, якщо він ненавмисно на деякий час стає публічним. Також я думаю, що асиметричну криптовалюту завжди слід використовувати замість симетричної. Я не бачу його недоліків, тільки це перевернуто: ви навіть можете залишити API де-небудь, щоб полегшити шифрування нових чутливих даних, які можуть бути жорстко кодованими.
Tiberiu-Ionuț Stan

7

Якщо ви хочете запустити свій код на Heroku, ви повинні надати їм його - ви не можете тримати його в секреті від свого хостинг-провайдера.

Що стосується загальнодоступних сховищ git, якщо ваш проект є відкритим кодом, але ви не хочете ділитися деталями хостингу, вам потрібно буде підтримувати приватну вилку вашого проекту для цілей розгортання.


1
Дякую, але що це за робочий процес?
Йонас

6

Ви не повинні приховувати частини коду. Безпека вашої системи не повинна покладатися на секретність коду; це відоме як "безпека через незрозумілість", на що нахмуріли експерти з безпеки, оскільки вона працює дуже погано.

Натомість паролі, криптовалюти тощо слід зберігати окремо від коду. Зберігайте їх у окремому файлі конфігурації або значенні конфігурації, яке зчитується кодом. Не потрібно зберігати їх в git.

Важливо: Ніколи не твердо кодуйте криптографічні ключі, паролі чи інші секрети у вихідному коді! Це дуже погана практика.

Дивитися також:

Plug: IT Security.SE - це чудове місце для запитань щодо безпеки!

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.