Хранение секретов вне контроля над исходным кодом - мы только перемещаем проблему?

10

Я унаследовал несколько проектов, в которых секреты находились в системе контроля версий в App.config и подобных файлах. К счастью, это не публичное хранилище, поэтому риск не такой серьезный, как мог бы быть. Я ищу более эффективные способы управления этим, такие как Azure KeyVault. (Но я не намерен, чтобы этот вопрос был конкретным для этого решения.)

В общем, разве мы не решаем проблему? Например, в Azure KeyVault идентификатор приложения и секрет приложения становятся тем, что нужно держать вне контроля источников. Вот, к сожалению, типичный пример того, как это может пойти не так. Другие подходы в конечном итоге схожи с ключами API или файлами хранилища ключей, которые вы должны защищать.

Мне кажется, что такие продукты, как Azure KeyVault, не лучше и бессмысленно сложнее, чем хранить свои секреты в отдельном конфигурационном файле и убедиться, что он находится в вашем .gitignore или аналогичном. Этот файл должен быть передан по мере необходимости через боковой канал. Конечно, люди, вероятно, будут небезопасно посылать это по электронной почте друг другу ...

Есть ли способ управлять секретами, который не просто перемещает проблему? Я считаю, что на этот вопрос есть один четко определенный ответ. По аналогии, если бы я спросил, как HTTPS не просто перемещает проблему, ответом было бы то, что ключи CA распространяются вместе с вашей ОС, и мы доверяем им, потому что мы доверяем методу распространения ОС. (Должны ли мы это отдельный вопрос ...)

StackOverthrow
источник

Ответы:

12

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

Но если все сделано правильно, вы переносите проблему из того места, которое трудно обеспечить должным образом, в место, которое вы можете лучше защитить. Например, размещение секретов в публичном репозитории github - это все равно, что оставлять ключи от дома приклеенными к входной двери. Любой, кто хочет их, не будет иметь проблем с их поиском. Но если вы перейдете к, скажем, хранилищу ключей во внутренней сети без внешних подключений, у вас будет гораздо больше шансов сохранить ваши пароли в безопасности. Это больше похоже на хранение ключей в кармане. Потерять их невозможно (например, эквивалент выдачи вашего пароля Azure), но это ограничивает вашу уязвимость по сравнению с прикосновением ваших ключей к вашей двери.

Becuzz
источник
4

Такие секреты, как ключи шифрования и учетные данные, не следует проверять в системе контроля версий по нескольким причинам. Во-первых, очевидно, что ключи шифрования и учетные данные должны всегда основываться на необходимости, а контроль версий не является надежным способом защиты информации от раскрытия. Другая причина, по которой вы не хотите, чтобы такие секреты были в вашем контроле исходного кода, обычно заключается в том, что секреты обычно (но не всегда) специфичны для определенного атрибута среды, в которой будет работать ваше приложение. (Например, получение закрытого ключа для создания цифрового подпись, необходимая для авторизации веб-службы, конкретная конечная точка этой веб-службы может работать в среде QA, требующей подписи QA).

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

Теперь рассмотрим некоторые из ваших аргументов:

В общем, разве мы не решаем проблему?

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

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

  • Храните ключ и зашифрованный файл на одном сервере (0 элементов управления, любой, кто имеет доступ к серверу, может получить конфиденциальную информацию тривиально)
  • Выполните действия, описанные выше, и защитите доступ к файлам к обоим файлам, чтобы он мог быть доступен для чтения только пользователю во время выполнения приложения ОС (1 элемент управления, скомпрометировавший пароль пользователя root или пользователя времени выполнения приложения, позволит злоумышленнику получить конфиденциальную информацию)
  • Сохраните ключ в хранилище внешнего ключа, получите ключ с помощью нескольких мер безопасности, таких как белый список IP-адресов, проверка подлинности сертификата и другие меры для приложения, которое может получить доступ к зашифрованному файлу в своей файловой системе. (Несколько элементов управления, несколько сбоев элементов управления безопасностью должны произойти, чтобы конфиденциальные данные были скомпрометированы)

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

Мне кажется, что такие продукты, как Azure KeyVault, не лучше и бессмысленно сложнее,

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

чем хранить свои секреты в отдельном конфигурационном файле и убедиться, что он находится в вашем .gitignore или аналогичном.

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

Конечно, люди, вероятно, будут небезопасно отправлять это по электронной почте друг другу ...

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

Есть ли способ управлять секретами, который не просто перемещает проблему? Я считаю, что на этот вопрос есть один четко определенный ответ. По аналогии, если бы я спросил, как HTTPS не просто перемещает проблему, ответом было бы то, что ключи CA распространяются вместе с вашей ОС, и мы доверяем им, потому что мы доверяем методу распространения ОС.

Безопасность не всегда устраняет проблемы, большую часть времени она контролирует их. Ваша аналогия лаконична, потому что именно это и делает криптография с открытым ключом. Мы «переносим проблему» в центр сертификации, полностью доверяя нашему центру сертификации, чтобы поручиться за идентификацию лица, владеющего публичным сертификатом. В принципе, ничего, кроме катастрофической цепочки сбоев (например, потеря доверия к ЦС), не должно произойти, чтобы привести к проблеме безопасности.

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

maple_shaft
источник
0

Стоит рассмотреть git secretпроект ( http://git-secret.io/ ), чтобы секретные файлы в git-репо зашифровывались с помощью асимметричного ключа. Открытые ключи также находятся в репо, закрытый ключ - нет.

Особенностями такого подхода является:

  • когда новый пользователь / компьютер должен расшифровать защищенные файлы - он публикует / отправляет свой открытый ключ gpg (gnu privacy guard aka pgp). Пользователь, который уже может дешифровать защищенные файлы, может перешифровать их новым дополнительным ключом - после этого новый пользователь может дешифровать защищенные файлы с помощью своего закрытого ключа.
  • очевидно, вам нужно контролировать, кто может совершать / отправлять в репозиторий git. В противном случае злоумышленник может зафиксировать свой собственный открытый ключ и подождать, пока кто-нибудь из авторизованных лиц не перешифрует защищенные файлы с помощью этого нового скомпрометированного открытого ключа.
Томас Кулханек
источник