Beveiligingsbeleid op rijniveau

Van toepassing op: ✅Microsoft Fabric✅Azure Data Explorer-

Gebruik groepslidmaatschap of uitvoeringscontext om de toegang tot rijen in een databasetabel te beheren.

Beveiliging op rijniveau (RLS) vereenvoudigt het ontwerpen en coderen van beveiliging. Hiermee kunt u beperkingen toepassen op toegang tot gegevensrijen in uw toepassing. Beperk bijvoorbeeld gebruikerstoegang tot rijen die relevant zijn voor hun afdeling of beperk klanttoegang tot alleen de gegevens die relevant zijn voor hun bedrijf.

De toegangsbeperkingslogica bevindt zich in de databaselaag, in plaats van de gegevens in een andere toepassingslaag. Het databasesysteem past de toegangsbeperkingen toe telkens wanneer gegevenstoegang vanuit elke laag wordt geprobeerd. Deze logica maakt uw beveiligingssysteem betrouwbaarder en robuuster door het oppervlak van uw beveiligingssysteem te verminderen.

Met RLS kunt u toegang bieden tot andere toepassingen en gebruikers, alleen voor een bepaald gedeelte van een tabel. U kunt bijvoorbeeld het volgende doen:

• Alleen toegang verlenen aan rijen die voldoen aan bepaalde criteria
• Gegevens in sommige kolommen anoniem maken
• Al het bovenstaande

Notitie

Wanneer een RLS-beleid is ingeschakeld voor een tabel, wordt de toegang volledig vervangen door de RLS-query die in de tabel is gedefinieerd. De toegangsbeperking is van toepassing op alle gebruikers, waaronder databasebeheerders en de maker van RLS. De RLS-query moet expliciet definities bevatten voor alle typen gebruikers aan wie u toegang wilt verlenen.

Zie beheeropdrachten voor het beheren van het beveiligingsbeleid op rijniveauvoor meer informatie.

Fooi

Deze functies zijn vaak handig voor row_level_security query's:

• current_principal()
• current_principal_details()
• current_principal_is_member_of()

Beperkingen

• Er is geen limiet voor het aantal tabellen waarop beveiligingsbeleid op rijniveau kan worden geconfigureerd.
• Beveiligingsbeleid op rijniveau kan niet worden geconfigureerd voor externe tabellen.
• Het RLS-beleid kan niet worden ingeschakeld voor een tabel onder de volgende omstandigheden:
  • Wanneer ernaar wordt verwezen door een updatebeleid query, terwijl het updatebeleid niet is geconfigureerd met een beheerde identiteit.
  • Wanneer ernaar wordt verwezen door een continue export die een andere verificatiemethode dan imitatie gebruikt.
  • Wanneer een toegangsbeleid voor beperkte weergave is geconfigureerd voor de tabel.
• De RLS-query kan niet verwijzen naar andere tabellen waarvoor beveiligingsbeleid op rijniveau is ingeschakeld.
• De RLS-query kan niet verwijzen naar tabellen die zich in andere databases bevinden.

Voorbeelden

Toegang tot de tabel Sales beperken

In een tabel met de naam Salesbevat elke rij details over een verkoop. Een van de kolommen bevat de naam van de verkoper. In plaats van uw verkopers toegang te geven tot alle records in Sales, schakelt u een beveiligingsbeleid op rijniveau in deze tabel in om alleen records te retourneren waarbij de verkoper de huidige gebruiker is:

Sales | where SalesPersonAadUser == current_principal()

U kunt ook het e-mailadres maskeren:

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

Als u wilt dat elke verkoper alle verkopen van een specifiek land/specifieke regio ziet, kunt u een query definiëren die vergelijkbaar is met:

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))

Als u een groep met de managers hebt, wilt u ze mogelijk toegang geven tot alle rijen. Hier volgt de query voor het beveiligingsbeleid op rijniveau.

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

Verschillende gegevens beschikbaar maken voor leden van verschillende Microsoft Entra-groepen

Als u meerdere Microsoft Entra-groepen hebt en u wilt dat de leden van elke groep een andere subset met gegevens zien, gebruikt u deze structuur voor een RLS-query.

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>)

Dezelfde RLS-functie toepassen op meerdere tabellen

Definieer eerst een functie die de tabelnaam als een tekenreeksparameter ontvangt en verwijst naar de tabel met behulp van de operator table().

