Поделиться через

Стратегии архитектуры для защиты секретов приложений

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

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

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

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

Терминология 

Срок Определение
Сертификаты Цифровые файлы, которые содержат открытые ключи для шифрования или расшифровки.
Credentials Сведения, используемые для проверки удостоверения издателя или потребителя в канале коммуникации.
Сканирование учетных данных Процесс проверки исходного кода, чтобы убедиться, что секреты не включены.
Encryption Процесс, с помощью которого данные делаются нечитаемыми и заблокированы секретным кодом.
Key Секретный код, используемый для блокировки или разблокировки зашифрованных данных.
Доступ с минимальными привилегиями Принцип нулевого доверия, направленный на минимизацию набора разрешений для выполнения функции задания.
Манажируемая идентичность Удостоверение, назначенное ресурсам и управляемое администратором 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, Azure Managed HSM и других местах. Дополнительные сведения см. в статье "Выбор правильного решения по управлению ключами".

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

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

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

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

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

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

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

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

  • Last updated on