“Everything should be made as simple as possible, but no simpler.”
Albert Einstein
2024.02.17 Update: Patrick Abel from Summit 7 has this great post on Cross-Cloud B2B and Teams Cross-Cloud Guest Access in GCC High.
This post is an unofficial elaboration of the official Microsoft guidance to Defense Industrial Base companies operating in multi-tenant Microsoft cloud environments. Many organizations use Microsoft’s GCC High environment to meet US Government compliance requirements. Last November, Microsoft released this best-practice guide that laid out three best-practice topologies for organizations with multiple tenants in Microsoft’s cloud services:
- “all-in” GCC High: Migrate all users to GCC High.
- “split tenant”: Migrate some users to GCC High and home other users in Commercial.
- “swivel seat” or “data enclave”: Provision users with one account in GCC High and another in Commercial.
If your organization is “all-in” GCC High, you need not read further. The “all-in” topology is the simplest. The original guidance covers this topology well. This post explores problems and proposes solutions for multi-tenant organizations when US users must be homed in GCC High and non-US users must be homed in Commercial. Thank you to Ryan Bonner and Richard Wakeman for generously contributing key insights and review to this discussion that Richard anticipated on page 31 of Microsoft’s guidance:
“A discussion on how a US-based company approaches foreign subsidiaries and user populations deserves a white paper of its own.”
Microsoft Reference Identity Architectures for the US Defense Industrial Base
Table of Contents
- What is GCC High?
- Three Multi-Tenant Scenarios
- Scenario 1: Unified GAL, No Cross-Tenant Access
- Scenario 2: GCC High Parent, Commercial Sub
- Scenario 3: Commercial Parent, GCC High Sub
- Conclusion
What is GCC High?
GCC High is a separate Microsoft Cloud instance designed to satisfy U.S. sensitive data regulatory, classification, residency, and sovereignty requirements:
- International Traffic in Arms Regulations (ITAR)
- Export Administration Restrictions (EAR)
- Not Releasable to Foreign Nationals (NOFORN)
- Supported by Background-Checked U.S. Persons
- Data residency in U.S. data centers
For more information on requirements satisfied by GCC High, please see these reference videos:
- [Summit 7] Do I need GCC High for CMMC 2.0? (spoiler: the answer is maybe)
- [Agile IT] Understanding GCC High, GCC, and Commercial Microsoft 365
Three Multi-Tenant Scenarios
GCC High addresses data handling requirements that Commercial cannot meet. Therefore, whenever a Commercial tenant is discussed, the risk of data leakage from GCC High into Commercial must be considered. There are (at least) three kinds of data leakage: (1) leakage within a GCC High tenant to unauthorized users, (2) leakage out of a GCC High tenant to a Commercial tenant in the same organization, (3) leakage out of an organization entirely. We concern ourselves with measures to prevent the second kind of data leakage in this post; however, these measures can protect against all three kinds of data leakage. Let’s review three common multi-tenant scenarios involving GCC High and Commercial tenants.
Scenario 1: Unified GAL, No Cross-Tenant Access
GALSync with Exchange Mail-Enabled Contacts
The “split tenant” and “swivel seat” topologies imply no cross-tenant access. An organization may not want cross-tenant access but want cross-tenant visibility through a unified Global Address List. Pages 15-18 of Microsoft’s guidance cover the GALSync solution from its on-premises origins in 2003 to present-day, cloud-based variants. The idea of a Unified GAL is to provision Contact objects from remote tenants to the local tenant to allow each user to see a unified Global Address List. We are adding Contact object support to the Mindline Identity Bridge based on Defense Industrial Base requests.
Problem: Emailing Attachments With Sensitive U.S. Data
Unified GAL or not, users might email attachments with sensitive U.S. data to unauthorized users. End-user training alone is inadequate protection.
Solution: Use Microsoft Purview Information Protection to Classify and Protect Sensitive Data
Microsoft Purview Information Protection is integrated across Microsoft 365, providing seamless protection across Microsoft 365 applications, Adobe Acrobat, Microsoft Defender, and Microsoft Sentinel.
Classify and Label Sensitive Data
Microsoft Purview allows you to create and manage sensitivity labels that can be applied to documents and emails. Users can apply these labels manually or automatically based on content recognition.
Apply Protection Actions to Labels
With sensitivity labels, you can define protection actions that should be automatically applied when a label is assigned to content. To prevent external sharing, you might configure labels to encrypt content and restrict access.
Create Data Loss Prevention Policies
DLP policies in Microsoft 365 can help prevent sensitive information from being shared outside your organization. You can configure rules to block email and notify senders when sensitive content is about to be emailed.
Limitations: Fidelity of Team Collaboration, Single Tenant Visibility of Sensitivity Labels
Teams and Purview have some limitations operating across tenants. Scenario 2 and Scenario 3 assume cross-tenant access through Microsoft Entra B2B.
Fidelity of Teams Collaboration
Teams supports Federated Chat to communicate with users in other tenants. Teams also supports Shared Channels to allow collaboration with people who aren’t in the Team or your tenant. These capabilities suffer some loss of fidelity, and some companies opt to invite external users using Microsoft Entra B2B to get an improved (though not yet perfect) collaboration experience.
Single Tenant Visibility of Sensitivity Labels
Sensitivity labels can be used to create Conditional Access policies that determine which users, from which locations, and using what authentication strengths can access labeled content. Unfortunately, these labels are only visible within a tenant, so they would require Microsoft Entra B2B to allow controlled access by external users.
Scenario 2: GCC High Parent, Commercial Sub
Enterprise “Home” In GCC High
If your business heavily deals with sensitive U.S. data, you want the data and the people authorized to handle that data contained within the GCC High environment to the greatest extent possible. If there is a data spill within the environment, at least U.S. data handling regulations haven’t been violated.
People’s day-to-day work does not 100% consist of handling sensitive U.S. data. Accessing HR, Training, Lunch Room Menus, and other non-sensitive data is a normal part of working for an organization. Containing sensitive data handlers to do all their sensitive and non-sensitive work in GCC High reduces the chance of data spillage outside GCC High and violating U.S. data handling regulations.
Problem: Commercial Sub Access in GCC High “Home”
However, some users are subject to non-U.S. data sovereignty, data residency, or support requirements that can only be met in Commercial. The organization has a choice to (1) replicate non-sensitive systems in the Commercial tenant or (2) provide access to non-sensitive data in GCC High. However, provisioning access to non-sensitive data in GCC High through Microsoft Entra B2B risks inadvertent disclosure of sensitive U.S. data to these users.
Solution: Protect Against External Access In GCC High
Fortunately, conditional access policies provide the ability to block access by external users. Suppose the sensitive data can be confined to a set of applications in the GCC High tenant. In that case, you can define conditional access policies in the GCC High tenant to block external access to those applications. Alternatively, suppose only the Lunch Room Menu needs to be accessed cross-tenant. Then, you can define a conditional access policy to “Block External Users From All Applications Except the Lunch Room Menu.” More nuanced policies can be created through Microsoft Purview Information Protection.
Scenario 3: Commercial Parent, GCC High Sub
Enterprise “Home” In Commercial
If only a small portion of your business deals with sensitive U.S. data, you may not want to migrate all your U.S. employees to GCC High. Instead, you may want to define a secure enclave of users and data in GCC High to handle sensitive U.S. data.
Problem: Data Spillage Into Commercial “Home”
This problem is the reverse of sharing sensitive data with external users. The organization has a choice to (1) replicate non-sensitive systems in the GCC high tenant or (2) provide access to non-sensitive data in Commercial to your GCC High users. However, provisioning access to non-sensitive data in the Commercial tenant through Microsoft Entra B2B risks that authorized GCC High users may inadvertently spill sensitive U.S. data into Commercial systems that don’t provide the required assurances.
Solution: Encrypt Sensitive U.S. Data
Happily, you can configure Microsoft DLP policies to prevent the storage of sensitive data in insecure locations. DLP policies can also encrypt sensitive U.S. data to ensure that, even if this data is stored in an insecure location, it can only be decrypted by authorized GCC High users.
Conclusion
This post scratches the surface of how native Microsoft cloud capabilities can help you protect sensitive U.S. data in multi-tenant organizations. I am grateful to Richard Wakeman and my former co-workers at Microsoft for their continued collaboration. If you want to automate synchronizing your users as External B2B Users or Contacts across GCC High and Commercial tenants, please check out the Mindline Identity Bridge.