Поделиться через

Для идентификации и за ее пределами — точка зрения одного архитектора

  • Статья

В этой статье Алекс Стинберг (Alex Shteynberg), главный технический архитектор корпорации Майкрософт, обсуждает основные стратегии проектирования для корпоративных организаций, внедряющих Microsoft 365 и другие облачные службы Майкрософт.

Об авторе

Фото Алекса Стинберга.

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

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

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

Я живу в Нью-йорке (лучшее!) и действительно наслаждаюсь разнообразием его культуры, еды и людей (не трафика). Я люблю путешествовать, когда я могу и надеюсь увидеть большую часть мира в моей жизни. В настоящее время я исследую поездку в Африку, чтобы узнать о дикой природе.

Руководящие принципы

  • Простой часто лучше: вы можете делать (почти) все с помощью технологии, но это не означает, что вы должны. Особенно в области безопасности, многие клиенты чрезмерно упрощают решения. Мне нравится это видео с конференции Google Stripe, чтобы подчеркнуть этот момент.
  • Люди, процесс, технологии. Проектируйте для людей, чтобы улучшить процесс, а не технологии в первую очередь. Не существует "идеальных" решений. Нам нужно сбалансировать различные факторы риска и решения, которые могут быть разными для каждого бизнеса. Слишком много клиентов разрабатывают подход, который их пользователи позже избежать.
  • Сосредоточьтесь на "почему" сначала и "как" позже: Быть раздражает 7-летний ребенок с миллионом вопросов. Мы не можем получить правильный ответ, если не знаем правильных вопросов, которые следует задать. Многие клиенты делают предположения о том, как все нужно работать, вместо того чтобы определять бизнес-проблему. Существует всегда несколько путей, которые можно использовать.
  • Длинный хвост предыдущих рекомендаций: признайте, что рекомендации меняются со скоростью света. Если вы смотрели на Microsoft Entra более трех месяцев назад, вы, скорее всего, устарели. Все здесь может быть изменено после публикации. "Лучший" вариант сегодня может быть не тот же шесть месяцев отныне.

Базовые понятия

Не пропустите этот раздел. Я часто считаю, что я должен вернуться к этим статьям, даже для клиентов, которые используют облачные службы в течение многих лет. Увы, язык не является точным инструментом. Мы часто используем одно и то же слово для обозначения разных понятий или разные слова для обозначения одной и той же концепции. Я часто использую следующую схему для определения базовой терминологии и "модели иерархии".

Иллюстрация клиента, подписки, службы и данных.

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

Пояснение к схеме

  • Клиент — экземпляр Microsoft Entra ID. Он находится в верхней части иерархии или на уровне 1 на схеме. Мы можем считать этот уровень "границей", где происходит все остальное (Microsoft Entra B2B в сторону). Все корпоративные облачные службы Майкрософт входят в состав одного из этих клиентов. Службы потребителей являются отдельными. "Клиент" отображается в документации как клиент Microsoft 365, клиент Azure, клиент WVD и т. д. Я часто считаю, что эти варианты вызывают путаницу для клиентов.
  • Службы и подписки уровня 2 на схеме принадлежат одному и только одному клиенту. Большинство служб SaaS имеют формат 1:1 и не могут перемещаться без миграции. Azure отличается, вы можете переместить выставление счетов и (или ) подписку в другой клиент. Есть много клиентов, которым нужно переместить подписки Azure. Этот сценарий имеет различные последствия. Объекты, существующие за пределами подписки, не перемещаются. Например, управление доступом на основе ролей (Azure RBAC), Microsoft Entra объекты (группы, приложения, политики и т. д.) и некоторые службы (azure Key Vault, Data Bricks и т. д.). Не переносите службы без хорошей бизнес-потребности. Некоторые скрипты, которые могут быть полезны для миграции, доступны на сайте GitHub.
  • Данная служба обычно имеет определенную границу уровня "sublevel" или уровня 3 (L3). Эту границу полезно понимать для разделения безопасности, политик, управления и т. д. К сожалению, не существует единого имени, которое я знаю. Ниже приведены примеры имен для L3: Подписка Azure = ресурс; Dynamics 365 CE = экземпляр; Power BI = рабочая область; Power Apps = среда; и так далее.
  • Уровень 4 — это место, где находятся фактические данные. Эта "плоскость данных" является сложной статьей. Некоторые службы используют Microsoft Entra ID для RBAC, другие — нет. Я немного обсудим это, когда мы перейдем к статьям о делегировании.

