Není žádným tajemstvím, že informace v současnosti hýbou světem. Pokud se podnik stará o své duševní vlastnictví a každý zaměstnanec může snadno získat potřebné informace, může podnik doufat v růst. Pokud je v datech chaos, podnik navzdory týmovému duchu selže.
V tomto článku prozkoumáme základy zabezpečení databáze a příklady ochrany informací v Oracle. Teoretické základy ochrany informací v databázi, o kterých se budeme v tomto článku zabývat, budou užitečné i pro lidi pracující s jinými databázemi.
Přístupová oprávnění
Ve většině společností, pro které jsem pracoval, měli všichni administrátoři a vývojáři plný přístup k databázím, stejně jako zaměstnanec IT oddělení byl bůh a mohl si dělat, co chtěl. proč se to děje? Jsou pro to dva důvody:
- Při práci v jednom oddělení se zaměstnanci mohou každý den na 8 hodin setkávat a stát se přáteli. Jak nemohou udělit přístup? Přátelství je jedna věc, ale obchod je obchod.
- Udělení některých přístupových práv nebo úprava některé konfigurace může vyžadovat určitá oprávnění. Někdy si správci myslí, že programátoři konfigurují nastavení lépe. Poskytují tak programátorům zbytečná přístupová práva. Místo toho se programátoři nesmějí podílet na správě a nesmějí k tomu mít žádná práva.
Podle mých zkušeností je druhý problém velmi častý, proto jej podrobně rozebereme.
Při vývoji programů pro databáze znají programátoři heslo superuživatele nebo prostě mají práva správce databáze. To je zbytečné a absolutně nejisté. Plná práva musí mít pouze správce databáze. Dokonce i vedoucí oddělení, ředitel a nejlepší přátelé mohou mít méně privilegií.
Například při vývoji programů stačí mít práva vlastníka schématu v databázi Oracle, která uchovává pracovní tabulky. Tato práva stačí k vytváření nových tabulek, balíčků, indexů a dalších objektů a také k udělení přístupových práv k objektům schématu dalším uživatelům. Pro práci na plný úvazek nepotřebujete systémová práva.
Pokud zde není správce databáze na plný úvazek, je to velmi špatné. Je lepší, když je někdo zodpovědný za výkon databáze, optimalizaci a zabezpečení. Musíte alespoň jmenovat jednoho programátora, který za to bude zodpovědný a bude mít výhradní práva.
Podle statistik způsobují ztrátu dat nejčastěji zaměstnanci společnosti. Navzdory této skutečnosti však většina společností toto vlákno nadále ignoruje a různé databáze uložené na discích s volným přístupem se prodávají i v metru.
Uživatelé a role
Existují dva typy objektů pro udělení přístupových práv k databázím:uživatelé a role. Role jsou některé skupiny, které kombinují uživatele, kteří musí mít podobná práva. Všichni účetní mohou například vyžadovat přístup k finančním dokumentům. Abychom vám zabránili udělovat práva každému účetnímu, můžeme je spojit do role s nezbytným přístupem.
Jak vidíte, princip rolí je podobný skupinám v operačním systému Windows. Přesto má určité rozdíly. Ne nadarmo lze v databázi implementovat všechny tři typy objektů, jako jsou uživatelé, skupiny a role. Ve většině databází jsou však implementováni pouze uživatelé a role. Všechny tyto objekty je nutné spravovat a monitorovat, aby každý uživatel získávající práva udělená rolemi měl přístup k datům, která jsou skutečně potřebná k řešení úkolů. Jako pravidla pro firewall je nutné použít přístupová práva. Pomocí těchto práv můžete vyřešit stejný problém – umožnit uživateli provádět pouze určité úkoly a zabránit možné ztrátě nebo poškození.
Pomocí rolí je celkem pohodlné řídit přístup, poskytovat oprávnění nebo blokovat celou skupinu uživatelů. Jedna role může být zahrnuta do druhé, a tak zdědit její přístupová práva. Proto můžeme vytvořit hierarchickou strukturu práv.
Všichni zaměstnanci s přístupovými právy do podnikové databáze mohou být zařazeni do jedné role s minimálními právy. Nyní, pokud potřebujete další oprávnění, přístup ke konkrétním tabulkám, budete muset přidat uživatele do jiných rolí (pokud skupina vyžaduje stejný přístup) nebo poskytnout konkrétnímu účtu práva.
V programu je pro řízení přístupu k tabulkám možné po každém pokusu o otevření datové sady zkontrolovat výsledek na chyby. Pokud dojde k chybě přístupu, přístup k zadané tabulce je uživateli zablokován. Není tedy potřeba implementovat přístupová práva do klientské aplikace. Pokud to však chcete implementovat, nebude to nic špatného. Alespoň v tom nevidím nic kritického; zdá se, že to má opačný účinek.
Audit zabezpečení
Pokud každý uživatel pracuje pod svým vlastním účtem ve vaší databázi, můžete zavolat proměnnou uživatele a určit aktuálního uživatele, například:
SELECT user from dual
Tento dotaz vrátí uživatelské jméno, pod kterým je navázáno spojení se serverem. Pokud se více lidí může přihlásit pod jedním jménem, tento dotaz vrátí stejné jméno pro oba a pro audit by byl k ničemu. Zejména, pokud k řízení uzamčení dochází na úrovni serveru.
Pokud se několik uživatelů může přihlásit pomocí stejného uživatelského jména, je složité, ale přesto možné, určit, kdo se k účtu přihlásil. Následující dotaz umožňuje získat podrobné informace o relaci:
select s.user#, s.username, s.osuser, s.terminal, s.program from sys.v_$session s WHERE username=user
Jak vidíte, dotaz vrátil uživatelské jméno připojené k databázi, jméno v operačním systému, uživatelské jméno terminálu a program.
Zde můžete přistupovat k zobrazení v_$session ze systémového schématu sys. Toto zobrazení vrací některé informace o připojeních k serveru. V klauzuli WHERE omezíme výstup pouze na aktuálního uživatele. Výsledkem je, že dotaz vrátí ID uživatele, jméno, jméno v operačním systému, terminál a program, ze kterého bylo spojení navázáno.
Když znáte uživatelské jméno a název terminálu, můžete uživatele s jistotou identifikovat. Chcete-li zjistit, do jakých rolí byl aktuální uživatel přidán, můžete spustit následující dotaz:
SELECT GRANTED_ROLE FROM dba_role_privs WHERE grantee=user
Zabezpečení účtu
Nebudeme říkat, že by neměla existovat výchozí hesla. Některé databáze, například MySQL, dělají špatně, když po instalaci vytvoří jednoduché a dobře známé systémové heslo. Nebudeme také říkat, že heslo by mělo být složité. Toto pravidlo platí pro všechny oblasti IT a mělo by být známé i začínajícímu uživateli. Budeme mluvit o problémech s databázemi.
Podle mých zkušeností používají vývojáři při vývoji firemních programů stejný účet pro přístup k databázi. Parametry tohoto účtu jsou evidovány přímo v programu, přičemž přístup k jednotlivým modulům včetně účetnictví, skladu, personálního oddělení atd. je realizován programově. Na jednu stranu je tento způsob pohodlný, protože se program může připojit k databázi s administrátorskými právy a nebude se muset starat o role a přístupová práva k tabulkám. Na druhou stranu tato metoda není ani zdaleka bezpečná. Úroveň uživatelů roste a přátelé zaměstnanců vaší společnosti se mohou vzdělávat v oblasti bezpečnosti a hackingu. Po znalosti jména a hesla, pod kterým se program připojuje k databázi, může běžný uživatel získat více příležitostí, než byste chtěli.
Jazyk SQL není tajný a komplikovaný jazyk. Existuje mnoho programů, pomocí kterých si můžete jednoduše prohlížet jakákoli data v databázi. Pomocí uživatelského jména a hesla může kdokoli ukrást všechna vaše data. Bude se tedy prodávat v každém stánku, který prodává disky.
Uživatelské jméno a heslo nesmí být nikdy uloženo v programu. Přístup k programu musí být rovněž omezen a znemožněn třetím stranám. Spojení obou přihlášení do jednoho je celkem logické. Na databázovém serveru je nutné vytvořit samostatný účet s minimálními nutnými právy pro každého uživatele v organizaci. Tato jména a hesla byste měli používat při přihlašování do programu. Můžete použít běžnou a velmi efektivní logiku – pokud se dokážete přihlásit do databáze se zadanými údaji, je přístup povolen; pokud ne, musíte program přerušit. Tento proces je jednoduchý a efektivní, protože jsme použili autorizaci databáze.
Chcete-li zkontrolovat, zda uživatelé nepracují současně ze dvou různých počítačů pod stejným názvem, můžete provést následující dotaz:
select s.username, s.terminal, count(*) from sys.v_$session s WHERE username=user HAVING count(*)>1 GROUP BY s.username, s.terminal
Ve skutečnosti nesmí vrátit žádný záznam.
Zobrazení
Pohledy jsou velmi pohodlným způsobem, jak vypnout datovou strukturu a zároveň vybudovat další úroveň ochrany. Je pravda, že pohledy mají negativní dopad na produktivitu, ale mají pozitivní dopad na bezpečnost. Můžeme jim udělit vlastní přístupová práva, zatímco tabulky, ze kterých jsou data načítána, mohou zůstat pro tento účet nepřístupné.
Kdy je lepší používat pohledy? Nejprve si definujme, jaké jsou jejich nevýhody. Pohled je příkaz SELECT pro načtení dat. Může přistupovat jak k jedné, tak k několika tabulkám. Pokud pouze vyberete data ze zobrazení, nedojde ke ztrátě výkonu. Můžeme však použít pohledy v jiných dotazech k výběru dat a odkazovat na ně jako na tabulky. Například:
SELECT list of fields FROM view, table_1, table_2 WHERE some parameters
V tomto případě dotaz načte data z pohledu a dvou tabulek. Kromě toho můžeme zobrazit vztah mezi všemi objekty a lze nastavit další podmínku.
Nyní se podívejme na dotaz tak, jak jej vidí optimalizátor databáze:
SELECT list of fields FROM (SELECT ...), table1, table2 WHERE some parameters
V tomto případě jsem pohled nahradil abstraktním příkazem SELECT v závorkách, ze kterého se pohled skládá. Ukázalo se, že server vidí dotaz s poddotazem. Pokud poddotaz vrací dynamická data, nikoli statickou hodnotu, bude tento výběr dat fungovat pomaleji, než kdybychom napsali stejný dotaz bez poddotazu.
Zabezpečení dat
Nikdy byste neměli udělit úplný přístup k objektům bez zvláštní potřeby. Vždy začnu poskytovat práva pouze k povolení výběru dat pomocí příkazu SELECT. Pokud uživatel skutečně potřebuje vložit nové záznamy a nemůže provést úkoly, které mu byly přiděleny, v tomto případě přidejte oprávnění k příkazu INSERT zadané tabulky.
Nejnebezpečnější operace pro data jsou úpravy a mazání, konkrétně UPDATE a DELETE. Tato práva musíte udělit opatrně. Ujistěte se, že data lze upravit nebo smazat. Pouze v tomto případě vyberte příslušná práva. Některé stoly jsou rozšířeny pouze přírodou.
Je nutné mít jistotu, že data budou často ovlivněna. Například tabulku zaměstnanců lze rozšířit a upravit, ale nikdy by neměl být smazán jediný záznam. Odstranění může ovlivnit pozadí práce zaměstnanců, výkaznictví a integritu dat. Případ, kdy personalista omylem přidá záznam navíc a chce jej smazat, je stále možný. Takové případy jsou však vzácné a chybu může opravit správce databáze. Chápeme, že se nikdo nechce přetěžovat a je jednodušší udělit povolení, nicméně bezpečnost je cennější.
Udělení práv se provádí pomocí operátora GRANT. Obecně to vypadá takto:
UDĚLEJTE, jaká práva udělit objektům ON uživatelům nebo rolím
Například následující dotaz uděluje právo vložit a zobrazit tabulku TestTable uživateli User1:
GRANT Select, Insert ON TestTable TO User1
Zahraniční klíče
Mnoho uživatelů se cizích klíčů bojí, protože obvykle neumožňují smazání dat, když dojde k vnějšímu spojení. Problém lze snadno vyřešit, pokud je vytvořeno smazání kaskády. Většině specialistů se však tato možnost nelíbí. Jedna směšná akce může poškodit velmi důležitá data bez jakýchkoli žádostí o potvrzení. Propojená data musí být smazána výslovně a pouze v případě, že uživatel vědomě potvrdil, že data lze smazat.
Nebojte se cizích klíčů. Poskytují nám pohodlný způsob, jak kontrolovat integritu dat z databázového serveru, takže toto je zabezpečení, které nikdy neuškodí. Skutečnost, že mohou být problémy s mazáním, je pouze výhodou. Je lepší data nesmazat, než o ně navždy přijít. Cizí klíč spolu s indexem nesnižuje výkon. Toto je jen malá kontrola při mazání dat nebo úpravě klíčového pole, ke kterému jsou data připojena v různých tabulkách.
Záloha
Zálohování je také jedním z bezpečnostních faktorů, které před první ztrátou dat ignorujeme. Osobně bych to však zařadil mezi ty hlavní. Ztrátu dat mohou způsobit nejen hackeři a nešikovní uživatelé, ale také selhání zařízení. Poruchy v zařízení mohou vést ke ztrátě databáze, jejíž obnova může trvat hodiny nebo dokonce dny.
Je nutné předem vyvinout nejúčinnější politiku zálohování. co se tím myslí? Prostoje způsobené ztrátou dat a do okamžiku obnovení pracovní kapacity by měly být minimální. Ztráta dat by měla být také minimální a záloha by neměla mít vliv na práci uživatele. Pokud jsou peníze a příležitosti, je lepší používat systémy jako RAID, cluster nebo dokonce replikaci dat.
Zálohování a obnova jsou samostatné a zajímavé téma. Nemohli jsme se toho zde dotknout, ale nebudeme se tím podrobně zabývat.
Shrnutí
Zvažovali jsme základy zabezpečení, zejména pro Oracle. Nezapomeňte, že ochrana poskytovaná databází je pouze jednoúrovňová, zatímco ochrana musí být víceúrovňová. Abychom se trochu vyspali s čistou myslí, je nutné implementovat veškeré bezpečnostní prvky na síti, serverech a všech počítačích, včetně antivirů, antispywaru, VPN, IDS atd. Čím více úrovní ochrany je, tím více bude těžké je překonat.
Měla by existovat jasná bezpečnostní politika a kontrola. Pokud zaměstnanec odejde, jeho účet je smazán. Pokud máte uživatele, kteří pracují se stejným heslem nebo používají skupinové heslo k provádění jakýchkoli úkolů, musí být všechna tato hesla změněna. Pokud například odejde správce a všichni správci používají stejný účet, musíte změnit heslo.
Zabezpečení je nutné. Musíte se chránit nejen před hackery, ale také před „začátečníky“ uživateli, kteří mohou svou nezkušeností poškodit data. Dobrá bezpečnostní politika pomáhá takovým případům předcházet a tuto možnost nelze vyloučit. Je lepší poskytnout možnost zabezpečit data před nezkušeností předem, než ztrácet spoustu času obnovou dat a získat zbytečné prostoje.
Přečtěte si také:
Nastavení přístupových oprávnění k databázi