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

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

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

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

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

Предпочтительный метод хранения паролей / ключей 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, который предлагает бесплатные частные репозитории.

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

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

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

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

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

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

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

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

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

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

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

Орудие труда

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

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

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

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

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

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

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

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

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

• Как проекты с открытым исходным кодом обрабатывают защищенные артефакты?

• Пароль в файле .php

• Стандарты для шифрования паролей в файлах конфигурации?

• Open Source и как он работает для защищенных проектов?

• Как защитить информацию учетной записи ftp в исходном коде программы

• Это безопасный способ объявить параметры БД в htaccess, а не в файле PHP?

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