Рекомендуемые политики и конфигурации безопасностиRecommended security policies and configurations

ВведениеIntroduction

Хотя единого оптимального варианта для всех клиентских сред не существует, в рекомендациях по конфигурациям и политиках в этом документе даны общие указания Майкрософт о применении политик и конфигураций в Microsoft Cloud для обеспечения безопасной и продуктивной работы ваших сотрудников.While there is no single best recommendation for all customer environments, the best practices and recommendations in this document describe general Microsoft recommendations about how to apply policy and configuration within the Microsoft cloud to ensure that your employees are both secure and productive.

Целевая аудитория. Эти рекомендации предназначены для архитекторов инфраструктуры предприятия и ИТ-специалистов, знакомых с Office 365 и Microsoft Enterprise Mobility + Security, включая, помимо прочего, Azure Active Directory (удостоверения), Microsoft Intune (управление устройствами) и Azure Information Protection (защита данных).Intended audience These recommendations are intended for enterprise infrastructure architects and IT Pros familiar with Office 365 and Microsoft Enterprise Mobility + Security which includes, among others, Azure Active Directory (identity), Microsoft Intune (device management), and Azure Information Protection (data protection).

Среда клиента. Рекомендуемые политики действуют для организаций, полностью работающих в облачной среде Майкрософт, и клиентов с инфраструктурой, развернутой в локальной и облачной средах Майкрософт.Customer environment The recommended policies are applicable to enterprise organizations operating both entirely within the Microsoft cloud and for customers with infrastructure deployed across on-premises and the Microsoft cloud.

Предположения. Многие из предоставленных рекомендаций опираются на службы, доступные только с помощью подписок Enterprise Mobility + Security (EMS) E5.Assumptions Many of the provided recommendations rely on services available only with Enterprise Mobility + Security (EMS) E5 subscriptions. Рекомендации предполагают использование всех возможностей подписки EMS E5.Recommendations presented assume full EMS E5 subscription capabilities.

Предупреждения. К вашей организации могут применяться нормативные или другие требования, включая конкретные рекомендации, которые могут потребовать применения политик, отличающихся от рекомендуемых конфигураций.Caveats Your organization may be subject to regulatory or other compliance requirements, including specific recommendations that may require you to apply policies that diverge from these recommended configurations. Эти конфигурации рекомендуют использовать средства управления, которые не были доступны ранее.These configurations recommend usage controls that have not historically been available. Мы рекомендуем применить эти средства управления, так как считаем, что они обеспечивают баланс между безопасностью и производительностью.We recommend these controls, because we believe they represent a balance between security and productivity.

Несмотря на то, что мы делаем все возможное, чтобы учесть самые разнообразные требования к защите, мы не в состоянии учесть все потребности или все уникальные аспекты вашей организации.While we’ve done our best to account for a wide variety of organizational protection requirements, we’re not able to account for all possible requirements or for all the unique aspects of your organization. Используйте эти рекомендации в качестве руководства, чтобы узнать, как корпорация Майкрософт и группы по обеспечению безопасности организации применяют политики.Use these recommendations as a guide for how Microsoft and the secure productive enterprise team is thinking about how to correctly apply policy.

Примечание

Обзор основных понятий, необходимых для понимания возможностей защиты, описанных в этих рекомендациях, см. на домашней странице документации по Microsoft 365 Enterprise.For an overview of the core concepts necessary to understand the protection capabilities described in these recommendations, see the Microsoft 365 Enterprise documentation home page.

Основные понятияCore concepts

Никакие меры безопасности не имеют значения, когда пользователи, сталкивающиеся с ненужным сопротивлением при попытке выполнения поставленных задач, обходят политики безопасности организации.All the security measures in the world do not matter when users, who experience unnecessary friction when trying to get their work done, bypass your organizational security policies. Единый вход Azure AD (SSO) предназначен для сокращения нагрузки на пользователей.Azure AD single-sign on (SSO) attempts to minimize the burden on users. В этом случае пользователи могут оставаться продуктивными, соблюдая при этом принятые в организации политики контроля доступа.This way users can remain productive while still conforming to the access control policies of the organization.

