Ochrana informací v databázích. Ochrana informací v subd

Můžeme jmenovat následující hlavní oblasti boje proti potenciálním hrozbám pro důvěrnost a integritu dat:

Identifikace a autentizace uživatelů;

Řízení přístupu k datům (vlastník objektu k němu převádí přístupová práva dle vlastního uvážení);

Mechanismus odpovědnosti za všechny činnosti ovlivňující bezpečnost;

Ochrana registračních informací před zkreslením a jejich analýza;

Čištění předmětů před jejich opětovným použitím;

Ochrana informací přenášených po komunikačních linkách.

Všechna tato univerzální doporučení platí i pro DBMS. Specifičnost DBMS navíc umožňuje potenciálně nové hrozby, a proto vyžaduje zvláštní ochranná opatření (např. reprezentace- kontroly přístupu v DBMS, které umožňují zviditelnit určité sloupce základních tabulek subjektům nebo vybrat určité řádky).

DBMS mají přísnou vnitřní strukturu a operace s jejich prvky jsou definovány poměrně jasně. Tyto operace zpravidla zahrnují čtyři hlavní akce - vyhledání, vložení, smazání a nahrazení prvku, zatímco ostatní mají pomocný charakter a používají se poměrně zřídka. Přítomnost přísné struktury a dobře definovaných operací zjednodušuje úkol ochrany DBMS. Ve většině případů se útočníci nehodlají věnovat DBMS a raději hackli ochranu sítě na úrovni OS a získali přístup k souborům DBMS pomocí nástrojů OS. Ale v případech, kdy je použit DBMS s nedostatečně silnými ochrannými mechanismy, nebo špatně otestovaná verze DBMS, nebo se správce DBMS dopustil chyby při definování bezpečnostní politiky, může útočník snadno překonat ochranu implementovanou na úrovni DBMS.

Existují dva konkrétní scénáře útoku DBMS:

1) v prvním případě výsledky aritmetické operace přes číselná pole DBMS jsou zaokrouhlena dolů a rozdíl je shrnut v nějakém jiném záznamu DBMS (zpravidla se jedná o peněžní částku, která je uložena na osobní účet hacker v bance a zaokrouhlená číselná pole odkazují na účty jiných zákazníků banky);

2) ve druhém případě získá útočník přístup k polím záznamů DBMS obsahujících pouze nashromážděné statistické informace. Úkolem crackera je formulovat dotaz tak, aby množinu záznamů, pro které se statistiky shromažďují, tvořil pouze jeden záznam.

Hlavní zdroj hrozeb specifických pro DBMS spočívá v samotné povaze databází, které uchovávají informace. Hlavním prostředkem interakce s DBMS je jazyk SQL je výkonný neprocedurální nástroj pro definování a manipulaci s daty. Uložené procedury k němu přidávají řídicí konstrukce. Mechanismus pravidel umožňuje budovat složité, obtížně analyzovatelné řetězce akcí a zároveň umožňuje implicitně převádět právo provádět procedury, a to i bez, přísně vzato, oprávnění k tomu. Výsledkem je, že potenciální útočník dostane do rukou výkonnou a pohodlnou sadu nástrojů a veškerý vývoj DBMS je zaměřen na to, aby byla tato sada nástrojů ještě výkonnější a pohodlnější.

Získávání informací logickými závěry.Často, odvozením, můžete extrahovat informace z databáze, pro které standardní prostředky Uživatel nemá dostatečná oprávnění.

Pokud se k implementaci řízení přístupu používají pohledy a tyto pohledy umožňují úpravy, lze k získání informací o obsahu základních tabulek použít operace modifikace/vložení, aniž byste k nim měli přímý přístup.

Hlavním prostředkem boje proti takovým hrozbám je kromě pečlivého návrhu datového modelu mechanismus šíření řetězců. Jeho podstata spočívá v tom, že primární klíč explicitně nebo implicitně obsahuje bezpečnostní štítek ( bezpečnostní štítek je úroveň zabezpečení dat, která určuje, kteří uživatelé nebo procesy mají povolen přístup k datům), což umožňuje ukládat více instancí řádků v tabulce s stejné hodnoty„smysluplná“ klíčová pole. Násobení řádků je nejpřirozeněji implementováno v DBMS, které podporují štítky, nicméně uspokojivé řešení lze získat i pomocí standardních nástrojů SQL.

Agregace dat. Agregace je metoda získávání nových informací kombinací dat získaných legálně z různých tabulek. Agregované informace se mohou ukázat jako tajnější než každá ze složek, které je tvoří. Informace o jednotlivých dílech nejsou samy o sobě tajné (jaký smysl má skrývat materiál, rozměry a počet matic?). Rozbor celé databáze zároveň umožňuje zjistit, jak vyrobit raketu, kterou lze považovat za státní tajemství.

Zvyšování míry utajení dat při agregaci je zcela přirozené – je to důsledek zákona přechodu kvantity v kvalitu. S agregací můžete bojovat pečlivým navržením datového modelu a maximálním omezením přístupu uživatelů k informacím.

Útoky na vysokou dostupnost (availability). Pokud má uživatel přístup ke všem schopnosti SQL, může docela snadno překážet v práci ostatním uživatelům tím, že iniciuje například dlouhou transakci, která zahrnuje velké množství tabulek. Moderní vícevláknové servery DBMS odrážejí pouze ty nejpřímější útoky, které spočívají například ve spuštění operace hromadného načítání dat ve špičce. Proto se nedoporučuje poskytovat uživatelům přímý SQL přístup k databázi pomocí aplikačních serverů jako filtrů. Volba takové architektury je rozumná z mnoha dalších důvodů.

Jako hrozba specifická pro relační DBMS, zmiňujeme referenční omezení. Přísně vzato, uložení takového omezení zabrání odstranění řádků z tabulky obsahující primární klíče, ačkoliv v moderní verze SQL se může dotazovat na to, co je známé jako kaskádové odstranění.

Pro podporu zabezpečení databází se vyvíjí mnoho produktů. Mezi nimi jsou produkty DBSecure a BrainTree Security Software. SQL Auditor DBSecure vyhodnocuje rizika v databázi Data společnosti Microsoft SQL Server detekuje slabá hesla, narušení zneužití, útoky při spouštění a další formy neoprávněného přístupu. S balíčkem SQL Secure od BrainTree je správa zabezpečení soustředěna do jediné konzole. Komponenta Password Manager analyzuje slabá místa hesel, spravuje proces přidělování hesel a data vypršení jejich platnosti. Komponenta Policy Manager pomáhá uživatelům vyhodnotit jejich databáze podle bezpečnostních standardů.

Odeslat svou dobrou práci do znalostní báze je jednoduché. Použijte níže uvedený formulář

Studenti, postgraduální studenti, mladí vědci, kteří využívají znalostní základnu ve svém studiu a práci, vám budou velmi vděční.

Hostováno na http://www.allbest.ru/

Úvod

Moderní život je nemyslitelný bez efektivního řízení. Důležitou kategorií jsou systémy zpracování informací, na kterých do značné míry závisí výkonnost každého podniku nebo instituce. Takový systém by měl:

zajistit příjem obecných a/nebo podrobných zpráv o výsledcích práce;

usnadnit určování trendů v nejdůležitějších ukazatelích;

zajistit příjem časově kritických informací bez významných prodlev;

provádět přesné a kompletní analýza data.

Moderní DBMS jsou většinou Windows aplikace, protože dané prostředí vám umožní plně využít možnosti osobní počítač než prostředí DOS. Pokles nákladů na vysoce výkonné počítače vedl nejen k rozsáhlému přechodu na Prostředí Windows kde se vývojář softwaru může méně starat o alokaci zdrojů, ale také to dělal software PC obecně a DBMS zvláště jsou méně důležité pro hardwarové zdroje počítače. Mezi nejvíce prominentní představitelé systémy pro správu databází lze zaznamenat: Lotus Approach, Microsoft Access, Borland dBase, Borland Paradox, Microsoft Visual FoxPro, Microsoft Visual Basic, stejně jako databáze Microsoft SQL Server a Oracle používané v aplikacích vytvořených pomocí technologie klient-server.

Problém zajištění bezpečnosti informací je jedním z nejdůležitějších při budování spolehlivého informační struktura počítačové instituce. Tato problematika se týká jak fyzické ochrany dat, tak systémové programy a ochrana před neoprávněným přístupem k datům přenášeným po komunikačních linkách a umístěných na úložných zařízeních, což je výsledkem obojího outsidery a speciální virové programy. Pojem ochrana dat tedy zahrnuje otázky zachování integrity dat a řízení přístupu k datům (autorizace).

Technologický aspekt Tento problém Spojen s různé typy omezení, která jsou podporována strukturou DBMS a musí být uživateli k dispozici. Tyto zahrnují:

Omezení aktualizace určitých atributů za účelem zachování požadovaných proporcí mezi jejich starými a novými hodnotami;

Omezení, která vyžadují, aby hodnoty pole indikátoru byly uloženy v určitém rozsahu;

Omezení spojená s danými funkčními závislostmi.

Obvykle v DBMS je jazyk pro manipulaci s daty již stanoven potřebné komponenty provádění těchto omezení. Problematika zajištění oprávnění k využívání dat je nejednoznačná, ale týká se především problematiky ochrany dat před nežádoucí úpravou či zničením a také před neoprávněným čtením.

V této práci se dotýkám hlavních aspektů ochrany databází, jejich implementace na příkladech konkrétních DBMS a také právní stránky této problematiky.

Ochrana dat. Pojem informační bezpečnosti

informace o ochraně neautorizovaný přístup

Informační bezpečnost je soubor opatření zaměřených na zajištění nejdůležitějších aspektů informační bezpečnost(integrita, dostupnost a v případě potřeby důvěrnost informací a zdrojů používaných pro zadávání, ukládání, zpracování a přenos dat) .

O systému se říká, že je bezpečný, pokud pomocí vhodného hardwaru a softwaru řídí přístup k informacím tak, že pouze řádně oprávněné osoby nebo procesy jednající jejich jménem mohou číst, zapisovat, vytvářet a mazat informace.

Je zřejmé, že absolutně bezpečné systémy ne a tady se bavíme o spolehlivém systému ve smyslu „systém, kterému lze věřit“ (jako člověku věřit můžete). Systém je považován za spolehlivý, pokud využívá dostatečný hardware a softwarových nástrojů zajišťuje souběžné zpracování informací různého stupně utajení skupinou uživatelů bez porušení přístupových práv.

Hlavní kritéria pro hodnocení spolehlivosti jsou: bezpečnostní politika a záruka.

Bezpečnostní politika, která je aktivní součástí ochrany (včetně analýzy možné hrozby a volba vhodných protiopatření) odráží soubor zákonů, pravidel a norem chování, které konkrétní organizace používá při zpracování, ochraně a šíření informací.

Volba konkrétních mechanismů pro zajištění bezpečnosti systému se provádí v souladu s formulovanou bezpečnostní politikou.

Zajištění jako pasivní prvek ochrany odráží míru důvěry, kterou lze vložit do architektury a implementace systému (jinými slovy, ukazuje, jak správně jsou zvoleny mechanismy zajišťující bezpečnost systému).

Spolehlivý systém by měl zaznamenávat všechny nastalé bezpečnostní události (měl by existovat mechanismus odpovědnosti za protokolování doplněný o analýzu uložených informací, tedy auditování).

Při hodnocení míry jistoty, se kterou lze systém považovat za spolehlivý, zaujímá centrální místo spolehlivá (spolehlivá) výpočetní základna. Trusted Computing Base (TBE) je kompletní sada obranných mechanismů počítačový systém, který se používá k vynucení odpovídající bezpečnostní politiky.

Spolehlivost DVB závisí pouze na jeho implementaci a správnosti zadaných údajů (např. údaje o důvěryhodnosti uživatelů určené administrací).

Hranice DVB tvoří bezpečnostní perimetr. Komponenty DVB, které jsou uvnitř této hranice, musí být spolehlivé (pro posouzení spolehlivosti počítačového systému tedy stačí vzít v úvahu pouze jeho DVB). Komponenty mimo bezpečnostní perimetr obecně nemusí být spolehlivé. To by však nemělo ovlivnit bezpečnost systému. Vzhledem k tomu, že je nyní široce používán distribuované systémy zpracování dat, pak „bezpečnostní perimetr“ označuje hranici majetku určité organizace, která je tomuto systému podřízena. Analogicky se pak to, co je uvnitř této hranice, považuje za spolehlivé. Prostřednictvím systému brány, který je schopen odolat potenciálně nespolehlivému a možná i nepřátelskému prostředí, probíhá komunikace přes tuto hranici.

Kontrola přípustnosti plnění ze strany subjektů určitých operací na objektech, tedy funkce sledování, je prováděna spolehlivě. výpočetní základna. Pokaždé, když uživatel přistupuje k programům nebo datům, monitor kontroluje přípustnost tohoto přístupu (konzistenci akcí konkrétního uživatele se seznamem akcí pro něj povolených). Implementace call monitoru se nazývá bezpečnostní jádro, na jehož základě jsou vybudovány všechny ochranné mechanismy systému. Bezpečnostní jádro musí zaručit svou vlastní neměnnost.

Ochrana vašeho PC před neoprávněným přístupem

Jak ukazuje praxe, neautorizovaný přístup (UAS) je jednou z nejvážnějších hrozeb pro škodlivé získávání chráněných informací v moderním ASOD. I když se to může zdát zvláštní, ale pro PC se nebezpečí této hrozby ve srovnání s velkými počítači zvyšuje, což je usnadněno následujícími objektivně existujícími okolnostmi:

1) naprostá většina PC je umístěna přímo v pracovnách specialistů, což vytváří příznivé podmínky pro přístup k nim neoprávněným osobám;

2) mnoho PC slouží jako kolektivní prostředek pro zpracování informací, což depersonalizuje odpovědnost, včetně odpovědnosti za ochranu informací;

3) moderní PC jsou vybaveny pevnými HDD disky velmi velká kapacita a informace na nich jsou uloženy i v beznapěťovém stavu;

4) pohony na GMD jsou vyráběny v takovém masovém množství, že se již používají pro šíření informací stejně jako papírová média;

5) Zpočátku byly PC vytvořeny speciálně jako osobní prostředek pro automatizaci zpracování informací, a proto nebyly speciálně vybaveny prostředky ochrany proti neoprávněnému přístupu.

S ohledem na výše uvedené by uživatelé, kteří si přejí zachovat důvěrnost svých informací, měli věnovat zvláštní pozornost tomu, aby počítač, který používají, vybavili vysoce účinnými prostředky ochrany proti neoprávněnému přístupu.

