Delphi - MS SQL adatbázis kezelés Delphi-ből

MS SQL 29. rész

forráskód letöltése
Az SQL Server használata során két biztonsági szintnek kell megfelelnünk. A hitelesítési (authentication) fázisban a rendszer azonosítja a felhasználót, de csak azt ellenőrzi, hogy a felhasználó csatlakozhat-e az SQL Serverhez. Sikeres belépés után a felhasználónak minden egyes adatbázishoz külön biztonsági fiókkal (security account) kell rendelkeznie. A jogosultságellenőrzési (permission validation) fázis ellenőrzi, hogy a felhasználó jogosult-e elvégezni az általa kiadott műveleteket.
Mellékelt példában az SQL Server biztonsági rendszerével foglalkozunk. Az SQL Server kétféle hitelesítést használ, a Windows NT hitelesítést és az SQL Server hitelesítést.

Windows NT hitelesítés

Windows NT hitelesítéskor az SQL Server a munkát az NT-re bízza. Az SQL Server beállításakor azt kell meghatározni, hogy mely NT felhasználók vagy felhasználó csoportok csatlakozhatnak az SQL Serverhez. Ezeket az információkat az SQL Server a syslogins táblában tárolja. Ha a felhasználó a felhasználói név megadása nélkül kísérel meg belépni, az SQL Server automatikusan Windows NT hitelesítést használ. Ha az SQL Server Windows NT hitelesítésre van konfigurálva és a felhasználó belépéskor megad egy felhasználói nevet, azt az SQL Server nem veszi figyelembe. A Windows NT hitelesítésnek van néhány nyilvánvaló előnye az SQL Server hitelesítéssel szemben, mégpedig azok az előnyök, amiket a Windows NT biztonsági rendszere kínál. Ilyenek pl. a biztonsági naplózás (auditing), a jelszóra vonatkozó megszorítások, a fiókok zárolása többszöri helytelen bejelentkezési kísérlet esetén, stb.

A Windows NT hitelesítés csak NT Serveren futó SQL Server esetében elérhető.

SQL Server hitelesítés

SQL Server hitelesítéskor az SQL Server maga dönti el, hogy a felhasználó csatlakozhat-e vagy sem. A rendszergazda feladata, hogy az SQL Serverben beállítsa a bejelentkezési fiókokat és a jelszavakat. Itt is a syslogins táblában tárolódnak az információk.



Az SQL Server hitelesítésre egyrészt a régebbi verziókkal való kompatibilitás miatt van szükség, másrészt a Windows 95/98-on futtatott SQL Serverek nem támogatják a Windows NT hitelesítést.

Hitelesítési módok

A fenti hitelesítéseket kétféle módban állíthatjuk be az SQL Serveren. Vagy Windows NT hitelesítést használunk (Windows NT hitelesítési mód) vagy mindkettőt egyszerre (Vegyes mód - Mixed). Utóbbi esetben, ha a felhasználó a csatlakozás alkalmával megad egy felhasználói fiókot, akkor SQL Server hitelesítés valósul meg, ha nem ad meg, akkor Windows NT hitelesítés.

A hitelesítést az Enterprise Managerben állíthatjuk be. Kattintsunk jobb gombbal a szerver nevén majd a Properties menüponton, és válasszuk a Security fület. A hitelesítés megadása mellett itt beállíthatjuk a bejelentkezések naplózását is.

Bejelentkezés után az egyes adatbázis objektumok eléréséhez a felhasználónak az adatbázison belül rendelkeznie kell biztonsági fiókkal. Így könnyen elérhető, hogy egy felhasználó csak azokba az adatbázisokba nyerjen betekintést, amikbe az adminisztrátor azt engedélyezi. A felhasználó sikeres csatlakozása után mindenféle műveleteket szeretne végrehajtani. A műveletek az SQL Serverhez T-SQL utasítások formájában jutnak el. Minden utasítás végrehajtása előtt az SQL Server ellenőrzi, hogy az adott felhasználó rendelkezik-e a megfelelő jogosultságokkal. Az ehhez szükséges információk a sysprotects rendszertáblában tárolódnak. Ha a jogosultság hiányzik, a művelet végrehajtása meghiúsul és egy hozzáférési hiba keletkezik.

