Стратегия сохранения секретной информации, такой как ключи API, от контроля версий?

Я работаю над веб-сайтом, который позволит пользователям входить в систему с использованием учетных данных OAuth, таких как Twitter, Google и т. Д. Для этого мне нужно зарегистрироваться у этих различных провайдеров и получить суперсекретный ключ API, который у меня есть. защищать залогами от различных частей тела. Если мой ключ будет взломан, часть будет вырвана.

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

Поскольку я дешевый ублюдок, я бы предпочел использовать бесплатные сервисы контроля версий, такие как TFS в облаке или GitHub. Это оставляет меня с небольшой загадкой:

Как я могу сохранить свое тело нетронутым, когда мои ключи API находятся в моем коде, и мой код доступен в общедоступном хранилище?

Я могу придумать несколько способов справиться с этим, но ни один из них не является настолько удовлетворительным.

• Я мог бы удалить всю личную информацию из кода и отредактировать ее после развертывания. Это было бы очень трудно реализовать (я не буду подробно описывать многие способы), и это не вариант.
• Я мог бы зашифровать это. Но, как я должен расшифровать, любой, у кого есть источник, может понять, как это сделать. Бессмысленно.
• Я мог бы заплатить за частный контроль источника. LOL J / K тратить деньги? Пожалуйста.
• Я мог бы использовать языковые функции, чтобы отделить конфиденциальную информацию от остальной части моего источника и, следовательно, сохранить ее от контроля источников. Это то, что я делаю сейчас, но это может быть легко испорчено, по ошибке проверив секретный файл.

Я действительно ищу гарантированный способ гарантировать, что я не делюсь своими привилегиями со всем миром (за исключением Snapchat), который будет бесперебойно работать в процессе разработки, отладки и развертывания, а также быть надежным. Это совершенно нереально. Так что реально я могу сделать?

_{Технические детали: VS2012, C # 4.5, контроль версий будет либо TF-сервисом, либо GitHub. В настоящее время используется частичный класс для разделения чувствительных ключей в отдельном файле .cs, который не будет добавлен в систему контроля версий. Я думаю, что GitHub может иметь преимущество, так как .gitignore может быть использован, чтобы гарантировать, что частичный файл класса не зарегистрирован, но я облажался с этим раньше. Я надеюсь на «о, общая проблема, вот как вы это делаете», но мне, возможно, придется согласиться на то, «что это не так много, как могло бы», /}

Не помещайте свою секретную информацию в свой код. Поместите его в файл конфигурации, который читается вашим кодом при запуске. Конфигурационные файлы не должны передаваться на контроль версий, если они не являются «заводскими настройками по умолчанию», и тогда они не должны иметь никакой частной информации.

См. Также вопрос Управление версиями и личный файл конфигурации, чтобы узнать, как это сделать.

Вы можете поместить все закрытые / защищенные ключи как системные переменные окружения. Ваш файл конфигурации будет выглядеть так:

private.key=#{systemEnvironment['PRIVATE_KEY']}

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

private.key=A_DEVELOPMENT_LONG_KEY

Pure Git way

• .gitignore включенный файл с личными данными
• Используйте локальную ветку, в которой вы заменяете TEMPLATEнаDATA
• Используйте грязные / чистые фильтры, в которых (локальный) скрипт фильтра выполняет двунаправленную замену TEMPLATE<->DATA

Ртутный путь

• MQ-patch (s) поверх фиктивного кода, который заменяется TEMPLATEна DATA(наборы изменений являются общедоступными, patch являются частными)
• Расширение ключевого слова со специально разработанными ключевыми словами (разворачивается только в вашем рабочем каталоге )

SCM-агностический способ

• Замена ключевых слов в процессе сборки / развертывания

Я помещаю секреты в зашифрованный файл (ы), которые я затем фиксирую. Пароль предоставляется при запуске системы или хранится в небольшом файле, который я не фиксирую. Приятно, что Emacs с удовольствием будет управлять этими зашифрованными файлами. Например, файл инициализации emacs включает в себя: (загрузить «secrets.el.gpg»), который просто работает - запрашивает пароль в тех редких случаях, когда я запускаю редактор. Я не беспокоюсь о том, что кто-то нарушит шифрование.

Это очень специфично для Android / Gradle, но вы можете определить ключи в вашем глобальном gradle.propertiesфайле, расположенном в user home/.gradle/. Это также полезно, поскольку вы можете использовать разные свойства в зависимости от buildType или разновидности, т.е. API для dev и разные для релиза.

gradle.properties

MY_PRIVATE_API_KEY=12356abcefg

build.gradle

buildTypes {
        debug{
            buildConfigField("String", "GOOGLE_VERIFICATION_API_KEY", "\"" + MY_PRIVATE_API_KEY +"\"")
            minifyEnabled false
            applicationIdSuffix ".debug"
            }
        }

В коде вы бы сослаться на это

String myAPI = BuildConfig.GOOGLE_VERIFICATION_API_KEY;

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

Мобильное веб-приложение

Для Android / iPhone устройство должно запрашивать KEY у вашего собственного веб-сервиса при первом запуске приложения. Затем ключ хранится в безопасном месте. Должен ли ключ быть изменен или отозван издателем. Ваш веб-сервис может опубликовать новый ключ.

Размещенное веб-приложение

Клиенты, использующие лицензию на ваше программное обеспечение, должны будут вручную ввести ключ при первой настройке программного обеспечения. Вы можете дать каждому один и тот же ключ, разные ключи, или они получают свои.

Опубликованный исходный код

Вы храните свой исходный код в общедоступном хранилище, но не KEY. В конфигурации файла вы добавляете строки * поместите ключ сюда * . Когда разработчик использует ваш исходный код, он делает копию sample.cfgфайла и добавляет свой собственный ключ.

Вы не храните свой config.cfgфайл, используемый для разработки или производства в репозитории.

Используйте переменные окружения для секретных вещей, которые меняются для каждого сервера.

http://en.wikipedia.org/wiki/Environment_variable

Как их использовать, зависит от языка.

Я думаю, что это проблема, с которой у всех когда-то возникали проблемы.

Вот рабочий процесс, который я использовал, который может работать для вас. Он использует .gitignore с изюминкой:

1. Все конфигурационные файлы находятся в специальной папке (с примерами конфигурационных файлов - необязательно)
2. Все файлы конфигурации включены в .gitignore, чтобы они не были общедоступными
3. Настройте сервер gitolite (или ваш любимый сервер git) на личном ящике
4. Добавить репо со всеми конфигурационными файлами на частном сервере
5. Добавить скрипт для копирования файлов конфигурации в специальную папку в главном репо (необязательно)

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

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

Я использую коробку 15 $ / год для частного git-сервера, но вы также можете установить ее дома, в соответствии с требованием cheapskate ;-)

