This article is the first of a series in the Microsoft Tech Community Public Sector Blog and touches on several of the key principles for compliance, including data residency versus data sovereignty. For a more in-depth explanation, please refer to Understanding Compliance Between Microsoft 365 Commercial, GCC, GCC-High and DoD Offerings.
I chose to start with this history lesson, as it puts our cloud offerings into perspective and enables an understanding of why, as we go levels deeper when explaining compliance between the various cloud offerings.
I outline principles throughout this article. Please keep in mind these principles are specific to the overlying emphasis on compliance.
Microsoft 365 started with Office 365 Commercial.
What’s it called? Internally, we call the Office 365 Commercial environment ‘Public Multi-Tenant’ or ‘Public MT’ for short. Back in 2010, we had a set of dedicated clouds as well, which is why we often differentiate the clouds as Multi-Tenant, meaning not dedicated nor private clouds. And the term ‘Public’ indicates that it’s available on the public internet and is often interchangeable with ‘Global’. Thus, if you hear someone from Microsoft refer to Public or Public MT, they are talking about our Commercial environment.
For purposes of this conversation, I will use the term “Commercial” which refers to the environment as opposed to “Enterprise” which refers to licenses. Office 365 Commercial originally shipped with the four primary workloads. Today those workloads are branded as Exchange Online, SharePoint Online, OneDrive for Business Online, and Skype for Business Online. It has evolved to include many new products including Advanced Threat Protection, Teams, Yammer, Power BI, Stream, the Security & Compliance Center and many more.
Office 365 Commercial pre-dates many of the Enterprise Mobility + Security (EM+S), Azure IaaS and PaaS services we are familiar with today, including the directory services solution we know as Azure Active Directory (Azure AD). Back in 2010, Office 365 shipped with a native directory service called Microsoft Online Directory Store (MSO-DS). The term ‘tenant’ can be described in a simplified fashion as being the security boundary defined by an instance of MSO-DS for a specific customer enrollment. Thus, an enrollment of MSO-DS (now Azure AD) directory services is a ‘tenant’.
Three primary principles emerge with the first release of Commercial:
- Global Directory. Starting with MSO-DS and now with Azure AD in Commercial, directory services are supported globally OCONUS (Outside the Continental United States). In other words, directory data transmission and data processing, including authentication and authorization, may be OCONUS. A tenant can be homed in a specific geo (e.g. the US), but the directory may be supported globally. That said, a tenant’s directory data storage may be restricted to a specific geo such as in the United States (where Azure AD data is stored solely in the United States) and in Europe (where Azure AD data is stored in Europe or the United States). Learn more here.
- Global Network. Data transmission and data processing is global. Most Commercial endpoints are *.com and may resolve to the closest geographical location of the Microsoft network. For example, when you sign into Commercial from Australia, it may resolve your client to our data centers in Sydney or Melbourne. Of course, if your data is elsewhere, such as in the US, your client will connect to the US over our high-speed fiber network backbone from Australia. But there is data transmission and data processing on systems OCONUS.
- Global Support Personnel. Office 365 Commercial support personnel are not restricted to US Persons. We have a follow-the-sun support model in Commercial where support personnel from India and elsewhere may have limited access to services to provide 24/7 support for our customers.
Keep these principles in mind as we continue to discuss the evolution of our cloud services as it’s the reason we ended up with several different clouds.
A word about Office 365 Multi-Geo
As Commercial has evolved, we now have regions, or ‘Geos’ in Public MT that offer data residency in multiple geographies, often aligned with countries. Our Office 365 Multi-Geo solution addresses your data residency requirements for workloads including (and limited to) Exchange Online, OneDrive for Business Online, SharePoint Online and Office 365 Groups. We will soon have a multi-geo solution for Teams as well. From a compliance perspective, this translates to having data stored at rest within a specific country or region.
At the time of this writing, we have available Geos in Australia, Brazil, Canada, European Union, France, Germany, India, Japan, South Korea, Norway, South Africa, Switzerland, United Arab Emirates, United Kingdom, and the United States. We are adding new Geo’s frequently.
A Geo in Office 365 is a data enclave for a defined region. Internally, a Geo is a data enclave of Commercial. A data enclave is segregated environment, with servers residing in regional Azure data centers. For example, the US Geo may be selected in Exchange Online for specifically assigned users that require mailboxes at rest within CONUS (Continental United States). Many governments, financial services, healthcare providers, etc. often have requirements for data residency in a specific country. This Multi-Geo solution often meets these compliance requirements in Commercial, especially in conjunction with the alphabet soup of industry standards and government regulations in the US and abroad.
History Sidebar: The often-forgotten true predecessor to Office 365 is the first public multi-tenant Office solution we delivered to Education customers called Live@edu. It began in 2005 and served as something of an early adopter program for Office 365, on-boarding over 50 million faculty, staff, and students to Outlook Live, SkyDrive and other Office solutions. Interestingly, I was the first solution architect for Live@edu starting back in 2007.
Some may dispute that BPOS (Business Productivity Online Suite) is the predecessor to Office 365, but in truth it was a parallel environment built and supported by BPOS engineering. Conversely, Live@edu was built and supported by each respective workload product group (e.g. Exchange), identical to Office 365. Regardless, both Live@edu and BPOS pre-date Office 365.
Introducing the US Government Community Cloud.
What’s it called again? Office 365 GCC should not be confused with GCC High. They are two separate clouds. Historically, we often referred to GCC as ‘GCC Moderate’ for its alignment with FedRAMP Moderate. I’ve also heard it called the ‘IL2’ environment, for its alignment with the DoD CC SRG Impact Level 2. But ‘Moderate’ and ‘IL2’ are confusing nicknames, and we try to avoid calling GCC anything other than ‘GCC’.
US Government customers have a variety of accreditations and industry standards for Cloud Solution Providers. Most notably, FedRAMP and NIST come to mind. Certain government entities extend beyond the accreditation with regulations such as CJIS and IRS 1075 that require screened US Persons. As such, it’s not good enough to simply have data residency within CONUS. The cloud service offering must impose restrictions so that only authorized personnel may access customer content. Ultimately, this data enclave for GCC not only ensures data residency and data processing for the primary workloads are in CONUS, it also restricts customer content access to authorized screened US Persons.
For Microsoft to capture the market for US Government entities, GCC is required. We have onboarded thousands of US government agencies and departments, especially in SLG (State & Local Government) and Federal Civilian. There are a few principles for GCC to keep in mind:
- GCC is a data enclave of Commercial. Shared services, such as outlined in the principles for Commercial apply to GCC as well (e.g. Global Directory, Global Network, Global Support, etc.)
- GCC offers data residency as opposed to data sovereignty. It’s paramount that you understand data residency applies to the GCC covered workloads (e.g. Exchange, OneDrive, etc.). Other workloads may not support data residency.
- US Government accreditation for GCC. The FedRAMP Moderate Agency ATO from the Department of Health and Human Services (DHHS) is specifically for a government tenant provisioned into GCC that resides in the Commercial environment (listed on the FedRAMP marketplace as Office 365 Multi-Tenant & Supporting Services).
- GCC is ultimately a data enclave of Commercial, thus FedRAMP Moderate accreditation has ‘equivalency’ across all our Public MT environment including Commercial tenants. Ultimately, it’s regulations (e.g. CJIS & IRS 1075) that drive government entities into GCC as opposed to Commercial.
Keep these GCC principles in mind, along with the Commercial principles. It's the reason many government customers with stricter regulatory requirements (e.g. ITAR, Nuclear, etc.) do not choose GCC.
Then along came Microsoft Azure.
Office 365 pre-dates Microsoft Azure. We did have Windows Azure around about the same time as the first release of Office 365, but the Windows variant did not have many of the EM+S, PaaS and SaaS components that are included today. For the purposes of this conversation, we’ll focus on Azure AD and EM+S. Many of the native features evolved out of Office 365 and into Azure. MSO-DS became Azure AD and provides directory services, authentication and authorization beyond Office 365, including Azure Resource Manager and 3rd-party applications. Azure RMS spun out and is now bundled with Microsoft Information Protection (MIP). And the list goes on. Azure now provides a platform for many workloads, and we’ve continued to build on top of that. For example, Dynamics 365 and Visual Studio Online are now built on top of the Azure platform and integrate into services such as Azure AD in Commercial.
The one key principal of Azure Commercial as it relates to Office 365 is:
- Office 365 Commercial and Office 365 GCC are both paired with Azure AD in Commercial. Office 365 GCC cannot be paired with Azure AD in Government (more on that to come).
To distill this down, compliance for Azure Commercial aligns closely to what is offered for Office 365 Commercial. The same three principles of Office 365 Commercial (Global Directory, Global Network, Global Support Personnel) apply to Azure Commercial. In other words, data residency is available, but data sovereignty is not.
In fact, many of the US SLG and Federal Civilian agencies will not deploy IaaS nor PaaS into Azure Commercial without US Persons support, regardless of the fact that we have a P-ATO for FedRAMP High in Azure Commercial.
To capture the market for US Government entities for IaaS and PaaS, Microsoft built Azure Government.
What’s it called? The initial release of Azure Government for IaaS and PaaS was the introduction of what we call the ‘US Sovereign Cloud’. Azure Government has internal code names including the first architecture called ‘Fairfax’ and the next generation sovereign architecture called ‘Arlington’. We also call it ‘MAG’ for Microsoft Azure Government. Most people just call it ‘Azure Gov’.
Azure Gov is a fully isolated cloud environment, that is both physically and virtually isolated. It's a separated instance of Azure within a compliance boundary dedicated to US government workloads. It's built exclusively for US government entities and their solution providers, to include the Defense Industrial Base (DIB). Azure Gov is designed for highly sensitive data such as Controlled Unclassified Information (CUI) that requires true data sovereignty. This enables Microsoft to contractually meet the compliance accreditation for FedRAMP High and requirements for US Defense regulations including DoD CC SRG IL4/5, DFARS 7012, ITAR and EAR.
For purposes of this discussion, several key principles include:
- US Sovereign Directory Services. Unlike with Commercial, Azure AD in Azure Gov is not global. No matter where your client connects from, you will always get authentication and authorization rendered from Azure Gov data centers located in CONUS. For example, you will always see a login page with a .US URL (e.g. https://login.microsoftonline.us/...)
- US Sovereign Network. Data Transmission and Data Processing is CONUS only. As opposed to Commercial endpoints that are all *.com, Azure Gov endpoints are all *.us or *.mil. For example, when you sign into Azure Gov from Australia, it will always resolve your client to Azure Gov data centers in the US. There is no probability of you connecting to data centers in Australia. If your internet peering is in the US, you can rest assured that no data transmission will occur OCONUS.
Note: You can implement public peering with Microsoft to enter our network in a geographically closer location to take advantage of our global high-speed fiber network backbone to route to the US, but there is no data processing OCONUS. - Screened US Persons. Support personnel is restricted to screened US Persons. This includes background checks as required by multiple regulations, including checks against export-related lists maintained by the Departments of Commerce, State and Treasury. Coverage is offered on all services in Azure Gov isolated within the compliance boundary where only screened US Persons are permitted.
- Azure Government supports US export-controlled data. True data sovereignty allows Microsoft to contractually commit to export controls, including US Defense regulations for DoD CC SRG IL4/5, DFARS 7012, ITAR and EAR. This includes coverage for Controlled Unclassified Information (CUI) and Covered Defense Information (CDI).
Now that we have Azure Government, it gave us a platform to begin deploying additional workloads into the US Sovereign Cloud.
Now introducing Office 365 DoD paired with Azure Government
After achieving a Provisional Authorization (PA) from DISA for DoD Cloud Computing (CC) Security Requirements Guide (SRG) Impact Level 5 (IL5) covering Azure Government, we began the construction of Office 365 for the US Department of Defense (DoD). To deploy Office 365 to the DoD, they required IL5 across the entire platform and services, to include Microsoft Peering with the DoD’s Cloud Access Point (CAP). We have delivered the full suite of services to Office 365 DoD, but we had one catch. Only the DoD and those approved by them (such as service providers or contractors working on behalf of DoD) are allowed into the IL5 environment. It does preclude other entities from being eligible to procure their own tenant of Office 365 in the US Sovereign Cloud. This includes the service providers for the DoD, such as the DIB. It also includes other government entities that require data sovereignty, such as cabinet-level agencies (e.g. DHS, FBI, DOJ, etc.). There was a tremendous demand from these entities as well.
To capture the market for the DIB and cabinet-level agencies, a mirror copy of Office 365 DoD was constructed and branded Office 365 Government (GCC High).
What’s it called? GCC High? Environment and SKU name aligns with High Impact Level. This should NOT be confused with the defense Industry term a ‘high-side environment’ which is a designation for classified information. To be clear, GCC High is not a ‘high-side environment’. GCC High is a ‘low-side environment’ regarding classified information. GCC High has also been called an ‘IL4’ environment, for its alignment with the DoD CC SRG Impact Level 4 controls. We avoid calling GCC High anything other than ‘GCC High’.
If you look for a DoD Provisional Authorization (PA) from DISA for a DoD CC SRG Impact Level 4 environment, you will not find one. That’s because we have equivalent IL5 environments. We have the IL5 PA on the Office 365 DoD environment, where GCC High is a near copy of. We can consider GCC High an IL4 environment for a couple of reasons. First, IL4 controls are derived from IL5 that we are accredited for. We have a consistent control framework and uniform implementations of controls in both environments; thus, we can say GCC High has IL4 ‘equivalency’. Second, no one besides the DoD proper is allowed into IL5. We call it an IL4 equivalent environment where the Defense Industrial Base and Cabinet-level agencies are allowed.
In alignment with the key principles for Azure Gov, several key principles of both the Office 365 DoD and GCC High environments include:
- US Sovereign Directory Services. Unlike Office 365 GCC that is paired with Azure AD in Commercial, Office 365 DoD and GCC High are paired with Azure AD in Azure Gov.
- US Sovereign Network. Data Transmission and Data Processing is CONUS Only. As opposed to Commercial endpoints that are all *.com, Office 365 DoD and GCC High endpoints are all *.us or *.mil. This is fundamentally important and a major talking point for compliance with export controls. For example, for email to be compliant, you must have all data processing in a US Sovereign solution. Microsoft offers Exchange Online Protection and Office Advanced Threat Protection within the compliance boundary keeping all data processing of email in CONUS. This includes logging and telemetry captured in the process of scanning email.
- Screened US Persons. Support personnel is restricted to screened US Persons. This includes background screening as required by multiple regulations, including checks against export-related lists maintained by the Departments of Commerce, State and Treasury. Coverage is offered on all services (no exclusions) in Office 365 DoD and GCC High isolated within the compliance boundary where only screened US Persons are permitted.
- Office 365 DoD and GCC High supports US export-controlled data. True data sovereignty allows Microsoft to contractually commit to export controls, including US Defense regulations for DoD CC SRG IL4/5, DFARS 7012, ITAR and EAR. This includes coverage for Controlled Unclassified Information (CUI) and Covered Defense Information (CDI). Microsoft will not commit to export controls anywhere else! This is especially true for ITAR.
We also have additional services that are branded GCC High. We now have Dynamics 365 GCC High, the Power Suite for GCC High, and many more services to come.
Appendix
Please follow me here and on LinkedIn. Here are my additional blog articles:
Blog Title |
Aka Link |
|
Accelerating CMMC compliance for Microsoft cloud (in depth review) |
|
|
Microsoft CMMC Acceleration Program Update |
|
|
History of Microsoft Cloud Service Offerings leading to the US Sovereign Cloud for Government (This One) |
|
|
Gold Standard! Understanding Compliance Between Microsoft 365 Commercial, GCC, GCC-High and DoD Offerings |
|
|
The Microsoft 365 Government (GCC High) Conundrum - DIB Data Enclave vs Going All In |
|
|
Microsoft US Sovereign Cloud Myth Busters - A Global Address List (GAL) Can Span Multiple Tenants |
|
|
Microsoft US Sovereign Cloud Myth Busters - A Single Domain Should Not Span Multiple Tenants |
|
|
Microsoft US Sovereign Cloud Myth Busters - Active Directory Does Not Require Restructuring |
|
|
Microsoft US Sovereign Cloud Myth Busters - CUI Effectively Requires Data Sovereignty |
|
|
Microsoft expands qualification of contractors for government cloud offerings |
|
|
Announcing Support for DFARS in Azure Commercial |
|
|
Announcing Support for DFARS in Microsoft 365 Government (GCC) |