Secure by default with Microsoft Purview and protect against oversharing - Phase 4

Artikkeli
09/20/2024

This guide is divided into four phases:

Introduction
Phase 1: Foundational – Start with default labeling
Phase 2: Managed – Address files with highest sensitivity
Phase 3: Optimized – Expand to your entire Microsoft 365 data estate
Phase 4: Strategic – Operate, expand, and retroactive actions (this page)

Secure by default with Microsoft Purview and protect against oversharing - Blueprint

Phase 4: Strategic - Operate, expand, and retroactive actions

In this final phase, we look at implementing operational procedures and expanding beyond Microsoft 365.

Operational review of user labeling behaviors

File labeling is an integral part of this blueprint. Administrators should review risky behaviors and configurations that deviate from the standards.

Here are the core operational scenarios to review:

Unlabeled Sites/Teams – Use Graph API to identify sites and contact Site Owners or apply corrective measures.
Mismatch between site label and default library label – Use Graph API to identify discrepancy and contact Site Owners or apply corrective measures.
Leverage Data Loss Prevention (DLP) on SIT and unrestricted labels – Catch exceptions with DLP when content is labeled without protection and sharing is attempted.
Look for risky users with Insider Risk Management audit – Review risky users and behaviors, fine tune IRM policies, and implement stricter Adaptive Protection.

Iterate with new labeling scenarios

In this deployment model, we focused on labeling scenarios that fit most organizations, allowing for a quick deployment and securing your data estate rapidly without the need for identifying all edge cases.

In this section, we look at potential iterations your organizations should consider after a core deployment.

Secure collaboration with trusted partners / multi-tenanted organizations

In situations where your organization has multiple tenants or that it works openly with a trusted partner, consider the use of labels with encryption that supports multiple domains such as “@contoso.com + @adventureworks.com”.

These would be labeled either/both Confidential and Highly confidential.

Tented projects

Tented projects are highly confidential. For example, merger and acquisition projects, where access to the content must be restricted to a specific group of users.

You can create a label with encryption for a security group and publish it only to the same individuals. After a period when this project isn't required, the label can be unpublished, and the information will remain protected, but no new labeling will be done with this label.

Full-Time Employees, Vendors, offshore or regional teams

Some organizations have requirements to identify – and protect – a segment of users such as:

Full-Time Employees (FTE)
Vendors
Offshore
Regional/country

In this guide, we simplify the labeling to “All Employees” but we understand that there may be a need to secure labeling differently in some cases between FTE and vendors/partners, and sometimes for specific regions.

As with the previous scenario, we recommend limiting the number of labels visible to users to no more than 5 group labels, each with no more than 5 labels (5x5) whenever possible. In context of regional or country labeling, you can target publishing to the appropriate users and use containers to file labeling to simplify defaulting to the most appropriate label.

Labeling on-premises file shares and SharePoint server

It's possible to use Sensitivity Labels with your on-premises file shares and SharePoint server with the Information Protection scanner. As this guide focuses on securing by default, we recommend configuring the right defaults in SharePoint, migrate your content to SharePoint, and automatically labeling the content as it is uploaded.

Note

For remaining on-premises scenarios, please refer to Learn about the Microsoft Purview Information Protection scanner

Bring Your Own Key (BYOK) and Double Key Encryption (DKE)

Both BYOK and DKE are options, available to meet regulatory requirements, and they are outside of the scope of this guide. BYOK is about ownership and how the rolling of encryption keys function, while DKE is intended for a small fraction of highly sensitive content that requires more security. DKE affects several collaborative capabilities.

You can learn more about BYOK here: Service encryption and key management - Microsoft Purview

You can learn more about DKE here: Double Key Encryption (DKE)

Set up accountability chain and lifecycle management

Empowering collaboration with SharePoint comes with responsibilities for Site Owners. It’s important to implement a chain of accountability and lifecycle management with the following recommendations:

2+ Site Owners on all sites – Use Site Ownership policies to identify sites without at least two owners and contact current owners or members to resolve.
Inactive site – Inactive site policies to remove unused sites.
Site attestation – Require site owners to attest sites regularly.
Review content shared with "everyone except external users" – Use SharePoint Advanced Management reporting to identify content shared with everyone except guests, and contact site owners.
Site access reviews – Use SharePoint Advanced Management, review site data governance, and initiate site access review, particularly for sites with high volume of sharing or access.

Extend protection to Azure SQL and non-Microsoft 365 storage

Sensitivity Labels can now extend protection to non-Microsoft 365 data sources. We currently support the following data sources in Public Preview:

Azure SQL Database
Azure Blob Storage
Azure Data Lake Storage Gen2
Amazon S3 buckets

Microsoft Purview is a combination of what was formerly known as Azure Purview and Microsoft Purview. This experience is now all under the new Microsoft Purview portal, Generally Available as of July 2024. It allows data security administrators to set up labeling, auto labeling, and protection policies across both Microsoft 365 and non-Microsoft 365.

Protection policies for non-Microsoft 365 data assets you allow to set up oversharing protection with “deny all except” permissions at the data level. For example, storage accounts that are inadvertently used for more sensitive content than intended, protection policies can ensure that permissions are restricted to data security admins.

Similarly, for Azure SQL Database, protection policies restrict access to a column if sensitive content is found and the column labeled. Granular configurations are available to set up who can retain access for each data asset.

Jaa