Разбираемся в клиенте Microsoft 365: архитектура, идентификация и границы

By Mirko Peters · 2026-08-27

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

Automatically translated with AI from the original post. Read the English original

Рады снова видеть вас в подкасте! Если вы слушали наши выпуски об облачной архитектуре, безопасности или администрировании предприятия, вы знаете, что нам нравится разбираться в устройстве технологий, которыми мы пользуемся каждый день. Сегодня мы подробно рассмотрим одну из самых фундаментальных и при этом часто неправильно понимаемых концепций в корпоративной облачной экосистеме: клиент Microsoft 365. Являетесь ли вы ИТ-администратором, который весь день проводит в центре администрирования, специалистом по безопасности, проектирующим политики доступа, или руководителем, который задаётся вопросом, как данные компании изолированы в облаке, — понимание клиента критически важно. В этой статье, дополняющей наш последний выпуск подкаста, мы расскажем об основных опорах облака Microsoft. Мы разберём, что такое клиент M365 на самом деле, как в нём работают идентификации, как подписки определяют лицензирование и почему административные границы — лучшая защита от утечек данных и взломов.

Введение в клиент Microsoft 365

Чтобы по-настоящему понять облако Microsoft, нужно начать с самого начала: с клиента. Но что такое клиент Microsoft 365, на самом деле? По сути, клиент — это выделенный экземпляр облачных служб Microsoft для вашей организации. Представьте его как защищённый, изолированный сегмент глобальной инфраструктуры дата-центров Microsoft. Когда ваша компания подключает Microsoft 365, Azure или Dynamics 365, Microsoft создаёт для вас выделенный контейнер. Этот контейнер хранит ваши данные, учётные записи пользователей, конфигурации служб и политики безопасности. Он полностью отделён от всех остальных клиентов облака Microsoft, что обеспечивает многоклиентскую изоляцию, соответствующую строгим требованиям комплаенса.

Однако многие путают понятия «клиент», «домен» и «подписка», используя их как взаимозаменяемые. Давайте сразу всё прояснim. Клиент — это общий контейнер. Домен — это просто пространство имён, например contoso.com, которое вы используете для адресов электронной почты и входа пользователей. Подписка — это коммерческое соглашение, по которому вы оплачиваете лицензии и службы. С одним клиентом может быть связано несколько доменов и несколько подписок, но сам клиент — это базовая граница, которая объединяет всё остальное. Полезно представить клиент как дом: клиент — это само здание и участок, на котором оно стоит, домены — это адрес на почтовом ящике, а подписки — это счета за коммунальные услуги, которые вы платите, чтобы в доме были свет и вода.

Роль Microsoft Entra ID и управление идентификацией

Нельзя говорить о клиенте Microsoft 365, не говоря об идентификации, и в частности о Microsoft Entra ID — ранее известном как Azure Active Directory. Если клиент — это дом, то Microsoft Entra ID — это система безопасности, замки на входной двери и реестр всех, кому разрешено войти. Каждый клиент Microsoft 365 поставляется с каталогом Microsoft Entra ID по умолчанию. Этот каталог — авторитетный источник всех учётных записей пользователей, групп, субъектов служб и регистраций приложений.

Идентификация — новый периметр безопасности в современной облачной архитектуре. В старые времена локальной ИТ-инфраструктуры мы защищали корпоративную сеть, выстраивая межсетевой экран и доверяя всему, что находится внутри этой сети. В облаке сетевого периметра больше нет: пользователи работают из кофеен, домашних офисов и с мобильных устройств по всему миру. Поэтому идентификация заняла место межсетевого экрана. Когда пользователь пытается получить доступ к Exchange Online, SharePoint или Microsoft Teams, именно Microsoft Entra ID проверяет, кто он, какие устройства использует, и решает, предоставить ли доступ, исходя из политик условного доступа.