Некоторые другие понятия, которые, как я считаю, многие клиенты (и сотрудники Майкрософт) путают или имеют вопросы о них, включают следующие проблемы:

  • Любой пользователь может создать множество клиентов бесплатно. Служба, подготовленная в ней, не требуется. У меня десятки. Каждое имя клиента уникально во всемирной облачной службе Майкрософт (другими словами, ни у двух клиентов не может быть одинаковых имен). Все они в формате TenantName.onmicrosoft.com. Существуют также процессы, которые автоматически создают клиенты (неуправляемые клиенты). Например, этот результат может произойти, когда пользователь регистрируется в корпоративной службе с доменом электронной почты, который не существует ни в одном другом клиенте.
  • В управляемом клиенте в нем можно зарегистрировать множество доменов DNS . Этот результат не изменяет исходное имя клиента. В настоящее время нет простого способа переименовать клиент (кроме миграции). Хотя имя клиента технически не критично в наши дни, некоторые люди могут чувствовать себя ограниченными этой реальностью.
  • Вам следует зарезервировать имя клиента для организации, даже если вы еще не планируете развертывать какие-либо службы. В противном случае кто-то может взять его у вас, и нет простого процесса, чтобы вернуть его обратно (та же проблема, что и DNS-имена). Я слышу это слишком часто от клиентов. То, как должно быть имя вашего клиента, также является дискуссией.
  • Если у вас есть пространство имен DNS, следует добавить все эти пространства имен в свои клиенты. В противном случае можно создать неуправляемый клиент с этим именем, что приведет к нарушению управления.
  • Пространство имен DNS (например, contoso.com) может принадлежать одному клиенту. Это требование влияет на различные сценарии (например, предоставление общего доступа к домену электронной почты во время слияния или приобретения и т. д.). Существует способ зарегистрировать подгруппу DNS (например, div.contoso.com) в другом клиенте, но этого следует избегать. При регистрации доменного имени верхнего уровня предполагается, что все поддомены принадлежат одному и тому же клиенту. В сценариях с несколькими клиентами (как описано далее) обычно рекомендуется использовать другое доменное имя верхнего уровня (например, contoso.ch или ch-contoso.com).
  • Кто должен "владеть" клиентом? Я часто вижу клиентов, которые не знают, кто в настоящее время владеет их клиентом. Это отсутствие знаний является значительным красным флагом. Обратитесь в службу поддержки Майкрософт как можно скорее. Так же проблематична, когда владелец службы (часто администратор Exchange) назначен для управления клиентом. Клиент содержит все службы, которые могут потребоваться в будущем. Владелец клиента должен быть группой, которая может принять решение о включении всех облачных служб в организации. Другая проблема заключается в том, что группе владельцев клиента предлагается управлять всеми службами. Этот метод не масштабируется для крупных организаций.
  • Не существует концепции суб-или супертенант. Почему-то этот миф продолжает повторяться. Эта концепция также относится к клиентам Azure Active Directory B2C . Слишком много раз я слышу фразу "Моя среда B2C находится в моем клиенте XYZ" или "Разделы справки переместить клиент Azure в клиент Microsoft 365?"
  • В этом документе основное внимание уделяется коммерческому глобальному облаку, так как это то, что использует большинство клиентов. Иногда полезно знать о национальных облаках. Национальные облака имеют другие последствия для обсуждения, которые не область для этого обсуждения.

Статьи о базовых удостоверениях

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

Подготовка

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

Microsoft Entra Connect и Microsoft Identity Manager (MIM) и что-то другое (стороннее или настраиваемое)? Избавите себя от проблем сейчас и в будущем и идите с Microsoft Entra Connect. В этом инструменте есть все виды умов для решения особых конфигураций клиентов и текущих инноваций.