Проверка подлинности при едином входеSingle sign-on authentication

На следующей схеме показан стандартный алгоритм проверки подлинности SSO.The following diagram illustrates a typical SSO authentication flow:

Единый вход конечного пользователя

Чтобы начать проверку подлинности, клиент отправляет учетные данные (например, имя пользователя и пароль) и (или) все полученные ранее артефакты в Azure AD.To begin authentication, the client submits credentials (such as username and password) and/or any SSO artifacts obtained in the past to Azure AD. Артефактом единого входа может быть маркер сеанса для браузера или маркер обновления для многофункциональных приложений.An SSO artifact can be a session token for a browser or a refresh token for rich applications.

После проверки учетных данных и (или) артефакта единого входа в Azure AD и оценки всех применимых политик выдается маркер доступа для поставщика ресурсов (Office 365 на схеме выше).After the credentials and/or SSO artifact have been verified in Azure AD, and all applicable policies have been evaluated, an access token for the resource provider (Office 365 in the above diagram) is issued. Azure AD также выдает артефакт SSO в составе ответа, чтобы разрешить клиентам получить SSO в последующих запросах.Azure AD also issues an SSO artifact as part of the response to allow clients to achieve SSO in subsequent requests. Клиент сохраняет артефакт SSO и отправляет маркер доступа поставщику ресурсов как доказательство подлинности.The client stores the SSO artifact and submits the access token as a proof of identity to the resource provider. После того как Office 365 проверит маркер доступа и выполнит необходимые проверки, клиент получит доступ к документам.After Office 365 verifies the access token and performs necessary checks, it will grant the client access to the documents.

Маркеры обновления единого входа (SSO)Single sign-on (SSO) refresh tokens

Существуют разные способы выполнения единого входа.SSO can be achieved in various ways. Например, файлы cookie от поставщика удостоверений можно использовать в качестве артефакта SSO для хранения состояния входа пользователя в браузере.For example, cookies from an identity provider can be used as the SSO artifact to store the sign-in state for a user within a browser. Затем будут доступны дальнейшие попытки входа в автоматическом режиме (без каких-либо запросов на ввод учетных данных) с помощью того же поставщика удостоверений.Future attempts to sign in silently (without any prompts for credentials) to applications using the same identity provider are then possible.

Когда пользователь проходит проверку подлинности в Azure AD, устанавливается сеанс единого входа с браузером пользователя и Azure AD.When a user authenticates with Azure AD, an SSO session is established with the user’s browser and Azure AD. Этот сеанс представляет маркер единого входа в виде файла cookie.The SSO token, in the form of a cookie, represents this session. Azure AD использует два вида маркеров сеанса единого входа: постоянные и непостоянные.Azure AD uses two kinds of SSO session tokens: persistent and non-persistent. Постоянные маркеры сеансов хранятся в виде постоянных файлов cookie в браузерах с установленным во время входа флажком Оставаться в системе.Persistent session tokens are stored as persistent cookies by browsers when the Keep me signed in checkbox is selected during sign in. Непостоянные маркеры сеансов хранятся в виде файлов cookie сеанса и удаляются при закрытии браузера.Non-persistent session tokens are stored as session cookies, and are destroyed when the browser is closed.

Единый вход в надежные приложения, использующие современные протоколы проверки подлинности, такие как OpenId Connect и OAuth 2.0, осуществляется с помощью маркеров обновления в качестве артефактов единого входа (в дополнение к ранее описанным файлам cookie SSO).For robust applications capable of using modern authentication protocols, such as OpenId Connect and OAuth 2.0, SSO is enabled using refresh tokens as the SSO artifacts (in addition to earlier described SSO cookies). Маркеры обновления предоставляются серверу авторизации, когда приложение запрашивает новый маркер доступа.Refresh tokens are presented to an authorization server when an application requests a new access token. Маркер обновления содержит утверждения и атрибуты, описывающие тип методов проверки подлинности, которые используются при проверке подлинности пользователей.The refresh token contains claims and attributes about the kind of authentication methods used when authenticating users. Например, если пользователь успешно прошел проверку подлинности с использованием различных методов (имени пользователя и пароля и проверки подлинности по телефону), то в маркере обновления присутствует утверждение многофакторной идентификации (MFA).For example, if a user has successfully authenticated using multiple methods (username & password and phone-based authentication), then a multi-factor authentication (MFA) claim is present in the refresh token. Кроме того, могут существовать дополнительные утверждения, которые содержат данные, такие как срок действия многофакторной идентификации.Also, there may be additional claims that contain data such as MFA validity duration.