Hlavní mechanismy ochrany počítače před neoprávněným přístupem mohou být reprezentovány následujícím seznamem:

1) fyzická ochrana PC a paměťových médií;

2) identifikace (autentizace) uživatelů a použitých komponent pro zpracování informací;

3) diferenciace přístupu k prvkům chráněných informací;

4) kryptografické uzavření chráněných informací uložených na médiu (archivace dat);

5) kryptografické uzavření chráněných informací v procesu jejich přímého zpracování;

6) registrace všech odkazů na chráněné informace. Obecný obsah a způsoby použití těchto mechanismů jsou uvedeny níže.

Ochrana dat v databázích

Moderní DBMS podporují jeden ze dvou nejběžnějších přístupů k problematice zabezpečení dat: selektivní přístup a povinný přístup. V obou přístupech může být jednotkou dat nebo "datovým objektem", pro který má být vytvořen bezpečnostní systém, buď celá databáze, nebo jakýkoli objekt v databázi.

Tyto dva přístupy se liší v následujících vlastnostech:

V případě selektivní kontroly má některý uživatel různá práva (privilegia nebo pravomoci) při práci s těmito objekty. Různí uživatelé mohou mít různá přístupová práva ke stejnému objektu. Hlasovací práva se vyznačují značnou flexibilitou.

V případě selektivní správy je naopak každému datovému objektu přiřazena určitá úroveň klasifikace a každý uživatel má určitou úroveň povolení. S tímto přístupem mají přístup k určitému datovému objektu pouze uživatelé s odpovídající úrovní přístupu.

Pro realizaci volebního principu jsou poskytnuty následující metody. Zapsáno do databáze nový typ Objekty DB jsou uživatelé. Každému uživateli v databázi je přiřazen jedinečný identifikátor. Pro dodatečná ochrana každý uživatel je kromě jedinečného identifikátoru opatřen jedinečným heslem, a pokud má identifikátor uživatele v systému k dispozici správce systému, jsou uživatelská hesla nejčastěji uložena ve speciální zakódované podobě a jsou známa pouze uživatelům oni sami.

Uživatelé mohou být seskupeni do speciální skupiny uživatelů. Jeden uživatel může patřit do několika skupin. Norma zavádí koncept skupiny PUBLIC, pro kterou musí být definován minimální standardní soubor práv. Standardně se předpokládá, že každý nově vytvořený uživatel patří do skupiny PUBLIC, pokud není uvedeno jinak.

Oprávnění nebo pravomoci uživatelů nebo skupin jsou souborem akcí (operací), které mohou provádět s databázovými objekty.

V nejnovější verze v řadě komerčních DBMS se objevil pojem „role“. Role je pojmenovaná sada oprávnění. Existuje řada standardních rolí, které jsou definovány v době instalace databázového serveru. A je možné vytvářet nové role seskupováním libovolných pravomocí do nich. Zavedení rolí umožňuje zjednodušit správu uživatelských oprávnění a strukturovat tento proces. Zavedení rolí navíc není spojeno s konkrétními uživateli, takže role mohou být definovány a konfigurovány dříve, než jsou definováni uživatelé systému.

Uživateli lze přiřadit jednu nebo více rolí.

Databázové objekty, které podléhají ochraně, jsou všechny objekty uložené v databázi: tabulky, pohledy, uložené procedury a spouštěče. Každý typ objektu má své vlastní akce, takže pro každý typ objektu lze definovat různá oprávnění.

Na nejzákladnější úrovni jsou koncepty zabezpečení databáze extrémně jednoduché. Je třeba podporovat dva základní principy: credentialing a autentizaci.

Kontrola oprávnění je založena na skutečnosti, že každý uživatel nebo proces informační systém odpovídá souboru akcí, které může provádět ve vztahu k určitým objektům. Autentizace znamená platné potvrzení, že uživatel nebo proces, který se pokouší provést autorizovanou akci, je skutečně tím, za koho se vydává.

Systém přidělování pravomocí je poněkud hierarchický. Má nejvyšší práva a pravomoci Správce systému nebo správce databázového serveru. Tradičně pouze tento typ uživatele může vytvářet další uživatele a udělovat jim určitá oprávnění.

DBMS ve svých systémových katalozích uchovává jak popis samotných uživatelů, tak popis jejich oprávnění ve vztahu ke všem objektům.

Dále je schéma udělování pravomocí postaveno podle následujícího principu. Každý objekt v databázi je ve vlastnictví uživatele, který jej vytvořil. daný objekt. Vlastník objektu má všechna práva-oprávnění pro tento objekt, včetně práva udělovat ostatním uživatelům oprávnění k práci s tímto objektem nebo odebírat dříve udělená oprávnění uživatelům.

V řadě DBMS je zavedena další úroveň uživatelské hierarchie - to je správce databáze. V těchto DBMS může jeden server spravovat mnoho DBMS (například MS SQL Server, Sybase). Oracle DBMS používá jednozákladovou architekturu, takže zavádí koncept podschéma -- část obecné schéma databázi a zadává jej uživatel, který má přístup k podschématu. Standard SQL nedefinuje příkaz k vytvoření uživatele, ale téměř ve všech komerčních DBMS můžete vytvořit uživatele nejen interaktivně, ale také programově pomocí speciálních uložených procedur. K provedení této operace však musí mít uživatel právo spustit odpovídající systémovou proceduru.

Standard SQL definuje dva příkazy: GRANT a REVOKE, v tomto pořadí, udělování a odebírání oprávnění.

Prohlášení o dotaci má následující formát:

GRANT(<список действий | ALL PRIVILEGES }

NA<имя_объекта>ŽE (<имя_пользователя>] VEŘEJNÉ )

Seznam akcí zde definuje množinu akcí z obecně platného seznamu akcí na objektu daného typu.

Parametr ALL PRIVILEGES určuje, že jsou povoleny všechny akce povolené pro objekty tohoto typu.

<имя_обьекта>-- nastavuje název konkrétního objektu: tabulka, pohled, uložená procedura, spouštěč.

<имя_пользователя>nebo PUBLIC určuje, komu jsou oprávnění udělena.

MOŽNOST S GRANTEM je volitelná a definuje režim, který uděluje nejen práva k určeným akcím, ale také právo udělovat tato práva dalším uživatelům. V tomto případě může uživatel převádět práva pouze v rámci jemu povolených akcí.

Vezměme si příklad, řekněme, že máme tři uživatele s naprosto jedinečnými jmény userl, user2 a user3. Všichni jsou uživateli stejné databáze.

Uživatel1 vytvořil objekt Tab1, je vlastníkem tohoto objektu a může předávat práva k práci s tímto objektem dalším uživatelům. Řekněme, že uživatel2 je operátor, který potřebuje zadávat data do Tab1 (například tabulka nových objednávek) a uživatel 3 je velký šéf (například vedoucí oddělení), který potřebuje pravidelně kontrolovat zadaná data.

Pro objekt typu tabulka je úplný seznam povolených akcí sada čtyř operací: SELECT, INSERT, DELETE, UPDATE. V tomto případě může být operace aktualizace omezena na několik sloupců.

Obecný formát příkazu přiřazení oprávnění pro objekt typu tabulka by měl následující syntaxi:

GRANT ([.INSERT][,DELETED[.UPDATE (<список столбцов>)]) ZAPNUTO<имя таблицы>

ŽE (<имя_пользователя>VEŘEJNOST)

Pak by bylo rozumné provést následující úkoly:

PAK uživatel2 UDĚLEJTE VÝBĚR

Tato přiřazení znamenají, že uživatel2 má právo pouze zadávat nové řádky ve vztahu Tab1> a uživatel3 má právo zobrazit všechny řádky v tabulce Tab1.

Při přidělování přístupových práv operaci úpravy můžete určit, u kterých sloupců může uživatel změnit hodnotu. Řekněme, že vedoucí oddělení má právo změnit cenu za poskytované služby. Předpokládejme, že cena je nastavena ve sloupci COST tabulky Tab1. Potom se operace přidělování oprávnění uživateli user3 může změnit a vypadat takto:

GRANT SELECT. AKTUALIZACE (NÁKLADY) NA Tab.1 PRO uživatele3

Pokud náš uživatel user1 předpokládá, že ho může uživatel4 v případě jeho nepřítomnosti nahradit, pak může tomuto uživateli udělit všechna práva pro práci s vytvořenou tabulkou Tab1.

UDĚLEJTE VŠECHNA VÝHODY

TO user4 S MOŽNOSTÍ GRANTU

V tomto případě může uživatel user4 přidělit oprávnění pro práci s tabulkou Tab1 v nepřítomnosti vlastníka objektu user1. Pokud se tedy objeví nový uživatel operátor user5, může mu přidělit práva k zadávání nových řádků do tabulky příkazem

ON Tab1 TO user5

Pokud je při přenosu oprávnění omezena množina operací s objektem, pak uživatel, kterému jsou tato oprávnění přenesena, může přenést na jiného uživatele pouze ta oprávnění, která má, nebo část těchto oprávnění. Pokud tedy byla uživateli user4 delegována následující oprávnění:

GRANT SELECT. AKTUALIZACE. VYMAZAT

PRO uživatele 4 S MOŽNOSTÍ GRANTU,

pak uživatel4 nebude moci přenést oprávnění k zadávání dat uživateli5, protože tato operace pro něj není zahrnuta v seznamu povolených dat.

Kromě přímého přidělení práv pracovat s tabulkami účinná metoda ochranou dat může být vytvoření pohledů, které budou obsahovat pouze nezbytné sloupce pro práci konkrétního uživatele a udělení práv k práci s tímto pohledem uživateli.

Vzhledem k tomu, že pohledy mohou odpovídat souhrnným dotazům, operace úprav nejsou pro tyto pohledy povoleny, a proto je pro takové pohledy sada povolených akcí omezena na operaci SELECT. Pokud pohledy odpovídají výběru ze základní tabulky, budou pro takový pohled platné všechny 4 operace: SELECT, INSERT, UPDATE a DELETE.

Chcete-li zrušit dříve udělená oprávnění, standard SQL definuje příkaz REVOKE. Příkaz o odvolání oprávnění má následující syntaxi:

ZRUŠIT(<список операций | ALL PRIVILEGES} ON <имя_объекта>

Z(<список пользователей | PUBLIC } {CASCADE | RESTRICT }

Volby CASCADE nebo RESTRICT určují, jak mají být oprávnění odvolána. Volba CASCADE odebere nejen oprávnění uživatele, který byl přímo jmenován v příkazu GRANT při udělení oprávnění, ale také všechny uživatele, kterým tento uživatel udělil oprávnění pomocí volby WITH GRANT OPTION.

Například při použití operace:

ZRUŠIT VŠECHNA PRIVILEGIA - NA Tab1 TO user4 CASCADE

oprávnění uživatele5, kterému se podařilo uživateli4 přidělit oprávnění, budou také odvolána.

Volba RESTRICKT omezuje odvolání oprávnění na uživatele přímo jmenovaného v příkazu REVOKE. Pokud však máte delegovaná oprávnění, tento příkaz nebude proveden. Takže například operace:

ZRUŠIT VŠECHNA PRIVILEGIA NA Tab1 TO user4 OMEZIT

nebude spuštěn, protože uživatel4 delegoval část svých oprávnění na uživatele5.

Pomocí příkazu REVOKE můžete odebrat všechna nebo pouze některá dříve přiřazená oprávnění pro práci s určitým objektem. Zároveň z popisu syntaxe operátoru revokace oprávnění je vidět, že je možné odebrat oprávnění s jedním operátorem více uživatelům najednou nebo celé skupině PUBLIC.

Proto je správné následující použití příkazu REVOKE:

ZRUŠIT VLOŽENÍ NA kartě! TO user2.user4 CASCADE

Při práci s jinými objekty se mění seznam operací, které jsou použity v příkazech GRANT a REVOKE.

Standardně je akce odpovídající spuštění (provedení) uložené procedury přiřazena všem členům skupiny PUBLIC.

Chcete-li tuto podmínku změnit, musíte po vytvoření uložené procedury napsat příkaz REVOKE.

REVOKE EXECUTE ON COUNT_EX TO PUBLIC CASCADE A nyní můžeme uživateli4 přidělit nová práva.

GRANT EXECUTE ON COUNT_EX TO user4

Správce systému může povolit určitému uživateli vytvářet a upravovat tabulky v určité databázi. Pak může napsat operátora grantu takto:

GRANT VYTVOŘIT TABULKU. ALTER TABLE, DROP TABLE ON OB_LIB TO user1

V tomto případě může uživatel1 vytvářet, upravovat nebo mazat tabulky v databázi DB_LIB, ale nemůže povolit ostatním uživatelům vytvářet nebo upravovat tabulky v této databázi, protože mu bylo uděleno oprávnění bez práva delegovat své schopnosti.

V některých DBMS mohou být uživateli udělena práva k vytvoření databáze. Například v MS SQL Server může správce systému udělit uživateli main_user právo vytvořit si vlastní databázi na tomto serveru. To lze provést pomocí následujícího příkazu:

GRANT VYTVOŘTE DATABÁZI

NA SERVERU) hlavnímu uživateli

Na základě principu hierarchie může nyní uživatel main_user po vytvoření vlastní databáze udělovat práva k vytváření nebo úpravě jakýchkoli objektů v této databázi jiným uživatelům. V DBMS, které podporují jednozákladní architekturu, taková oprávnění nejsou povolena. Například v Oracle DBMS je na serveru vytvořena pouze jedna databáze, ale uživatelé mohou pracovat na úrovni podschéma (části databázových tabulek a související objekty). Proto je tam zaveden koncept systémových oprávnění. Je jich hodně, 80 různých výsad.

Aby uživatel mohl v rámci této databáze vytvářet objekty, používá se koncept systémových oprávnění, které lze přiřadit jednomu nebo více uživatelům. Vydávají se pouze pro akce a konkrétní typ objektu. Pokud jste tedy jako správce systému udělili uživateli právo vytvářet tabulky (CREATE TABLE), pak aby mohl vytvořit trigger pro tabulku, musí mu být uděleno další systémové oprávnění CREATE TRIGGER. Bezpečnostní systém v Oracle je považován za jeden z nejvýkonnějších, ale má to nevýhodu – je velmi složitý. Úkol správy v Oracle proto vyžaduje dobrou znalost jak sémantiky principů udržování přístupových práv, tak fyzické implementace těchto schopností.

Implementace ochrany v některých DBMS

