Beim Thema Security sind mit Azure Purview im Wesentlichen 2 Bereiche zu betrachten. Zum einen der Zugriff auf Azure Purview selber und zum anderen der Bereich Zugriff auf Datenquellen.
Für den Zugriff auf Azure Purview hat Microsoft neue Rollen in der Role Based Access Control (RBAC) geschaffen, welche sich aktuell noch in der Preview befinden.
Benutzer mit der Purview Data Reader Role haben Zugriff auf Azure Purview und können sämtlichen Content innerhalb von Azure Purview lesen.
Über die Rolle Purview Data Curator Role besteht ebenfalls lesender Zugriff auf sämtichen Inhalte von Azure Purview. Zusätzlich können Informationen über Assets, Klassifizierungsdefinitionen (Classifications) sowie Glossarbegriffe (Glossary Terms) bearbeitet werden. Klassifizierungsdefinitionen sowie Glossarbegriffe können wiederum auch auf Assets angewendet werden.
Mit der weiteren neuen Rolle, der Purview Data Source Administrator Role, besteht kein Zugriff auf das Portal selber. Hierfür müsste eine Benutzer zusätzlich auch noch in der Rolle Data Reader oder Data Contributor enthalten sein. Diese Rolle dient dazu, den gesamten Vorgang des Scannens von Datenquellen einzurichten und zu verwalten.
Eine gute Auflistung wann welchem Benutzer welche Rolle zuzuweisen ist, ist in den Microsoft Docs “Who should be assigned to what role?” zu finden.
Grundsätzlich ist zu beachten, dass der Ersteller eines neuen Purview Accounts so behandelt wird, als wären ihm die beiden Rollen Purview Data Creator Role und Purview Data Source Administrator Role zugeordnet. Tatsächlich ist der Ersteller des Accounts im Role Store jedoch nicht diesen Rollen zugeordnet, sondern bekommt diese Rollen automatisch über Purview anhand des Prinicples zugeordnet.
Auch wenn Azure Purview im Management Center einen Bereich Access Control hat, können Zugriffsberechtigungen aktuell nur über die Access Control (IAM) vergeben werden.
Wird später innerhalb von Azure Purview eine Azure Data Factory Connection eingerichtet, so wird der Principal der entsprechende ADF automatisch der Rolle Purview Data Contributor hinzugefügt.
Die jeweiligen Rollen können natürlich nicht nur über das Portal, sondern auch via PowerShell vergeben werden:
# RoleAssignment.ps1
$user = Get-AzADUser -UserPrincipalName "<UserPrincipalName>"
$role = Get-AzRoleDefinition -Name "Purview Data Reader"
$resource = Get-AzResource -Name "<ResourceName>"
New-AzRoleAssignment -ObjectId $user.Id `
-RoleDefinitionName $role.Name `
-Scope $resource.IdUm mit Purview auf Datenquellen zuzugreifen, gibt es je nach Datenquelle zwei verschiedene Möglichkeiten. Zum einen kann auf die Datenquelle über eine Managed Identity zugegriffen werden, zum anderen können auch die quellspezifischen Credentials direkt angegeben werden.
Die Verwendung einer Managed Identity ist – sofern möglich – in der Regel zu empfehlen, da so über das zentrale AAD die besten Managementfunktionen bestehen. Es kann für den Zugriff – wieder je nach Service – die Purview eigene Managed Identity (Purview MSI) verwendet werden oder eine Managed Identity dafür erstellt werden. In beiden Fällen muss der entsprechenden Managed Identity Zugriff auf die zu konfigurierende Source erteilt werden. Hier ist zu beachten, welche Rollen Azure Purview auf den jeweiligen Dienst benötigt. Bei einem Azure Data Lake Gen2 sind z.B. über die Access Control (IAM) mindestens die Storage Blob Data Reader Berechtigungen zu gewähren.
Soll eine Source eigene Authentifizierung verwendet werden, wie z.B. ein SQL Login, so wird zwingend ein Azure Key Vault benötigt, in dem Azure Purview sämtliche Credentials ablegen kann. Eine entsprechende Verbindung zu einem Azure Key Vault kann beim ersten Anlegen einer Credential erstellt werden oder manuell über das Management Center. Hierfür kann dann im Bereich Credentials die Option Manage Key Vault Connections ausgewählt werden.
Aktuell ist dabei zu beachten, dass ein Azure Key Vault in Purview nur angelegt und gelöscht, aber nicht nachträglich wieder bearbeitet werden kann. Ich hoffe, dass die Bearbeitung in einer der nächsten Versionen auch ermöglicht wird.
Um einen Azure Key Vault zu definieren, muss Azure Purview im Key Vault selber als Application den Access Policies hinzugefügt werden. Beim Erstellen eines neuen key Vaults in Purview wird dafür im unteren Bereich eine Info Box angezeigt, in der neben dem Managed Identity Namen von Azure Purview auch die Object ID und die Application ID zu finden sind – im Screenshot unten in Rot gekennzeichnet. Verwenden Sie die entsprechende ID um Azure Purview im Key Vault die notwendigen Access policies zuzuordnen.
Sämtliche Quellspezifische Credentials können in Purview nur über den Azure Key Vault verwendet werden. Aus meiner Sicht eine konsequente Umsetzung für ein Data Governance Tool.
Credentials selber können nachträglich bearbeitet werden, so dass z.B. auf ein anderes Secret verwiesen oder die Version explizit definiert werden kann.
