Как обрабатывать конфиденциальные данные при использовании Github и Heroku?

49

Я еще не привык к тому, как работает Git (и удивляюсь, если кто-то кроме Линуса;)).

Если вы используете Heroku для размещения своего приложения, вам необходимо проверить свой код в репозитории Git. Если вы работаете над проектом с открытым исходным кодом, вы с большей вероятностью поделитесь этим репо на Github или других хостах Git.

Некоторые вещи не должны быть проверены в публичном репо; пароли базы данных, ключи API, сертификаты и т. д. Но эти вещи все еще должны быть частью репозитория Git, поскольку вы используете его для передачи своего кода в Heroku.

Как работать с этим вариантом использования?

Примечание: я знаю, что Heroku или PHPFog могут использовать переменные сервера, чтобы обойти эту проблему. Мой вопрос больше о том, как «спрятать» части кода.

Jonas
источник
3
Я бы начал с использования частного репо. Затем, в зависимости от того, насколько я доверяю этому, я могу .gitignore мои файлы конфигурации, которые содержат конфиденциальные данные, и только версии их локально. (Локальное, не внешнее центральное местоположение, которое может быть внутренним сервером или кто знает)
Риг

Ответы:

30

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

(Пример ниже и весь мой ответ относятся к приложениям rails)

$ 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 является bitbucket, который предлагает бесплатные частные репозитории.

Майк Вормвальд
источник
17

Несколько идей ... Криптография с открытым ключом - самый гибкий ответ.

Запутывание (только для кода)

Для частей кода, которые вы хотите скрыть, вы могли бы поместить их в другой проект, скомпилировать их и проверить только скомпилированный код, а не исходный код? Это не шифрование и не подходит для шифрования паролей или ключей. Люди все еще могут перепроектировать ваш скомпилированный код, но они не получают исходный код.

Закрытое хранилище GIT

Это должен быть публичный репозиторий git?

Серверное хранилище

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

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

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

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

Если другим разработчикам нужно проверять секретные вещи в общедоступном git-репозитории, для такого рода вещей была создана криптография с открытым / закрытым ключом (асимметричная). Установите закрытый ключ на свой сервер (не включайте его в систему контроля версий!) И сгенерируйте открытый ключ из него. Зашифруйте ваши секретные данные с помощью открытого ключа сервера. Только сервер может расшифровать эти данные, используя свой закрытый ключ. Вы даже можете проверить открытый ключ в управлении исходным кодом, чтобы другие люди могли шифровать данные с использованием того же открытого ключа, и только сервер может расшифровать его.

Орудие труда

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

Заключительные мысли

Если «сервер» - это веб-сервер, который использует https, то у вас уже должно быть какое-то безопасное хранилище ключей на сервере для хранения закрытого ключа. Это своего рода сногсшибательное, что хостинговая компания не делает скидок на это. Может быть, у них есть некоторые подсказки о том, как другие решают проблему, с которой вы сталкиваетесь?

GlenPeterson
источник
Чтобы добавить WRT к хранилищу на стороне сервера - я не знаю, можете ли вы сделать это с Heroku, но я видел установки, когда сценарий запускается из ловушки после получения и / или что-то вроде Capistrano на сервере развертывания, чтобы скопируйте файл базы данных развертывания в правильное местоположение. Это позволяет вам полностью исключить файл базы данных из репозитория и иметь автоматический механизм, обеспечивающий сохранение такой информации.
Шона
Даже частные репозитории GIT должны защищать конфиденциальные данные. На тот случай, если на какое-то время это произойдет случайно. Кроме того, я думаю, что всегда следует использовать асимметричное шифрование, а не симметричное. Я не вижу в этом недостатка, только этот плюс: вы даже можете оставить где-нибудь API-интерфейсы, чтобы упростить шифрование новых конфиденциальных данных, которые будут жестко закодированы.
Тибериу-Ионю Стан
7

Если вы хотите запустить свой код на Heroku, вы должны предоставить его им - вы не можете держать его «в тайне» от своего хостинг-провайдера.

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

Ричард Николс
источник
1
Спасибо, но каков рабочий процесс для этого?
Джонас
6

Вы не должны скрывать части кода. Безопасность вашей системы не должна зависеть от секретности кода; это известно как «безопасность через неизвестность», которую эксперты по безопасности не одобряют, потому что она работает очень плохо.

Вместо этого пароли, криптографические ключи и т. Д. Должны храниться отдельно от кода. Сохраните их в отдельном файле конфигурации или в значении конфигурации, которое читается кодом. Вам не нужно хранить их в Git.

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

Смотрите также:

Plug: IT Security.SE - отличное место, чтобы задавать вопросы о безопасности!

DW
источник