Architektura zabezpečení přístupu. Pokud máte zkušenosti se zabezpečením používaným na serveru nebo sálovém počítači, bude vám struktura zabezpečení v Accessu znít povědomě. Můžete určit, kteří uživatelé mají povolen nebo odepřen přístup k databázovým objektům. Kromě toho můžete definovat skupiny uživatelů a přidělovat oprávnění na úrovni skupiny, aby bylo snazší vytvářet zabezpečení pro velký počet uživatelů. Stačí, aby uživatel byl členem skupiny a získal pro ni nastavená přístupová práva.

Access ukládá bezpečnostní informace na dvou místech. Během instalace vytvoří instalační program ve složce \Program Files\Microsoft Office\0ffice standardní soubor pracovní skupiny (System.mdw), který se poté použije jako výchozí při spuštění aplikace Access. Tento soubor obsahuje informace o všech uživatelích a skupinách. Když vytvoříte databázi, Access ukládá informace o právech udělených konkrétním uživatelům a skupinám do databázového souboru.

Umístění aktuálního souboru pracovní skupiny je uloženo v registru systému Windows. Pomocí nástroje Wrkadm.exe (Workgroup Administrator) můžete upravit aktuální nebo definovat nový soubor pracovní skupiny. Kromě toho můžete požadovaný soubor pracovní skupiny vybrat za běhu nastavením příslušné možnosti příkazového řádku v zástupce pro spuštění.

Pokud v síti často spouštíte sdílenou zabezpečenou aplikaci, měli byste zajistit, aby správce systému nastavil vaši výchozí pracovní skupinu jako sdílený soubor v síťové složce.

Každá pracovní skupina má jedinečné interní ID, které vygeneruje Access při definování souboru pracovních skupin. Jakákoli databáze vytvořená uživatelem pracovní skupiny je „vlastněna“ tímto uživatelem i pracovní skupinou. Každý uživatel a skupina má také jedinečné interní ID, ale je možné duplikovat stejné ID uživatele a skupiny ve více pracovních skupinách.

Když přiřadíte přístup k objektu v databázi, Access uloží interní ID uživatele nebo skupiny do databáze spolu s informacemi o přístupu. Práva, která udělíte, se tedy přesunou s databázovým souborem, když jej zkopírujete do jiné složky nebo počítače.

Organizace obrany

V kritických obchodních aplikacích, kdy musí být server DBMS neustále dostupný klientům, musí být většina preventivní údržby databáze prováděna prakticky on-line. MS SQL Server má schopnost dynamicky zálohovat data, tedy i když tato data používají a mění klienti. V případě selhání hardwaru, výpadku proudu apod. automatický obnovovací mechanismus MS SQL Serveru obnoví všechny databáze do posledního konzistentního stavu bez zásahu administrátora. Všechny dokončené, ale neodrážející se v databázovém protokolu z transakčního protokolu, jsou aplikovány na databázi (to se ve skutečnosti děje v události kontrolního bodu) a probíhající transakce, tj. ty, které byly aktivní v době selhání, jsou vymazány z log.

Když už mluvíme o symetrické architektuře, operace zálohování a obnovy mohou být vícevláknové a spouštěné souběžně s využitím výhod asynchronního I/O. Každé zálohovací zařízení má svůj vlastní stream. Paralelní zálohování podporuje až 32 simultánních zálohovacích zařízení, což umožňuje rychle vytvářet záložní kopie i velmi rozsáhlých databází. Možnost zálohovat a obnovovat jednotlivé tabulky, o které jsme se zmínili při probírání Transact-SQL, umožňuje ušetřit místo a čas tím, že nekopírujete celou databázi jen pro některé její objekty. Zálohování jedné tabulky však vyžaduje exkluzivní zámek, na rozdíl od zálohování celé databáze nebo transakčního protokolu, které lze provádět bez ohledu na úroveň aktivity uživatele. Zálohám lze přiřadit dobu uchování nebo datum vypršení platnosti, před kterým nelze místo obsazené těmito zálohami na zařízení použít k ukládání dalších záloh při inicializaci zařízení. Dočasná zařízení, která nejsou součástí databáze a nemají záznamy v systémové tabulce sysdevices, lze také použít jako záložní zařízení:

DECLARE @tomorrow char(8)

SELECT @zítra = CONVERT(char(8), DATEADD(dd, 1, GETDATE()) , 1)

DUMP DATABASE hospody

NA DISK = "\\ntalexeysh\disk_d\sql_experiments\pubs.dmp"

S INIT, [e-mail chráněný], STATISTIKY

U malé databáze je její transakční protokol obvykle uložen na stejném zařízení jako samotná databáze a archivován spolu s ní. Logování transakcí probíhá na principu write-ahead, což znamená, že jakákoliv změna se nejprve projeví v transakčním logu a teprve poté se dostane do samotné databáze. Pokud je transakční protokol umístěn na samostatném zařízení, je možné zálohovat transakční protokol samostatně.

Databáze se obvykle zálohuje méně často než protokol transakcí. Například protokol transakcí se ukládá denně a záložní kopii celé databáze lze vytvořit jednou týdně, protože archivace protokolu transakcí je časově mnohem rychlejší a zabírá méně místa než výpis celé databáze. Na rozdíl od zálohování databáze, dumping protokolu transakcí vymaže jeho neaktivní část, tj. všechny dokončené (potvrzené nebo přerušené) transakce od posledního výpisu, pokud není použita možnost NO_TRUNCATE. Příkaz DUMP TRANSACTION TRUNCATE_ONLY, který vymaže transakční protokol, je užitečný v případě přetečení, které lze ovládat např. příkazem DBCC SQLPERF (LOGSPACE). Pokud je stupeň přetečení protokolu velmi vysoký, můžete odmítnout protokolování samotné skutečnosti této události při jejím mazání: DUMP TRANSACTION NO_LOG. Pokud nemáte zájem o zálohování transakcí, můžete povolit možnost vymazat poslední dokončené transakce v databázi při výskytu události kontrolního bodu. Smyslem mechanismu kontrolních bodů je periodicky zapisovat data z mezipaměti na disk, aby se zabránilo znečištění dat. Takové události jsou neustále generovány MS SQL Serverem nebo k nim dochází z iniciativy uživatele. Pokud je povolena, volba zkrácení log on checkpoint zajišťuje, že obslužná rutina události provádí akce s určitou frekvencí, která je přibližně ekvivalentní příkazu DUMP TRANSACTION TRUNCATE_ONLY.

Po obnovení protokolu transakcí se odpovídající transakce použijí v databázi. To znamená, že pokud byla zálohována celá databáze na začátku týdne a poté byly transakce pro každý den archivovány denně, pak pokud je nutné obnovení, stav databáze na začátku týdne se zvýší a protokol transakcí postupně se na něj navalují skládky za všechny dny předcházející okamžiku obnovy. MS SQL Server 6.5 má schopnost obnovit data z transakčního protokolu do libovolného bodu v čase (samozřejmě promítnutý do protokolu) pomocí příkazu LOAD TRANSACTION STOPAT nebo v okně zálohování a obnovy databáze výběrem možnosti do času. Všechny transakce obsažené v tomto výpisu, které jsou po tomto okamžiku označeny jako dokončené, budou vráceny zpět.

Možnost včasného plánování úloh zálohování a zasílání zpráv e-mailem v případě úspěchu / neúspěchu jsme zvažovali při diskuzi o SQL Executive.

MS SQL Server 6.5 poskytuje možnost zrcadlení zařízení, přepnutí na zrcadlová zařízení jako hlavní, vypnutí zrcadlení a zničení zrcadlového zařízení také „za běhu“, tedy bez zastavení běžného provozu serveru pro obsluhu požadavků uživatelů. Zrcadlení a duplexování zařízení pro práci s MS SQL Serverem lze provádět také pomocí nástrojů Windows NT, a to i na úrovni hardwaru (podpora různých systémů RAID atd.). Zřejmě by se mělo předpokládat, že implementace první fáze clusterové technologie WolfPack bude podporovat MS SQL Server 6.5 ve dvouuzlových failover clusterech. Vzhled další verze MS SQL Serveru by měl zajistit provoz serverů v clusteru jako jediného virtuálního serveru.

Transfer Manager se používá k exportu/importu objektů a databázových dat na MS SQL Server mezi různými hardwarovými platformami, například mezi procesory Intel a Alpha, jakož i mezi různými verzemi MS SQL Server, zejména z dřívějších na novější nebo mezi ekvivalentními jedničky (k dispozici 4.xa 6.x). Velmi často se návrh databázových objektů provádí pomocí různých grafických nástrojů, ale projektová dokumentace může vyžadovat strukturu objektů až po příkazy DDL. Chcete-li získat skripty, které popisují vytvoření jednoho databázového objektu, můžete použít příkaz transfer z místní nabídky objektu nebo vybrat příslušnou třídu a název objektu ve Správci přenosu. Datový obsah lze navíc nahrávat/stahovat pomocí nástroje bcp (viz tabulka 1).

Problémy se zabezpečením přístupu

Pokud jde o výhody integrace s operačním systémem, MS SQL Server při své práci využívá bezpečnostní služby Windows NT. Připomeňme, že Windows NT je aktuálně certifikován podle bezpečnostních tříd C2 / E3. MS SQL Server lze nakonfigurovat tak, aby fungoval v jednom ze tří režimů zabezpečení. Integrovaný režim používá mechanismy ověřování systému Windows NT k zabezpečení veškeré uživatelské komunikace. V tomto případě jsou k serveru povolena pouze důvěryhodná nebo ověřující připojení (pojmenované kanály a víceprotokolové). Administrátor má možnost mapovat skupiny uživatelů Windows NT na odpovídající hodnoty přihlašovacích id MS SQL Server pomocí nástroje SQL Security Manager. V tomto případě se při přihlašování na MS SQL Server ignoruje přihlašovací jméno a heslo předané přes DB-Library nebo ODBC. Standardní bezpečnostní režim předpokládá, že na MS SQL Serveru budou vytvořena nezávislá přihlašovací jména a jim odpovídající hesla. Smíšený režim používá integrovaný model při vytváření pojmenovaných kanálů nebo víceprotokolových připojení a standardní model ve všech ostatních případech.

MS SQL Server poskytuje víceúrovňovou kontrolu oprávnění při načtení na server. Nejprve jsou identifikována práva uživatele k navázání spojení s vybraným serverem (přihlašovací jméno a heslo) a provádění administrativních funkcí: vytváření zařízení a databází, přidělování práv dalším uživatelům, změna nastavení serveru atd. Správce systému má maximální práva. Na úrovni databáze může mít každý uživatel přihlášený na server uživatelské jméno (uživatelské jméno) databáze a přístupová práva k objektům v ní. Je možné mapovat více přihlašovacích id na uživatele databáze, stejně jako skupinové uživatele pro snadnou správu a přidělování podobných oprávnění. Ve vztahu k databázovým objektům lze uživateli přidělit práva k provádění různých operací s nimi: čtení, přidávání, mazání, úpravy, deklarativní referenční integritu (DRI), provádění uložených procedur a také práva na přístup k jednotlivým polím. Pokud to nestačí, můžete se uchýlit k pohledům (views), pro které platí výše uvedené. Nakonec můžete uživateli obecně zakázat přímý přístup k datům a ponechat mu pouze práva na provádění uložených procedur, které budou obsahovat celý scénář jeho přístupu k databázi. Uložené procedury lze vytvořit pomocí možnosti WITH ENCRYPTION, která zašifruje skutečný text procedury, obvykle uložený v syscomments. Práva k provádění některých příkazů (vytváření databází, tabulek, výchozích hodnot, pravidel, pohledů, procedur, zálohování databází a transakčních protokolů) nejsou specifická pro objekt, takže je přiděluje systémový administrátor serveru nebo vlastník (tvůrce) databáze při editaci databáze. Uživatelská oprávnění jsou obvykle spravována v SQL Enterprise Manager, nicméně Transact-SQL má uložené procedury (sp_addlogin, sp_password, sp_revokelogin, sp_addalias, sp_adduser) a příkazy (GRANT, REVOKE), které umožňují vytvoření, přiřazení a zrušení akcí uživatele. práva při provádění skripty. Další příležitost ke správě oprávnění poskytují výše popsané SQL-DMO.

Řízení přístupu

Bezpečnostní systém SQL Server má několik úrovní zabezpečení:

* operační systém;

* databáze;

* objekt databáze.

Na druhé straně bezpečnostní mechanismus předpokládá existenci čtyř typů uživatelů:

* správce systému s neomezeným přístupem;

* vlastník databáze má plný přístup ke všem databázovým objektům;

* vlastník databázových objektů;

* ostatní uživatelé, kteří musí získat oprávnění pro přístup k databázovým objektům.

Model zabezpečení serveru SQL Server obsahuje následující součásti:

* typ připojení k serveru SQL Server;

* uživatel databáze;

* uživatel (host);

* role.

Typ připojení SQL server

Při připojení (a v závislosti na typu připojení) SQL Server podporuje dva režimy zabezpečení:

* Režim ověřování Windows NT;

* smíšený režim ověřování.

Režim ověřování WINDOWSNT používá systém zabezpečení WINDOWSNT a jeho mechanismus účtů. Tento režim umožňuje serveru SQL Server používat uživatelské jméno a heslo, které jsou definovány v systému Windows, a tím obejít proces připojení k serveru SQL Server. Uživatelé s platným účtem Windows se tak mohou připojit k serveru SQL Server bez zadání svého uživatelského jména a hesla. Když uživatel přistupuje k DBMS, DBMS získá informace o uživatelském jménu a hesle z atributů zabezpečení sítě uživatele Windows (které se nastavují, když se uživatel připojí k Windows).

Ověřování ve smíšeném režimu používá ověřovací systémy Windows i SQL Server. Při použití autentizačního systému SQL Server musí jednotlivý uživatel připojující se k serveru SQL zadat uživatelské jméno a heslo, které budou porovnány s těmi, které jsou uloženy v systémové tabulce serveru. Při použití ověřovacího systému Windows se uživatelé mohou připojit k serveru SQL Server bez zadání uživatelského jména a hesla.

Uživatelé databáze

Termín uživatel databáze odkazuje na databázi (nebo databáze), ke které může přistupovat jeden uživatel. Po úspěšném připojení server určí, zda má tento uživatel oprávnění pracovat s databází, ke které se přistupuje.

Jedinou výjimkou z tohoto pravidla je uživatel typu host. Speciální uživatelské jméno guest umožňuje každému uživateli připojenému k SQL Serveru přístup k této databázi. Uživateli s názvem guest je přiřazena veřejná role.

Přístupová práva

Ke správě přístupových práv v SQL Server se používají následující příkazy:

* GRANT. Umožňuje provádět akce s objektem nebo jej v případě příkazu provést;

* ZRUŠIT. Odebere přístupová práva k objektu nebo v případě příkazu zabrání jeho provedení;

