В этой статье вы узнаете о принципах проектирования и зависимостях для сценария условного доступа, основанного на нулевом доверии.
Принципы проектирования
Начнем с некоторых принципов проектирования.
Условный доступ в качестве подсистемы политики нулевого доверия
Подход Майкрософт к нулевому доверию включает условный доступ в качестве основного механизма политики. Ниже приведен обзор этого подхода:
Скачайте SVG-файл этой архитектуры.
Условный доступ используется в качестве обработчика политик для архитектуры нулевого доверия, которая охватывает как определение политики, так и принудительное применение политик. На основе различных сигналов или условий условный доступ может блокировать или предоставлять ограниченный доступ к ресурсам, как показано ниже.
Ниже приведено более подробное представление элементов условного доступа и о том, что он охватывает:
На этой схеме показаны условный доступ и связанные элементы, которые могут помочь защитить доступ пользователей к ресурсам, а не интерактивный или нечеловеческий доступ. На следующей схеме описаны оба типа удостоверений.
схема 
Условный доступ в основном сосредоточен на защите доступа от интерактивных людей к ресурсам. По мере роста числа нечеловеческих удостоверений необходимо также учитывать доступ к этим удостоверениям. Корпорация Майкрософт предлагает две функции, связанные с защитой доступа к удостоверениям рабочей нагрузки и от нее.
- Защита доступа к приложениям, представленным удостоверением рабочей нагрузки, которое невозможно выбрать на портале условного доступа Microsoft Entra. Этот параметр поддерживается с помощью атрибутов безопасности. Назначение атрибута безопасности удостоверениям рабочей нагрузки и выбор этих удостоверений на портале условного доступа Microsoft Entra является частью лицензии Microsoft Entra ID P1.
- Защита доступа к ресурсам, инициированным удостоверениями рабочей нагрузки (субъектами-службами). Новая функция "Удостоверения рабочей нагрузки Microsoft Entra" предлагается в отдельной лицензии, поддерживающей этот сценарий. Она включает управление жизненным циклом удостоверений рабочей нагрузки, включая защиту доступа к ресурсам с помощью условного доступа.
Корпоративная модель доступа
Корпорация Майкрософт ранее предоставила рекомендации и принципы для доступа к локальным ресурсам на основе модели распределения по уровням:
- Уровень 0. Контроллеры домена, инфраструктура открытых ключей (PKI), серверы служб федерации Active Directory (AD FS) и решения управления, управляющие этими серверами
- Уровень 1. Серверы, в которых размещаются приложения
- Уровень 2. Клиентские устройства
Эта модель по-прежнему актуальна для локальных ресурсов. Чтобы защитить доступ к ресурсам в облаке, корпорация Майкрософт рекомендует стратегию управления доступом, которая:
- Является всеобъемлющим и последовательным.
- Строго применяет принципы безопасности во всем стеке технологий.
- Достаточно гибкий для удовлетворения потребностей вашей организации.
На основе этих принципов корпорация Майкрософт создала следующую корпоративную модель доступа:
Модель корпоративного доступа заменяет устаревшую модель уровня, которая сосредоточена на несанкционированном эскалации привилегий в локальной среде Windows Server Active Directory. В новой модели уровень 0 расширяется, чтобы стать плоскость управления, уровень 1 состоит из уровня управления и плоскости данных, а уровень 2 охватывает доступ пользователей и приложений.
Корпорация Майкрософт рекомендует переместить управление и управление в облачные службы, использующие условный доступ в качестве основной плоскости управления и обработчика политик, таким образом определяя и применяя доступ.
Вы можете расширить подсистему политики условного доступа Microsoft Entra к другим точкам применения политик, в том числе:
- Современные приложения: приложения, использующие современные протоколы проверки подлинности.
- Устаревшие приложения: через прокси приложения Microsoft Entra.
- Решения ДЛЯ VPN и удаленного доступа: такие решения, как Microsoft AlwaysOn VPN, Cisco AnyConnect, Palo Alto Networks, F5, Fortinet, Citrix и Zscaler.
- Документы, электронная почта и другие файлы: с помощью Microsoft Information Protection.
- Приложения SaaS.
- Приложения, работающие в других облаках, таких как AWS или Google Cloud (на основе федерации).
Принципы нулевого доверия
Три основных принципа нулевого доверия, которые корпорация Майкрософт определяет, как представляется, понятна, особенно отделами безопасности. Однако иногда важность удобства использования игнорируется во время разработки решений нулевого доверия.
Удобство использования всегда должно считаться неявным принципом.
Принципы условного доступа
На основе предыдущих сведений ниже приведены краткие сведения о предлагаемых принципах. Корпорация Майкрософт рекомендует создать модель доступа на основе условного доступа, которая соответствует трем основным принципам Microsoft Zero Trust:
явно
- Переместите плоскость управления в облако. Интеграция приложений с идентификатором Microsoft Entra и защита их с помощью условного доступа.
- Учитывайте, что все клиенты должны быть внешними.
Использовать наименее привилегированный доступ
- Оцените доступ на основе соответствия требованиям и риска, включая риск пользователя, риск входа и риск устройства.
- Используйте следующие приоритеты доступа:
- Доступ к ресурсу напрямую с помощью условного доступа для защиты.
- Публикация доступа к ресурсу с помощью прокси приложения Microsoft Entra с помощью условного доступа для защиты.
- Используйте условный доступ на основе VPN для доступа к ресурсу. Ограничить доступ к уровню приложения или DNS-имени.
Предположим, что нарушение
- Сегментируйте сетевую инфраструктуру.
- Свести к минимуму использование PKI предприятия.
- Перенос единого входа из AD FS в синхронизацию хэша паролей (PHS).
- Свести к минимуму зависимости от DCs с помощью KDC Kerberos в идентификаторе Microsoft Entra.
- Переместите плоскость управления в облако. Управление устройствами с помощью Microsoft Endpoint Manager.
Ниже приведены более подробные принципы и рекомендации по условному доступу.
- Применение принципов нулевого доверия к условному доступу.
- Используйте режим только для отчетов, прежде чем поместить политику в рабочую среду.
- Проверьте как положительные, так и отрицательные сценарии.
- Используйте управление изменениями и редакцией в политиках условного доступа.
- Автоматизация управления политиками условного доступа с помощью таких средств, как Azure DevOps/ GitHub или Azure Logic Apps.
- Используйте режим блокировки для общего доступа только в том случае, если и где вам нужно.
- Убедитесь, что все приложения и ваша платформа защищены. Условный доступ не имеет неявного "запретить все".
- Защита привилегированных пользователей во всех системах управления доступом на основе ролей (RBAC) Microsoft 365.
- Требовать изменение пароля и многофакторную проверку подлинности для пользователей с высоким риском и входа (применяется по частоте входа).
- Ограничение доступа с устройств с высоким уровнем риска. Используйте политику соответствия Intune с проверкой соответствия требованиям в условном доступе.
- Защита привилегированных систем, таких как доступ к порталам администрирования для Office 365, Azure, AWS и Google Cloud.
- Предотвращение постоянных сеансов браузера для администраторов и на ненадежных устройствах.
- Блокировать устаревшую проверку подлинности.
- Ограничение доступа от неизвестных или неподдерживаемых платформ устройств.
- По возможности требуется соответствующее устройство для доступа к ресурсам.
- Ограничение строгой регистрации учетных данных.
- Рекомендуется использовать политику сеансов по умолчанию, которая позволяет сеансам продолжаться, если до сбоя были выполнены соответствующие условия.
Проектирование зависимостей и связанных технологий
На следующей схеме показаны зависимости и связанные технологии. Некоторые технологии необходимы для условного доступа. Другие зависят от условного доступа. Дизайн, описанный в этом документе, главным образом ориентирован на условный доступ, а не на связанные технологии.
Руководство по условному доступу
Дополнительные сведения см. в разделе проектирование условного доступа на основе нулевого доверия ипользователей.
Участников
Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.
Автор субъекта:
- Claus Jespersen | Идентификатор основного консультанта&с
Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.