Маркеры обновления позволяют клиенту получить новый маркер доступа без прохождения другого вида интерактивной проверки подлинности.Refresh tokens allow the client to obtain a new access token, without needing to do another interactive authentication. Маркеры обновления имеют более длительное время существования, чем маркеры доступа, и могут быть активированы для получения новой пары маркеров доступа и обновления.Refresh tokens have a much longer lifetime than access tokens and can be redeemed to obtain a new access and refresh token pair. После этого новые маркеры обновления можно применять для постоянного получения других наборов маркеров доступа и обновления.The newly obtained refresh tokens can then be continually used to fetch another set of access and refresh tokens. Клиент продолжает выполнять этот процесс единого входа либо до истечения максимального времени неактивности маркера обновления, либо до истечения максимального срока действия маркера обновления, либо до изменения требований политики проверки подлинности и авторизации.The client continues this SSO process until either the refresh token maximum inactive time setting expires, the refresh token max age expires, or the authentication and authorization policy requirements change. Это изменение происходит в то время, когда был выдан исходный маркер обновления.This change occurs during the time when the original refresh token was issued. Для существенных изменений атрибутов пользователя, например сброса пароля, также требуется создание маркера проверки подлинности.Significant user attribute changes, for example a password reset, also require a new authentication token to be generated. Чтобы продолжать действия, клиент должен выполнить новую интерактивную проверку подлинности.The client must do a fresh interactive authentication to continue further. По сути это означает нарушение процесса единого входа, с которым клиент не сталкивался до этого момента.Essentially it signifies a break in the SSO process that the client has not experienced until now.

Условный доступConditional access

Azure AD, выступающая в качестве службы авторизации для приложений, определяет, следует ли выдавать маркеры доступа, на основе оценки всех политик условного доступа, применяемых к ресурсу, к которому вы пытаетесь получить доступ.Azure AD, acting as an authorization service for your applications, determines whether to issue access tokens based on an evaluation of any conditional access policies applied to the resource that you’re trying to access. Если требования политики удовлетворяются, выдаются маркер обновления и маркер доступа.If policy requirements are met, then an access token and updated refresh token are issued. В противном случае пользователь получает инструкции о том, как нужно выполнить требования, и (или) должен будет реализовать дополнительные действия, включая многофакторную идентификацию (MFA).If the policy is not met, the user receives instructions on how to meet the policy and/or is required to complete additional steps including multi-factor authentication (MFA). После завершения многофакторной идентификации в результирующий маркер обновления добавляется утверждение MFA.Once MFA has been completed, the MFA claim is added to the resulting refresh token.

Со временем утверждения накапливаются в маркере обновления.Claims in the refresh token get accumulated over time. Некоторые утверждения имеют сроки действия, по истечении которых они больше не учитываются во время проверок авторизации.Some of the claims have expiration timelines, after which they are no longer considered during authorization checks. Иногда это может приводить к неожиданным результатам.This can sometimes cause unexpected results. Например, если политика условного доступа настроена так, что для поступающих из экстрасети попыток проверки подлинности требуется многофакторная идентификация.For example, if a conditional access policy is configured so that MFA is required for authentication attempts coming from extranet locations. В этом случае при доступе к ресурсу из экстрасети пользователи могут не получать ожидаемый запрос на многофакторную идентификацию.In this case, users might sometimes not receive the expected MFA prompt when accessing a resource from extranet. Возможная причина заключается в том, что пользователь мог пройти многофакторную идентификацию незадолго до выхода из интрасети.A possible reason for this is that the user could have previously performed MFA shortly before leaving the intranet. Таким образом, в его маркере доступа находится допустимое утверждение многофакторной идентификации.Therefore, they have a valid MFA claim in their access token. Это утверждение многофакторной идентификации соответствует требованиям политики, поэтому Azure AD не выводит дополнительный запрос MFA.This MFA claim satisfies the policy requirement and thus Azure AD does not prompt the user with an additional MFA request.

