Ohrožení informační bezpečnosti databází. Metody ochrany databáze a zabezpečení

Moderní DBMS podporují jeden ze dvou nejběžnějších přístupů k problematice bezpečnosti 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 má vlastníka – 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 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).

V Oracle DBMS používá jednobázovou architekturu, takže je tam zaveden koncept podschéma – části obecné schéma databázi a zadává jej uživatel, který má přístup k podschématu.

V 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.

V 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(<список действий>| VŠECHNA PRIVILEGIS)

NA<имя_объекта>ŽE (<имя_пользователя>

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, trigger.

<имя_пользователя>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 userS. 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 Tab (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][.DELETE][,UPDATE (<список столбцов»)]}

NA<имя таблицы»

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

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

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 uvedena ve sloupci COST tabulky TaB. 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 kartě uživateli3

Pokud náš uživatel userl předpokládá, že ho v případě jeho nepřítomnosti může nahradit uživatel4, 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živatelský operátor, user5 on mu může přidělit práva k zadávání nových řádků do tabulky příkazem

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, UPDATE, DELETE

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ělování práv pro práci s tabulkami může být účinnou metodou ochrany dat 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, nejsou u těchto pohledů povoleny operace úprav, a proto pro takové pohledy

zobrazení, je sada platný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}

NA<имя_объекта>

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 PRIVILEGIÍ

TO user4 CASCADE

oprávnění uživatele user, kterému se user4 podařilo 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 PRIVILEGIÍ

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:

TO uživatel2, uživatel4 KASKÁDA

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.

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, ZMĚNIT TABULKU.

DROP TABLE ON DB_LIB TO userl

V V tomto případě může uživatel vytvářet, upravovat nebo mazat tabulky v databázi DB_LIB, ale nemůže dovolit jiný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 U některých DBMS lze uživateli udělit 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 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 na tabulce, 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á i 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 systému ochrany v MS SQL Server

SQL Server 6.5 podporuje 3 režimy kontroly při určování uživatelských práv:

1. Standardní (standardní).

2. Integrované (integrované zabezpečení).

3. Smíšené (smíšené).

Výchozí režim zabezpečení vyžaduje, aby každý uživatel měl účet jako uživatel domény serveru NT. Uživatelský účet domény obsahuje uživatelské jméno a individuální heslo. Doménové uživatele lze spojovat do skupin. Jako uživatel domény má uživatel udělen přístup k určitým prostředkům domény. SQL Server je považován za jeden z prostředků domény. Ale pro přístup k SQL Serveru musí mít uživatel uživatelský účet MS SQL Server. Tento účet musí také obsahovat jedinečné uživatelské jméno a heslo serveru. Při připojování k operačnímu prostředí uživatel zadá své doménové uživatelské jméno a heslo. Při připojování k databázovému serveru uživatel zadá své jedinečné uživatelské jméno a heslo pro SQL Server.

Integrovaný režim předpokládá, že uživateli je přidělen pouze jeden účet v operačním systému jako uživatel domény a SQL Server identifikuje uživatele podle jeho dat v tomto účtu. V tomto případě si uživatel nastaví pouze jedno uživatelské jméno a jedno heslo.

V v případě smíšeného režimu mohou být někteří uživatelé připojeni k serveru pomocí standardního režimu a někteří pomocí integrovaného režimu.

V MS SQL Server 7.0 ponechal pouze 2 režimy: integrovaný, nazývaný režim ověřování Windows NT (ověření Windows NT) a smíšený, smíšený režim (ověření Windows NT a ověřování SQL Server). Algoritmus pro kontrolu autentizace uživatele v MS SQL Server 7.0 je znázorněn na Obr. 13.1.

Rýže. 13.1. Algoritmus pro kontrolu autentizace uživatele v MS SQL Server 7.0

Při pokusu o připojení k databázovému serveru nejprve zkontroluje, jaká autentizační metoda je pro daného uživatele definována. Pokud je definován režim ověřování Windows NT, pak zkontroluje, zda má daný uživatel domény přístup k prostředku SQL Server, pokud ano, pokusí se připojit pomocí uživatelského jména a hesla definovaného pro uživatele domény; pokud má tento uživatel práva pro připojení k SQL Server, pak připojení proběhne úspěšně, jinak uživatel obdrží zprávu, že tento uživatel se nemůže připojit k SQL Serveru. Při použití ověřování ve smíšeném režimu SQL Server postupně kontroluje uživatelské jméno (login) a jeho heslo (heslo); pokud jsou tyto parametry správně nastaveny, připojení proběhne úspěšně, v opačném případě uživatel obdrží také zprávu o nemožnosti připojení k SQL Serveru.

U Oracle DBMS se pro práci s databázovým serverem vždy kromě uživatelského jména a hesla v operačním prostředí používá jeho uživatelské jméno a heslo.

Kontrola autorizace

Druhým úkolem při práci s databází, jak již bylo zmíněno, je kontrola oprávnění uživatelů. Uživatelská oprávnění jsou uložena ve speciálních systémových tabulkách a během každé operace je kontroluje jádro DBMS. Logicky je pro každého uživatele a každý objekt v databázi vytvořena nějaká podmíněná matice, jako by to bylo, kde jsou objekty umístěny podél jedné dimenze a uživatelé jsou umístěni podél druhé. Na průsečíku každého sloupce a každého řádku je seznam povolených operací pro daného uživatele na daném objektu. Na první pohled se tento ověřovací model zdá být poměrně robustní. Ale problém nastává, když používáme nepřímý přístup k objektům. Například uživatel user_N nemá povolen přístup k tabulce Tab1, ale tento uživatel může spustit uloženou proceduru SP_N, která provede výběr z tohoto objektu. Ve výchozím nastavení jsou všechny uložené procedury spuštěny pod jménem jejich vlastníka.

Takové problémy by měly být řešeny organizačními metodami. Při povolování přístupu některým uživatelům si musíte být vědomi možnosti nepřímého přístupu.

V každém případě problém ochrany nikdy nebyl čistě technickým úkolem, jde o soubor organizačních a technických opatření, která by měla zajistit maximální důvěrnost informací uložených v databázi.

Navíc při práci v síti stále existuje problém s ověřováním přihlašovacích údajů.

Tento problém je následující. Řekněme, že proces 1 má oprávnění pracovat s databází a proces 2 taková oprávnění udělena nemá. Proces 2 pak nemůže přímo přistupovat k databázi, ale může přistupovat k procesu 1 a přistupovat k informacím z databáze přes něj.

Proto v zabezpečeném prostředí musí existovat model ověřování, který ověřuje identity nárokované uživateli nebo procesy. Pověřovací údaje se staly ještě důležitějšími s rozmachem distribuovaných počítačů. Při stávající vysoké úrovni konektivity výpočetních systémů je nutné řídit všechna volání do systému.

Problémy s autentizací jsou obvykle klasifikovány v oblasti komunikace a zabezpečení sítě, takže se jimi zde nebudeme dále zabývat, s výjimkou následující poznámky. V holistickém počítačovém bezpečnostním systému, kde je přesné provedení programu ochrany informací zajištěno interakcí vhodných nástrojů v operačních systémech, sítích, databázích, autentizace přímo souvisí s bezpečností databáze.

Všimněte si, že model zabezpečení založený na základních mechanismech ověřování a ověřování neřeší problémy, jako jsou odcizení identity a hesla uživatelů nebo škodlivé činy některých uživatelů s oprávněním – například když programátor pracuje na účtu, který má plný přístup k účtování databáze, vloží do kódu programu trojského koně za účelem odcizení nebo záměrné změny informací uložených v databázi. Takové otázky jsou mimo náš rozsah

diskuzi o nástrojích zabezpečení databází, ale přesto je třeba chápat, že program zabezpečení informací by měl zahrnovat nejen technické oblasti (jako je ochrana sítí, databází a operačních systémů), ale také otázky fyzické bezpečnosti, personální spolehlivost (skryté kontroly), audit, různé manuální nebo částečně automatizované postupy údržby zabezpečení.

Generalizovaná architektura DBMS

Zvažovali jsme některé aspekty práce DBMS. Nyní se pokusíme stručně shrnout vše, co jsme se naučili, a postavit nějakou podmíněnou zobecněnou strukturu DBMS. Na Obr. 14.1 ukazuje takovou strukturu. Zde je podmíněně ukázáno, že DBMS musí spravovat externí paměť, ve které jsou umístěny datové soubory, log soubory a soubory systémového katalogu.

Na druhou stranu, DBMS také spravuje RAM, která obsahuje datové buffery, log buffery, data systémového katalogu, která jsou nezbytná pro udržení integrity a kontrolu uživatelských oprávnění. Kromě toho RAM během provozu DBMS obsahuje informace, které odpovídají aktuálnímu stavu zpracování dotazů, jsou zde uloženy prováděcí plány pro sestavené dotazy atd.

