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


Обеспечьте безопасность развертывания Azure Monitor

В этой статье приведены инструкции по безопасному развертыванию Azure Monitor и описано, как Майкрософт защищает Azure Monitor.

Прием журналов и хранение

Предоставление доступа к данным в рабочей области на основе необходимости

  1. Установите режим управления доступом к рабочему пространству на Использование прав на использование ресурсов или рабочей области, чтобы разрешить владельцам ресурсов использовать ресурс-контекст для доступа к их данным без необходимости явного предоставления доступа к рабочему пространству. Это упрощает настройку рабочей области и помогает обеспечить пользователям доступ только к нужным данным.
    Инструкции. Управление доступом к рабочим областям Log Analytics
  2. Назначьте соответствующую встроенную роль, чтобы предоставить администраторам разрешения рабочей области на уровне подписки, группы ресурсов или рабочей области в зависимости от их области обязанностей.
    Инструкции. Управление доступом к рабочим областям Log Analytics
  3. Примените RBAC уровня таблицы для пользователей, которым требуется доступ к набору таблиц в нескольких ресурсах. Пользователи с разрешениями на таблицу имеют доступ ко всем данным в таблице независимо от их разрешений ресурса.
    Инструкции. Управление доступом к рабочим областям Log Analytics

Обеспечение безопасности данных журналов при передаче

Если вы используете агенты, соединители или API журналов для запроса или отправки данных в рабочую область, используйте протокол TLS 1.2 или более поздней версии, чтобы обеспечить безопасность передаваемых данных. Более старые версии TLS и SSL имеют уязвимости и, хотя они по-прежнему могут работать для обеспечения обратной совместимости, они не рекомендуется, и отрасль быстро переместилась, чтобы отказаться от поддержки этих старых протоколов.

Совет по стандартам безопасности PCI установил крайний срок 30 июня 2018 года, чтобы отключить старые версии TLS/SSL и обновить до более безопасных протоколов. После удаления устаревшей поддержки Azure клиенты, которые не полностью взаимодействуют по протоколу TLS 1.2 или более поздней версии, не смогут отправлять или запрашивать данные в журналы Azure Monitor.

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

Это важно

В соответствии с инициативой по выводу из эксплуатации устаревшего TLS во всех службах Azure, протокол TLS 1.0/1.1 будет полностью заблокирован для журналов Azure Monitor до дат, указанных в следующей таблице. Чтобы обеспечить лучшее шифрование в классе, журналы Azure Monitor уже используют TLS 1.2/1.3 в качестве подходящих механизмов шифрования.

Дата применения Запрос конечных точек API Версия протокола TLS
1 июль 2025 г. Конечные точки интерфейса API для запросов журналов TLS 1.2 или более поздней версии
1 марта 2026 г. Конечные точки API приема журналов TLS 1.2 или более поздней версии

Рекомендуемое действие

Чтобы избежать потенциальных сбоев служб, убедитесь, что ресурсы, взаимодействующие с конечными точками API журналов, не имеют зависимостей от протоколов TLS 1.0 или 1.1.

Например, клиенты, настроенные для работы со старыми серверами, могут по-прежнему использовать протоколы TLS 1.0/1.1 для запуска подтверждения TLS. Когда клиент подключается к журналам Azure Monitor до даты применения TLS 1.2, конечная точка API журналов по-прежнему позволяет первоначальному подключению TLS 1.0/1.1 для клиента hello, но направляет клиент использовать TLS 1.2 или более поздней версии. Затем клиент может установить подключение по протоколу TLS 1.2/1.3 или удалить подключение. После даты вступления в силу TLS 1.2 конечная точка API для журналов отбрасывает любой трафик, который не соответствует TLS 1.2 или более поздней версии.

Общие вопросы о проблеме устаревшего TLS или о том, как протестировать поддерживаемые наборы шифров, см. статьи "Решение проблем TLS и Поддержка TLS в Azure Resource Manager.

Настройка аудита запросов журнала

  1. Настройте аудит запросов журнала для записи сведений о каждом запросе, выполняемом в рабочей области.
    Инструкции: Аудит запросов в журналах Azure Monitor
  2. Следует обрабатывать данные аудита запросов журнала как данные безопасности и обеспечить безопасный доступ к таблице LAQueryLogs.
    Инструкции.Настройка доступа к данным в рабочей области на основе необходимости.
  3. Если вы отделяете данные о работе и безопасности, отправьте журналы аудита для каждой рабочей области в локальную рабочую область или консолидируйте в выделенную рабочую область безопасности.
    Инструкции.Настройка доступа к данным в рабочей области на основе необходимости.
  4. Используйте аналитику рабочей области Log Analytics для периодического просмотра данных аудита запросов журнала.
    Инструкции: Инсайты рабочей области Log Analytics.
  5. Создайте правила генерации оповещений поиска по журналам, чтобы уведомить вас о попытке несанкционированных пользователей выполнять запросы.
    Инструкции: Правила оповещений для поиска в журналах.