A Windows NT-hez hasonlóan az SQL Server is hierarchikus struktúrába szervezi a felhasználókat. Hogy egyszerűbb legyen a felhasználók adminisztrálása, csoportokba rendezhetjük őket és szerepeket rendelhetünk hozzájuk. Ha egy csoportra definiálunk biztonsági beállítást, az a csoport minden tagjára vonatkozni fog.

A bejelentkezési és biztonsági fiókok beállításai (login account, security account)
SQL Serverhez való csatlakozást engedélyezhetünk már létező Windows NT felhasználói fiókoknak. Ha egy csoport minden tagja csatlakozhat az SQL Serverhez, a jogot hozzárendelhetjük magához a csoporthoz is, ha nem csatlakozhat minden tag, egyesével kell jogosultságot kiosztani a megfelelő felhasználóknak. Az engedélyezéskor mindig specifikálnunk kell a tartomány vagy számítógép nevét is. Pl. ha a London tartomány Andrew felhasználójának kell hozzáférést biztosítanunk, felhasználói névként a London\Andrew-t kell megadnunk.

Az erre szolgáló T-SQL utasítás az
sp_grantlogin 'login'
A fenti példánál maradva
EXEC sp_grantlogin 'London\Andrew'
Ezzel az utasítással a London tartomány Andrew nevű felhasználóját feljogosítottuk, hogy belépjen az SQL Serverbe. Azonban még csak a csatlakozást engedélyeztük, az adatbázisokhoz még nem fér hozzá.

Ha a belépési jogosultságát fel akarjuk függeszteni, az sp_denylogin utasítást használhatjuk.
EXEC sp_denylogin 'London\Andrew'
Ha az NT felhasználói fiók bejegyzést törölni szeretnénk az SQL Serverből, az sp_revokelogin utasítást használhatjuk.
EXEC sp_revokelogin 'London\Andrew'
A revokelogin utasítás nem akadályozza meg explicit módon, hogy az adott felhasználó belépjen az SQL Serverbe, mindössze annyi történik, hogy a megadott felhasználói névvel nem lehet belépni. A felhasználó továbbra is beléphet, ha például tagja egy olyan csoportnak, akinek belépési jogosultsága van. Explicit kitiltáshoz a már említett denylogin utasítást kell használnunk.

Ugyanezeket az utasításokat használhatjuk akkor is, ha felhasználó csoportokat szeretnénk menedzselni. A Windows NT kétféle csoportot különböztet meg, vannak lokális és globális csoportok. Globális csoportba egy tartomány felhasználói tartozhatnak. Globális csoport tagja nem lehet egy lokális csoport, illetve nem lehet tag egy másik tartomány felhasználója sem. Lokális csoportba tartozhatnak globális csoportok, a tartomány felhasználói vagy akár más tartományok felhasználói is, ha a tartományok között trust kapcsolat van.

Vannak beépített lokális csoportok, mint pl. az Administrators, Users vagy Guests. Ezeknek a csoportoknak is adhatunk belépési jogosultságot, de a tartománynév helyett a BUILTIN kulcsszót kell használnunk.
EXEC sp_grantlogin 'BUILTIN\Administrators'
Ha az NT Servertől függetlenül szeretnénk SQL Server bejelentkezési fiókot létrehozni, az sp_addlogin utasítást használhatjuk.
sp_addlogin 'login'[, 'password'][, 'database']
Példák:

1. Hozzunk létre egy bejelentkezési fiókot Victoria néven.
EXEC sp_addlogin 'Victoria'
2. Hozzunk létre egy bejelentkezési fiókot Victoria néven, de most adjunk meg jelszót is (food), és azt az adatbázist, ahová a felhasználó bejelentkezés után kerül (corporate).
EXEC sp_addlogin 'Albert', 'food', 'corporate'
Az adminisztrátor egy előre definiált fiókot használhat a belépéshez: sa. A Microsoft ajánlása szerint azonban célszerű az adminisztrátoroknak is létrehozni felhasználói fiókokat, és az sa fiókot csak akkor használni, ha erre szükség van (pl. az adminisztrátor elfelejtette a jelszavát). Az SQL Server telepítésekor az sa fiók jelszó nélkül jön létre. Nagyon ajánlott rögtön a telepítés után jelszót rendelni ehhez a fiókhoz.

