Hozzáférés-vezérlők az SQL felhasználókhoz és szerepekhez

A biztonság kiemelkedő fontosságú az adatbázis-adminisztrátorok számára, akik gigabájt létfontosságú üzleti adatokat védenek a jogosulatlan kívülállók és a bennfentesek kíváncsi tekintetéből. Minden relációs adatbázis-kezelő rendszer egyfajta belső biztonsági mechanizmust biztosít a veszélyek minimalizálására. Ezek a Microsoft Access által nyújtott egyszerű jelszavas védelemtől a komplex felhasználói / szerep struktúrához tartoznak, amelyet olyan fejlett relációs adatbázisok támogatnak, mint az Oracle és a Microsoft SQL Server. Ez a cikk a Strukturált lekérdezési nyelv (vagy SQL ) megvalósítását végző összes adatbázisra jellemző biztonsági mechanizmusokra összpontosít. Együtt megismerkedünk az adatokhoz való hozzáférés ellenőrzésének megerősítésével és az adatok biztonságának biztosításával.

felhasználók

A kiszolgálóalapú adatbázisok mindegyike támogatja a számítógépes operációs rendszerekhez hasonló felhasználói koncepciót. Ha ismeri a Microsoft Windows NT és Windows 2000 rendszerben található felhasználó / csoport hierarchiát, akkor az SQL Server és az Oracle által támogatott felhasználók / szerepkörcsoportok nagyon hasonlóak.

Nagyon ajánlott egyedi adatbázis-felhasználói fiókokat létrehozni minden olyan személy számára, aki hozzáfér az adatbázisához. Műszakilag lehetséges megosztani a fiókokat a felhasználók között, vagy egyszerűen csak egy felhasználói fiókot használnia minden olyan felhasználónak, amelyiknek hozzáférést kell biztosítania az adatbázisához, de két okból nagyon elhárítom ezt a gyakorlatot. Először is megszünteti az egyéni elszámoltathatóságot - ha egy felhasználó módosítja az adatbázist (mondjuk 5000 dollár emeléssel), akkor nem lesz képes nyomon követni egy bizonyos személyhez audit naplók használatával. Továbbá, ha egy adott felhasználó elhagyja a szervezetét, és eltávolítani kívánja a hozzáférését az adatbázisból, akkor kényszerül arra, hogy megváltoztassa a jelszót, amelyet minden felhasználó támaszkodik.

A felhasználói fiókok létrehozásának módszerei platformonként eltérőek, és a pontos eljáráshoz kell fordulnia a DBMS-specifikus dokumentációhoz. A Microsoft SQL Server felhasználóknak meg kell vizsgálniuk a sp_adduser tárolt eljárás használatát. Az Oracle adatbázis-adminisztrátorok hasznosnak találják a CREATE USER parancsot. Lehet, hogy meg akarja vizsgálni az alternatív hitelesítési rendszereket is. A Microsoft SQL Server például támogatja a Windows NT Integrated Security használatát. A rendszer keretében a felhasználók a Windows NT felhasználói fiókjukkal azonosíthatók az adatbázisba, és nem szükséges további felhasználói azonosítót és jelszót megadni az adatbázis eléréséhez. Ez a megközelítés rendkívül népszerű az adatbázis-adminisztrátorok körében, mert a számlavezetés terhét a hálózati ügyintézői személyzetre tolja át, és egyszerű hozzáférést biztosít a végfelhasználó számára.

szerepek

