Útmutató a Linuxon futó SQL Server biztonsági funkcióihoz

A következőkre vonatkozik:SQL Server Linux rendszeren

Ha Ön linuxos felhasználó, aki még nem ismeri az SQL Servert, az alábbi feladatok végigvezetik a biztonsági feladatok némelyikén. Ezek a feladatok nem egyediek vagy kifejezetten Linuxra jellemzőek, de adnak egy képet, milyen területeket érdemes tovább vizsgálni. Minden példa linket ad az adott területre vonatkozó részletes dokumentációhoz.

A cikkben szereplő kódminták a AdventureWorks2025, AdventureWorksDW2025, vagyis AdventureWorksLT2025 mintaadatbázist használják, amelyet letölthetsz az Azure Data SQL Samples Repository GitHub repository-jából.

Bejelentkezés és adatbázis-felhasználó létrehozása

Másoknak is hozzáférést biztosít az SQL Server-hez azzal, hogy bejelentkezést hozz létre az master adatbázisban az utasítássalCREATE LOGIN. Például:

CREATE LOGIN Sasha
    WITH PASSWORD = '<password>';

Caution

A jelszónak az SQL Server alapértelmezett password szabályzatot kell követnie. Alapértelmezés szerint a jelszónak legalább nyolc karakter hosszúnak kell lennie, és a következő négy készletből három karakterből kell állnia: nagybetűk, kisbetűk, 10 számjegyből és szimbólumokból. A jelszavak legfeljebb 128 karakter hosszúak lehetnek. Használjon olyan jelszavakat, amelyek a lehető legkomplexebbek és hosszúak.

A bejelentkezések csatlakozhatnak az SQL Serverhez, és hozzáféréssel (korlátozott engedélyekkel) rendelkeznek az master adatbázishoz. A felhasználói adatbázishoz való csatlakozáshoz a bejelentkezéshez megfelelő azonosítóra van szükség az adatbázis szintjén, amit adatbázis-felhasználónak neveznek. A felhasználók minden adatbázishoz specifikusak, ezért külön kell létrehoznod őket minden adatbázisban, hogy hozzáférést kaphass.

A következő példa az AdventureWorks2025 adatbázisra vált, majd az CREATE USER utasítással létrehoz egy Sasha nevű felhasználót, amely a Sasha nevű bejelentkezéshez van leképezve. Bár a bejelentkezés és a felhasználó kapcsolódik egymáshoz (egymásnak megfeleltetve), mégis két különböző objektum. A bejelentkezés egy szerver szintű főszereplő. A felhasználó adatbázisszintű főszereplő.

USE AdventureWorks2025;
GO

CREATE USER Sasha;
GO
  • Az SQL Server-rendszergazdai fiókok bármilyen adatbázishoz csatlakozhatnak, és bármilyen adatbázisban több bejelentkezést és felhasználót hozhatnak létre.
  • Amikor létrehozol egy adatbázist, te leszel az adatbázis tulajdonosa, és csatlakozhatsz hozzá. Az adatbázis-tulajdonosok több felhasználót is létrehozhatnak.

Később engedélyezheti a többi bejelentkezést, hogy további bejelentkezéseket hozzon létre az ALTER ANY LOGIN engedély megadásával. Az adatbázison belül engedélyezheti más felhasználók számára, hogy további felhasználókat hozzanak létre az ALTER ANY USER engedély megadásával. Például:

GRANT ALTER ANY LOGIN TO Sasha;
GO

USE AdventureWorks2025;
GO

GRANT ALTER ANY USER TO Sasha;
GO

Most a bejelentkezés Sasha több bejelentkezést hozhat létre, és a felhasználó Sasha is több felhasználót hozhat létre.

Hozzáférés biztosítása a legkisebb jogosultságokkal

Az adminisztrátorok és az adatbázis-tulajdonosok általában az elsők a felhasználók, akik csatlakoznak egy felhasználói adatbázishoz. Ezek a fiókok minden jogosultságot megkapnak az adatbázisban. Ne használd ezeket a fiókokat olyan feladatokhoz, amelyekhez kevesebb jogosultságot igényelnek.

Amikor most kezded, általános jogosultságkategóriákat rendelhetsz a beépített fix adatbázis szerepekkel. Például a db_datareader fix adatbázis szerepe képes az adatbázis összes tábláját elolvasni, de nem tud változtatni. Adjon tagságot egy rögzített adatbázis-szerepkörhöz a ALTER ROLE utasítással. Az alábbi példa hozzáadja a felhasználót Sashaa db_datareader fix adatbázis szerepéhez.

USE AdventureWorks2025;
GO

ALTER ROLE db_datareader ADD MEMBER Sasha;

A rögzített adatbázis-szerepkörök listáját az Adatbázisszintű szerepkörök című témakörben találja.

Később, amikor készen állsz pontosabb hozzáférést konfigurálni az adataidhoz (nagyon ajánlott), hozd létre saját felhasználó által definiált adatbázis szerepeket a mondalommal CREATE ROLE . Ezután rendeljen hozzá konkrét részletes engedélyeket az egyéni szerepkörökhöz.