SQL Server bejelentkezési fiókot az sp_droplogin utasítással törölhetünk.
sp_droplogin 'Victoria'
A felhasználók bármikor megváltoztathatják jelszavukat az sp_password utasítást használva:
sp_password 'régi jelszó', 'új jelszó', 'login'
Az adminisztrátor bárkinek megváltoztathatja a jelszavát, a régi jelszó helyére NULL-t kell írni:
EXEC sp_password NULL, 'ok', 'Victoria'
Eddig áttekintettük az SQL Server eléréséhez szükséges bejelentkezési fiók (login account) beállítására vonatkozó utasításokat. Ezeket két csoportra osztottuk; a grantlogin, denylogin és revokelogin utasítások NT bejelentkezési fiókokra vonatkoztak, az addlogin és droplogin utasítások pedig SQL Server bejelentkezési fiókokra.

Miután egy bejelentkezési fiókot (login account) beállítottunk, azt minden olyan adatbázisban biztonsági fiókhoz (security account) kell rendelni, amikben a felhasználónak hozzáférést szeretnénk biztosítani. Ez az a bizonyos - a fejezet elején már említett - második biztonsági szint.

Minden adatbázisban van egy sysusers rendszertábla, ami soronként tartalmazza azokat a felhasználókat és csoportokat, akik valamilyen kapcsolatban vannak az adatbázissal. A kapcsolat jellegét, vagyis a konkrét jogosultságokat a sysprotects tábla tartalmazza.
Biztonsági fiókot az sp_grantdbaccess utasítással hozhatunk létre.
sp_grantdbaccess 'login', 'name_in_db'
A login az a bejelentkezési fiók, amihez most biztonsági fiókot fogunk rendelni. A name_in_db pedig ennek a biztonsági fióknak a neve. Például szeretnénk majd jogosultságot adni a London\Andrew NT felhasználónak a NorthWind adatbázisban, és ehhez először el szeretnénk készíteni az ő biztonsági fiókját, aminek legyen a neve egyszerűen Andrew:
EXEC sp_grantdbaccess 'London\Andrew', 'Andrew'
A biztonsági fiókokat az adatbázisból az sp_revokedbaccess utasítás távolítja el.
EXEC sp_revokedbaccess 'London\Andrew'
Míg a Windows NT bejelentkezési fiókokat és az SQL Server bejelentkezési fiókokat más utasításokkal kezeltük, a biztonsági fiókok létrehozása mindkét esetben az sp_grantdbaccess utasítással történik. Az Enterprise Managerben is ugyanott történik a beállítás: a Databases mappára kattintva válasszuk ki az adatbázist, és a nevén kattintsunk jobb egérgombbal, majd válasszuk a New database user... menüpontot.

Az adatbázis tulajdonosa (dbo, database owner)

Az a felhasználó, aki létrehoz egy adatbázist, automatikusan az adatbázis tulajdonosává válik. Ha azt szeretné, hogy az általa létrehozott adatbázishoz illetve annak objektumaihoz más is hozzáférjen, jogosultságokat kell kiosztania.

Ha el szeretnénk érni egy olyan objektumot, amit egy másik felhasználó hozott létre, az objektum nevének megadásakor annak tulajdonosát is specifikálnunk kell (táblanév helyett tulajdonos.táblanév). Ha ezt nem tesszük meg, akkor az SQL Server először a saját objektumaink között kezd el keresni, majd a dbo objektumait nézi végig. Ha nem találja a hivatkozott objektumot, akkor hibaüzenetet kapunk.

Például a John nevű felhasználó létrehoz egy táblát T1 néven. Ha most saját maga szeretné elérni a táblát, elég T1 néven hivatkoznia rá. Más felhasználóknak azonban John nevét is meg kell adniuk: John.T1. Ellenkező esetben az SQL Server először a saját, majd a dbo objektumai között keres, és mivel nem talál T1 táblát, hibát jelez. Nagyobb a baj, ha talál ilyet, mert ez esetben nem azokat az adatokat értük el, amiket szerettünk volna, és nem biztos, hogy azonnal észrevesszük.