Обеспечение неизменяемости данных аудита

Azure Monitor — это платформа данных только для добавления, но она включает в себя положения для удаления данных в целях соответствия требованиям. Чтобы защитить данные аудита:

  1. Установите блокировку в рабочей области Log Analytics, чтобы предотвратить все действия, которые могут привести к удалению данных, такие как очистка, удаление таблиц и изменения в ретенции данных на уровне таблиц или целой рабочей области. Однако следует помнить, что эту блокировку можно удалить.
    Инструкции. Блокировка ресурсов для защиты инфраструктуры

  2. Если вам требуется полностью защищенное решение, рекомендуется экспортировать данные в неизменяемое решение для хранения:

    1. Определите определенные типы данных, которые следует экспортировать. Не все типы журналов имеют одинаковую релевантность для соответствия требованиям, аудита или безопасности.
    2. Используйте экспорт данных для отправки данных в учетную запись хранения Azure.
      Инструкции. Экспорт данных рабочей области Log Analytics в Azure Monitor
    3. Задайте политики неизменяемости для защиты от изменения данных.
      Инструкции:Настройка политик неизменяемости для версий BLOB-объектов

Фильтрация или скрытие конфиденциальных данных в рабочей области

Если данные журнала содержат конфиденциальную информацию:

  1. Фильтрация записей, которые не должны собираться с помощью конфигурации для конкретного источника данных.
  2. Используйте преобразование, если следует удалить или запутать только определенные столбцы в данных.
    Инструкции. Преобразования в Azure Monitor
  3. Если у вас есть стандарты, требующие, чтобы исходные данные были неизменены, используйте литерал 'h' в запросах KQL для маскировки результатов запросов, отображаемых в рабочих книгах.
    Инструкции. Нефускированные строковые литералы

Очистка конфиденциальных данных, собранных случайно

  1. Периодически проверяйте частные данные, которые могут случайно собираться в рабочей области.
  2. Используйте очистку данных для удаления нежелательных данных. Обратите внимание, что данные в таблицах с вспомогательным планом в настоящее время не могут быть удалены.
    Инструкции.Управление личными данными в журналах Azure Monitor и Application Insights

Azure Monitor шифрует все данные в состоянии покоя и сохраненные запросы с использованием ключей, управляемых Microsoft (MMK). Если вы собираете достаточно данных для выделенного кластера, свяжите рабочую область с выделенным кластером для расширенных функций безопасности, в том числе:

  • Управляемые клиентом ключи для повышения гибкости и управления жизненным циклом ключей. Если вы используете Microsoft Sentinel, убедитесь, что вы знакомы с рекомендациями по настройке управляемого клиентом ключа Microsoft Sentinel.
  • Блокировка клиента для Microsoft Azure для проверки и утверждения или отклонения запросов на доступ к данным клиента. Блокировка клиента используется, когда инженер Майкрософт должен получить доступ к данным клиента, независимо от того, отвечает ли клиент на запрос в службу поддержки, инициированный клиентом, или проблема, обнаруженная корпорацией Майкрософт. В настоящее время Lockbox не может быть применен к таблицам с «Auxiliary plan».

Инструкции. Создание выделенного кластера и управление ими в журналах Azure Monitor

Корпорация Майкрософт защищает подключения к общедоступным конечным точкам с помощью сквозного шифрования. Если требуется частная конечная точка, используйте приватный канал Azure , чтобы разрешить ресурсам подключаться к рабочей области Log Analytics через авторизованные частные сети. Вы также можете использовать Private Link для принудительного приема данных рабочей области через ExpressRoute или VPN.

Инструкции. Разработка настройки Приватного канала Azure

Поглощение TLS в Application Insights

Поддерживаемые конфигурации TLS

Application Insights использует TLS 1.2 и 1.3. Кроме того, следующие наборы шифров и эллиптические кривые также поддерживаются в каждой версии.

Версия Комплекты шифров Эллиптические кривые
TLS 1.2 • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• NistP384
• NistP256
TLS 1.3 • TLS_AES_256_GCM_SHA384
• TLS_AES_128_GCM_SHA256
• NistP384
• NistP256

Устаревшие настройки TLS

Это важно

Чтобы повысить безопасность, Azure блокирует следующие конфигурации TLS для Application Insights 1 мая 2025 года. Это изменение является частью отказа от устаревшего TLS в Azure:

  • Версии протокола TLS 1.0 и TLS 1.1
  • Устаревшие наборы шифров TLS 1.2 и TLS 1.3
  • Устаревшие эллиптические кривые TLS

TLS 1.0 и TLS 1.1

Tls 1.0 и TLS 1.1 удаляются.

TLS 1.2 и TLS 1.3

