Megosztás a következőn keresztül:

Sorszintű biztonság a Fabric-adattárházakban

  • Cikk

A következőkre vonatkozik:✅ SQL Analytics-végpont és Warehouse a Microsoft Fabricben

A sorszintű biztonság (RLS) lehetővé teszi a csoporttagság vagy a végrehajtási környezet használatát az adatbázistábla soraihoz való hozzáférés szabályozásához. Gondoskodhat például arról, hogy a dolgozók csak azokat az adatsorokat érjék el, amelyek a részlegükhöz kapcsolódnak. Egy másik példa az ügyfelek adathozzáférésének korlátozása csak a vállalatuk számára releváns adatokra egy több-bérlős architektúrában. A funkció hasonló az SQL Server sorszintű biztonságához.

Sorszintű biztonság adatszinten

A sorszintű biztonság leegyszerűsíti a biztonság tervezését és kódolását az alkalmazásban. A sorszintű biztonság segít az adatsor-hozzáférés korlátozásainak megvalósításában.

A hozzáférés-korlátozás logikája az adatbázis szintjén van, nem egyetlen alkalmazásszinten. Az adatbázis minden adathozzáféréskor alkalmazza a hozzáférési korlátozásokat bármely alkalmazásból vagy jelentéskészítési platformról, beleértve a Power BI-t is. Ez megbízhatóbbá és robusztusabbá teszi a biztonsági rendszert a biztonsági rendszer felületének csökkentésével. A sorszintű biztonság csak a Fabricben található Warehouse- vagy SQL Analytics-végponton lévő lekérdezésekre vonatkozik. A Power BI-lekérdezések a Direct Lake-módban lévő raktárban a sorszintű biztonság érdekében vissza fognak esni a Direct Query módba.

Bizonyos sorokhoz való hozzáférés korlátozása bizonyos felhasználók számára

Implementálja az RLS-t a CREATE SECURITY POLICY Transact-SQL utasítással, és beágyazott táblaértékű függvényekként létrehozott predikátumokat.

A rendszer sorszintű biztonságot alkalmaz a megosztott raktárra vagy a lakehouse-ra, mert a mögöttes adatforrás nem változott.

Predikátumalapú sorszintű biztonság

A Fabric Data Warehouse sorszintű biztonsága támogatja a predikátumalapú biztonságot. A szűrési predikátumok csendesen szűrik az olvasási műveletekhez elérhető sorokat.

A tábla sorszintű adataihoz való hozzáférést egy beágyazott táblaértékű függvényként definiált biztonsági predikátum korlátozza. A függvényt ezután egy biztonsági szabályzat hívja meg és kényszeríti ki. Szűrési predikátumok esetén az alkalmazás nem tud az eredményhalmazból szűrt sorokról. Ha az összes sor szűrve van, a rendszer null értéket ad vissza.

A szűrő predikátumok az alaptáblából származó adatok beolvasása során kerülnek alkalmazásra. Ezek az összes lekérési műveletre hatással vannak: SELECT, DELETEés UPDATE. Minden táblának külön kell meghatároznia a sorszintű biztonságot. Azok a felhasználók, akik sorszintű biztonsági szabályzat nélkül kérdeznek le táblákat, szűretlen adatokat fognak megtekinteni.

A felhasználók nem jelölhetnek ki és nem törölhetnek szűrt sorokat. A felhasználó nem tudja frissíteni a szűrt sorokat. A sorokat azonban úgy is frissítheti, hogy azokat később szűrni lehessen.

A szűrési predikátum és a biztonsági szabályzatok viselkedése a következő:

  • Meghatározhat egy predikátumfüggvényt, amely egy másik táblához csatlakozik, és/vagy meghív egy függvényt. Ha a biztonsági szabályzat az alapértelmezett beállítással SCHEMABINDING = ON van létrehozva, akkor az illesztés vagy a függvény elérhető a lekérdezésből, és a várt módon működik további engedélyellenőrzések nélkül.

  • Lekérdezést adhat ki egy olyan táblára, amely meghatározott, de letiltott biztonsági predikátumot tartalmaz. A szűrt vagy letiltott sorokra nincs hatással.

  • Ha egy dbo-felhasználó, a db_owner szerepkör tagja vagy a tábla tulajdonosa lekérdez egy olyan táblát, amely rendelkezik definiált és engedélyezett biztonsági szabályzattal, a sorok a biztonsági szabályzatban meghatározottak szerint lesznek szűrve vagy letiltva.

  • A séma által kötött biztonsági szabályzattal kötött tábla sémájának módosítására tett kísérletek hibát eredményeznek. A predikátum által nem hivatkozott oszlopok azonban módosíthatók.

  • Ha olyan táblához próbál predikátumot hozzáadni, amely már rendelkezik a megadott művelethez definiálttal, hibát eredményez. Ez akkor fordul elő, ha a predikátum engedélyezve van vagy sem.

  • A séma által kötött biztonsági házirendek tábláiban predikátumként használt függvények módosítására tett kísérletek hibát eredményeznek.

  • Több olyan aktív biztonsági szabályzat definiálása, amelyek nem átfedésben lévő predikátumokat tartalmaznak, sikeresek.