Egy adatbázis objektum tulajdonosát az sp_changeobjectowner utasítással változtathatjuk meg.
sp_changeobjectowner 'object', 'owner'
Például nevezzük ki az Andrew nevű felhasználót az authors tábla tulajdonosává:
EXEC sp_changeobjectowner 'authors', 'London\Andrew'
Az sp_changeobjectowner utasítást természetesen nem használhatja mindenki, csak a db_owner, db_dlladmin és a db_securityadmin beépített adatbázis szerepek tagjai adhatják ki. (A szerepekről néhány bekezdéssel később beszélünk.)
Magának az adatbázisnak a tulajdonosát az sp_changedbowner utasítással módosíthatjuk.
EXEC sp_changedbowner 'Andrew'
Az adatbázist nem kell megadnunk, a parancs arra vonatkozik, amelyikben éppen vagyunk. A master, model és tempdb adatbázisok tulajdonosát nem lehet megváltoztatni. Ezt az utasítást csak a sysadmin szerep tagjai adhatják ki.

Guest

A guest felhasználói fiók lehetővé teszi az adatbázis megtekintését mindazoknak, akik nem rendelkeznek biztonsági fiókkal az adott adatbázisban. Kétféleképpen lehet valaki guest egy adatbázisban:

1. Belépett az SQL Serverbe, tehát rendelkezik bejelentkezési fiókkal, de az adott adatbázisban nincs biztonsági fiókja.

2. Az adatbázisban definiáltunk guest fiókot, és a felhasználó ezt használva lépett be.
A guest fiókhoz ugyanúgy rendelhetünk jogosultságokat, mint a többi fiókhoz.

Mielőtt a biztonsági fiókokhoz jogosultságokat rendelnénk, nézzük meg, mik is azok a szerepek.

A szerepek

A szerepek segítségével egységbe foghatjuk az azonos jogosultsági körrel felruházandó felhasználókat. A legfontosabb adminisztrációs feladatok elvégzéséhez rendelkezésre állnak előre definiált, beépített szerepek, de mi magunk is létrehozhatunk szerepeket. Ügyesen kialakítva az egyes szerepköröket a munkatársak cégen belüli - egyik munkakörből a másikba történő - mozgását könnyen követhetjük, hiszen csak az egyik szerepből a másikba kell mozgatni a fiókját és nem kell a hozzáférési jogait az adatbázis objektumainak a szintjén módosítani.

A beépített szerepek két csoportba oszthatók. Az első csoport a szerver adminisztrálásával foglalkozó szerepeket tartalmazza. A következő szerepek tartoznak ide:
  • sysadmin - Bármiféle műveletet elvégezhet.
  • dbcreator - Létrehozhat és módosíthat adatbázist.
  • diskadmin - A lemezen lévő állományokat kezelheti.
  • processadmin - Az SQL Server műveleteit kezelheti.
  • serveradmin - Felparaméterezheti és hangolhatja az SQL Servert.
  • setupadmin - Replikációkat telepíthet és konfigurálhat.
  • securityadmin - Fiókokat menedzselhet.
Ezek a szerepek server szintűek tehát az adatbázisoktól függetlenek, ezért a master adatbázis syslogins táblájában tárolódnak. A bejelentkezési fiókokhoz az sp_addsrvrolemember utasítással rendelhetünk szerepet:
sp_addsrvrolemember 'login', 'role'
Példa: a London\Andrew felhasználóhoz rendeljünk sysadmin szerepet:
EXEC sp_addsrvrolemember 'London\Andrew', 'sysadmin'
Az utasítás kiadásakor a syslogins tábla tartalma módosul, és jelezni fogja, hogy a felhasználói fiók most már tagja a szerepnek, és jogosult mindazokat a műveleteket elvégezni, amik ehhez a szerephez vannak rendelve. Ha egy fiók-szerep összerendelést meg szeretnénk szüntetni, a fiókot el kell távolítani a szerep 'tagságából' az sp_dropsrvrolemember utasítással:
EXEC sp_dropsrvrolemember 'London\Andrew', 'sysadmin'
A második csoportba tartozó beépített szerepek az adatbázis-szintű adminisztráció elvégzésére szolgálnak:
  • public - Alapértelmezett szerep.
  • db_owner - Az összes adatbázis szintű szerep tevékenységét végrehajthatja, konfigurálhatja és karbantarthatja az adatbázist.
  • db_accessadmin - Az adatbázishoz való hozzáférést szabályozhatja, vagyis fiókokat adhat az adatbázishoz és kitörölheti őket.
  • db_ddladmin - Létrehozhat, módosíthat és törölhet objektumokat az adatbázisban.
  • db_securityadmin - Szerepeket és hozzáféréseket állíthat be.
  • db_backupoperator - Lementheti az adatbázist.
  • db_datareader - Az összes felhasználó táblájából olvashat.
  • db_datawriter - Az összes felhasználó táblájába írhat, módosíthat és törölhet.
  • db_denydatareadre - Semmilyen adatot nem láthat.
  • db_denydatawriter - Semmilyen adatot nem módosíthat.
