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

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

  • Статья

Применяется к следующей рекомендации по контрольному списку Well-Architected Security в Power Platform:

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

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

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

Определения

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

Важно

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

Параметры приложения, которые не являются секретами, например URL-адреса API, необходимые для приложения, следует хранить отдельно от кода приложения или секретов приложения. Чтобы сохранить конфигурацию приложения, рассмотрите возможность использования пользовательского соединителя или переменных среды. Другой вариант — использовать таблицу Dataverse для хранения метаданных о конфигурации приложения. Однако вам нужно будет найти способ заполнить эти данные в новой среде, например перенести данные конфигурации из среды разработки в тестовую или рабочую среду. Для этого вы можете использовать потоки данных.

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

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

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

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

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

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

Предварительно отправленные ключи

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

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

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

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

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

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

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

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

Смена секретов

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

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

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

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

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

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

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

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

Заметка

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

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

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

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

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

Возможности в Power Platform

В следующих разделах описаны функции и возможности Power Platform, которые можно использовать для управления секретами приложения.

Использование секретов Azure Key Vault

Переменные среды позволяют ссылаться на секреты, хранящиеся в Azure Key Vault. Затем эти секреты становятся доступными для использования в потоках Power Automate и нестандартных соединителях. Обратите внимание, что секреты недоступны для использования в других настройках или через API.

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

Использование средства проверки решений

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

Использование действий CyberArk

CyberArk обеспечивает платформу защиты личности, которая обеспечивает сквозную идентификацию людей и компьютеров. Классические потоки Power Automate позволяют получать учетные данные из CyberArk. Дополнительные сведения см. в разделе Действия CyberArk.

См. также

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

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

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