Эффективное управление identities внутри вашего клиента требует продуманной стратегии. Большинство организаций используют гибридную модель идентификации: синхронизируют свои локальные Active Directory Domain Services с Microsoft Entra ID с помощью инструмента Microsoft Entra Connect или Microsoft Entra Cloud Sync. Это позволяет пользователям работать с единым набором учётных данных как для локальных сетевых ресурсов, так и для облачных сервисов Microsoft 365. Однако независимо от того, созданы ли ваши identities только в облаке или синхронизированы из локальной среды, управление их жизненным циклом (создание, назначение ролей, управление учётными данными и удаление) остаётся одной из самых важных задач администратора Microsoft 365.

Управление подписками, лицензиями и биллингом

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

Важно понимать, что подписки привязаны к клиенту. Нельзя купить подписку Microsoft 365 Business Premium или Enterprise E5 и назначить её пользователю из другого клиента. Все лицензии необходимо приобретать и назначать в административных границах конкретного клиента. Кроме того, организации часто управляют несколькими подписками внутри одного клиента. Например, у вас может быть одна подписка на лицензии Microsoft 365 E5, другая подписка на облачные сервисы Azure с оплатой по потреблению и третья подписка на специализированные дополнительные продукты, такие как Power BI Premium или Microsoft Copilot.

Управление лицензиями может быстро превратиться в административную головную боль, если не подходить к нему проактивно. Администраторы должны назначать лицензии пользователям или группам, гарантируя, что у людей есть доступ именно к тем инструментам, которые им нужны, будь то Exchange для почты, SharePoint для совместной работы с документами или полный набор настольных приложений. Автоматизированное управление лицензиями, как правило, на основе лицензирования по группам в Microsoft Entra ID, является передовой практикой для растущих организаций. Когда новый пользователь добавляется в группу «Sales», система автоматически назначает ему нужные лицензии, а когда он покидает организацию и удаляется из группы, эти лицензии высвобождаются и становятся доступны другим пользователям.

Настройка пользовательских доменов и DNS

Когда вы впервые создаёте клиент Microsoft 365, Microsoft присваивает вам домен по умолчанию, который заканчивается на onmicrosoft.com, например contoso.onmicrosoft.com. Этот домен полностью работоспособен, но вряд ли вы хотите, чтобы корпоративная почта уходила с адресов вида user@contoso.onmicrosoft.com. Чтобы создать профессиональный бренд и обеспечить бесперебойную доставку почты и интеграцию сервисов, необходимо настроить пользовательские домены в вашем клиенте.

Настройка пользовательского домена предполагает подтверждение того, что вы действительно владеете доменным именем, которое собираетесь использовать. Для этого в DNS-хостинге, например GoDaddy, Cloudflare или Route 53, добавляются определённые записи TXT или MX. Как только Microsoft подтвердит владение доменом, например contoso.com, вы сможете сделать его основным, обновить имена участников-пользователей (UPN), чтобы пользователи входили под своими рабочими адресами электронной почты, и настроить необходимые DNS-записи для доставки почты (записи MX), автообнаружения (записи CNAME) и протоколов безопасности, таких как SPF, DKIM и DMARC.

Правильная настройка DNS важна не только для профессионального вида, но и как требование безопасности. Если для пользовательского домена в вашем клиенте M365 не настроены корректные записи SPF, DKIM и DMARC, злоумышленники могут легко подделать домен вашей почты, что приведёт к фишинговым атакам на ваших клиентов и партнёров. Время, потраченное на правильную настройку и проверку параметров DNS, является обязательным этапом любого проекта внедрения Microsoft 365.

Основные облачные сервисы и выделение ресурсов

Когда клиент, система удостоверений, подписки и пользовательские домены настроены, ваша среда Microsoft 365 наконец готова к размещению рабочих нагрузок. Клиент Microsoft 365 — это не монолит, а развитая экосистема интегрированных приложений Software-as-a-Service (SaaS), созданных для повышения продуктивности, совместной работы и коммуникации. Для любого администратора важно понимать, как эти основные облачные сервисы развертываются и взаимодействуют в границах клиента.