* ODMÍTAT. Nedovoluje vám provádět akce s objektem (zatímco příkaz REVOKE tato oprávnění jednoduše odebere).

Oprávnění k objektům umožňují řídit přístup k objektům na serveru SQL Server udělováním a odebíráním oprávnění k tabulkám, sloupcům, pohledům a uloženým procedurám. K provedení akce s objektem musí mít uživatel příslušné přístupové právo. Pokud chce uživatel například provést příkaz tabulky SELECT * FROM, musí mít také právo provést příkaz SELECT pro tabulku tabulky.

Oprávnění příkazů určují, kteří uživatelé mohou provádět administrativní akce, jako je vytváření nebo kopírování databáze. Oprávnění příkazů jsou následující:

CREATE DATABASE -- právo vytvořit databázi;

CREATE DEFAULT -- právo vytvořit výchozí hodnotu pro sloupec tabulky;

CREATE PROCEDURE -- právo vytvořit uloženou proceduru.

CREATE ROLE -- právo vytvořit goavil pro sloupec tabulky;

CREATE TABLE -- právo vytvořit tabulku;

CREATE VIEW -- právo vytvořit pohled;

ZÁLOHA DATABÁZE -- právo vytvořit záložní kopii;

ZÁLOŽNÍ TRANSAKCE -- právo vytvořit záložní kopii transakčního protokolu.

Role

Přiřazení uživatele k určitému relé mu umožňuje provádět všechny funkce, které tato role umožňuje. Role v podstatě logicky seskupují uživatele se stejnými přístupovými právy. SQL Server má následující typy rolí:

* role na úrovni serveru;

* Role na úrovni databáze.

Role na úrovni serveru

Tyto role poskytují různé stupně přístupu k operacím a úlohám serveru*. Role na úrovni serveru jsou předdefinované a fungují v rámci serveru. Jsou nezávislé na konkrétních databázích a nelze je upravovat.

V SQL Server existují následující typy rolí na úrovni serveru:

Sysadmin - dává právo provádět jakoukoli akci v SQL Server;

Serveradmin - dává právo změnit nastavení SQL Server a vypnout;

Setupadmin - dává právo instalovat replikační systém a spravovat provádění rozšířených uložených procedur;

Securityadmin - dává právo kontrolovat parametry účtů pro připojení k serveru a udělovat přístupová práva k databázím;

Processadmin - dává právo řídit průběh procesů v SQL Server;

Dbcreator - dává právo vytvářet a upravovat databáze;

Diskadmin -- Dává vám právo spravovat databázové soubory na disku.

Role na úrovni databáze

Role na úrovni databáze vám umožňují přiřadit práva pro práci s konkrétní databází jednotlivému uživateli nebo skupině. Role na úrovni databáze lze přiřadit uživatelským účtům v režimu ověřování Windows nebo SQL Server. Role lze také vnořovat, takže účtům lze přiřadit hierarchickou skupinu přístupových práv.

SQL Server má tři typy rolí:

* předdefinované role;

* uživatelsky definované role;

* implicitní role.

Standardní role na úrovni DB jsou předdefinovány. Každá databáze SQL Server má tyto role. Umožňují snadný a jednoduchý přenos povinností.

Předdefinované role jsou specifické pro databázi a nelze je změnit. Standardní role na úrovni databáze jsou uvedeny níže.

db_owner -- definuje plný přístup ke všem databázovým objektům, může mazat a znovu vytvářet objekty a přidělovat práva k objektům ostatním uživatelům. Zahrnuje všechny funkce uvedené níže pro ostatní standardní role na úrovni databáze;

db_accessadmin -- řídí přístup k databázi přidáváním nebo odebíráním uživatelů v režimech ověřování;

db_datareader -- definuje plný přístup k získávání dat (pomocí příkazu SELECT) z libovolné databázové tabulky. Zakazuje provádění příkazů INSERT, DELETE a UPDATE pro jakoukoli databázovou tabulku;

db_datawriter -- umožňuje provádět příkazy INSERT, DELETE a UPDATE na libovolné databázové tabulce. Zakáže provedení příkazu SELECT pro jakoukoli tabulku v databázi;

db_ddladmin -- umožňuje vytvářet, upravovat a mazat databázové objekty;

db_securityadmin -- spravuje systém zabezpečení databáze a také přidělování oprávnění k objektům a příkazům a rolí pro databázi;

db_backupoperator -- umožňuje vytvářet zálohy databáze;

db_denydatareader -- Odepřít oprávnění k provedení příkazu SELECT na všech databázových tabulkách. Umožňuje uživatelům upravovat stávající struktury tabulek, ale neumožňuje vytváření nebo odstraňování existujících tabulek;

db_denydatawriter -- Odepřít oprávnění k provádění příkazů modifikace dat (INSERT, DELETE a UPDATE) na jakýchkoli databázových tabulkách;

public -- automaticky přiřazená role ihned po udělení uživatelských přístupových práv k databázi.

Uživatelsky definované role vám umožňují seskupit uživatele a přiřadit konkrétní bezpečnostní funkci každé skupině.

Existují dva typy uživatelských rolí na úrovni databáze:

* standardní role;

* Role na úrovni aplikace.

Standardní role poskytuje metodu pro vytváření uživatelsky definovaných rolí specifickou pro databázi. Nejběžnějším účelem standardní role je logické seskupování uživatelů podle jejich přístupových práv. Například aplikace mají několik typů úrovní zabezpečení spojených se třemi kategoriemi uživatelů. Zkušený uživatel může provádět jakoukoli operaci s databází; běžný uživatel může modifikovat některé datové typy a aktualizovat data; nekvalifikovaný uživatel má obvykle zakázáno upravovat jakékoli datové typy.

Role na úrovni aplikace umožňuje uživateli vykonávat práva role. Když uživatel převezme roli na úrovni aplikace, uživatel převezme novou roli a dočasně se vzdá všech ostatních přístupových práv specifických pro databázi, která mu byla přidělena. Role na úrovni aplikace má smysl v prostředí, kde uživatelé dotazují a upravují data pomocí klientské aplikace.

Systémová analýza je aplikace systematického přístupu při zpracování konkrétních informací a rozhodování. Uvažovanými principy systémového přístupu jsou také principy systémové analýzy.

Jsou doplněny o následující specifické zásady:

* analýza jakéhokoli rozhodovacího procesu by měla začít identifikací a jasnou formulací cílů (požadovaných výkonových výsledků), které jsou často určeny na základě zvážení systému vyšší úrovně;

* je třeba uvažovat pouze ty cíle, jejichž pravděpodobnost dosažení p>p0 v čase t

Tyto speciální principy implikují určitou systémovou strategii analýzy, která vyžaduje zohlednění nejen systému samotného, ​​ale také vnějšího prostředí (supersystémy nebo metasystémy) a vymezení hranice mezi nimi.

Perspektivu rozvoje systémů pro vyhledávání dokumentárních informací a databází jsou znalostní banky, nový koncept informačního systému, který využívá výsledky výzkumu a vývoje v oblasti umělé inteligence.

Zabezpečení dat v Oracle 7

Omezení přístupu. Pokud jsme si jisti, že se k naší databázi mohou připojit pouze oprávnění uživatelé a že mohou spouštět pouze moduly, ke kterým mají výslovně oprávnění, pak musíme myslet na další úroveň zabezpečení – omezení přístupu těchto uživatelů k datům.

Obrovským krokem vpřed v zabezpečení dat bylo zavedení rolí v Oracle7. Před Oracle7 musel každý uživatel explicitně udělit přístupová práva ke každému databázovému objektu, který směl používat. Tento proces je zjednodušen tím, že roli udělíte přístup ke sbírce objektů a poté udělíte právo používat tuto roli příslušným jednotlivcům. Pomocí příkazu GRANT můžeme uživatelům udělit právo provádět operace SELECT, INSERT, UPDATE a DELETE na databázových objektech (například tabulkách). To však samo o sobě neposkytuje velkou flexibilitu. Uživatelům můžeme omezit přístup k částem tabulky tak, že ji rozdělíme horizontálně (omezíme uživatele na určité řádky), vertikálně (omezíme uživatele na určité sloupce) nebo horizontálně i vertikálně. Jak to udělat?

Vraťme se k našemu příkladu tabulky MZDY. Nechceme, aby všichni uživatelé viděli sloupec MZDA, a chceme omezit přístup uživatelů tak, aby viděli pouze záznamy za zaměstnance svého oddělení.

Můžeme definovat pohled a poskytnout uživatelům přístup k tomuto pohledu spíše než k podkladové tabulce (PAYROLL). Budou se moci dotazovat na data tabulky pouze prostřednictvím pohledu, který omezuje jejich přístup. Definice takového pohledu je uvedena níže.

CREATE VIEW vjpayroll AS SELECT id

Platební_období Z mezd WHERE odd. = (VYBRAT odd

FROM mysys_users WHERE uživatelské jméno = USER) S MOŽNOSTÍ KONTROLY;

Sloupec SALARY v tomto příkladu není zahrnut v pohledu, takže v něm nevidíte plat a klauzule WHERE zajišťuje, že uživatelé mohou dotazovat data z tabulky MZDY pouze pro své oddělení.

K tomuto rozhodnutí je třeba říci následující. Nejprve musíme uživatelům zabránit ve změně jejich oddělení aktualizací hodnoty MYSYSJUSERS a poté vyžádáním záznamů z jiného oddělení. Za druhé, s tímto zobrazením mohli uživatelé aktualizovat, vkládat a odstraňovat i řádky mimo oddělení v tabulce MZDY, pokud jsme tuto funkci nezakázali pomocí klauzule WITH CHECK OPTION.

Poznámka

Pohled V_PAYROLL pravděpodobně nebude aktualizovatelný, protože ve sloupci SALARY je téměř jistě použito omezení NOT NULL. Doporučujeme však použít WITH CHECK OPTION na všech ohraničujících pohledech, protože došlo k výraznému nárůstu počtu pohledů, které jsou aktualizovány ve verzi 7.3.

Omezení zobrazení dat pomocí zobrazení funguje velmi dobře. U velké tabulky se složitými požadavky na zabezpečení však možná budete muset vytvořit více pohledů a nechat aplikace rozhodnout, které z nich je pro konkrétního uživatele potřeba. Implementace tohoto v rámci aplikace není žádoucí, takže by měla být prozkoumána jiná řešení. Všechny operace na tabulce MZDY můžeme zapouzdřit do uloženého balíčku nebo vyvinout více spouštěčů. Podívejme se na první řešení.

Použití balíčků

Balíček má metody (procedury/funkce), které vám umožňují pracovat s tabulkou nebo z ní dotazovat řádky. Pro uživatele, který má oprávnění ke spuštění balíčku, ale nemá oprávnění k přístupu k tabulce, jsou obsah a struktura tabulky přímo nepřístupné. Majitel balíčku má plný přístup k MZD, ale volající uživatel ne. Když uživatel provede uloženou proceduru, to znamená, že ve skutečnosti použije pohled, jedná s přístupovým oprávněním uděleným jejímu vlastníkovi.

Náš první pokus o vytvoření takového balíčku je uveden v příkladu 10.2. Balíček k_payroll zajišťuje, že záznamy může mazat pouze vedoucí oddělení a pouze vedoucí oddělení může nastavovat hodnotu sloupce MZDA.

Příklad vytvoření balíčku pro zajištění bezpečnosti přístupu k datům

VYTVOŘIT NEBO VYMĚNIT BALÍČEK k_payroll AS my_dept payroll.dept%TYPE; mgr BOOLEAN;

PROCEDURE del(p_emp_id INTEGER);

PROCEDURE ins (p_emp_id INTEGER, p_name VARCHAR2

P_odd INTEGER, p_platební_období VARCHAR2

P_plat CELÉ ČÍSLO);

PROCEDURE upd(p_emp_id INTEGER, p_name VARCHAR2

P_platba_penod VARCHAR2 ,p_plat INTEGER);

/VYTVOŘIT NEBO VYMĚNIT TĚLO BALÍKU k_payroll AS

mgr_flag payroll.mgr_flag%TYPE;

OD mysys_users

WHERE uživatelské jméno = USER;

FUNCTION checkdept (p_emp_id INTEGER) NÁVRAT BOOLEAN JE

odd mzdy.odd%TYPE;

CURSOR cjpayroll IS

Z výplaty mezd

WHERE id = p_emp_id;

OPEN c_payroll ;

FETCH cjpayroll DO odd;

ZAVŘÍT c_payroll;

oddělení IF<>moje_oddělení PAK

POSTUP del (p_emp_id INTEGER) JE

Mazat zaměstnance mohou pouze vedoucí jejich oddělení

Záznamy mzdové tabulky

POKUD checkdept(p_emp_id) AND mgr THEN

WHERE id = p_emp_id;

raise_application_error(-20001, "Nedostatečné oprávnění"); KONEC KDYŽ;

Podobné dokumenty

Nutnost a potřeba ochrany informací. Druhy ohrožení bezpečnosti informačních technologií a informací. Kanály úniku a neoprávněný přístup k informacím. Zásady navrhování systému ochrany. Vnitřní a vnější pachatelé AITU.

test, přidáno 04.09.2011


Historické aspekty vzniku a vývoje informační bezpečnosti. Prostředky informační bezpečnosti a jejich klasifikace. Druhy a princip fungování počítačových virů. Právní základ pro ochranu informací před neoprávněným přístupem.

prezentace, přidáno 12.9.2015


Charakteristika hlavních metod ochrany před neoprávněným přístupem. Vývoj systémové bezpečnostní politiky. Návrh softwarové aplikace některých prostředků ochrany informací v OS. Obsah hlavních oddílů rejstříku.

laboratorní práce, přidáno 17.03.2017


Studium pojmu a klasifikace typů a metod neoprávněného přístupu. Definice a model útočníka. Organizace informační bezpečnosti. Klasifikace způsobů ochrany informací v počítačových systémech před náhodnými a záměrnými hrozbami.

abstrakt, přidáno 16.03.2014


Moderní vývoj automatizovaných systémů řízení a ochrany informací. Funkce ochranného systému se třemi registry. Volba ochranných mechanismů a jejich vlastnosti. Odpovědnost za porušení bezpečnosti metod. Metody ochrany v režimu přímého přístupu. Požadavky na informační bezpečnost.

abstrakt, přidáno 29.10.2010


Metody a prostředky ochrany informačních dat. Ochrana před neoprávněným přístupem k informacím. Vlastnosti ochrany počítačových systémů kryptografickými metodami. Kritéria pro hodnocení bezpečnosti informačních počítačových technologií v evropských zemích.

test, přidáno 08.06.2010