Ha kevés felhasználóval rendelkező környezetben tartózkodik, akkor valószínűleg elegendő lesz a felhasználói fiókok létrehozásához és az engedélyek közvetlen hozzárendeléséhez. Ha azonban nagy számú felhasználó van, valószínűleg túlterhelik a fiókok és a megfelelő engedélyek terhelése. E teher enyhítésére relációs adatbázisok támogatják a szerepek fogalmát. Az adatbázis-szerepek hasonlóan működnek a Windows NT csoportokhoz. A felhasználói fiókokat szerepkörökhöz rendelik, és a jogosultságokat az egész szerephez hozzárendelik az egyes felhasználói fiókok helyett. Például létre tudunk hozni egy DBA-szerepkört, majd hozzáadhatjuk adminisztratív személyzetünk felhasználói fiókját ehhez a szerephez. Miután ezt megtettük, a jelenlegi (és a jövőbeli) rendszergazdák számára egy külön engedélyt rendelhetünk hozzá, egyszerűen megadva az engedélyt a szerephez. Ismét a szerepkörök létrehozásának eljárása platformról platformra változik. Az MS SQL Server rendszergazdái megvizsgálják a sp_addrole tárolt eljárást, míg az Oracle DBA-k a CREATE ROLE szintaxist használják.

Engedélyek megadása

Most, hogy hozzáadtuk a felhasználókat adatbázisunkba, itt az ideje, hogy engedélyekkel bővítsük a biztonság megerősítését. Első lépésünk a megfelelő adatbázis-engedélyek megadása a felhasználók számára. Ezt az SQL GRANT nyilatkozat használatával fogjuk elérni.

Itt van a nyilatkozat szintaxisa:

GRANT
[ON ]
TO
[WITH GRANT OPTION]

Most vessünk egy pillantást az utasításra line-by-line. Az első sor, a GRANT lehetővé teszi számunkra, hogy megadjuk a megadott táblázati engedélyeket. Ezek lehetnek asztalszintű jogosultságok (például SELECT, INSERT, UPDATE és DELETE) vagy adatbázis-engedélyek (például CREATE TABLE, ALTER DATABASE és GRANT). Egyetlen GRANT utasításban több engedély is megadható, de az asztalszintű engedélyek és az adatbázis szintű engedélyek nem kombinálhatók egyetlen utasításban.

A második sor, az ON az asztalszintű jogosultságok érintett táblázatának meghatározására használható. Ez a sor elhagyott, ha adatbázis-szintű engedélyeket adunk. A harmadik sor határozza meg a jogosultsággal rendelkező felhasználókat vagy szerepet.

Végül a negyedik sor, WITH GRANT OPTION opció. Ha ez a sor szerepel a nyilatkozatban, akkor az érintett felhasználó engedélyezheti ugyanezen jogosultságok más felhasználók számára is. Ne feledje, hogy a WITH GRANT OPTION nem adható meg, ha a jogosultságokat egy szerephez rendelik.

Példák

Nézzünk néhány példát. Első forgatókönyvünkben nemrégiben felvettünk egy 42 adatbeviteli szolgáltatócsoportot, akik hozzáadják és karbantartják az ügyfélrekordokat. Meg kell tudniuk férni az információkhoz az Ügyfelek táblázatban, módosítani kell ezeket az információkat, és új rekordokat kell hozzáadni az asztalhoz. Nem szabadna teljes mértékben törölni egy rekordot az adatbázisból. Először létre kell hoznunk felhasználói fiókokat minden egyes operátor számára, majd mindegyiket hozzáadni egy új szerephez, a DataEntry-hez. Ezt követően a következő SQL utasítással kell megadnunk a megfelelő jogosultságokat:

GRANT SELECT, INSERT, UPDATE
ON ügyfelek
TO DataEntry

És mindennek van rajta! Most vizsgáljuk meg azt az esetet, amikor adatbázis-szintű engedélyeket rendelünk hozzá. Azt szeretnénk, hogy a DBA-szerepkör tagjai új táblázatokat adhassanak az adatbázisunkba. Továbbá azt is szeretnénk, hogy a többi felhasználó engedélyt kapjon arra, hogy ugyanezt tegye. Itt van az SQL utasítás:

GRANT CREATE TÁBLÁZAT
A DBA-hoz
GRANT OPCIÓNAK

