рекомендации по управлению удостоверениями и управлению доступом Azure

В этой статье рассматривается коллекция рекомендаций по управлению удостоверениями и управлению доступом Azure. Эти рекомендации основаны на опыте Microsoft с Microsoft Entra ID и опытом клиентов.

Эта статья соответствует модели безопасности microsoft "Никому не доверяй", которая рассматривает удостоверение как основной периметр безопасности и требует явной проверки для каждого запроса доступа. Сведения о предписывающих мерах безопасности, для которых используется принудительное применение Политика Azure, см. в Microsoft Cloud Security Benchmark v2 — Управление удостоверениями.

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

В этой статье представлен общий план повышения безопасности после внедрения, руководствуясь чек-листом «5 шагов к защите вашей инфраструктуры идентификации», который проведёт вас через основные функции и сервисы.

Мнения и технологии меняются со временем. Эта статья регулярно обновляется, чтобы отразить эти изменения.

Рассмотренные в этой статье лучшие практики безопасности управления удостоверениями и доступом в Azure включают:

  • Рассматривайте удостоверение как основной периметр безопасности.
  • Централизуйте управление идентификационными данными.
  • Управление подключенными клиентами.
  • Включите единый вход в систему.
  • Включите условный доступ.
  • Планирование стандартных улучшений безопасности.
  • Включите управление паролями.
  • Принудительное применение многофакторной проверки для пользователей.
  • Используйте управление доступом на основе ролей.
  • Более низкая уязвимость привилегированных учетных записей.
  • Управление расположениями, где находятся ресурсы.
  • Используйте Microsoft Entra ID для проверки подлинности хранилища.

Рассматривать удостоверение как основной периметр безопасности

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

Microsoft Entra ID — это решение Azure для управления удостоверениями и доступом. Microsoft Entra ID — это облачная мультитенантная служба управления каталогами и удостоверениями от Microsoft. Это решение объединяет в себе базовые службы каталогов, управление доступом к приложению и защиту идентификации.

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

  • Сосредоточьте средства контроля безопасности и механизмы обнаружения вокруг удостоверений пользователей и служб: используйте Microsoft Entra ID, чтобы объединить средства контроля и удостоверения в одном месте.

Централизация управления идентификацией

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

  • Создайте один экземпляр Microsoft Entra. Согласованность и один авторитетный источник повышают ясность и снижают риски безопасности от человеческих ошибок и сложности конфигурации: укажите один Microsoft Entra каталог в качестве авторитетного источника для корпоративных и организационных учетных записей.

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

Замечание

Некоторые факторы влияют на производительность Microsoft Entra Connect. Убедитесь, что Microsoft Entra Connect имеет достаточную емкость, чтобы предотвратить ухудшение работоспособности систем, которое может повлиять на безопасность и производительность. Крупные или сложные организации, например организации, подготавливающие более 100 000 объектов, должны следовать рекомендациям по оптимизации реализации Microsoft Entra Connect.

  • Не синхронизируйте учетные записи с Microsoft Entra ID с высокими привилегиями в существующем экземпляре Active Directory: конфигурация по умолчанию Microsoft Entra Connect исключает только встроенную учетную запись администратора (RID 500). Чтобы защитить другие высоко привилегированные учетные записи, такие как администраторы домена и администраторы предприятия, используйте фильтрацию на основе подразделений или фильтрацию на основе атрибутов , чтобы исключить их из синхронизации. Эта конфигурация снижает риск того, что злоумышленники переходит от облака к локальным ресурсам, что может создать крупный инцидент.

  • Включение синхронизации хэша паролей: синхронизация хэша паролей — это функция, используемая для синхронизации хэшей паролей пользователей из экземпляра локальная служба Active Directory в облачный экземпляр Microsoft Entra. Эта синхронизация помогает защитить от утечки учетных данных, воспроизводимых из предыдущих атак.

    Даже если вы решите использовать федерацию с службы федерации Active Directory (AD FS) (AD FS) или другими поставщиками удостоверений, вы можете опционально настроить синхронизацию хэша паролей в качестве резервной копии в случае сбоя или временной недоступности ваших локальных серверов. Эта синхронизация позволяет пользователям входить в службу с помощью того же пароля, который они используют для входа в локальный экземпляр Active Directory. Кроме того, защита идентификации позволяет обнаруживать скомпрометированные учетные данные, сравнивая синхронизированные хэши паролей с паролями, известными как скомпрометированные, если пользователь использовал тот же адрес электронной почты и пароль в других службах, которые не подключены к Microsoft Entra ID.

    Для получения дополнительной информации см. Реализация синхронизации хэширования паролей с Microsoft Entra Connect Sync.

  • Для разработки новых приложений используйте Microsoft Entra ID для проверки подлинности: используйте следующие возможности для поддержки проверки подлинности.

    • Microsoft Entra ID для сотрудников.
    • Microsoft Entra B2B для гостевых пользователей и внешних партнеров.
    • Внешняя идентификация Microsoft Entra управлять тем, как клиенты регистрируются, входят в систему и управляют своими профилями при использовании приложений.

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