Způsoby neoprávněného přístupu, klasifikace metod a prostředků ochrany informací. Kanály úniku informací. Hlavní směry ochrany informací v EMS. Opatření přímé ochrany PC. Analýza bezpečnosti uzlů místní sítě "Stroyproekt".

práce, přidáno 06.05.2011


Metody a prostředky ochrany informací před neoprávněným přístupem. Vlastnosti ochrany informací v počítačových sítích. Kryptografická ochrana a elektronický digitální podpis. Metody ochrany informací před počítačovými viry a útoky hackerů.

abstrakt, přidáno 23.10.2011


Způsoby neoprávněného přístupu, klasifikace metod a prostředků ochrany informací. Analýza metod informační bezpečnosti v LAN. Identifikace a autentizace, protokolování a auditování, řízení přístupu. Koncepce bezpečnosti počítačových systémů.

práce, přidáno 19.04.2011


Software a hardware pro ochranu počítače před neoprávněným přístupem. Elektronický zámek "Sobol". Informační bezpečnostní systém SecretNet. Zařízení pro zabezpečení otisků prstů. Správa veřejných klíčů, certifikační autority.

Zatímco se ale naši zákonodárci přou o návrhy zákonů o obchodním tajemství a elektronickém obchodu, na veřejných místech – na přechodech metra a dokonce i na parkovištích, nemluvě o internetu, se CD s různými databázemi (DB) prodávají dál. Výběr je neobvykle široký: za 40–60 USD vám bude nabídnuta databáze MGTS (aktualizováno - leden 2003), Jednotná státní registrace podniků (kompletní informace o podnicích registrovaných v Rusku v roce 2003), informace o registraci v Moskvě a Moskevská oblast , a dražší, za 110 dolarů si můžete koupit databázi zahraniční ekonomické aktivity atd. Mírně "zastaralé zboží", například mírně zastaralé údaje o předplatitelích MTS (k listopadu 2002), stojí pouze 40 " cu ".

Je nepravděpodobné, že nějakého poctivého občana potěší, když na takto pořízeném CD najde své osobní údaje. Ostatně takový disk si může snadno koupit nejen „zvídavý soudruh“, ale i tzv. zločinecké struktury. Nejhorší však je, že dosud prakticky neexistovaly reálné mechanismy k zabránění krádeži informací a prokázání trestného činu k potrestání narušitelů. Řešení, které implementuje ochranu dat pod kontrolou Oracle 9i DBMS pomocí elektronických klíčů eToken, nemá podle autorů v době psaní tohoto článku na světovém trhu ochrany informací obdoby.

Podstatou metody je použití standardních mechanismů infrastruktury veřejných klíčů a organizace přístupu uživatelů k informacím po předložení digitálních certifikátů X.509 podporovaných nástroji Oracle Advanced Security na dvou úrovních: pro autentizaci v podnikové síti (například pod Microsoft Windows Server 2000/2003 ) a pro přístup k citlivým datům, která jsou zpracovávána a ukládána na serverech Oracle. Oba certifikáty jsou uloženy v osobním identifikátoru v podobě USB klíče nebo čipové karty eToken.

Tato metoda umožňuje výrazně snížit rizika ztrát spojených s lidským faktorem a jedinečně personalizovat jednání uživatelů informačních systémů pracujících s Oracle 9i DBMS.

Hlavní otázky

Proč dochází ke krádežím informací v různých organizacích, dokonce i v orgánech činných v trestním řízení? Jaké jsou předpoklady pro únik dat a je pro překonání stávající ochrany nutné mít rozsáhlé znalosti a dovednosti crackera? Existují způsoby, jak vybudovat systémy zabezpečení informací (IPS), aby se minimalizovalo riziko ztráty dat? Mohu chránit firemní data před vlastním správcem systému?

Všechny tyto otázky související s ochranou důvěrných dat na úrovni DBMS by měly být posuzovány z různých hledisek, přičemž je třeba vzít v úvahu nejen databázovou architekturu a vestavěné ochranné nástroje, ale také konfiguraci podnikové sítě, jejího systému ochrany a specifika klientských stanic.

Úrovně ochrany přístupu k datům

Typický model ochrany přístupu uživatelů k podnikovým datům a aplikacím zahrnuje čtyři prvky:

• organizační opatření k omezení přístupu k počítači připojenému k podnikové síti;
• omezení přístupu do podnikové sítě;
• ochrana přístupu do DBMS;
• omezení používání aplikačního softwaru konkrétním uživatelem.

Vzhledem k tomu, že organizační opatření a mechanismy pro omezování přístupu do podnikové sítě jsou podrobně popsány jak z hlediska metodologie, tak praktické implementace, stojí za to se podrobněji pozastavit nad úkoly ochrany přístupu do SŘB a omezeními používání aplikačního softwaru. . Nejprve si ale řekněme, jaké podmínky „zvýhodňují“ krádež informací.

Proč se informace kradou?

Pokusme se rozebrat možné důvody úspěšných pokusů o krádež informací uložených v podnikových databázích.

Prvním a hlavním důvodem je chybějící systematický přístup k hodnocení hrozeb. Bohužel v současné době jen malá část podniků uvádí do praxe mezinárodní zkušenosti a obecný přístup k hodnocení hrozeb podrobně popsaný v pracích Státní technické komise i doporučení k používání adekvátních prostředků ochrany informací.

V obecném případě je u podnikových databází jako objektu ochrany před neoprávněným přístupem obvyklé klasifikovat hrozby podle zdroje a dělit je na interní a externí. Zdrojem vnitřní hrozby mohou být legální uživatelé databází nebo interní hackeři, zdrojem vnější hrozby mohou být legální uživatelé podnikové sítě nebo externí hackeři.

Krádež informací z databáze je obvykle spojena s nelegálním jednáním uživatelů podnikové sítě, tedy s implementací interních hrozeb. Podle údajů z různých zdrojů se až 85 % krádeží informací a kompromitací dopouštějí legální uživatelé podnikového informačního systému a, což je obzvláště nepříjemné, správci DBMS nebo aplikačních systémů. Podíl interních (tj. registrovaných ve firemní síti) hackerů snažících se získat neoprávněný přístup k informacím podle různých odhadů tvoří až 15 % hrozeb, resp.

Externí hrozby neoprávněného přístupu k podnikovým datům jsou také rozděleny do dvou podtříd, z nichž externí hackeři tvoří až 20 % a legální uživatelé podnikové sítě – až 100 %.

Druhým důvodem je selhání ochrany heslem. Navzdory obrovskému množství publikací, že hesla neposkytují dostatečnou ochranu dat a aplikací, je tato metoda stále nejpoužívanější, a to především kvůli nulové ceně. Otázka selhání ochrany heslem je dostatečně podrobně zvažována například v pracích.

Nejnepříjemnější je, že tento přístup se často používá v daleko od malých organizací. A přístup k systémovým prostředkům několika různými uživateli pod stejným účtem je velmi běžná a dobře zavedená praxe. Pokud má například organizace pět systémových administrátorů, pak mohou mít všichni přístup se stejným heslem. Hříšnost takové organizace přístupu dobře ilustruje přirovnání s jízdou ulicemi velkého města v autech bez SPZ. Žádný dopravní policista v proudu „anonymů“ nebude schopen jednoznačně identifikovat auto překračující povolenou rychlost, pokud všichni jedou bez SPZ.

Třetím důvodem jsou neúplně používané prostředky ochrany informací a monitorování uživatelských akcí zabudované do DBMS, stejně jako neopodstatněné naděje na kvalifikaci vývojářů aplikačního softwaru z hlediska organizace systému správy přístupových práv. Kdo je skutečně odpovědný za používání/nepoužívání nástrojů informační bezpečnosti zabudovaných v DBMS? S největší pravděpodobností na vývojářích aplikačního softwaru, kteří implementují své systémy u zákazníků. Paradox však spočívá v tom, že drtivá většina vývojářů nemá ve svých řadách specialistu na informační bezpečnost a neví o běžných schopnostech organizovat ochranu SŘB. Podle nejkonzervativnějších odhadů je na ruském trhu několik tisíc aplikovaných systémů a softwarových produktů založených na využití průmyslových DBMS. Přitom se v drtivé většině případů má za to, že veškeré záležitosti spojené se zabezpečením dat si zajišťuje SŘB sám a přístup do IS probíhá pomocí hesla.

V důsledku nedostatečné pozornosti vývojářům aplikačního softwaru otázkám bezpečnosti se tak mechanismy ochrany informací implementované v samotném DBMS stávají extrémně důležitými. Navíc, jak je uvedeno výše, do systému může mít přístup několik osob s maximálními (administrativními) právy. Sledování akcí konkrétní osoby (jinými slovy personalizace těchto akcí) v takových podmínkách není možné. I když je možné lokalizovat únikový kanál, uživatel nepodléhá žádným, alespoň administrativním, postihům. Standardní argument narušitele je odkaz na skutečnost, že jeho heslo bylo vyzvednuto a někdo pod jeho jménem se dopustil protiprávního jednání.

Konečně posledním, ale významným důvodem je pachatelův přetrvávající pocit beztrestnosti. Praxe zavádění přísných předpisů a administrativních opatření bez nejpřísnější dokumentované kontroly bohužel nevede k znatelnému poklesu počtu porušení. Téměř všichni bezohlední zaměstnanci přistižení za ruku přiznali, že by se takového jednání nedopustili, kdyby věděli, že toto jednání bude monitorováno a hlavně personalizováno. Správnou úroveň ochrany důvěrných údajů lze proto dosáhnout pouze kombinací administrativních a technických opatření, podpořených softwarovými kontrolními a monitorovacími nástroji.

Vestavěné zabezpečení

Pokud vezmeme v úvahu bezpečnostní nástroje z hlediska přístupu k databázi, ukládání informací a přenosu po síti, pak je dnes jasnou jedničkou na trhu systémů pro správu databází Oracle DBMS. Poskytuje vývojářům softwaru a správcům aplikačních systémů celou řadu nástrojů a nástrojů potřebných k budování bezpečných systémů. Mezi nimi stojí za to zdůraznit následující:

Virtuální privátní databáze (VPD)- prostředky pro oddělení přístupu k datům na úrovni řádků (ve verzi 10g - i na úrovni sloupců) a možnost organizovat práci uživatele pouze s virtuální regulovanou částí dat, nikoli s reálnou databází;

Pokročilé zabezpečení Oracle- sadu nástrojů pro ověřování a zabezpečení sítě, včetně podpory protokolů pro bezpečný přenos dat, včetně SSL;

Oracle Label Security (OLS)- nástroje podobné VPD, ale s možností kontroly úrovně přístupu uživatele;

Fine Grained Audit Control (FGAC)- nástroj podrobného auditu.

Běžné prostředky Oracle + eToken

Ochrana klientského softwaru Oracle 9i DBMS pomocí elektronických klíčů eToken umožňuje radikálně zvýšit bezpečnost databázových aplikací. Ochranu bylo možné výrazně zvýšit použitím několika technologických řešení.

V první řadě byl způsob autentizace uživatele jménem a heslem nahrazen spolehlivější dvoufaktorovou autentizací pomocí digitálních certifikátů standardu X.509. A přestože vestavěné nástroje Oracle Advanced Security podporují ověřování digitálních certifikátů, otázka ukládání certifikátů a soukromých klíčů zůstává otevřená. Metody Oracle pro ukládání certifikátů ve formě kontejnerových souborů PKCS#12 nebo registru OS Windows mají řadu významných nevýhod. Podstatu schopností zabudovaných do Advanced Security ilustruje schéma pro ukládání certifikátů (obr. 1).

Rýže. 1. Schéma uložení digitálních certifikátů Oracle v architektuře Oracle Advanced Security pomocí eTokenu.

Například soubor kontejneru může být ukraden útočníkem, který má práva ke čtení odpovídajícího klíče registru nebo souboru kontejneru. Práce s DBMS je přitom povolena pouze uživateli, pro kterého byl vytvořen odpovídající kontejner a navíc je „připojen“ ke konkrétní pracovní stanici (kde se nachází soubor kontejneru). Pro zamezení těchto „průšvihů“ je nutné ukládat digitální certifikáty přímo do paměti elektronického klíče eToken a pro provádění kryptografických operací s privátním klíčem využít v něm zabudovaný kryptoprocesor s dodatečnou autorizací uživatelského PIN.

Kromě zvýšení spolehlivosti poskytuje autentizace eTokenem samozřejmě řadu výhod oproti tradiční metodě (přihlášení/heslo). Elektronický klíč v prvé řadě umožňuje uživateli různých aplikací „nikam“ neukládat a nepamatovat si potřebná jména a hesla. Znáte-li jeden PIN kód a vyberete si certifikát z navrženého seznamu, můžete s příslušnými právy a oprávněními přistupovat ke konkrétní databázi a z libovolné pracovní stanice.

Bezpečnostní administrátor zároveň získává další pohodlí v podobě centralizovaného řízení přístupu a kontroly nad prací systémových administrátorů. Všechny tyto možnosti správy poskytuje jediný nástroj – adresářová služba Oracle Internet Directory. Stávající aplikace dostávají „tváří v tvář“ adresářové službě jediný vstupní bod – jakýsi portál architektury klient-server. V tomto případě ve většině případů nejsou nutné změny v aplikačním softwaru.

architektonické prvky

Navržené řešení je založeno na použití digitálních certifikátů standardu X.509 a protokolu Secure Sockets Layer (SSL), který podporuje silnou dvoufaktorovou autentizaci uživatelů Oracle DBMS a také šifrování informací přenášených po síti mezi databázový server a klientská pracovní stanice (obr. 2). V tomto případě se jedná pouze o standardní nastavení DBMS a klienta Oracle, jak je popsáno v dokumentaci Oracle Advanced Security. Instalace služeb eToken na pracovní stanici umožňuje používat certifikáty na klíči pro autentizaci v Oracle DBMS (viz postranní panel "Oracle DBMS Authentication using eToken").

Rýže. 2. Architektura udělování přístupu.

Certifikáty a jejich přidružené soukromé klíče jsou uloženy v zabezpečené paměti eTokenu (je přístupná pouze kryptoprocesoru v něm zabudovanému). Pro provádění kryptografických operací se soukromým klíčem musí uživatel zadat PIN. Tento přístup umožňuje v praxi implementovat model organizace bezpečného uživatelského přístupu k datům (DBMS) pomocí digitálních certifikátů X.509 instalovaných v eTokenu ve dvou úrovních. Legální uživatelé podnikové sítě (například pod kontrolou doménového řadiče Windows 2000/2003) se mohou přihlásit do sítě (obr. 3) až po úspěšném dokončení procesu autentizace čipové karty, který zahrnuje předložení odpovídajícího certifikátu (první úroveň). Na druhém stupni ochrany mají oprávnění uživatelé podnikové sítě přístup k chráněným datům DBMS pouze po předložení příslušného certifikátu Oracle.