PS: Вы также можете использовать подмодуль git ( http://git-scm.com/docs/git-submodule ), но я всегда забываю команды, так что быстрые и грязные правила!

Используйте шифрование, но предоставьте главный ключ при запуске в качестве пароля на консоли, в файле, который может прочитать только пользователь процесса, или из системного хранилища ключей, такого как цепочка ключей Mac OS или хранилище ключей Windows.

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

3 стратегии, еще не упомянутые (?)

При регистрации или в предварительной проверке VCS на крючке

• поиск строк с высокой энтропией, пример обнаружения секретов
• регулярное выражение для поиска известных шаблонов ключей API. Ключи AWS AKIA * являются примером, git-секреты - это один из инструментов, основанный на этом. Кроме того, имена переменных, такие как «пароль» с постоянным присваиванием.
• ищите известные секреты - вы знаете свои секреты, ищите текст для них. Или используйте инструмент, я написал это доказательство концепции .

Стратегии уже упоминались

• хранить в файле за пределами исходного дерева
• Имейте это в исходном дереве, но скажите VCS игнорировать его
• Переменные среды представляют собой вариант хранения данных вне исходного дерева.
• просто не давайте ценные секреты разработчикам

Храните личную информацию под контролем вашего источника. Создайте незагруженное значение по умолчанию для распространения, и пусть ваша VCS игнорирует реальную. Ваш процесс установки (будь то ручной, настройка / сборка или мастер) должен обрабатывать создание и заполнение нового файла. При необходимости измените права доступа к файлу, чтобы его мог прочитать только требуемый пользователь (веб-сервер?).

Выгоды:

• Не предполагает разработку объекта == производственный объект
• Не предполагает, что все соавторы / рецензенты кода являются доверенными
• Предотвратите легкие ошибки, не допуская контроля версий
• Простая автоматизация установки с помощью настраиваемой конфигурации для QA / builds

Если вы уже делаете это и случайно регистрируете его, добавьте его в свой проект .gitignore. Это сделает невозможным сделать снова.

Вокруг есть множество бесплатных хостов Git, которые предоставляют частные репозитории. Хотя вы никогда не должны проверять свои учетные данные, вы можете быть дешевыми и иметь частные репозитории. ^ _ ^

Вместо того, чтобы хранить ключ OAuth в любом месте в виде необработанных данных, почему бы не выполнить строку с помощью какого-либо алгоритма шифрования и сохранить его как соленый хеш? Затем используйте файл конфигурации, чтобы восстановить его во время выполнения. Таким образом, ключ нигде не хранится, хранится ли он в блоке разработки или на самом сервере.

Вы даже можете создать API, чтобы ваш сервер автоматически генерировал новый соленый и хешированный ключ API для каждого запроса, так что даже ваша команда не сможет увидеть источник OAuth.

Редактировать: Возможно, попробуйте Stanford Javascript Crypto Library , она обеспечивает довольно безопасное симметричное шифрование / дешифрование.