A szűrési predikátumok viselkedése a következő:

  • Adjon meg egy olyan biztonsági szabályzatot, amely szűri a tábla sorait. Az alkalmazás nem ismeri azokat a sorokat, amelyek szűrve vannak a , UPDATEés DELETE a műveletek esetébenSELECT. Beleértve azokat a helyzeteket is, amikor az összes sor ki van szűrve. Az alkalmazás akkor is sorokat állíthat INSERT be, ha más műveletek során szűrni fogja őket.

Engedélyek

A biztonsági szabályzatok létrehozásához, módosításához vagy elvetéséhez engedély ALTER ANY SECURITY POLICY szükséges. A biztonsági szabályzat létrehozásához vagy elvetéséhez engedélyre van szükség ALTER a sémán.

Emellett a következő engedélyekre van szükség minden hozzáadott predikátumhoz:

  • SELECT és REFERENCES a predikátumként használt függvény engedélyeit.

  • REFERENCES a szabályzathoz kötött céltáblára vonatkozó engedély.

  • REFERENCES az argumentumként használt céltábla minden oszlopára vonatkozó engedély.

A biztonsági szabályzatok az összes felhasználóra vonatkoznak, beleértve az adatbázis dbo-felhasználóit is. A Dbo-felhasználók módosíthatják vagy elvethetik a biztonsági szabályzatokat, de a biztonsági szabályzatok módosításait naplózhatják. Ha az olyan szerepkörök tagjainak, mint a Rendszergazda, a Tag vagy a Közreműködő, látniuk kell az adatok hibaelhárításához vagy ellenőrzéséhez szükséges összes sort, a biztonsági szabályzatot ennek engedélyezéséhez meg kell írni.

Ha biztonsági szabályzatot hoz létre SCHEMABINDING = OFF, akkor a céltábla lekérdezéséhez a felhasználóknak rendelkezniük kell a SELECT EXECUTE predikátumfüggvényen, valamint a predikátumfüggvényen belül használt további táblákkal, nézetekkel vagy függvényekkel. Ha biztonsági szabályzatot hoz létre SCHEMABINDING = ON (az alapértelmezett), akkor ezeket az engedélyellenőrzéseket a rendszer megkerüli, amikor a felhasználók lekérdezik a céltáblát.

Biztonsági szempontok: oldalcsatorna-támadások

Fontolja meg és készüljön fel a következő két forgatókönyvre.

Rosszindulatú biztonsági házirend-kezelő

Fontos megfigyelni, hogy egy rosszindulatú biztonsági házirend-kezelő, amely megfelelő engedélyekkel rendelkezik ahhoz, hogy biztonsági szabályzatot hozzon létre egy bizalmas oszlop tetején, és engedéllyel rendelkezik a beágyazott táblaértékkel rendelkező függvények létrehozására vagy módosítására, ütközhet egy másik felhasználóval, aki egy táblára vonatkozó engedélyeket választva adatszivárgást hajthat végre azáltal, hogy rosszindulatúan hoz létre beágyazott, táblázatértékes függvényeket, amelyek oldalcsatorna-támadások használatával következtetnek az adatokra. Az ilyen támadásokhoz összejátszásra (vagy egy rosszindulatú felhasználónak adott túlzott engedélyekre) lenne szükség, és valószínűleg több iterációra lenne szükség a szabályzat módosításához (engedélyre van szükség a predikátum eltávolításához a sémakötés megszakításához), módosítani kell a beágyazott táblaértékű függvényeket, és a céltáblán ismétlődően futtatni a választó utasításokat. Javasoljuk, hogy szükség szerint korlátozza az engedélyeket, és figyelje a gyanús tevékenységeket. Figyelni kell az olyan tevékenységeket, mint a szabályzatok folyamatos módosítása és a sorszintű biztonsághoz kapcsolódó beágyazott táblaértékelt függvények.

Gondosan összeállított lekérdezések