Ha egy adatbázisszintű szerephez szeretnénk fiókot rendelni, az sp_addrolemember utasítást kell használnunk. Példaként létrehozunk a NorthWind adatbázisban egy biztonsági fiókot a London tartomány Andrew felhasználójának, és ezt a fiókot a db_backupoperator szerep tagjává tesszük. Vagyis Andrew számára lehetővé tesszük az adatbázis mentésének végrehajtását.
USE NorthWind
GO
EXEC sp_grantdbaccess 'London\Andrew', 'Andrew'
GO
EXEC sp_addrolemember 'db_backupoperator', 'Andrew'

A hozzárendelést - vagy tagságot - az sp_droprolemember utasítás szünteti meg.

A public szerep

Az adatbázisok felhasználói automatikusan tagjai a public szerepnek. Ha egy felhasználóhoz nem rendelünk jogosultságokat, a public szerep jogosultságaival fog rendelkezni. Ez azt jelenti, hogy végrehajthat olyan utasításokat, amikhez nem szükséges külön jogosultsággal rendelkezni (ilyen pl. a PRINT), betekinthet bizonyos rendszerinformációkat tartalmazó táblába és futtathat bizonyos tárolt eljárásokat, hozzáfér minden guest felhasználói fiókkal rendelkező adatbázishoz.

Felhasználót nem tehetek a public szerep tagjává, hiszen alapértelmezés szerint mindenki tag. Ezt a szerepet minden adatbázis tartalmazza, még a rendszeradatbázisok is.

Új szerepet az sp_addrole utasítással készíthetünk.
sp_addrole 'role', 'owner'
Az új szerepet az SQL Server az adatbázis sysusers táblájában fogja tárolni. Ha jogosultságot rendelünk a szerephez, az olyan, mintha a jogosultságot a szerep minden egyes tagjához hozzárendeltük volna. Az utasítást csak a db_owner vagy a db_securityadmin szerepek tagjai adhatják ki. Az új szerephez az sp_addrolemember utasítással adhatunk tagokat. Az sp_addrolemember utasítást a szerep tulajdonosa is kiadhatja. Példaként készítsünk egy szerepet Managers néven, és adjunk hozzá egy tagot.
EXEC sp_addrole Managers, dbo
EXEC sp_addrolemember Managers, Alicia
Tagság megszüntetését az sp_droprolemember, szerep törlését az sp_droprole utasítások alkalmazásával tehetjük meg.

Jogosultságok

A fiókok és szerepek beállítása után az adatbázis biztonságának megteremtéséhez jogosultságokat kell azokhoz rendelnünk. A jogosultságok segítségével meghatározhatjuk, hogy a felhasználók mely adatbázis objektumhoz férhetnek hozzá és milyen műveleteket végezhetnek el rajtuk. A jogosultságoknak három típusa van: utasítás (statement), objektum (object) és beépített (implied) jogosultság.

Adatbázis, illetve adatbázis egy elemének létrehozása utasítás jogosultságot igényel. Például ha egy felhasználó szeretne létrehozni egy táblát az adott adatbázisban, a CREATE TABLE utasítás jogosultsággal kell rendelkeznie. Az SQL Serverben a következő utasítás jogosultságok vannak: CREATE DATABASE, CREATE PROCEDURE, CREATE TABLE, CREATE VIEW, CREATE RULE, CREATE DEFAULT, BACKUP DATABASE, BACKUP LOG. Utasításjogosultságot a sysadmin, a db_owner és a db_ securityadmin szerepek tagjai adhatnak.

Az adatokkal való műveletek elvégzése és a tárolt eljárások végrehajtása objektum jogosultságot igényel. Az objektum jogosultságok táblákhoz, nézetekhez és tárolt eljárásokhoz kötődnek, és a SELECT, INSERT, UPDATE, DELETE, illetve tárolt eljárás esetén az EXECUTE utasítás végrehajtását szabályozzák.