Некоторые пограничные варианты, которые могут привести к более сложной архитектуре:

  • У меня есть несколько лесов AD без сетевого подключения между ними. Существует новый параметр под названием Подготовка облака.
  • У меня нет Active Directory и я не хочу его установить. Microsoft Entra Connect можно настроить для синхронизации из LDAP (может потребоваться партнер).
  • Мне нужно подготовить одни и те же объекты для нескольких клиентов. Этот сценарий не поддерживается технически, но зависит от определения "то же самое".

Следует ли настраивать правила синхронизации по умолчанию (фильтрация объектов, изменение атрибутов, альтернативный идентификатор входа и т. д.)? Избегайте этого! Платформа удостоверений так же ценна, как и службы, которые ее используют. Хотя вы можете выполнять все виды сумасшедших конфигураций, чтобы ответить на этот вопрос, необходимо рассмотреть влияние на приложения. Если фильтровать объекты с поддержкой почты, то глобальный список адресов для веб-службы является неполным; если приложение использует определенные атрибуты, фильтрация по этим атрибутам оказывает непредсказуемые последствия и т. д. Это не решение команды по идентификации.

XYZ SaaS поддерживает JIT-подготовку. Почему вы требуете синхронизацию? См. предыдущий абзац. Многие приложения нуждаются в сведениях о профилях для функциональных возможностей. У вас не может быть глобального списка адресов, если все объекты с поддержкой почты недоступны. То же самое относится и к подготовке пользователей в приложениях, интегрированных с Microsoft Entra ID.

Проверка подлинности

Синхронизация хэша паролей (PHS) и сквозная проверка подлинности (PTA) и федерация.

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

Некоторые клиенты включают федерацию и PHS в основном для:

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

Пример беседы доски.

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

Мы преследовали мечту о едином входе (SSO) до тех пор, как я помню. Некоторые клиенты считают, что они могут добиться единого входа, выбрав "правильный" поставщик федерации (STS). Microsoft Entra ID может значительно помочь в реализации возможностей единого входа, но никакие STS не являются волшебными. Существует слишком много устаревших методов проверки подлинности, которые по-прежнему используются для критически важных приложений. Расширение Microsoft Entra ID с помощью решений партнеров может решить многие из этих сценариев. Единый вход — это стратегия и путешествие. Вы не можете добраться до этого, не перейдя к стандартам для приложений. Эта статья связана с переходом к проверке подлинности без пароля , которая также не имеет волшебного ответа.

Многофакторная проверка подлинности (MFA) имеет важное значение на сегодняшний день (см . дополнительные сведения). Добавьте в него аналитику поведения пользователей , и у вас есть решение, которое предотвращает наиболее распространенные кибератаки. Даже службы потребителей переходят на требование MFA. Тем не менее, я по-прежнему встречаюсь со многими клиентами, которые не хотят переходить на современные подходы к проверке подлинности . Самый большой аргумент, который я слышу, заключается в том, что это влияет на пользователей и устаревшие приложения. Иногда хороший удар может помочь клиентам двигаться вперед - Exchange Online объявленные изменения. Теперь доступно множество Microsoft Entra отчетов, которые помогут клиентам с этим переходом.

Авторизация

В Википедии слово "авторизовать" — это определение политики доступа. Многие люди смотрят на него как на возможность определять элементы управления доступом к объекту (файл, служба и т. д.). В современном мире киберугроз эта концепция быстро развивается до динамической политики, которая может реагировать на различные векторы угроз и быстро корректировать элементы управления доступом в ответ на них. Например, если я получаю доступ к своему банковскому счету из необычного расположения, я получаю дополнительные действия по подтверждению. Чтобы приблизиться к этой реальности, необходимо рассмотреть не только саму политику, но экосистему методов обнаружения угроз и корреляции сигналов.

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

Обработчик политик в Microsoft Entra ID.

Объединение всех этих сигналов вместе позволяет использовать следующие динамические политики:

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

Если вы согласны с этим расширенным определением авторизации, необходимо реализовать дополнительные решения. Какие решения вы реализуете, зависит от того, насколько должна быть динамична политика и какие угрозы вы хотите приоритизировать. Ниже приведены некоторые примеры таких систем:

