Information barriers in Microsoft 365 (M365) refer to a set of policies and controls designed to prevent certain groups of users within an organization from communicating or collaborating with each other. These barriers are crucial for maintaining confidentiality, preventing conflicts of interest, and ensuring compliance with regulatory requirements.
The primary purpose of information barriers is to control the flow of sensitive information within an organization, especially in scenarios where different groups of users, such as employees in different departments or subsidiaries, should not have access to each other's data.
Information Barriers Benefits
Segregation of Duties: Enforces segregation of duties by preventing certain groups of users from accessing each other's data.
Conflict of Interest Mitigation: Mitigates conflicts of interest by restricting access to sensitive information that could lead to unethical behavior.
Regulatory Compliance: Helps organizations meet regulatory requirements by controlling access to sensitive data and preventing unauthorized disclosures.
Data Leakage Prevention: Reduces the risk of data leaks and misuse by restricting communication and collaboration between specific user groups.
Organization Segments
The Information Barriers block communication between segments established within an organization. First, segments should be carefully planned, ensuring coverage for the entire organization without leaving anyone behind.
Once segments are identified, Azure AD properties are considered next. The most intuitive approach is to use the department property for the segments.
Information Barriers are successful only if organization segments are properly defined, and these segments are only as effective as the underlying Azure AD structure. Therefore, addressing any Azure AD issues or messes and validating them is essential.
Another potential issue is that some organizations' department structures may not align well with the needs of Information Barriers. For example, ensuring that communication from the Directorship & Senior Management doesn't leak to the rest of the department can be challenging. In such cases, leveraging the Azure AD Department Property may not suffice. Interestingly, if the Directorship & Senior Management end up behind an Ethical Firewall, they wouldn't be able to send communications to all staff. These and other constraints could complicate the planning and implementation of Information Barriers.
If using the Department Property for creating Segments doesn't suit your organization, you can create Segments using Groups.
If none of your Azure AD Properties align with your planned Segments, you can use Azure AD Custom Attributes. In this case the custom attribute would need to be properly populated for the entire organization.
Regardless of the Azure AD Properties/Attribute you choose to leverage for segmentation, you can use only one Property for creating Segments. You cannot mix Departments and Groups when creating Segments.
Lists of attributes that you can use with information barriers
Azure AD Property Name (LDAP display name) | Exchange property name |
Co | Co |
Company | Company |
Department | Department |
ExtensionAttribute1 | CustomAttribute1 |
ExtensionAttribute2 | CustomAttribute2 |
ExtensionAttribute3 | CustomAttribute3 |
ExtensionAttribute4 | CustomAttribute4 |
ExtensionAttribute5 | CustomAttribute5 |
ExtensionAttribute6 | CustomAttribute6 |
ExtensionAttribute7 | CustomAttribute7 |
ExtensionAttribute8 | CustomAttribute8 |
ExtensionAttribute9 | CustomAttribute9 |
ExtensionAttribute10 | CustomAttribute10 |
ExtensionAttribute11 | CustomAttribute11 |
ExtensionAttribute12 | CustomAttribute12 |
ExtensionAttribute13 | CustomAttribute13 |
ExtensionAttribute14 | CustomAttribute14 |
ExtensionAttribute15 | CustomAttribute15 |
MSExchExtensionCustomAttribute1 | ExtensionCustomAttribute1 |
MSExchExtensionCustomAttribute2 | ExtensionCustomAttribute2 |
MSExchExtensionCustomAttribute3 | ExtensionCustomAttribute3 |
MSExchExtensionCustomAttribute4 | ExtensionCustomAttribute4 |
MSExchExtensionCustomAttribute5 | ExtensionCustomAttribute5 |
MailNickname | Alias |
PhysicalDeliveryOfficeName | Office |
PostalCode | PostalCode |
ProxyAddresses | EmailAddresses |
StreetAddress | StreetAddress |
TargetAddress | ExternalEmailAddress |
UsageLocation | UsageLocation |
UserPrincipalName | UserPrincipalName |
WindowsEmailAddress | |
Description | Description |
MemberOf | MemberOfGroup |
Source: Microsoft
Information Barriers Architecture
Source: Microsoft
The implementation of Information Barriers will vary across M365 workloads like Exchange Online, SharePoint Online, and MS Teams due to differences in their underlying architecture.
Exchange Online and Information Barriers
The concept of an Ethical Firewall is not new for Microsoft Exchange. In Exchange, Address Book Policies (ABPs) are used to enforce Ethical Firewalls by limiting access to the directory. However, implementing Exchange Online Information Barrier requires the removal of all ABPs.
ABP cannot be removed if there is a mailbox still associated with the ABP. If the mailbox is inactive, it would need to be made active first.
Information Barriers Implementation
At present, Information Barriers can only be implemented through the use of PowerShell scripts.
Step 1: Create Organization Segments
New-OrganizationSegment -Name "segmentname" -UserGroupFilter "attribute -eq 'attributevalue'"
Let's create four different Organizational Segments:
Legal Department
HR Department
Sales Department
Research Department
New-OrganizationSegment -Name "Legal" -UserGroupFilter "Department -eq 'Legal'"
New-OrganizationSegment -Name "HR" -UserGroupFilter "Department -eq 'HR'"
New-OrganizationSegment -Name "Sales" -UserGroupFilter "Department -eq 'Sales'"
New-OrganizationSegment -Name "Research" -UserGroupFilter "Department -eq 'Research'"
Step 2: Create Information Barrier Policies
Information Barrier Policies control how information flows between the segments by either blocking or allowing information flow.
IB Policy to Block Flow of Information: PS Command:
New-InformationBarrierPolicy -Name "policyname" -AssignedSegment "segmentAname" -SegmentsBlocked "segmentBname" -State "state"
The best practice is to initially create IB Policies in an inactive state and then activate them only after everything is set up for the entire organization.
In this example, we create IB Policies to prevent the Sales Department from communicating with the Research Department.
New-InformationBarrierPolicy -Name "Research Block Sales" -AssignedSegment "Research" -SegmentsBlocked "Sales" -State Inactive
New-InformationBarrierPolicy -Name "Sales Block Research" -AssignedSegment "Sales" -SegmentsBlocked "Research" -State Inactive
IB Policy to Allow Flow of Information:
To allow communication to be restricted to specific segments, use the SegmentAllowed when creating the Information Barrier Policy.
New-InformationBarrierPolicy -Name "policyname" -AssignedSegment "segmentAname" -SegmentsAllowed "segmentBname","segment1name" -State "state"
New-InformationBarrierPolicy -Name "Allow HR and Legal Communications" -AssignedSegment "Legal" -SegmentsAllowed "HR" -State Inactive
If there is no policy either blocking or allowing communication between segments, then communication will be permitted.
Step 3: Activate Information Barrier Policies
When we finish creating all IB Policies, we can now activate them by using the following PS cmdlet:
Set-InformationBarrierPolicy
Set-InformationBarrierPolicy -Identity "Research Block Sales" -State Active
Set-InformationBarrierPolicy -Identity "Sales Block Research" -State Active
Set-InformationBarrierPolicy -Identity "Allow HR and Legal Communications" -State Active
Step 2: Apply Information Barrier Policies
To start applying IB Policies, use the following cmdlet:
Start-InformationBarierPoliciesApplication
Applying IB Policies may take some time. You can run the following command to check the status:
Get-InformationBarrierPoliciesApplicationStatus
Comments