Разрешить поду в кластере AKS безопасно получать доступ к Azure Key Vault без использования хранимых учетных данных, таких как секреты клиента или сертификаты.
→Используйте Azure AD Workload Identity. Создайте управляемое удостоверение, назначаемое пользователем, установите федеративную учетную запись между учетной записью службы K8s и управляемым удостоверением, и предоставьте управляемому удостоверению доступ к Key Vault.
Почему: Workload Identity использует федерацию OIDC для обмена токена Kubernetes на токен Azure AD, полностью устраняя необходимость хранить, управлять или ротировать секреты в кластере.
Источник↗
Защитить Azure Key Vault, разрешив доступ только из определенных VNets, регистрировать все операции и защищать от случайного удаления критически важных ключей.
→Настройте брандмауэр Key Vault так, чтобы он разрешал доступ из "Частной конечной точки и выбранных сетей". Включите диагностическое логирование в рабочую область Log Analytics. Включите как Soft Delete, так и Purge Protection.
Почему: Soft Delete позволяет восстановиться после случайного удаления, но Purge Protection предотвращает даже привилегированному пользователю окончательное удаление хранилища или его содержимого в течение периода хранения. Эта комбинация критически важна для защиты ключей TDE.
Службе Azure App Service необходимо аутентифицироваться в Azure SQL Database для получения данных, не храня пароли строк подключения в конфигурации.
→Включите управляемое удостоверение, назначаемое системой, в App Service. В Azure SQL создайте содержащегося пользователя, сопоставленного с именем управляемого удостоверения App Service, и предоставьте ему необходимые роли базы данных (например, db_datareader).
Почему: Управляемое удостоверение предоставляет удостоверение для самого ресурса Azure в Azure AD. Azure автоматически обрабатывает создание и ротацию учетных данных, устраняя хранимые секреты, что является основной лучшей практикой безопасности.
Шифрование управляемых дисков Azure VM в состоянии покоя с использованием ключа, который ваша организация контролирует в Azure Key Vault.
→Создайте ресурс Disk Encryption Set. Настройте его на использование ключа, управляемого клиентом (CMK), из вашего Azure Key Vault. Назначьте Disk Encryption Set управляемым дискам VM.
Почему: Это шифрование на стороне сервера (SSE) с CMK, которое шифрует данные в инфраструктуре хранения. Оно проще, чем Azure Disk Encryption (ADE), который использует BitLocker/dm-crypt для шифрования данных внутри гостевой ОС и обычно используется для дисков ОС и данных вместе.
Обеспечить сканирование образов контейнеров, хранящихся в Azure Container Registry (ACR), на наличие уязвимостей перед их развертыванием.
→Включите Microsoft Defender for Containers. Это автоматически сканирует образы в ACR при их загрузке, извлечении и на постоянной основе на предмет вновь обнаруженных уязвимостей.
Почему: Эта практика безопасности "сдвига влево" выявляет уязвимости на ранних этапах конвейера CI/CD. Defender for Containers предоставляет эту возможность сканирования нативно в экосистеме Azure.
Обнаружение и получение оповещений о потенциальных SQL-инъекциях и аномальных паттернах доступа к базе данных Azure SQL.
→Включите Microsoft Defender for SQL на логическом сервере SQL. Это обеспечивает расширенную защиту от угроз и оценку уязвимостей.
Почему: Defender for SQL — это специализированный план защиты рабочих нагрузок, который использует поведенческую аналитику и машинное обучение для обнаружения угроз, таких как SQL-инъекции, атаки методом перебора и необычный доступ к данным, которые не видны сетевым инструментам.
Ограничить учетную запись хранения определенной VNet, но при этом разрешить доступ к ней доверенным службам Microsoft, таким как Azure Backup.
→В сетевых настройках учетной записи хранения выберите "Включено для выбранных виртуальных сетей и IP-адресов". Добавьте требуемую VNet/подсеть. Затем установите флажок "Разрешить доверенным службам Microsoft доступ к этой учетной записи хранения".
Почему: Исключение для доверенных служб создает безопасный путь для определенных служб Microsoft для обхода правил брандмауэра VNet. Без него службы, работающие от имени пользователя (например, Backup или Portal), были бы заблокированы.
Защита определенных конфиденциальных столбцов данных (например, номеров кредитных карт) в базе данных Azure SQL, даже от привилегированных администраторов баз данных (DBA).
→Используйте Always Encrypted. Драйвер клиентского приложения прозрачно шифрует данные перед отправкой в базу данных, и ключи шифрования никогда не раскрываются движку базы данных.
Почему: Прозрачное шифрование данных (TDE) шифрует всю базу данных в состоянии покоя (на диске), но DBA с доступом все еще может видеть данные. Always Encrypted обеспечивает шифрование на стороне клиента, разделяя тех, кто управляет данными (DBA), и тех, кто может их видеть.
Обрабатывать высокочувствительные данные на виртуальной машине Azure, обеспечивая их шифрование и защиту даже в памяти от гипервизора и облачных операторов.
→Разверните конфиденциальную виртуальную машину Azure (Azure Confidential VM). Эти виртуальные машины используют аппаратные доверенные среды выполнения (TEE), такие как AMD SEV-SNP, для создания изолированного, зашифрованного пространства памяти.
Почему: Стандартное шифрование виртуальных машин (например, ADE или SSE) защищает данные в состоянии покоя. Confidential Computing — единственная технология, которая защищает данные *во время использования* в памяти, обеспечивая высочайший уровень конфиденциальности и изоляции данных в облаке.
Службе App Service требуется использовать секрет из Key Vault в качестве настройки приложения, не изменяя код приложения для использования Key Vault SDK.
→Включите управляемое удостоверение в App Service и предоставьте ему разрешения "Get" на секреты в Key Vault. В конфигурации App Service создайте настройку приложения со значением, отформатированным как ссылка на Key Vault: `@Microsoft.KeyVault(SecretUri=...)`.
Почему: Эта функция позволяет платформе App Service разрешать значение секрета во время выполнения, используя управляемое удостоверение. Код приложения просто считывает стандартную переменную среды, абстрагируя взаимодействие с Key Vault.
Хранить данные, связанные с соответствием требованиям, в Azure Blob Storage в состоянии WORM (Write-Once, Read-Many) в течение 7 лет.
→Для контейнера хранения настройте политику неизменяемости. Используйте политику хранения на основе времени, установленную на 7 лет, и заблокируйте политику. После блокировки данные не могут быть изменены или удалены кем-либо до истечения периода хранения.
Почему: Эта функция специально разработана для удовлетворения требований нормативного соответствия (например, SEC 17a-4). Блокировка политики является критическим шагом, который делает ее по-настоящему неизменяемой.
В многопользовательском приложении, использующем одну базу данных Azure SQL, убедитесь, что пользователи из одного клиента могут видеть только данные, принадлежащие их собственному клиенту.
→Реализуйте безопасность на уровне строк (RLS). Создайте политику безопасности с предикатной функцией, которая фильтрует строки на основе идентификатора клиента пользователя, который хранится в контексте сеанса или в таблице поиска пользователей.
Почему: RLS применяет логику доступа непосредственно в движке базы данных. Это более безопасно и надежно, чем реализация фильтрации на уровне приложения, поскольку ее невозможно обойти, и она прозрачна для кода приложения.
Защита виртуальных машин поколения 2 от буткитов и руткитов путем обеспечения целостности всей цепочки загрузки от UEFI до ядра ОС.
→Создайте виртуальную машину с включенной функцией Trusted Launch. Это активирует Secure Boot, который проверяет подписи всех компонентов загрузки, и виртуальный Trusted Platform Module (vTPM) для измеренной загрузки и аттестации.
Почему: Trusted Launch решает проблемы сложного, низкоуровневого вредоносного ПО, которое может подорвать традиционные средства контроля безопасности на уровне ОС. Он устанавливает аппаратный корень доверия для виртуальной машины.