Rýže. 3. Dvouúrovňový model přístupu k chráněným datům pomocí digitálních certifikátů X.509.

Pojďme si to shrnout. Navržený způsob ochrany dat výrazně omezuje možnost krádeže informací. A v případě trestného činu poskytuje přiměřené důkazy pro uplatnění trestu, vždyť je vždy znám vlastník elektronického klíče a certifikátů v něm uložených.

1 - Obvykle jsou průmyslové DBMS třídy DB2 a Oracle certifikovány minimálně v bezpečnostní třídě C2.

2 - Podle řady zdrojů, včetně IDC. - Cca. vyd.

Příspěvek se zabývá některými z nejvýznamnějších požadavků legislativy na ochranu osobních údajů (OÚ). Jsou uvedeny obecné přístupy k ochraně databází řízených DBMS. Je uveden příklad ochrany PD zohledňující zákonné požadavky na platformu Oracle, jednu z nejpoužívanějších ve středních a velkých informačních systémech.

Zákon o ochraně osobních údajů není implementován. Proč?

Pro začátek si připomeňme některá ustanovení č. 152 spolkového zákona „O osobních údajích“.

Podle článku 3 zákona je „provozovatelem státní orgán, orgán obce, právnická osoba nebo fyzická osoba, která organizuje a (nebo) provádí zpracování osobních údajů, jakož i určující účely a obsah zpracování osobních údajů. " Dostáváme se tedy k závěru, ze kterého budeme vycházet: prakticky všechny právnické osoby Ruské federace jsou potenciálními provozovateli PD.

Zákon také výslovně uvádí, že zpracováním osobních údajů se rozumí téměř vše, co s nimi lze provádět, od obdržení údajů až po jejich depersonalizaci a likvidaci: „zpracování osobních údajů – úkony (operace) s osobními údaji, včetně jejich shromažďování, systematizace, shromažďování, uchovávání, upřesňování (aktualizace, změna), používání, distribuce (včetně přenosu), depersonalizace, blokování, zničení osobních údajů.

Kromě toho požadavky zákona „O ochraně osobních údajů“ č. 152-FZ obsahují některé, mírně řečeno, neobvyklé postupy pro ruské organizace, jako jsou:

• získání souhlasu občanů se zpracováním jejich osobních údajů, včetně (je-li to nutné) předání třetím stranám;
• stanovení složení OÚ pro každý informační systém, který zpracovává osobní údaje (ISPD);
• klasifikace ISPD podle objemu dat a bezpečnostních charakteristik v závislosti na posouzení možného poškození subjektů údajů;
• příprava a organizace pravidelných oznámení o zpracování osobních údajů pověřenému orgánu.

Všimněte si, že naprostá většina ruských organizací nemá v praxi takové požadavky splněny. Neexistují ani stanovena pravidla pro vzájemné vztahy založené na důvěře, je například extrémně vzácné sepsat nabídkovou smlouvu na souhlas s použitím osobních údajů občanů. Ale tento přístup je již dlouho úspěšně praktikován ve vyspělých zemích. A ještě jedna věc: i když by taková dohoda jasně definovala, jaké druhy zpracování osobních údajů konkrétní organizace povoluje a kdo konkrétně bude odpovědný za porušení dohodnutých druhů zpracování a kompromitaci osobních údajů, jen málo občanů rozhodl takovou dohodu uzavřít. V kontextu vágní dikce právní úpravy je zřejmé, že i kdyby občan udělil souhlas se zpracováním svých osobních údajů, v každém případě by byl zcela odkázán na to, jak rozumně a svědomitě by si provozovatel normy vyložil. zákona.

Je vhodné dodat, že podle některých informací zmíněnou klasifikaci a požadavky odpovídající každé třídě podle vládního nařízení č. 781 již vypracovaly FSTEC, FSB a Ministerstvo informací a komunikací Ruska a budou budou zveřejněny v blízké budoucnosti. Tento dlouho očekávaný dokument v mnoha ohledech osvětlí tyto a další aspekty praktické aplikace FZ-152. Ale hlavní naděje, které jsou s tím spojeny, jsou získání praktických návodů k realizaci požadavků zákona pro státní organizace, které zpracovávají osobní údaje občanů.

Obecně platí, že komerční struktury dlouhodobě chrání kritická obchodní data (například rejstřík akcionářů a další obchodní informace), včetně PD. Jen málo organizací však splňuje požadavky federálního zákona o obchodním tajemství a toto široké téma přesahuje rámec tohoto článku.

Státní organizace zase čekají na konkrétní pokyny a metody pro systémy ochrany budov v závislosti na třídě informačního systému a charakteru dat zpracovávaných tímto systémem. Chtěl bych doufat, že v blízké budoucnosti budou dokončeny a zveřejněny všechny potřebné dokumenty, což dá impuls k zahájení skutečné práce na ochraně osobních údajů.

Zákon je tvrdý, ale spravedlivý

Neméně zajímavé je, jaké možnosti zákon poskytuje samotným občanům – subjektům osobních údajů. Kromě výše uvedeného připomínáme další ustanovení zákona. Podle části 4 článku 14 federálního zákona-152 má subjekt osobních údajů právo obdržet na základě žádosti nebo po obdržení žádosti informace týkající se zpracování jeho PD, včetně: potvrzení skutečnosti, že osobní údaje je provozovatelem zpracovávána, jakož i účel tohoto zpracování; metody zpracování PD používané provozovatelem; informace o osobách, které mají přístup k PD; seznam zpracovávaných osobních údajů a zdroj jejich obdržení; podmínky zpracování PD včetně podmínek jejich uložení; informace o tom, jaké právní důsledky pro subjekt osobních údajů může mít zpracování jeho OÚ. Ve skutečnosti je to také nelehký úkol pro provozovatele, protože nikdo nezrušil článek 137 Trestního zákoníku Ruské federace „Narušení soukromí“ ze dne 13. června 1996. V článku se zejména uvádí, že trestní odpovědnost znamená: nezákonné shromažďování nebo šíření informací o soukromém životě osoby, které tvoří její osobní nebo rodinné tajemství, bez jejího souhlasu, nebo šíření těchto informací veřejným projevem, veřejně vystaveným dílem nebo hromadných sdělovacích prostředků, pokud byly tyto činy spáchány ze sobeckého nebo jiného osobního zájmu a způsobily újmu na právech a oprávněných zájmech občanů.

Podle článku 17 federálního zákona-152, pokud se subjekt PD domnívá, že provozovatel zpracovává jeho PD v rozporu s požadavky tohoto spolkového zákona nebo jinak porušuje jeho práva a svobody, má subjekt PD právo se proti žalobám odvolat. nebo nečinnosti provozovatele u oprávněného orgánu ochrany práv subjektů PD nebo u soudu. Osoby, které se provinily porušením požadavků, zároveň nesou správní, občanskoprávní, trestní a jinou odpovědnost stanovenou zákonem.

Zdá se velmi významné, že za implementaci bezpečnostních požadavků v systémech informační bezpečnosti jsou odpovědní vývojáři.

Zde jsou hlavní součásti systému státní kontroly a dozoru nad zajištěním bezpečnosti OÚ při jejich zpracování v IS:

• Rossvyazohrankultura - autorizovaný orgán ochrany práv subjektů PD;
• FSB - Federální výkonný orgán oprávněný v oblasti zajišťování bezpečnosti státu a používání šifrovacích nástrojů;
• FSTEC - federální služba pro technickou a exportní kontrolu a boj proti zahraničnímu zpravodajství - autorizovaný orgán v oblasti kontroly používaných technických prostředků ochrany;
• Ministerstvo informačních technologií a komunikací Ruské federace - postup pro klasifikaci informačních systémů obsahujících osobní údaje.

Vzniká tak promyšlený systém státní kontroly provozovatelů zpracovávajících osobní údaje.

Jak správně chránit databáze?

Opatření na ochranu osobních údajů se příliš neliší od obecně přijímaného přístupu k ochraně informací, omezeného přístupu. Integrovaný přístup k ochraně databází se tedy skládá z po sobě jdoucích fází, mezi nimiž jsou:

• stanovení adekvátního modelu ohrožení;
• odhad rizika;
• vývoj na něm založeného ochranného systému za použití metod poskytovaných pro odpovídající třídu informačních systémů (IS);
• kontrola připravenosti systémů informační bezpečnosti (IPS) s provedením příslušné dokumentace (popis systému, provozní řád, předpisy apod.), včetně závěrů o možnosti provozování tohoto IPS;
• Instalace a uvedení do provozu zařízení pro bezpečnost informací;
• účtování aplikovaných zařízení informační bezpečnosti, technické dokumentace k nim, jakož i nosičů PD;
• účtování osob přijatých k práci s PD v IS;
• vypracování kompletního popisu systému ochrany PD;
• kontrolu nad používáním IS.

Tradičně se přitom používají dvě složky budování systému informační bezpečnosti: provádět inventarizaci informačních zdrojů, určit jejich vlastníky, kategorizovat informace (včetně omezeného přístupu, v případě potřeby zavést režim obchodního tajemství), připravit a podepsat příkaz k provedení vypracovaných organizačních ochranných opatření, zdůvodnit a získat rozpočet, vybrat a proškolit personál, proškolit, organizovat rekvalifikace a ... to není vše.

Všechny tyto činnosti by měly být popsány a schváleny v regulační a administrativní dokumentaci. Velmi důležitá je přitom podpora managementu pro důslednou implementaci vypracované bezpečnostní politiky. Je zřejmé, že nejlepší praxí je, aby každý zaměstnanec podepsal samostatnou dohodu o práci s omezenými informacemi. V krajním případě musí být zaměstnanci bezpodmínečně poučeni, což musí být potvrzeno podpisem „seznámený“ s uvedením celého jména, funkce zaměstnance ve všech rozkazech a pokynech.

Přejděme k úvaze o technických prostředcích ochrany databáze obsahující osobní údaje podrobněji.

Hlavní součásti systému ochrany databází

Klasické schéma ochrany databáze (DB) je rozděleno do následujících povinných postupů:

• Řízení přístupu- každý uživatel včetně správce má přístup pouze k těm informacím, které potřebuje podle své pozice.
• Ochrana přístupu - přístup k údajům může získat uživatel, který prošel procedurou identifikace a autentizace.
• Šifrování dat- je nutné šifrovat jak data přenášená v síti pro ochranu proti odposlechu, tak data zapsaná na média pro ochranu proti krádeži média a neoprávněnému prohlížení/úpravě jinými prostředky než pomocí systému správy databází (DBMS).
• Audit přístupu k datům- akce s kritickými daty by měly být protokolovány. Přístup k protokolu by neměl být dostupný uživatelům, na kterých je udržován. V případě aplikací využívajících vícevrstvou architekturu probíhají i výše uvedené ochranné funkce, s výjimkou ochrany dat na médiu - tato funkce zůstává databázi.

Všechny tyto bezpečnostní funkce jsou do určité míry vybaveny Oracle DBMS a aplikacemi, což je příznivě odlišuje od konkurenčních produktů. Zvažme tyto postupy podrobněji.

Řízení přístupu

S cílem chránit databázi před hrozbami zevnitř, zajistit kontrolu přístupu ve verzi DBMS 10g Release 3, vydala společnost Oracle nový produkt Database Vault, navržený tak, aby zabránil neoprávněnému přístupu k uživatelským informacím, včetně těch se zvláštními pravomocemi, jako je např. správci databází. Sada pravidel v databázovém trezoru, která omezují přístup, je poměrně široká. Vedení organizace může například definovat pravidla, která vyžadují, aby byli dva zaměstnanci přítomni ve stejnou dobu, aby mohli provádět úkoly, které vyžadují přístup ke kritickým informacím. Database Vault tedy řeší následující problémy:

• omezení přístupu k údajům správce databáze a dalších privilegovaných uživatelů;
• zamezení manipulace s databázemi a přístupu k jiným aplikacím správce aplikací;
• poskytuje kontrolu nad tím, kdo, kdy a odkud může přistupovat k aplikaci.

Ochrana přístupu

Autentizace v kontextu Oracle znamená autentizaci někoho nebo něčeho – uživatele, aplikace, zařízení – kdo nebo co potřebuje přístup k datům, zdrojům nebo aplikacím. Po úspěšné autentizační proceduře následuje autorizační proces, který zahrnuje přiřazení určitých práv, rolí a privilegií subjektu autentizace.

Oracle poskytuje řadu metod ověřování a umožňuje vám používat jednu nebo více z nich současně. Společné pro všechny tyto metody je, že se jako předmět autentizace používá uživatelské jméno. Některé další informace, jako je heslo, mohou být vyžadovány k potvrzení jeho pravosti. Autentizace správců Oracle DBMS vyžaduje zvláštní postup, což je dáno specifickými pracovními povinnostmi a mírou odpovědnosti tohoto zaměstnance. Software Oracle také šifruje uživatelská hesla pro bezpečný přenos po síti.

Pojďme se tedy blíže podívat na metody ověřování v Oracle DBMS.

Autentizace pomocí operačního systému

Řada operačních systémů umožňuje Oracle DBMS využívat informace o uživatelích spravovaných samotným operačním systémem. V tomto případě má uživatel počítače přístup k databázovým zdrojům bez dodatečného zadání jména a hesla – použijí se jeho síťové přihlašovací údaje. Tento typ autentizace je považován za nezabezpečený a používá se hlavně k ověření správce DBMS.

Autentizace pomocí síťových služeb

Tento typ ověřování poskytuje server Oracle Advanced Security. Poskytuje následující služby:

1. SSL - autentizace používá protokol SSL (Secure Socket Layer) - protokol aplikační vrstvy. Lze jej použít pro autentizaci databáze a obecně (pokud se později použije autentizace uživatele pomocí DBMS) nezávisí na globálním systému správy uživatelů poskytovaného adresářovou službou Oracle - Oracle Internet Directory.

2. Autentizace službami třetích stran.

Na základě Kerberos. Použití Kerberos jako důvěryhodného autentizačního systému třetí strany je založeno na použití tzv. sdílené tajemství. To předurčuje bezpečnost a spolehlivost důvěryhodné strany a umožňuje použití Single Sign - On, centralizovaného ukládání hesel, transparentní autentizace pomocí databázových odkazů (databázových odkazů) a také vylepšených bezpečnostních nástrojů na pracovních stanicích.