Помимо Microsoft Entra ID, различные службы и приложения имеют собственные модели авторизации. Некоторые из этих моделей рассматриваются далее в разделе делегирования.

Аудит

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

Нет Exchange

Не паникуйте! Exchange не рекомендуется (или SharePoint и т. д.). Это по-прежнему основная служба. То, что я имею в виду, в течение довольно долгого времени поставщики технологий переносили пользовательский интерфейс (UX) для охвата компонентов нескольких служб. В Microsoft 365 простой пример — "современные вложения", где вложения в электронную почту хранятся в SharePoint Online или OneDrive.

Вложение файла в сообщение электронной почты.

При просмотре клиента Outlook вы увидите множество служб, которые являются "подключенными" в рамках этого интерфейса, а не только Exchange. Примеры включают Microsoft Entra ID, поиск (Майкрософт), приложения, профиль, соответствие требованиям и группы Microsoft 365.

Интерфейс Outlook с выносками.

Ознакомьтесь с Microsoft Fluid Framework для предварительной версии предстоящих возможностей. В предварительной версии я могу читать беседы Teams и отвечать на нее непосредственно в Outlook. На самом деле клиент Teams является одним из наиболее ярких примеров этой стратегии.

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

Сегодня многие ИТ-группы клиентов структурированы вокруг "продуктов". Это логично для локального мира, так как вам нужен эксперт для каждого конкретного продукта. Тем не менее, я рад, что мне не нужно выполнять отладку базы данных Active Directory или Exchange, так как эти службы перемещены в облако. Автоматизация (в основном это облако) удаляет некоторые повторяющиеся задания вручную (посмотрите, что произошло с фабриками). Однако эти задачи заменяются более сложными требованиями для понимания взаимодействия между службами, эффекта, бизнес-потребностей и т. д. Если вы хотите учиться, вы можете воспользоваться большими возможностями, предоставляемыми облачным преобразованием. Прежде чем перейти к технологиям, я часто разговариваю с клиентами об управлении изменениями в ИТ-навыках и структурах команд.

Всем поклонникам и разработчикам SharePoint прекратите спрашивать "Как сделать XYZ в SharePoint Online?" Используйте Power Automate (или Flow) для рабочих процессов. Это гораздо более мощная платформа. Используйте Azure Bot Framework для создания лучшего пользовательского интерфейса для списка 500-тысячных элементов. Начните использовать Microsoft Graph вместо CSOM. Microsoft Teams включает в себя SharePoint, но и мир больше. Есть много других примеров, которые я могу перечислить. Там огромная и замечательная вселенная. Откройте дверь и начните исследовать.

Другой распространенный эффект заключается в области соответствия требованиям. Такой подход между службами, как представляется, полностью запутает многие политики соответствия требованиям. Я все время вижу, что организации заявляют: "Мне нужно записывать все сообщения электронной почты в систему обнаружения электронных данных". Что означает это утверждение, когда электронная почта больше не просто электронная почта, а окно в другие службы? Microsoft 365 имеет комплексный подход к соответствию требованиям, но изменение людей и процессов часто гораздо сложнее, чем технология.

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

Параметры структуры клиента

Однотенантное и мультитенантное

Как правило, у большинства клиентов должен быть только один рабочий клиент. Существует много причин, по которым несколько клиентов сложно (дать ему поиск Bing) или прочитать этот технический документ. В то же время у многих корпоративных клиентов, с которыми я работаю, есть еще один (небольшой) клиент для ОБУЧЕНИЯ, тестирования и экспериментирования. Межтенантный доступ к Azure упрощается с помощью Azure Lighthouse. Microsoft 365 и многие другие службы SaaS имеют ограничения для сценариев между клиентами. В Microsoft Entra сценариях B2B следует учитывать многое.

Многие клиенты получают несколько рабочих арендаторов после слияния и приобретения (M&A) и хотят консолидироваться. Сегодня это не просто, и для этого потребуется Microsoft Consulting Services (MCS) или партнер, а также стороннее программное обеспечение. В будущем ведется инженерная работа по решению различных сценариев с клиентами с несколькими клиентами.

Некоторые клиенты предпочитают использовать несколько клиентов. Это должно быть тщательное решение и почти всегда бизнес-причина, направляемая! Ниже приведены некоторые примеры.

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

