Базовый план безопасности Azure для Службы Azure Bot

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

Если функция имеет соответствующие Политика Azure определения, которые они перечислены в этом базовом плане, чтобы помочь измерить соответствие элементам управления и рекомендациям Azure Security Benchmark. Для реализации определенных сценариев безопасности некоторые рекомендации могут потребовать платного плана Microsoft Defender.

Примечание

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

Безопасность сети

Дополнительные сведения см. в статье Azure Security Benchmark: безопасность сети.

NS-1: реализация безопасности для внутреннего трафика

Рекомендации. При развертывании ресурсов Службы Azure Bot необходимо создать или использовать существующую виртуальную сеть. Убедитесь, что все виртуальные сети Azure следуют принципу сегментации предприятия, который соответствует бизнес-рискам. Любая система, с которой связан повышенный риск для организации, должна быть изолирована в собственной виртуальной сети и достаточно хорошо защищена с помощью группы безопасности сети (NSG) или при помощи Брандмауэра Azure.

Создание группы безопасности сети с правилами безопасности: /azure/virtual-network/tutorial-filter-network-traffic​​

Развертывание и настройка Брандмауэра Azure: /azure/firewall/tutorial-firewall-deploy-portal

Ответственность: Customer

NS-2: совместное подключение частных сетей

Руководство. Воспользуйтесь Azure ExpressRoute или виртуальной частной сетью Azure (VPN) для создания частных подключений между центрами обработки данных Azure и локальной инфраструктурой среды для совместного размещения. Подключения ExpressRoute не проходят через общедоступный Интернет и обеспечивают повышенную надежность и быстродействие, а также более низкую задержку по сравнению с обычными интернет-подключениями. В случае VPN "точка — сеть" и VPN типа "сеть — сеть" локальные устройства или сети можно подключить к виртуальной сети с помощью любого сочетания параметров VPN и Azure ExpressRoute.

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

Ответственность: Customer

NS-4: защита приложений и служб от внешних сетевых атак

Рекомендации. Защитите ресурсы Службы Azure Bot от атак из внешних сетей, включая распределенные Атаки (DDoS), т.е. "отказ в обслуживании", атаки на определенные приложения, а также нежелательный и потенциально вредоносный интернет-трафик. Воспользуйтесь Брандмауэром Azure для защиты приложений и служб от потенциально вредоносного трафика, поступающего из Интернета и других внешних расположений. Защитите свои ресурсы от распределенных атак DDoS, включив в виртуальных сетях Azure стандартную защиту от атак DDoS. Используйте Microsoft Defender для облака, чтобы определять риски, связанные с неверной конфигурацией сетевых ресурсов.

Используйте возможности Брандмауэра веб-приложения (WAF) в Шлюзе приложений Azure, в Azure Front Door и сети доставки содержимого Azure (CDN) для защиты приложений, работающих в Службе Azure Bot, от атак на уровне приложения.

Ответственность: Customer

NS-6: упрощение правил безопасности сети

Рекомендации. Используйте теги службы виртуальной сети для определения элементов управления доступом к сети для групп безопасности сети или Брандмауэра Azure, настроенных для ресурсов Службы Azure Bot. Теги служб можно использовать вместо определенных IP-адресов при создании правил безопасности. Указав имя тега службы (например, AzureBotService) в соответствующем поле источника или назначения правила, можно разрешить или запретить трафик для соответствующей службы. Корпорация Майкрософт управляет префиксами адресов, входящих в тег службы, и автоматически обновляет этот тег при изменении адресов.

Ответственность: Customer

Управление удостоверениями

Дополнительные сведения см. в статье Azure Security Benchmark: управление удостоверениями.

IM-1. Стандартизация Azure Active Directory как центральной системы идентификации и проверки подлинности

Инструкции. В Службе Azure Bot в качестве службы управления удостоверениями и доступом по умолчанию используется Azure Active Directory (Azure AD). Стандартизируйте Azure AD для управления удостоверениями и доступом в организации в следующих областях: облачные ресурсы Microsoft, таких как портал Azure, служба хранилища Azure, виртуальные машины Azure (Linux и Windows), Azure Key Vault, PaaS и приложения SaaS.

  • Ресурсы организации, такие как приложения в Azure или ресурсы корпоративной сети.

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

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

Ответственность: Customer

IM-3. Использование единого входа (SSO) Azure AD для доступа к приложениям