Политика времени существования маркераToken lifetime policy

Окончание срока действия имеют не только отдельные утверждения в маркере, но и сами маркеры.Beyond the expiration of individual claims in a token, tokens themselves have expiration times. Как было отмечено ранее, маркеры с истекшим сроком действия являются одной из причин разрыва сеанса единого входа.As noted before, expired tokens are one reason why the SSO experience can be broken. Задать время существования маркера, выданного Azure AD, можно с помощью политик времени существования маркера.You can set the lifetime of a token issued by Azure AD by using token lifetime policies. Можно сделать вывод о сложности фиксации определения контуров сеанса единого входа.As can be inferred from above, defining the contours of an SSO session is harder to capture. Например, когда на многофункциональные приложения действуют кажущиеся отключенными различные факторы, которые могут повлиять на время существования сеанса единого входа.For example, when rich apps as various factors that are seemingly disconnected can impact the lifetime of an SSO session.

Примечание

Глобальные администраторы Azure AD могут управлять периодами действия и бездействия маркеров обновления.Azure AD Global Administrators can control the validity and inactivity periods of refresh tokens. Сведения о маркерах доступа и утверждениях, использующих параметры, описаны в статье Настройка времени жизни маркеров в Azure Active Directory.Information about access token and claims using the settings described in the article Configurable token lifetimes in Azure Active Directory.

Основные маркеры обновленияPrimary refresh tokens

До этого момента в данной статье рассматривалось действие единого входа в контексте одного клиента, но этого недостаточно, чтобы использовать единый вход в пределах приложения.So far, this article has discussed how SSO works within the context of a single client, but this is not enough to experience SSO within a single app. В современном мире пользователей окружают интерактивные рабочие процессы, охватывающие несколько приложений в одном и том же наборе приложений, например Microsoft Office.These days, users experience interactive workflows spanning multiple applications within the same suite of applications, such as Microsoft Office. Пользователям также требуется доступ между несвязанными приложениями, включая корпоративные бизнес-приложения.Users also need access across unrelated applications, including internally developed line of business (LOB) applications.

Как правило, присоединенные к домену устройства Windows, использующие встроенную проверку подлинности Windows (Kerberos), обладают максимальной поддержкой единого входа в нескольких приложениях и ресурсах.Traditionally, domain joined Windows devices, using Windows Integrated Authentication (Kerberos), achieve a high degree of SSO experience across multiple applications and resources. В число этих приложений входят поддерживаемые браузеры, такие как Internet Explorer или Edge.These apps include supported browsers such as Internet Explorer or Edge. У среды Azure AD есть аналог в виде основного маркера обновления (PRT).There is an analog for the Azure AD realm, in the form of a primary refresh token (PRT). Этот привилегированный маркер доступен только определенному набору сущностей клиента (например, системным компонентам платформы).This privileged token is only available to a select set of client entities (such as platform system components). Сущности затем могут разрешать доступ с проверкой подлинности через брокер к другим клиентским приложениям, чтобы они также предлагали возможности единого входа.The entities can then allow brokered authentication access to other client applications, so that they can also offer a seamless SSO experience. Для пользователей Office 365 на устройствах iOS и Android были предприняты дополнительные меры по сокращению количества необходимых проверок подлинности за счет применения функциональности брокера проверки подлинности.For Office 365 users on iOS and Android devices, additional work has been done to reduce the number of required authentications by applying authentication broker functionality. Эта функция встроена в Microsoft Authenticator и приложение корпоративного портала Intune.This functionality is built into the Microsoft Authenticator and Intune Company Portal apps.

