Nové „vlastní atributy zabezpečení“ v Azure AD a jejich využití

Definice vlastních atributů v Active Directory (tedy rozšíření schématu AD) a jejich využívání není žádnou novinkou, i když je administrátoři příliš v oblibě nemají. S příchodem Azure Active Directory je možné tyto (případně i další ale defaultně nesynchronizované) atributy synchronizovat z místního AD do Azure AD pomocí Azure AD Connect serveru jako tzv. „Directory Extensions“.

Tyto atributy je možné použít například pro vytváření dynamických skupin nebo je načítat pomocí Microsoft Graph API. Jen ty názvy ve formátu „extension__atribut“ jsou trochu neintuitivní.

Directory extension atributy také nelze dále využívat pro řízení přístupu ke zdrojům. A tím se dostáváme k hlavnímu tématu dnešního článku, kterým jsou

Custom Security Attributes

Vlastní atributy zabezpečení jsou svým způsobem univerzálnější a v tomto okamžiku je možné je nastavovat pro objekty typu „User“, „Azure AD Enterprise Application (service principals)“ a „Managed Identities“. Další výhodou je možnost definovat také multivalue nebo boolean atributy.

S novou funkcionalitou (prozatím v Preview) je potřeba počítat také s novými rolemi. Překvapivě ani Global Admin nemá možnost vytvářet definice nových atributů (dokonce ani číst jejich hodnoty), aniž by neměl přidělenu roli „Attribute definition administrator“. Nezapomeňte tedy správně navrhnout a nastavit role, včetně role „Attribute definition reader“.

Při pohledu na seznam rolí a fakt, že uživatelé nemají ve výchozím stavu oprávnění číst hodnoty atributů zabezpečení je jasné, že jejich využívání se bude lišit od doposud používaných zvyklostí.

Atributy budeme patrně nejčastěji používat třeba pro

• Ukládání citlivých informací přímo do Azure AD;
• Reporty a kategorizace aplikací;
• Definici úrovně přístupu k datům ve storage accounts bez nutnosti generování klíčů nebo SAS tokenů na základě podmínek, ve kterých můžeme pracovat s atributy úložiště a/nebo atributy zabezpečení uživatele.

Přípravu a návrh designu nových atributů bychom rozhodně neměli podceňovat, protože podobně jako u rozšíření schématu Active Directory nelze již vytvořené atributy a sady atributů z tenantu odstranit. Lze je pouze deaktivovat a v omezené míře editovat. Mějme na paměti především následující:

• Počet aktivních definic atributů je omezen na 500 na tenant;
• Počet sad atributů je omezen na 500 na tenant;
• Atributy ani sady nelze smazat, je možné je pouze deaktivovat;
• Celkový počet hodnot atributů je omezen na 50 na objekt. Tedy například 5 atributů s 10 hodnotami, nebo 50 atributů s jednou hodnotou;
• Atributy je nutné vkládat do skupin (sad), přičemž jméno sady se pak stává součástí jména atributu samotného;
• Datové typy atributů mohou být „Boolean“, „Integer“ a „String“
• Je možné vynutit pouze povolené (předdefinované) hodnoty;
• Předdefinované hodnoty jsou „case sensitive“ (!);
• Role je možné definovat také na úrovni sady atributů;
• Pro využívání atributů zabezpečení je nutná licence Azure AD Premium P1 nebo P2.

Vytvoření nové sady atributů je jednoduché, jen pamatujete že jméno je definitivní. Maximální počet atributů bude vhodné volit spíše nižší vzhledem k celkovému limitu na celý tenant.

Pokud preferujete PowerShell, lze použít příkaz

New-AzureADMSAttributeSet -Id "Project" -Description "Projektové řízení" -MaxAttributesPerSet 5

Vytvoření nového atributu je podobné, opět věnujte péči názvu, typu i ostatním volbám. Následné změny již většinou nebudou možné. Například volbu předdefinovaných hodnot můžeme dodatečně změnit z Yes na No, ale z No na Yes už nikoliv.

Pokud preferujete PowerShell, lze použít příkaz

New-AzureADMSCustomSecurityAttributeDefinition -AttributeSet "Project" -Name "Priority" -Description "Priorita projektu" -Type "String" -Status "Available" -IsCollection $false -IsSearchable $true -UsePreDefinedValuesOnly $true

Výsledná sada atributů pak může vypadat zhruba takto:

Povolené hodnoty se pro jednotlivé atributy aktualizují dodatečně.

Nastavení atributů uživatelům (nebo třeba registrované aplikaci) tedy obnáší „asignment“ – každému uživateli definujeme přidělené atributy a jejich hodnoty.

Poznámka: Naše testovací uživatelka Adéla je synchronizována z místní Active Directory. Atributy lze nastavit jak synchronizovaným uživatelům, tak uživatelům typu Guest, vzhledem k nastavenému režimu ale patrně nebude možné plnit atributy přímo pomocí AAD Connectu.

Pro filtrování objektů (aplikací nebo uživatelů) pak už můžeme ve filtre snadno použít naše nové atributy.

Poznámka: Při vytváření dynamické skupiny ovšem tyto atributy bohužel prozatím využít nemůžeme.

Pro výpis atributů konkrétního uživatele z PowerShellu můžeme použít příkaz

$adela=Get-AzureADMSUser -Id 4abffe62-1e61-43a0-890b-abd14e9bd11c -Select CustomSecurityAttributes
$adela.CustomSecurityAttributes

A nyní již můžeme začít připravovat výrazně složitější scénáře pro řízení přístupů, které například oproti Azure RBAC a jeho limitu 2000 přidělení rolí umožní na základě podmínek využívající atributy opravdu komplexní řešení. Inspiraci naleznete například na docs.microsoft.com

Zdroj: Microsoft