Kontroly prístupu pre používateľov a roly v SQL

Bezpečnosť je najdôležitejšia pre administrátorov databázy, ktorí sa snažia chrániť ich gigabajty dôležitých obchodných údajov z očarujúcich očí neoprávnených nečlenov a zasvätencov, ktorí sa pokúšajú prekročiť ich autoritu. Všetky systémy na riadenie relačných databáz poskytujú nejaké vnútorné bezpečnostné mechanizmy navrhnuté na minimalizáciu týchto hrozieb. Od najjednoduchšej ochrany heslom, ktorú ponúka Microsoft Access, až po komplexnú štruktúru používateľov a úloh podporovanú rozšírenými relačnými databázami, ako sú Oracle a Microsoft SQL Server. Tento článok sa zameriava na bezpečnostné mechanizmy spoločné pre všetky databázy, ktoré implementujú štruktúrovaný dotazovací jazyk (alebo SQL ). Spoločne budeme prechádzať procesom posilňovania kontrol prístupu k údajom a zabezpečením bezpečnosti vašich údajov.

užívatelia

Serverové databázy podporujú koncept používateľa podobný tomu, ktorý sa používa v počítačových operačných systémoch. Ak ste oboznámení s hierarchiou používateľov / skupín nachádzajúcou sa v systémoch Microsoft Windows NT a Windows 2000, zistíte, že skupiny používateľov / rolí podporované servermi SQL Server a Oracle sú veľmi podobné.

Veľmi sa odporúča vytvoriť individuálne používateľské účty databázy pre každú osobu, ktorá bude mať prístup k vašej databáze. Je technicky možné zdieľať účty medzi používateľmi alebo jednoducho používať jeden používateľský účet pre každý typ používateľa, ktorý potrebuje prístup k vašej databáze, ale silne odraďujem túto prax z dvoch dôvodov. Po prvé, odstráni individuálnu zodpovednosť - ak používateľ vykoná zmenu vašej databázy (povedzme tým, že si sám dá 5.000 dolárov zvýšenie), nebudete ju môcť spätne sledovať na konkrétnu osobu pomocou audítorských protokolov. Okrem toho, ak konkrétny používateľ opustí vašu organizáciu a chcete odstrániť svoj prístup z databázy, budete nútení zmeniť heslo, na ktoré sa všetci používatelia spoliehajú.

Metódy vytvárania používateľských účtov sa líšia v závislosti od platformy na platformu a budete musieť skontrolovať konkrétnu dokumentáciu k DBMS. Používatelia Microsoft SQL Server by mali skúmať použitie uloženej procedúry sp_adduser. Administrátori databázy Oracle nájdu príkaz CREATE USER užitočný. Možno budete tiež chcieť preskúmať alternatívne schémy autentifikácie. Napríklad Microsoft SQL Server podporuje použitie integrovaného zabezpečenia Windows NT. V rámci tejto schémy sú užívatelia identifikovaní do databázy svojimi užívateľskými účtami Windows NT a nie je potrebné zadávať ďalšie ID užívateľa a heslo na prístup k databáze. Tento prístup je mimoriadne obľúbený medzi správcami databázy, pretože presúva zaťaženie správy účtov na pracovníkov sieťovej správy a poskytuje jednoduché prihlásenie koncovým používateľom.

role

Ak ste v prostredí s malým počtom používateľov, pravdepodobne zistíte, že vytváranie používateľských účtov a prideľovanie povolení priamo pre nich je dostatočné pre vaše potreby. Avšak, ak máte veľký počet používateľov, budete s najväčšou pravdepodobnosťou zahltení bremenom vedenia účtov a správnych povolení. Na zmiernenie tejto záťaže podporujú relačné databázy pojem rolí. Databázové role fungujú podobne ako skupiny Windows NT. Používateľské kontá sú priradené k úlohe (rolám) a oprávnenia sú potom pridelené úlohe ako celku, a nie ako jednotlivé používateľské účty. Mohli by sme napríklad vytvoriť úlohu DBA a potom pridať používateľské účty našich administratívnych pracovníkov k tejto úlohe. Akonáhle to urobíme, môžeme prideliť špecifické povolenie všetkým súčasným (a budúcim) administrátorom tým, že jednoducho pridelíme povolenie tejto úlohe. Postupy pre vytváranie rolí sa znova líšia z platformy na platformu. Správcovia systému MS SQL Server by mali vyšetrovať uloženú procedúru sp_addrole, zatiaľ čo Oracle DBA by mali používať syntax CREATE ROLE.

Udeľovanie povolení

Teraz, keď sme pridali používateľov do našej databázy, je čas začať posilňovať bezpečnosť pridaním povolení. Prvým krokom bude poskytnutie vhodných oprávnení pre našich používateľov. Vykonáme to pomocou príkazu SQL GRANT.

Tu je syntax vyhlásenia:

GRANT
[ON

]
TO
[S možnosťou GRANTu]

Teraz sa pozrime na toto vyhlásenie line-by-line. Prvý riadok, GRANT , nám umožňuje špecifikovať špecifické povolenia tabuľky, ktoré udeľujeme. Môžu to byť buď oprávnenia na úrovni tabuľky (napr. SELECT, INSERT, UPDATE a DELETE), alebo oprávnenia databázy (napríklad CREATE TABLE, ALTER DATABASE a GRANT). V jednom výkaze GRANT sa môže udeliť viac ako jedno povolenie, ale povolenia na úrovni tabuľky a oprávnenia na úrovni databázy sa nemusia kombinovať v jednom výkaze.

Druhý riadok, ON