Примечание

Рекомендации, описанные в этом документе, предполагают, что одно из этих приложений (Microsoft Authenticator или корпоративный портал Intune) было развернуто на устройства iOS или Android.The recommendations described in this document assume that one of these apps (Microsoft Authenticator or Intune Company Portal) has been deployed to your users' iOS or Android devices.

многофакторную идентификацию;Multi-factor authentication

Многофакторная идентификация (MFA) обеспечивает высокий уровень доверия к субъекту проверки подлинности, так как субъект предоставляет несколько подтверждений или доказательств его личности.Multi-factor Authentication (MFA) provides a high level of trust about the subject of authentication, because the subject provides multiple proofs or pieces of evidence about its identity. Доказательствами могут быть готовые секреты, которые известны только субъекту и руководству, или физический объект, обладать которым может только субъект.The proofs can be pre-established secrets that only the subject and the authority are aware of or a physical entity that only the subject is expected to possess. Как правило, многофакторная идентификация выполняется поэтапно.MFA is typically performed in stages. Сначала она устанавливает личность с помощью паролей, после чего ей требуется другой (менее подверженный вредоносным атакам) метод проверки подлинности или наоборот.First it establishes the identity using passwords, and then it requires a different (less prone to malicious attacks) authentication method as the second factor, or vice versa.

Разное руководство может по-разному понимать многофакторную идентификацию или строгую проверку подлинности.Different authorities may have a slightly different interpretation of MFA, or strong authentication. Например, некоторые руководители (или точнее, администраторы, настраивающие политики для этих руководителей) могут интерпретировать проверку подлинности на основе физических смарт-карт как многофакторную идентификацию.For example, some authorities (or more specifically the admins configuring policy on those authorities) may choose to interpret the physical smartcard-based authentication as MFA. Такое определение может применяться, даже если, строго говоря, проверка подлинности на основе смарт-карты является одноэтапной идентификацией.This can happen even though strictly speaking smartcard authentication is a single stage authentication.

Многофакторной идентификацией может считаться сочетание требования физической смарт-карты и требования ввода ПИН-кода (секрета) для использования смарт-карты.The combination of requiring a physical smartcard and the requirement to enter a PIN (secret) to use smartcard can be interpreted as MFA. Однако организации могут занимать менее строгую позицию с точки зрения частоты выполнения проверки подлинности.However, organizations might choose to be more lenient in terms of how often more onerous authentication methods are required to be performed. В таких случаях стандартные проверки, осуществляемые между более строгими проверками подлинности, могут признаваться допустимыми для ресурсов, которым обычно требуется строгая проверка подлинности.In these cases, normal authentications, that take place between stronger authentications,can be considered to be valid for resources that typically require strong authentication. Например, в некоторых организациях часто может быть приемлемым такой подход, когда пользователь должен проходить многофакторную идентификацию каждые несколько часов или дней.For example, in some organizations it may be acceptable to require a user to do MFA every few hours or days. Время зависит от конфиденциальности защищаемых ресурсов и не меняется, пока из физического расположения пользователя предпринимается попытка получить доступ к ресурсу.The time depends on the sensitivity of resources they are protecting and as long as the physical location of the user attempting to access a resource, does not change.

Azure AD и AD FS используют утверждения многофакторной идентификации, чтобы указать, выполняется ли проверка подлинности с помощью многофакторной проверки MFA.Azure AD and AD FS use the MFA claim to indicate whether the authentication is performed with MFA. По умолчанию Azure AD выдает маркеры с утверждением MFA, если проверка подлинности выполняется с использованием Azure MFA или Windows Hello для бизнеса.By default, Azure AD issues tokens with MFA claim when authentication is done with Azure MFA or Windows Hello for Business. В сценариях федерации Azure AD учитывает утверждение MFA от поставщиков федеративных удостоверений, например служб федерации Active Directory, и передает утверждение MFA в маркерах.In federation scenarios, Azure AD honors the MFA claim from federated identity providers such as AD FS and carries over the MFA claim in the tokens.

