An interesting topic for this week – understanding the relationships between the various Azure cloud offerings. I was working with a customer that had a need to manage data that was subject to ITAR (International Traffic in Arms Regulations), a US regulation that creates a number of restrictions for using cloud data. This includes among other restrictions a requirement to guarantee that systems and data are only accessed by US persons (citizens and permanent residents), among other things. The customer also wanted to be able to utilize Power BI to process the data and create reports.
This customer was looking at the various Azure and Microsoft 365 offerings, trying to understand which services they needed to use and how the different systems were related. They were faced with numerous acronyms and terminology. They wanted to know – should they use Azure Gov, GCC, or GCC High?
Helping them answer that question meant I first needed to help them understand Microsoft’s terminology. While I’ve created a diagram to illustrate those relationships, the full answer requires some explanation.
Multiple clouds, one name
While we often speak of the Azure cloud as if it’s a single entity, Azure has two primary flavors in the US: Microsoft Azure Commercial (also called MAC or Commercial) and Microsoft Azure Government (also called MAG, Azure Gov, or US Sovereign Cloud). When we talk about “Azure”, we’re usually discussing MAC. It receives the fastest updates and has the newest features.By comparison, MAG requires certifications that can impact which features are available. To support this and the specialized requirements, the services on Azure Gov are generally more expensive. Over time, additional Azure Gov cloud offerings have emerged – DoD (for Department of Defense workloads) Secret, and Top Secret (for classified workloads). All of the Azure Gov offerings generally require a special approval and validation of eligibility.
Azure Government is a physically and virtually isolated environment, separate from the Azure Commercial data centers. It is built to meet stricter compliance requirements. To this end, data transmission and processing is restricted to CONUS only (data resides in the US and does not leave the US). Because of this, it can support export controls. While Azure Commercial is available both inside the Continental US (CONUS) and Outside the Continental US (OCONUS), Azure Gov is restricted to CONUS, allowing it to support DISA SRG Impact Level 5 (IL5), as well as ITAR and Export Administration Regulations(EAR).
The Azure Gov DoD offering meets IL5 and IRS 1075, and is managed separately from Azure Gov. It has more restricted personnel screening requirements and is limited to the DoD and those approved by them. Azure Gov Secret adds IL6, ICD 503, and JSIG (PL-3) and can process classified Secret-level data, while Top Secret includes ICD 705 and can process classified Top Secret data. These dedicated, air gapped facilities handle national security workloads.
Each of the different sites has a different Azure portal, making the boundaries clear and obvious.
Office 365 and the Government Community Cloud
Office 365 (and Microsoft 365) are built on top of Azure. So are Dynamics, Power BI, and the other SaaS offerings. This isn’t a big surprise to most people. As a result, they are only as compliant as the hosting Azure environment. Initially, all of these existed on the Commercial cloud. As a result, this is also called “Office Commercial”. Obviously, that may not be enough for Government customers, so there are additional offerings designed to meet those needs.
Government Community Cloud (GCC), a special copy of the Office 365 commercial environment. GCC (sometimes called “GCC Moderate”) is not actually a separate cloud offering. It is a dedicated data and services enclave within the Commercial cloud that comes with some guarantees:
- Covered workloads (such as Exchange, SharePoint, Teams, Planner, OneDrive, Office 365 apps, and Power Apps) will have all data will reside in the U.S. Note that non-covered workloads and third-party integrations aren’t covered, and that the global network means that you do not have data sovereignty.
- Access to the systems is restricted to screened Microsoft personnel
- Data is logically segregated from the Office 365 Commercial services
- Compliance includes FedRAMP High, Defense Federal Acquisition Regulations Supplement (DFARS), Criminal Justice Information (CJI/CJIS), and Federal Tax Information (FTI)
Because it is in Azure Commercial, is uses Microsoft Entra ID Commercial (which cannot integrate with Microsoft Entra ID Gov). The Commercial environment means it is not sufficient for ITAR, EAR, or Department of Defense (DoD) Controlled Defense Information (CDI) or Controlled Unclassified Information (CUI).
GCC High and Office 365 DoD
Obviously, something more is needed to support the requirements of ITAR, EAR, and other stronger regulations. These environments are built in Azure Gov and staffed by people that undergo a more detailed background screening, including verification of US citizenship. This environment also has restrictions to prevent sharing data with any organization that isn’t also GCC High. Because of the restrictions, the supported product features can be different. GCC High (and better) stores the data in Azure Gov, so it is physically segregated from the Commercial services.
GCC High (“High” or “IL4”) is build on Azure Gov, so it uses Microsoft Entra ID Gov. It offers stronger guarantees on data residency and sovereignty, enabling ITAR and EAR data to be processed and stored. Similarly, Office 365 DoD (“IL5”) uses Azure Gov DoD, while Office 365 Government Secret(“IL6”) uses Azure Secret.
It’s worth mentioning that as you review the compliance offerings center, you will often be guided towards the minimum supported offering. For example, DoD IL2 support exists for Office 365 services in both GCC and GCC High. However, ITAR support requires GCC High or Office 365 DoD.
It’s important to know that GCC High and higher utilize separate Microsoft Entra ID environments. As a result, they use a different set of credentials from the commercial offering. These identities will have a
different tenancy and a domain ending in .onmicrosoft.us
. This ensures that it’s always clear when you’re accessing a more restricted system.
Note: This means that you will have more than one identity. While many customers are concerned with this and try to find ways to force synchronization, this is actually a best practice for security. It ensures that you cannot accidentally move data between the two systems and that you are always aware of the restricted nature of the data and services being accessed.
What about FedRAMP?
One of the most common compliance requests is FedRAMP High. I’m often asked where those workloads should go. The answer is simple – it depends. 😄
Both Azure and Azure Gov maintain FedRAMP High P-ATO (Provisional Authorization to Operate). As a result, both can be used. If system access needs to be limited to screened US persons, then Azure Gov would be required. Otherwise, Commercial may be sufficient. Consequently, Office 365, Dynamics 365, and Power BI are also in-scope.
Does that mean your application or solution is automatically compliant? Absolutely not! Compliance requires more than just Microsoft having an approval. While there are Azure Policy definitions that can help ensure that the Azure services are correctly configured to support compliance, every compliance standard requires some shared responsibility. You cannot solely rely on Azure Blueprints or Azure Policy to meet a compliance standard. Microsoft assists with this process by documenting some of the controls to help users understand the limitations of what is implemented. This practice holds true for many of their compliance offerings.
Putting it together
Coming back to the customer, ITAR and EAR data require Azure Gov for data storage to ensure compliance. To guarantee that the data was only available and processed within the US (and on systems only accessible by US persons) the minimum compliant Office environment the customer could use was GCC High. Power BI is a covered workload, although it’s restricted to Pro and Premium licenses. Because it’s GCC High, they would use the GCC High sign-in URL and their Azure Gov Entra ID identity. They would also not utilize DoD or higher unless required and approved for that access by the DoD.
The customer would not consider Azure Commercial or GCC for working with their data since those environments are not compliant for ITAR and do not guarantee data sovereignty. That said, they could use those environments for storing and processing data that does not have those restrictions.
Mixing data classifications
If users need to interact with both restricted and unrestricted data, then there are typically two choices to consider:
- Have two environments, with the different data stored and processed in the appropriate environment. This can be a less expensive route in some cases, but it can require more effort for end users.
- Use the most restricted environment for everything. This may have a higher cost, but it would allow users a more seamless experience. It would be very important to classify the data to ensure that restricted data could still be identified.
In both cases, it can make sense to use Microsoft’s Data Classification tools to ensure data is properly labeled for sensitivity, retention, and classification. For Azure Commercial workloads, Azure Purview can help with automating this process. Purview is not yet available in Azure Gov.
But wait! There’s more …
I know that’s a lot of information and links! There’s a lot to understand when it comes to compliance considerations. The links in this article help to connect you to a number of those items.
If you want to dive deeper into understanding of the history and relationships between the offerings, make sure to read these two articles from Microsoft. They explore this topic in much greater depth.