Freigeben über


Sicherheitsrichtlinie auf Zeilenebene

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

Verwenden Sie gruppenmitgliedschafts- oder Ausführungskontext, um den Zugriff auf Zeilen in einer Datenbanktabelle zu steuern.

Die Sicherheit auf Zeilenebene (Row-Level Security, RLS) vereinfacht das Entwerfen und Programmieren der Sicherheit. Damit können Sie Einschränkungen für den Datenzeilenzugriff in Ihrer Anwendung anwenden. Beschränken Sie beispielsweise den Benutzerzugriff auf Zeilen, die für ihre Abteilung relevant sind, oder beschränken Sie den Kundenzugriff nur auf die daten, die für ihr Unternehmen relevant sind.

Die Zugriffsbeschränkungslogik befindet sich auf der Datenbankebene und nicht auf einer anderen, von den Daten getrennten Anwendungsebene. Das Datenbanksystem wendet die Zugriffsbeschränkungen jedes Mal an, wenn der Datenzugriff von einer beliebigen Ebene aus versucht wird. Diese Logik macht Ihr Sicherheitssystem zuverlässiger und robuster, indem die Fläche Ihres Sicherheitssystems reduziert wird.

Mit RLS können Sie Zugriff auf andere Anwendungen und Benutzer gewähren, nur auf einen bestimmten Teil einer Tabelle. Auf diese Weise können Sie z. B. folgende Vorgänge durchführen:

  • Gewähren des Zugriffs nur auf Zeilen, die einige Kriterien erfüllen
  • Anonymisieren von Daten in einigen Spalten
  • Alle oben genannten Aussagen sind zutreffend.

Hinweis

Wenn eine RLS-Richtlinie für eine Tabelle aktiviert ist, wird der Zugriff vollständig durch die RLS-Abfrage ersetzt, die in der Tabelle definiert ist. Die Zugriffsbeschränkung gilt für alle Benutzer, einschließlich Datenbankadministratoren und dem Ersteller von RLS. Die RLS-Abfrage muss explizit Definitionen für alle Benutzertypen enthalten, auf die Sie Zugriff gewähren möchten.

Weitere Informationen finden Sie unter Verwaltungsbefehle zum Verwalten der Sicherheitsrichtlinie auf Zeilenebene.

Tipp

Diese Funktionen sind häufig für row_level_security Abfragen nützlich:

Begrenzungen

  • Es gibt keine Beschränkung für die Anzahl der Tabellen, für die die Richtlinie für die Sicherheit auf Zeilenebene konfiguriert werden kann.
  • Die Sicherheitsrichtlinie auf Zeilenebene kann in externen Tabellen nicht konfiguriert werden.
  • Die RLS-Richtlinie kann unter folgenden Umständen nicht in einer Tabelle aktiviert werden:
    • Wenn sie von einer Aktualisierungsrichtlinienabfrage referenziert wird, während die Updaterichtlinie nicht mit einer verwalteten Identität konfiguriert ist.
    • Wenn auf einen fortlaufenden Export verwiesen wird, der eine andere Authentifizierungsmethode als Identitätswechsel verwendet.
    • Wenn eine Richtlinie für den Eingeschränkten Ansichtszugriff für die Tabelle konfiguriert ist.

Beispiele

Einschränken des Zugriffs auf die Tabelle "Vertrieb"

In einer Tabelle mit dem Namen Salesenthält jede Zeile Details zu einem Sonderangebot. Eine der Spalten enthält den Namen des Verkäufers. Statt Ihren Vertriebsmitarbeitern Zugriff auf alle Datensätze Saleszu gewähren, aktivieren Sie in dieser Tabelle eine Richtlinie für die Sicherheit auf Zeilenebene, um nur Datensätze zurückzugeben, bei denen der Vertriebsmitarbeiter der aktuelle Benutzer ist:

Sales | where SalesPersonAadUser == current_principal()

Sie können auch die E-Mail-Adresse masken:

Sales | where SalesPersonAadUser == current_principal() | extend EmailAddress = "****"

Wenn jeder Vertriebsmitarbeiter alle Umsätze eines bestimmten Landes/einer bestimmten Region anzeigen soll, können Sie eine Abfrage wie die folgenden definieren:

let UserToCountryMapping = datatable(User:string, Country:string)
[
  "john@domain.com", "USA",
  "anna@domain.com", "France"
];
Sales
| where Country in ((UserToCountryMapping | where User == current_principal_details()["UserPrincipalName"] | project Country))