Például a következő utasítások létrehoznak egy adatbázis szerepet , amelynek címe Sales, lehetővé teszik a Sales csoportnak, hogy sorokat olvasson, frissítsen és töröljön a Orders táblából, majd hozzáadják a felhasználót Sasha a Sales szerepbe.

CREATE ROLE Sales;

GRANT SELECT ON OBJECT::Orders TO Sales;
GRANT UPDATE ON OBJECT::Orders TO Sales;
GRANT DELETE ON OBJECT::Orders TO Sales;

ALTER ROLE Sales ADD MEMBER Sasha;

Az engedélyrendszerrel kapcsolatos további információkért tekintse meg az adatbázismotor engedélyeinek első lépéseit.

Sorszintű biztonság konfigurálása

A sorszintű biztonság lehetővé teszi, hogy korlátozd az adatbázis sorainak hozzáférését a lekérdezést futtató felhasználó alapján. Ez a funkció hasznos olyan helyzetekben, mint amikor az ügyfelek csak a saját adataikhoz férhetnek hozzá, vagy hogy a dolgozók csak a saját osztályuk adataihoz juthassanak hozzá.

A következő lépések bemutatják, hogyan állíthat be két felhasználót, akik eltérő sorszintű hozzáféréssel rendelkeznek a Sales.SalesOrderHeader táblához.

Hozz létre két felhasználói fiókot a sorszintű biztonság tesztelésére:

USE AdventureWorks2025;
GO

CREATE USER Manager WITHOUT LOGIN;
CREATE USER SalesPerson280 WITHOUT LOGIN;

Olvasási hozzáférés biztosítása a Sales.SalesOrderHeader táblán mindkét felhasználó számára:

GRANT SELECT ON Sales.SalesOrderHeader TO Manager;
GRANT SELECT ON Sales.SalesOrderHeader TO SalesPerson280;

Hozzon létre egy új sémát és egy beágyazott táblaértékű függvényt. A függvény akkor tér vissza 1 , amikor az oszlop egyik sor SalesPersonID megegyezik egy SalesPerson felhasználó azonosítójával, vagy amikor a lekérdezést lefuttató felhasználó a Manager felhasználó.

CREATE SCHEMA Security;
GO

CREATE FUNCTION Security.fn_securitypredicate
(@SalesPersonID INT)
RETURNS TABLE
WITH SCHEMABINDING
AS
RETURN
    SELECT 1 AS fn_securitypredicate_result
    WHERE ('SalesPerson' + CAST (@SalesPersonID AS VARCHAR (16)) = USER_NAME())
          OR (USER_NAME() = 'Manager')

Hozzon létre egy biztonsági szabályzatot, amely szűrőként és blokk predikátumként is hozzáadja a függvényt a táblához:

CREATE SECURITY POLICY SalesFilter
    ADD FILTER PREDICATE Security.fn_securitypredicate(SalesPersonID) ON Sales.SalesOrderHeader,
    ADD BLOCK PREDICATE Security.fn_securitypredicate(SalesPersonID) ON Sales.SalesOrderHeader
    WITH (STATE = ON);

Futtassa le a következő utasításokat a(z) SalesOrderHeader tábla lekérdezéséhez, felhasználónként. Ellenőrizze, hogy SalesPerson280 csak a 95 sort látja-e a saját értékesítéséből, és hogy az Manager összes sor látható-e a táblában.

EXECUTE AS USER = 'SalesPerson280';

SELECT *
FROM Sales.SalesOrderHeader;

REVERT;

EXECUTE AS USER = 'Manager';

SELECT *
FROM Sales.SalesOrderHeader;

REVERT;

Változtasd meg a biztonsági szabályzatot, hogy letiltsd azt. Most már mindkét felhasználó hozzáférhet az összes sorhoz.

ALTER SECURITY POLICY SalesFilter
    WITH (STATE = OFF);

Dinamikus adatmaszkolás engedélyezése

A dinamikus adatmaszkolás lehetővé teszi, hogy bizonyos oszlopok teljes vagy részleges maszkolásával korlátozza a bizalmas adatoknak az alkalmazás felhasználóinak való kitettségét.

ALTER TABLE Utasítással egy maszkoló függvényt adhat hozzá a EmailAddress oszlopához a Person.EmailAddress táblában:

USE AdventureWorks2025;
GO

ALTER TABLE Person.EmailAddress
    ALTER COLUMN EmailAddress
        ADD MASKED WITH (FUNCTION = 'email()');

Hozzon létre egy új felhasználót TestUserSELECT jogosultsággal a táblára, majd TestUser felhasználóként hajtson végre egy lekérdezést a maszkolt adatok megtekintéséhez:

CREATE USER TestUser WITHOUT LOGIN;

GRANT SELECT
    ON Person.EmailAddress TO TestUser;

EXECUTE AS USER = 'TestUser';

SELECT EmailAddressID,
       EmailAddress
FROM Person.EmailAddress;

REVERT;

Ellenőrizze, hogy a maszkoló függvény módosítja-e az e-mail-címet az első rekordban:

EmailAddressID E-mail cím
1 ken0@adventure-works.com

