Такие секреты, как ключи шифрования и учетные данные, не следует проверять в системе контроля версий по нескольким причинам. Во-первых, очевидно, что ключи шифрования и учетные данные должны всегда основываться на необходимости, а контроль версий не является надежным способом защиты информации от раскрытия. Другая причина, по которой вы не хотите, чтобы такие секреты были в вашем контроле исходного кода, обычно заключается в том, что секреты обычно (но не всегда) специфичны для определенного атрибута среды, в которой будет работать ваше приложение. (Например, получение закрытого ключа для создания цифрового подпись, необходимая для авторизации веб-службы, конкретная конечная точка этой веб-службы может работать в среде QA, требующей подписи QA).
Правильный способ обращения с окружающей средой (или глобальной тайной) состоит в том, чтобы обращаться с ней так же, как с любым другим атрибутом конфигурации среды, с дополнительными мерами безопасности для хорошей меры. Хорошо спроектированный, независимый и обновляемый модуль кода должен быть идентичен в разных средах, чтобы среда, в которой они развернуты, информировала приложение о его атрибутах (например, сведения о подключении к базе данных, учетные данные, конечные точки веб-службы, пути к файлам и т. Д.). Теперь детали конфигурации, важные для вашего приложения, выводятся наружу и становятся параметрами конфигурации вашей среды.
Теперь рассмотрим некоторые из ваших аргументов:
В общем, разве мы не решаем проблему?
Идеальной безопасности не существует, однако «перемещение» проблемы в область, где могут быть размещены дополнительные меры и средства контроля, увеличит сложность и уменьшит вероятность случайного или злонамеренного раскрытия секретов. Хорошее практическое правило, которому следует следовать при разработке системы, в которой должны быть защищены конфиденциальные данные, - всегда помещать элементы управления по двое. Под этим я подразумеваю, что для обеспечения случайного или злонамеренного раскрытия конфиденциальной информации или инцидента в системе безопасности должен произойти сбой или два или более элементов управления.
Хорошим примером этого может быть хранение зашифрованного файла на сервере. У меня также есть секретный ключ расшифровки, который я должен хранить в секрете в другом файле.
- Храните ключ и зашифрованный файл на одном сервере (0 элементов управления, любой, кто имеет доступ к серверу, может получить конфиденциальную информацию тривиально)
- Выполните действия, описанные выше, и защитите доступ к файлам к обоим файлам, чтобы он мог быть доступен для чтения только пользователю во время выполнения приложения ОС (1 элемент управления, скомпрометировавший пароль пользователя root или пользователя времени выполнения приложения, позволит злоумышленнику получить конфиденциальную информацию)
- Сохраните ключ в хранилище внешнего ключа, получите ключ с помощью нескольких мер безопасности, таких как белый список IP-адресов, проверка подлинности сертификата и другие меры для приложения, которое может получить доступ к зашифрованному файлу в своей файловой системе. (Несколько элементов управления, несколько сбоев элементов управления безопасностью должны произойти, чтобы конфиденциальные данные были скомпрометированы)
Опять же, не существует такой вещи, как идеальная защита, но цель наличия нескольких элементов управления гарантирует, что для возникновения раскрытия необходимо несколько сбоев.
Мне кажется, что такие продукты, как Azure KeyVault, не лучше и бессмысленно сложнее,
Сложно да, бессмысленно совершенно субъективно. Мы не можем обсуждать бессмысленность дополнительной безопасности, если не будем реально учитывать, насколько серьезным было бы раскрытие конфиденциальных данных. Если бы кто-то мог использовать конфиденциальные данные для отправки незаконных электронных переводов из вашего финансового учреждения, то что-то вроде хранилища ключей - самая отдаленная вещь из того, что было бы бессмысленно.
чем хранить свои секреты в отдельном конфигурационном файле и убедиться, что он находится в вашем .gitignore или аналогичном.
До тех пор, пока кто-то случайно не проверит его в системе контроля версий, теперь этот секрет навсегда встроен в историю системы контроля версий.
Конечно, люди, вероятно, будут небезопасно отправлять это по электронной почте друг другу ...
Безопасность - это не только техническая проблема, но и проблема людей. Это было бы не по теме, однако я чувствую, что в этот момент вы пытаетесь отговорить себя от необходимости делать все необходимое.
Есть ли способ управлять секретами, который не просто перемещает проблему? Я считаю, что на этот вопрос есть один четко определенный ответ. По аналогии, если бы я спросил, как HTTPS не просто перемещает проблему, ответом было бы то, что ключи CA распространяются вместе с вашей ОС, и мы доверяем им, потому что мы доверяем методу распространения ОС.
Безопасность не всегда устраняет проблемы, большую часть времени она контролирует их. Ваша аналогия лаконична, потому что именно это и делает криптография с открытым ключом. Мы «переносим проблему» в центр сертификации, полностью доверяя нашему центру сертификации, чтобы поручиться за идентификацию лица, владеющего публичным сертификатом. В принципе, ничего, кроме катастрофической цепочки сбоев (например, потеря доверия к ЦС), не должно произойти, чтобы привести к проблеме безопасности.
Как и во многих других аспектах, безопасность - это линия, которую вы должны провести на основе субъективных критериев, характера данных, последствий раскрытия информации, склонности к риску, бюджета и т. Д.