A beépített szerepek tagjai és a dbo által végezhető műveletek is jogosultsághoz kötöttek, ezek a beépített jogosultságok. Például a dbo rendelkezik az adatbázison végezhető mindenfajta művelet beépített jogosultsággal. Vagyis benne objektumokat hozhat létre és törölhet, jogosultságokat oszthat szét, felhasználói fiókokat hozhat létre, stb.
Biztonsági fiókhoz jogosultságot a GRANT utasítással rendelhetünk. A szintaktika utasítás jogosultság esetén a következő:
GRANT {ALL | statement[,...n]} TO security_account[,...n]
Példa 1.
GRANT CREATE DATABASE, CREATE TABLE TO Mary, John
Példa 2. A jogosultságot egy szerephez (Accounting) rendeljük.
GRANT CREATE TABLE TO Accounting
Az ALL kulcsszó azt jelenti, hogy az összes utasításra megadjuk a végrehajtás jogát. Az statement helyére a fentebb felsorolt 7 utasítás jogosultság írható be. A security account helyére írhatunk SQL Server felhasználót vagy szerepet, illetve Windows NT felhasználót vagy csoportot.

Az objektum jogosultság esetén a szintaxis egy kicsit bonyolultabb:
GRANT {ALL | permission[,...n]} 
        [(column[,...n])] 
        {
          ON {table | view} | 
          ON {stored_procedure |extended_procedure}
        }
        TO security_account [,...n]
Példa 1. Először megadjuk az authors táblára a SELECT jogot a public szerepnek, vagyis mindenkinek betekintést engedünk ebbe a táblába. Majd három felhasználónak engedélyezzük, hogy módosíthassák is a táblát.
GRANT SELECT
ON authors
TO public
GO 
GRANT INSERT, UPDATE, DELETE
ON authors
TO Mary, John, Tom
GO
Az ALL kulcsszó itt is az összes jogosultságot jelenti. Látszik, hogy a jogosultságot nemcsak táblára, hanem nézetre és tárolt eljárásra is vonatkoztathatjuk.

Az SQL Server lehetővé teszi, hogy a szerepeknek a felhasználókon kívül NT csoportok illetve más szerepek is tagjai legyenek. Így egy sokrétű, hierarchikus biztonsági rendszert építhetünk fel, ahol a jogosultságok alakulásába több különböző szinten is beavatkozhatunk.
Előfordulhat, hogy egy bizonyos felhasználó vagy egy bizonyos szerep jogosultságát szeretnénk letiltani. Erre a célra a DENY utasítást kell használnunk. Egy jogosultság letiltásakor,
  • eltávolítjuk a korábban adott jogosultságot;
  • érvénytelenítjük a más szerepektől örökölt jogosultságokat; és
  • biztosítjuk, hogy a felhasználó a jövőben se örökölhessen jogosultságot egy magasabb szintű szereptől.
Ahogy a GRANT utasítást, úgy a DENY utasítást is csak a sysadmin, a db_owner és a db_securityadmin szerepek tagjai használhatják.

A DENY utasítás szintaktikája is kétféle lehet attól függően, hogy utasítás jogosultságra vagy objektum jogosultságra vonatkozik.
1.
DENY{ALL | statement[,...n]}
TO security_account[,...n]

2.
DENY
    {ALL | permission[,...n]}
    {
        [(column[,...n])] ON {table | view}
        | ON {stored_procedure | extended_procedure}
    }
TO security_account[,...n]
Példa 1. A GRANT utasítás példájában adott jogokat most letiltjuk.
DENY CREATE DATABASE, CREATE TABLE TO Mary, John
DENY CREATE TABLE TO Accounting

Példa 2. Először a pubs adatbázis authors táblájára adunk SELECT jogot mindenkinek, vagyis a public szerepnek. Ezután néhány felhasználó esetén letiltjuk az összes jogosultságot.
USE pubs
GO

GRANT SELECT
ON authors
TO public
GO
 
DENY SELECT, INSERT, UPDATE, DELETE
ON authors
TO Mary, John, Tom
A jogosultság letiltásakor egy negatív bejegyzés jön létre a sysprotects táblában. Ez jelenti azt, hogy az adott feladat nem végrehajtható, és ezt más szerepek sem bírálhatják felül.