Modul správy externí paměti zajišťuje tvorbu potřebných externích paměťových struktur jak pro ukládání dat přímo obsažených v databázi, tak pro servisní účely, např. pro urychlení přístupu k datům v některých případech (k tomu se obvykle používají indexy). Jak jsme již uvedli dříve, v některých implementacích DBMS se aktivně využívají schopnosti stávajících souborových systémů, v jiných se pracuje až na úrovni externích paměťových zařízení. Zdůrazňujeme však, že v pokročilých DBMS uživatelé v žádném případě nemusí vědět, zda DBMS používá souborový systém, a pokud ano, jak jsou soubory uspořádány. Zejména DBMS udržuje svůj vlastní systém pojmenování objektů databáze.

Modul pro správu vyrovnávací paměti RAM je určen k řešení problémů efektivního vyrovnávací paměti, který se používá pro téměř všechny ostatní funkce DBMS.

Obvykle může být RAM spravovaná DBMS reprezentována jako soubor vyrovnávacích pamětí, které ukládají datové stránky, vyrovnávacích pamětí, které ukládají stránky protokolů transakcí, a sdílená oblast fondu (viz obrázek 14.2). Poslední oblast obsahuje fragmenty systémového katalogu, které je nutné neustále uchovávat v paměti RAM, aby se urychlilo zpracování uživatelských požadavků, a oblast SQL příkazů s kurzory. Fragmenty systémového katalogu se v některých implementacích nazývají datový slovník. Standard SQL2 definuje obecné požadavky na systémový katalog.

Rýže. 14.1. Zobecněná struktura DBMS

Rýže. 14.2. RAM spravovaná DBMS

Systémový katalog v relačním DBMS je kolekce speciálních tabulek vlastněných samotným DBMS. Tabulky systémového katalogu se vytvářejí automaticky při instalaci softwaru databázového serveru. Všechny systémové tabulky jsou obvykle spojeny nějakým speciálním "systémovým uživatelským jménem". Při zpracování SQL dotazů DBMS neustále přistupuje k těmto tabulkám. Některé DBMS umožňují omezený přístup uživatelů k řadě systémových tabulek, ale pouze v režimu čtení. Pouze správce systému má některá práva upravovat data v některých systémových tabulkách.

Každá tabulka systémového katalogu obsahuje informace o jednotlivých konstrukčních prvcích databáze. Standard SQL2 definuje následující systémové tabulky:

Tabulka 14.1. Obsah systémového katalogu podle standardu SQL2

REFERENTIAL_CONSTRAINTS Jeden řádek pro každý cizí klíč přítomný v definici tabulky

CHECK_CONSTRAINTS Jeden řádek pro každou podmínku kontroly specifikovanou v definici tabulky

CHECK_TABLE_USAGE Jeden řádek pro každou tabulku odkazovanou v kontrolní podmínce, omezení domény nebo celé tabulce

Standard SQL2 nevyžaduje, aby DBMS přesně podporoval požadovanou sadu systémových tabulek. Norma se omezuje na požadavek, aby některé speciální pohledy na systémový katalog byly dostupné běžným uživatelům. Proto jsou systémové tabulky v různých DBMS organizovány odlišně a mají různé názvy, ale většina DBMS poskytuje běžným uživatelům řadu základních pohledů.

Kromě toho systémový katalog odráží některé další funkce poskytované konkrétními DBMS. Takže například v katalogu systému Oracle existují tabulky synonym.

Oblast SQL obsahuje data vazby, dočasné vyrovnávací paměti, strom analýzy a plán provádění pro každý příkaz SQL předaný databázovému serveru. Sdílená oblast

Fond má omezenou velikost, takže se do něj nemusí vejít všechny příkazy SQL, které byly provedeny od spuštění databázového serveru. Jádro DBMS odstraňuje staré, dlouho nepoužívané příkazy a uvolňuje paměť pro nové příkazy SQL. Pokud uživatel provede dotaz, jehož plán provádění je již uložen ve sdíleném fondu, pak jej DBMS neanalyzuje a nesestaví nový plán, okamžitě jej spustí k provedení, případně s novými parametry.

Modul správy transakcí podporuje mechanismy pro potvrzení a vrácení transakcí, je spojen s modulem správy vyrovnávací paměti RAM a zajišťuje uložení všech informací, které jsou vyžadovány po měkkých nebo těžkých selháních v systému. Kromě toho modul pro řízení transakcí obsahuje speciální mechanismus pro hledání uváznutí nebo uváznutí a implementuje jednu z akceptovaných strategií pro vynucené dokončení transakce pro uvolnění uváznutí.

Zvláštní pozornost by měla být věnována modulu podpory SQL. Jedná se prakticky o překladač z jazyka SQL a blok optimalizace dotazů.

Obecně lze optimalizaci dotazů rozdělit na syntaktickou a sémantickou.

Metody optimalizace syntaktického dotazu

Metody optimalizace syntaktického dotazu jsou spojeny s konstrukcí nějakého ekvivalentního formuláře, někdy nazývaného kanonický formulář, který vyžaduje nižší náklady na provedení dotazu, ale poskytuje výsledek, který je zcela ekvivalentní původnímu dotazu.

Techniky používané při optimalizaci syntaktických dotazů zahrnují následující:

Logické transformace dotazů.Především se jedná o transformaci predikátů zahrnutých do výběrové podmínky. Predikáty obsahující jednoduché operace porovnávání hodnot. Takový predikát má tvar OS aritmetický výraz aritmetický výraz, kde OS je porovnávací operace a aritmetické výrazy levé a pravé části obecně obsahují názvy relačních polí a konstant (v SQL mohou být mezi konstantami i názvy proměnných přiloženého programu, jejichž hodnoty se stanou známými pouze „když je dotaz skutečně proveden).

Kanonické reprezentace mohou být různé pro predikáty různých typů. Pokud predikát obsahuje pouze jeden název pole, pak jeho kanonickou reprezentací může být například konstantní aritmetický výraz názvu pole OS (tato forma predikátu - jednoduchý výběrový predikát - je velmi užitečná při provádění další fáze optimalizace). Pokud je počáteční reprezentace predikátu

(n+12)*R.B OC 100

kde n je jazyková proměnná, R.B je název sloupce Ve vztahu R je OS platná porovnávací operace.

Kanonická reprezentace takového predikátu může být

R.V OS 100/(n+12)

V tomto případě vypočítáme výraz v závorce a pravou stranu porovnávací operace 100/(n +12) jednou pro danou hodnotu proměnné n a poté můžeme každý řádek porovnat s výslednou hodnotou.

Pokud predikát obsahuje právě dva názvy polí různých vztahů (nebo dva různé výskyty stejného vztahu), pak jeho kanonickou reprezentací může být název pole OS aritmetický výraz, kde aritmetický výraz na pravé straně obsahuje pouze konstanty a druhý název nula (toto je také formulář, užitečný pro provedení dalšího kroku optimalizace, -

spojit predikát; případ equijoin je zvláště důležitý, když je OS rovnost). Pokud v počáteční reprezentaci predikát vypadá takto:

12*(Rl.A)-n*(R2.B) OS m,

R1.A OS (m+n*(R2.B)/12

Další třída logických transformací souvisí s redukcí na kanonickou formu logického výrazu, který specifikuje podmínku výběru dotazu. Zpravidla se používají buď disjunktivní nebo konjunktivní normální formy. Volba kanonické formy závisí na celkové organizaci optimalizátoru.

R1 PŘIROZENÉ SPOJENÍ R2

KDE R1.A OS a AND

Zde aab jsou některé konstanty, které omezují hodnotu atributů vztahu

spojit predikát; zvláště důležitý je případ zquiconnection, kdy OC je rovnost). Pokud v počáteční reprezentaci predikát vypadá takto:

12*(Rl.A)-n*(R2.B) OS m,

pak jeho kanonická reprezentace je:

R1.A OS (m+n*(R2.B)/12

V obecném případě je žádoucí redukovat predikát na kanonické zobrazení tvaru aritmetický výraz OS konstantní aritmetický výraz, kde jsou výrazy pravé a levé části také redukovány na kanonické zobrazení. V budoucnu můžete hledat běžné aritmetické výrazy v různých predikátech dotazu. To je oprávněné, protože při provádění dotazu bude výpočet aritmetických výrazů proveden při načítání každé následné n-tice, tedy potenciálně velkého počtu opakování.

Při redukci predikátů na kanonickou reprezentaci můžete vyhodnotit konstantní výrazy a zbavit se logických negací.

Další třída logických transformací souvisí s redukcí na kanonickou formu logického výrazu, který specifikuje podmínku výběru dotazu. Zpravidla se používají buď disjunktivní nebo konjunktivní normální formy. Volba kanonické formy závisí na celkové organizaci optimalizátoru.

Při redukci logické podmínky na kanonickou reprezentaci je možné hledat běžné predikáty (mohou zpočátku existovat, mohou se objevit po redukci predikátů na kanonickou formu nebo v procesu normalizace logické podmínky) a zjednodušit logického vyjádření například identifikací spojky vzájemně si odporujících predikátů.

Transformace dotazů s přeuspořádáním relačních operací. V

V tradičních optimalizátorech jsou běžné logické transformace spojené se změnou pořadí provádění relačních operací.

Máme například následující požadavek:

Rl PŘIROZENÉ SPOJENÍ R2 KDE R1.A OC a A R2.B C b

Zde a a b jsou některé konstanty, které omezují hodnotu atributů vztahů R1 a R2.

Uvažujeme-li to z hlediska relační algebry, pak se jedná o přirozenou kombinaci relací R1 a R2, ve kterých jsou dána vnitřní omezení na n-tice každé relace.

Chcete-li snížit počet spojených n-tic, je rozumnější provést nejprve operace vzorkování u každého vztahu a teprve poté přejít k operacím přirozeného spojení.

Proto bude tento dotaz ekvivalentní následující sekvenci operací relační algebry:

R3 =.R1R4 = R2 R5 = R3**R4

Ačkoli málo relačních systémů má dotazovací jazyky založené čistě na relační algebře, pravidla pro transformaci algebraických výrazů mohou být užitečná i v jiných případech. Poměrně často se jako základ pro vnitřní reprezentaci dotazu používá relační algebra. Přirozeně potom lze provádět i algebraické transformace.

Zejména se jedná o přístupy související s transformací dotazů v jazyce SQL do algebraické formy. A co je nejdůležitější, relační algebra je jednodušší než SQL. Transformace dotazu do algebraické formy zjednodušuje další akce optimalizátoru při výběru optimálních plánů. Obecně řečeno, vyspělý optimalizátor dotazů systému orientovaného na SQL musí objevit všechny možné plány provádění pro jakýkoli dotaz, ale „vyhledávací prostor“ těchto plánů je obecně velmi velký; každý konkrétní optimalizátor používá svou vlastní heuristiku ke zmenšení prostoru pro vyhledávání. Některé, možná nejoptimálnější plány nebudou nikdy brány v úvahu. Rozumná konverze dotazu SQL na algebraickou reprezentaci snižuje prostor pro vyhledávání plánů provádění dotazů se zárukou, že se neztratí optimální plány.

Převod dotazů s vnořenými poddotazy na dotazy se spojeními.Hlavním rozdílem mezi jazykem SQL a jazykem relační algebry je možnost používat predikáty obsahující vnořené poddotazy v podmínkách logického výběru. Hloubka vnoření není omezena jazykem, tedy obecně řečeno může být libovolná. Predikáty s vnořenými poddotazy se společnou syntaxí mohou mít velmi odlišnou sémantiku. Jediný společný pro všechny možné sémantický vnořených poddotazů, algoritmus pro provádění dotazu je vyhodnotit vnořený poddotaz pokaždé, když je vyhodnocena hodnota predikátu. Proto je přirozené usilovat o takovou transformaci dotazu obsahujícího predikáty s vnořenými poddotazy, která učiní sémantiku poddotazu explicitnější, a tím poskytne optimalizátoru příležitost vybrat metodu provádění dotazu, která nejvíce odpovídá sémantice dotazu. poddotaz.

Kanonická reprezentace dotazu na n relací je dotaz obsahující n-1 predikátů spojení a žádné predikáty s vnořenými poddotazy. Ve skutečnosti je kanonický tvar algebraickou reprezentací dotazu.

Například dotaz s vnořeným poddotazem:

(VYBERTE R2.B Z R2, KDE Rl.C = R2.D)

ekvivalent

KDE Rl.A = R2.B A Rl.C = R2.D)

Druhá žádost:

(VYBERTE Rl.A Z Rl KDE Rl.K =

(VYBRAT AVG (R2.B) Z R2, KDE Rl.C = R2.D)

(VYBERTE Rl.A Z Rl.R3

KDE Rl.C = R3.D A Rl.K = R3.L)

R3 = VYBERTE R2.D, L AVG (R2.B)

Při použití tohoto přístupu v optimalizátoru dotazů není nutné provádět formální transformace dotazů. Optimalizátor by měl ve větší míře využívat sémantiku zpracovávaného dotazu a způsob jeho rozpoznání je otázkou techniky.

Všimněte si, že v přístupu, který jsme stručně popsali, jsou některé jemné sémantické nedostatky. Opravené metody jsou známy, ale jsou příliš technicky složité na to, aby je bylo možné uvažovat v tomto návodu.

Metody optimalizace sémantických dotazů

Výše uvedené metody nijak nesouvisí se sémantikou konkrétní databáze, jsou použitelné pro jakoukoli databázi bez ohledu na její konkrétní obsah. Metody sémantické optimalizace jsou založeny právě na zohlednění sémantiky konkrétní databáze. Takových metod může být v různých implementacích mnoho, my se dotkneme pouze některých z nich:

Transformace požadavků zohledňující sémantické informace.To se týká především dotazů, které se provádějí na pohledech. Samotný pohled je dotaz. V databázi je pohled uložen ve formě sestaveného plánu provádění dotazu, to znamená, že již obsahuje všechny predikáty a samotný plán provádění dotazu v nějaké kanonické podobě. Při transformaci externího dotazu je vnější dotaz kombinován s vnitřní formou dotazu, který tvoří základ pohledu, a je vytvořen zobecněný kanonický formulář, který kombinuje oba dotazy. Pro tuto formu kořisti se provádí analýza a transformace predikátů. Proto, když je dotaz proveden na pohledu, nebudou provedeny dva, ale pouze jeden dotaz, optimalizovaný zobecněnými parametry dotazu.

Použití omezení integrity při analýze požadavků.Omezení integrity souvisí s podmínkami, které jsou uvaleny na hodnoty sloupců tabulky. Při provádění dotazů na tabulky se podmínky dotazu kombinují speciálním způsobem s omezujícími podmínkami tabulky a výsledné zobecněné predikáty jsou již analyzovány. Řekněme, že v naší knihovně hledáme čtenáře, kteří jsou starší 100 let, ale pokud máme v tabulce ČTENÁŘI nastaveno omezení, které omezuje datum narození našich čtenářů tak, aby měl čtenář datum narození mezi 17 a 100 lety staré, včetně. Optimalizátor dotazů tedy porovnáním těchto dvou predikátů může okamžitě určit, že výsledkem dotazu bude prázdná množina.

Po optimalizaci má dotaz neprocedurální podobu, to znamená, že nedefinuje striktní pořadí pro provádění elementárních operací na zdrojových objektech. V další fázi jsou sestaveny všechny možné plány provádění dotazů a pro každý z nich jsou provedeny odhady nákladů. Vyhodnocování plánů provádění dotazů je založeno na analýze aktuálních objemů dat uložených v databázových relacích a na statistické analýze uložených informací. Většina DBMS sleduje rozsah hodnot jednotlivých sloupců s procentem pro každý rozsah. Proto při sestavování plánu dotazů může DBMS odhadnout množství mezilehlých vztahů a sestavit plán takovým způsobem, aby v nejranějších fázích provádění dotazu minimalizoval počet řádků zahrnutých do mezilehlých vztahů.

Kromě enginu DBMS poskytuje každý dodavatel speciální nástroje, které usnadňují správu databáze a vývoj nových databázových projektů a uživatelských aplikací pro daný server. V poslední době mají téměř všechny utility a nástroje vyvinuté grafické rozhraní.

K vývoji aplikací mohou uživatelé využívat nejen nástroje dodávané s databázovým serverem, ale také nástroje od dodavatelů třetích stran. V naší zemi se tedy stalo velmi populární prostředí nástroje Delphi, které umožňuje vyvíjet aplikace pro různé databázové servery. Zámoří

Systémy nástrojů pro rychlý vývoj aplikací jsou oblíbené

Produkty pokročilého informačního systému (RAF Rapid Application Foundation),

Sada nástrojů Power Builder od Power Soft, systém SQL Windows od Power Soft

Útoky na úložiště a databáze patří mezi nejnebezpečnější pro podniky a organizace. Podle statistik infowatch v posledních letech počet úniků dat ve světě neustále roste, přičemž v roce 2015 jich bylo více než třicet procent externích narušitelů a více než šedesát bylo provedeno za účasti zaměstnanců organizace. I když předpokládáme, že v některých případech únik zahrnoval data, ke kterým má zaměstnanec legální přístup, každý třetí případ byl externím útokem. Je třeba také poznamenat, že podle údajů uvedených v datech sedm z osmi úniků s více než deseti miliony záznamů připadá na externí útoky.

Útočníky zajímají takové typy informací, jako jsou interní provozní informace, osobní údaje zaměstnanců, finanční informace, informace o zákaznících/klientech, duševní vlastnictví, průzkum trhu/analýza konkurence, platební informace. Tyto informace se nakonec ukládají do podnikových úložišť a databází různých velikostí.

To vše vede k nutnosti zajistit ochranu nejen komunikací, operačních systémů a dalších prvků infrastruktury, ale i datových úložišť jako další bariéry pro útočníka. Dosud je však práce v oblasti bezpečnosti databází zaměřena především na překonání stávajících a již známých zranitelností, implementaci základních přístupových modelů a zvážení problémů specifických pro konkrétní DBMS. Účelem této práce je komplexní přehled a systematizace problematiky bezpečnosti různých databází ve světle nových hrozeb, obecných trendů ve vývoji informační bezpečnosti a rostoucí role a rozmanitosti datových úložišť.

Problematika integrované bezpečnosti databází přitahuje pozornost badatelů, každoročně se jim věnuje řada prací v Rusku i v zahraničí. Studie, jako je klasická práce, lze zaznamenat. Pojednává o přístupech k zajištění důvěrnosti, integrity a dostupnosti DBMS, prevenci, detekci a ignorování útoků. Jsou navrženy přístupy k poskytování povinného a na rolích založeného diskrečního přístupu k relačnímu serveru. Toto téma je vyvinuto prací, která se dotýká stejných otázek zajištění oddělení přístupu, oprávnění, auditování a šifrování dat, stejně jako otázek používání vestavěných mechanismů pro zajištění bezpečného přístupu, jako jsou spouštěče, pohledy a uložené procedury. Práce, která je shrnuje, shrnuje vývoj přístupů k bezpečnosti v historickém aspektu.

Mezi zahraničními pracemi pokrývajícími moderní oblasti výzkumu lze zaznamenat. Práce ruských badatelů se věnují především úzkým otázkám bezpečnosti DBMS, například .

Je třeba poznamenat i monografie. Tyto práce, stejně jako zejména známé učební pomůcky a materiály, však také nepřekračují výše uvedená témata nebo například reflektují specifika konkrétního DBMS.

Podobnou situaci lze pozorovat i v práci. STIG zahrnuje známé bezpečnostní problémy a kritéria pro úroveň certifikace softwaru DBMS, vyhodnocuje zabezpečení softwaru na základě známých hrozeb, aniž by bral v úvahu specifika uložených dat.

Dnešní výzkum v oblasti bezpečnosti DBMS se tak omezuje na vývoj konceptu důvěrnosti, integrity a dostupnosti dat, který nesplňuje moderní požadavky na systémy ochrany a informační bezpečnost softwarových řešení (např. specifické metody ochrany spíše než holistické zvážení problému. Zároveň se často věnují konkrétním softwarovým produktům, nikoli celé třídě odpovídajícího softwaru.

Vývoj databázových bezpečnostních systémů

Historicky vývoj databázových bezpečnostních systémů probíhal jako reakce na akce narušitelů v souladu s fázemi vývoje samotných úložišť (DB) a změnami typu a typu narůstajících hrozeb. Tyto změny byly způsobeny celkovým vývojem databáze od řešení pro sálové počítače po cloudová úložiště.

Z hlediska architektury lze rozlišit následující přístupy:

Úplný přístup pro všechny uživatele k databázovému serveru;

Rozdělení uživatelů na důvěryhodné a částečně důvěryhodné pomocí DBMS (systémy pro správu databází);

Zavedení systému auditu (logy uživatelských akcí) pomocí DBMS;

Zavedení šifrování dat; odstranění autentizačních prostředků mimo DBMS operačním systémům a middlewaru; odhlášení od plně důvěryhodného správce údajů.

Zavedení ochranných nástrojů jako reakce na hrozby však neposkytuje ochranu proti novým metodám útoku a vytváří roztříštěný pohled na samotný bezpečnostní problém. Na jednu stranu velké společnosti mohou pro své produkty alokovat dostatečné množství bezpečnostních nástrojů, na druhou stranu právě z tohoto důvodu existuje velké množství heterogenních řešení, chybí pochopení pro komplexní zabezpečení dat (a její komponenty se liší výrobce od výrobce), neexistuje žádný obecný, jednotný přístup k zabezpečení datových skladů a v důsledku toho i příležitostí. Predikce budoucích útoků a perspektivní vývoj ochranných mechanismů jsou stále obtížnější, pro mnohé systémy zůstává relevantní relevance již dávno známých útoků a školení bezpečnostních specialistů se komplikuje.

Právě vývoj softwarových nástrojů pro pokročilou ochranu (před útočníkem), zajišťující možnost zavedení takové technologie, se autorům článku jeví jako nejnaléhavější úkoly v současné fázi.

Moderní problémy se zabezpečením databáze

Seznam hlavních zranitelností datového skladu, který je dnes relevantní, se za posledních pět let výrazně nezměnil. Po analýze bezpečnostních nástrojů DBMS, architektury databáze, rozhraní, známých zranitelností a bezpečnostních incidentů můžeme identifikovat následující důvody této situace:

Bezpečnostními otázkami se vážně zabývají pouze velcí výrobci, především u předních produktů řad datových úložišť;

Databázoví programátoři, aplikační programátoři a správci databází nevěnují náležitou pozornost bezpečnostním otázkám;

Různá měřítka a typy uložených dat vyžadují různé přístupy k zabezpečení;

Různé DBMS používají různé jazykové dialekty pro přístup k datům organizovaným kolem stejného modelu;

Objevují se nové typy a modely ukládání dat.

Zvažme tato ustanovení podrobněji na příkladu produktové řady od společnosti Oracle. Oracle Database Server DBMS má poměrně pokročilý bezpečnostní systém, který obsahuje základní i doplňkové moduly a obsahuje nástroje pro granulaci přístupu na úroveň záznamu a maskování dat. Všimněte si, že produkt MySQL DBMS se nemůže pochlubit takovou úrovní zabezpečení. To je poměrně vážný problém, protože MySQL je široce používaný DBMS v e-commerce i vládních databázích.

Mnoho zranitelností identifikovaných ve studiích (například v ) zůstává relevantních kvůli nepozornosti nebo neznalosti bezpečnostních problémů ze strany administrátorů databázových systémů. Například známé jednoduché techniky SQL injection jsou dnes hojně využívány ve vztahu k různým webovým a dalším aplikacím, které nevěnují pozornost kontrole vstupních dat dotazu. Důvody jsou jak nedostatečná informovanost nebo pozornost administrátorů DBMS a aplikačních programátorů, tak nedostatek vestavěných kontrol známých zranitelností ve většině DBMS. Dobrým řešením by bylo automatizovat a přenést kontrolu nad těmito hrozbami na úroveň serveru, ale rozmanitost jazykových dialektů to neumožňuje.

Je třeba také poznamenat, že použití různých nástrojů zabezpečení informací je pro organizaci finančním kompromisem: zavedení bezpečnějších produktů a nábor kvalifikovanějších pracovníků jsou nákladné. Kromě toho mohou komponenty zabezpečení negativně ovlivnit výkon systémů správy databází, jako jsou úrovně konzistence transakcí. Plná shoda s ACID modelem je nejpomalejší způsob, jak zajistit integritu při práci s více uživateli. Postupy, jako je maskování dat nebo zavádění bezpečnostních kontrol přístupu, to také zpomalují.

Dalším důvodem této situace je fragmentace dialektů dotazovacího jazyka DBMS. Pokud vezmeme v úvahu pouze známé relační DBMS, i přes přítomnost vyvíjejícího se standardu SQL (SQL-92, SQL-99, SQL-2003, SQL-2008) i velcí výrobci nejen používají vlastní jazyková rozšíření, ale také nepodporovat přijatou verzi až do konce provozního standardu. Tato skutečnost komplikuje vývoj jednotných mechanismů ochrany databází na úrovni serveru.

Výše uvedené problémy se zhoršily s příchodem a rozšířeným používáním nerelačních datových skladů a DBMS pracujících s jiným datovým modelem, ale postaveným na stejných principech a majících podobný účel jako tradiční relační servery. Různorodost moderních tzv. NoSQL (nerelačních) řešení ve skutečnosti vede k různým používaným datovým modelům a stírá hranice konceptu databáze.

Důsledkem těchto problémů a nedostatku jednotných metod je současná bezpečnostní situace NoSQL systémů. Tato řešení jsou na trhu nová a ještě neprošla cestou „chyb a zranitelností“ svých vyspělejších relačních protějšků. Většina systémů NoSQL postrádá nejen obecně uznávané bezpečnostní mechanismy, jako je šifrování, podpora integrity dat a audit dat, ale dokonce i pokročilé nástroje pro autentizaci uživatelů.

Vlastnosti databázových systémů jako předmětu ochrany

V souvislosti se vznikem nových řešení v oblasti nerelačních úložišť, která stírají hranice tradičního pohledu na DBMS (například in-memory data caching systém MemcasheDB nebo Hadoop HDFS), definujeme funkce, které odlišit DBMS od úložiště souborů a jiných typů softwarových produktů. V tomto duchu je zvýrazněno několik znaků. Přeformulování prvního znaku - "udržování logicky konzistentní sady souborů", díky aktivnímu vývoji v paměti DBMS, které ukládají a všechny operace s daty v RAM, uvádíme tato kritéria v následujícím vydání:

Udržování logicky konzistentní datové sady;

Poskytování jazyka pro manipulaci s daty;

Obnova informací po různých druzích selhání;

Reálná paralelní práce více uživatelů (procesů).

Pomocí tohoto přístupu je možné oddělit DBMS od souborových systémů a jiných typů softwaru.

Charakteristickým rysem databázových systémů od jiných typů aplikačního softwaru je (ve vztahu nejen k informační bezpečnosti) jejich dvojí povaha. Z tohoto pohledu DBMS zahrnuje dvě složky: uložená data (samotnou databázi) a řídicí programy (DBMS).

Bez zajištění bezpečné správy dat není možné zejména zajistit bezpečnost uložených informací. Na základě tohoto konceptu lze všechny zranitelnosti a bezpečnostní problémy DBMS rozdělit do dvou kategorií: datově závislé a datově nezávislé.

Všimněte si, že zranitelnosti nezávislé na datech (jejich struktury, organizace atd.) jsou typické pro všechny ostatní typy softwaru. Do této skupiny patří předčasné aktualizace softwaru nebo přítomnost nepoužívaných funkcí.

Velké množství aspektů zabezpečení závisí na datech (v té či oné míře). Zejména mechanismy logické inference a agregace dat, nazývané specifické problémy DBMS, lze nazvat přímo závislými. Mnoho zranitelností je přitom na datech nepřímo závislých. Například moderní DBMS (včetně relačních i nerelačních řešení) podporují dotazy na data pomocí nějakého druhu dotazovacího jazyka. Na druhé straně specializované dotazovací jazyky ​​(SQL, CQL, OQL a další), sady uživatelsky přístupných funkcí (které lze zase považovat za operátory dotazovacího jazyka) nebo libovolné funkce v programovacím jazyce (nejčastěji Java ) se používají v této funkci. . Zobecněná rozhraní pro práci s daty jsou znázorněna na obrázku.

Architektura používaných jazyků, alespoň pokud jde o specializované jazyky (dotazy) a sady funkcí, přímo souvisí s datovým modelem používaným k ukládání informací. Model tedy určuje rysy jazyka a rysy jazyka určují přítomnost určitých zranitelností v něm. Navíc zranitelnosti obecného typu, jako je injekční vkládání (injektováním rozumíme útok na databázi úpravou vstupních požadavků, což nutí server DBMS provést nelegitimní sadu akcí), se provádějí odlišně (vstřikování SQL, vkládání JAVA) v závislosti na na syntaxi a sémantických jazycích, které, jak bylo uvedeno výše, jsou částečně definovány datovým modelem, a jsou tedy datově závislou komponentou.

Požadavky na zabezpečení databáze

Na základě oddělení zranitelností je tedy možné rozlišovat mezi datově závislými a datově nezávislými bezpečnostními opatřeními pro informační úložiště. Následující požadavky na bezpečný databázový systém lze nazvat datově nezávislý.

· Fungování v důvěryhodném prostředí.

Důvěryhodný je chápán jako informační prostředí, které integruje soubor ochranných mechanismů zajišťujících zpracování informací bez porušení bezpečnostní politiky. V tomto případě musí DBMS fungovat v důvěryhodném informačním systému s vhodnými metodami výměny dat.

· Organizace fyzického zabezpečení datových souborů.

Tento problém vyžaduje podrobnější studii, protože datové struktury používané v různých datových modelech DBMS mohou být důležité při šifrování a ochraně datových souborů. V prvním přiblížení je však otázka fyzického zabezpečení datových souborů podobná otázce fyzického zabezpečení jakéhokoli jiného uživatele a souborů aplikace.

· Organizace bezpečného a aktuálního nastavení DBMS.

Tento aspekt zahrnuje takové obecné bezpečnostní problémy, jako je včasná instalace aktualizací, deaktivace nepoužívaných modulů nebo použití účinných zásad hesel.

Následující požadavky lze nazvat datově závislé.

· Zabezpečení uživatelské softwarové vrstvy.

· Bezpečná organizace dat a manipulace s nimi.

V systémech ukládání informací je klíčová otázka organizace a správy dat. Přestože je tato oblast uvedena na posledním místě v seznamu, zahrnuje organizaci dat s řízením integrity, ochranou odvození a dalšími bezpečnostními problémy specifickými pro DBMS. Ve skutečnosti tento úkol zahrnuje hlavní soubor zranitelností závislých na datech a ochranu proti nim.

Způsoby vytváření bezpečných databází

Pro překonání těchto problémů zajištění informační bezpečnosti SŘB je nutné přejít od metody uzavírání zranitelností k integrovanému přístupu k zajištění bezpečnosti informačních úložišť. Hlavními fázemi tohoto přechodu by podle autorů měla být následující ustanovení.

1. Vývoj komplexních metod pro zajištění bezpečnosti datových skladů v současné fázi.

Vytvoření komplexních metodik umožní jejich aplikaci (nebo jejich odpovídající verze) při vývoji datových skladů a uživatelského softwaru. Podkladem pro tvorbu takových dokumentů mohou být práce, které problémy zobecňují, např. popř. Dodržování komplexní metodiky vám umožní vyhnout se mnoha chybám správy DBMS a chránit se před dnešními nejběžnějšími zranitelnostmi.

2. Hodnocení a klasifikace DBMS hrozeb a zranitelností.

Specializovaná klasifikace hrozeb a zranitelností DBMS umožní jejich uspořádání pro následnou analýzu a ochranu a umožní stanovit vztah mezi zranitelnostmi a příčinami (zdroji) jejich výskytu. V důsledku toho, když je do DBMS zaveden specifický mechanismus, bude možné identifikovat a předvídat hrozby s tím spojené a předem připravit vhodné bezpečnostní nástroje.

3. Vývoj standardních (použitelných pro různé DBMS bez provedení změn nebo s minimálními změnami) bezpečnostních mechanismů.

Standardizace přístupů a jazyků pro práci s daty umožní vytvářet multiplatformní bezpečnostní nástroje použitelné pro různé DBMS. Na jedné straně se jedná o metodologické a teoretické přístupy aplikovatelné v rámci datového modelu. K dnešnímu dni dochází k vývoji takových mechanismů podle relačního modelu, ale neřeší všechny naléhavé bezpečnostní problémy. Na druhé straně je to vývoj teoretického základu pro nové DBMS, zejména specifikace a formalizace agregovaných datových modelů. Vzhled hotových softwarových nástrojů do značné míry závisí na výrobcích a vývojářích DBMS a jejich dodržování standardů a také na dostatku prostředků definovaných ve standardu pro budování pokročilých bezpečnostních mechanismů.

4. Vypracování teoretického základu pro ochranu informací systémů pro ukládání a manipulaci s daty.

Výše byla zmíněna řada charakteristických rysů specifických pro datové sklady: duální povaha DBMS, závislost zranitelností a kontrolních mechanismů na datech a modelu, který popisuje jejich organizaci, vyvozování hrozeb a různý význam kombinací dat. To vše určuje specifickou povahu zabezpečení DBMS a vyžaduje nové teoretické přístupy k zajištění ochrany dat v softwarových systémech tohoto druhu. Samostatnou velkou otázkou je vývoj teoretického základu v kontextu formalizace datového modelu a také vývoj přístupů k zajištění integrity informací pro nová úložiště NoSQL.

Na základě výše uvedeného vyvozujeme následující závěry. V důsledku zohlednění ruských a zahraničních děl a také situace na trhu DBMS článek zdůrazňuje současný přístup k zajištění bezpečnosti, princip a hlavní vývojové fáze databázových systémů. Jsou formulovány problémy informační bezpečnosti moderních DBMS: rozmanitost jazykových nástrojů, vznik nových datových modelů, které nejsou podloženy teoretickým základem, potřeba najít rovnováhu mezi bezpečností a její cenou, vývoj ochranných systémů jako reakce na ztrátu finančních prostředků a prestiže, stejně jako obecný nedostatek pozornosti k otázkám bezpečnosti.

Jsou formulována kritéria, která odlišují DBMS od podobných softwarových produktů, berou v úvahu nová clusterová a paměťová řešení, vlastnosti této třídy softwaru z hlediska informační bezpečnosti a základní rozdělení zranitelností na závislé a nezávislé na datech a jejich organizaci je navržený.

V důsledku toho jsou formulovány obecné požadavky na bezpečnost databází, perspektivní způsoby výzkumu a vývoje ochranných systémů pro budování spolehlivých a bezpečných serverů pro zpracování informací. Zahrnovaly jak systematizaci a rozvoj stávajících přístupů v podobě vývoje metod a standardizace ochranných mechanismů, tak i oblasti nového výzkumu, například klasifikaci zranitelností DBMS a formalizaci nových datových modelů, konstrukci prediktivní ochrany nástroje.

Literatura

1. Studie úniků informací za první polovinu roku 2015. URL: http://www.infowatch.ru/analytics/reports/16340 (datum přístupu: 26.02.2016).

2. Informační bezpečnost podnikání. Studium současných trendů v bezpečnosti podnikových informací. 2014. URL: http://media.kaspersky.com/pdf/IT_risk_report_Russia_2014.pdf (přístup 26.02.2016).

3. Sandhu Ravi S., Jajodia Sushil. Zabezpečení a kontroly dat a databází. Handbook of Information Security Management, Auerbach Publishers, 1993, pp. 181-199.

4. Qiu M., Davis S. Bezpečnostní mechanismy databáze a implementace. IACIS, Issues in Inform. Syst. 2002, sv. 03, str. 529-534.

5. Lesov P. Zabezpečení databáze: historický pohled. 2010. URL: http://arxiv.org/ftp/arxiv/papers/1004/1004.4022.pdf (přístup 26.02.2016).

6. Burtescu E. Zabezpečení databáze - útoky a způsoby kontroly. Journ. aplikovaných kvantitativních metod, 2009, roč. 4, č. 4, str. 449-454.

7. Rohilla S., Mittal P.K. Zabezpečení databáze: vlákna a výzvy. Internovat. Journ. of Advanced Research in Computer Science and Software Engineering, 2013, roč. 3, iss. 5, str. 810-813.

8. Potapov A.E., Manukhina D.V., Solomatina A.S., Badmaev A.I., Jakovlev A.V., Nilova A.S. Zabezpečení lokálních databází na příkladu SQL Server Compact // Vestn. Tambov. univerzita Řada: Přírodní a technické vědy. 2014. č. 3. S. 915-917.

9. Bortovchuk Yu.V., Krylova K.A., Ermolaeva L.V. Informační bezpečnost v moderních systémech správy databází // Moderní problémy ekonomického a sociálního rozvoje. 2010. č. 6. S. 224-225.

10. Gorbačovskaja E.N., Kat'yanov A.Yu., Krasnov S.S. Zabezpečení informací pomocí Oracle DBMS // Vestn. VUiT. 2015. č. 2 (24). str. 72-85.

11. Tkačenko N.O. Implementace bezpečnostního monitoru MySQL DBMS v systémech dbf/dam // PDM. Aplikace. 2014. č. 7. S. 99-101.

12. Poltavtseva M.A. Problém ukládání přístupových práv k datům v RDBMS na příkladu Microsoft SQL Server // Aktuální směry základního a aplikovaného výzkumu: mater. V Stážista. vědecko-praktické. conf. 2015. S. 118-120.

13. Baranchikov A.I., Baranchikov P.A., Pylkin A.N. Algoritmy a modely přístupu k záznamům databáze. M.: Hotline-Telecom, 2011. 182 s.

14. Polyakov A.M. Zabezpečení Oracle očima auditora: útok a obrana. M.: DMK Press, 2014. 336 s.

15. Smirnov S.N. Zabezpečení databázových systémů. M.: Helios ARV, 2007. 352 s.

16Murray M.C. Zabezpečení databáze: co studenti potřebují vědět. JITE:IIP, sv. 9, 2010, str. 61-77.

17. Průvodce technickou implementací zabezpečení databáze (STIG). Ministerstvo obrany USA. Vers. 7. Vydání 1. 2004. URL: https://www.computer.org/cms/s2esc/s2esc_excom/Minutes/2005-03/DISA%20STIGs/DATABASE-STIG-V7R1.pdf .

18. Zegzhda P.D. Zajištění bezpečnosti informací v podmínkách vytvoření jednotného informačního prostoru // Ochrana informací. Uvnitř. 2007. č. 4 (16). s. 28-33.

19. Deset největších hrozeb zabezpečení databáze. URL: http://www.imperva.com/docs/wp_topten_database_threats.pdf IMPREVA 2015 (vstup 26.02.2016).

20. Kuzněcov S.D. Databáze: učebnice pro studenty. M.: Akademie, 2012. 496 s.

21. Zegzhda D.P., Kalinin M.O. Zajištění plné moci informačního prostředí na základě rozšíření pojmu „integrita“ a řízení bezpečnosti // Problemy inform. bezpečnostní. Počítačové systémy. 2009. č. 4. S. 7-16.

22. Poltavtseva M.A., Zegzhda D.P., Suprun A.F. Zabezpečení databáze: učebnice. příspěvek. Petrohrad: Nakladatelství SPbPU, 2015. 125 s.

Práce na kurzu

Software MDK 02.02.R1. IMPLEMENTACE DATABÁZE V ACCESS DBMS

K TÉMATU: "Návrh databáze obchodní organizace"

Ukončeno: student gr. PO-41

M. V. Tsatsin

Hlava: I.I. Shalaeva

Školní známka:__________________

G. Sterlitamak

úvod ................................................. ................................................. ..... 3

Formulace problému ................................................................ .................................. 5

1. ZÁKLADNÍ POJMY O DATABÁZÍCH V MS ACCESS................................................. 6

1.1 Databáze a systémy správy databází................................................ 6

1.2. Typy dat. 7

1.3. Zabezpečení databáze. 8

2. Struktura databáze ............................................................ ................................................. 10

2.1 Schéma ................................................ ................................................................... ...... 10

2.2 Tabulky ............................................................ ...................................................... jedenáct

2.3. Formuláře ................................................. ................................................. 16

2.4. Žádosti ................................................ ................................................. 19

2.5. Zprávy ................................................................ ................................................. .21

3. VARIANTA DATABÁZE OBCHODNÍ ORGANIZACE ZABÝVAJÍCÍ SE PRODEJEM PTAČÍCH RYB................................ ...................................................... ................... 23

ZÁVĚR................................................. ................................................. 25

ÚVOD

Aby mohl činit správná a efektivní rozhodnutí ve výrobních činnostech, v ekonomickém řízení a v politice, musí být moderní specialista schopen přijímat, shromažďovat, ukládat a zpracovávat data pomocí počítačů a komunikací a prezentovat výsledek ve formě vizuálních dokumentů. Informační technologie se v moderní společnosti velmi rychle rozvíjejí, pronikají do všech sfér lidské činnosti.

V různých oblastech ekonomiky je často nutné pracovat s daty z různých zdrojů, z nichž každý je spojen s určitým typem činnosti. Ke koordinaci všech těchto dat jsou zapotřebí určité znalosti a organizační schopnosti.

Produkt společnosti Microsoft – Access kombinuje informace z různých zdrojů v jedné relační databázi. Vytváří formuláře, dotazy a sestavy, které vám umožňují rychle a efektivně aktualizovat data, získávat odpovědi na otázky, vyhledávat relevantní data, analyzovat data, tisknout sestavy, grafy a poštovní štítky.

Účelem této práce v předmětu je zamyšlení nad teorií a tvorbou v praxi databáze v produktu Microsoftu pro správu databází "Microsoft Access" na téma: "Návrh databáze obchodní organizace" zabývající se implementací bird-fish.

Cíle práce v kurzu byly:

· Komunikujte informace efektivně.

· Poskytovat přístup k informacím.

· Rozšiřte databázi o nová data.

· Zkontrolujte pravost informací.

· Zabránit možným chybám v přístupu k databázi.

· Otevřený přístup pouze k informacím, které jsou nezbytné pro práci.

· Otevřít možnost upravovat informace pouze důvěryhodným lidem.

· Usnadnit způsob úpravy informací i hlášení.

FORMULACE PROBLÉMU

1.1. Vyviňte databázi (DB) "Organizace obchodu", která vám umožní udržovat:

soupis stávajícího zboží;

účetnictví kupujících;

účtování dodávky zboží;

1.2. Základní požadavky na databázi podle funkční sady:

1.2.1. Požadavky na obchodní účetnictví:

Nákup zboží podle druhu;

Nákup zboží podle termínů na určité období;

1.2.2. Požadavky zákaznického účetnictví

· Údaje o dodávce produktů zákazníkům;

· Sortiment ptačích ryb;

· Zpráva o nákupech podle dat;

· Zpráva o nákupech podle typů.

ZÁKLADNÍ KONCEPCE O DATABÁZÍCH V MS ACCESS

Databáze a systémy pro správu databází

Databáze je organizovaná struktura pro ukládání informací. Moderní databáze ukládají nejen data, ale také informace.

Toto tvrzení lze snadno vysvětlit, vezmeme-li v úvahu například databázi knihovny. Obsahuje všechny potřebné informace o autorech, knihách, čtenářích atd. Tato databáze je přístupná jak pracovníkům knihovny, tak čtenářům, kteří potřebují najít publikaci. Ale mezi nimi se snad nenajde člověk, který má plný přístup k celé databázi a zároveň je schopen v ní svépomocí provádět libovolné změny. Databáze kromě dat obsahuje metody a nástroje, které umožňují každému ze zaměstnanců pracovat pouze s daty, která jsou v jeho kompetenci. V důsledku interakce dat obsažených v databázi s metodami dostupnými konkrétním zaměstnancům se tvoří informace, které konzumují a na základě kterých zadávají a upravují data ve vlastní kompetenci.

Pojem systém správy databází úzce souvisí s pojmem databáze. Jedná se o sadu softwarových nástrojů určených k vytvoření struktury nové databáze, jejímu naplnění obsahem, úpravě obsahu a vizualizaci informací. Vizualizací databázových informací se rozumí výběr zobrazovaných dat podle daného kritéria, jejich řazení, návrh a následné výdej na výstupní zařízení nebo přenos komunikačními kanály.

Na světě existuje mnoho systémů pro správu databází. Navzdory skutečnosti, že mohou pracovat s různými objekty různými způsoby a poskytovat uživateli různé funkce a nástroje, většina DBMS se spoléhá na jedinou, dobře zavedenou sadu základních konceptů. To nám dává příležitost zvážit jeden systém a zobecnit jeho koncepty, techniky a metody na celou třídu DBMS. Jako takový výukový objekt zvolíme Microsoft Access DBMS, který je součástí balíku Microsoft Office.

Typy dat

Databázové tabulky mají tendenci zpracovávat mnohem větší množství různých typů dat. Databáze Microsoft Access například pracují s následujícími typy dat.

· Text je datový typ používaný k ukládání běžného neformátovaného textu omezené velikosti (až 255 znaků).

· Numeric – datový typ pro ukládání reálných čísel.

· Pole Memo je speciální datový typ pro ukládání velkého množství textu (až 65 535 znaků). Text není fyzicky uložen v poli. Je uložen na jiném místě v databázi a ukazatel na něj je uložen v poli, ale takové oddělení není pro uživatele vždy patrné.

· Datum/čas – datový typ pro ukládání kalendářních dat a aktuálního času.

· Peněžní - datový typ pro ukládání peněžních částek. Teoreticky by k jejich zaznamenání mohla být použita i pole číselného typu, ale pro peněžní částky existují některé funkce (například související s pravidly zaokrouhlování), které umožňují pohodlnější použití speciálního datového typu než nastavení číselného typu. .

· Počítadlo – speciální datový typ pro jedinečná (v poli se neopakující) přirozená čísla s automatickým přírůstkem. Přirozené použití je pro sekvenční číslování záznamů.

· Boolean - typ pro ukládání logických dat (mohou nabývat pouze dvou hodnot, například Ano nebo Ne).

· Průvodce vyhledáváním není speciální datový typ. Jedná se o objekt, který lze nakonfigurovat pro automatizaci zadávání dat do pole tak, že je nezadáváte ručně, ale vybíráte je z rozevíracího seznamu.

Zabezpečení databáze

Databáze jsou také soubory, ale práce s nimi se liší od práce s jinými typy souborů vytvořenými jinými aplikacemi. Výše jsme viděli, že o veškerou údržbu struktury souborů se stará operační systém. Databáze má speciální požadavky na zabezpečení, takže k ukládání dat přistupují jinak.

Databáze jsou speciální struktury. Informace, které obsahují, mají velmi často veřejnou hodnotu. Není neobvyklé, že se stejnou databází pracují tisíce lidí po celé zemi. Blaho mnoha lidí může záviset na informacích obsažených v některých databázích. Integrita obsahu databáze tedy nemůže a neměla by záviset ani na konkrétních akcích určitého uživatele, který zapomněl uložit soubory před vypnutím počítače, ani na výpadcích proudu.

Problém zabezpečení databáze je vyřešen tím, že DBMS používá k ukládání informací duální přístup. Některé operace jako obvykle zahrnují operační systém počítače, ale některé operace ukládání obcházejí operační systém.

Struktura databáze

Datové schéma

Datové schéma zobrazuje datový model pro datovou stránku ve stromové podobě. Ukládá zdroje dat, pole a ovládací prvky stránky. Vzhledem k tomu, že seznam polí nezobrazuje obsah konkrétní stránky, je pro seznámení se strukturou stránky lepší využít datovou strukturu. Můžete také vybírat objekty zobrazené v datové struktuře, nastavovat jejich parametry, definovat a upravovat vazby mezi datovými zdroji, mazat pole a datové zdroje.

Obr.1 Schéma dat

Komponenty datového schématu jsou tři tabulky:

"Nomenklatura"

"Dodávka zboží"

"kupující"

tabulky

Tabulky jsou základními objekty každé databáze. Za prvé, tabulky ukládají všechna data dostupná v databázi a za druhé, tabulky také ukládají strukturu databáze (pole, jejich typy a vlastnosti).

Všechny 3 tabulky jsem vytvořil v návrhovém režimu, ve všech tabulkách je klíčové pole - ProductCode.

Konstruktor tabulky "Nomenklatura bird-fish" je na obr.2.

2 Struktura tabulky "Nomenklatura ptačích ryb" Obr.

Tabulka „Nomenklatura ptáků a ryb“ na obr. 3 je navržena tak, aby zobrazila celý sortiment, který organizace má.

Tabulka "Nomenklatura ptačích ryb"

Konstruktor tabulky "Zákazníci" je na obrázku 3.

Systémy pro správu databází se staly hlavním nástrojem pro ukládání velkého množství informací. Moderní informační aplikace spoléhají především na víceuživatelské DBMS. V tomto ohledu je v současné době věnována velká pozornost problémům zajištění informační bezpečnosti, která určuje míru bezpečnosti organizace, instituce jako celku.

Informační bezpečnost je chápána jako ochrana informací před náhodnými a záměrnými vlivy přirozené nebo umělé povahy, zatíženými škodami pro vlastníky nebo uživatele informací.

Za účelem ochrany informací v databázích jsou nejdůležitější aspekty informační bezpečnosti (evropská kritéria):

podmínky přístupu (schopnost přijímat některé požadované informační služby);

integrita (konzistence informací, jejich ochrana před zničením a neoprávněnými změnami);

důvěrnost (ochrana před neoprávněným čtením).

Problém zajištění informační bezpečnosti je složitý, proto je třeba jeho řešení posuzovat na různých úrovních: legislativní, administrativní, procesní, softwarové a hardwarové. V současné době je problém vytvoření legislativního rámce, který zajistí bezpečné používání informačních systémů, obzvláště akutní v Rusku.

Mezi hlavní softwarová a hardwarová opatření, jejichž aplikace vyřeší některé z výše uvedených problémů, patří:

autentizace a identifikace uživatele;

řízení přístupu k databázi;

udržování integrity dat;

protokolování a auditování;

ochrana komunikace mezi klientem a serverem;

odraz hrozeb specifických pro DBMS.

Autentizace uživatele databázových aplikací se nejčastěji provádí buď prostřednictvím příslušných mechanismů operačního systému, nebo pomocí specifického SQL příkazu: uživatel je identifikován svým jménem a jako prostředek autentizace slouží heslo. Takový systém vytváří značné potíže pro opakované kontroly a vylučuje takové kontroly před každou transakcí.

Řízení přístupu k databázi je založeno na implementaci následující minimální sady akcí:

libovolná kontrola přístupu;

zajištění opětovného použití předmětů;

používání bezpečnostních štítků;

nucené řízení přístupu.

Libovolné řízení přístupu je metoda omezení přístupu k objektům na základě identity subjektu nebo skupin, do kterých subjekt patří. Tato technologie poskytuje vlastníkovi objektu (pohledu, databázového serveru, procedury, tabulky) převod práv na jinou osobu dle vlastního uvážení. Touto osobou v této situaci může být subjekt uživatele, skupina uživatelů.

Hlavní výhodou libovolného řízení přístupu je flexibilita. Přidružené charakteristiky, jako je rozptýlené řízení a složitost centralizovaného řízení, však vytvářejí mnoho problémů pro bezpečnost dat.

Pozornost by měla být věnována také zajištění bezpečnosti opakovaného použití databáze subjekty. Znamená to odnětí práv vstupu do informačního systému všem uživatelům, kteří z organizace odešli.

Bezpečnostní štítek se skládá ze dvou částí: úrovně zabezpečení a seznamu kategorií. První komponenta závisí na aplikaci a ve standardním případě může vypadat jako rozsah hodnot od přísně tajné po netajné. Druhá složka umožňuje popsat předmětnou oblast, přičemž informace rozděluje do přihrádek, což přispívá k lepší bezpečnosti. Mechanismus bezpečnostních štítků neruší, ale doplňuje libovolnou kontrolu přístupu: uživatelé mohou nadále pracovat s tabulkami pouze v rámci svých oprávnění, přijímat pouze část dat. Hlavním problémem používání bezpečnostních štítků je zachování jejich integrity. To znamená, že všechny objekty a předměty musí být označeny a štítky musí zůstat platné pro jakékoli operace s daty.

Vynucená kontrola přístupu je založena na shodě bezpečnostních štítků předmětu a objektu. Aby bylo možné číst informace o objektu, musí štítek subjektu dominovat nad štítkem objektu. Při provádění operace zápisu informací do objektu musí bezpečnostní štítek objektu dominovat nad štítkem subjektu. Tento způsob řízení přístupu se nazývá nucený, protože nezávisí na vůli subjektů. Uplatnění našel v DBMS, vyznačující se zvýšenými bezpečnostními opatřeními.

Zajištění integrity dat není o nic méně důležité než řízení přístupu. Z pohledu uživatelů DBMS jsou hlavním prostředkem zachování integrity dat omezení a pravidla. Omezení mohou být obsažena přímo v relačním datovém modelu, nebo je lze nastavit při vytváření tabulky. Omezení tabulky mohou odkazovat na skupinu sloupců, jednotlivé atributy. Referenční omezení jsou zodpovědná za udržování integrity vztahů mezi tabulkami. Omezení jsou uložena vlastníkem tabulky a ovlivňují výsledek následných operací s daty. Pravidla umožňují provádět určité procedury, když dojde k určitým změnám databáze. Na rozdíl od omezení, která poskytují kontrolu nad relativně jednoduchými podmínkami, pravidla umožňují kontrolovat a udržovat vztahy jakékoli složitosti mezi datovými položkami v databázi. Při použití pravidel jako nástroje zabezpečení informací je však chyba ve složitém systému pravidel zatížena nepředvídatelnými důsledky pro celou databázi.

Protokolování a audit se skládají z následujícího:

odhalování neobvyklých a podezřelých akcí uživatelů a identifikace osob, které se těchto akcí dopustily;

posouzení možných následků porušení;

Poskytování pomoci;

organizace pasivní ochrany informací před nezákonným jednáním uživatele.

Problém ochrany komunikace mezi klientem a serverem v informačních systémech není specifický pro DBMS. Pro zajištění ochrany informací je přidělena bezpečnostní služba, mezi jejíž funkce patří autentizace, šifrování a autorizace.

Hlavní zdroj hrozeb pro DBMS však spočívá v samotné povaze databází. Často nutné, ale nedostupné informace o stavu lze získat dedukcí. Například pomocí operace add, spíše než operace select (která nemá žádná práva), je možné analyzovat výstupní kódy příkazů SQL. K boji s těmito hrozbami se používá mechanismus násobení řetězců DBMS, který podporuje bezpečnostní štítky. Agregace je metoda získávání nových informací kombinací legálně získaných dat z různých databázových tabulek. 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.

• Dudkina Anastasia Sergejevna, bakalář, student
• Baškirská státní agrární univerzita

• OCHRANA
• PHPMYADMIN
• MySQL
• DATABÁZE

Článek pojednává o hlavních oblastech ochrany dat uložených nebo zpracovávaných v systémech pro správu databází (DBMS). Popisuje, jak chránit důvěrnost a integritu informací pomocí snadno použitelných nástrojů zabudovaných do DBMS.

• Informační technologie interakce v obecní správě
• O některých vlastnostech rozšířených struktur na rozdělení bimetrických variet
• Na třídě rozšířených bimetrických struktur na distribucích sub-Riemannových variet
• Vizuální znázornění statistických dat pomocí bublinového grafu

V současné době se téměř žádná moderní organizace neobejde při své činnosti bez využití databází. Databáze (DB) jsou nejvýznamnějším a nejcennějším aktivem každé společnosti. Vzhledem k tomu, že v databázi mohou být uloženy velmi citlivé nebo důvěrné informace, je třeba jejich ochranu brát velmi vážně. Jakékoli poruchy v provozu DBMS a databází mohou vést ke katastrofickým následkům.

Mezi hlavní prostředky ochrany informací patří:

• ochrana heslem;
• ochrana polí a záznamů databázových tabulek.
• zřízení přístupových práv k databázovým objektům;
• šifrování dat a programů;

Ochrana databáze se provádí na dvou úrovních:

• na úrovni hesla;
• na úrovni uživatele (ochrana uživatelských účtů a identifikovaných objektů).

PhpMyAdmin je PHP program navržený pro správu serveru MySQL přes World Wide Web. phpMyAdmin podporuje širokou škálu operací MySQL. Nejčastěji používané operace jsou podporovány prostřednictvím uživatelského rozhraní (správa databáze, tabulky, pole, vztahy, indexy, uživatelé, oprávnění atd.) a současně můžete přímo spouštět libovolný SQL dotaz.

Zajištění informační bezpečnosti vyvíjeného projektu probíhá na několika úrovních. Na první úrovni ochranu informací zajišťuje samotný systém phpMyAdmin, počínaje vchodem do ovládacího panelu, kde panel vyžaduje zadání přihlašovacího jména a hesla.

Další úroveň ochrany poskytuje MySQL DBMS, rovněž vymezující přístupová práva.

Kromě toho je také možné omezit přístup nejen k samotnému systému správy databází, ale i samostatně k databázím, k databázovým tabulkám, k záznamům konkrétních tabulek a dokonce i k hodnotám tabulky nebo polí záznamu. Je třeba poznamenat, že vestavěné šifrovací funkce nejsou přítomny ve všech DBMS. Tuto metodu proto nelze nazvat univerzální. Tento DBMS nabízí dvě identické sady šifrovacích funkcí, z nichž jedna implementuje algoritmus DES a druhá - AES. Kromě toho MySQL implementuje několik hashovacích algoritmů. Sada kryptografických funkcí tohoto DBMS vypadá takto:

Tabulka 1. Kryptografické funkce DBMS

Funkce šifrování dat AES používají 128bitový šifrovací klíč, tj. šifrování pomocí 192bitových a 256bitových klíčů AES není v MySQL implementováno. Šifrovací klíč je specifikován explicitně jako jeden z parametrů funkce. Naproti tomu funkce DES_ENCRYPT() a DES_DECRYPT(), které šifrují pomocí algoritmu TripleDES, kromě explicitního zadání šifrovacího klíče umožňují nejjednodušší možnost správy klíčů ve formě souboru klíčů obsahujícího vyčíslené hodnoty klíčů. Tyto funkce jsou však ve výchozím nastavení zakázány, pro jejich použití je nutné povolit podporu protokolu SSL v konfiguraci DBMS.

Funkci ENCRYPT() lze použít pouze v operačních systémech Unix, protože šifruje data pomocí systémového volání crypt(). Pokud jde o použité hashovací funkce, dokumentace MySQL varuje, že základní algoritmy jsou hacknuty (toto je podrobně popsáno v , takže je třeba je používat opatrně. MySQL však zatím nenabízí robustnější funkce. Kryptografické funkce uvedené výše jsou také velmi snadné použití, například následující dotaz vloží do tabulky tabulky hodnotu „text“ zašifrovanou klíčem „password“: INSERT INTO table VALUES (1, AES_ENCRYPT("text", "password" )); Všimněte si, že formát pole, do kterého je zašifrovaná hodnota zapsána, musí vyhovovat omezením daným použitým kryptografickým algoritmem - v tomto případě musí být binární (například typu VARBINARY) a předpokládat zarovnání podle 128bitového velikost bloku algoritmu AES .

Systém ochrany databází hraje důležitou roli při automatizaci řízení akcí uživatelů pracujících s databázemi, ochraně před vnějšími a vnitřními hrozbami a zvyšování spolehlivosti provozu databáze.

Bibliografie

1. Melnikov, V.P. Informační bezpečnost a ochrana informací. / V.P. Melnikov,
2. S.A. Kleymenov, A.M. Petrakov // 3. vyd., ster. - M.: Akademie, 2008. - 336 s.
3. Panasenko S.P. Komplexní ochrana informací. // Informační technologie. -2001 - č. 3 - str. 14-16
4. Pracovní program oboru "Informační bezpečnost": směr školení 080500 Podniková informatika [Elektronický zdroj]: profil školení Informační systémy v podnikání: kvalifikace (stupeň) absolventa Bakalář / Bashkir State Agrarian University, [katedra. informatika a informační technologie; komp. A. R. Basyrov]. - Ufa: [b. and.], 2013. - 16 s. - Před naším letopočtem.
5. Stránky PHP webové aplikace "phpMyAdmin" [Elektronický zdroj]. – Režim přístupu: http://www.phpmyadmin.net/home_page/ , zdarma