推荐的安全策略和配置Recommended security policies and configurations

简介Introduction

尽管没有对所有客户环境都适用的单个最佳建议,但本文的最佳做法和建议介绍了 Microsoft 一般建议,让用户了解如何在 Microsoft 云中应用策略和配置,确保员工安全高效地工作。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 365Microsoft 企业移动性 + 安全性(其中包括 Azure Active Directory(标识)、Microsoft Intune(设备管理)和 Azure 信息保护(数据保护))的企业基础结构架构师和 IT 专业人员。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).

客户环境:推荐的策略适用于完全在 Microsoft 云内运营的企业组织,以及跨本地和 Microsoft 云部署了基础结构的客户。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.

假设:提供的许多建议都依赖仅企业移动性 + 安全性 (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. 使用这些建议作为指南,了解 Microsoft 和 Secure Productive Enterprise 团队如何考虑正确应用策略。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 企业版文档主页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:

最终用户单一登录体验

开始身份验证时,客户端将过去获得的凭据(如用户名和密码)和/或任何 SSO 项目提交到 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. SSO 项目可以是浏览器的会话令牌,也可以是富应用程序的刷新令牌。An SSO artifact can be a session token for a browser or a refresh token for rich applications.

在 Azure AD 中验证了凭据和/或 SSO 项目,并评估了所有适用策略后,会为资源提供程序(在上图中为 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。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 建立一个 SSO 会话。When a user authenticates with Azure AD, an SSO session is established with the user’s browser and Azure AD. SSO 令牌以 Cookie 形式表示此会话。The SSO token, in the form of a cookie, represents this session. Azure AD 使用两种 SSO 会话令牌:持久型和非持久型。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 ConnectOAuth 2.0),可通过将刷新令牌用作 SSO 项目来启用 SSO(前文所述的 SSO Cookie 除外)。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. 此外,还可能有包含数据(例如 MFA 有效期)的其它声明。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. 客户端将继续执行此 SSO 过程,直到刷新令牌最大非活动时间设置过期、刷新令牌最长时间过期,或身份验证和身份验证策略要求发生更改。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. 实际上它表示 SSO 过程中发生的中断,客户端之前未遇到此中断。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 后,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. 例如,如果配置了条件访问策略,来自 Extranet 位置的身份验证尝试需要完成 MFA。For example, if a conditional access policy is configured so that MFA is required for authentication attempts coming from extranet locations. 在这种情况下,当从 Extranet 访问资源时,用户有时可能不会接收到预期的 MFA 提示。In this case, users might sometimes not receive the expected MFA prompt when accessing a resource from extranet. 出现此情况可能是因为,在离开 Intranet 不久前,用户可能执行了 MFA。A possible reason for this is that the user could have previously performed MFA shortly before leaving the intranet. 因此,其访问令牌中具有有效的 MFA 声明。Therefore, they have a valid MFA claim in their access token. 由于此 MFA 声明满足策略要求,因此 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. 如前文所述,过期的令牌也是导致 SSO 体验中断的原因之一。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. 从上文可推断出,捕获定义 SSO 会话的分布图十分困难。As can be inferred from above, defining the contours of an SSO session is harder to capture. 例如,种类繁多的应用虽然看起来是毫无关联的不同因素,但却会影响 SSO 会话的生存期。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

到目前为止,本文讨论了 SSO 在单个客户端上下文中的工作方式,但这不足以在单个应用中体验 SSO。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. 用户还需要在不相关的应用程序(包括内部开发的业务线 (LOB) 应用程序)之间访问。Users also need access across unrelated applications, including internally developed line of business (LOB) applications.

传统上,已加入域的 Windows 设备使用 Windows 集成身份验证 (Kerberos) 实现跨多个应用程序和资源的高水平 SSO 体验。Traditionally, domain joined Windows devices, using Windows Integrated Authentication (Kerberos), achieve a high degree of SSO experience across multiple applications and resources. 这些应用包括受支持的浏览器,如 Internet Explorer 或 Microsoft 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). 然后,这些实体可以允许对其它客户端应用程序进行中转身份验证访问,以便它们也能提供无缝 SSO 体验。The entities can then allow brokered authentication access to other client applications, so that they can also offer a seamless SSO experience. 对于使用 iOSAndroid 设备的 Office 365 用户,已通过应用身份验证中转站功能完成了额外的工作,减少了所需身份验证次数。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.

备注

本文所述建议假设已在用户的 iOS 或 Android 设备上部署了其中一个应用(Microsoft Authenticator 或 Intune 公司门户)。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 通常分阶段执行。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.

不同的颁发机构对 MFA 或强身份验证的解释可能略有不同。Different authorities may have a slightly different interpretation of MFA, or strong authentication. 例如,某些颁发机构(或更具体地说,在这些颁发机构中配置策略的管理员)可能会将基于物理智能卡的身份验证解释为 MFA。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.

既要求使用物理智能卡,还要求输入 PIN(密码)来使用智能卡,这种组合也可被解释为 MFA。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. 例如,在某些组织中,要求用户每隔几小时或几天执行一次 MFA 是可以接受的。For example, in some organizations it may be acceptable to require a user to do MFA every few hours or days. 只要尝试访问资源的用户的物理位置保持不变,则执行 MFA 的时间间隔取决于所保护资源的敏感性。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 声明来指示是否使用 MFA 来执行身份验证。Azure AD and AD FS use the MFA claim to indicate whether the authentication is performed with MFA. 默认情况下,当使用 Azure MFAWindows Hello 企业版完成身份验证时,Azure AD 使用 MFA 声明来颁发令牌。By default, Azure AD issues tokens with MFA claim when authentication is done with Azure MFA or Windows Hello for Business. 在联合方案中,Azure AD 遵循联合标识提供者(如 AD FS)发出的 MFA 声明,并将 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.

本部分介绍了我们为了向用户提供最佳 SSO 体验而推荐的默认平台客户端配置,以及条件访问的技术先决条件。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.

Windows 设备Windows devices

由于 Azure 旨在为本地和 Azure AD 提供尽可能流畅的 SSO 体验,因此建议使用 Windows 10(版本 1703 或更高版本)。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 ADWork 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". 请注意,Windows 10 上的 Chrome 浏览器用户需要安装扩展,以便获得与 Microsoft 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 设备已加入域,可以安装非 Windows 10 计算机的 Microsoft Workplace Join 包以向 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.

iOS 设备iOS devices

建议在部署条件访问或 MFA 策略之前,在用户设备上安装 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.

Android 设备Android 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 的标准化 OEM 和版本,以便通过 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. 为了帮助理解这些权衡,广泛使用了安全性、功能性、可用性/易用性 (SFU) 安全性三联原则: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 提供多种功能,帮助组织满足相关要求,包括为标识和设备添加保护。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 BaselineBaseline 敏感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
强制执行 Intune 应用程序保护Enforce 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 移动应用中泄露(在 COD 和 BYOD 上都是如此)。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