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.

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

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.
• Die RLS-Abfrage kann nicht auf Tabellen verweisen, die sich in anderen Datenbanken befinden.

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.

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

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

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.