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 clouds 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:
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.
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, Asia Pacific, Canada, European Union, France, India, Japan, Korea, 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 logically 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.
What’s it called? Office 365 GCC should not be confused with GCC High. They are two separate clouds. We often refer 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 to support the service. As such, it’s not good enough to simply have data residency within CONUS but must also have the proper personnel managing and supporting the workloads. Ultimately, this data enclave for GCC not only ensures data residency for the primary workloads (the same ones supported by Multi-Geo today) but are also supported by screened US Persons. This includes data processing specific to the covered workloads (e.g. Exchange Online Protection).
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:
Keep these GCC principles in mind, along with the Commercial principles. It's the reason many government customers with stricter regulatory requirements (such as DFARs, ITAR, DoD CC SRG, etc.) do not choose GCC.
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 Azure Information Protection (AIP). 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 principle of Azure Commercial as it relates to Office 365 is:
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.
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, DFARS, ITAR and EAR.
For purposes of this discussion, several key principles include:
Now that we have Azure Government, it gave us a platform to begin deploying additional workloads into the US Sovereign Cloud.
After achieving a Provisional Authorization (PA) from DISA for DoD CC 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 L5 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.
What’s it called? GCC High? Environment and SKU name aligns with its accreditation of FedRAMP High. 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’. Also note, Office 365 (GCC High) currently has a FedRAMP Agency ATO at the Moderate Impact Level from the Department of Justice (DOJ) and successfully completed two FedRamp High Impact Level audits.
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:
We also have additional services that are branded GCC High. We now have Dynamics 365 GCC High, the Power Suite for GCC High coming online as we speak, and many more services to come.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.