Использование проверок доступа для управления пользователями, исключенными из политик условного доступа
В идеальном мире все пользователи соблюдают политики доступа, чтобы обеспечить безопасный доступ к ресурсам организации. Но иногда в интересах бизнеса приходится делать исключения. В этой статье рассматриваются некоторые примеры ситуаций, когда могут потребоваться исключения. Вы, как ИТ-администратор, можете управлять решением этой задачи, чтобы избежать упущений в исключениях из политик и предоставить аудиторам доказательства регулярной проверки этих исключений с помощью проверок доступа Microsoft Entra.
Примечание.
Для использования проверок доступа Microsoft Entra ID P2 или Управление идентификацией Microsoft Entra, Enterprise Mobility + Security E5 требуется допустимая лицензия Microsoft Entra ID P2 или Управление идентификацией Microsoft Entra, Enterprise Mobility + Security E5. Дополнительные сведения см . в выпусках Microsoft Entra.
Зачем нужно исключать пользователей из политики?
Предположим, что в качестве администратора вы решили использовать условный доступ Microsoft Entra, чтобы требовать многофакторную проверку подлинности (MFA) и ограничить запросы на проверку подлинности определенным сетям или устройствам. Планируя развертывание этой системы, вы понимаете, что не все пользователи могут соблюсти эти требования. Например, у вас могут быть пользователи, работающие из удаленных офисов, а не из внутренней сети. Кроме того, вам может потребоваться разместить пользователей, подключающихся с помощью неподдерживаемых устройств, ожидая замены этих устройств. Говоря коротко, для бизнеса необходимо, чтобы эти пользователи входили в систему и делали свою работу, и поэтому вам нужно исключить их из политик условного доступа.
В качестве другого примера можно использовать именованные расположения в условном доступе, чтобы указать набор стран и регионов, из которых пользователи не хотят получать доступ к своему клиенту.
К сожалению, некоторые пользователи по-прежнему могут иметь действительную причину входа из этих заблокированных стран или регионов. Например, пользователи могут находиться в рабочей командировке и им может требоваться доступ к корпоративным ресурсам. В этом случае в политике условного доступа, которая блокирует эти страны или регионы, можно использовать специальную облачную группу безопасности для пользователей, к которым эта политика не применяется. Пользователи, которым требуется доступ во время путешествия, могут добавлять себя в группу с помощью самостоятельного управления группами Microsoft Entra.
Другим примером может быть политика условного доступа, которая блокирует устаревшую проверку подлинности для большинства пользователей. Если же у вас есть пользователи, которым все-таки необходимо использовать старые методы проверки подлинности для доступа к ресурсам из Office 2010 или через клиенты IMAP, SMTP или POP, вы можете исключить этих пользователей из политики, которая блокирует старые методы проверки подлинности.
Примечание.
Корпорация Майкрософт настоятельно рекомендует блокировать в клиенте устаревшие протоколы, чтобы повысить уровень безопасности.
Почему исключения вызывают трудности?
В идентификаторе Microsoft Entra можно область политику условного доступа набору пользователей. Кроме того, можно настроить исключения, выбрав роли Microsoft Entra, отдельных пользователей или гостей. Важно помнить, что при наличии исключений невозможно обязать таких пользователей соблюдать требования политики. Если исключения настроены с помощью списка пользователей или использования устаревших локальных групп безопасности, у вас ограничена видимость исключений. В результате:
Пользователи могут не знать, что они исключены.
Пользователи могут присоединиться к группе безопасности, чтобы обойти политику.
Исключенные пользователи могли бы претендовать на исключение до этого, но больше не претендовать на него.
Часто при первой настройке исключения существует краткий список пользователей, которые обходят политику. Со временем больше пользователей добавляются в исключение, и список растет. В какой-то момент следует просмотреть этот список и проверить, все ли включенные в него пользователи действительно заслуживают исключения. Управление списком исключений с технической точки зрения может быть относительно простым, но кто принимает бизнес-решения, и как убедиться, что это все аудит? Однако при настройке исключения с помощью группы Microsoft Entra можно использовать проверки доступа в качестве компенсирующего элемента управления, для обеспечения видимости и уменьшения числа исключенных пользователей.
Создание группы исключения в политике условного доступа
Выполните следующие действия, чтобы создать новую группу Microsoft Entra и политику условного доступа, которая не применяется к этой группе.
Создание группы исключения
Войдите в Центр администрирования Microsoft Entra как минимум пользователь Администратор istrator.
Перейдите к группам>удостоверений>Все группы.
Выберите Создать группу.
В списке Тип группы выберите Безопасность. Введите имя и описание.
Для параметра Членство обязательно укажите тип Назначено.
Выберите пользователей, которые должны быть частью этой группы исключений, а затем нажмите кнопку "Создать".
Создание политики условного доступа, которая не распространяется на группу
Теперь вы можете создать политику условного доступа, которая распространяется на эту группу исключения.
Войдите в Центр администрирования Microsoft Entra в качестве администратора условного доступа.
Перейдите к условному доступу к защите>.
Выберите команду Создать политику.
Присвойте политике имя. Мы рекомендуем организациям присваивать политикам понятные имена.
В разделе "Назначения" выберите "Пользователи и группы".
На вкладке Включить выберите Все пользователи.
В разделе "Исключить" выберите "Пользователи" и "Группы " и выберите созданную группу исключений.
Примечание.
Мы рекомендуем на время тестирования внести исключить из политики хотя бы одну учетную запись администратора, чтобы случайно не заблокировать весь доступ к клиенту.
Настройте остальные параметры политики условного доступа в соответствии с требованиями организации.
Давайте рассмотрим два примера, в которых проверка доступа поможет в управлении исключениями из политик условного доступа.
Пример 1. Проверка доступа для пользователей, обращаюющихся из заблокированных стран или регионов
Предположим, у вас есть политика условного доступа, которая блокирует доступ из определенных стран или регионов. В этой политике также настроена группа исключений. Ниже приведена рекомендуемая проверка доступа, в которой рассматриваются члены группы.
Примечание.
Для создания проверки доступа нужна роль глобального администратора или пользователя-администратора. Пошаговое руководство по созданию проверки доступа см. в статье "Создание проверки доступа" для групп и приложений.
Проверка происходит каждую неделю.
Проверка никогда не заканчивается, чтобы убедиться, что вы храните эту группу исключений в актуальном состоянии.
Все члены этой группы находятся в область для проверки.
Каждый пользователь должен самостоятельно подтвердить, что им по-прежнему нужен доступ из этих заблокированных стран или регионов, поэтому они по-прежнему должны быть членом группы.
Если пользователь не отвечает на запрос проверки, он автоматически удаляется из группы и больше не имеет доступа к клиенту во время поездки в эти страны или регионы.
Включите уведомления по электронной почте, чтобы пользователи получали информацию о начале и завершении проверки доступа.
Пример 2. Проверка доступа для пользователей, использующих устаревшие методы проверки подлинности
Предположим, вы настроили политику условного доступа, которая блокирует доступ для пользователей со старыми версиями клиента и старыми методами проверки подлинности, и в этой политике имеется группа, на которую не распространяется действие политики. Ниже приведена рекомендуемая проверка доступа, в которой рассматриваются члены группы.
Эта проверка должна выполняться регулярно.
Проверка применяется к каждому члену группы.
Можно настроить ее так, чтобы рецензентами проверки являлись руководители бизнес-подразделений.
Автоматическое применение результатов и удаление пользователей, которые не утверждены для продолжения использования устаревших методов проверки подлинности.
Также будет полезно включить рекомендации, чтобы рецензентам больших групп было легче принимать решения.
Включите уведомления по электронной почте, чтобы пользователи получали информацию о начале и завершении проверки доступа.
Внимание
Если у вас много групп исключений, поэтому необходимо создать несколько проверок доступа, Microsoft Graph позволяет создавать и управлять ими программным способом. Чтобы приступить к работе, ознакомьтесь со справочником по API проверки доступа и учебником с помощью API проверки доступа в Microsoft Graph.
Результаты проверки доступа и журналы аудита
Теперь, когда у вас есть все на месте, группа, политика условного доступа и проверки доступа, пришло время отслеживать и отслеживать результаты этих проверок.
Войдите в Центр администрирования Microsoft Entra как минимум Администратор istrator для управления удостоверениями.
Перейдите к проверкам доступа к управлению удостоверениями>.
Выберите проверку Access, которую вы используете с группой, для которую вы создали политику исключения.
Выберите Результаты , чтобы узнать, кто был утвержден, чтобы остаться в списке, и кто был удален.
Выберите журналы аудита, чтобы просмотреть действия, выполненные во время этой проверки.
Вы как ИТ-администратор должны знать, что иногда невозможно избежать создания групп исключений для политик. Однако, сохраняя эти группы, регулярно просматривая их владельцем бизнеса или самими пользователями, и аудит этих изменений можно упростить с помощью проверок доступа.