Weboldal keresés

A sor- és oszlopszintű biztonság megvalósítása az SQL Serverben


Az SQL Server számos biztonsági funkciót tartalmaz. A két legértékesebb az oszlopszintű és a sorszintű biztonság, amelyek lehetővé teszik a felhasználók számára, hogy részletesen hozzáférjenek egy táblázat soraihoz és oszlopaihoz. Ez a cikk elmagyarázza, hogyan implementálhatja ezeket a szolgáltatásokat a környezetében.

Biztosíthatók, megbízók és engedélyek

Mielőtt belemerülnénk a sorok és oszlopok biztonságába, át kell tekintenünk az SQL Server biztonsági alapjait. Az adatbázis biztonsága alapvetően azt jelenti, hogy valaki hozzáférhet az adatbázisban tárolt adatokhoz, és műveleteket hajthat végre rajta. A „valaki” megbízó, a műveletek, amelyeket megtehetnek, az ő engedélyei, és az adatok, amelyeken a műveleteket végrehajtják, biztosítható - biztosítható példák közé tartoznak az adatbázisok, táblák, sémák, sorok és oszlopok.

Vessünk egy pillantást a biztosítható elemekre alkalmazható engedélyekre:

  • KIVÁLASZTÁS - A Megbízóknak erre az engedélyre van szükségük ahhoz, hogy adatokat kapjanak vagy olvashassanak a táblázatból.
  • INSERT - Az igazgatóknak szükségük van erre az engedélyre, hogy új sorokat adhassanak a táblázathoz.
  • FRISSÍTÉS - A megbízóknak szükségük van erre az engedélyre a táblázat adatainak módosításához.
  • TÖRLÉS - Az igazgatóknak szükségük van erre az engedélyre a sorok táblázatból való eltávolításához.
  • REFERENCIÁK - A megbízóknak szükségük van erre az engedélyre, hogy idegen kulcsot hozzanak létre egy táblához, ha nincs más engedélyük a táblához.

SQL Server oszlop szintű biztonság

Kétféleképpen védheti meg az oszlopokat az SQL Serverben: oszlopszintű engedélyekkel és oszlopszintű titkosítással. A rendszergazdák számára az a nagyszerű, hogy ez a két technika kombinálható.

Oszlopszintű engedélyek

Az oszlop szintű engedélyek részletesebb szintű biztonságot nyújtanak az adatbázisban lévő adatok számára. Nem kell külön GRANT vagy DENY utasításokat végrehajtania minden oszlophoz; csak nevezze meg őket egy lekérdezésben:

GRANT SELECT ON data1.table (column1, column2) TO user1;

GO

DENY SELECT ON data1.table (column3) TO user1;

GO

Ha táblaszinten végrehajt egy DENY utasítást egy oszlophoz egy felhasználó számára, majd ezt követően hajt végre egy GRANT utasítást ugyanabban az oszlopban, a DENY engedély eltávolításra kerül, és a felhasználó hozzáférhet az oszlophoz. Hasonlóképpen, ha végrehajtja a GRANT, majd a DENY parancsot, a DENY engedély lesz érvényben.

Oszlop szintű titkosítás

Az oszlop szintű titkosítás egy oszlopban lévő adatok közvetlen titkosítása. Kódmódosítást igényel, mert csak az adatbázis programozása közben alkalmazható. Ez egy szemcsés módja az adatok titkosításának, így csak meghatározott oszlopok vagy oszlopok részei titkosíthatók. Különböző oszlopokhoz különböző titkosítási kulcsokat is használhat. Az oszlop szintű titkosításhoz bináris oszlopokra van szükség a titkosított adatok tárolására. Ezenkívül a kulcsokat a kiszolgálón tárolja, így az SQL-adatbázisnak megbíznia kell a kulcsokat tároló szerverben.

Az oszlop szintű titkosítás szimmetrikus kulcsokat használ az adatok titkosításához, mivel ez segít fenntartani a termelékenységet, és minden szimmetrikus kulcsot egy aszimmetrikus kulcs véd. A szimmetrikus kulcsokhoz különböző algoritmusokat használhat, de az AES a legjobb megoldás. Ezenkívül a szimmetrikus kulcsok jelszavakkal vagy mesterkulcsokkal is védhetők.

A kulcsok biztonságának megőrzése érdekében SQL-engedélyekkel korlátozhatja a hozzáférésüket a megbízható felhasználói fiókokra. Egy másik fontos megjegyzés, hogy a titkosított adatok nem indexelhetők; Ha indexelni szeretné, akkor először vissza kell fejteni.

Az oszlopszintű titkosítás megvalósításához a következő lépéseket kell tennünk:

  1. Először létrehozzuk az adatbázis főkulcsát a szimmetrikus kulcsunk titkosításához. Ezt a CREATE MASTER KEY paranccsal és a ENCRYPTION BY PASSWORD argumentum használatával lehet megtenni, amely meghatározza a kulcs titkosításához szükséges jelszót:
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'P@$$w0rd' 