Egy megadott vagy letiltott jogosultságot a REVOKE utasítással helyezhetünk hatályon kívül. A jogosultság elvétele hasonlít a letiltáshoz, azzal a különbséggel, hogy az elvétellel nem akadályozunk meg egy esetleges későbbi öröklést. Például a dolgozók adatait tartalmazó Employees táblára SELECT jogosultságot adtunk ki a HumanResources szerepnek. Ez azt jelenti, hogy a szerep tagjai, vagyis a munkaügyes felhasználók mind hozzáférnek ehhez a táblához és a benne lévő adatokhoz. Később ezt a jogosultságot a REVOKE utasítással visszavonva a szerep tagjai a továbbiakban nem férnek hozzá a táblához. Ha a HumanResources szerep tagja az Administrators szerepnek és mi SELECT jogosultságot adunk az Employees táblán ennek a szerepnek, a HumanResources szerep tagjai látni fogják a táblát, mert ezt a jogosultságukat örökölni fogják az Administrators szereptől. Ha REVOKE helyett a DENY utasítást használtuk volna, most nem férnének hozzá a táblához.

A szintaxis most már ismerős lesz:

1.
REVOKE {ALL | statement[,...n]}
FROM security_account[,...n]
2.
REVOKE
    {ALL | permission[,...n]}
    {
        [(column[,...n])] ON {table | view}
        | {stored_procedure | extended_procedure}
    }
{TO | FROM} security_account[,...n]
Egy felhasználó jogosultsága vagy megadott (GRANT), vagy letiltott (DENY) vagy elvett (REVOKE) állapotban van. Ennek megfelelően a sysprotects táblában vagy pozitív bejegyzés van és ekkor az adott feladat végrehajtható, vagy negatív bejegyzés van és ekkor a feladat nem hajtható végre még jog-öröklés útján sem, vagy nincs bejegyzés és a feladat ekkor sem hajtható végre, de a végrehajthatóságot egy szerep felülbírálhatja.

Egy feladat végrehajthatóságát tehát a szerepeknek, csoportoknak és a felhasználónak adott jogosultságok összessége határozza meg. Legmagasabb precedenciája a letiltásnak (DENY) van. Egy jogosultságot bármelyik szinten letiltva az adott műveletet a felhasználó nem hajthatja végre. Például John tagja a sales szerepnek, aminek SELECT jogosultsága van a customer táblán. Ha most a sales szerep SELECT jogát letiltjuk (DENY), akkor John még akkor sem nézhet bele a customer táblába, ha saját magának erre egyébként joga van.

Példaprogram

A már megszokott Test1 aliast fogjuk használni, ami a pubs adatbázisra mutat. Azonban szükségünk van a master adatbázisra is a syslogins tábla miatt, így a futtatás előtt létre kell hoznunk egy Test2 nevű aliast, és kössük rá a master adatbázisra.

A példaprogramban az alapvető biztonsági beállítási lehetőségeket mutatjuk be egy konkrét szituáción keresztül.

Új munkatársnak kell hozzáférést biztosítanunk az SQL Serverhez. Egy Victoria nevű SQL Server bejelentkezési fiókot hozunk létre, majd engedélyezzük, hogy a pubs adatbázishoz is hozzáférjen. A jogosultságokat nem közvetlenül a felhasználói fióknak osztjuk ki, hanem csinálunk egy szerepet (Victoria_role), a fiókot a szerep tagjává tesszük és a jogosultságokat a szerephez rendeljük.

A program jobb oldalán látjuk a három legfontosabb rendszertáblát, a master adatbázis syslogins tábláját (ami valójában nem tábla, hanem egy nézet, view) és a pubs adatbázis sysusers és sysprotects tábláját.

A bal oldalon beléphetünk az SQL Serverbe valamilyen névvel, és a táblák böngészésével próbálgathatjuk, hogy mihez van jogunk és mihez nincs. A bal oldal gombsora mögött az egyes SQL utasítások be vannak drótozva.