В этом разделе рассматриваются рекомендуемые конфигурации клиента платформы по умолчанию, обеспечивающие оптимальный единый вход для пользователей, а также технические требования для условного доступа.This section describes the default platform client configurations we recommend to provide the best SSO experience to your users, as well as the technical pre-requisites for conditional access.

Устройства WindowsWindows devices

Рекомендуется Windows 10 (версия 1703 или более поздние), так как платформа Azure обеспечивает максимально удобные возможности единого входа в локальной среде и Azure AD.We recommend the Windows 10 (version 1703 or later), as Azure is designed to provide the smoothest SSO experience possible for both on-premises and Azure AD. Выданные организацией или учебным заведением устройства должны быть настроены для прямого присоединения к Azure AD или, если организация использует локальное присоединение к домену AD, эти устройства должны быть настроены для автоматической регистрации в Azure AD.Work or school issued devices should be configured to join Azure AD directly or if the organization uses on-premises AD domain join, those devices should be configured to automatically and silently register with Azure AD.

При использовании устройств BYOD Windows пользователи могут нажать кнопку "Добавить рабочую или учебную учетную запись".For BYOD Windows devices, users can use "Add work or school account". Обратите внимание, что пользователи браузера Chrome в Windows 10 должны установить расширение, чтобы выполнять вход так же легко, как пользователи Edge или IE.Note that Chrome browser users on Windows 10 need to install an extension so those users can get the same smooth sign-in experience as Edge/IE. Кроме того, если в организации есть устройства Windows 7, присоединенные к домену, можно установить Microsoft Workplace Join для компьютеров без Windows 10, чтобы зарегистрировать устройства в Azure AD.Also, if your organization has domain joined Windows 7 devices, you can install Microsoft Workplace Join for non-Windows 10 computers package to register the devices with Azure AD.

Устройства iOSiOS devices

Перед развертыванием политик условного доступа или многофакторной идентификации рекомендуется установить приложение Microsoft Authenticator на устройства пользователей.We recommend installing the Microsoft Authenticator app on user devices before deploying conditional access or MFA policies. Как минимум, приложение должно быть установлено, когда пользователям предлагается зарегистрировать устройства в Azure AD путем добавления рабочей или учебной учетной записи или когда они устанавливают приложение корпоративного портала Intune для регистрации устройств в системе управления.At a minimum, the app should be installed when users are asked to register their device with Azure AD by adding a work or school account or when they install the Intune company portal app to enroll their device into management. Это зависит от политики условного доступа.This depends on the configured conditional access policy.

Устройства AndroidAndroid devices

Перед развертыванием политик условного доступа или при необходимости во время определенных попыток проверки подлинности рекомендуется установить приложение корпоративного портала Intune и приложение Microsoft Authenticator.We recommend users install the Intune Company Portal app and Microsoft Authenticator app before conditional access policies are deployed or when required during certain authentication attempts. После установки приложения пользователям может быть предложено зарегистрироваться в Azure AD и зарегистрировать устройства в Intune.After app installation, users may be asked to register with Azure AD or enroll their device with Intune. Это зависит от политики условного доступа.This depends on the configured conditional access policy.

Также рекомендуется стандартизовать корпоративные устройства (COD) у изготовителей оборудования для версий, поддерживающих Android for Work или Samsung Knox, чтобы разрешить управление почтовыми учетными записями и их защиту с помощью политики Intune MDM.We also recommend that corporate-owned devices (COD) are standardized on OEMs and versions that support Android for Work or Samsung Knox to allow mail accounts to be managed and protected by Intune MDM policy.

Рекомендации по безопасностиSecurity guidelines

Этот раздел содержит общие рекомендации, которых следует придерживаться при реализации советов, приведенных в следующих разделах.This section contains general security guidelines that should be followed when implementing any of the recommendations provided in later sections.

Баланс между безопасностью и производительностьюSecurity and productivity trade-offs