Замечание

Выберите каталоги, где находятся критически важные учетные записи, а также определите, будут ли рабочей станцией администратора управлять новые облачные службы или существующие процессы. Существующие процессы управления и подготовки учетных записей могут снизить некоторые риски. Они также могут создавать риск того, что злоумышленник скомпрометирует локальную учетную запись и использует ее для дальнейшего проникновения в облако. Может потребоваться использовать другую стратегию для различных ролей, таких как ИТ-администраторы и администраторы подразделений. В этом случае у вас есть два варианта. Первым вариантом является создание учетных записей Microsoft Entra, которые не синхронизированы с экземпляром локальная служба Active Directory. Присоедините рабочую станцию администратора к Microsoft Entra ID, которой можно управлять и устанавливать обновления с помощью Microsoft Intune. Второй вариант — использовать существующие учетные записи администраторов, синхронизировав их с вашим локальным экземпляром Active Directory. Используйте существующие рабочие станции в домене Active Directory для управления и безопасности.

Управление подключенными клиентами

Ваша организация безопасности нуждается в видимости для оценки риска и определения того, соответствует ли ваша организация своим политикам и нормативным требованиям. Убедитесь, что ваша организация безопасности имеет представление обо всех подписках, подключенных к рабочей среде и сети (через Azure ExpressRoute или VPN типа "сеть — сеть"). Глобальный администратор в Microsoft Entra ID может повысить доступ к роли администратора доступа пользователей и иметь возможность просматривать все подписки и управляемые группы, подключенные к вашей среде.

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

Включение единого входа

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

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

  • Включите единый вход: Microsoft Entra ID распространяет локальную службу Active Directory на облако. Пользователи могут использовать свою основную рабочую или учебную учетную запись для устройств, подключенных к домену, ресурсов компании и всех веб-приложений и приложений SaaS, которые им необходимы для выполнения рабочих задач. Пользователям не нужно запоминать несколько наборов имен пользователей и паролей. Их доступ к приложению может быть автоматически предоставлен или отозван в зависимости от членства в группах организации и статуса сотрудника. Вы можете управлять доступом для приложений коллекции или для собственных локальных приложений, которые вы разработали и опубликовали с помощью прокси приложения Microsoft Entra.

Используйте единый вход, чтобы пользователи могли получать доступ к приложениям SaaS на основе своей рабочей или учебной учетной записи в Microsoft Entra ID. Эта возможность применяется не только к приложениям Microsoft SaaS, но и к другим приложениям, таким как Google Apps и Salesforce. Приложение можно настроить для использования Microsoft Entra ID в качестве поставщика удостоверений на основе SAML. В качестве меры безопасности Microsoft Entra ID не выдаёт токен, позволяющий пользователям войти в приложение, если только Microsoft Entra ID не предоставляет им доступ. Вы можете предоставить доступ напрямую или через группу, включающую пользователей.

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

