Alăturați-vă nouă în noiembrie pentru a explora inovațiile în inteligența artificială, pentru a vă îmbunătăți setul de competențe și pentru a vă extinde rețeaua.
Common security policies for Microsoft 365 organizations
Articol
Organizations have lots to worry about when deploying Microsoft 365 for their organization. The Conditional Access, app protection, and device compliance policies referenced in this article are based on Microsoft's recommendations and the three guiding principles of Zero Trust:
Verify explicitly
Use least privilege
Assume breach
Organizations can take these policies as is or customize them to fit their needs. If possible, test your policies in a non-production environment before rolling out to your production users. Testing is critical to identify and communicate any possible effects to your users.
We group these policies into three protection levels based on where you are on your deployment journey:
Starting point - Basic controls that introduce multifactor authentication, secure password changes, and app protection policies.
Enterprise - Enhanced controls that introduce device compliance.
Specialized security - Policies that require multifactor authentication every time for specific data sets or users.
The following diagram shows which level of protections each policy applies to and whether the policies apply to PCs or phones and tablets, or both categories of devices.
Requiring the use of multifactor authentication (MFA) is recommended before enrolling devices in Intune to assure that the device is in the possession of the intended user. You must enroll devices in Intune before you can enforce device compliance policies.
Prerequisites
Permissions
Users who will manage Conditional Access policies must be able to sign in to the Azure portal as at least a Conditional Access Administrator.
Users who will manage app protection and device compliance policies must be able to sign in to Intune as at least an Intune Administrator.
Those users who only need to view configurations can be assigned the Security Reader or Global Reader roles.
Ensure your users register for multifactor authentication prior to requiring its use. If you have licenses that include Microsoft Entra ID P2, you can use the MFA registration policy within Microsoft Entra ID Protection to require that users register. We provide communication templates, you can download and customize, to promote registration.
Groups
All Microsoft Entra groups used as part of these recommendations must be created as a Microsoft 365 group not a Security group. This requirement is important for the deployment of sensitivity labels when securing documents in Microsoft Teams and SharePoint later on. For more information, see the article Learn about groups and access rights in Microsoft Entra ID
Assigning policies
Conditional Access policies may be assigned to users, groups, and administrator roles. Intune app protection and device compliance policies may be assigned to groups only. Before you configure your policies, you should identify who should be included and excluded. Typically, starting point protection level policies apply to everybody in the organization.
Here's an example of group assignment and exclusions for requiring MFA after your users have completed user registration.
Microsoft Entra Conditional Access policy
Include
Exclude
Starting point
Require multifactor authentication for medium or high sign-in risk
All users
Emergency access accounts
Conditional Access exclusion group
Enterprise
Require multifactor authentication for low, medium, or high sign-in risk
Executive staff group
Emergency access accounts
Conditional Access exclusion group
Specialized security
Require multifactor authentication always
Top Secret Project Buckeye group
Emergency access accounts
Conditional Access exclusion group
Be careful when applying higher levels of protection to groups and users. The goal of security isn't to add unnecessary friction to the user experience. For example, members of the Top Secret Project Buckeye group will be required to use MFA every time they sign in, even if they aren't working on the specialized security content for their project. Excessive security friction can lead to fatigue.
You may consider enabling passwordless authentication methods, like Windows Hello for Business or FIDO2 security keys to reduce some friction created by certain security controls.
Emergency access accounts
All organizations should have at least one emergency access account that is monitored for use and excluded from policies. These accounts are only used in case all other administrator accounts and authentication methods become locked out or otherwise unavailable. More information can be found in the article, Manage emergency access accounts in Microsoft Entra ID.
Exclusions
A recommended practice is to create a Microsoft Entra group for Conditional Access exclusions. This group gives you a means to provide access to a user while you troubleshoot access issues.
Avertisment
This group is recommended for use as a temporary solution only. Continuously monitor and audit this group for changes and be sure the exclusion group is being used only as intended.
To add this exclusion group to any existing policies:
Users must perform MFA anytime they sign in to your organizations services
Microsoft 365 E3 or E5
App protection policies
App protection policies define which apps are allowed and the actions they can take with your organization's data. There are many choices available and it may be confusing to some. The following baselines are Microsoft's recommended configurations that may be tailored to your needs. We provide three templates to follow, but think most organizations will choose levels 2 and 3.
Level 2 enterprise enhanced data protection – Microsoft recommends this configuration for devices where users access sensitive or confidential information. This configuration is applicable to most mobile users accessing work or school data. Some of the controls may affect user experience.
Level 3 enterprise high data protection – Microsoft recommends this configuration for devices run by an organization with a larger or more sophisticated security team, or for specific users or groups who are at uniquely high risk (users who handle highly sensitive data where unauthorized disclosure causes considerable material loss to the organization). An organization likely to be targeted by well-funded and sophisticated adversaries should aspire to this configuration.
Create app protection policies
Create a new app protection policy for each platform (iOS and Android) within Microsoft Intune using the data protection framework settings by:
To create device compliance policies, sign in to the Microsoft Intune admin center, and navigate to Devices > Compliance policies > Policies. Select Create Policy.
The starting point and enterprise protection levels map closely with the level 2 enhanced security settings.
The specialized security protection level maps closely to the level 3 high security settings.
Compliance settings for personally enrolled devices
Personal basic security (Level 1) – Microsoft recommends this configuration as the minimum security configuration for personal devices where users access work or school data. This configuration is done by enforcing password policies, device lock characteristics, and disabling certain device functions, like untrusted certificates.
Personal enhanced security (Level 2) – Microsoft recommends this configuration for devices where users access sensitive or confidential information. This configuration enacts data sharing controls. This configuration is applicable to most mobile users accessing work or school data on a device.
Personal high security (Level 3) – Microsoft recommends this configuration for devices used by specific users or groups who are uniquely high risk (users who handle highly sensitive data where unauthorized disclosure causes considerable material loss to the organization). This configuration enacts stronger password policies, disables certain device functions, and enforces extra data transfer restrictions.
Compliance settings for automated device enrollment
Supervised basic security (Level 1) – Microsoft recommends this configuration as the minimum security configuration for supervised devices where users access work or school data. This configuration is done by enforcing password policies, device lock characteristics, and disabling certain device functions, like untrusted certificates.
Supervised enhanced security (Level 2) – Microsoft recommends this configuration for devices where users access sensitive or confidential information. This configuration enacts data sharing controls and blocks access to USB devices. This configuration is applicable to most mobile users accessing work or school data on a device.
Supervised high security (Level 3) – Microsoft recommends this configuration for devices used by specific users or groups who are uniquely high risk (users who handle highly sensitive data where unauthorized disclosure causes considerable material loss to the organization). This configuration enacts stronger password policies, disables certain device functions, enforces extra data transfer restrictions, and requires apps to be installed through Apple's volume purchase program.
Enrollment and compliance settings for Android
Android Enterprise supports several enrollment scenarios, two of which are covered as part of this framework:
Android Enterprise work profile – this enrollment model is typically used for personally owned devices, where IT wants to provide a clear separation boundary between work and personal data. Policies controlled by IT ensure that the work data can't be transferred into the personal profile.
Android Enterprise fully managed devices – these devices are corporate-owned, associated with a single user, and used exclusively for work and not personal use.
The Android Enterprise security configuration framework is organized into several distinct configuration scenarios, providing guidance for work profile and fully managed scenarios.
The starting point and enterprise protection levels map closely with the level 2 enhanced security settings.
The specialized security protection level maps closely to the level 3 high security settings.
Compliance settings for Android Enterprise work profile devices
Because of the settings available for personally owned work profile devices, there's no basic security (level 1) offering. The available settings don't justify a difference between level 1 and level 2.
Work profile enhanced security (Level 2)– Microsoft recommends this configuration as the minimum security configuration for personal devices where users access work or school data. This configuration introduces password requirements, separates work and personal data, and validates Android device attestation.
Work profile high security (Level 3) – Microsoft recommends this configuration for devices used by specific users or groups who are uniquely high risk (users who handle highly sensitive data where unauthorized disclosure causes considerable material loss to the organization). This configuration introduces mobile threat defense or Microsoft Defender for Endpoint, sets the minimum Android version, enacts stronger password policies, and further restricts work and personal separation.
Compliance settings for Android Enterprise fully managed devices
Fully managed basic security (Level 1) – Microsoft recommends this configuration as the minimum security configuration for an enterprise device. This configuration is applicable to most mobile users accessing work or school data. This configuration introduces password requirements, sets the minimum Android version, and enacts certain device restrictions.
Fully managed enhanced security (Level 2) – Microsoft recommends this configuration for devices where users access sensitive or confidential information. This configuration enacts stronger password policies and disables user/account capabilities.
Fully managed high security (Level 3) - Microsoft recommends this configuration for devices used by specific users or groups who are uniquely high risk. These users may handle highly sensitive data where unauthorized disclosure may cause considerable material loss to the organization. This configuration increases the minimum Android version, introduces mobile threat defense or Microsoft Defender for Endpoint, and enforces extra device restrictions.
Recommended compliance settings for Windows 10 and later
For Device health > Windows Health Attestation Service evaluation rules, see this table.
Property
Value
Require BitLocker
Require
Require Secure Boot to be enabled on the device
Require
Require code integrity
Require
For Device properties, specify appropriate values for operating system versions based on your IT and security policies.
For Configuration Manager Compliance, if you are in a co-managed environment with Configuration Manager select Require otherwise select Not configured.
For System security, see this table.
Property
Value
Require a password to unlock mobile devices
Require
Simple passwords
Block
Password type
Device default
Minimum password length
6
Maximum minutes of inactivity before a password is required
15 minutes
Password expiration (days)
41
Number of previous passwords to prevent reuse
5
Require password when device returns from idle state (Mobile and Holographic)
Require
Require encryption of data storage on device
Require
Firewall
Require
Antivirus
Require
Antispyware
Require
Microsoft Defender Antimalware
Require
Microsoft Defender Antimalware minimum version
Microsoft recommends versions no more than five behind from the most recent version.
Microsoft Defender Antimalware signature up to date
Use this policy along with Microsoft Entra password protection, which detects and blocks known weak passwords and their variants in addition to terms specific to your organization. Using Microsoft Entra password protection ensures that changed passwords are stronger.
Require approved apps and app protection policies
You must create a Conditional Access policy to enforce the app protection policies created in Intune. Enforcing app protection policies requires a Conditional Access policy and a corresponding app protection policy.
To create a Conditional Access policy that requires approved apps and APP protection, follow the steps in Require approved client apps or app protection policy with mobile devices. This policy only allows accounts within mobile apps protected by app protection policies to access Microsoft 365 endpoints.
Blocking legacy authentication for other client apps on iOS and Android devices ensures that these clients can't bypass Conditional Access policies. If you're following the guidance in this article, you've already configured Block clients that don't support modern authentication.
Require compliant PCs and mobile devices
The following steps will help create a Conditional Access policy to require devices accessing resources be marked as compliant with your organization's Intune compliance policies.
Atenție
Make sure that your device is compliant before enabling this policy. Otherwise, you could get locked out and be unable to change this policy until your user account has been added to the Conditional Access exclusion group.
Sign in to the Azure portal.
Browse to Microsoft Entra ID > Security > Conditional Access.
Select New policy.
Give your policy a name. We recommend that organizations create a meaningful standard for the names of their policies.
Under Assignments, select Users or workload identities.
Under Include, select All users.
Under Exclude, select Users and groups and choose your organization's emergency access or break-glass accounts.
Under Cloud apps or actions > Include, select All cloud apps.
If you must exclude specific applications from your policy, you can choose them from the Exclude tab under Select excluded cloud apps and choose Select.
Under Access controls > Grant.
Select Require device to be marked as compliant.
Select Select.
Confirm your settings and set Enable policy to On.
Select Create to create to enable your policy.
Notă
You can enroll your new devices to Intune even if you select Require device to be marked as compliant for All users and All cloud apps in your policy. Require device to be marked as compliant control does not block Intune enrollment and the access to the Microsoft Intune Web Company Portal application.
Subscription activation
Organizations using the Subscription Activation feature to enable users to "step-up" from one version of Windows to another, may want to exclude the Universal Store Service APIs and Web Application, AppID 45a330b1-b1ec-4cc1-9161-9f03992aa49f from their device compliance policy.
Conditional Access gives a fine granularity of control over which users can do specific activities, access which resources, and how to ensure data and systems are safe.