В таких сценариях с несколькими клиентами клиенты часто хотят сохранить определенную конфигурацию одинаковой в разных клиентах или сообщать об изменениях и смещениях конфигурации. Это часто означает переход от ручных изменений к настройке в виде кода. Поддержка Microsoft Premiere предлагает семинар по следующим типам требований на основе этого общедоступного IP-адреса: https://Microsoft365dsc.com.

Поддержка нескольких регионов

Для нескольких регионов или не для нескольких регионов. Вот в чем вопрос. С помощью Microsoft 365 Multi-Geo вы можете подготавливать и хранить неактивные данные в географических расположениях, которые соответствуют требованиям к размещению данных . Существует много заблуждений об этой возможности. Учитывайте следующие моменты.

  • Это не обеспечивает преимущества производительности. Это может ухудшит производительность, если некорректная конструкция сети . Получите устройства "близко" к сети Майкрософт, не обязательно к вашим данным.
  • Это не решение для соответствия GDPR. GDPR не фокусируется на суверенитете данных или расположениях хранения. Существуют и другие платформы соответствия для обеспечения независимости данных или расположений хранения.
  • Он не устраняет делегирование администрирования (см. ниже) или информационные барьеры.
  • Это не то же самое, что мультитенантный, и требует больше рабочих процессов подготовки пользователей .
  • Клиент (ваш Microsoft Entra ID) не перемещается в другой географический регион.

Делегирование администрирования

В большинстве крупных организаций разделение обязанностей и управление доступом на основе ролей (RBAC) является необходимой реальностью. Я собираюсь извиниться заранее. Это действие не так просто, как некоторые клиенты хотят, чтобы оно было. Клиентские, юридические, нормативные и другие требования отличаются, а иногда и конфликтуют по всему миру. Простота и гибкость часто находятся на противоположных сторонах друг друга. Не поймите меня неправильно, мы можем сделать лучшую работу в этой цели. С течением времени были (и будут) значительные улучшения. Посетите местный Центр технологий Майкрософт , чтобы выработать модель, которая соответствует вашим бизнес-требованиям, не читая 379 230 документов! Здесь, я сосредоточусь на том, о чем вы должны думать, а не почему это так. В ближайшее время пять различных областей для планирования и некоторые из распространенных вопросов, с которыми я сталкиваюсь.

центры администрирования Microsoft Entra ID и Microsoft 365

Существует длинный и растущий список встроенных ролей. Каждая роль состоит из списка разрешений ролей, сгруппированных для выполнения определенных действий. Эти разрешения отображаются на вкладке "Описание" в каждой роли. Кроме того, вы можете увидеть более удобную для чтения версию этих разрешений в центре Microsoft 365 Admin. Нельзя изменить определения для встроенных ролей. Как правило, эти роли объединяются в три категории:

  • глобальный администратор. Эта роль "все возможности" должна быть защищена так же, как и в других системах. Типичные рекомендации: отсутствие постоянного назначения и использование Microsoft Entra управление привилегированными пользователями (PIM); строжная проверка подлинности и т. д. Интересно, что эта роль не предоставляет доступ ко всем по умолчанию. Как правило, я вижу путаницу в отношении доступа к соответствию требованиям и доступа Azure, как описано далее. Однако эта роль всегда может назначить доступ другим службам в клиенте.
  • Администраторы определенных служб. Некоторые службы (Exchange, SharePoint, Power BI и т. д.) используют высокоуровневые роли администрирования из Microsoft Entra ID. Это поведение не является согласованным во всех службах, и есть больше ролей для конкретных служб, которые рассматриваются далее.
  • Функциональный. Существует длинный (и растущий) список ролей, ориентированных на конкретные операции (приглашающий гостей и т. д.). Периодически добавляется больше этих ролей в зависимости от потребностей клиента.

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

Примечание. Центр администрирования Microsoft 365 имеет более удобный интерфейс, но имеет подмножество возможностей по сравнению с интерфейсом администратора Microsoft Entra. Оба портала используют одни и те же роли Microsoft Entra, поэтому изменения происходят в одном месте. Совет. Если вам нужен пользовательский интерфейс администратора, ориентированный на управление удостоверениями, без всех помех Azure, используйте https://aad.portal.azure.com.