Включение условного доступа

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

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

  • Управляйте и контролируйте доступ к корпоративным ресурсам: настройте распространенные политики условного доступа Microsoft Entra на основе групп, местоположения и уровня конфиденциальности приложений для приложений SaaS и приложений, подключенных к Microsoft Entra ID.

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

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

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

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

  • Планируйте регулярные проверки безопасности и улучшения на основе передовых практик в вашей отрасли: используйте функцию Identity Secure Score, чтобы оценивать свои улучшения с течением времени.

Включение управления паролями

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

  • Настройте самостоятельный сброс пароля (SSPR) для пользователей: используйте функцию самостоятельного сброса пароля Microsoft Entra ID.

  • Следите за тем, как используется SSPR: отслеживайте пользователей, которые регистрируются с помощью отчета об активности регистрации сброса пароля Microsoft Entra ID. Функция создания отчетов, которая Microsoft Entra ID предоставляет, помогает ответить на вопросы с помощью предварительно созданных отчетов. При наличии соответствующей лицензии можно также создавать пользовательские запросы.

  • Расширьте облачные политики паролей в локальной инфраструктуре: расширьте политики паролей в организации, выполняя те же проверки на наличие локальных изменений паролей, что и для изменения паролей на основе облака. Установите Microsoft Entra защиту паролей для локальных агентов Windows Server Active Directory, чтобы расширить списки запрещенных паролей в существующей инфраструктуре. Пользователи и администраторы, которые изменяют, задают или сбрасывают пароли в локальной среде, должны соответствовать той же политике паролей, что и пользователи только в облаке.

Принудительное применение многофакторной проверки для пользователей

Требовать многофакторную проверку подлинности (MFA) для всех пользователей. Это включает администраторов и других пользователей в организации, которые могут оказать значительное влияние, если их учетная запись скомпрометирована, например финансовые сотрудники.

Это важно

Обязательное применение MFA: начиная с 1 октября 2025 г. Azure применяет этап 2 обязательного применения MFA. На этом этапе требуется надежная проверка подлинности для всех пользователей службы Azure, включая интерфейс командной строки (CLI), PowerShell, Azure мобильное приложение, средства инфраструктуры как код (IaC) и конечные точки REST API для операций создания, обновления или удаления. Это внедрение значительно повышает безопасность идентификационных удостоверений, нейтрализуя украденные учетные данные в крупном масштабе. Microsoft исследования показывают, что MFA может блокировать более 99,2% атак компрометации учетных записей. Дополнительные сведения см. в разделе Планирование обязательной многофакторной аутентификации для Azure.

Приоритет методов MFA, устойчивых к фишингу

Методы проверки подлинности, устойчивые к фишингу, такие как ключи безопасности FIDO2, секретные ключи, Windows Hello for Business и проверка подлинности на основе сертификатов, обеспечивают самую надежную защиту от сложных атак. Эти методы используют аппаратно поддерживаемые криптографические ключи, которые злоумышленники не могут перехватить или воспроизвести повторно. Microsoft рекомендует внедрять устойчивую к фишингу MFA в качестве базового стандарта защиты личности. Инструкции см. в разделе "Планирование фишинго-устойчивого развертывания проверки подлинности без пароля".

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

Следующие параметры и преимущества помогут включить многофакторную проверку подлинности.

Вариант 1. Включить MFA с помощью параметров безопасности по умолчанию Microsoft Entra

Включите многофакторную проверку подлинности (MFA) для всех пользователей и способов входа, используя параметры безопасности по умолчанию Microsoft Entra.

Эта опция помогает быстро применять MFA для всех пользователей вашей среды, используя строгую политику:

  • Проверяйте учетные записи администраторов и способы входа с правами администратора.
  • Требовать вызов MFA через Microsoft Authenticator для всех пользователей.
  • ограничение использования устаревших протоколов проверки подлинности.

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

Вариант 2. Включение многофакторной проверки подлинности путем изменения состояния пользователя

Включение многофакторной проверки подлинности путем изменения состояния пользователя — это традиционный метод для двухфакторной проверки подлинности. Этот метод работает как с многофакторной аутентификацией Microsoft Entra в облаке, так и с сервером Azure Multifactor Authentication. Этот метод требует от пользователей выполнять двухфакторную проверку при каждом входе и переопределении политик условного доступа.

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