Wenn Sie über eine Gruppe verfügen, die die Vorgesetzten enthält, möchten Sie ihnen möglicherweise Zugriff auf alle Zeilen gewähren. Hier sehen Sie die Abfrage für die Richtlinie für die Sicherheit auf Zeilenebene.

let IsManager = current_principal_is_member_of('aadgroup=sales_managers@domain.com');
let AllData = Sales | where IsManager;
let PartialData = Sales | where not(IsManager) and (SalesPersonAadUser == current_principal()) | extend EmailAddress = "****";
union AllData, PartialData

Verfügbarmachen verschiedener Daten für Mitglieder verschiedener Microsoft Entra-Gruppen

Wenn Sie über mehrere Microsoft Entra-Gruppen verfügen und die Mitglieder jeder Gruppe eine andere Teilmenge von Daten sehen sollen, verwenden Sie diese Struktur für eine RLS-Abfrage.

Customers
| where (current_principal_is_member_of('aadgroup=group1@domain.com') and <filtering specific for group1>) or
        (current_principal_is_member_of('aadgroup=group2@domain.com') and <filtering specific for group2>) or
        (current_principal_is_member_of('aadgroup=group3@domain.com') and <filtering specific for group3>)

Anwenden derselben RLS-Funktion auf mehrere Tabellen

Definieren Sie zunächst eine Funktion, die den Tabellennamen als Zeichenfolgenparameter empfängt, und verweisen Sie mithilfe des table() Operators auf die Tabelle.

Zum Beispiel:

.create-or-alter function RLSForCustomersTables(TableName: string) {
    table(TableName)
    | ...
}

Konfigurieren Sie dann RLS für mehrere Tabellen auf diese Weise:

.alter table Customers1 policy row_level_security enable "RLSForCustomersTables('Customers1')"
.alter table Customers2 policy row_level_security enable "RLSForCustomersTables('Customers2')"
.alter table Customers3 policy row_level_security enable "RLSForCustomersTables('Customers3')"

Fehler beim nicht autorisierten Zugriff

Wenn Nicht authentifizierte Tabellenbenutzer einen Fehler erhalten sollen, anstatt eine leere Tabelle zurückzugeben, verwenden Sie die assert() Funktion. Das folgende Beispiel zeigt, wie Sie diesen Fehler in einer RLS-Funktion erzeugen:

.create-or-alter function RLSForCustomersTables() {
    MyTable
    | where assert(current_principal_is_member_of('aadgroup=mygroup@mycompany.com') == true, "You don't have access")
}

Sie können diesen Ansatz mit anderen Beispielen kombinieren. Beispielsweise können Sie benutzern in verschiedenen Microsoft Entra-Gruppen unterschiedliche Ergebnisse anzeigen und für alle anderen Benutzer einen Fehler erzeugen.

Steuern von Berechtigungen für Followerdatenbanken

Die in der Produktionsdatenbank konfigurierte RLS-Richtlinie wird auch in den Folgedatenbanken wirksam. Sie können keine unterschiedlichen RLS-Richtlinien für die Produktions- und Folgedatenbanken konfigurieren. Sie können die current_cluster_endpoint() Funktion in Ihrer RLS-Abfrage jedoch verwenden, um denselben Effekt zu erzielen, wie bei unterschiedlichen RLS-Abfragen in Folgetabellen.

Zum Beispiel:

.create-or-alter function RLSForCustomersTables() {
    let IsProductionCluster = current_cluster_endpoint() == "mycluster.eastus.kusto.windows.net";
    let DataForProductionCluster = TempTable | where IsProductionCluster;
    let DataForFollowerClusters = TempTable | where not(IsProductionCluster) | extend EmailAddress = "****";
    union DataForProductionCluster, DataForFollowerClusters
}

Hinweis

Die oben genannte RLS-Funktion hat keinerlei Auswirkungen auf die Leistung auf Abfragen des Leaderclusters. Die Auswirkungen der Leistung auf Abfragen in den Followerclustern werden nur durch die Komplexität beeinflusst DataForFollowerClusters.

Steuern von Berechtigungen für Verknüpfungsdatenbanken

Die in der Produktionsdatenbank konfigurierte RLS-Richtlinie wird auch in den Verknüpfungsdatenbanken wirksam. Sie können keine unterschiedlichen RLS-Richtlinien für die Produktions- und Verknüpfungsdatenbanken konfigurieren. Sie können die current_cluster_endpoint() Funktion in Ihrer RLS-Abfrage jedoch verwenden, um denselben Effekt zu erzielen, wie bei unterschiedlichen RLS-Abfragen in Verknüpfungstabellen.

Zum Beispiel:

.create-or-alter function RLSForCustomersTables() {
    let IsProductionCluster = current_cluster_endpoint() == "mycluster.eastus.kusto.windows.net";
    let DataForProductionCluster = TempTable | where IsProductionCluster;
    let DataForFollowerClusters = TempTable | where not(IsProductionCluster) | extend EmailAddress = "****";
    union DataForProductionCluster, DataForFollowerClusters
}

Hinweis

Die oben genannte RLS-Funktion hat keinerlei Auswirkungen auf die Leistung auf Abfragen in der Quelldatenbank. Die Auswirkungen der Leistung auf Abfragen in den Verknüpfungsdatenbanken werden nur durch die Komplexität von DataForFollowerClusters.

Weitere Anwendungsfälle

  • Ein Supportmitarbeiter des Callcenters kann Anrufer anhand mehrerer Ziffern seiner Sozialversicherungsnummer identifizieren. Diese Nummer sollte der Supportperson nicht vollständig offengelegt werden. Eine RLS-Richtlinie kann auf die Tabelle angewendet werden, um alle vier Ziffern der Sozialversicherungsnummer im Resultset einer abfrage zu maskieren.
  • Legen Sie eine RLS-Richtlinie fest, die persönlich identifizierbare Informationen (PII) maskiert, und ermöglicht Es Entwicklern, Produktionsumgebungen zur Problembehandlung abzufragen, ohne die Compliancebestimmungen zu verletzen.
  • Ein Krankenhaus kann eine RLS-Richtlinie festlegen, mit der Pflegekräfte nur Datenzeilen für ihre Patienten anzeigen können.
  • Eine Bank kann eine RLS-Richtlinie festlegen, um den Zugriff auf Finanzdatenzeilen basierend auf der Geschäftsabteilung oder Rolle eines Mitarbeiters einzuschränken.
  • Eine mehrinstanzenfähige Anwendung kann Daten aus vielen Mandanten in einer einzelnen Tabelle speichern (die effizient ist). Sie würden eine RLS-Richtlinie verwenden, um eine logische Trennung der Datenzeilen jedes Mandanten von den Zeilen jedes anderen Mandanten zu erzwingen, sodass jeder Mandant nur seine Datenzeilen sehen kann.

Auswirkungen auf die Leistung auf Abfragen

Wenn eine RLS-Richtlinie für eine Tabelle aktiviert ist, wirkt sich dies auf Abfragen aus, die auf diese Tabelle zugreifen. Der Zugriff auf die Tabelle wird durch die RLS-Abfrage ersetzt, die in dieser Tabelle definiert ist. Die Leistungsauswirkungen einer RLS-Abfrage bestehen normalerweise aus zwei Teilen:

  • Mitgliedschaftsprüfungen in Microsoft Entra ID: Prüfungen sind effizient. Sie können die Mitgliedschaft in zehn oder sogar Hunderten von Gruppen überprüfen, ohne dass sich die Abfrageleistung erheblich auswirkt.
  • Filter, Verknüpfungen und andere Vorgänge, die auf die Daten angewendet werden: Die Auswirkung hängt von der Komplexität der Abfrage ab.

Zum Beispiel:

let IsRestrictedUser = current_principal_is_member_of('aadgroup=some_group@domain.com');
let AllData = MyTable | where not(IsRestrictedUser);
let PartialData = MyTable | where IsRestrictedUser and (...);
union AllData, PartialData

Wenn der Benutzer nicht Teil des some_group@domain.comBenutzers ist, wird er IsRestrictedUser ausgewertet.false Die ausgewertete Abfrage ähnelt der folgenden:

let AllData = MyTable;           // the condition evaluates to `true`, so the filter is dropped
let PartialData = <empty table>; // the condition evaluates to `false`, so the whole expression is replaced with an empty table
union AllData, PartialData       // this will just return AllData, as PartialData is empty

Ebenso wird, wenn IsRestrictedUser dies ausgewertet truewird, nur die Abfrage PartialData ausgewertet.

Verbessern der Abfrageleistung beim Verwenden von RLS

  • Wenn ein Filter auf eine Spalte mit hoher Kardinalität angewendet wird, z. B. DeviceID, erwägen Sie die Verwendung der Partitionierungsrichtlinie oder zeilenreihenfolgenrichtlinie.
  • Wenn auf eine Spalte mit niedriger mittlerer Kardinalität ein Filter angewendet wird, sollten Sie die Zeilenreihenfolgerichtlinie verwenden .

Auswirkungen der Leistung auf die Aufnahme

Es gibt keine Auswirkungen auf die Leistung bei der Aufnahme.