Az adatok kiszivárgását olyan gondosan kialakított lekérdezésekkel lehet előidézni, amelyek hibákat használnak az adatok kiszűréséhez. Például tudatná egy rosszindulatú felhasználóval, SELECT 1/(SALARY-100000) FROM PAYROLL WHERE NAME='John Doe'; hogy John Doe fizetése pontosan 100 000 dollár. Annak ellenére, hogy létezik biztonsági predikátum, amely megakadályozza, hogy egy rosszindulatú felhasználó közvetlenül lekérdezze mások fizetését, a felhasználó meghatározhatja, hogy a lekérdezés mikor ad vissza nulladik osztásos kivételt.

Példák

A Sorszintű biztonsági raktár és AZ SQL Analytics végpontot a Microsoft Fabricben mutatjuk be.

Az alábbi példa olyan mintatáblákat hoz létre, amelyek a Warehouse in Fabricben működnek majd, de az SQL Analytics végpontja meglévő táblákat használ. Az SQL Analytics-végponton nem CREATE TABLElehet , de lehet CREATE SCHEMA, CREATE FUNCTIONés CREATE SECURITY POLICY.

Ebben a példában először hozzon létre egy sémát sales, egy táblát sales.Orders.

CREATE SCHEMA sales;
GO

-- Create a table to store sales data
CREATE TABLE sales.Orders (
    SaleID INT,
    SalesRep VARCHAR(100),
    ProductName VARCHAR(50),
    SaleAmount DECIMAL(10, 2),
    SaleDate DATE
);

-- Insert sample data
INSERT INTO sales.Orders (SaleID, SalesRep, ProductName, SaleAmount, SaleDate)
VALUES
    (1, 'Sales1@contoso.com', 'Smartphone', 500.00, '2023-08-01'),
    (2, 'Sales2@contoso.com', 'Laptop', 1000.00, '2023-08-02'),
    (3, 'Sales1@contoso.com', 'Headphones', 120.00, '2023-08-03'),
    (4, 'Sales2@contoso.com', 'Tablet', 800.00, '2023-08-04'),
    (5, 'Sales1@contoso.com', 'Smartwatch', 300.00, '2023-08-05'),
    (6, 'Sales2@contoso.com', 'Gaming Console', 400.00, '2023-08-06'),
    (7, 'Sales1@contoso.com', 'TV', 700.00, '2023-08-07'),
    (8, 'Sales2@contoso.com', 'Wireless Earbuds', 150.00, '2023-08-08'),
    (9, 'Sales1@contoso.com', 'Fitness Tracker', 80.00, '2023-08-09'),
    (10, 'Sales2@contoso.com', 'Camera', 600.00, '2023-08-10');

Security Séma, függvény Security.tvf_securitypredicateés biztonsági szabályzat SalesFilterlétrehozása.

-- Creating schema for Security
CREATE SCHEMA Security;
GO
 
-- Creating a function for the SalesRep evaluation
CREATE FUNCTION Security.tvf_securitypredicate(@SalesRep AS nvarchar(50))
    RETURNS TABLE
WITH SCHEMABINDING
AS
    RETURN SELECT 1 AS tvf_securitypredicate_result
WHERE @SalesRep = USER_NAME() OR USER_NAME() = 'manager@contoso.com';
GO
 
-- Using the function to create a Security Policy
CREATE SECURITY POLICY SalesFilter
ADD FILTER PREDICATE Security.tvf_securitypredicate(SalesRep)
ON sales.Orders
WITH (STATE = ON);
GO

A sorszintű biztonsági függvény módosításához először el kell dobnia a biztonsági szabályzatot. A következő szkriptben elvetjük a szabályzatot SalesFilter , mielőtt utasítást ALTER FUNCTION adunk a következőre Security.tvf_securitypredicate: . Ezután újra létrehozzuk a szabályzatot SalesFilter.

-- Drop policy so we can change the predicate function.
DROP SECURITY POLICY SalesFilter;
GO

-- Alter the function for the SalesRep evaluation
ALTER FUNCTION Security.tvf_securitypredicate(@SalesRep AS nvarchar(50))
    RETURNS TABLE
WITH SCHEMABINDING
AS
    RETURN SELECT 1 AS tvf_securitypredicate_result
WHERE @SalesRep = USER_NAME() OR USER_NAME() = 'president@contoso.com';
GO
 
-- Re-create a Security Policy
CREATE SECURITY POLICY SalesFilter
ADD FILTER PREDICATE Security.tvf_securitypredicate(SalesRep)
ON sales.Orders
WITH (STATE = ON);
GO

Következő lépés

Sorszintű biztonság megvalósítása a Fabric Adattárolás

Kapcsolódó tartalom