Sådan sikrer du et lakehouse til datawarehousing-teams
Introduktion
I denne artikel giver vi et overblik over, hvordan du konfigurerer sikkerhed for et lakehouse i Fabric til brug sammen med SQL-brugere med T-SQL-forespørgsler. Disse brugere kan være forretningsanalytikere, der bruger data via SQL, report builders eller datateknikere, der opretter nye tabeller og visninger.
Sikkerhedsfunktioner
Microsoft Fabric bruger en sikkerhedsmodel med flere lag med forskellige kontrolelementer, der er tilgængelige på forskellige niveauer, for kun at give de nødvendige minimumtilladelser. Du kan få flere oplysninger om de forskellige sikkerhedsfunktioner, der er tilgængelige i Fabric, under Data Access Control Model i OneLake.
I Fabric Data Warehouse-arbejdsbelastningen giver slutpunktselementerne for lageret og SQL-analyse også mulighed for at definere oprindelig SQL-sikkerhed. SQL Security bruger hele biblioteket med T-SQL-sikkerhedskonstruktioner til at tillade detaljeret adgangskontrol af tabeller, visninger, rækker og kolonner i et element. Du kan finde flere oplysninger om SQL-sikkerhed under SQL-detaljerede tilladelser.
De SQL-tilladelser, der er konfigureret i lageret eller SQL Analytics-slutpunktet, gælder kun for forespørgsler, der udføres i forhold til lageret eller SQL Analytics-slutpunktet. De underliggende data findes i OneLake, men adgangen til OneLake-data styres separat via OneLake-dataadgangsroller. Hvis du vil sikre, at brugere med SQL-specifikke tilladelser ikke kan se data, de ikke har SQL-adgang til, skal du ikke inkludere disse brugere i en OneLake-dataadgangsrolle.
Sikker efter use case
Sikkerhed i Microsoft Fabric er optimeret til sikring af data til specifikke use cases. En use case er et sæt brugere, der har brug for specifik adgang og adgang til data via et givent program. I SQL-scenarier er nogle almindelige use cases:
- SQL-skrivere: Brugere, der skal oprette nye tabeller, få vist eller skrive data til eksisterende tabeller.
- SQL-læsere: Brugere, der skal læse data ved hjælp af SQL-forespørgsler. De kan få adgang til SQL-forbindelsen direkte eller via en anden tjeneste, f.eks. Power BI.
Vi kan derefter justere hver enkelt use case med de nødvendige tilladelser i Fabric.
SQL-skriveadgang
En bruger kan få skriveadgang til et lager- eller SQL-analyseslutpunkt på to måder:
- Via Fabric-arbejdsområderoller kan du tildele medlemskab til tre arbejdsområderoller, der giver skrivetilladelser. Hver rolle oversættes automatisk til en tilsvarende rolle i SQL, der giver tilsvarende skriveadgang.
- Tildel læseadgang til SQL-programmet, og tildel brugerdefinerede SQL-tilladelser til at skrive til nogle eller alle dataene.
Hvis en bruger har brug for skriveadgang til alle lager- eller SQL Analytics-slutpunkter i et arbejdsområde, skal du tildele dem til en arbejdsområderolle. Medmindre en bruger skal tildele andre brugere til arbejdsområderoller, skal rollen Bidragyder bruges.
Hvis en bruger kun skal skrive til bestemte lagre eller SQL-analyser, skal du give dem direkte adgang via SQL-tilladelser.
LÆSEADGANG TIL SQL
Der er to måder, hvorpå en bruger kan få læseadgang til et lager- eller SQL Analytics-slutpunkt:
- Tildel læseadgang via tilladelsen ReadData, der er tildelt som en del af rollerne i Fabric-arbejdsområdet. Alle fire arbejdsområderoller giver tilladelsen ReadData.
- Tildel læseadgang til SQL-programmet, og tildel brugerdefinerede SQL-tilladelser til at læse til nogle eller alle dataene.
Hvis en bruger er medlem af en fabric-arbejdsområderolle, får vedkommende tilladelsen ReadData. Tilladelsen ReadData knytter brugeren til en SQL-rolle, der giver SELECT-tilladelser til alle tabeller i lageret eller lakehouse'et. Denne tilladelse er nyttig, hvis en bruger har brug for at se alle eller de fleste af dataene i lakehouse eller warehouse. Alle SQL DENY-tilladelser, der er angivet for et bestemt lakehouse eller warehouse, gælder stadig og begrænser adgangen til tabeller. Derudover kan sikkerhed på række- og kolonneniveau angives for tabeller for at begrænse adgangen på et detaljeret niveau.
Hvis en bruger kun har brug for adgang til et bestemt lakehouse eller lager, giver delingsfunktionen kun adgang til det delte element. Under delingen kan brugerne vælge kun at give tilladelsen Læs eller Læs + ReadData. Tildeling af læsetilladelse giver brugeren mulighed for at oprette forbindelse til lagerets eller SQL Analytics-slutpunktet, men giver ingen tabeladgang. Tildeling af tilladelserne ReadData til brugere giver dem fuld læseadgang til alle tabeller i lageret eller SQL Analytics-slutpunktet. I begge tilfælde kan yderligere SQL-sikkerhed konfigureres til at tildele eller nægte adgang til bestemte tabeller. Denne SQL-sikkerhed kan omfatte detaljeret adgangskontrol, f.eks. sikkerhed på række- eller kolonneniveau.
Bruges sammen med genveje
Genveje er en OneLake-funktion, der gør det muligt at referere til data fra én placering uden fysisk at kopiere dataene. Genveje er et effektivt værktøj, der gør det nemt at genbruge data fra ét lakehouse på andre placeringer uden at lave dublerede kopier af data.
Lagre i Fabric understøtter ikke genveje. Der er dog en særlig funktionsmåde for, hvordan SQL Analytics-slutpunktet for et lakehouse interagerer med genveje.
Alle genveje i et lakehouse tilgås i delegeringstilstand, når der sendes en forespørgsel via SQL Analytics-slutpunktet. Den delegerede identitet er den Fabric-bruger, der ejer lakehouse'et. Ejeren er som standard den bruger, der oprettede lakehouse- og SQL Analytics-slutpunktet. Ejeren kan ændres i udvalgte tilfælde, og den aktuelle ejer vises i kolonnen Ejer i Fabric, når elementet vises på listen over elementer i arbejdsområdet. Den delegerede funktionsmåde betyder, at en bruger, der forespørger, kan læse fra genvejstabeller, hvis ejeren har adgang til de underliggende data, ikke den bruger, der udfører forespørgslen. Den bruger, der forespørger, skal kun have adgang til at vælge fra genvejstabellen.
Bemærk
UserA er f.eks. ejeren af et lakehouse, og UserB kører en forespørgsel på en tabel, der er en genvej. UserB skal først have læseadgang til tabellen, uanset om det er via ReadData eller via SQL-tilladelser. For at få vist data kontrollerer forespørgslen, om UserA har adgang til genvejen. Hvis UserA har adgang, kan UserB se forespørgselsresultaterne. Hvis UserA ikke har adgang, mislykkes forespørgslen.
For lakehouses, der bruger funktionen OneLake-dataadgangsroller , bestemmes adgangen til en genvej af, om ejeren af SQL Analytics-slutpunktet har adgang til at se målsøhuset og læse tabellen via en OneLake-dataadgangsrolle.
For lakehouses, der endnu ikke bruger funktionen OneLake-dataadgangsroller , bestemmes genvejsadgang af, om ejeren af SQL Analytics-slutpunktet har tilladelsen Læs og LæsAlle på destinationsstien.