6 SQL Server biztonsági alapok, amelyeket minden adatbázis-adminisztrátornak tudnia kell

Túl sok adatszivárgást a rosszul védett adatbázis-kiszolgálók okoznak. A Microsoft SQL Server népszerű vállalati megoldás, de megértése és konfigurálása is bonyolult. Íme 6 SQL Server biztonsági funkció, amelyeket tudnia kell a szerver adatainak védelme érdekében.

1. SQL Server hitelesítés vs. Windows hitelesítés

A Microsoft SQL Server két hitelesítési lehetőséget támogat:

A Windows-hitelesítés az Active Directoryra (AD) támaszkodik a felhasználók hitelesítésére, mielőtt SQL-hez kapcsolódnának. Ez az ajánlott hitelesítési mód, mivel az AD a legjobb módja a jelszóházirendek, valamint a szervezetben lévő alkalmazásokhoz való felhasználói és csoportos hozzáférések kezelésének. .
Az SQL Server Authentication úgy működik, hogy a felhasználóneveket és jelszavakat az adatbázis-kiszolgálón tárolja. Olyan helyzetekben használható, amikor az Active Directory nem érhető el.

Az SQL Server és a Windows hitelesítés egyidejűleg is használható (vegyes mód), de lehetőség szerint kizárólag a Windows hitelesítést használja.

Ha SQL Server hitelesítést kell használnia, győződjön meg arról, hogy az alapértelmezett sa-fiók le van tiltva, vagy erős jelszóval rendelkezik, amelyet gyakran cserélnek, mivel ezt a fiókot gyakran célba veszik a hackerek. Az SQL Server-fiókok, beleértve az sa-t is (ha engedélyezve van), az SQL Server Management Studio szolgáltatással vagy az ALTER LOGIN Transact-SQL (T-SQL) paranccsal kezelhetők.

2. Szerverbejelentkezések és szerepkörök

A választott hitelesítési módszertől függetlenül kétféle bejelentkezést konfigurálhat az SQL-példányokhoz: a felhasználói bejelentkezéseket és a szerverbejelentkezéseket. A felhasználói bejelentkezésekről a következő részben fogok beszélni. A kiszolgálói bejelentkezés lehetővé teszi a felhasználók számára, hogy kapcsolatot létesítsenek egy SQL Server-példánnyal. Minden kiszolgálói bejelentkezéshez egy vagy több kiszolgálói szerepkör van hozzárendelve, amelyek lehetővé teszik bizonyos műveletek végrehajtását a példányon. Alapértelmezés szerint a kiszolgálói bejelentkezésekhez nyilvános kiszolgálói szerepkör van hozzárendelve, amely alapvető hozzáférést biztosít a példányhoz. További elérhető szerepek: bulkadmin, sercurityadmin, dbcreator és serveradmin.

Szerverbejelentkezések hozhatók létre a T-SQL vagy az SQL Server Management Studio használatával. Szerverbejelentkezés létrehozásakor meg kell adni egy alapértelmezett adatbázist. A szerverbejelentkezések az alapértelmezett adatbázisban lévő felhasználói bejelentkezéshez vannak társítva. Érdemes megjegyezni, hogy a szerver bejelentkezési nevének és a hozzá tartozó felhasználói bejelentkezés nevének nem kell egyeznie. Ha az alapértelmezett adatbázisban nincs társított felhasználói objektum, a rendszer megtagadja a kiszolgálói bejelentkezést, kivéve, ha a bejelentkezéshez rendelt kiszolgálói szerepkör minden adatbázishoz hozzáfér. A szerverbejelentkezések egy vagy több adatbázisban leképezhetők egy felhasználóhoz, és a szerverbejelentkezések beállításakor létrehozhat felhasználókat.

3. Adatbázis-felhasználók, séma és szerepkörök

A felhasználói bejelentkezés létrehozásakor meg kell adnia az adatbázist, amelyhez hozzá lesz rendelve, egy felhasználónevet és egy alapértelmezett sémát, amely a felhasználó által létrehozott összes objektumra vonatkozik, ha nincs más séma megadva. Az SQL Server sémák objektumok, például táblák és nézetek gyűjteményei, amelyek logikailag el vannak választva más adatbázis-objektumoktól, ami megkönnyíti a hozzáférés kezelését, és azt jelenti, hogy nincs szükség a sémanév használatára, amikor T-SQL-parancsokat futtat egy adatbázissal szemben.

A felhasználó által meghatározott objektumok alapértelmezett séma a dbo. A másik alapértelmezett séma a sys; az összes rendszerobjektum tulajdonosa.

Ugyanúgy, ahogy a kiszolgálói bejelentkezésekhez kiszolgálói szerepköröket rendelnek, a felhasználói bejelentkezésekhez adatbázis-szerepköröket rendelnek, amelyek jogokat rendelnek hozzá az adatbázisokhoz. A szerveradatbázis-szerepek közé tartozik a public, db accessadmin, db tulajdonos és a db securityadmin.