Необходимо обеспечить баланс между безопасностью и производительностью.There is a trade-off to be made between security and productivity. Понять этот баланс поможет широко используемая триада безопасности "Безопасность-функциональность-удобство использования":To help understand these trade-offs, the Security-Functionality-Usability/Ease of Use (SFU) security triad is widely used:

Баланс между безопасностью и производительностью

Предоставленные рекомендации основаны на следующих принципах триады безопасности SFU:The recommendations are have provided are based on the following SFU security triad principles:

  • Знание аудитории — проявление гибкости в соответствии с должностью или уровнем безопасностиKnow the audience - Be flexible by job function/security bar
  • Своевременное применение политики безопасности и обеспечение ее значимостиApply security policy just in time and ensure it is meaningful

Администраторы и пользователиAdministrators versus users

Рекомендуется создавать группы безопасности, содержащие всех пользователей с учетными записями администратора или правами на получение привилегий учетной записи администратора на временной основе.We recommend creating security groups that contain all the users who have administrative accounts or are eligible to receive an administrative account privileges on a temporary basis. Затем эти группы безопасности следует использовать для определения политик условного доступа для администраторов Azure AD и Office 365.These security groups should then be used to define conditional access policies specific to Azure AD and Office 365 administrators.

В рекомендуемых политиках учитываются привилегии, связанные с учетной записью.The provided policy recommendations consider the privileges associated with an account. Роли администратора Office 365 имеют значительно больше прав доступа к службам Office 365.Office 365 administrator roles have substantially more privileges to Office 365 services. Таким образом, рекомендации относительно этих учетных записей являются более жесткими, чем для обычных учетных записей.Thus, our policy recommendations for these accounts are more stringent than for regular user accounts. Все политики, которые ссылаются на администраторов, являются рекомендуемыми политиками для административных учетных записей Office 365.All the policies that refer to Administrators indicate the recommended policy for Office 365 administrative accounts.

Сокращение количества учетных записей с постоянным административным доступомReduce the number of accounts with persistent admin access

Azure AD Privileged Identity Management позволяет уменьшить количество постоянных административных учетных записей.Use Azure AD Privileged Identity Management to reduce the number of persistent administrative accounts. Кроме того, рекомендуется, чтобы администраторы Office 365 имели отдельную учетную запись для обычного использования и применяли свою административную учетную запись для выполнения должностных задач.In addition, we recommend that Office 365 administrators have a separate user account for regular non-administrative use and only use their administrative account when necessary to complete a task associated with their job function.

Уровни безопасности и защитыTiers of security and protection

Большинство организаций предъявляет особые требования, касающиеся безопасности и защиты данных.Most organizations have specific requirements regarding security and data protection. Эти требования зависят от отраслевого сегмента и должностных обязанностей в организации.These requirements vary by industry segment and by job functions within organizations. Например, юридическому отделу и администраторам Office 365 могут потребоваться дополнительные средства безопасности и защиты информации для сообщений электронной почты, которые не нужны пользователям других бизнес-подразделений.For example, your legal department and Office 365 administrators might require additional security and information protection controls around their email correspondence that are not required for other business unit users.

Кроме того, в каждой отрасли существует собственный набор специализированных нормативных предписаний.Each industry also has their own set of specialized regulations. Вместо предоставления списка всех возможных средств безопасности или рекомендаций для каждого отраслевого сегмента или должности были разработаны рекомендации для трех различных уровней безопасности и защиты, которые могут применяться с учетом степени детализации ваших потребностей: базовый, конфиденциальный и строго регулируемый.Rather than providing a list of all possible security options or a recommendation per industry segment or job function, recommendations have been provided for three different tiers of security and protection that can be applied based on the granularity of your needs: baseline, sensitive, and highly regulated.

Базовый уровень.Baseline. Рекомендуется установить минимальный стандарт для защиты данных, а также удостоверений и устройств, обращающихся к данным.We recommend that you establish a minimum standard for protecting data, as well as the identities and devices that access your data. Для обеспечения усиленной защиты по умолчанию, соответствующей потребностям многих организаций, можно следовать базовым рекомендациям.Baseline recommendations can be followed to provide strong default protection that meets the needs of many organizations.

