Рекомендации по защите секретов приложения

  • Статья

Применяется к этой рекомендации по безопасности Azure Well-Architected Framework:

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

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

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

Определения 

Термин Определение
Сертификаты Цифровые файлы, которые содержат открытые ключи для шифрования или расшифровки.
Подтверждение компетенции Сведения, используемые для проверки удостоверения издателя или потребителя в канале связи.
Проверка учетных данных Процесс проверки исходного кода, чтобы убедиться, что секреты не включены.
Шифрование Процесс, с помощью которого данные делаются нечитаемыми и блокируются с помощью секретного кода.
Ключ Секретный код, используемый для блокировки или разблокировки зашифрованных данных.
Доступ с минимальными привилегиями Принцип "Никому не доверяй", направленный на минимизацию набора разрешений для выполнения функции задания.
Управляемое удостоверение Удостоверение, назначенное ресурсам и управляемое Azure.
Несекретный Информация, которая не ставит под угрозу состояние безопасности рабочей нагрузки в случае утечки.
Поворот Процесс регулярного обновления секретов, чтобы в случае их компрометации они были доступны только в течение ограниченного времени.
Секрет Конфиденциальный компонент системы, упрощающий обмен данными между компонентами рабочей нагрузки. В случае утечки секреты могут привести к нарушению безопасности.
X.509 Стандарт, определяющий формат сертификатов открытого ключа.

Важно!

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

Примером несекретных параметров конфигурации приложения, таких как URL-адреса интерфейсов API, которые использует приложение. Эти сведения не должны храниться вместе с кодом приложения или секретами приложения. Для управления этими параметрами рекомендуется использовать специальную систему управления конфигурацией, например Конфигурация приложений Azure. Дополнительные сведения см. в статье Что такое Конфигурация приложений Azure?.

Ключевые стратегии проектирования

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

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

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

  • Доступ к секретам должны иметь только доверенные удостоверения.

  • Для проверки и проверки доступа к секретам следует вести журнал аудита.

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

Безопасные методики по управлению секретами

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

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

Общие ключи

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

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

Дополнительные сведения см. в статье Рекомендации по управлению удостоверениями и доступом.

Хранилище секретов

Используйте систему управления секретами, например Azure Key Vault, для хранения секретов в защищенной среде, шифрования неактивных и передаваемых данных, а также аудита доступа и изменений в секретах. Если вам нужно хранить секреты приложения, храните их за пределами исходного кода, чтобы упростить смену.

Сертификаты должны храниться только в Key Vault или в хранилище сертификатов ОС. Например, не рекомендуется хранить сертификат X.509 в PFX-файле или на диске. Если вам нужен более высокий уровень безопасности, выберите системы с возможностями аппаратного модуля безопасности (HSM), а не хранилища секретов на основе программного обеспечения.

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

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

Также необходимо управлять доступом на уровне секрета. Каждый секрет должен иметь доступ только к одному ресурсу область. Создайте границы изоляции, чтобы компонент мог использовать только необходимые секреты. Если изолированный компонент скомпрометирован, он не может получить контроль над другими секретами и, возможно, всей рабочей нагрузкой. Один из способов изолировать секреты — использовать несколько хранилищ ключей. Дополнительные затраты на создание дополнительных хранилищ ключей не требуются.

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

смены секретов;

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

Тщательно обрабатывайте маркеры доступа OAuth с учетом времени их жизни. Подумайте, нужно ли настроить окно экспозиции до более короткого периода. Маркеры обновления должны храниться безопасно с ограниченным доступом к приложению. Продленные сертификаты должны также использовать новый ключ. Сведения о маркерах обновления см. в разделе Secure OAuth 2.0 On-Behalf-Of.

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

Дополнительные сведения о том, как служба хранилища Azure обрабатывает смену, см. в статье Управление ключами доступа к учетной записи.

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

Безопасные методики использования секретов

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

Предотвращение жесткого кодирования

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

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

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

Примечание

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

Реагирование на смену секретов

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

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

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

Упрощение azure

Храните секреты с помощью Key Vault. Храните секреты в системе управления секретами Azure, Key Vault, управляемом устройстве HSM Azure и других расположениях. Дополнительные сведения см. в статье Выбор правильного решения для управления ключами.

Интеграция управления доступом на основе удостоверений. Microsoft Entra идентификаторы и управляемые удостоверения помогают свести к минимуму потребность в секретах. Microsoft Entra ID обеспечивает высокий уровень безопасности и удобство использования для управления доступом со встроенными механизмами для обработки смены ключей, аномалий и т. д.

Используйте управление доступом на основе ролей Azure (RBAC), чтобы назначать разрешения пользователям, группам и приложениям на определенном область.

Используйте модель доступа для управления хранилищами ключей, разрешениями и секретами. Дополнительные сведения см. в статье Общие сведения о модели Access.

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

Не храните ключи и секреты для любого типа среды в файлах конфигурации приложений или конвейерах непрерывной интеграции и непрерывной поставки (CI/CD). Разработчики должны использовать подключенные службы Visual Studio или локальные файлы для доступа к учетным данным.

Контрольный список по безопасности

Ознакомьтесь с полным набором рекомендаций.

Контрольный список по безопасности