4. Biztonságos elemek és engedélyek

Ha a szerver- vagy adatbázis-szerepkörök túl sok vagy túl kevés hozzáférést adnának a felhasználónak, ehelyett hozzárendelhet egy vagy több biztonságossá tételt. A biztosítható elemek a szerver, a séma és az adatbázis szintjén léteznek; ezek SQL Server-erőforrások, amelyekhez szerver és felhasználói bejelentkezésekkel lehet hozzáférni. A biztonságossá tételek használatával például csak egy adott táblához vagy függvényhez adhat hozzáférést a kiszolgálónak, olyan részletességgel, amely nem lehetséges a bejelentkezéshez szerepkör hozzárendelésével.

Az engedélyek az SQL Server biztonságossá tételéhez való hozzáférés biztosítására szolgálnak. Engedélyt adhat az adatok megtekintésére vagy csak az adatok módosítására. A GRANT, DENY és REVOKE T-SQL utasítások az engedélyek konfigurálására szolgálnak.

Az engedélyek azonban bonyolultak lehetnek. Például a DENY engedélyek beállítása egy biztonságosan megakadályozza az engedélyek öröklődését az alacsonyabb szintű objektumokon. De az oszlopszintű GRANT engedély felülírja a DENY-t az objektum szintjén, így a táblán beállított DENY engedélyt felülírja az oszlop GRANT engedélye. Mivel az engedélyek összetettek lehetnek, mindig érdemes ellenőrizni a hatékony engedélyeket T-SQL használatával. A következő parancs határozza meg JoeB engedélyeit egy objektumhoz, ebben az esetben egy „alkalmazottak” nevű táblához.

SELECT * FROM fn_my_permissions('joeb', alkalmazottak);
GOt

5. Adattitkosítás

Az SQL Server több titkosítási lehetőséget is támogat:

A Secure Sockets Layer (SSL) titkosítja a forgalmat, amikor az a szerverpéldány és az ügyfélalkalmazás között halad, hasonlóan ahhoz, ahogy az internetes adatforgalom biztonságos a böngésző és a szerver között. Ezenkívül a kliens a kiszolgáló tanúsítványával ellenőrizheti a szerver azonosságát.
A Transparent Data Encryption (TDE) titkosítja a lemezen lévő adatokat. Pontosabban, titkosítja a teljes adatot és naplófájlt. Az ügyfélalkalmazásokat nem kell módosítani, ha a TDE engedélyezve van
A Biztonsági mentés titkosítása hasonló a TDE-hez, de az SQL biztonsági másolatokat titkosítja az aktív adatok és naplófájlok helyett.
Az oszlop-/cellaszintű titkosítás gondoskodik arról, hogy bizonyos adatok titkosítva legyenek az adatbázisban, és akkor is titkosítva maradjanak, ha azokat a memóriában tárolják. Az adatok visszafejtése egy függvény segítségével történik, és ehhez módosítani kell az ügyfélalkalmazásokon
A Mindig titkosítva az oszlop-/cellaszintű titkosítás továbbfejlesztése, mivel nem igényel változtatásokat az ügyfélalkalmazásokon; az adatok titkosítva maradnak a hálózaton, a memóriában és a lemezen. Ezenkívül megvédi az érzékeny adatokat a kiváltságos SQL Server felhasználók kíváncsi tekintetétől. Ezzel a titkosítási lehetőséggel azonban problémák adódhatnak - mivel az SQL Server nem tudja olvasni az adatokat, egyes indexelések és funkciók nem működnek.

6. Sorszintű biztonság

A sorszintű biztonság (RLS) lehetővé teszi a szervezetek számára, hogy szabályozzák, ki láthatja a sorokat az adatbázisban. Például korlátozhatja a felhasználókat, hogy csak azokat a sorokat lássák, amelyek az ügyfeleikről tartalmaznak információkat.

Az RLS három fő részből áll: egy predikátum függvényből, egy biztonsági predikátumból és egy biztonsági szabályzatból. A predikátum függvény azt ellenőrzi, hogy az adatbázis-lekérdezést végrehajtó felhasználó logika alapján hozzáfér-e egy sorhoz. Például ellenőrizheti, hogy a lekérdezést futtató felhasználó felhasználóneve megegyezik-e a sor valamelyik oszlopában található mezővel. A predikátumfüggvény és a biztonsági predikátum együtt vannak definiálva egy függvényben, hogy vagy csendben szűrjék a lekérdezések eredményeit, hibák nélkül, vagy hibával blokkolják, ha a sorhoz való hozzáférés meg van tiltva. Végül egy biztonsági szabályzat a függvényt egy táblához köti.