Что в имени? Не делайте предположений из имени роли. Язык не является точным инструментом. Перед рассмотрением необходимых ролей необходимо определить операции, которые необходимо делегировать. Добавление пользователя в роль "Читатель безопасности" не приводит к отображению параметров безопасности во всех приложениях.

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

Еще один распространенный вопрос — возможность область роли в подмножество каталога. Один из примеров — "Администратор службы поддержки только для пользователей в ЕС". Административные единицы предназначены для решения этого сценария. Как уже упоминалось ранее, я думаю, что эти области применимы к функциям в Microsoft Entra ID и могут не охватывать "вниз". Некоторые роли не имеет смысла область (глобальные администраторы, администраторы служб и т. д.).

Сегодня для всех этих ролей требуется прямое членство (или динамическое назначение, если используется Microsoft Entra PIM). Это означает, что клиенты должны управлять этой ролью непосредственно в Microsoft Entra ID, и эти роли не могут быть основаны на членстве в группах безопасности. Я не любитель создавать скрипты для управления этими ролями, так как он должен выполняться с повышенными правами. Как правило, рекомендуется интегрировать API с системами процессов, такими как ServiceNow, или использовать партнерские средства управления, такие как Saviynt. С течением времени продолжается инженерная работа по решению этой проблемы.

Я несколько раз упоминал Microsoft Entra PIM. Существует соответствующее решение Microsoft Identity Manager (MIM) Privileged Access Management (PAM) для локальных элементов управления. Вы также можете просмотреть рабочие станции с привилегированным доступом (PAW) и Управление Microsoft Entra ID. Кроме того, существуют различные сторонние средства, которые могут обеспечить JIT- и динамическое повышение ролей. Эта возможность обычно является частью более широкого обсуждения защиты среды.

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

порталы соответствия требованиям Microsoft Defender XDR и Microsoft 365 Purview

Email & роли совместной работы на портале Microsoft Defender и *Группы ролей для решений Microsoft Purview на портале соответствия требованиям Microsoft 365 Purview представляют собой набор "групп ролей", которые отделены от Microsoft Entra ролей. Это может привести к путанице, так как некоторые из этих групп ролей имеют те же имена, что и Microsoft Entra роли (например, Читатель безопасности), но у них может быть разное членство. Я предпочитаю использовать Microsoft Entra роли. Каждая группа ролей состоит из одной или нескольких "ролей" (см., что я имею в виду о повторном использовании одного и того же слова?) и членов из Microsoft Entra ID, которые являются объектами с поддержкой электронной почты. Кроме того, можно создать группу ролей с тем же именем, что и роль, которая может содержать или не содержать эту роль (избегайте путаницы).

В каком-то смысле эти разрешения являются эволюцией модели групп ролей Exchange. Однако Exchange Online имеет собственный интерфейс управления группами ролей. Некоторые группы ролей в Exchange Online блокируются и управляются с Microsoft Entra ID или порталов соответствия требованиям Microsoft Defender XDR и Microsoft 365 Purview, но другие могут иметь те же или похожие имена и управлять с помощью Exchange Online (что добавляет путаницу). Рекомендуется избегать использования пользовательского интерфейса Exchange Online, если вам не нужны области для управления Exchange.

Вы не можете создать пользовательские роли. Роли определяются службами, созданными корпорацией Майкрософт, и продолжают расти по мере внедрения новых служб. Это поведение аналогично ролям, определенным приложениями в Microsoft Entra ID. При включении новых служб часто необходимо создавать новые группы ролей, чтобы предоставить или делегировать доступ к этим службам (например, управление внутренними рисками).

Эти группы ролей также требуют прямого членства и не могут содержать Microsoft Entra группы. К сожалению, сегодня эти группы ролей не поддерживаются Microsoft Entra PIM. Как и Microsoft Entra ролей, я, как правило, рекомендую управлять этими группами ролей с помощью API или продукта управления партнерами, например Saviynt или других.

Microsoft Defender портал и роли портала соответствия требованиям Microsoft 365 Purview охватывают Microsoft 365, и вы не можете область эти группы ролей в подмножестве среды (например, с административными единицами в Microsoft Entra ID). Многие клиенты спрашивают, как они могут выполнять подчиненные. Например, "создайте политику защиты от потери данных только для пользователей ЕС". Сегодня, если у вас есть права на определенную функцию на порталах соответствия требованиям Microsoft Defender XDR и Microsoft 365 Purview, у вас есть права на все, что покрывает эта функция в клиенте. Тем не менее, многие политики имеют возможность ориентироваться на подмножество среды (например, "сделать эти метки доступными только для этих пользователей"). Правильное управление и взаимодействие являются ключевым компонентом, который позволяет избежать конфликтов. Некоторые клиенты предпочитают реализовать подход "конфигурация как код" для решения субделегации на порталах соответствия требованиям Microsoft Defender XDR и Microsoft 365 Purview. Некоторые определенные службы поддерживают субделегацию (см. следующий раздел).

Конкретная служба

Как уже говорилось ранее, многие клиенты стремятся реализовать более детализированную модель делегирования. Распространенный пример: "Управление службой XYZ только для пользователей и расположений раздела X" (или другое измерение). Возможность сделать это зависит от каждой службы и не согласована между службами и возможностями. Кроме того, каждая служба может иметь отдельную и уникальную модель RBAC. Вместо того чтобы обсуждать все эти модели (которые будут принимать навсегда), я добавляю соответствующие ссылки для каждой службы. Этот список не является полным, но он может приступить к работе.

  • Exchange Online — (/exchange/permissions-exo/permissions-exo)
  • SharePoint Online — (/sharepoint/manage-site-collection-administrators)
  • Microsoft Teams — (/microsoftteams/itadmin-readiness)
  • Обнаружение электронных данных — (.. /compliance/index.yml)
    • Фильтрация разрешений — (.. /compliance/index.yml)
    • Границы соответствия — (.. /compliance/set-up-compliance-boundaries.md)
    • Обнаружение электронных данных (премиум) — (.. /compliance/overview-ediscovery-20.md)
  • Viva Engage - (/viva/engage/manage-viva-engage-users/manage-viva-engage-admins)
  • Несколько регионов — (.. /enterprise/add-a-sharepoint-geo-admin.md)
  • Dynamics 365 — (/dynamics365/)

Примечание.

Эта ссылка связана с корнем документации. Существует несколько типов служб с различными вариантами модели администрирования или делегирования.

  • Power Platform — (/power-platform/admin/admin-documentation)

    • Power Apps — (/power-platform/admin/wp-security)

      Примечание.

      Существует несколько типов с вариантами моделей администрирования или делегирования.

    • Power Automate — (/power-automate/environments-overview-admin)

    • Power BI — (/power-bi/service-admin-governance)

      Примечание. Безопасность и делегирование платформы данных (компонентом которого является Power BI) — это сложная область.

  • Intune — (/mem/intune/fundamentals/role-based-access-control)

  • Microsoft Defender для конечной точки — (/windows/security/threat-protection/microsoft-defender-atp/user-roles)

  • Microsoft Defender XDR - (.. /security/defender/m365d-permissions.md)

  • Microsoft Defender for Cloud Apps — (/cloud-app-security/manage-admins)

  • Stream — (/stream/assign-administrator-user-role)

  • Информационные барьеры — (.. /compliance/information-barriers.md)

Журналы действий

Microsoft 365 имеет единый журнал аудита. Это очень подробный журнал, но не читайте слишком много в имени. Он может не содержать все необходимое или необходимое для обеспечения безопасности и соответствия требованиям. Кроме того, некоторые клиенты очень заинтересованы в аудите (Премиум).

Примеры журналов Microsoft 365, доступ к которым осуществляется через другие API, включают следующие функции:

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

С точки зрения делегирования администратора большинство журналов действий Microsoft 365 не имеют встроенной модели RBAC. Если у вас есть разрешение на просмотр журнала, вы сможете просмотреть все в нем. Распространенный пример требования клиента: "Я хочу иметь возможность запрашивать действия только для пользователей ЕС" (или другое измерение). Чтобы выполнить это требование, необходимо перенести журналы в другую службу. В облаке Майкрософт рекомендуется перенести его в Microsoft Sentinel или Log Analytics.

