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

 
 Jan Žák

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í.

img

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“.

img

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.

img

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.

Obsah obrázku text  Popis byl vytvořen automaticky

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.

Obsah obrázku text  Popis byl vytvořen automaticky

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:

img

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

img

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.

img

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.

img

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

Obsah obrázku text  Popis byl vytvořen automaticky

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

Diagram of role assignment with a condition.

Diagram of access is not allowed with a condition. Zdroj: Microsoft

Sdílej v médiích

nove-vlastni-atributy-zabezpeceni-v-azure-ad-a-jejich-vyuziti

Kontakt

Nenašli jste, co hledáte? Pošlete nám zprávu a zůstaneme s vámi ve spojení.

* Vyžadované pole. Osobní data použijeme pouze pro vypracování odpovědi na dotaz. Pravidla zpracování osobních údajů.

* Souhlas se zpracováním údajů

map us
map eu