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