Блог

Главная - Вопросы по программированию - Есть ли необходимость использовать .Средство управления секретами Net Core?

Есть ли необходимость использовать .Средство управления секретами Net Core?

#.net-core #asp.net-core-security

#.net-core #asp.net-core-security

Вопрос:

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

Теперь вопрос в том, зачем нам использовать этот относительно громоздкий подход, если мы можем просто читать из appsettings.secrets.json файлов, например, с которыми намного проще работать, просматривать секреты и добавлять их в .gitignore, чтобы они никогда не появлялись в системе управления версиями.

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

P.S. Я могу думать только об опасности случайной фиксации файла secrets, но это не так просто, если вы не измените весь свой файл .gitignore

Комментарии:

1. То, что вы описываете, — это то же самое, что делает инструмент, только вручную. Это более громоздко, чем просто вызвать инструмент. Вы могли бы автоматизировать это, конечно. Однако на этом этапе вы бы перестроили сам инструмент управления секретами. Что касается случайной фиксации файла secrets, это очень просто — кто-то в команде допустит ошибку в его написании. Или поместите его не в ту папку

2. Ну, проще передать файл кому-то, чем обычно запускать команды, поскольку это требуется на каждой новой машине разработчиков

3. Другой проблемой является сервер сборки . Как .secrets.json файл будет доставлен туда?

4. Еще одна проблема заключается в том, что работа через .gitignore обходит соглашения о конфигурации. Распространенным способом защиты секретов в производстве является использование службы управления ключами вашего облачного провайдера или поставщика защиты данных. Инструмент управления секретами отлично вписывается в эту архитектуру и, по сути, является просто еще одним поставщиком конфигурации. Вы можете использовать разные секреты так же, как вы можете использовать разные поставщики конфигурации для каждой среды. Однако вам придется вручную переместить .secrets.json файл и … изменить свой код, чтобы искать его в зависимости от среды

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

Ответ №1:

Я думаю, мне следует поместить комментарии в один ответ.

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

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

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

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

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

  • В корпоративной среде вы могли бы поместить файл «secrets» в общий файловый ресурс, где только члены команды имеют доступ для чтения, и предоставить общий доступ к местоположению через другого поставщика конфигурации, например, через переменные среды. Файл может быть защищен с помощью группы безопасности, что означает, что добавление / удаление доступа к нему будет намного проще, чем добавление / удаление доступа к отдельным файлам. Вы могли бы включить аудит в общей файловой системе, чтобы также видеть, кто обращается к файлу secrets. Это то, чего вы не можете сделать с .gitignore

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

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

  • Вы также могли бы скопировать некоторые файлы настроек. Вы могли бы сделать это с помощью etcd в Linux или репликации файлов в Windows. Это также один из способов доставки изменений настроек на несколько серверов / контейнеров.