В этой статье описывается архитектура условного доступа, которая соответствует принципам нулевого доверия. Архитектура использует подход на основе человека для формирования структурированной платформы условного доступа.
Архитектура нулевого доверия условного доступа
Сначала необходимо выбрать архитектуру. Рекомендуется рассмотреть архитектуру условного доступа для целевого или нулевого доверия. На этой схеме показаны соответствующие параметры:
Архитектура условного доступа нулевого доверия — это тот, который лучше всего подходит принципам нулевого доверия. Если выбрать параметр Все облачные приложения в политике условного доступа, все конечные точки защищены указанными элементами управления предоставления, такими как известный пользователь и известное или соответствующее устройство. Но политика не только применяется к конечным точкам и приложениям, поддерживающим условный доступ. Он применяется к любой конечной точке, с которым взаимодействует пользователь.
Примером является конечная точка потока входа устройства, которая используется в различных новых средствах PowerShell и Microsoft Graph. Поток входа устройства позволяет разрешить вход с устройства, на котором невозможно отобразить экран входа, например устройство Интернета вещей.
Команда входа на основе устройства выполняется на данном устройстве, а код отображается пользователю. Этот код используется на другом устройстве. Пользователь переходит к https://aka.ms/devicelogin и указывает имя пользователя и пароль. После входа с другого устройства вход выполняется успешно на устройстве Интернета вещей в этом контексте пользователя.
Проблема с этим входом заключается в том, что он не поддерживает условный доступ на основе устройств. Это означает, что никто не сможет использовать средства и команды, если вы применяете базовую политику, требующую известного пользователя и известного устройства для всех облачных приложений. Существуют другие приложения, которые имеют ту же проблему с условным доступом на основе устройств.
Другая архитектура, предназначенная, основана на принципе, который предназначен только для отдельных приложений, которые необходимо защитить в политиках условного доступа. В этом случае имя входа устройства для конечных точек, которые ранее охватывались всеми облачными приложениями, такими как вызовы графа к идентификатору Microsoft Entra ID, не защищены политиками условного доступа, поэтому они продолжают работать.
При использовании устройства-входа в качестве примера для отличия двух архитектур можно пройти проверку подлинности с помощью имени входа на устройство. Имя входа для устройства может быть разрешено для одного или нескольких отдельных приложений, учитывая, что каждое приложение является целевым и таким образом может быть исключено в политике условного доступа, требующей входа на основе устройства.
Проблема с целевой архитектурой заключается в том, что вы можете забыть защитить все облачные приложения. Даже поэтому вы выберете все доступные приложения в политиках условного доступа. Вы оставляете доступ к приложениям, которые не могут быть выбраны без защиты. Примерами являются доступ к порталу Office, порталу Azure EA (Enterprise Agreement) и информационному порталу безопасности, которые являются очень конфиденциальными.
Другим фактором является то, что число приложений Office 365 и Microsoft Entra увеличивается со временем, так как корпорация Майкрософт и партнеры выпускают новые функции, а ит-администраторы интегрируют различные приложения с идентификатором Microsoft Entra. Доступ ко всем таким приложениям защищен только в том случае, если у вас есть механизм, который обнаруживает любое новое приложение, поддерживающее условный доступ и которое автоматически применяет к ней политику. Создание и обслуживание такого скрипта может оказаться трудным.
Кроме того, максимальное поддерживаемого числа приложений для любой политики условного доступа составляет примерно 250. Вы можете добавить до 600 приложений до получения ошибки об превышении полезных данных, но это число не поддерживается.
Лица условного доступа
Существует множество способов структурировать политики условного доступа. Одним из подходов является структура политик на основе конфиденциальности доступа к ресурсу. На практике этот подход может быть трудно реализовать таким образом, чтобы защитить доступ к ресурсам для различных пользователей.
Например, можно определить политику условного доступа, требующую известного пользователя и известного устройства для доступа к конфиденциальному ресурсу, к которому должны обращаться гости и сотрудники. Когда гости пытаются получить доступ с управляемого устройства, запрос на доступ не будет работать. Необходимо настроить политику условного доступа в соответствии с обоими требованиями, что обычно приведет к политике, которая соответствует менее безопасному требованию.
Другой подход заключается в том, чтобы попытаться определить политики доступа на основе того, где пользователь находится в организации. Такой подход может привести ко многим политикам условного доступа и может быть неуправляемым.
Лучший подход — структурировать политики, связанные с общими потребностями доступа, и упаковать набор потребностей доступа в человеке для группы пользователей, имеющих те же потребности. Personas — это типы удостоверений, которые совместно используют общие корпоративные атрибуты, обязанности, опыт, цели и доступ.
Понимание доступа к корпоративным ресурсам и ресурсам различными лицами является неотъемлемой частью разработки комплексной стратегии нулевого доверия.
Ниже показаны некоторые предлагаемые лица условного доступа от Корпорации Майкрософт:
Корпорация Майкрософт также рекомендует определить отдельную персону для удостоверений, которые не являются частью какой-либо другой группы лиц. Это называется глобальной персоной. Глобальный предназначен для применения политик для удостоверений, которые не являются группой и политиками, которые должны применяться для всех лиц.
В следующих разделах описаны некоторые рекомендуемые лица.
глобальные
Глобальный — это заполнитель или лицо для политик, которые являются общими в природе. Он используется для определения политик, которые применяются ко всем пользователям или которые не применяются к одному конкретному человеку. Используйте его для политик, которые не охватываются другими лицами. Этот человек необходим для защиты всех соответствующих сценариев.
Например, предположим, что вы хотите использовать одну политику для блокировки устаревшей проверки подлинности для всех пользователей. Вы можете сделать ее глобальной политикой вместо использования группы устаревших политик, которые могут отличаться для различных лиц.
Другой пример: вы хотите заблокировать учетную запись или пользователя из определенных приложений, а пользователь или учетная запись не является частью какого-либо пользователя. Например, если вы создаете облачное удостоверение в клиенте Microsoft Entra, это удостоверение не является частью любого другого пользователя, так как оно не назначает никаких ролей Microsoft Entra. Вы по-прежнему можете заблокировать удостоверение от доступа к службам Office 365.
Может потребоваться заблокировать доступ от удостоверений, которые не охватываются какой-либо группой лиц. Или вы можете просто применить многофакторную проверку подлинности.
администраторов
В этом контексте администратор является любым не гостевым удостоверением, облаком или синхронизированным, с любым идентификатором Microsoft Entra или другой ролью администратора Microsoft 365 (например, в Microsoft Defender для облачных приложений, Exchange, Defender для конечной точки или диспетчера соответствия требованиям). Так как гости с этими ролями рассматриваются в другом человеке, гости исключены из этого лица.
Некоторые компании имеют отдельные учетные записи для ролей конфиденциальных администраторов, на основе которых основан этот человек. Оптимально администраторы используют эти конфиденциальные учетные записи из рабочей станции привилегированного доступа (PAW). Но часто мы видим, что учетные записи администратора используются на стандартных рабочих станциях, где пользователь просто переключается между учетными записями на одном устройстве.
Вам может потребоваться различаться на основе конфиденциальности ролей администратора облака и назначать менее конфиденциальные роли Azure внутренней персоне, а не использовать отдельные учетные записи. Вместо этого можно использовать повышение прав JIT-In-Time. В этом случае пользователь предназначен для двух наборов политик условного доступа, по одному для каждого пользователя. Если вы используете paWs, вам также может потребоваться ввести политики, использующие фильтры устройств в условном доступе, чтобы ограничить доступ, чтобы администраторы разрешались только в PAW.
разработчиков
Пользователь разработчиков содержит пользователей, имеющих уникальные потребности. Они основаны на учетных записях Active Directory, которые синхронизируются с идентификатором Microsoft Entra, но им нужен специальный доступ к службам, таким как Azure DevOps, конвейеры CI/CD, поток кода устройства и GitHub. Пользователь разработчиков может включать пользователей, которые считаются внутренними и другими считаются внешними, но человек должен находиться только в одном из лиц.
внутренних
Внутренние элементы содержат всех пользователей, у которых есть учетная запись Active Directory, синхронизированная с идентификатором Microsoft Entra, которые являются сотрудниками компании и которые работают в стандартной роли конечных пользователей. Рекомендуется добавить внутренних пользователей, которые являются разработчиками в персону разработчиков.
внешние
Этот человек содержит всех внешних консультантов, у которых есть учетная запись Active Directory, синхронизированная с идентификатором Microsoft Entra. Рекомендуется добавить внешних пользователей, которые являются разработчиками в персону разработчиков.
гостей
Гости содержат всех пользователей, у которых есть гостевая учетная запись Microsoft Entra, которая была приглашена в клиент.
GuestAdmins
Пользователь GuestAdmins содержит всех пользователей, у которых есть гостевая учетная запись Microsoft Entra, назначаемая любой из ранее упомянутых ролей администратора.
Microsoft365ServiceAccounts
Эта персона содержит облачные учетные записи службы на основе Microsoft Entra ID, используемые для доступа к службам Microsoft 365, если ни один другой решение не соответствует необходимости, например с использованием управляемого удостоверения службы.
AzureServiceAccounts
Эта персона содержит облачные учетные записи службы на основе Microsoft Entra, используемые для доступа к службам Azure (IaaS/PaaS), когда никакое другое решение не соответствует необходимости, например с использованием управляемого удостоверения службы.
CorpServiceAccounts
Эта персона содержит учетные записи службы на основе пользователей, которые имеют все следующие характеристики:
- Происходит из локальной среды Active Directory.
- Используются из локальной или из виртуальной машины на основе IaaS в другом (облачном) центре обработки данных, например Azure.
- Синхронизируются с экземпляром Microsoft Entra, который обращается к любой службе Azure или Microsoft 365.
Этот сценарий следует избежать.
WorkloadIdentities
Этот человек содержит удостоверения компьютера, такие как субъекты-службы Microsoft Entra и управляемые удостоверения. Условный доступ теперь поддерживает защиту доступа к ресурсам из этих учетных записей с некоторыми ограничениями в отношении условий и предоставления элементов управления.
Доступ к карточкам шаблонов
Мы рекомендуем использовать карточки шаблонов доступа для определения характеристик для каждого пользователя. Ниже приведен пример:
Карточка шаблона для каждого пользователя предоставляет входные данные для создания определенных политик условного доступа для каждого пользователя.
Руководство по условному доступу
Просмотрите платформу условного доступа, которая включает структурированный подход для группирования политик на основе созданных пользователей.
Участников
Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.
Автор субъекта:
- Claus Jespersen | Идентификатор основного консультанта&с
Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.
Дальнейшие действия
- Путь обучения : реализация удостоверения и управление ими и доступ
- Что такое условный доступ?
- распространенные политики условного доступа