Vegye figyelembe, hogy a WITH GRANT OPTION vonalat beillesztettük annak biztosítására, hogy DBA-k hozzárendeljék ezt az engedélyt más felhasználókhoz.

Engedélyek eltávolítása

Miután engedélyeket adtunk, gyakran bizonyítani kell, hogy később visszavonjuk őket. Szerencsére az SQL megadja a REVOKE parancsot a korábban megadott engedélyek eltávolítására. Itt van a szintaxis:

REVOKE [GRANT OPTION FOR]
ON
FROM

Észre fogod venni, hogy a parancs szintaxisa hasonló a GRANT parancshoz. Az egyetlen különbség az, hogy A GRANT OPTION a REVOKE parancssoron van megadva, nem pedig a parancs végén. Például képzeljük el, hogy visszavonjuk Mária korábban megadott engedélyét a rekordok eltávolítására az Ügyfelek adatbázisából. A következő parancsot használnánk:

REVOKE DELETE
ON ügyfelek
Marytől

És mindennek van rajta! A Microsoft SQL Server támogatja a DENY parancsot. Ezzel a paranccsal kifejezetten megtagadhatja egy olyan felhasználó engedélyét, amelyet egyébként egy jelenlegi vagy jövőbeni szerepkör tagságán keresztül lehetne megtenni. Itt van a szintaxis:

DENY
ON
TO

Példák

Visszatérve a korábbi példánkra, képzeljük el, hogy Mary szintén tagja volt a Menedzserek szerepnek, amely szintén hozzáférést biztosított az Ügyfelek táblához. Az előző REVOKE nyilatkozat nem elegendő ahhoz, hogy megtagadja az asztalhoz való hozzáférését. Eltávolítja a GRANT nyilatkozatán keresztül megadott engedélyét, amely a felhasználói fiókját célozza meg, de nem befolyásolja a vezetői szerepben való tagságából származó engedélyeket. Azonban ha DENY nyilatkozatot használunk, blokkolja az engedély örökségét. Itt van a parancs:

TENNI TÖRLÉS
ON ügyfelek
Maryhez

A DENY parancs alapvetően egy "negatív engedélyt" hoz létre az adatbázis-hozzáférés-vezérlésekben. Ha később úgy döntünk, hogy Mary-nek engedélyezzük a sorok eltávolítását az Ügyfelek táblából, nem egyszerűen használhatjuk a GRANT parancsot. Ezt a parancsot a meglévő DENY azonnal felülírná. Ehelyett először a REVOKE parancsot használnánk a negatív engedélybejegyzés eltávolításához a következőképpen:

REVOKE DELETE
ON ügyfelek
Marytől

Észre fogja venni, hogy ez a parancs pontosan ugyanaz, mint amit a pozitív engedély eltávolítására használt. Ne feledje, hogy a DENY és a GRANT parancsok mind hasonló módon működnek * mdash, mindkettő engedélyeket (pozitív vagy negatív) hoz létre az adatbázis-hozzáférés-vezérlési mechanizmusban. A REVOKE parancs eltávolítja a megadott felhasználó összes pozitív és negatív engedélyét. Miután kiadta ezt a parancsot, Mary képes lesz arra, hogy törölje a sorokat az asztalról, ha olyan szerepkör tagja, amely rendelkezik ezzel az engedéllyel. Alternatív megoldásként egy GRANT parancsot is ki lehet adni, hogy a DELETE engedélyt közvetlenül a fiókjához adják.

A cikk folyamán megtudtál egy jó üzletet a szabványos lekérdezési nyelv által támogatott hozzáférés-ellenőrzési mechanizmusokról. Ez a bevezetés jó kiindulási pontot nyújt, de javaslom, hogy hivatkozzon a DBMS dokumentációjára, hogy megtudja a rendszer által támogatott fokozott biztonsági intézkedéseket. Meg fogja találni, hogy számos adatbázis támogatja a fejlettebb hozzáférés-vezérlési mechanizmusokat, például az egyes oszlopok engedélyezését.