Share via

Übersicht über die Zugriffssteuerung

  • Artikel

Die Zugriffssteuerung von Azure Data Explorer 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.

  • Authentifizierung: Überprüft die Identität des Sicherheitsprinzipals, der eine Anforderung sendet
  • Autorisierung: Überprüft, ob der Sicherheitsprinzipal, der eine Anforderung sendet, diese Anforderung an die Zielressource senden darf.

Authentifizierung

Für die programmgesteuerte Authentifizierung bei Ihrem Cluster muss ein Client mit Microsoft Entra ID kommunizieren und ein Zugriffstoken speziell für Azure Data Explorer anfordern. Anschließend kann der Client das erworbene Zugriffstoken als Identitätsnachweis verwenden, wenn Anforderungen an Ihren Cluster ausgestellt werden.

Die Standard 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 menschliches Eingreifen auf Ressourcen zugreifen muss, indem konfigurierte Anmeldeinformationen verwendet werden.
  • OBO-Authentifizierung (On-Behalf-of): Ermöglicht es einer Anwendung, ein Token für diese Anwendung mit einem Token für den Zugriff auf einen Kusto-Dienst auszutauschen. Dieser Flow muss mit MSAL implementiert werden.
  • Single-Page-Anwendungsauthentifizierung (Single Page Application, SPA): Ermöglicht clientseitigen SPA-Webanwendungen das Anmelden von Benutzern und das Abrufen von Token für den Zugriff auf Ihren Cluster. Dieser Flow muss mit MSAL implementiert werden.

Hinweis

Für die Benutzer- und Anwendungsauthentifizierung wird die Verwendung der Kusto-Clientbibliotheken empfohlen. Wenn Sie die Authentifizierung von On-behalf-of (OBO) oder Single-Page Application (SPA) benötigen, müssen Sie MSAL direkt verwenden, da diese Flows von den Clientbibliotheken nicht unterstützt werden. Weitere Informationen finden Sie unter Authentifizieren mit der Microsoft Authentication Library (MSAL).

Benutzerauthentifizierung

Die Benutzerauthentifizierung erfolgt, wenn ein Benutzer Anmeldeinformationen an Microsoft Entra ID oder einen Identitätsanbieter vorgibt, der mit Microsoft Entra ID verbunden ist, z. B. Active Directory-Verbunddienste (AD FS). Der Benutzer erhält ein Sicherheitstoken zurück, 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 für Azure Data Explorer ausgestellten Microsoft Entra-Token.
  • Benutzerauthentifizierung mit einem Microsoft Entra Token, das für eine andere Ressource ausgestellt wird und mithilfe der OBO-Authentifizierung (On-behalf-of) gegen ein Azure Data Explorer-Token ausgetauscht werden kann.

Anwendungsauthentifizierung

Die Anwendungsauthentifizierung ist erforderlich, wenn Anforderungen nicht einem bestimmten Benutzer zugeordnet sind oder wenn kein Benutzer verfügbar ist, um Anmeldeinformationen bereitzustellen. In diesem Fall authentifiziert sich die Anwendung bei Microsoft Entra ID oder dem Verbund-IdP, indem geheime Informationen angezeigt werden.

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

  • Anwendungsauthentifizierung mit einer verwalteten Azure-Identität.
  • Anwendungsauthentifizierung mit lokal installiertem 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 abgerufenen gültigen Microsoft Entra Token, das für Azure Data Explorer ausgestellt wurde.
  • Anwendungsauthentifizierung mit einem Microsoft Entra Token, das für eine andere Ressource ausgestellt wird und mithilfe der OBO-Authentifizierung (On-behalf-of) gegen ein Azure Data Explorer-Token ausgetauscht werden kann.

Authorization

Vor dem Ausführen einer Aktion für eine Azure Data Explorer-Ressource müssen alle authentifizierten Benutzer eine Autorisierungsprüfung bestehen. Azure Data Explorer verwendet das rollenbasierte Zugriffssteuerungsmodell von Kusto, bei dem Prinzipale mindestens einer Sicherheitsrolle zugeordnet werden. Die Autorisierung wird gewährt, solange eine der dem Benutzer zugewiesenen Rollen das Ausführen der angegebenen Aktion ermöglicht. Beispielsweise gewährt die Rolle Datenbankbenutzer Sicherheitsprinzipalen 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 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 der Gruppe eine oder mehrere Rollen zugewiesen werden.

Wenn die Autorisierung eines Benutzers oder Anwendungsprinzipals überprüft wird, überprüft das System zunächst auf eine explizite Rollenzuweisung, die die jeweilige Aktion zulässt. Wenn keine solche Rollenzuweisung vorhanden ist, analysiert das System die Mitgliedschaft des Prinzipals über alle Gruppen hinweg, die die Aktion möglicherweise autorisieren könnten. Wenn bestätigt wird, dass der Prinzipal Mitglied einer dieser Gruppen ist, wird die angeforderte Aktion autorisiert. Andernfalls besteht die Aktion nicht, wenn der Prinzipal kein Mitglied solcher Gruppen ist, die Autorisierungsprüfung nicht, und die Aktion ist nicht zulässig.

Hinweis

Die Überprüfung von Gruppenmitgliedschaften kann ressourcenintensiv sein. Da sich Gruppenmitgliedschaften nicht häufig ändern, werden die Ergebnisse der Mitgliedschaftsüberprüfungen zwischengespeichert. Die Zwischenspeicherdauer variiert und wird durch Faktoren wie das Mitgliedschaftsergebnis (ob der Prinzipal ein Mitglied ist oder nicht), der Typ des Prinzipals (Benutzer oder Anwendung) beeinflusst. Die maximale Zwischenspeicherungsdauer kann bis zu drei Stunden betragen, während die Mindestdauer 30 Minuten beträgt.

Verwandte Inhalte