Bezpečnost je nejdůležitější pro administrátory databází, kteří se snaží chránit své gigabajty důležitých obchodních údajů před zvědavými očima neoprávněných cizinců a zasvěcených osob, kteří se snaží překročit jejich autoritu. Všechny systémy pro správu relačních databází poskytují určitý druh vnitřních bezpečnostních mechanismů, jejichž cílem je minimalizovat tyto hrozby. Od jednoduché ochrany heslem nabízené aplikací Microsoft Access k komplexní struktuře uživatelů a rolí podporované vyspělými relačními databázemi, jako jsou Oracle a Microsoft SQL Server. Tento článek se zaměřuje na mechanismy zabezpečení, které jsou společné všem databázím, které implementují jazyk strukturovaných dotazů (nebo SQL ). Společně projdeme procesem posílení kontroly přístupu k datům a zajištění bezpečnosti vašich dat.
Uživatelé
Databázové servery založené na serveru podporují koncept uživatele podobný tomu, který se používá v operačních systémech počítače. Pokud jste obeznámeni s hierarchií uživatelů / skupin nalezenou v systémech Microsoft Windows NT a Windows 2000, zjistíte, že seskupení uživatelů a rolí podporovaná serverem SQL Server a Oracle jsou velmi podobné.
Doporučuje se, abyste vytvořili individuální uživatelské účty pro každou osobu, která bude mít přístup k vaší databázi. Technicky je možné sdílet účty mezi uživateli nebo jednoduše použít jeden uživatelský účet pro každý typ uživatele, který potřebuje k vaší databázi, ale tuto praxi silně odrazuji ze dvou důvodů. Za prvé, bude eliminovat individuální odpovědnost - pokud uživatel provede změnu v databázi (řekněme například tím, že se zvýšíte o 5 000 dolarů), nebudete ji moci pomocí konkrétních protokolů o auditu vysledovat zpět na konkrétní osobu. Dále, pokud určitý uživatel opustí vaši organizaci a chcete odebrat přístup z databáze, budete muset změnit heslo, na které se uživatelé spoléhají.
Metody vytváření uživatelských účtů se liší od platformy k platformě a budete muset nahlédnout do dokumentace specifické pro systém DBMS pro přesný postup. Uživatelé serveru Microsoft SQL Server by měli vyšetřovat použití uložené procedury sp_adduser. Administrátoři databází Oracle najdou užitečný příkaz CREATE USER. Můžete také chtít prověřit alternativní schémata autentizace. Například Microsoft SQL Server podporuje použití integrovaného zabezpečení Windows NT. V rámci tohoto schématu jsou uživatelé identifikováni do databáze jejich uživatelskými účty Windows NT a není nutné zadávat další uživatelské ID a heslo pro přístup k databázi. Tento přístup je mimořádně oblíbený u administrátorů databází, protože posunuje zátěž správy účtu na pracovníky správy sítě a umožňuje snadné přihlášení jediného uživatele ke koncovému uživateli.
Role
Pokud jste v prostředí s malým počtem uživatelů, pravděpodobně zjistíte, že vytváření uživatelských účtů a přidělování oprávnění přímo jim stačí pro vaše potřeby. Pokud však máte velké množství uživatelů, budete s největší pravděpodobností ohromeni zátěží o vedení účtů a řádných oprávnění. Pro usnadnění této zátěže podporují relační databáze pojem role. Databázové role fungují podobně jako skupiny WINDOWSNT. Uživatelské účty jsou přiřazeny k roli a oprávnění jsou pak přiřazena roli jako celku, nikoli individuálním uživatelským účtům. Například bychom mohli vytvořit roli DBA a poté přidat uživatelské účty našich administrativních pracovníků k této roli. Jakmile to uděláme, můžeme určitému oprávnění udělit všem současným (a budoucím) administrátorům jednoduchým přidělením oprávnění k roli. Opět platí, že postupy pro vytváření rolí se liší od platformy k platformě. Správci MS SQL Server by měli vyšetřovat uloženou proceduru sp_addrole, zatímco Oracle DBA by měli používat syntaxi CREATE ROLE.
Poskytování oprávnění
Nyní, když jsme přidali uživatele do naší databáze, je čas začít posilovat zabezpečení přidáním oprávnění. Naším prvním krokem bude poskytnutí vhodných oprávnění pro naše uživatele. Toho dosáhneme pomocí příkazu SQL GRANT.
Zde je syntaxe příkazu:
GRANT Nyní se podívejme na toto prohlášení line-by-line. První řádek, GRANT Druhý řádek ON Konečně je čtvrtý řádek s možností GRANTu volitelný. Je-li tento řádek zahrnut do příkazu, je dotčenému uživateli povoleno udělit stejné oprávnění i ostatním uživatelům. Všimněte si, že možnost GRANT OPTION nelze zadat při přiřazení oprávnění k roli. Podívejme se na několik příkladů. V našem prvním scénáři jsme nedávno najali skupinu 42 operátorů pro zadávání dat, kteří budou přidávat a uchovávat záznamy o zákaznících. Musí mít přístup k informacím v tabulce Zákazníci, upravovat tyto informace a přidávat nové záznamy do tabulky. Neměli by být schopni úplně odstranit záznam z databáze. Nejprve bychom měli vytvořit uživatelské účty pro každého operátora a pak je všechny přidat do nové role DataEntry. Dále bychom měli použít následující příkaz SQL, abychom jim poskytli příslušná oprávnění: GRANT SELECT, INSERT, UPDATE A to je vše! Nyní zkoumme případ, kdy přidělíme oprávnění na úrovni databáze. Chceme členům role DBA přidat do naší databáze nové tabulky. Navíc chceme, aby mohli ostatním uživatelům udělit povolení k tomu stejnému. Zde je příkaz SQL: TABULKA VYTVOŘENÍ GRANTU Všimněte si, že jsme zahrnovali řádek WITH GRANT OPTION, abychom zajistili, že naše DBA mohou tomuto oprávnění přiřadit ostatním uživatelům. Jakmile udělíme oprávnění, je často nutné je později zrušit. Naštěstí SQL nám poskytuje příkaz REVOKE k odebrání dříve udělených oprávnění. Zde je syntaxe: REVOKE [OPTION GRANT FOR] Všimnete si, že syntaxe tohoto příkazu je podobná syntaxi příkazu GRANT. Jediný rozdíl spočívá v tom, že příkaz GRANT OPTION je zadán na příkazovém řádku REVOKE namísto na konci příkazu. Jako příklad si představujeme, že chceme zrušit dříve udělené oprávnění Mary odebrat záznamy z databáze zákazníků. Použijeme následující příkaz: REVOKE DELETE A to je vše! Existuje jeden další mechanismus podporovaný Microsoft SQL Server, který stojí za zmínku - příkaz DENY. Tento příkaz lze explicitně zakázat uživateli povolení, které by jinak mohlo mít prostřednictvím stávajícího nebo budoucího členství v rolích. Zde je syntaxe: DENY Vrátit se k našemu předchozímu příkladu, představme si, že Mary byla také členem role manažerů, která měla také přístup ke stolu Zákazníci. Předchozí prohlášení REVOKE by nebylo dostačující k odmítnutí přístupu k tabulce. Odstraní oprávnění, která jí byla udělena prostřednictvím příkazu GRANT zaměřeného na její uživatelský účet, ale neovlivní oprávnění získaná členstvím v roli správce. Použijeme-li však příkaz DENY, blokuje jeho dědičnost. Zde je příkaz: DENY DELETE Příkaz DENY v podstatě vytváří "záporné oprávnění" v ovládacích prvcích přístupu k databázi. Pokud se později rozhodneme dát Marii povolení k odstranění řádků z tabulky Zákazníci, nemůžeme jednoduše použít příkaz GRANT. Tento příkaz by okamžitě přepsal stávající DENY. Místo toho nejprve použijeme příkaz REVOKE k odebrání položky záporného oprávnění následujícím způsobem: REVOKE DELETE Všimnete si, že tento příkaz je přesně stejný jako ten, který byl použit k odstranění pozitivního povolení. Nezapomeňte, že příkazy DENY a GRANT fungují podobně, a vytvářejí oprávnění (pozitivní nebo negativní) v mechanismu kontroly přístupu k databázi. Příkaz REVOKE odstraní všechna kladná a záporná oprávnění pro daného uživatele. Jakmile bude tento příkaz vydán, Mary bude moci odstranit řádky z tabulky, pokud je členem role, která má toto oprávnění. Případně by mohl být vydán příkaz GRANT, který poskytne povolení DELETE přímo na její účet. Během průběhu tohoto článku jste se naučili hodně o mechanismech kontroly přístupu podporovaných standardním jazykem dotazu. Tento úvod by měl poskytnout vám dobrý výchozí bod, ale doporučuji vám, abyste odkazovali na dokumentaci DBMS, abyste se dozvěděli, jak zvýšit bezpečnostní opatření podporovaná vaším systémem. Zjistíte, že mnoho databází podporuje pokročilejší mechanismy řízení přístupu, jako je například udělení oprávnění pro určité sloupce.
[ON ]
TO
[S možností GRANTu]
slouží k zadání ovlivněné tabulky pro oprávnění na úrovni tabulky. Tento řádek se vynechává, pokud udělujeme oprávnění na úrovni databáze. Třetí řádek určuje uživatele nebo roli, která byla udělena oprávnění.
Příklady
ON Zákazníci
Do DataEntry
DO DBA
S možností GRANTu Odstranění oprávnění
ON
FROM
ON Zákazníci
Z Mary
ON
TO Příklady
ON Zákazníci
K Mary
ON Zákazníci
Z Mary