Вариант 3. Включение многофакторной проверки подлинности с помощью политики условного доступа

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

Эта опция — самый гибкий способ обеспечить двухэтапную верификацию для ваших пользователей. Политика условного доступа работает только для многофакторной проверки подлинности Microsoft Entra в облаке и является премиум-функцией Microsoft Entra ID. Дополнительные сведения об этом методе см. в статье "Развертывание облачной Microsoft Entra многофакторной идентификации".

Вариант 4. Включение многофакторной проверки подлинности с помощью политик условного доступа на основе рисков

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

Этот параметр позволяет выполнять следующие действия.

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

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

Замечание

Вариант 2, включение многофакторной проверки подлинности путем изменения пользовательского состояния, переопределяет политики условного доступа. Так как параметры 3 и 4 используют политики условного доступа, с ними нельзя использовать вариант 2.

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

Некоторые организации используют учетные записи пользователей в Microsoft Entra ID как сервисные аккаунты для автоматизации. При обязательном применении MFA важно перенести эти учетные записи служб на основе пользователей на безопасные облачные учетные записи служб с удостоверениями рабочей нагрузки. Идентификаторы рабочей нагрузки, включая управляемые удостоверения и субъекты-службы, предназначены для использования в сценариях автоматизации и не требуют многофакторной аутентификации. Эти цифровые идентификаторы обеспечивают более безопасное и удобное в управлении решение. Руководство по миграции см. в статьях "Вход в Azure с помощью управляемого удостоверения с помощью Azure CLI" и "Вход в Azure PowerShell в неинтерактивном режиме для сценариев автоматизации".

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

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

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

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

Ваша команда безопасности должна просматривать Azure ресурсы для оценки и устранения рисков. Если у службы безопасности есть операционные обязанности, им нужно больше разрешений для выполнения своей работы.

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

  • Разделяйте обязанности внутри своей команды и предоставляйте пользователям только тот доступ, который необходим им для выполнения своих рабочих задач. Вместо предоставления всем неограниченным разрешениям в подписке или ресурсах Azure разрешать только определенные действия в определенной области.: используйте встроенные роли Azure в Azure для назначения прав пользователям.

Замечание

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

  • Предоставьте группам безопасности, отвечающим за Azure, доступ для просмотра ресурсов Azure, чтобы они могли оценивать и устранять риски: назначьте группам безопасности роль Azure RBAC Security Reader. Вы можете использовать корневую группу управления или группу управления сегментами в зависимости от области обязанностей.

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

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

  • Предоставьте Microsoft Defender для облака доступ к ролям безопасности, которым он нужен. Defender для облака помогает командам по безопасности быстро выявлять и устранять риски: добавьте команды безопасности с этими потребностями в роль Azure RBAC security admin, чтобы они могли просматривать политики безопасности, просматривать состояния безопасности, изменять политики безопасности, просматривать оповещения и рекомендации, а также отклонять оповещения и рекомендации. Используйте группу управления корнем или группу управления сегментами, в зависимости от объема обязанностей.

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

Более низкая уязвимость привилегированных учетных записей

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

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

Разработайте и придерживайтесь дорожной карты для защиты привилегированного доступа от киберзлоумышленников. Сведения о создании подробной стратегии защиты удостоверений и доступа, управляемых или передаваемых в Microsoft Entra ID, Microsoft Azure, Microsoft 365 и других облачных службах, см. в статье "Защита привилегированного доступа для гибридных и облачных развертываний в Microsoft Entra ID".