založené na PKI. Použití PKI pro autentizaci zahrnuje vydávání digitálních certifikátů pro uživatele (aplikace), které se používají pro přímou autentizaci na databázových serverech v rámci stejné organizace. Nevyžaduje použití dalšího ověřovacího serveru. Oracle definuje následující komponenty pro použití PKI:

• protokol SSL
• sada funkcí OCI (Oracle Call Interface - rozhraní aplikace pro přístup k databázi) a PL / SQL
• důvěryhodné certifikáty, pro ověřování pravosti certifikátů předložených uživateli (aplikacemi)
• Peněženky Oracle - klíčové kontejnery obsahující soukromý klíč uživatele, jeho certifikát a řetězce důvěryhodných certifikátů
• Oracle AS Certificate Authority - komponenta Oracle Application Server určená k vydávání certifikátů a jejich další správě
• - Oracle Wallet Manager (OWM) - komponenta DBMS pro správu peněženky

založené na RADIUS. Oracle DBMS podporuje protokol RADIUS (Remote Authentication Dial - In User Service), standardní protokol pro ověřování vzdálených uživatelů. Zároveň se zpřístupňují služby a autentizační zařízení třetích stran, se kterými může RADIUS server komunikovat (například zařízení pro generování jednorázových hesel, biometrická zařízení atd.).

Na základě adresářové služby LDAP. Použití adresářové služby LDAP velmi zefektivňuje správu autentizace a správu uživatelských (aplikačních) účtů. V infrastruktuře Oracle DBMS je katalogová služba reprezentována následujícími komponentami:

• Oracle Internet Directory (OID) umožňuje centrálně ukládat a spravovat informace o uživatelích (tzv. podnikových uživatelích). Umožňuje mít jeden uživatelský účet pro mnoho databází. Je možná integrace s adresářovými službami třetích stran, jako je MS Active Directory nebo iPlanet. OID umožňuje flexibilní správu bezpečnostních atributů a oprávnění každého uživatele, včetně těch, které jsou ověřeny digitálními certifikáty. Pro zvýšení bezpečnosti při autentizačním procesu je možné použít protokol SSL.
• Oracle Enterprise Security Manager je nástroj pro správu uživatelů, skupin, rolí a oprávnění.

3. Autentizace ve vícevrstvých aplikacích

Výše uvedené metody autentizace lze také použít ve vícevrstvých aplikacích. Pro přístup k aplikacím z internetu se zpravidla používá autentizace pomocí uživatelského jména a hesla (včetně použití protokolu RADIUS) nebo protokolu SSL. Jiné metody se používají pro práci uživatelů v lokální síti.

Šifrování dat

Pro ochranu dat přenášených po síti v Oracle DBMS, počínaje verzí 8i, možnost se používá Oracle Advanced Security, která má funkci síťové šifrování, který umožňuje zašifrovat celý datový tok. Bezpečnost informací je zajištěna utajením klíče použitého k šifrování dat.

síťové šifrování umožňuje dosáhnout vysoké úrovně zabezpečení. Jsou podporovány následující šifrovací algoritmy AES (pouze 10g/11g). DES , 3 DES , RC 4 (pouze 10g / 11g).

Ochranu dat přenášených po síti v aplikacích Oracle zajišťuje protokol SSL s využitím algoritmů, které jsou podporovány aplikačním serverem, zpravidla se jedná o Oracle WEB server.

Ochranu dat na médiích zajišťují dvě součásti Oracle DBMS – balíčky, které implementují šifrovací algoritmy a možnost Transparency Data Encryption (TDE). Počínaje verzí 8i poskytuje Oracle DBMS vývojářům aplikací balíčky uložených procedur, které implementují algoritmy: DES s délkou klíče 56 bitů, Trojitý DES s délkou klíče 112 a 168 bitů , AES s délkou klíče 128, 192 a 256 bitů RC4(pouze 10g / 11g).

Volba TDE se objevil v Oracle DBMS 10g Release 2 jako součást pokročilé zabezpečení. Umožňuje selektivně šifrovat sloupce tabulek pomocí Triple DES (s délkou klíče 168 bitů), AES (s délkou klíče 128, 192 nebo 256 bitů). Šifrovací klíče jsou spravovány databázovým strojem a použití takového šifrování nevyžaduje změnu klientského a serverového aplikačního softwaru. Ve verzi DBMS 11g a vyšší bylo možné šifrovat celý tabulkový prostor.

Audit přístupu k datům

DBMS Věštec disponuje výkonnými nástroji pro audit uživatelských akcí, včetně přístupu k datům a událostí registrace / ukončení a změn ve struktuře databáze. Počínaje verzí 9i je DBMS vybaveno funkcí Fine Grained Audit Control, která umožňuje auditovat přístup podle podmínek stanovených poměrně flexibilními vlastními pravidly. Tyto nástroje auditu vám však neumožňují sledovat akce, které provádí správce databáze, a také mu nebrání změnit protokol auditu, odstranit jakékoli řádky a nezanechat po takových akcích žádné stopy. Objevila se potřeba auditovat aktivity a chránit auditovaná data před privilegovanými uživateli, včetně administrátorů databází Věštec vyvinout nový koncept auditu. Vychází z myšlenky, na které je funkce založena Databázový trezor: DBA je izolován od správy auditu, což ze zřejmých důvodů poskytuje vyšší úroveň zabezpečení databáze. Jako v případě Databázový trezor pravidla pro přidělení auditu Audit Vault velmi flexibilní.

Jsou vestavěné ochrany dostatečné?

Náš stručný přehled nástrojů pro bezpečnost informací, které společnost Oracle Corporation zabudovala do svých produktů a technologií, ukazuje pevný základ pro budování IS s různými úrovněmi zabezpečení, které splňují nejnovější bezpečnostní požadavky. I letmý pohled na bezpečnostní systémy různých softwarů využívajících DBMS nebo aplikační server Oracle však ukáže, že až na vzácné výjimky se vestavěné bezpečnostní nástroje buď nepoužívají vůbec, nebo jsou nahrazeny proprietárním vývojem podobným např. funkčnosti nebo hotového vývoje nabízeného na trhu, případně vestavěné nástroje jsou doplněny softwarem třetích stran.

V podstatě se jedná o tři přístupy tuzemských firem k problematice informační bezpečnosti obecně a k ochraně databází před stále rostoucími hrozbami zejména.

Bohužel stojí za to uznat, že první přístup je nejběžnější a zahrnuje použití nejjednoduššího ověření hesla, autorizace a šifrování dat.

Od zastánců tohoto přístupu při vývoji a provozu IS lze nejčastěji slyšet tyto argumenty:

• nejjednodušší, a proto provozně spolehlivější;
• nízké náklady na vlastnictví;
• není vyžadována vyšší úroveň ochrany.

Ochrana heslem samozřejmě nevyžaduje dodatečné náklady ani ve fázi vývoje, ani ve fázi provozu IS - veškeré „starosti“ o obsluhu uživatelů a jejich hesel přebírá DBMS nebo aplikační server. Rovněž nevznikají žádné náklady na další hardware (ověřovací servery, adresářové služby, klíčová úložiště atd.) a software (licence, software třetích stran atd.). Důležité také je, že kvalifikační požadavky na správce databází a bezpečnostní správce jsou v tomto případě mnohem nižší a jde také o hospodárnost. Třetí argument se zdá být historicky zachován z doby, kdy se bezpečnostní otázky vážně neřešily.

Ochranné systémy postavené podle druhého přístupu jsou o něco méně běžné. Částečně se na ně převádějí systémy z první možnosti, kdy si například zákazníci takového systému, unavení „nízkými“ náklady na vlastnictví ochrany heslem, objednají vývojáře nebo si koupí hotový systém správy hesel. Stává se, že pravidelné skandály krádeží dat vás nutí dělat softwarové „fleky“ na hotovém systému pro implementaci šifrování, často pomocí vašich vlastních „superodolných“ algoritmů.

Důvody pro takový přístup jsou zhruba následující: vestavěné ochrany jsou zjevně nedostatečné a plné zranitelností;

• je lepší jednat s „místním“ vývojovým týmem, než se spoléhat na podporu dodavatele;
• systém funguje normálně s ochranou heslem a je lepší se ho nedotýkat, stačí implementovat další software pro správu hesel.

Výše uvedené dvě možnosti využití ochranných nástrojů jsou typické pro IS vyvíjené a implementované především koncem 90. let minulého století. Typickým příkladem jsou billingové systémy, které samostatně vyvíjejí desítky firem. Neméně nápadným příkladem jsou databáze zdravotnických a donucovacích orgánů. Obsahují však působivé množství důvěrných informací a zejména osobních údajů, které musí být podle ruského práva spolehlivě chráněny. Je takový nedbalý přístup k ochraně databází s osobními údaji občanů důvodem, proč se mezi pirátskými kopiemi filmů neustále objevují sbírky databází fyzických a právnických osob? Odpověď na tuto otázku je třeba hledat především na základě nedostatků popsaných přístupů. Pokusme se analyzovat zastánce těchto přístupů.

Je ověření heslem dostatečné?

O snadném použití ochrany heslem není pochyb. Ale jednoduchost a spolehlivost ochrany jsou v tomto případě nekompatibilní. Z hlediska bezpečnosti a snadného použití se tato technologie stává zastaralou. Síla hesla a následně i bezpečnost jeho použití přímo závisí na jeho kvalitě (použité znaky, jejich velikost, odlišnost od smysluplných slov). A použitelnost rapidně klesá i s mírným zvýšením „bezpečnosti“ hesla, protože zapamatovat si nečitelnou kombinaci znaků je dost obtížné. Pojďme k faktům a číslům. Uživatelská hesla jsou uložena v Oracle DBMS jako hodnoty hash a jsou čitelná pro privilegované uživatele. Algoritmus výpočtu hash hesla je již dlouho znám. Nejkomplexnější studii síly hesla v Oracle provedla společnost Červená - Databáze - Security GmbH - přední světový odborník na bezpečnost produktů Oracle. Zde jsou některé údaje o síle hesla pro DBMS verze 7-10g:

Na počítači s Pentiem 4 3 GHz je požadovaný čas (útok hrubou silou):

• 10 sekund všechny kombinace 5 znaků
• 5 minut všechny kombinace 6 znaků
• 2 hodiny všechny kombinace 7 znaků
• 2,1 dne všech 8 kombinací znaků
• 57 dní všech 9 kombinací znaků
• 4 roky všech 10 kombinací znaků

A to při použití daleko od nejvýkonnějšího počítače. S rostoucím výkonem jsou slovníkové útoky ještě rychlejší. Tím neříkám, že Oracle na tento stav nereaguje – ve verzi DBMS 11g se situace výrazně zlepšila. Byl posílen algoritmus generování hash a kvalita generování hesel. V důsledku toho se výše uvedená čísla zvýšila 2,5-3krát. Ale i přes tato vylepšení Oracle doporučuje používat silné autentizační nástroje, které byly také vylepšeny, například bylo možné použít HSM (Hardware Security Module) pro autentizaci a ukládání šifrovacích klíčů.

Docházíme tedy k závěru, že spolehlivost a bezpečnost používání hesel k ochraně IP již nyní přestala vyhovovat požadavkům společností, které na jedné straně dbají o svou pověst a na straně druhé jsou povinny plnit požadavky aktuální legislativa.

Nízké náklady na vlastnictví – mýtus?

Rozšířená mylná představa. Statistiky potvrzují fakta o značných nákladech na údržbu, řekněme, zapomenutých hesel. Ještě hmatatelnější ztráty vznikají společnostem kvůli nízké spolehlivosti a bezpečnosti ochrany heslem.

Jsou vestavěné ochrany zranitelné?

A v této věci se opět setkáváme s konvenční moudrostí, že běžné bezpečnostní nástroje jsou nedostatečné. Jak vysvětlit vznik takového názoru, zejména s ohledem na skutečnost, že vestavěné ochranné nástroje jsou nejčastěji využívány zdaleka ne 100%. T

Pokud jde o zranitelnosti vestavěných ochran v Oracle, situace je zde úplně stejná jako v jiných komplexních systémech. Společnost Oracle Corporation tradičně zodpovídá za nalezení a opravu nalezených zranitelností. Pravidelně (4x ročně) jsou vydávány aktualizace CPU (Critical Patch Updates), které odstraňují mezery objevené jak samotným Oraclem, tak desítkami dalších společností, z nichž nejznámější je již zmíněná Red - Database - Security GmbH. Takže například v říjnu 2007 bylo odstraněno 27 zranitelností v DBMS v CPU, 11 v aplikačním serveru a 13 v různých aplikacích. Vzhledem k počtu produktů Oracle, jejich verzím a jejich softwarovým a hardwarovým platformám to není tolik.

Vlastní vývoj versus podpora dodavatele

Existuje mnoho názorů na tuto problematiku. Některé organizace preferují mít vlastní vývojové týmy, některé ne. Snad nejpřesvědčivějším argumentem ve prospěch podpory prodejců je, že ne každá společnost si může dovolit mít ve vývojovém oddělení specialisty na informační bezpečnost.

I když však takové zdroje existují, je třeba mít na paměti, že „samo psaný“ systém do značné míry závisí na vývojovém týmu, který se podílel na jeho návrhu a tvorbě. To znamená, že jejich úroveň profesionality, jejich kvalifikace jsou rozhodující z hlediska kvality vývoje, absence chyb zabudovaných v softwaru a zranitelnosti, kterých mohou externí útočníci využít. Navíc „sama psaná“ řešení jsou zatížena skutečností, že odchod jednoho nebo více klíčových „autorů“ těchto řešení může s sebou nést rizika spojená se správnou podporou a rozvojem dříve vytvořené infrastruktury novými specialisty.

Pojďme si tedy shrnout průběžné výsledky. Hlavní argumenty uváděné obhájci přístupů, které jsme vyjmenovali – vestavěné ochranné nástroje se nepoužívají a „vlastně psané“ nástroje jsou spolehlivější než ty běžné – ve skutečnosti nemají žádné vážné důvody. A společnosti, které se řídí těmito možnostmi ochrany svých databází, účinně vystavují citlivé informace obsažené v databázi riziku krádeže a úniku.

Příležitosti k posílení ochranných funkcí: kdy je to nutné?

Výše uvedený příklad o ochraně databází různých sociálních institucí je vlastně velmi orientační. Přeci jen se bavíme o státním podniku, který přímo souvisí s dodržováním na jedné straně zájmů státu, na straně druhé zájmů občanů. Prioritou číslo jedna se tak stává otázka ochrany uchovávaných a zpracovávaných dat kolujících v informační infrastruktuře této instituce. A v tomto případě může být maximální využití schopností standardních ochranných nástrojů v řešeních spolehlivých prodejců stále nedostatečné. Požadavek na zvýšenou ochranu státních podniků je spojen jednak se zaváděním technologií pro vyšší úroveň zabezpečení, jednak s plněním zákonných požadavků, zejména používání výhradně certifikované ochranné prostředky.