Инструкции. Используйте Azure Active Directory (Microsoft Azure AD) для предоставления управления удостоверениями и доступом к ресурсам Azure, облачным и локальным приложениям. Управление идентификацией и доступом применяется к корпоративным удостоверениям, таким как сотрудники, а также к внешним удостоверениям, таким как участники, партнеры и поставщики.

Обеспечивается единый вход (SSO) через Azure Active Directory для управления данными и ресурсами организации, а также предоставляет безопасный доступ к ним в локальной среде и в облаке. Подключайте пользователей, приложения и устройства к Azure Active Directory, чтобы обеспечить простой, безопасный доступ и более широкие возможности видимости и управления.

Ответственность: Customer

IM-7: исключение непреднамеренного раскрытия учетных данных

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

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

Ответственность: Customer

Привилегированный доступ

Дополнительные сведения см. в статье Azure Security Benchmark: привилегированный доступ.

PA-3. Регулярная проверка и согласование доступа пользователей

Инструкции. В Службе Azure Bot используются учетные записи Azure AD для управления ресурсами, а также регулярной проверки учетных записей и назначения доступа, чтобы обеспечить действительность учетных записей и допустимость уровня их доступа. Используя проверку доступа средствами Azure AD, можно проверять членство в группах, доступ к корпоративным приложениям и назначение ролей. Облегчить поиск устаревших учетных записей могут журналы, предоставляемые функциями создания отчетов в Azure AD. Вы также можете использовать функции Azure AD Privileged Identity Management для создания рабочего процесса получения отчета о проверке доступа, который упростит процесс проверки.

Кроме того, Azure AD Privileged Identity Management можно настроить для выдачи оповещения в случае, когда создается чрезмерно много учетных записей администраторов, и выявления устаревших или неправильно настроенных учетных записей администраторов. Примечание. Некоторые службы Azure поддерживают локальных пользователей и роли, которые не управляются с помощью Microsoft Azure Active Directory. Требуется управлять этими пользователями по отдельности.

Ответственность: Customer

PA-6: использование рабочих станций с привилегированным доступом

Инструкции: защищенные изолированные рабочие станции критически важны для защиты привилегированных ролей, таких как администраторы, разработчики и критические операторы обслуживания. Для выполнения административных задач используйте надежно защищенные рабочие станции и (или) Бастион Azure. Используйте Azure Active Directory (Azure AD), Advanced Threat Protection (ATP) в Microsoft Defender и Microsoft Intune, чтобы развернуть безопасную и (или) управляемую рабочую станцию пользователя для выполнения административных задач. Защищенными рабочими станциями можно централизованно управлять, чтобы обеспечить безопасную настройку, включая строгую проверку подлинности, базовые параметры программного обеспечения и оборудования, ограниченный логический и сетевой доступ.

Ответственность: Customer

PA-7. Использование Just Enough Administration (принцип предоставления наименьших прав)

Инструкции. Управление ресурсами Службы Azure Bot обеспечивается путем интеграции с управлением доступом на основе ролей Azure. Azure RBAC позволяет управлять доступом к ресурсам Azure посредством назначения ролей. Вы можете назначать роли пользователям, группам субъектов-служб и управляемым удостоверениям. Для некоторых ресурсов существуют предварительно определенные встроенные роли. Эти роли могут быть инвентаризированы или запрошены с помощью таких средств, как Azure CLI, Azure PowerShell или портал Azure. Привилегии, назначаемые ресурсам через Azure RBAC, должны всегда ограничиваться возможностями, которые необходимы ролям. Данный метод дополняет JIT-подход Azure Active Directory (Azure AD) Privileged Identity Management (PIM). Его необходимо периодически проверять.

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

Сведения об управлении доступом на основе ролей в Azure (Azure RBAC) /azure/role-based-access-control/overview

Ответственность: Customer

Защита данных

Дополнительные сведения см. в статье Azure Security Benchmark: защита данных.

DP-2. Защита конфиденциальных данных

Руководство. Защитите конфиденциальные данные путем ограничения доступа посредством управления доступом на основе ролей Azure (Azure RBAC), сетевых элементов управления доступом и специальных элементов управления в службах Azure (например, шифрование в SQL и других базах данных).

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

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

Ответственность: Совмещаемая блокировка

DP-3. Мониторинг несанкционированной передачи конфиденциальных данных

