Få kontroll och säkra dina Teams team

Det är många organisationer som rullat ut Teams i stor utsträckning där samarbete involverande externa parter är expansivt. Det sker ibland utan att organisationerna begränsar skapandet av Teams team, det vill säga de underliggande Microsoft 365-grupperna som man applicerar Teams på, vilket innebär att användarna kan skapa dem fritt. Det leder till att mängden grupper och team ökar snabbt, att det genereras samarbetsplatser med snarlika namn, man vet inte riktigt var man kan hitta viss information eller i vilket team det går att göra vad. Man tappar helt enkelt kontrollen.

För att hantera situationen är det vanligt att välja olika strategier eller tillvägagångssätt för att vända på utvecklingen. Man ändrar högst sannolikt sina inställningar för EnableGroupCreation i AzureADDirectorySettingTemplate så endast ett urval av konton har möjlighet att skapa grupper/team, man ser över sina gruppinställningar i Azure AD såsom naming policy och group expirations med mera. Sist men inte minst automation av hela den här Teams-processen genom ett flöde skapat med Microsoft Graph eller det mer lätthanterliga (för oss icke-utvecklare) Power Automate tillsammans med Forms.

Men nu tänkte jag ju lyfta fram extern delning i Microsoft 365 och Teams och hur du kan göra det enkelt och säkert i dina team. Först och främst behöver man känna till inställningarna som avgör huruvida det är möjligt eller inte, samt på vilket sätt om det tillåts. Utan att gå djupare in på detaljer så handlar det om den organisatoriska inställningen för extern delning, som konfigureras för både SharePoint och OneDrive, samt den underliggande inställningen per site. De kallas org-wide setting och site-level sharing setting.

Organisationsnivå SharePoint och OneDrive

Övergripande delningsinställningar

Beroende på vad du skapar för typ av site så kommer den sistnämnda site-level sharing-inställningen att skilja sig åt. Vid skapandet av en ny site får exempelvis en klassisk SharePoint site ”Only people in your organization” som standardinställning, en personlig OneDrive har alltid ”Anyone”, medan en site associerad till en Microsoft 365 grupp ”New and existing guests”. Det vill säga, så länge man har aktiverat att gruppägare får lägga till externa personer i de grupperna för annars skulle det ändras till ”Existing guests only”.

Man kan alltså som organisation tillåta delning av filer till vilken utomstående som helst med den organisatoriska inställningen, men om man som användare skulle vara inne i en Communication site till exempel så skulle det mest tillåtande delningsalternativet i biblioteket ändå inte vara tillgängligt, om nu inte någon varit där och ändrat förstås.

Site-nivå

Delningsinställningar per site

Vänta lite nu, jag hänger inte med...

Precis, det är ganska krångligt och därför tänkte jag berätta lite mer om känslighetsetiketter för containrar som hjälper till att hålla reda på det här. Det är nog vanligare att man känner igen dem från sitt engelska namn sensitivity labels, men i det här fallet för containers. Skydd och klassificering av dokument med sensitivity labels har ju funnits under lång tid och många kanske tänker på begreppen AIP eller MIP även om dagens officiella namn är Microsoft Purview Information Protection, där till exempel AIP ingår.

Vad är då känslighetsetiketter för containrar? Det är alltså en label eller etikett som man använder på grupper, team och siter. Men till skillnad från de mer etablerade etiketterna där klassning och skydd appliceras på dokument så handlar det i stället om att skapa en fördefinierad mall med vilka inställningar, möjligheter, begränsningar och funktioner det ska finnas i ett specifikt team.

Nedanför är vad som kan konfigureras i en känslighetsetikett för en container.

Privacy (public or private) of Teams sites and Microsoft 365 groups
- Ska man ansluta till teamet med eller utan godkännande?
Externaluser access
- Ska det tillåtas externa personer i teamet?

External sharing from SharePoint sites
- Ska dokument få delas externt och vilken delningsnivå gäller?
Access from unmanaged devices
- Ska personer som ansluter med en dator som inte är hanterad blockas helt eller få en begränsad upplevelse?
Authentication contexts (in preview)
- Ska conditional access policies, som öppnar upp mängder av kontroller, knytas till etiketten?
Default sharing link for a SharePoint site (PowerShell-only configuration)
- Vilken typ av delningslänk ska vara förvald om delning tillåts?
In preview: Site sharing settings (PowerShell-only configuration)
- Ska bara ägare kunna dela SharePoint-siten?

Exempel från Microsoft Purview compliance portal med en strikt authentication context tilldelad. För att få tillgång till ett team som har den här etiketten behöver man acceptera terms of use, verifiera med ännu en MFA, enheten måste uppfylla organisationens krav och efter två timmar upphör sessionen.
IT-Total_M365_Teams_Bild1-png

Sensitivity labels är fantastiska och det blir inte sämre av att det finns för grupper, team och siter. Det är dessutom toppen att man kan skriva några rader i själva etiketten om vad man som användare kan förvänta sig i just det teamet. Det underlättar enormt för alla gruppmedlemmar. Inom en snar framtid kommer det bli möjligt att välja en standardetikett på ett SharePoint-bibliotek så filer som laddas upp eller modifieras ärver den känslighetsetiketten, det vill säga den mer vanligt förekommande känslighetsetiketten för dokument. Plötsligt har vi då även skydd på våra filer som ligger i teamet. Har man sedan tidigare en mängd data i sitt bibliotek så kan man använda auto-labeling för att skydda sin data at rest.

Den här artikeln fokuserar på sensitivity labels för containers, men det finns förstås fler verktyg att använda sig av för att säkra upp det externa samarbetet. Det tar jag upp vid ett senare tillfälle.

Några heads-up är att funktioner i preview ofta har vissa begränsningar eller kan komma att ändras innan publik introduktion. Och när det kommer till en person med rollen Ägare så har de behörighet att ändra eller ta bort känslighetsetiketten från en container, därav viktigt att man involverar sin organisation innan implementering. Något jag märkte i helgen är att auto-labeling inte fungerar på siter med shared channels, men om det är en bugg eller brist i funktionalitet återstår att se.