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

  • Статья

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

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

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

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

Определения 

Срок Определение
Сертификаты Цифровые файлы, которые содержат открытые ключи для шифрования или расшифровки.
Подтверждение компетенции Сведения, используемые для проверки удостоверения издателя или потребителя в канале коммуникации.
Проверка учетных данных Процесс проверки исходного кода, чтобы убедиться, что секреты не включены.
Шифрование Процесс, с помощью которого данные нечитаемые и заблокированы с помощью секретного кода.
Ключ Секретный код, используемый для блокировки или разблокировки зашифрованных данных.
Доступ к наименьшим привилегиям Принцип нулевого доверия, направленный на минимизацию набора разрешений для выполнения функции задания.
Управляемое удостоверение Удостоверение, назначенное ресурсам и управляемое Azure.
Nonsecret Информация, которая не ставит под угрозу безопасность рабочей нагрузки, если она утечка.
Rotation Процесс регулярного обновления секретов таким образом, чтобы, если они скомпрометировались, они доступны только в течение ограниченного времени.
Секретный Конфиденциальный компонент системы, упрощающий взаимодействие между компонентами рабочей нагрузки. При утечке секреты могут вызвать нарушение.
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 refresh token.

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

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

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

Безопасное использование секретов рабочей нагрузки

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

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

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

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

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

Примечание.

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

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

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

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

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

Упрощение функций Azure

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

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

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

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

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

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

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

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

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