Схема высокого уровня:

схема источников журналов для программы обеспечения безопасности и соответствия требованиям.

На схеме представлены встроенные возможности для отправки журналов в Центры событий и (или) службу хранилища Azure и (или) Azure Log Analytics. Еще не все системы включают в себя это в коробке. Но существуют и другие подходы к отправке этих журналов в тот же репозиторий. Например, см . раздел Защита Teams с помощью Microsoft Sentinel.

Объединение всех журналов в одном расположении хранения включает дополнительные преимущества, такие как перекрестная корреляция, пользовательское время хранения, добавление данных, необходимых для поддержки модели RBAC, и т. д. После того как данные будут в этой системе хранения, можно создать панель мониторинга Power BI (или другой тип визуализации) с соответствующей моделью RBAC.

Журналы не должны направляться только в одно место. Также может быть полезно интегрировать журналы Microsoft 365 с Microsoft Defender for Cloud Apps или пользовательской моделью RBAC в Power BI. Разные репозитории имеют разные преимущества и аудиторию.

Стоит отметить, что в службе под названием Microsoft Defender XDR есть богатая встроенная система аналитики безопасности, угроз, уязвимостей и т. д.

Многие крупные клиенты хотят передать эти данные журнала в стороннюю систему (например, SIEM). Существуют различные подходы к этому результату, но в целом Центры событий Azure и Graph являются хорошими отправными точками.

Azure

Меня часто спрашивают, существует ли способ разделения ролей с высоким уровнем привилегий между Microsoft Entra ID, Azure и SaaS (например, глобальный администратор Microsoft 365, но не Azure). Не так. Многотенантная архитектура необходима, если требуется полное административное разделение, но это значительно усложняет (как обсуждалось ранее). Все эти службы являются частью одной границы безопасности и идентификации (как показано в модели иерархии).

Важно понимать связи между различными службами в одном клиенте. Я работаю со многими клиентами, которые создают бизнес-решения, охватывающие Azure, Microsoft 365 и Power Platform (а также часто локальные и сторонние облачные службы). Один распространенный пример:

  1. Я хочу совместно работать над набором документов, изображений и т. д. (Microsoft 365)
  2. Отправка каждого из них через процесс утверждения (Power Platform)
  3. После утверждения всех компонентов соберите эти элементы в унифицированные конечные типы (Azure) Microsoft API Graph это ваш лучший друг. Не невозможно, но значительно сложнее спроектировать решение, охватывающее несколько клиентов.

Azure Role-Based контроль доступа (RBAC) обеспечивает детальное управление доступом для Azure. С помощью RBAC можно управлять доступом к ресурсам, предоставляя пользователям наименьшее количество разрешений, необходимых для выполнения заданий. Подробные сведения не область для этого документа, но дополнительные сведения о RBAC см. в статье Что такое управление доступом на основе ролей (RBAC) в Azure? RBAC является важным, но только частью рекомендаций по управлению для Azure. Cloud Adoption Framework является отличной отправной точкой для получения дополнительных сведений. Мне нравится, как мой друг, Андрес Равинет, пошагово проходит клиентов через различные компоненты, чтобы определиться с подходом. Высокоуровневое представление для различных элементов (не так хорошо, как процесс для получения фактической модели клиента) выглядит примерно так:

Общее представление компонентов Azure для делегированного администрирования.

Как видно из рисунка выше, многие другие службы должны рассматриваться в качестве части проекта (например, Политики Azure, Azure Blueprints, группы управления и т. д.).

Заключение

Эта статья началась как краткое резюме, в итоге дольше, чем я ожидал. Я надеюсь, что теперь вы готовы понять, как создать модель делегирования для вашей организации. Эта беседа очень распространена для клиентов. Нет ни одной модели, которая работает для всех. Дождитесь нескольких запланированных улучшений от разработки Майкрософт, прежде чем документировать распространенные шаблоны, которые мы видим для клиентов. В то же время вы можете сотрудничать со своей командой по работе с учетными записями Майкрософт, чтобы организовать посещение ближайшего технологического центра Майкрософт. Увидимся там!