Следующий текст содержит обобщение лучших практик, указанных в Обеспечение привилегированного доступа для гибридных и облачных развертываний в Microsoft Entra ID:

  • Управление, управление и мониторинг доступа к привилегированным учетным записям: включение Microsoft Entra управление привилегированными пользователями. После включения управление привилегированными пользователями вы получаете уведомления о смене роли с привилегированным доступом. Эти уведомления дают раннее предупреждение о добавлении новых пользователей в высокопривилегированные роли в вашем каталоге.

  • Убедитесь, что все критически важные учетные записи администраторов представляют собой управляемые учетные записи Microsoft Entra: удалите все личные учетные записи, такие как учетные записи Microsoft с адресами hotmail.com, live.com и outlook.com, из критически важных административных ролей.

  • Убедитесь, что у всех критически важных администраторских ролей есть отдельный аккаунт для административных задач, чтобы избежать фишинга и других атак, нарушающих административные права: Создайте отдельную учётную запись администратора, которому будут назначены необходимые права для выполнения административных задач. Блокировать использование этих административных учетных записей для ежедневных инструментов повышения производительности, таких как электронная почта Microsoft 365 или случайный серфинг в интернете.

  • Определение и классификация учетных записей, находящихся в ролях с высоким уровнем привилегий: после включения Microsoft Entra управление привилегированными пользователями просмотрите пользователей, которые находятся в глобальном администраторе, администраторе привилегированных ролей и других ролях с высоким уровнем привилегий. Удалите все учетные записи, которые больше не нужны в этих ролях. Классифицируйте оставшиеся учетные записи, назначенные ролям администратора.

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

  • Внедрить доступ «точно в срок» (JIT), чтобы ещё больше сократить время действия привилегий и повысить прозрачность использования привилегированных учетных записей: Microsoft Entra управление привилегированными пользователями помогает выполнять следующие действия.

    • Ограничьте пользователей доступом только к своим привилегиям JIT.
    • назначать роли на короткий период с уверенностью в том, что привилегии будут автоматически отозваны.

  • Определите по крайней мере две учетные записи аварийного доступа: учетные записи аварийного доступа помогают организациям ограничить привилегированный доступ в существующей среде Microsoft Entra. Такие учетные записи имеют высокий уровень привилегий и не назначаются конкретным лицам. Учетные записи аварийного доступа ограничены сценариями, в которых обычные административные учетные записи нельзя использовать. Организации должны ограничивать использование экстренной учетной записи только на необходимый срок.

Оцените учетные записи, назначенные или подходящие для роли глобального администратора. Если вы не видите учетные записи только в облаке, используя домен *.onmicrosoft.com, предназначенный для экстренного доступа, создайте их. Для получения дополнительной информации см. раздел Управление учетными записями административного доступа в экстренных ситуациях в Microsoft Entra ID.

Требовать при входе многофакторную проверку подлинности Microsoft Entra для всех пользователей, которые постоянно назначены в одну или несколько ролей администратора Microsoft Entra: глобальный администратор, администратор привилегированных ролей, администратор Exchange Online и администратор SharePoint Online. Включите многофакторную аутентификацию для ваших администраторских аккаунтов и убедитесь, что пользователи администраторских аккаунтов регистрируются.

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

Управление расположениями, в которых создаются ресурсы

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

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

Замечание

Политики безопасности не совпадают с Azure RBAC. Политики безопасности используют Azure RBAC для авторизации пользователей для создания этих ресурсов.

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

Активный мониторинг подозрительных действий

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

  • Иметь метод для выявления подозрительных действий при входе: отслеживайте попытки входа без отслеживания, атак методом подбора паролей против конкретной учетной записи, попытки входа из нескольких местоположений, входы с зараженных устройств и с подозрительных IP-адресов. Используйте отчеты об аномалиях в Microsoft Entra ID P1 или P2. Имеют процессы и процедуры, чтобы ИТ-администраторы выполняли эти отчеты ежедневно или по запросу (обычно в сценарии реагирования на инциденты).

  • У вас есть активная система мониторинга, которая уведомляет вас о рисках и может настроить уровень риска (высокий, средний или низкий) в соответствии с вашими бизнес-требованиями: используйте Защита Microsoft Entra ID, которая помечает текущие риски на собственной панели мониторинга и отправляет ежедневные уведомления сводки по электронной почте. Чтобы защитить идентичность вашей организации, вы можете настроить политики, основанные на рисках, которые автоматически реагируют на выявленные риски при достижении определённого уровня риска.

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

Использование Microsoft Entra ID для проверки подлинности хранилища

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

Используйте Microsoft Entra ID с управляемыми удостоверениями для авторизации запросов на служба хранилища Azure по возможности.

Дальнейшие шаги

  • Last updated on