Как безопасно хранить ключи API

В чем проблема?

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

В этой статье вы не найдете решение всех проблем, связанных с хранением ключей API. Здесь я просто хочу поделиться собственным подходом к анализу этой проблемы и предлагаю методы решения. Итак, в чем же состоит проблема хранения конфиденциальной информации совместно с программным кодом в репозитории git?

Почему вы не должны хранить ключи API в репозиториях git

Хранение ключей API или любой другой конфиденциальной информации в репозитории git  – это то, чего следует избегать любой ценой. Даже если репозиторий является приватным, вы не должны рассматривать его как безопасное место для хранения конфиденциальной информации. Давайте начнем анализ проблемы с того, почему хранить ключи API в публичных репозиториях git является плохой идеей.

По-сути публичный репозиторий git может быть доступен любому. Иными словами, любой, у кого есть подключение к Интернету, может получить доступ к содержимому публичного репозитория git. Кроме того, любой может просматривать код в репозитории и даже запускать его. Если вы храните ключ API в публичном репозитории, вы публикуете его в открытом виде, то есть каждый может его увидеть.

На текущий момент поиск по ключевому слову client_secret на GitHub показывает, что имеется более 30 000 коммитов, которые потенциально могут раскрыть ключ API. В некоторых случаях вы даже можете получить доступ к API просто скопировав себе код. Эта проблема становится настолько важной, что некоторые компании стали инвестировать свои ресурсы в проверку доступности ключей API. Так в прошлом году компания Slack начала искать открытые API-маркеры и аннулировать их. Эти действия предотвращают вредоносный доступ к учетным записям Slack, но не позволяет найти все утечки.

Это происходит на публичных репозиториях git, а как насчет закрытых? В чем заключается проблема? Частные репозитории git, особенно размещеные на таких сервисах, как GitHub, GitLab и Bitbucket, подвергаются другому типу риска. Всякий раз, когда вы интегрируете стороннее приложение с одной из перечисленных служб, вы, возможно, открываете доступ к своему хранилищу третьим лицам. Эти приложения смогут получить доступ к вашим приватным репозиториям и прочитать содержащуюся в них информацию. И хотя само по себе это не создает никакого риска, представьте, что одно из этих приложений становится уязвимым. Получая несанкционированный доступ к одному из этих сторонних приложений, злоумышленники могут получить доступ к вашим конфиденциальным данным, включая ключи API.

Итак, где же должны храниться ключи API?

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

git-remote-gcrypt

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

git-secret

git-secret – инструмент, работающий на локальном компьютере и шифрующий отдельные файлы до размещения в репозитории. По сути, git-secret – это скрипт для шела, который использует gpg для шифрования и дешифрования файлов, содержащих конфиденциальную информацию.

git-crypt

Еще одно решение –  git-crypt. При схожести с git-secret имеются любопытные отличия. Первое отличие - это не скрипт, а бинарный исполняемый файл. Значит применение потребует предварительной компиляции или поиска бинарного дистрибутива под вашу машину. Если у вас Mac, считайте, вам повезло, потому что HomeBrew предлагает готовый к установке git-cryp пакет и единственное, что потребуется ‑ запустить  brew install git-crypt  через терминал.

BlackBox

BlackBox – инструмент, созданный Stack Overflow, компанией поддерживающей сообщества Q&A, такие как Stack Overflow, Server Fault и Super User. BlackBox - надежный инструмент, поскольку работает как с git, так и с другими системами, такими как Mercurial и Subversion, поддерживает шифрование и отдельных строк и целых файлов. Это достигается при работе с puppet, используется hiera, инструмента поиска конфигурации. Шифрование отдельных строк позволяет BlackBox быть отличным решением по защите ключей API и конфиденциальной информации.

Конфигурация Heroku и конфигурационные Vars

При работе с Heroku, не нужно хранить конфиденциальную информацию и ключи API в репозиториях git. Heroku предлагает решение, устанавливающее переменные конфигурации. Приложение получает динамический доступ к содержимому переменных конфигурации, обращаясь к соответствующим переменным среды. Хотя сами данные не шифруются, это решение позволяет избежать использования git-хранилища для хранения ключей API. Dokku - решение с открытым кодом, аналогично Heroku, и предлагает тот же функционал.

Секреты Doker

Рассматриваемый спектр решений завершим рассказом о  Docker secrets. Это решение было предложено компанией Docker в феврале 2017 года и с тех пор популярность только растет. Doker динамически определяет зашифрованные переменные, доступные для служб репозиториев. Конфиденциальная информация кодируется при передаче и при хранении. Благодаря такому подходу Docker становится идеальным решением для безопасного хранения ключей API и конфиденциальной информации в зашифрованном виде.

Резюме

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

Статью перевел Владислав Семёнов