Először lépjünk be adminisztrátorként (sa) az SQL Serverbe, és hozzuk létre az új fiókot az 'új SQL fiók' gomb megnyomásával. A jobb oldalon a syslogins táblában látjuk, hogy keletkezett egy új bejegyzés. A deny oszlop jelzi, hogy a fiók nincs letiltva, a group és user oszlopok jelzik, hogy nem egy NT csoportról vagy NT felhasználói fiókról van szó. Ha az 'SQL fiók törlése' gombra kattintunk, a bejegyzés megszűnik. Érdemes már most kilépni és Victoria névvel és food jelszóval ismét belépni az SQL Serverhez, hogy lássuk, mihez férünk hozzá. A felhasználó még nincs egyik adatbázishoz sem hozzáadva, mégis előfordulhat, hogy látjuk az egész pubs adatbázist. Ez azért lehet, mert az adatbázisban definiálva van a guest felhasználói fiók, ami lehetővé teszi az adatbázis megtekintését mindazoknak, akik nem rendelkeznek biztonsági fiókkal az adott adatbázisban.

Ha tovább szeretnénk lépni, ismét adminisztrátorként kell belépnünk. A 'DB hozzáférés' gomb megnyomásával a Victoria nevű felhasználónak belépést engedélyezünk a pubs adatbázisba. A sysusers táblában látjuk az új bejegyzést. Láthatjuk, a fiók kapott egy azonosítót (uid), ami az adatbázison belül egyedi, a suid mező értéke ugyanaz, mint a syslogins táblában, a többi mező neve beszédes. Az 'új szerep' gomb megnyomásával létrehozzuk a szerepet is. A szerepek is a sysusers táblában vannak. Ezután rendeljük a szerephez a felhasználót. Ezt a lépést explicit módon nem tudjuk követni a táblákban. A jogosultság kiosztását azonban annál inkább. A jogosultságok a sysprotects táblában vannak elhelyezve. Kattintsunk a két legalsó gombra, és keressük meg a sysprotects táblában azokat a sorokat, ahol az uid mező értéke megegyezik a szerepünk sysusers táblában lévő uid-jával. Láthatjuk a SELECT, INSERT, UPDATE és DELETE utasításokhoz kiosztott GRANT és REVOKE jogokat is. Hogy melyik objektumra vonatkozik, azt nem látjuk, csak az objektum azonosítóját. A titles táblához adtunk hozzáférést, a Victoria névvel bejelentkezve ki is próbálhatjuk.


MS SQL cikksorozat

MS SQL adatbázis kezelés Delphi-ből - 1. rész
MS SQL adatbázis kezelés Delphi-ből - 2. rész
MS SQL adatbázis kezelés Delphi-ből - 3. rész
MS SQL adatbázis kezelés Delphi-ből - 4. rész
MS SQL adatbázis kezelés Delphi-ből - 5. rész
MS SQL adatbázis kezelés Delphi-ből - 6. rész
MS SQL adatbázis kezelés Delphi-ből - 7. rész
MS SQL adatbázis kezelés Delphi-ből - 8. rész
MS SQL adatbázis kezelés Delphi-ből - 9. rész
MS SQL adatbázis kezelés Delphi-ből - 10. rész
MS SQL adatbázis kezelés Delphi-ből - 11. rész
MS SQL adatbázis kezelés Delphi-ből - 12. rész
MS SQL adatbázis kezelés Delphi-ből - 13. rész
MS SQL adatbázis kezelés Delphi-ből - 14. rész
MS SQL adatbázis kezelés Delphi-ből - 15. rész
MS SQL adatbázis kezelés Delphi-ből - 16. rész
MS SQL adatbázis kezelés Delphi-ből - 17. rész
MS SQL adatbázis kezelés Delphi-ből - 18. rész
MS SQL adatbázis kezelés Delphi-ből - 19. rész
MS SQL adatbázis kezelés Delphi-ből - 20. rész
MS SQL adatbázis kezelés Delphi-ből - 21. rész
MS SQL adatbázis kezelés Delphi-ből - 22. rész
MS SQL adatbázis kezelés Delphi-ből - 23. rész
MS SQL adatbázis kezelés Delphi-ből - 24. rész
MS SQL adatbázis kezelés Delphi-ből - 25. rész
MS SQL adatbázis kezelés Delphi-ből - 26. rész
MS SQL adatbázis kezelés Delphi-ből - MS SQL 27. rész
MS SQL adatbázis kezelés Delphi-ből - MS SQL 28. rész

MS SQL adatbázis kezelés Delphi-ből - MS SQL 29. rész

MS SQL adatbázis kezelés Delphi-ből - MS SQL 30. rész
MS SQL adatbázis kezelés Delphi-ből - MS SQL 31. rész
MS SQL adatbázis kezelés Delphi-ből - MS SQL 32. rész