, slúži na zadanie príslušnej tabuľky pre oprávnenia na úrovni tabuľky. Tento riadok sa vynecháva, ak udeľujeme povolenia na úrovni databázy. Tretí riadok určuje používateľa alebo úlohu, ktorému boli udelené povolenia.

Nakoniec je štvrtý riadok s možnosťou GRANTu voliteľný. Ak je tento riadok zahrnutý do príkazu, dotknutý používateľ je tiež oprávnený udeliť rovnaké oprávnenia iným používateľom. Upozorňujeme, že možnosť GRANT OPTION nie je možné špecifikovať, keď sú práva priradené k rolke.

Príklady

Pozrime sa na niekoľko príkladov. V našom prvom scenári sme nedávno najali skupinu 42 operátorov na zadávanie údajov, ktorí budú pridávať a uchovávať záznamy o zákazníkoch. Musia mať prístup k informáciám v tabuľke Zákazníci, upravovať tieto informácie a pridávať do tabuľky nové záznamy. Nemali by byť schopné úplne vymazať záznam z databázy. Najprv by sme mali vytvoriť používateľské účty pre každého operátora a potom ich pridať do novej úlohy DataEntry. Ďalej by sme mali použiť nasledujúci príkaz SQL na udelenie príslušných povolení:

GRANT SELECT, INSERT, UPDATE
ON Zákazníci
Do DataEntry

A to je všetko, čo je k tomu! Teraz skúmme prípad, v ktorom priraďujeme povolenia na úrovni databázy. Chceme umožniť členom úlohy DBA pridať do našej databázy nové tabuľky. Okrem toho chceme, aby boli schopní udeliť iným používateľom povolenie na to, aby urobili to isté. Tu je príkaz SQL:

GRANT CREATE TABLE
DO DBA
S možnosťou GRANTu

Všimnite si, že sme zaradili riadok s možnosťou GRANT OPTION, aby sme zabezpečili, že naše DBA môžu prideliť toto povolenie ostatným používateľom.

Odstránenie oprávnení

Po udelení povolení sa často ukáže, že je potrebné ich neskôr zrušiť. SQL nám našťastie poskytuje príkaz REVOKE na odstránenie predtým pridelených povolení. Tu je syntax:

REVOKE [GRANT OPTION FOR]
ON


FROM

Všimnete si, že syntax tohto príkazu je podobný ako v príkaze GRANT. Jediný rozdiel je v tom, že GRANT OPTION je zadaný na príkazovom riadku REVOKE a nie na konci príkazu. Predstavme si napríklad, že chceme zrušiť predtým udelené povolenie spoločnosti Mary na odstránenie záznamov z databázy Zákazníci. Použili by sme nasledujúci príkaz:

ZRUŠIŤ DELETE
ON Zákazníci
Z Mary

A to je všetko, čo je k tomu! Existuje jeden ďalší mechanizmus podporovaný Microsoft SQL Serverom, ktorý stojí za zmienku - príkaz DENY. Tento príkaz môže byť použitý na výslovné zamietnutie povolenia pre používateľa, ktoré by inak mohli mať prostredníctvom súčasného alebo budúceho členstva v úlohe. Tu je syntax:

DENY
ON


TO

Príklady

Keď sa vrátime k nášmu predchádzajúcemu príkladu, predstavme si, že Mary bola tiež členom úlohy manažérov, ktorá mala prístup aj do tabuľky Zákazníci. Predchádzajúce vyhlásenie REVOKE by nestačilo na to, aby odmietol prístup k tabuľke. Odstránilo povolenie, ktoré jej bolo udelené prostredníctvom príkazu GRANT zameraného na jej používateľský účet, ale neovplyvnilo práva získané prostredníctvom jej členstva v úlohe manažéra. Ak však použijeme vyhlásenie DENY, zablokuje jej dedenie povolenia. Tu je príkaz:

DENY DELETE
ON Zákazníci
K Márii

Príkaz DENY v podstate vytvára "negatívne povolenie" v ovládacích prvkoch prístupu k databáze. Ak sa neskôr rozhodneme dať Márii povolenie na odstránenie riadkov z tabuľky Zákazníci, nemôžeme jednoducho použiť príkaz GRANT. Tento príkaz by okamžite prekonal existujúci DENY. Namiesto toho by sme najprv použili príkaz REVOKE na odstránenie záporného povolenia:

ZRUŠIŤ DELETE
ON Zákazníci
Z Mary

Všimnete si, že tento príkaz je presne ten istý ako ten, ktorý bol použitý na odstránenie pozitívneho povolenia. Nezabúdajte, že príkazy DENY a GRANT pracujú podobne a vytvárajú oprávnenia (pozitívne alebo negatívne) v mechanizme kontroly prístupu k databáze. Príkaz REVOKE odstráni všetky kladné a negatívne oprávnenia pre zadaného používateľa. Keď bude tento príkaz vydaný, Mary bude môcť odstrániť riadky z tabuľky, ak je členom roly, ktorá má toto povolenie. Prípadne by mohol byť vydaný príkaz GRANT, ktorý poskytne povolenie DELETE priamo na jej účet.

V priebehu tohto článku ste sa naučili veľa o mechanizmoch kontroly prístupu podporovaných jazykom štandardného dotazu. Tento úvod by mal poskytnúť dobrý východiskový bod, ale odporúčam vám, aby ste sa na dokumentáciu DBMS dozvedeli, ako sa dozviete rozšírené bezpečnostné opatrenia podporované vaším systémom. Zistíte, že mnohé databázy podporujú zdokonalené mechanizmy kontroly prístupu, ako napríklad udeľovanie povolení pre konkrétne stĺpce.