Руководство. Мониторинг несанкционированной передачи данных в расположения за пределами корпоративной видимости и управления. Обычно этот процесс предусматривает мониторинг за аномальными действиями (большими или необычными передачами данных), которые могут указывать на несанкционированную кражу данных. Расширенная защита от угроз в службе хранилища Azure (ATP) и Azure SQL ATP могут оповещать об аномальной передаче информации, которая может указывать на несанкционированную передачу конфиденциальной информации. Azure Information Protection (AIP) предоставляет возможности мониторинга для сведений, которые были классифицированы и помечены. При необходимости для обеспечения соответствия требованиям защиты от потери данных (DLP) можно использовать решение защиты от потери данных на основе узла для принудительного применения детективных и (или) профилактических элементов управления для предотвращения кражи данных.

Ответственность: Customer

DP-4: шифрование конфиденциальной информации во время передачи

Рекомендация. Все конечные точки Службы Azure Bot открываются для доступа по протоколу HTTP с принудительным подключением по TLS 1.2. В случае принудительного подключения по протоколу безопасности объекты-получатели, пытающиеся вызвать конечную точку Службы Azure Bot, должны соблюдать следующие рекомендации:

  • Клиентская операционная система должна поддерживать TLS 1.2. — при этом, язык (и платформа), используемые для вызова HTTP, должны содержать TLS 1.2 в виде части запроса. В зависимости от языка и платформы, указание протокола TLS выполняется либо явно, либо неявно. Для дополнения элементов управления доступом данные при передаче должны быть защищены от «внеполосных» атак (например, в виде захвата трафика) с помощью шифрования, чтобы злоумышленники не могли легко считывать или изменять данные. Хотя это не является обязательным для трафика в частных сетях, это чрезвычайно важно для трафика во внешних и общедоступных сетях. Для HTTP-трафика необходимо убедиться, что все клиенты, подключающиеся к вашим ресурсам Azure, могут согласовывать TLS версии 1.2 или выше. Для удаленного управления используйте SSH (для Linux) или RDP/TLS (для Windows) вместо незашифрованного протокола. Устаревшие версии и протоколы SSL, TLS и SSH, а также слабые шифры должны быть отключены.

Azure по умолчанию обеспечивает шифрование данных, передаваемых между центрами обработки данных Azure.

Ответственность: Совмещаемая блокировка

DP-5. Шифрование конфиденциальных неактивных данных

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

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

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

Ответственность: Customer

управление ресурсами.

Дополнительные сведения см. в статье Azure Security Benchmark: управление ресурсами.

AM-1. Предоставление группе безопасности возможности просматривать угрозы безопасности для ресурсов

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

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

Разрешения читателя сведений о безопасности можно расширить для всего клиента (корневой группы управления) или ограничить до определенной группы управления или конкретных подписок.

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

Ответственность: Customer

AM-2: убедитесь, что группа безопасности имеет доступ к инвентаризации и метаданным активов.

Инструкции. Применяйте теги к ресурсам, группам ресурсов и подпискам Azure для их логической классификации по определенной таксономии. Каждый тег состоит из пары "имя — значение". Например, имя Environment и значение Production можно применить ко всем ресурсам в рабочей среде.

Служба Azure Bot не поддерживает развернутые службы ресурсов на основе Azure Resource Manager и обнаружение с помощью Azure Resource Graph.

Ответственность: Customer

AM-3: использование только утвержденных служб Azure

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

Ответственность: Customer

Ведение журналов и обнаружение угроз

Дополнительные сведения см. в статье Azure Security Benchmark: ведение журнала и обнаружение угроз.

LT-1. Включение обнаружения угроз для ресурсов Azure

Рекомендации. Служба Azure Bot не предоставляет собственных возможностей для мониторинга угроз безопасности, связанных с ее ресурсами.

Перешлите журналы из Службы Azure Bot в SIEM, чтобы затем их можно было использовать для настройки обнаружения угроз. Обязательно следите за потенциальными угрозами и аномалиями, относящимися к различным типам ресурсов Azure. Чтобы сократить число ложноположительных результатов, получаемых аналитиками, сосредоточьтесь на получении высококачественных оповещений. Источником предупреждений могут быть данные журналов, агенты или другие данные.

Ответственность: Customer

LT-2. Включение функции обнаружения угроз для управления удостоверениями и доступом в Azure

Рекомендации. Azure Active Directory (Azure AD) предоставляет следующие журналы пользователей, которые можно просмотреть в отчетах Azure AD или интегрировать с Azure Monitor, Microsoft Sentinel или другими средствами мониторинга или SIEM для использования в более сложных сценариях мониторинга и аналитики:

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

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