GO
  1. Ezután létre kell hoznunk egy szimmetrikus kulcsot, de a biztonság érdekében digitálisan aláírt tanúsítványt kell készíteni. Tanúsítvány létrehozásához használja a CREATE CERTIFICATE parancsot, amelyet a főkulcsunk véd. Ezután létrehozhatunk egy szimmetrikus kulcsot aCREATE SYMMETRIC KEY paranccsal és az AES_256 titkosítási algoritmussal.
CREATE CERTIFICATE SelfSignedCertificate WITH SUBJECT = 'Column Encryption'; 

GO 

CREATE SYMMETRIC KEY SQLSymmetricKey 

WITH ALGORITHM = AES_256

ENCRYPTION BY CERTIFICATE SelfSignedCertificate; 

GO
  1. Ezután hozzá kell adnunk egy oszlopot a táblázatunkhoz a titkosított adatok tárolására.
USE DB; 

GO 

ALTER TABLE Testtable 

ADD EncryptedColumn varbinary(MAX )NULL 

GO
  1. A táblázat adatainak titkosításához meg kell nyitnunk a szimmetrikus kulcsunkat és frissítenünk kell a táblázatot.
OPEN SYMMETRIC KEY SQLSymmetricKey 

DECRYPTION BY CERTIFICATE SelfSignedCertificate;
  1. A szimmetrikus kulcs megnyitása után frissítenünk kell a táblázatot.
UPDATE Testtable 

SET [EncryptedColumn] = EncryptByKey(Key_GUID('SQLSymmetricKey'), ColumnWithSensitiveData); 

GO 

select * from Testtable
  1. A titkosított oszlop létrejött; tartalmazza a columnwithsensitivedata titkosított adatait Az SQL Server biztonsági céljának elérése érdekében el kell dobnunk a meglévő egyszerű szöveges columnwithsensitivedata oszlopot a DROP paranccsal, és csak a titkosított oszlopot kell megtartanunk.

SQL Server sor szintű biztonság

A sorszintű biztonság (RLS) lehetővé teszi a fejlesztők számára, hogy soronként szabályozzák a felhasználói hozzáférési jogokat az információkhoz; minden felhasználó csak azokat a sorokat láthatja, amelyekhez hozzáféréssel rendelkezik. Ez a biztonsági szolgáltatás magas szintű engedélyekkel rendelkezik, mivel megkerüli a meglévő SQL Server biztonsági hozzáférési listákat. Három részből áll:

  • Predikátum funkció - Ez egy sémafüggvény, amely azt szabályozza, hogy a lekérdezést végrehajtó felhasználói fióknak van-e hozzáférése a sorhoz.
  • Biztonsági predikátum - A biztonsági predikátum predikátumfüggvényt köt a táblázathoz. Kétféle biztonsági predikátum létezik:

    • Szűrő predikátum - Ez korlátozza az olvasási műveleteket (SELECT) a sorban. Ez a szűrés csendben történik, eseménynaplók nélkül.
    • Predikátum blokkolása - Ez korlátozza az írási műveleteket (INSERT) a sorban. A BLOCK predikátumoknak négy típusa van: AFTER INSERT, BEFORE UPDATE, AFTER UPDATE és BEFORE DELETE műveletek.
  • Biztonsági szabályzat - Ez a biztonsági predikátumok gyűjteménye egyetlen új objektumban csoportosítva.

A logika egyszerű: egy predikátum függvény határozza meg, hogy bizonyos paraméterek alapján engedélyezi-e vagy blokkolja a felhasználó által elérhet sorokat, majd a függvény egy biztonsági házirenddel rendelkező táblára kerül, és aktívvá válik. Nézzük meg közelebbről ezt a folyamatot:

    1. Először is létre kell hoznunk egy szűrőpredikátumot. Ebben a példában engedélyezzük a hozzáférést egy sorhoz egy felhasználó számára, ha az megegyezik az adott sor privilegeuser oszlopával, vagy ha a felhasználó neve ADMIN.
    CREATE FUNCTION dbo.NewPredicateFunction
    
    ( @privilegeuser AS SYSNAME )
    
    RETURNS TABLE
    
    WITH SCHEMABINDING
    
    AS
    
    RETURN SELECT 1 AS AccessRight
    
        WHERE @privilegeuser = USER_NAME() OR USER_NAME() = 'ADMIN'
    
    GO
    1. Ezután létrehozunk egy biztonsági szabályzatot a következő szkript végrehajtásával, amely hozzáadja az imént létrehozott predikátum függvényt szűrőpredikátumként a teszttáblázatunkhoz.
    CREATE SECURITY POLICY PrivacyPolicy
    
    ADD FILTER PREDICATE
    
    dbo.NewPredicateFunction(privilegeuser) ON dbo.testtable
    
    WITH (STATE = ON)

    Ez minden. Biztonsági házirendünk aktív az SQL-adatbázisunkban, és lehetővé teszi a felhasználók számára, hogy csak a saját sorukhoz férhessenek hozzá, miközben az ADMIN fiók az összes sorhoz hozzáférhet.

    Kapcsolódó cikkek