ba

EmailAddressID E-mail cím
1 kXXX@XXXX.com

Transzparens adattitkosítás engedélyezése

Egy támadó ellophat adatbázisfájlokat a merevlemezedről. Ez akkor fordulhat elő, ha egy támadó magasabb szintű hozzáférést kap a rendszerhez, ha egy alkalmazott elveszi a fájlokat, vagy ha valaki ellopja a fájlokat tartalmazó számítógépet.

A transzparens adattitkosítás (TDE) a merevlemezen tárolt adatfájlokat titkosítja. master Az SQL Server adatbázismotor adatbázisa rendelkezik a titkosítási kulcstal, így a Database Engine képes kezelni az adatokat. Az adatbázisfájlok nem olvashatók a kulcs elérése nélkül. A felsőszintű adminisztrátorok kezelni, biztonsági mentést készíthetnek és újraalkotni a kulcsot, így csak kiválasztott személyek tudják áthelyezni az adatbázist. Ha bekapcsolod a TDE-t, az SQL Server automatikusan titkosítja az tempdb adatbázist is.

Mivel a Database Engine képes olvasni az adatokat, a TDE nem véd el a számítógép adminisztrátorainak engedély nélküli hozzáférése ellen, akik közvetlenül olvashatják a memóriát vagy az SQL Server-hez egy adminisztrátori fiókon keresztül.

TDE konfigurálása

  • Létrehoz egy mesterkulcsot
  • Főkulcs által védett tanúsítvány létrehozása vagy beszerzése
  • Hozz létre egy adatbázis-titkosítási kulcsot, és védd meg a tanúsítványsal
  • Az adatbázis beállítása titkosítás használatára

A TDE konfigurálásához CONTROL engedély szükséges a master adatbázisra és CONTROL engedély a felhasználói adatbázisra. Általában egy rendszergazda konfigurálja a TDE-t.

Az alábbi példa a AdventureWorks2025 adatbázis titkosítását és visszafejtését mutatja be egy, a kiszolgálóra telepített, MyServerCert nevű tanúsítvánnyal.

USE master;
GO

CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<master-key-password>';
GO

CREATE CERTIFICATE MyServerCert
    WITH SUBJECT = 'My Database Encryption Key Certificate';
GO

USE AdventureWorks2025;
GO

CREATE DATABASE ENCRYPTION KEY WITH ALGORITHM = AES_256
    ENCRYPTION BY SERVER CERTIFICATE MyServerCert;
GO

ALTER DATABASE AdventureWorks2025
    SET ENCRYPTION ON;

A TDE eltávolításához futtassa a következő parancsot:

ALTER DATABASE AdventureWorks2025
    SET ENCRYPTION OFF;

Az SQL Server ütemezi a titkosítási és dekódolási műveleteket háttérszálakon. Ezeknek a műveleteknek az állapotát a katalógusnézetekkel és dinamikus menedzsment nézetekkel tekintheti meg a későbbi cikkben található listában.

Warning

Az adatbázis-titkosítási kulcs a TDE-t használó adatbázisok biztonsági mentésfájljait is titkosítja. Ennek eredményeképpen ezeknek a biztonsági másolatoknak a visszaállításakor elérhetővé kell tenni az adatbázis titkosítási kulcsát védő tanúsítványt. Az adatbázis mentelése mellett a szerver tanúsítványokat is le kell mentened, hogy elkerüld az adatvesztést. Adatvesztés akkor következik, ha a tanúsítvány már nem elérhető. További információ: SQL Server-tanúsítványok és aszimmetrikus kulcsok.

A TDE-ről további információt a Transzparens adattitkosítás (TDE) című témakörben talál.

Biztonsági mentés titkosításának konfigurálása

Az SQL Server képes titkosítani adatokat biztonsági mentés közben. A biztonsági mentés létrehozásakor a titkosítási algoritmus és a titkosító (tanúsítvány vagy aszimmetrikus kulcs) megadásával létrehozhat egy titkosított biztonsági mentési fájlt.

Warning

Mindig biztonsági mentést kell készíteni a tanúsítványról vagy aszimmetrikus kulcsról, lehetőleg egy másik helyre, mint a titkosított biztonsági mentési fájlról. A tanúsítvány vagy az aszimmetrikus kulcs nélkül nem állíthatja vissza a biztonsági másolatot, így a biztonsági mentési fájl használhatatlanná válik.

Az alábbi példa létrehoz egy tanúsítványt, majd létrehoz egy, a tanúsítvány által védett biztonsági másolatot.

USE master;
GO

CREATE CERTIFICATE BackupEncryptCert
    WITH SUBJECT = 'Database backups';
GO

BACKUP DATABASE [AdventureWorks2025]
TO DISK = N'/var/opt/mssql/backups/AdventureWorks2025.bak'
WITH COMPRESSION,
    ENCRYPTION (ALGORITHM = AES_256, SERVER CERTIFICATE = BackupEncryptCert),
    STATS = 10;
GO

További információ: Biztonsági másolat titkosítása.

Kapcsolódó tartalom

  • Utolsó frissítés időpontja: