![\"Microsoft](\"https:\/\/www.microsoft.com\/insidetrack\/blog\/uploads\/prod\/2021\/10\/ms-digital-technical-stories-300x112.png\")
Identity-driven security is a core pillar of our Zero Trust model.<\/p>\nIdentity-driven security is a core pillar of our Zero Trust model.<\/p>\n
Identities define the Zero Trust security boundary, and we use identity as the primary factor in how we allow access to corporate resources. When an identity tries to access any resource, we verify that identity with strong authentication, and we ensure that access is compliant and follows the access patterns typical for that identity. We also confirm that the identity follows least-privilege access principles.<\/p>\n
With these processes in place, verified identity contributes to the broader framework for Zero Trust, alongside the other pillars of verified devices, verified access, and verified services.<\/p>\n
<\/p>\n [Check out verifying devices in a Zero Trust model<\/a>. | Read more about implementing a Zero Trust security model at Microsoft<\/a>.<\/em>]<\/em><\/p>\n A unified identity environment is crucial to verified identity in our Zero Trust model. To enable a single user identity for authentication and offer a unified experience, we integrated on-premises Windows Server Active Directory forests with Microsoft Azure Active Directory (Azure AD). Azure AD provides a centralized, cloud-based identity directory on which all our identity-related processes depend. We use Azure AD Connect and Microsoft Azure Active Directory Federation Services (AD FS) to unify identity data within Azure AD so that Microsoft Azure\u2013based applications can confirm the individual user attributes that make up an identity\u2014location, organization, or job title, for example.<\/p>\n Every employee or partner who needs access to corporate resources is assigned an identity that is synchronized to Microsoft Azure AD and gives the user access to corporate resources, Microsoft Office 365, Microsoft software as a service (SaaS) applications, and third-party SaaS and platform as a service (PaaS) applications.<\/p>\n A key part of our business is working closely with partner companies. To enable more seamless collaboration with our partners, we’re pioneering a new multifactor authentication feature to mitigate multiple credential prompts that some users experienced. Previously, external users who had already authenticated with a second factor in their home tenant were prompted again for a different two-factor authentication to access internal Microsoft resources. Now, if our external partner has already signed in to their home tenant using multifactor authentication, they won\u2019t encounter a separate multifactor authentication prompt when accessing our Microsoft resources.<\/p>\n Our internal security team and the Microsoft Digital Employee Experience team\u2019s approach to verified identity is rooted in three primary goals specifically related to human-based identities as they\u2019re stored in our unified identity environment:<\/p>\n Enforcing strong identity depends on a centralized, modern, cloud-based directory solution, which we have in Microsoft Azure AD. Azure AD helps us bridge our cloud and on-premises identities by using Microsoft Azure AD Connect and AD FS, and it provides key functionality for enforcing strong identity across our hybrid environment:<\/p>\n Reducing password dependency to eliminate password usage has been in process at Microsoft for some time. Deploying a companywide strategy for eliminating passwords wasn\u2019t easy, but it also wasn\u2019t as complicated as many organizations might think it is. The goal isn\u2019t to eliminate password data but to reduce the need for the user to repeatedly use that password as part of the authentication process. We\u2019re working toward eliminating passwords at Microsoft by using several platforms and technologies:<\/p>\n Implementing least-privilege access reduces the attack surface area for our identities with elevated privileges and ensures that our employees are always granted the level of access they require to perform the tasks their role requires. By default, identities begin with no access. In the least-privilege access model, systems grant access only when needed. Applications, services, and infrastructure only provide the minimum set of access required by their users. Our approach to least-privilege access involves several focal points:<\/p>\n The first step in implementing least-privilege was the identification and classification of those roles that absolutely required elevated access. However, not all elevated-privilege accounts are created equal. Limiting the attack surface visible to potential aggressors depends not only on reducing the number of elevated-privilege accounts. It also relies on only providing elevated-privilege accounts with the least-privilege access needed to get their respective jobs done.<\/p>\n We can provide conditional access to applications with AD FS rules. We can vary the granularity of how we enforce multifactor authentication at an application level. AD FS is flexible and allows us to designate people or groups that can access an application, and how they must authenticate when they\u2019re on or outside the corporate network. Most users who access applications from the corporate network are allowed single-factor authentication, while users who access applications from the internet require multifactor authentication. Some applications are so critical that they require multifactor authentication even when the user accesses them from the corporate network.<\/p>\n Identity-driven security is a core pillar of our Zero Trust model. Identities define the Zero Trust security boundary, and we use identity as the primary factor in how we allow access to corporate resources. When an identity tries to access any resource, we verify that identity with strong authentication, and we ensure that access is […]<\/p>\n","protected":false},"author":133,"featured_media":8834,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_hide_featured_on_single":false,"_show_featured_caption_on_single":true,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[1],"tags":[407,95],"coauthors":[646],"class_list":["post-8832","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized","tag-enterprise-mobility-and-security","tag-security","program-microsoft-digital-technical-stories","m-blog-post"],"yoast_head":"\n![\"The](\"https:\/\/www.microsoft.com\/insidetrack\/blog\/uploads\/prod\/2022\/11\/10193-img-001.png\")
Unifying the identity environment<\/h2>\n
Goals for verifying identity in Zero Trust<\/h2>\n
\n
Enforcing strong identity<\/h2>\n
\n
Reducing dependency on passwords<\/h2>\n
\n
Limiting access to data with least-privilege access<\/h2>\n
\n
![\"Key](\"https:\/\/www.microsoft.com\/insidetrack\/blog\/uploads\/prod\/2021\/10\/key-takeaways-300x74.png\")
\nIdentity is a primary factor in determining access to corporate resources in the Zero Trust model. By enforcing strong identities, reducing dependency on passwords, and limiting access to data by using least-privilege access, we\u2019re creating an identity framework on which the entire Zero Trust model rests. As we continue to strengthen our processes for verifying identity throughout our digital estate, we\u2019re strengthening the remaining three pillars: device, access, and services, and, in turn, the entire Zero Trust model.<\/p>\n![\"Related](\"https:\/\/www.microsoft.com\/insidetrack\/blog\/uploads\/prod\/2021\/10\/related_links-300x81.png\")
<\/p>\n\n