Sensitivity Labels pentru Microsoft Entra security groups au ajuns în preview și, sincer, mi se pare foarte bun. Nu pentru că etichetele securizează magic un grup. Nu o fac. Ci pentru că grupurile de access control au fost ani de zile un punct slab de guvernanță, iar Microsoft începe în sfârșit să trateze obiectele de identitate ca pe ceva ce merită clasificat, nu doar documentele și Teams.
Asta contează dacă administrezi un tenant mare, unde security groups decid cine primește acces la aplicații, trasee administrative și sisteme interne sensibile. Grupul în sine poate să nu conțină date de business, dar membership-ul decide adesea totul. Un model de clasificare consecvent pentru aceste grupuri era demult necesar.
Ce face de fapt această funcție
Acest preview îți permite să atribui etichete Microsoft Purview sensitivity labels unor cloud security groups suportate în Microsoft Entra ID. Etichetele vin din același model de labeling folosit deja pentru containere și trebuie publicate cu scope-ul Groups & Sites.
Punctul important este simplu: eticheta nu schimbă singură permisiunile grupului. Ce schimbă este modul în care Entra validează operațiile de membership față de politica asociată etichetei.
De exemplu, dacă o etichetă blochează guest access, adăugarea unui guest într-un grup etichetat astfel este blocată. Microsoft evaluează și regulile pentru nested groups, iar aici lucrurile devin mai interesante decât la Microsoft 365 group labeling.
Asta face funcția mai mult decât metadata frumoasă; devine guvernanță de identitate susținută de policy. Dacă faci deja un audit de AI și automation sau revizuiești accesul privilegiat răspândit prin tenant, exact acest tip de control merită pus pe listă.
De ce este diferit față de etichetele pentru Microsoft 365 groups
La Microsoft 365 groups, sensitivity labels țin în principal de containerul de colaborare: privacy, guest access, comportamentul site-ului, setări legate de Teams.
La security groups, scopul este altul. Acestea sunt obiecte de autorizare. Un child group nested, cu reguli mai permisive, poate deveni o cale indirectă de ocolire, așa că Microsoft impune compatibilitatea etichetelor în întreaga ierarhie.
Iată diferențele practice din Microsoft Learn:
| Comportament | Microsoft 365 groups | Cloud security groups |
|---|---|---|
| Schimbare etichetă | Poate fi schimbată sau eliminată | Nu poate fi schimbată sau eliminată în preview |
| Nested groups | Nu sunt suportate | Sunt suportate, dar child label trebuie să fie egală sau mai restrictivă |
| Nested members existenți la momentul etichetării | Nu este relevant | Trebuie eliminați înainte de etichetarea părintelui |
| Bypass pentru privilegii ridicate | Adminii respectă politicile etichetelor | Unele roluri de admin și unele aplicații pot ocoli regulile în preview |
Ultimul rând este cel pe care eu nu l-aș ignora. Pentru majoritatea organizațiilor, funcția este utilă și azi. Dar dacă ai construit procese stricte bazate pe enforcement-ul etichetelor, verifică exact ce trasee administrative privilegiate și ce app permissions încă pot ocoli controlul în perioada de preview.
Capcana: etichetele sunt imuabile
Aici este marele risc operațional.
În preview, după ce aplici o sensitivity label pe un cloud security group, nu o mai poți schimba sau elimina. Microsoft Learn este foarte clar aici. Dacă ai ales greșit, soluția este să creezi un grup nou cu eticheta corectă și să muți membership-ul.
Deci da, îmi place funcția. Dar aș începe cu un pilot pe grupuri noi sau pe grupuri de acces cu risc mai mic, unde reconstruirea este acceptabilă. M-aș mira ca multe tenant-uri mature să vrea să relabel-uiască lejer grupuri critice în aceste condiții.
Mai merită reținut:
- sunt suportate doar cloud security groups
- security groups cu dynamic membership nu sunt suportate
- etichetele trebuie sincronizate în Entra, iar Microsoft spune că asta poate dura până la 24 de ore după sync
- dacă un grup are deja nested groups, trebuie să le scoți înainte să etichetezi grupul părinte
Cum îl activezi
Security groups folosesc un directory settings template separat față de Microsoft 365 groups. Chiar dacă ai activat deja labels pentru M365 groups, tot trebuie să activezi template-ul Group.Security și să setezi EnableMIPLabels pe True.
Acesta este cel mai util fragment de configurare din Microsoft Learn:
Connect-MgGraph -Scopes "Directory.ReadWrite.All"
$params = @{
templateId = "d209f6fa-3839-4d70-b83f-60b1c64d0e8f"
values = @(
@{
name = "AllowToAddGuests"
value = "True"
}
@{
name = "EnableMIPLabels"
value = "True"
}
)
}
New-MgBetaDirectorySetting -BodyParameter $params
Mai trebuie să rulezi și label sync din Security and Compliance PowerShell:
Execute-AzureAdLabelSync
Dacă introduci asta în PowerShell și Azure automation sau în fluxurile interne de provisioning, fă-l ca infrastructură repetabilă din prima. Eu nu l-aș lăsa ca setare făcută manual din portal.
Cum atribui eticheta cu Graph PowerShell
Microsoft suportă și atribuirea etichetei la crearea grupului sau pe un grup existent:
$param = @{
description = "Finance access group"
displayName = "Finance Access"
mailEnabled = $false
securityEnabled = $true
mailNickname = "FinanceAccess"
assignedLabels = @(
@{ "LabelId" = "<labelID>" }
)
}
New-MgBetaGroup @param
$assignedLabels = @(
@{ "LabelId" = "<labelID>" }
)
Update-MgBetaGroup -GroupId <groupId> -AssignedLabels $assignedLabels
Dacă echipa ta construiește deja tooling intern de identitate sau custom MCP servers pentru administrare Microsoft 365, acesta este genul de control mic dar foarte util pe care eu l-aș expune în astfel de workflow-uri.
Părerea mea
Acesta este unul dintre acele preview features care rezolvă o problemă reală fără să pretindă că este mai mult decât este. Nu înlocuiește entitlement management, access reviews sau designul corect al rolurilor. Dar adaugă un strat de guvernanță care lipsea pentru grupurile ce controlează în tăcere prea mult acces.
Concluzia mea practică: merită folosit, dar începe cu o strategie de labeling restrânsă, evită mai întâi grupurile vechi și complicate cu nesting, și pornește de la ideea că anumite comportamente din preview se vor schimba înainte de GA.
