Så här skyddar du ett sjöhus för Datalagring team
Introduktion
I den här artikeln ger vi en översikt över hur du konfigurerar säkerhet för en lakehouse i Fabric för användning med SQL-användare med T-SQL-frågor. Dessa användare kan vara affärsanalytiker som använder data via SQL, rapportbyggare eller datatekniker som skapar nya tabeller och vyer.
Säkerhetsfunktioner
Microsoft Fabric använder en säkerhetsmodell i flera lager med olika kontroller som är tillgängliga på olika nivåer för att endast ge de behörigheter som krävs. Mer information om de olika säkerhetsfunktionerna som är tillgängliga i Infrastruktur finns i Data Access Control Model i OneLake.
I arbetsbelastningen Fabric Data Warehouse tillåter lager- och SQL-analysslutpunktsobjekten även definition av inbyggd SQL-säkerhet. SQL-säkerhet använder det fullständiga biblioteket med T-SQL-säkerhetskonstruktioner för att möjliggöra detaljerad åtkomstkontroll av tabeller, vyer, rader och kolumner i ett objekt. Mer information om SQL-säkerhet finns i SQL-detaljerade behörigheter.
SQL-behörigheterna som konfigureras i lager- eller SQL-analysslutpunkten gäller endast för frågor som körs mot lager- eller SQL-analysslutpunkten. Underliggande data finns i OneLake, men åtkomsten till OneLake-data styrs separat via OneLake-dataåtkomstroller. För att säkerställa att användare med SQL-specifika behörigheter inte ser data som de inte har SQL-åtkomst till ska du inte inkludera dessa användare i en OneLake-dataåtkomstroll.
Skydda med användningsfall
Säkerheten i Microsoft Fabric är optimerad för att skydda data för specifika användningsfall. Ett användningsfall är en uppsättning användare som behöver specifik åtkomst och åtkomst till data via en viss motor. För SQL-scenarier är några vanliga användningsfall:
- SQL-skrivare: Användare som behöver skapa nya tabeller, visa eller skriva data till befintliga tabeller.
- SQL-läsare: Användare som behöver läsa data med SQL-frågor. De kan komma åt SQL-anslutningen direkt eller via en annan tjänst som Power BI.
Sedan kan vi justera varje användningsfall med nödvändiga behörigheter i Infrastrukturresurser.
SQL-skrivåtkomst
Det finns två sätt för en användare att beviljas skrivåtkomst till ett lager eller en SQL-analysslutpunkt:
- Via infrastrukturarbetsyteroller kan du bevilja medlemskap till tre arbetsyteroller som ger skrivbehörighet. Varje roll översätts automatiskt till en motsvarande roll i SQL som ger motsvarande skrivåtkomst.
- Bevilja läsbehörighet till SQL-motorn och bevilja anpassade SQL-behörigheter för att skriva till vissa eller alla data.
Om en användare behöver skrivåtkomst till alla lager eller SQL-analysslutpunkter på en arbetsyta tilldelar du dem till en arbetsyteroll. Om inte en användare behöver tilldela andra användare till arbetsyteroller ska rollen Deltagare användas.
Om en användare bara behöver skriva till specifika lager eller SQL-analys kan du ge dem direkt åtkomst via SQL-behörigheter.
SQL-läsåtkomst
Det finns två sätt för en användare att beviljas läsåtkomst till ett lager eller en SQL-analysslutpunkt:
- Bevilja läsåtkomst via ReadData-behörigheten, som beviljats som en del av infrastrukturresursernas arbetsyteroller. Alla fyra arbetsyteroller beviljar ReadData-behörigheten.
- Bevilja läsbehörighet till SQL-motorn och bevilja anpassade SQL-behörigheter för att läsa till vissa eller alla data.
Om en användare är medlem i en fabric-arbetsyteroll får de behörigheten ReadData. ReadData-behörigheten mappar användaren till en SQL-roll som ger SELECT-behörigheter för alla tabeller i lagret eller lakehouse. Den här behörigheten är användbar om en användare behöver se alla eller de flesta data i lakehouse eller informationslagret. Alla SQL DENY-behörigheter som angetts för ett visst lakehouse eller lager gäller fortfarande och begränsar åtkomsten till tabeller. Dessutom kan säkerhet på rad- och kolumnnivå ställas in på tabeller för att begränsa åtkomsten på detaljerad nivå.
Om en användare bara behöver åtkomst till ett specifikt lakehouse eller lager ger resursfunktionen endast åtkomst till det delade objektet. Under resursen kan användarna välja att endast ge läsbehörighet eller Läsa + ReadData. Om du beviljar läsbehörighet kan användaren ansluta till lager- eller SQL-analysslutpunkten men ger ingen tabellåtkomst. Genom att ge användarna Läsdata-behörigheter får de fullständig läsåtkomst till alla tabeller i lagret eller SQL-analysslutpunkten. I båda fallen kan ytterligare SQL-säkerhet konfigureras för att bevilja eller neka åtkomst till specifika tabeller. Den här SQL-säkerheten kan innehålla detaljerad åtkomstkontroll, till exempel säkerhet på rad- eller kolumnnivå.
Använda med genvägar
Genvägar är en OneLake-funktion som gör att data kan refereras från en plats utan att fysiskt kopiera data. Genvägar är ett kraftfullt verktyg som gör att data från en lakehouse enkelt kan återanvändas på andra platser utan att dubbletter av data kopieras.
Lager i Infrastrukturresurser stöder inte genvägar. Det finns dock ett särskilt beteende för hur SQL-analysslutpunkten för ett lakehouse interagerar med genvägar.
Alla genvägar i ett sjöhus nås i ett delegerat läge när du frågar via SQL-analysslutpunkten. Den delegerade identiteten är fabric-användaren som äger lakehouse. Som standard är ägaren den användare som skapade lakehouse- och SQL-analysslutpunkten. Ägaren kan ändras i utvalda fall och den aktuella ägaren visas i kolumnen Ägare i Infrastruktur när objektet visas i arbetsytans objektlista. Det delegerade beteendet innebär att en frågande användare kan läsa från genvägstabeller om ägaren har åtkomst till underliggande data, inte användaren som kör frågan. Den frågande användaren behöver bara åtkomst för att välja från genvägstabellen.
Kommentar
UserA är till exempel ägare till ett lakehouse och UserB kör en fråga på en tabell som är en genväg. UserB måste först ha läsbehörighet i tabellen, antingen via ReadData eller via SQL-behörigheter. För att se data kontrollerar frågan sedan om UserA har åtkomst till genvägen. Om UserA har åtkomst ser UserB frågeresultatet. Om UserA inte har åtkomst misslyckas frågan.
För lakehouses som använder funktionen OneLake-dataåtkomstroller bestäms åtkomsten till en genväg av om SQL-analysslutpunktens ägare har åtkomst till mål lakehouse och läser tabellen via en OneLake-dataåtkomstroll.
För lakehouses som ännu inte använder funktionen OneLake-dataåtkomstroller bestäms genvägsåtkomst av om SQL-analysslutpunktens ägare har läs- och ReadAll-behörigheten på målsökvägen.