Ответственность: Customer

LT-3: включение ведения журнала для сетевых операций Azure

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

В Службе Azure Bot также не создаются и не обрабатываются журналы запросов DNS, которые необходимо включить.

Ответственность: Customer

LT-4: включение ведения журнала для ресурсов Azure

Инструкции. Журналы действий, которые автоматически доступны, содержат все операции записи (PUT, POST, DELETE) для ресурсов Службы Azure Bot, за исключением операций чтения (GET). Журналы действий можно использовать для поиска ошибки при устранении неполадок, а также для наблюдения за тем, как пользователь организации изменяет ресурс.

Сейчас Служба Azure Bot не создает журналы ресурсов Azure.

Ответственность: Customer

LT-5: централизованные управление журналом безопасности и анализ

Инструкции. Централизуйте хранение и анализ журналов, чтобы можно было соотносить данные между собой. Для каждого источника журнала убедитесь, что назначен владелец данных, разработано руководство по доступу, есть место хранения, определено, какие средства используются для обработки данных и доступа к ним, и установлены требования к хранению данных. Интегрируйте журналы действий Azure со своей централизованной системой ведения журналов. Принимайте журналы, используя Azure Monitor для объединения данных безопасности, создаваемых устройствами конечных точек, сетевыми ресурсами и другими системами безопасности. В Azure Monitor используйте рабочие области Log Analytics для запроса и выполнения анализа и используйте учетные записи службы хранилища Azure для долгосрочного и архивного хранения.

Кроме того, настройте Microsoft Sentinel или стороннюю систему SIEM и подключите к ней данные.

Многие организации предпочитают задействовать Microsoft Sentinel для "горячих", часто используемых данных, а службу хранилища Azure — для "холодных" данных, которые используются реже.

Ответственность: Customer

LT-6: Настройка хранения журналов

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

В Azure Monitor можно задать период хранения для рабочей области Log Analytics согласно нормативным требованиям организации. Используйте службу хранилища Azure, озеро данных или учетные записи рабочей области Log Analytics для долгосрочного и архивного хранения.

Ответственность: Customer

LT-7. Использование утвержденных источников синхронизации времени

Рекомендации. Корпорация Майкрософт поддерживает источники времени для большинства служб PaaS и SaaS в Azure. На виртуальных машинах можно использовать сервер NTP по умолчанию для синхронизации времени, если не указаны конкретные требования. Если необходимо установить собственный NTP-сервер, обеспечьте безопасность порта службы UDP 123. Все журналы, созданные ресурсами в Azure, содержат отметки времени с часового пояса, указанным по умолчанию.

Ответственность: Microsoft

Управление состоянием защиты и уязвимостью

Дополнительные сведения см. в статье Тесты производительности системы безопасности Azure. Управление состоянием безопасности и уязвимостями.

PV-8: регулярное моделирование атак

Инструкции: при необходимости выполните тестирование на проникновение в ресурсы Azure или привлеките для участия "красные команды" и обеспечьте исправление всех обнаруженных проблем с безопасностью. Следуйте правилам тестирования Microsoft Cloud на проникновение, чтобы убедиться, что тесты на проникновение не нарушают политики Майкрософт. Используйте стратегию Майкрософт и рекомендации "красных команд", а затем выполните тест на проникновение в режиме реального времени для управляемых корпорацией Майкрософт облачной инфраструктуры, служб и приложений.

Ответственность: Совмещаемая блокировка

Архивация и восстановление

Дополнительные сведения см. в статье Azure Security Benchmark: резервное копирование и восстановление.

BR-1: обеспечение регулярного автоматического резервного копирования

Руководство. Убедитесь в резервном копировании систем и данных для обеспечения непрерывности бизнес-процессов после непредвиденного события. Необходимо задать их с помощью любых целевых точек для целевых точек восстановления (RPO) и целевого времени восстановления (RTO). Включите Azure Backup и настройте источник резервного копирования (например, виртуальные машины Azure, SQL Server, базу данных HANA или общие папки). Укажите также требуемую частоту и период хранения.

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

Ответственность: Customer

BR-2: шифрование данных резервного копирования

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

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

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

Ответственность: Customer

BR-3: проверка всех резервных копий, включая ключи, управляемый клиентом

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

Ответственность: Customer

BR-4: снижение риска потери ключей

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

Ответственность: Customer

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