Exchange Online обеспечивает корпоративный уровень электронной почты, календарей и управления контактами. SharePoint Online служит основой для хранения документов, интранет-сайтов и управления корпоративным контентом. Microsoft Teams объединяет чат, собрания, звонки и совместную работу в едином центре, который глубоко интегрирован с SharePoint, Exchange и различными сторонними приложениями. Наряду с этими ключевыми сервисами работают OneDrive для бизнеса, Planner, Stream и Power Platform (Power Apps, Power Automate и Power BI).

Когда пользователи создают команду в Microsoft Teams, за кулисами клиент автоматически развертывает сложную сеть взаимосвязанных ресурсов: коллекцию сайтов SharePoint для хранения файлов, группу Microsoft 365 для управления участниками, общий почтовый ящик Exchange с календарем и блокнот OneNote. Этот автоматизированный механизм развертывания демонстрирует возможности архитектуры M365. Однако он также подчеркивает важность управления. Без превентивных политик управления — например, ограничения на создание групп Microsoft 365 или настройки автоматического истечения срока действия для неактивных команд — ваш клиент может быстро превратиться в хаотичное разрастание неиспользуемых ресурсов и избыточных данных.

Административные границы и рекомендации по безопасности

Завершая наше глубокое погружение в клиент Microsoft 365, нельзя обойти самую важную тему: административные границы и рекомендации по безопасности. Клиент является вашей основной границей безопасности. Данные внутри клиента шифруются в состоянии покоя и при передаче, и по умолчанию они полностью недоступны никому за пределами вашей организации, включая других клиентов Microsoft и даже специалистов службы поддержки Microsoft (если только им не предоставлен временный доступ явным образом через Customer Lockbox).

Однако безопасность не заканчивается на периметре клиента: вы также должны управлять разрешениями *внутри* клиента. Здесь вступает в силу принцип наименьших привилегий. Microsoft Entra ID предоставляет широкий набор встроенных административных ролей, таких как Global Administrator, Exchange Administrator, Helpdesk Administrator и User Administrator. Одна из самых распространенных ошибок организаций — назначение роли Global Administrator, которая имеет полный доступ ко всем настройкам и данным в клиенте, слишком большому числу людей. Рекомендуется сводить число Global Administrator к абсолютному минимуму (обычно от двух до четырех человек для резервирования) и назначать более детализированные роли, ориентированные на конкретные задачи, для повседневной работы.

Кроме того, защита административных учетных записей с помощью многофакторной аутентификации (MFA) не подлежит обсуждению. Внедрение устойчивой к фишингу MFA, например ключей безопасности FIDO2 или сопоставления чисел в Microsoft Authenticator, — это самый эффективный шаг для предотвращения несанкционированного доступа к клиенту. Дополните это надежными политиками условного доступа, которые оценивают уровень риска, соответствие устройства требованиям и местоположение перед предоставлением доступа, и вы создадите надежную многоуровневую систему защиты.

Наконец, управление и мониторинг никогда не должны быть запоздалой мыслью. Использование таких инструментов, как Microsoft Purview для соответствия требованиям, предотвращения утечек данных (DLP) и защиты информации, гарантирует, что конфиденциальные данные маркируются, отслеживаются и защищаются на всем протяжении жизненного цикла. Регулярный аудит назначений административных ролей, проверка журналов входа и мониторинг оповещений в портале Microsoft Defender помогут поддерживать безопасность, соответствие требованиям и оптимальную работу клиента под нужды вашего бизнеса.

Спасибо, что прочитали эту статью — она дополняет наш подкаст! Надеемся, что этот подробный разбор архитектуры клиентов Microsoft 365, управления идентификацией, подписок, пользовательских доменов и границ безопасности помог вам лучше понять, как устроено облако изнутри. Если статья вам понравилась, подпишитесь на подкаст, поделитесь этим материалом с вашей ИT-командой и присоединяйтесь к нам на следующей неделе, когда мы разберём ещё одну интересную тему из мира корпоративных технологий. А пока берегите безопасность своих клиентов и отказоустойчивость облачных архитектур!