V poslední době proto začíná nabírat na obrátkách třetí „smíšený“ přístup k ochraně informačních systémů. Pokud analyzujeme typické požadavky na ochranu IP a možnosti, které lze implementovat pomocí vestavěných nástrojů Oracle, můžeme okamžitě zdůraznit, co by mělo být doplněno:

Algoritmy ruské kryptografie (PKI, EDS, šifrování v síti a na médiích)

Implementace šifrování při zápisu na média bez použití TDE

Skladování klíčového materiálu.

Vývojáři Oracle ze zřejmých důvodů neposkytli univerzální implementaci těchto dvou bodů, i když poskytli některé obecné přístupy.

Aplikace domácích kryptografických algoritmů

Kryptografické algoritmy lze použít v procesu autentizace, generování EDS (GOST R 34.10-2001), k ochraně komunikačního kanálu (GOST 28147-89, GOST R 34.11-94) a šifrování dat (GOST 28147-89). Vestavěné nástroje Oracle neimplementují tyto algoritmy ani v DBMS, ani v aplikačním serveru, ani v aplikacích. Implementaci kryptografie ve formě knihoven, standardních poskytovatelů kryptografie (CSP), vývojářských sad (SDK) nabízí několik ruských výrobců - CryptoPro, Signal-Com, Infotex, Lissy, CryptoCom, CryptoEx atd. Jde však spíše o problematické, aby produkty Oracle fungovaly s navrhovanými knihovnami. Nejde ani o to, že tyto nástroje nejsou kompatibilní na úrovni softwaru a hardwaru – zabudování kryptografie do produktů Oracle by nemělo porušovat licenční smlouvu dodavatele týkající se integrity softwaru. Pokud u IS postaveného na bázi aplikačního serveru Oracle nebo celé sady Oracle aplikací zpravidla problémy s embedováním nejsou, pak u DBMS je situace složitější. Vzhledem k tomu, že jádro DBMS nemá programovací rozhraní pro krypto operace (autentizace, šifrování), je třeba použít náhradní řešení. Použijte například ověřovací protokol Kerberos nebo generátory jednorázových hesel s protokolem RADIUS a chraňte komunikační kanál pomocí certifikovaného softwaru.

Šifrování dat bez použití TDE

Navzdory extrémní jednoduchosti možnosti Oracle TDE je často nutné její použití opustit. Existují dva hlavní důvody:

Některé datové typy nejsou podporovány

Není zde možnost pravidelně používat ruské kryptoalgoritmy

Neexistuje žádná skutečná ochrana proti privilegovaným uživatelům.

První problém je v zásadě vyřešen pomocí produktů třetích stran - DbEncrypt pro Oracle (Application Security, Inc.), eToken SafeData (Aladdin Software Security R . D.), Průvodce šifrováním pro Oracle (Relational Database Consultants, Inc.). Druhý problém je v zásadě vyřešen stejným způsobem, ale existuje méně možností - eToken SafeData nebo Průvodce šifrováním pro Oracle. Navíc u prvního produktu je nutná dodatečná montáž verze (v závislosti na použitém certifikovaném výrobci kryptografie) a u druhého produktu jsme prostě nenašli potřebné informace. Třetí problém by se v zásadě dal vyřešit sdílením možností TDE A Oracle Database Vault, ale v tomto případě oprávnění správce DBMS plynule přechází na správce Database Va u lt, tzn. problém ochrany před privilegovanými uživateli zůstává.

Skladování klíčového materiálu

Klíčový materiál (certifikáty, soukromé klíče, šifrovací klíče) používaný vestavěnými bezpečnostními nástroji Oracle k ověřování nebo šifrování dat je uložen v kontejnerech klíčů (tzv. peněženkách) jako běžné soubory. Pro přístup k informacím v peněžence je vyžadováno heslo. Tento způsob ukládání často nesplňuje požadavky na zabezpečení, zejména na klientských pracovních stanicích. Oracle DBMS od verze 10g umožňuje ukládat soukromé klíče na hardwarových zařízeních, která podporují standard PKCS # 11. Oracle zároveň nezaručuje provoz jiných hardwarových zařízení než produkčních zařízení. nCipher (nCipher Corporation Ltd.). To není vždy přijatelné, například pokud má být použit pouze certifikovaný hardware. A v tomto případě lze problém s ukládáním klíčů a certifikátů vyřešit pomocí řešení třetích stran. Na ruském trhu je snad jediný produkt ve své třídě eToken SecurLogon pro Oracle (Aladdin Software Security R.D.).

Závěr

Navzdory vědomému pochopení problému, který nastolili jak zákonodárci, tak vládní a komerční organizace, osobní údaje stále podléhají únikům informací, jejichž škody se někdy odhadují na velmi působivá čísla. Absenci významných precedentů lze vysvětlit latencí trestných činů v této oblasti. K únikům ale dochází neustále a dříve či později se proti vykrádání databází rozjede totální boj na státní úrovni. Samozřejmě můžete použít necertifikovaná řešení, můžete použít nelicencovaný software a znovu vynalézt kolo sami, ignorovat osvědčená průmyslová řešení... Ale pouze v tomto případě by si organizace měly uvědomit, že všechna další rizika – od finančních po reputační – spojená s používáním takových produktů také plně přebírají. Existují hrozby a jsou zde důsledky. Organizace přijímají ten či onen přístup k zajištění bezpečnosti informačních zdrojů a buď riskují, nebo si pro sebe vytvářejí nejbezpečnější podmínky.

V současné době jsou požadavky spotřebitelů na bezpečnost poměrně vysoké a optimálním řešením je plně využít vestavěné bezpečnostní nástroje a inteligentně je doplnit produkty a řešeními třetích stran. Touha vybudovat spolehlivou IP ochranu však často spočívá na banálním nedostatku kvalifikovaného personálu – vývojářů, analytiků, techniků technické podpory, konzultantů. Důsledkem toho je špatná znalost schopností vestavěných bezpečnostních prvků Oracle a dalších systémů a jejich správného používání. Dalším důsledkem je stejná situace, ale ve vztahu k produktům jiných výrobců softwaru a hardwaru pro bezpečnost informací a jejich použití ve spojení s technologiemi a produkty Oracle. Výsledkem je, že stávající systémy nadále používají zastaralé systémy ochrany heslem, získávají zbytečné úpravy a hromady dalších předpisů, a co je horší, vyvíjejí se nové IS se starými ochrannými technologiemi. Východiskem z této situace je především vyškolit personál s odbornými znalostmi v samotné informační bezpečnosti, v produktové řadě Oracle a schopný integrovat vývoj ruských společností s vestavěnými bezpečnostními nástroji. Taková příprava by měla začít již na specializovaných univerzitách a specialisté v této oblasti by měli mít možnost zvýšit své zkušenosti a dovednosti ve školicích centrech. Rád bych v této věci viděl podporu jak ze strany společnosti Oracle, tak ze strany dalších výrobců působících na ruském trhu informační bezpečnosti.

V tomto ohledu je podle našeho názoru velmi povzbudivým trendem vznik skutečných řešení, metod a přístupů k organizaci systémů informační bezpečnosti vyvíjených tuzemskými společnostmi společně s ruskými zastoupeními západních korporací. Taková spolupráce umožňuje zajistit nejen stabilní výkon ochranných mechanismů jako součásti informačního systému, ale také soulad těchto řešení s požadavky ruské legislativy.

Prostředky ochrany databáze v různých DBMS se od sebe poněkud liší. Na základě analýzy moderních DBMS Borland a Microsoft lze tvrdit, že nástroje ochrany databází jsou podmíněně rozděleny do dvou skupin, základní a doplňkové.

Mezi hlavní prostředky ochrany informací patří následující prostředky:

Ochrana heslem;

Šifrování dat a programů;

Zřízení přístupových práv k databázovým objektům;

Ochrana polí a záznamů databázových tabulek.

Ochrana heslem představuje jednoduchý a efektivní způsob ochrany databáze před neoprávněným přístupem. Hesla nastavují koncoví uživatelé nebo správci databáze. Účtování a ukládání hesel provádí DBMS sám. Hesla jsou obvykle uložena v určitých systémových souborech DBMS v zašifrované podobě. Proto je nemožné jednoduše najít a určit heslo. Po zadání hesla má uživatel DBMS všechny možnosti pracovat s chráněnou databází.

Šifrování dat(celá databáze nebo jednotlivé tabulky) slouží k zabránění čtení dat jiným programům. Šifrování zdrojových textů programů umožňuje skrýt před neoprávněným uživatelem popis odpovídajících algoritmů.

Aby bylo možné řídit používání základních prostředků DBMS, mnoho systémů má prostředky pro zřízení přístupových práv k databázovým objektům . Přístupová práva určují možné akce s objekty. Veškerá práva má vlastník objektu (uživatel, který objekt vytvořil) i správce databáze. Ostatní uživatelé mohou mít různé úrovně přístupu k různým objektům.

Ve vztahu k tabulkám lze obecně poskytnout následující přístupová práva.

Prohlížení (čtení) dat;

Změna (editace) dat;

Přidávání nových záznamů;

Přidávání a mazání dat;

Veškeré operace včetně změny struktury tabulky.

Data dostupná v tabulce lze chránit proti jednotlivým polím a jednotlivým záznamům. V relačních DBMS nejsou jednotlivé záznamy speciálně chráněny.

S ohledem na ochranu dat v polích tabulky lze rozlišit následující úrovně přístupových práv:

Úplný zákaz přístupu;

Pouze čtení;

Povolení všech operací (prohlížení, zadávání nových hodnot, mazání a změna).

Ve vztahu k formulářům lze zajistit dvě hlavní operace: výzvu k práci a rozvoj (výzva konstruktéra). U obrazovkových formulářů hotových aplikací je vhodné zakázat volání Constructoru, aby koncový uživatel aplikaci omylem nezkazil. V samotných formách obrazovky lze chránit i jednotlivé prvky. Některá pole zdrojové tabulky mohou například chybět nebo jsou pro uživatele vůbec skrytá a některá pole mohou být pouze pro zobrazení.

Přehledy jsou v mnoha ohledech podobné obrazovkám, s následujícími výjimkami. Za prvé neumožňují měnit údaje v tabulkách a za druhé je jejich hlavním účelem tisk informací. Zprávy, stejně jako formuláře na obrazovce, mohou mít zakázáno volat jejich vývojové nástroje.

Pro vyloučení prohlížení a modifikace (náhodné či úmyslné) programových textů používaných v DBMS aplikacích lze kromě šifrování využít jejich ochranu heslem.

Mezi další nástroje ochrany databází patří ty, které nelze přímo přiřadit k nástrojům ochrany, ale které přímo ovlivňují zabezpečení dat. Jedná se o následující nástroje:

Vestavěné ovládací prvky pro datové hodnoty podle typů;

Zvýšení spolehlivosti vstupních dat;

Zajištění integrity propojení tabulek;

Sdílení databázových objektů v síti.

Při úpravě databáze může uživatel omylem zadat hodnoty, které neodpovídají typu pole, do kterého se tato hodnota zadává (například zadání textové informace do číselného pole). V tomto případě používá DBMS hodnotové kontroly blokuje vstup a informuje uživatele o chybě.

Prostředky ke zlepšení spolehlivosti vstupních hodnot v DBMS slouží k hlubší kontrole související se sémantikou zpracovávaných dat. Obvykle poskytují možnost zadat následující omezení hodnot při vytváření tabulky: minimální a maximální hodnoty, výchozí hodnota (pokud neexistuje žádný vstup), požadovaný vstup; nastavení vstupní masky (šablony) atd.

Dokonalejší formou organizace kontroly nad spolehlivostí informací v databázi je vývoj uložených procedur. Mechanismus uložených procedur se používá v databázích hostovaných na serveru. Samotné uložené procedury jsou programy, jejichž algoritmy zajišťují provádění určitých funkcí (včetně řídicích) na datech. Procedury jsou ukládány společně s daty a v případě potřeby jsou volány z aplikací nebo při výskytu určitých událostí v databázi.

Řešení aplikovaného problému zpravidla vyžaduje výběr informací z několika tabulek. Tabulky v databázi lze propojit. Funkce údržby logická integrita propojených tabulek přebírá DBMS. Pokud DBMS tyto funkce neimplementuje, pak za správnost odkazů odpovídá aplikace.

Uveďme příklad možných akcí DBMS pro řízení integrity propojení tabulek. Nechť existuje vztah mezi dvěma tabulkami tvaru 1.M, a proto jednomu záznamu hlavní tabulky může odpovídat několik záznamů pomocné tabulky.

Při vkládání záznamů do pomocné tabulky systém kontroluje přítomnost odpovídajících hodnot v poli odkazu hlavní tabulky. Pokud vstupní hodnota není v hlavní tabulce, DBMS dočasně zablokuje práci s novým záznamem a nabídne změnu hodnoty nebo smazání celého záznamu.

Mazání záznamů z dodatkových tabulek není kontrolováno. Po odstranění záznamu z hlavní tabulky dojde ke kontrole. V případě, že je záznam hlavní tabulky spojen s několika záznamy doplňkové tabulky, jsou možné dvě chování. Nemažte kmenový záznam, pokud existuje alespoň jeden podřízený záznam (záznamy musí smazat uživatel), nebo odstraňte kmenový záznam a všechny podřízené záznamy (kaskádové mazání).

V distribuovaných informačních systémech, které pracují s databázemi, existuje problém řešení konfliktů mezi různými akcemi na stejných objektech ( sdílení objektů DB). Co například dělat v případě, kdy jeden z uživatelů lokální sítě upravuje databázi a druhý chce změnit její strukturu? Pro takové situace by měl DBMS poskytovat mechanismy pro řešení konfliktů.

Zámky se obvykle používají, když je více uživatelů současně online. Zámky může působit na různé databázové objekty a na jednotlivé prvky objektů. K uzamčení objektů dochází, když je souběžně s používáním objektu učiněn pokus o vstup do vývojového režimu stejného objektu. Ve vztahu k databázovým tabulkám může docházet k dalším zámkům při práci s jednotlivými záznamy nebo poli.

Zámky mohou být explicitní nebo implicitní. Explicitní zámky zavádí uživatel nebo aplikace prostřednictvím příkazů. Implicitní zámky jsou organizovány samotným systémem, aby se předešlo možným konfliktům. Například v případě pokusu o změnu struktury databáze při editaci informací je nastaven zákaz restrukturalizace databáze do doby dokončení editace dat.