Freigeben über

Übersicht über die Zugriffssteuerung

  • Artikel

Gilt für: ✅Microsoft Fabric✅Azure Data Explorer

Die Zugriffssteuerung basiert auf Authentifizierung und Autorisierung. Jede Abfrage und jeder Befehl in einer Azure Data Explorer-Ressource, z. B. einem Cluster oder einer Datenbank, muss sowohl Authentifizierungs- als auch Autorisierungsprüfungen bestehen.

Die Zugriffssteuerung basiert auf Authentifizierung und Autorisierung. Jede Abfrage und jeder Befehl in einer Fabric-Ressource, z. B. einer Datenbank, muss sowohl Authentifizierungs- als auch Autorisierungsprüfungen bestehen.

  • Authentifizierungs-: Überprüft die Identität des Sicherheitsprinzipals, der eine Anforderung vornimmt.
  • Autorisierungs-: Überprüft den Sicherheitsprinzipal, der eine Anforderung anfordert, diese Anforderung an die Zielressource zu stellen.

Authentifizierung

Um sich programmgesteuert zu authentifizieren, muss ein Client mit Microsoft Entra ID kommunizieren und ein Zugriffstoken anfordern, das für den Kusto-Dienst spezifisch ist. Anschließend kann der Client das erworbene Zugriffstoken als Identitätsnachweis verwenden, wenn Anforderungen an Ihre Datenbank ausgestellt werden.

Die wichtigsten Authentifizierungsszenarien sind wie folgt:

  • Benutzerauthentifizierung: Wird verwendet, um die Identität von menschlichen Benutzern zu überprüfen.
  • Anwendungsauthentifizierung: Wird verwendet, um die Identität einer Anwendung zu überprüfen, die ohne menschliche Intervention auf Ressourcen zugreifen muss, indem konfigurierte Anmeldeinformationen verwendet werden.
  • Authentifizierung im Auftrag von (OBO): Ermöglicht einer Anwendung das Austauschen eines Tokens für die besagte Anwendung mit einem Token für den Zugriff auf einen Kusto-Dienst. Dieser Fluss muss mit MSAL implementiert werden.
  • Single Page Application (SPA)-Authentifizierung: Ermöglicht es clientseitigen SPA-Webanwendungen, Benutzer anzumelden und Token für den Zugriff auf Ihre Datenbank abzurufen. Dieser Fluss muss mit MSAL implementiert werden.

Anmerkung

Für die Benutzer- und Anwendungsauthentifizierung empfehlen wir die Verwendung der Kusto-Clientbibliotheken. Wenn Sie eine Authentifizierung im Auftrag von (OBO) oder Single-Page Application (SPA) erfordern, müssen Sie MSAL direkt verwenden, da die Clientbibliotheken diese Flüsse nicht unterstützen. Weitere Informationen finden Sie unter Authenticate with Microsoft Authentication Library (MSAL).

Benutzerauthentifizierung

Die Benutzerauthentifizierung erfolgt, wenn ein Benutzer Anmeldeinformationen für Microsoft Entra-ID oder einen Identitätsanbieter anzeigt, der mit Microsoft Entra-ID verbunden ist, z. B. Active Directory-Verbunddienste. Der Benutzer erhält ein Sicherheitstoken, das dem Azure Data Explorer-Dienst angezeigt werden kann. Azure Data Explorer bestimmt, ob das Token gültig ist, ob das Token von einem vertrauenswürdigen Aussteller ausgestellt wird und welche Sicherheitsansprüche das Token enthält.

Azure Data Explorer unterstützt die folgenden Methoden der Benutzerauthentifizierung, einschließlich über die Kusto-Clientbibliotheken:

  • Interaktive Benutzerauthentifizierung mit Anmeldung über die Benutzeroberfläche.
  • Benutzerauthentifizierung mit einem Microsoft Entra-Token, das für Azure Data Explorer ausgestellt wurde.
  • Benutzerauthentifizierung mit einem Microsoft Entra-Token, das für eine andere Ressource ausgegeben wird, die mit der Authentifizierung im Auftrag von (OBO) für ein Azure Data Explorer-Token ausgetauscht werden kann.

Anwendungsauthentifizierung

Die Anwendungsauthentifizierung ist erforderlich, wenn Anforderungen keinem bestimmten Benutzer zugeordnet sind oder wenn kein Benutzer zum Bereitstellen von Anmeldeinformationen verfügbar ist. In diesem Fall authentifiziert sich die Anwendung bei der Microsoft Entra-ID oder dem Partner-IDP, indem geheime Informationen präsentiert werden.

Azure Data Explorer unterstützt die folgenden Methoden der Anwendungsauthentifizierung, einschließlich über die Kusto-Clientbibliotheken:

  • Anwendungsauthentifizierung mit einer von Azure verwalteten Identität.
  • Anwendungsauthentifizierung mit einem lokal installierten X.509v2-Zertifikat.
  • Anwendungsauthentifizierung mit einem X.509v2-Zertifikat, das der Clientbibliothek als Bytestream zugewiesen wird.
  • Anwendungsauthentifizierung mit einer Microsoft Entra-Anwendungs-ID und einem Microsoft Entra-Anwendungsschlüssel. Die Anwendungs-ID und der Anwendungsschlüssel sind wie ein Benutzername und ein Kennwort.
  • Anwendungsauthentifizierung mit einem zuvor erhaltenen gültigen Microsoft Entra-Token, ausgestellt für Azure Data Explorer.
  • Anwendungsauthentifizierung mit einem Microsoft Entra-Token, das für eine andere Ressource ausgegeben wird, die mit der Authentifizierung im Auftrag von (OBO) für ein Azure Data Explorer-Token ausgetauscht werden kann.

Ermächtigung

Bevor Sie eine Aktion für eine Ressource ausführen, müssen alle authentifizierten Benutzer eine Autorisierungsprüfung bestehen. Das rollenbasierten Kusto-Zugriffssteuerung Modell wird verwendet, wobei Prinzipale einer oder mehreren Sicherheitsrollen zugeordnet werden. Die Autorisierung wird gewährt, solange eine der dem Benutzer zugewiesenen Rollen die ausführung der angegebenen Aktion ermöglicht. Beispielsweise gewährt die Datenbankbenutzerrolle Sicherheitsprinzipale das Recht, die Daten einer bestimmten Datenbank zu lesen, Tabellen in der Datenbank zu erstellen und vieles mehr.

Die Zuordnung von Sicherheitsprinzipalen zu Sicherheitsrollen kann einzeln oder mithilfe von Sicherheitsgruppen definiert werden, die in der Microsoft Entra-ID definiert sind. Weitere Informationen zum Zuweisen von Sicherheitsrollen finden Sie unter Übersicht über Sicherheitsrollen.

Gruppenautorisierung

Die Autorisierung kann Microsoft Entra-ID-Gruppen erteilt werden, indem sie der Gruppe eine oder mehrere Rollen zuweisen.

Beim Überprüfen der Autorisierung für einen Benutzer oder Anwendungsprinzipal sucht das System zuerst nach einer expliziten Rollenzuweisung, die die spezifische Aktion zulässt. Wenn die Rollenzuweisung nicht vorhanden ist, überprüft das System die Mitgliedschaft des Prinzipals in allen Gruppen, die die Aktion autorisieren könnten.

Wenn der Prinzipal Mitglied einer Gruppe mit entsprechenden Berechtigungen ist, wird die angeforderte Aktion autorisiert. Andernfalls besteht die Aktion nicht an der Autorisierungsprüfung und ist unzulässig.

Anmerkung

Die Überprüfung von Gruppenmitgliedschaften kann ressourcenintensiv sein. Da sich Gruppenmitgliedschaften nicht häufig ändern, werden die Ergebnisse der Mitgliedschaftsprüfung zwischengespeichert. Die Zwischenspeicherungsdauer variiert und bestimmt, wie schnell Änderungen an Gruppenmitgliedschaften aktualisiert werden. Das Hinzufügen eines Benutzers zu einer Gruppe kann bis zu 30 Minuten dauern, bis er verteilt wird. Das Entfernen eines Benutzers aus einer Gruppe kann bis zu drei Stunden dauern.

Erzwingen der Aktualisierung der Gruppenmitgliedschaft

Prinzipale können eine Aktualisierung von Gruppenmitgliedschaftsinformationen erzwingen. Diese Funktion ist in Szenarien hilfreich, in denen just-in-time(JIT) privilegierte Zugriffsdienste wie Microsoft Entra Privileged Identity Management (PIM) verwendet werden, um höhere Berechtigungen für eine Ressource zu erhalten.

Aktualisieren für eine bestimmte Gruppe

Prinzipale können eine Aktualisierung der Gruppenmitgliedschaft für eine bestimmte Gruppeerzwingen. Die folgenden Einschränkungen gelten jedoch:

  • Eine Aktualisierung kann bis zu 10 Mal pro Stunde pro Prinzipal angefordert werden.
  • Der anfordernde Prinzipal muss zum Zeitpunkt der Anforderung Mitglied der Gruppe sein.

Die Anforderung führt zu einem Fehler, wenn eine dieser Bedingungen nicht erfüllt ist.

Führen Sie den folgenden Befehl aus, um die Mitgliedschaft des aktuellen Prinzipals einer Gruppe neu zu bewerten:

Ersetzen Sie im folgenden Beispiel <GroupFQN> durch ihre eigenen Werte, z. B. group='aadGroup=MyGroup@MyOrg.com'.

.clear cluster cache groupmembership with (group='<GroupFQN>')

Verwenden Sie den vollqualifizierten Namen der Gruppe (FQN). Weitere Informationen finden Sie unter Verweisen auf Microsoft Entra-Prinzipale und Gruppen.

Aktualisieren für andere Prinzipale

Ein privilegierter Prinzipal kann eine Aktualisierungs-für andere Prinzipaleanfordern. Der anfordernde Prinzipal muss über AllDatabaseMonitor Zugriff für den Zieldienst verfügen. Privilegierte Prinzipale können auch den vorherigen Befehl ohne Einschränkungen ausführen.

Führen Sie den folgenden Befehl aus, um die Gruppenmitgliedschaft eines anderen Prinzipals zu aktualisieren:

Ersetzen Sie im folgenden Befehl <PrincipalFQN> durch Ihren eigenen vollqualifizierten Prinzipalnamen (Fully Qualified Name, FQN) und <GroupFQN> durch Ihren eigenen Gruppen-FQN, z. B. principal='aadUser=UserUpn@MyOrg.com', group='aadGroup=MyGroup@MyOrg.com'. Weitere Informationen finden Sie unter Verweisen auf Microsoft Entra-Prinzipale und Gruppen.

.clear cluster cache groupmembership with (principal='<PrincipalFQN>', group='<GroupFQN>')

Verwandte Inhalte