Bijvoorbeeld:

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

Configureer RLS vervolgens op deze manier voor meerdere tabellen:

.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')"

Een fout veroorzaken bij onbevoegde toegang

Als u wilt dat niet-geverifieerde tabelgebruikers een fout ontvangen in plaats van een lege tabel te retourneren, gebruikt u de functie assert(). In het volgende voorbeeld ziet u hoe u deze fout kunt produceren in een RLS-functie:

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

U kunt deze benadering combineren met andere voorbeelden. U kunt bijvoorbeeld verschillende resultaten weergeven voor gebruikers in verschillende Microsoft Entra-groepen en een fout voor iedereen produceren.

Machtigingen beheren voor snelkoppelingsdatabases

Het RLS-beleid dat u op de productiedatabase configureert, wordt ook van kracht in de snelkoppelingsdatabases. U kunt geen ander RLS-beleid configureren voor de productie- en snelkoppelingsdatabases. U kunt echter de functie current_cluster_endpoint() in uw RLS-query gebruiken om hetzelfde effect te bereiken, zoals het gebruik van verschillende RLS-query's in snelkoppelingstabellen.

Bijvoorbeeld:

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

Notitie

De bovenstaande functie RLS heeft geen invloed op de prestaties van query's in de brondatabase. De invloed van de prestaties op query's op de snelkoppelingsdatabases wordt alleen beïnvloed door de complexiteit van DataForFollowerClusters.

Meer use cases

• Een ondersteuningsmedewerker van het callcenter kan bellers identificeren op verschillende cijfers van hun burgerservicenummer. Dit nummer mag niet volledig zichtbaar zijn voor de ondersteuningsmedewerker. Een RLS-beleid kan worden toegepast op de tabel om alle behalve de laatste vier cijfers van het burgerservicenummer in de resultatenset van een query te maskeren.
• Stel een RLS-beleid in waarmee persoonlijke informatie (PII) wordt gemaskeerd en waarmee ontwikkelaars query's kunnen uitvoeren op productieomgevingen voor probleemoplossing zonder nalevingsregels te schenden.
• Een ziekenhuis kan een RLS-beleid instellen waarmee verpleegsters alleen gegevensrijen voor hun patiënten kunnen bekijken.
• Een bank kan een RLS-beleid instellen om de toegang tot rijen met financiële gegevens te beperken op basis van de bedrijfsafdeling of rol van een werknemer.
• Een toepassing met meerdere tenants kan gegevens van veel tenants opslaan in één tabelset (wat efficiënt is). Ze gebruiken een RLS-beleid om een logische scheiding af te dwingen van de gegevensrijen van elke tenant uit de rijen van elke andere tenant, zodat elke tenant alleen de gegevensrijen kan zien.

Invloed op de prestaties van query's

Wanneer een RLS-beleid is ingeschakeld voor een tabel, is er enige invloed op de prestaties van query's die toegang hebben tot die tabel. Toegang tot de tabel wordt vervangen door de RLS-query die in die tabel is gedefinieerd. De invloed van de prestaties van een RLS-query bestaat normaal gesproken uit twee onderdelen:

• Lidmaatschapscontroles in Microsoft Entra-id: Controles zijn efficiënt. U kunt het lidmaatschap in tientallen of zelfs honderden groepen controleren zonder grote invloed op de queryprestaties.
• Filters, joins en andere bewerkingen die worden toegepast op de gegevens: Impact is afhankelijk van de complexiteit van de query

Bijvoorbeeld:

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

Als de gebruiker geen deel uitmaakt van some_group@domain.com, wordt IsRestrictedUser geëvalueerd om false. De query die wordt geëvalueerd, is vergelijkbaar met deze:

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

Als IsRestrictedUser ook trueevalueert, wordt alleen de query voor PartialData geëvalueerd.

Queryprestaties verbeteren wanneer beveiliging op rijniveau wordt gebruikt

• Als een filter wordt toegepast op een kolom met hoge kardinaliteit, bijvoorbeeld DeviceID, kunt u overwegen partitioneringsbeleid te gebruiken of beleid voor rijvolgorde
• Als een filter wordt toegepast op een kolom met lage kardinaliteit, kunt u overwegen beleid voor rijvolgorde te gebruiken

Invloed op de prestaties van opname

Er is geen invloed op de prestaties bij opname.