HomeAbout Me
Microsoft 365
Sensitivity labels in Microsoft Teams
Simon Ågren
Simon Ågren
June 02, 2022
4 min

Table Of Contents

01
Protecting containers
02
Container settings
03
Label Creation Considerations
04
Examples
05
Finishing up
Sensitivity labels in Microsoft Teams

I have previously written about Guest Access and Sharing settings. In those posts, I mentioned Sensitivity labels as a mechanism to automate some governance-related settings - and today, we will look at them.

Sensitivity labels are a part of Microsoft Purview (formerly Microsoft Compliance) Information Protection. Traditionally, sensitivity labels have been used to classify and protect documents and emails while ensuring that user productivity and collaboration abilities aren’t hindered. We can also use sensitivity labels with containers such as Microsoft Teams, Microsoft 365 Groups, and SharePoint sites. Today we are looking at how to package settings according to how we want to classify our Teams.

If you want to learn more about sensitivity labels for content: Learn about sensitivity labels - Microsoft Purview (compliance) | Microsoft docs

Protecting containers

Sensitivity Labels are a great way to consistently enforce some of the requirements we gathered in the governance strategy. For example, teams can be restricted or locked down via a sensitivity label, and the team will inherit the settings from the label in an automated fashion - which is preferred over doing it manually.

Figure 1: Sensitivity label scope
Figure 1: Sensitivity label scope

Applying a label on a team does not protect the specific documents in the team. A team often has sensitive content that some people should not be able to access – may it be from inside or outside the organization. If we allow guests in a team, we might use private channels to limit access to where the files are at rest. Additionally, make sure to protect sensitive documents with sensitivity labels and encryption – as that protection follows as the data travels.

Private & Shared channels has a separate SharePoint site collection in the backend. The label is inherited from the team and automatically applied. An owner can change the label in a private channel site, which changes nothing in the parent team (and site). The label can’t be removed or replaced in a shared channel site.

Container settings

Managing labels is done from Microsoft Purview (Compliance Center), under Information Protection.

For a step by step guide on the creation of a label: Use sensitivity labels with Microsoft Teams, Microsoft 365 Groups, and SharePoint sites - Microsoft Purview (compliance) | Microsoft Docs

When creating a container scoped label, these are the current options:

  • Privacy: setting public/private enforces that selection when a user creates a team; none lets the user decide on their own.

  • External user access: restrict or allow group owners from inviting guests to the team.

  • External sharing from SharePoint sites: change the sharing setting of the SharePoint site where the label is applied by selecting a more restrictive option than the tenant default.

  • Access from unmanaged devices: override the default value and limit access to the web (limiting the attack surface) or block entirely.

  • Authentication contexts (Preview): enforce more precise access conditions for users accessing SharePoint sites, enabling MFA or a terms-of-use (ToU) policy before accessing the content.

  • Site sharing settings (Preview): Microsoft recommends that only owners of the SharePoint site be allowed to share the site directly and limit the members to sharing content. There’s currently no option from the UI for this, and we need to resort to PowerShell: Configure site sharing permissions by using PowerShell.

  • Default sharing link in SharePoint: change the SharePoint site’s default sharing link by selecting a different option than the tenant default. PowerShell: How to configure settings for the default sharing link type.

Label Creation Considerations

When you create a label, you need to think about the description. It should be very informative and precise for the end-user. It also shows up as a label that you can hover and see that description.

Figure 2: A team with the Highly Sensitive Area label
Figure 2: A team with the Highly Sensitive Area label

Should you incorporate container labels on an existing label taxonomy then?
There’s not much to gain from adding protection to existing content labels. To make it clear for the end-user, the description should be in the context of what the user is doing, and it’s hard to make it sound right for both creating content and creating teams. And even if we create separate labels, it will be the same user experience for an end-user selecting the label.

You publish the created labels, using a Label policy, to the users and groups that should be able to use them. We can also specify a default label and require users to apply a label when they create a team. Requiring that all teams are labeled will help users make a conscious choice about sensitivity when creating a team.

Figure 3: Default label and requiring label assigning in a Label Policy
Figure 3: Default label and requiring label assigning in a Label Policy

My general advice would be to start with three labels for your containers: General Area, Confidential Area, and Highly Confidential Area. The General Area label can be used for teams that are not sensitive.

Examples

My tenant settings are currently:

  • External access: allow guests
  • External sharing: new and existing guests
  • Unmanaged devices: are not limited.
  • Default Sharing link: organization only
  • Site sharing settings: always defaults to that members and owners can share content and the SharePoint site.

General Area

The Privacy is set to None so that the end-user can decide on their own.

Figure 4: General Area privacy
Figure 4: General Area privacy

The tenant level settings regarding external access, external sharing, default sharing link and unmanaged devices are used.

Figure 5: Team with General Area label
Figure 5: Team with General Area label

As per Microsoft’s recommendation, we change the site sharing settings so members can share content, but only site owners can share the site.

Set-Label -Identity "General Area" -AdvancedSettings @{MembersCanShare="MemberShareFileAndFolder"}

Confidential Area

Figure 4: Confidential Area privacy can only be private
Figure 4: Confidential Area privacy can only be private

The tenant level settings regarding external access and external sharing are used.

Figure 5: Team with Confidential Area label
Figure 5: Team with Confidential Area label

We change that unmanaged devices can only access the team and the site via the web.

As per Microsoft’s recommendation, we change the site sharing settings so members can share content, but only site owners can share the site.

Set-Label -Identity "Confidential Area" -AdvancedSettings @{MembersCanShare="MemberShareFileAndFolder"}

We also change the default sharing link to specific users.

Set-Label -Identity "Confidential Area" -AdvancedSettings @{DefaultSharingScope="SpecificPeople"}

Highly confidential Area

Figure 6: Highly Confidential Area privacy can only be private
Figure 6: Highly Confidential Area privacy can only be private

No tenant level settings are used.

Figure 7: Team with Highly Confidential Area label
Figure 7: Team with Highly Confidential Area label

No guests are allowed; sharing can only be done internally, and unmanaged devices are blocked.

We take it one step further and change the site sharing settings so only site owners can share content and the site.

Set-Label -Identity "Highly Confidential Area" -AdvancedSettings @{MembersCanShare="MemberShareNone"}

We also change the default sharing link to specific users.

Set-Label -Identity "Confidential Area" -AdvancedSettings @{DefaultSharingScope="SpecificPeople"}

Finishing up

By now, you should have understood the context around sensitivity labels for containers, why they are great and how to think about their configuration.

You have also learned the importance of making clear descriptions for the end-users. The examples in this post might not be perfect for your organization, but treat them as a starting point where you can adapt.

There are more things to creating a label taxonomy and ensuring the end-users understand the labels for content and containers. But that is an entirely different post.

Thanks for reading
/Simon


Tags

msteamsgovernancesensitivity
Previous Article
When n00bs Fiddle(r) with PowerShell

Simon Ågren

CTA & Microsoft MVP

Solving business problems with tech

Expertise

Microsoft 365
Azure

Social Media

githubtwitterwebsite

Related Posts

A learn more link for sensitivity labels
A learn more link for sensitivity labels
June 10, 2022
2 min

Quick Links

About

Social Media