Конфиденциальный уровень.Sensitive. Некоторые клиенты располагают данными, которые должны быть защищены на более высоком уровне, или им необходимо обеспечить высокий уровень защиты всех данных.Some customers have a subset of data that must be protected at higher levels or require all data to be protected at these higher levels. Можно применить усиленную защиту ко всем или конкретным наборам данных в среде Office 365.You can apply increased protection to all or specific data sets in your Office 365 environment. Рекомендуется защищать удостоверения и устройства, обращающиеся к конфиденциальным данным, с помощью сравнимых уровней безопасности.We recommend protecting identities and devices that access sensitive data with comparable levels of security.

Строго регулируемый уровень.Highly regulated. В некоторых организациях может существовать весьма небольшой объем данных, являющихся строго засекреченными, регулируемыми или представляющими коммерческую тайну.Some organizations may have a very small amount of data that is highly classified, trade secret, or regulated data. Корпорация Майкрософт предоставляет возможности, позволяющие организациям соответствовать этим требованиям, включая дополнительную защиту для удостоверений и устройств.Microsoft provides capabilities to help organizations meet these requirements, including added protection for identities and devices.

Рекомендации относительно механизма защиты по умолчаниюDefault protection mechanism recommendations

В следующей таблице содержатся рекомендации относительно механизма защиты по умолчанию для всех ранее определенных уровней безопасности и защиты.The following table contains default protection mechanism recommendations for each of the previously defined security and protection tiers:

Механизм защитыProtection mechanism Базовая версияBaseline КонфиденциальныйSensitive Строго регулируемый уровеньHighly regulated
Применять MFAEnforce MFA При среднем или более высоком уровне риска при входеOn medium or above sign-in risk При низком или более высоком уровне риска при входеOn low or above sign-in risk Для всех новых сеансовOn all new sessions
Применять политику смены паролейEnforce Password Change Для пользователей с высоким уровнем рискаFor high risk users Для пользователей с высоким уровнем рискаFor high risk users Для пользователей с высоким уровнем рискаFor high risk users
Применять защиту приложений IntuneEnforce Intune Application Protection ДаYes ДаYes ДаYes
Применять регистрацию Intune (COD)Enforce Intune Enrollment (COD) Требовать соответствующее требованиям или присоединенное к домену устройствоRequire a compliant or domain joined device Требовать соответствующее требованиям или присоединенное к домену устройствоRequire a compliant or domain joined device Требовать соответствующее требованиям или присоединенное к домену устройствоRequire a compliant or domain joined device

Владение устройствамиDevice ownership

В приведенной выше таблице демонстрируется тенденция многих организаций поддерживать сочетание корпоративных (COD) и личных (BYOD) устройств для повышения производительности сотрудников с использованием мобильных приложений и устройств.The above table reflects the trend for many organizations to support a mix of corporate-owned devices (COD) as well as personal or bring-your-own devices (BYOD) to enable mobile productivity across their workforces. Политики защиты приложений Intune предотвращают утечку сообщений электронной почты из мобильного приложения Outlook и других мобильных приложений Office на корпоративных и личных устройствах.Intune App Protection Policies ensure that email is protected from exfiltrating out of the Outlook mobile app and other Office mobile apps, on both COD and BYOD.

Чтобы применить дополнительные средства защиты и управления к корпоративным устройствам, они должны находиться под управлением Intune или входить в состав домена.Corporate-owned devices are required to be managed by Intune or domain-joined to apply additional protections and control. В зависимости от уровня конфиденциальности данных организация может запретить BYOD для заполнений конкретного пользователя или конкретных приложений.Depending on data sensitivity, your organization may choose to not allow BYOD for specific user populations or specific apps.

Дальнейшие действияNext steps

Общие рекомендуемые политики удостоверений и доступа к устройствамDeploy common identity and device access policies