Версия Комплекты шифров Эллиптические кривые
TLS 1.2 * TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
* TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
* TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
* TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
* TLS_RSA_WITH_AES_256_GCM_SHA384
* TLS_RSA_WITH_AES_128_GCM_SHA256
* TLS_RSA_WITH_AES_256_CBC_SHA256
* TLS_RSA_WITH_AES_128_CBC_SHA256
* TLS_RSA_WITH_AES_256_CBC_SHA
* TLS_RSA_WITH_AES_128_CBC_SHA
* кривая25519
TLS 1.3 * кривая25519

Дополнительные сведения см. в разделе "Поддержка TLS" в Application Insights: вопросы и ответы.

Уведомления

Управление разрешениями правила генерации оповещений поиска по журналам с помощью управляемых удостоверений

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

Использование управляемого удостоверения требуется, если запрос правила обращается к Azure Data Explorer (ADX) или Azure Resource Graph (ARG).

Инструкции. Создание или изменение правила генерации оповещений поиска по журналам.

Назначение роли читателя мониторинга всем пользователям, которым не нужны права конфигурации

Повышение безопасности путем предоставления пользователям минимальных привилегий, необходимых для их роли.

Инструкции. Роли, разрешения и безопасность в Azure Monitor.

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

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

Инструкции.Настройка проверки подлинности для безопасного веб-перехватчика.

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

Azure Monitor шифрует все данные и сохраненные запросы в состоянии покоя с помощью ключей, управляемых Microsoft (MMK). Если требуется собственный ключ шифрования и сбор достаточно данных для выделенного кластера, используйте управляемые клиентом ключи для повышения гибкости и управления жизненным циклом ключей.

Инструкции. Управляемые клиентом ключи.

Если вы используете Microsoft Sentinel, см. раздел"Настройка управляемого клиентом ключа Microsoft Sentinel".

Мониторинг виртуальных машин

Реализация мониторинга безопасности виртуальных машин с помощью служб безопасности Azure

Хотя Azure Monitor может собирать события безопасности с виртуальных машин, он не предназначен для мониторинга безопасности. Azure включает несколько служб, таких как Microsoft Defender для облака и Microsoft Sentinel , которые вместе предоставляют полное решение для мониторинга безопасности. См. мониторинг безопасности для сравнения этих служб.

Корпорация Майкрософт защищает подключения к общедоступным конечным точкам с помощью сквозного шифрования. Если требуется частная конечная точка, используйте приватный канал Azure , чтобы разрешить ресурсам подключаться к рабочей области Log Analytics через авторизованные частные сети. Вы также можете использовать Private Link для принудительного приема данных рабочей области через ExpressRoute или VPN.

Инструкции. Разработка настройки Приватного канала Azure

Мониторинг контейнеров

Подключение кластеров к инсайтам контейнеров с помощью аутентификации с управляемыми идентификаторами.

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

Инструкции:Перейти на аутентификацию с управляемой идентичностью

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

Инструкции: Подробнее о настройке кластера для приватной ссылки см. в статье "Включение приватной ссылки для мониторинга Kubernetes в Azure Monitor". Дополнительные сведения о запросе данных с помощью частной ссылки см. в Использование частных конечных точек для Управляемого Prometheus и рабочей области Azure Monitor.

Мониторинг сетевого трафика в кластеры и из кластеров с помощью аналитики трафика

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

Включение наблюдаемости сети

Надстройка "Наблюдаемость сети" для AKS обеспечивает наблюдаемость на нескольких уровнях в сетевом стеке Kubernetes. Наблюдение доступа между службами в кластере (восточно-западный трафик).

Инструкции. Настройка наблюдаемости сети контейнеров для службы Azure Kubernetes (AKS)

Защита рабочей области Log Analytics

Аналитика контейнеров отправляет данные в рабочую область Log Analytics. Обязательно обеспечьте защиту сбора и хранения данных журналов в рабочей области Log Analytics.

Инструкции. Прием журналов и хранение.

Как компания Microsoft обеспечивает безопасность Azure Monitor

Инструкции, описанные в этой статье, описаны в модели ответственности майкрософт. В рамках этой модели общей ответственности корпорация Майкрософт предоставляет эти меры безопасности клиентам Azure Monitor:

Рекомендации и лучшие практики по безопасности Azure

Инструкции по безопасному развертыванию Azure Monitor основаны на и соответствуют комплексным рекомендациям и лучшим практикам по облачной безопасности Azure, включая следующие:

  • Cloud Adoption Framework, который предоставляет рекомендации по безопасности для команд, которые управляют инфраструктурой технологий.
  • Azure Well-Architected Framework, которая предоставляет архитектурные рекомендации по созданию безопасных приложений.
  • Microsoft Cloud Security Benchmark (MCSB), описывающий доступные функции безопасности и рекомендуемые оптимальные конфигурации.
  • Принципы безопасности нулевого доверия, которые предоставляют рекомендации для групп безопасности для реализации технических возможностей для поддержки инициативы модернизации "Нулевое доверие".

Следующий шаг