Bankovní institut vysoká škola Praha Katedra informačních technologií a elektronického obchodování
Implementace Oracle Advanced Security Diplomová práce
Autor:
Bc. Radek Zela Informační technologie a management
Vedoucí práce:
Praha
Ing. Jiří Rezler
Duben 2010
Prohlášení Prohlašuji, že jsem diplomovou práci zpracoval samostatně a s použitím uvedené literatury.
V Praze dne 26. dubna 2010
Radek Zela
Poděkování Mému vedoucímu práce Ing. Jiřímu Rezlerovi za čas, který věnoval mé práci. Mojí manželce Michale za trpělivost a podporu.
Anotace práce Jméno a příjmení autora:
Radek Zela
Instituce:
Bankovní institut vysoká škola Praha
Název:
Implementace Oracle Advanced Security
Počet stran:
84
Počet příloh:
5
Počet titulů bibliografie:
13
Klíčová slova:
algoritmus,
analýza
rizik,
bezpečnost,
bezpečnostní politika, bezpečnostní riziko, databáze, šifrovací klíč, datový soubor, databázový
systém,
hacker,
šifrování,
autentizace,
integrita,
škodlivý
software,
tabulka, tabulkový prostor
Práce se zabývá implementací produktu Oracle Advanced Security do prostředí databázového systému Oracle. Je rozdělena do tří kapitol. V úvodní kapitole jsou obecně popsána nejčastější bezpečnostní rizika a hrozby, kterým je nutné v jakékoliv počítačové síti čelit. V krátkosti jsou nastíněny i některé způsoby útoku proti počítačové síti nebo konkrétním částem informačního systému, které často používají hackeři. Ve druhé kapitole je představen produkt Oracle Advanced Security a je předestřeno, které hrozby je možné použitím tohoto produktu omezit nebo prakticky zcela eliminovat. Poslední kapitola se zabývá vlastní implementací vybraných funkčností tohoto produktu do prostředí databázového systému Oracle. Annotation Authors’ name:
Radek Zela
Institution:
Bankovní institut vysoká škola Praha
Title:
Implementation of Oracle Advanced Security
Number of pages:
84
Number of annexes:
5
Number of bibliography:
13
4
Keywords:
algorithm, risk analysis, security, security policy, security risk, database, encryption key, datafile,
database
encryption,
system,
authentication,
hacker,
data
integration,
malware, table, tablespace Work deals with the implementation of Oracle Advanced Security in environment of Oracle database system. It is divided into three chapters. The introductory chapter describes in general the most common security risks and threats, which are necessary in any computer network to deal with. There are briefly outlined some ways of attacks against computer network or specific parts of an information system, which are often used by hackers. The second chapter introduces the Oracle Advanced Security product with suggestions which threats can be reduced or almost eliminated by use of this product. The last chapter deals with its own implementation of selected functionality of this product into the Oracle database system environment.
5
Obsah Úvod
....................................................................................................................... 8
1. Bezpečnostní rizika v počítačových sítích ................................................................. 10 1.1.
Lidé ...................................................................................................................... 10
1.1.1.
Vlastní zaměstnanci ..................................................................................... 10
1.1.2.
Hackeři ........................................................................................................ 11
1.2.
Škodlivé programy .............................................................................................. 14
1.2.1.
Viry .............................................................................................................. 15
1.2.2.
Trojské koně ................................................................................................ 15
1.2.3.
Červi ............................................................................................................ 15
1.3.
Podvodné jednání ................................................................................................ 16
1.3.1.
Falešné antiviry ........................................................................................... 17
1.3.2.
Phishing ....................................................................................................... 18
1.4.
Odcizení ............................................................................................................... 19
2. Představení Oracle Advanced Security ..................................................................... 20 2.1.
Šifrování uložených dat ....................................................................................... 23
2.1.1.
Šifrování sloupců v tabulkách ..................................................................... 25
2.1.2.
Šifrování tabulkových prostorů ................................................................... 26
2.2.
Šifrování a datová integrita síťové komunikace .................................................. 27
2.3.
Silná autentizace .................................................................................................. 30
2.3.1.
SSL autentizace ........................................................................................... 32
2.3.2.
RADIUS autentizace ................................................................................... 32
2.3.3.
Kerberos autentizace ................................................................................... 33
2.4.
Šifrování záloh..................................................................................................... 33
2.5.
Zhodnocení možností produktu ........................................................................... 33
3. Implementace Oracle Advanced Security ................................................................. 36 3.1.
Nástroje pro konfiguraci a správu ....................................................................... 36
3.1.1.
Oracle Net Manager .................................................................................... 36
3.1.2.
Oracle Wallet Manager................................................................................ 37
3.2.
Šifrování síťové komunikace............................................................................... 38 6
3.2.1.
Nativní šifrování .......................................................................................... 40
3.3.
Datová integrita přenášených dat ........................................................................ 44
3.4.
Šifrování uložených dat ....................................................................................... 45
3.4.1.
Vytvoření hlavního šifrovacího klíče .......................................................... 46
3.4.2.
Šifrování tabulkových prostorů ................................................................... 49
3.4.3.
Šifrování sloupců tabulek ............................................................................ 52
3.5.
Implementace SSL............................................................................................... 56
3.5.1.
Certifikáty .................................................................................................... 56
3.5.2.
Konfigurace SSL na serveru ........................................................................ 58
3.5.3.
Konfigurace SSL na klientovi ..................................................................... 60
3.5.4.
Konfigurace volitelných parametrů ............................................................. 62
4. Výsledky ..................................................................................................................... 65 4.1.
Oracle Network Manager .................................................................................... 65
4.2.
Šifrování existujících sloupců tabulek................................................................. 67
4.3.
Vytvoření šifrovaného tabulkového prostoru ...................................................... 70
4.4.
Použití indexů ...................................................................................................... 71
4.5.
Čitelnost dat v indexech ...................................................................................... 75
Závěry a doporučení.......................................................................................................... 77 Seznam použité literatury ................................................................................................. 79 Seznam zkratek .................................................................................................................. 80 Seznam schémat, tabulek a obrázků ................................................................................ 81 Seznam příloh .................................................................................................................... 84
7
Úvod Počítačová síť je dnes nepostradatelná pro každou alespoň trochu větší firmu, bez ohledu na obor podnikání. Každá firma potřebuje vést účetnictví, mít přehled o skladových zásobách, o objednávkách svých klientů a podobně. Současně jsou dnes v interních informačních systémech běžně využívány i informace získávané z datových skladů a CRM systémů. Vzhledem k potřebě firmy komunikovat elektronickou formou se svým okolím, ať již jde o dodavatele, zákazníky, banky či státní úřady, je standardem též připojení počítačové sítě na internet. Zvyšující se kapacita pevných disků za současného poklesu jejich cen umožnila uchovávat v databázích i historické údaje, zatímco dříve je bylo nutné archivovat na magnetické pásky nebo rovnou odmazávat. Různé techniky pro dolování dat (data mining) umožňují spolu s CRM systémy tyto údaje skutečně aktivně využívat. Se zvyšujícím se množstvím dat uchovávaným v různých databázích roste i hodnota těchto databází. Tím však roste i riziko, že se na takovou databázi zaměří nějaký útočník či jejich skupina s cílem do takové databáze proniknout. Připojení interní počítačové sítě k internetu poskytuje útočníkům mnoho potencionálních cest, kterými se mohou pokusit získat interní data z databází. Údaje z databáze pak mohou být zneužity, což může vést nejenom k poškození jména firmy, ale podle zákona č. 101/2000 Sb., o ochraně osobních údajů, může být odpovědné fyzické či právnické osobě uložena vysoká pokuta, podle závažnosti přestupku může být její výše až v řádu milionů korun. Ohrožení pro data v databázích však mohou představovat i různé druhy škodlivého software, pro práci s počítači nedostatečně proškolení zaměstnanci a v neposlední řadě také odcizení hardware. V této práci chci čtenáře v krátkosti seznámit s riziky, které mohou ohrozit interní počítačovou síť. Dále představím produkt Oracle Advanced Security, který umožňuje více zabezpečit data v databázovém systému Oracle v souladu s principy hloubkové ochrany a analyzuji jeho možnosti pro pokrytí různých druhů ohrožení. Na modelovém případě pak čtenáře blíže seznámím s nasazením klíčových funkčností tohoto produktu do prostředí databázového systému Oracle verze 11g. Veškeré modelové příklady budou demonstrovány na prostředí databázového systému Oracle 11g instalovaném na platformě Red Hat Enterprise Linux, klient je pak instalován na platformě Microsoft Windows XP Professional. Příkazy operačního systému používané v příkladech 8
nemusejí být relevantní v jiných operačních systémech, používaná řešení tudíž nelze automaticky bez úprav aplikovat do jiného prostředí. Rovněž chování nasazovaných komponent se může na různých platformách mírně odlišovat v závislosti na jejich implementaci na příslušnou platformu. Dosažené výsledky tudíž není možné považovat za 100% přenositelné na jiná prostředí, rozdíly však budou hlavně v oblasti jiného způsobu implementace, popřípadě problémů typických pro použitou platformu, nikoliv v oblasti funkčnosti produktu.
9
1.
Bezpečnostní rizika v počítačových sítích
Počítačové sítě a všechny jejich prvky od serverů až po jednotlivé personální počítače jsou dnes ohrožovány celou řadou hrozeb. V důsledku připojení k celosvětové síti internet pak hrozí vedení útoku odkudkoliv z celého světa, čímž se současně velmi snižuje šance na dopadení útočníka. Je však třeba pamatovat na to, že veškerá bezpečnostní rizika musí být ošetřena komplexně a v souladu s bezpečnostní politikou firmy. Prostředky vynaložené na ochranu pouze proti jednomu typu ohrožení při zanedbávání ostatních hrozeb jsou v konečném důsledku vynaloženy neefektivně. Často se tak firma zaměřuje na technickou stránku, ale opomíjí fakt, že uživatelem je člověk se svými slabými stránkami. Je třeba se chránit proti všem typům ohrožení, avšak současně je třeba si uvědomit, že interní síť nelze nikdy ochránit na 100%. Hrozby můžeme pro větší přehlednost rozdělit do několika skupin, i když tyto skupiny se částečně překrývají a prolínají. Těmito skupinami jsou lidé (jako aktivní útočníci), škodlivé programy, ohrožení v důsledku oklamání uživatelů, posledním specifickým typem ohrožení je odcizení některých komponent počítačové sítě.
1.1. Lidé Člověk samozřejmě stojí za každým typem útoku v celé jejich škále, ať se jedná o napadení virem, útok hackera, nebo odcizení například serveru. V této souvislosti však budeme chápat člověka jako aktivního fyzického útočníka.
1.1.1. Vlastní zaměstnanci Vlastní zaměstnanci jsou vždy největším bezpečnostním rizikem interních informačních systémů. Velmi často je uváděn odhad, že až 80% 1 bezpečnostních incidentů mají na svědomí útočníci z interní sítě, ať již jde o vlastní zaměstnance nebo najaté pracovníky externí firmy. Převážná část těchto incidentů je však způsobena chybným postupem práce s informačním systémem, případně nedbalostí a nedostatečnou kontrolou. Jelikož zaměstnanci musí mít pro svou práci přístup k různým údajům včetně citlivých, lze riziko nějaké formy útoku ze strany zaměstnance pouze snížit, a to přidělováním pouze
1
Stejný odhad lze nalézt ve více zdrojích, například dokumentace Oracle Database 10g, Oracle Security
Overview - Top Security Myths 10
nezbytných oprávnění, zvyšováním loajality k zaměstnavateli a v neposlední řadě důsledně prováděným a hlavně pravidelně vyhodnocovaným auditem vykonávaných operací. Velkým rizikem se však pro firmu mohou stát pro práci s informačními systémy nedostatečně proškolení zaměstnanci. Důvodem je jejich menší odolnost v případě, že se jich útočník snaží zneužít za použití metod sociálního inženýrství.
1.1.2. Hackeři V předchozí kapitole bylo řečeno, že většinu útoků mají na svědomí lidé, mající z povahy své práce přístup do interní firemní sítě, ať již jde o vlastní zaměstnance, nebo o různé externisty. Skutečností však zůstává, že útok profesionála z řad hackerů může mít pro firmu závažnější důsledky, jelikož takoví lidé mají dostatek znalostí nejen k proniknutí do informačního systému, ale i k zahlazení stop po svém útoku. Firma tak často nemusí vědět, že byl jejich systém napaden a byly odcizeny například citlivé údaje. Pod skupinou lidí nazývaných hackery však najdeme širokou škálu lidí s různou úrovní počítačových znalostí. Většina hackerů se pouze snaží využít nalezených bezpečnostních nedostatků v různých systémech. K tomu používá zejména různé programy a postupy stažené z internetu. Nemají však dostatek znalostí k tomu, aby vedli útok cílený na konkrétní firmu. Opravdovou hrozbou tak jsou výše zmínění profesionálové. Forma jejich útoku se může vymykat běžným postupům a je tedy těžko předvídatelná. Tím je i obrana proti nim obtížná. Hrozí i riziko, že se takovýto profesionální hacker v rámci přípravy útoku nechá ve firmě zaměstnat, čímž se mu zjednoduší přístup k interním sítím, navíc tak má možnost lépe poznat bezpečnostní prvky a procedury ve firmě. Útočníkům však k průniku do informačního systému pomáhá i jejich jiný náhled na informační systém jako celek. Příkladem může být již pouhá oblast různých interních předpisů - firemní bezpečnostní pracovníci i administrátoři systémů jsou si vědomi existence různých vnitřních bezpečnostních předpisů a nařízení, proto většinou příliš nepočítají s tím, že by toto někdo z interních pracovníků porušoval, jelikož překročení těchto nařízení lze snadno dohledat například v auditních záznamech. Některé oblasti bezpečnosti tak mohou být pokryty především těmito nařízeními. Pete Finnigan v rámci svých seminářů zaměřených na bezpečnost v prostředí Oracle doporučuje posluchačům k překlenutí tohoto rozdílného pohledu na systém pokusit se přistupovat k bezpečnostní problematice z pohledu útočníka, to znamená zkoušet různé postupy a přemýšlet jako útočník, doslovně „The solution: Try and think like a hacker – be suspicious“[4]. Tento 11
přístup by se tak měl stát východiskem ke kritickému pohledu na zabezpečení vlastního informačního systému. Hackeří však většinou zkoušejí použít techniky, jejichž princip je obecně znám. Z těchto typů útoků si přibližme alespoň některé z nich - spoofing, man-in-the-middle, eavesdropping, SQL Injection, DoS, buffer overflow a session stealing. Poznámka - tyto útoky jsou v odborné literatuře občas nazývány i jinými jmény, nebo je možné narazit na jejich český překlad, takže je rozlišování útoků trochu nepřehledně. Podstata útoku je ale stejná, což je patrné z jejich bližšího popisu. Pokud se lze s těmito odlišnými jmény setkat častěji, jsou u příslušného typu útoku zmíněny. Spoofing – při tomto typu útoku se útočník vydává za někoho či něco jiného. Tento typ útoku má mnoho variant, kdy se útočník může vydávat za jiného uživatele e-mailu (e-mail spoofing), jiný počítač (DNS spoofing), jiná internetová adresa (URL spoofing) a mnoho dalších variant, například níže popsaný MITM. Man-in-the-middle (MITM) – je variantou útoku typu spoofing v oblasti síťových přenosů dat, kdy útočník aktivně vstupuje do komunikace mezi jinými stranami. Útočník se tak stává prostředníkem komunikace mezi těmito stranami, řekněme 1 a 2. Straně 1 předstírá, že je strana 2 a naopak. Současně může aktivně měnit data vyměňovaná mezi původními stranami komunikace. Tato situace je znázorněna na následujícím obrázku: Obrázek 1.
Útok typu MITM na síťovou komunikaci.
Zdroj: Nákres autora práce
Útočník tak může například změnit velikost bankovního vkladu, na účet je tak připsána jiná (útočníkem modifikovaná) částka, než jaká byla zadána pokladníkem na bankovní pobočce. Firma Oracle označuje ve svých dokumentech tento typ útoku častěji jako Data Tampering.
12
Eavesdropping – při tomto typu útoku útočník „odposlouchává“ komunikaci jiných uživatelů. Takto útočník může zachytit třeba nezabezpečeně přenášená hesla2 nebo citlivá data. Velkým nebezpečím je, že odposlouchávaní účastníci komunikace o faktu, že jsou jimi odesílaná data zachycována a kopírována vůbec nevědí, neboť z podstaty digitálně přenášených dat lze tato data libovolně kopírovat bez jakékoliv změny původních dat. O skutečnosti, že je komunikace zachycována, se tak mohou účastníci komunikace dozvědět až z případného zneužití zachycených dat. Tento typ útoku bývá někdy označován jako sniffing (doslova čichání, očichávání), zařízení pro odposlech komunikace je označováno jako sniffer. SQL Injection – jde o útok, jehož cílem je získat neautorizovaný přístup k datům v databázi. Využívá k tomu podsunutí vlastního kódu do prováděného SQL dotazu na úrovni aplikační vrstvy. Pokud není v aplikaci ošetřen vstup, může provést pozměněný dotaz a vrátit data, která jinak nejsou (a nemají být) v aplikaci dostupná.[8] DoS (zkratka z anglického názvu Denial of Service) útok je veden proti dostupnosti služby. Každá služba má zdroje dimenzovány na určitou kapacitu, pokud je tato kapacita překročena, neúnosně se prodlouží odezvy takto přetíženého systému. To je i cílem tohoto typu útoku. Pokud jsou například stránky s internetovým bankovnictvím zahlceny třeba různými chybnými pokusy o přihlášení, nemůže se v důsledku přihlásit ani jejich skutečný uživatel. Variantou útoku DoS je Distributed DoS (DDoS), kdy útočník na svůj cíl útočí současně z většího množství počítačů. Jejich skuteční uživatelé o této činnosti prováděné z jejich počítačů zpravidla vůbec netuší, jelikož útočník v rámci příprav útoku získal nad jejich počítači kontrolu. Každý takový počítač pak vystupuje jako bot 3 v celé síti takovýchto počítačů, nazývané botnet. Útok DDoS je pak veden z takovéhoto botnetu. Buffer overflow – lze přeložit jako přetečení paměti, využívá skutečnost, že program správně nekontroluje velikost svých dat v paměti. Jestliže se aplikace bude snažit umístit příliš velké množství dat do vyrovnávací paměti (bufferů), data „přetečou“ a mohou se zapsat do jiných míst paměti. Současně se spustí škodlivý kód přidaný útočníkem, který například změní přístupová práva uživatele.[9]
2
Záleží na typu používaných služeb a programů, zda komunikaci šifrují – například protokol telnet v čitelné
formě odesílá i hesla. 3
Bot je zkratkou z názvu robot. Jde o počítačový program, který v prostředí internetu vykonává nějakou
činnost. Hacker může takovýto bot instalovat na napadené počítače a zneužívat je tak pro své účely. 13
Session stealing (odcizení relace), často také nazývaný jako session hijacking, je založen na získání ID (identifikátoru) klientské session a jeho následném použití pro identifikaci na serveru. Výše uvedené techniky se v praxi různě prolínají, například útok typu session stealing může být proveden na základě zachycené komunikace (eavesdropping) mezi klientem a serverem a podobně. K přípravám aktivního útoku však samozřejmě slouží i specifické programy, například typu trojské koně či metody sociálního inženýrství, například phishing, které jsou popsané v následujících kapitolách.
1.2. Škodlivé programy Jako škodlivé programy (v angličtině nazývané malware) označujeme všechny programy, které svou činností nějakým způsobem poškozují uživatele. Jejich činnost se může projevovat různým způsobem, od jinak poměrně neškodného zobrazování různých textů na obrazovce, přes destruktivní činnosti (třeba smazání některých souborů nebo celého disku), až po rozesílání zpráv nezávisle na vůli uživatele. Mohou však také zachytávat například hesla zadávaná z klávesnice a případně je odesílat pomocí internetu potencionálnímu útočníkovi. Základním prvkem obrany proti škodlivým programům je kvalitní antivirový program, nutným předpokladem jeho účinnosti proti nejnovějším škodlivým programům je jeho pravidelná aktualizace. Důvodem je, že antivirové programy fungují zpravidla na dvou principech, a to porovnáváním signatur (jako hlavní způsob detekce) a heuristickou analýzou. Při porovnávání signatur je porovnáván obsah operační paměti nebo souborového systému zkoumaného počítače s databází signatur škodlivých programů, neaktuální databáze tedy znamená riziko, že daná signatura nebude k dispozici v čase výskytu škodlivého programu. Heuristická analýza se pak snaží vyhledat škodlivý software pomocí speciálních algoritmů. Podle způsobu činnosti rozlišujeme tři hlavní kategorie škodlivých programů, a to viry, trojské koně a červy. Je možné používat i jiné způsoby kategorizace škodlivých programů, například podle účelu, za jakým byl daný škodlivý program vytvořen. Použité rozlišení vychází z knihy Tomáše Doseděla [1], jelikož dobře rozlišuje jednotlivé skupiny škodlivého software podle jejich činnosti.
14
1.2.1. Viry Pro šíření virů je nezbytný nějaký hostitel, například spustitelný soubor, jehož virus infikuje přidáním svého kódu k tomuto souboru. Nadále se pak šíří jeho prostřednictvím. Virus může také napadat boot sektor počítače, tak zajistí svoji aktivaci ihned při zapnutí počítače. Velký počet virů tyto dvě možnosti svého šíření a aktivace kombinuje, pokud tedy uživatel spustí nakažený soubor na svém počítači, virus se aktivuje, napadá další soubory, současně však infikuje i boot sektor. V dnešní době není šíření výše zmíněných typů virů tak časté, jako tomu bylo v minulosti. Důvodem je zejména vyšší složitost dnešních programů spojená s nutností tyto programy instalovat. Podstatně se tak omezilo dříve velmi časté šíření virů například pomocí disket, na nichž se nacházely infikované spustitelné soubory. Místo těchto virů se však dnes rozšířil jiný typ, využívající pro své šíření dokumenty – makroviry. Tento typ virů je navíc multiplatformní, pokud pro příslušnou hardwarovou platformu existuje využívaný software (makroviry jsou většinou zaměřeny na některý z balíků kancelářských programů4), makrovir je zpravidla funkční i na této platformě. [1]
1.2.2. Trojské koně Jako trojské koně je označována skupina škodlivého software, která se vůči uživateli chová jako nějaké užitečné programy. Skutečným účelem je však činnost, kterou trojský kůň provádí skrytě na pozadí, například zachytávání uživatelem zadávaných hesel. Takto zaznamenaná hesla pak může prostřednictvím internetu předávat svým tvůrcům. Může však i sledovat chování uživatele, například uživatelem používané programy, navštěvované internetové stránky a podobně. Tyto údaje opět odesílá pomocí internetu. Tento typ trojských koní je nazýván spyware.
1.2.3. Červi Červi5 se na rozdíl od virů šíří pomocí počítačové sítě, nepotřebují tak ke svému šíření infikovaný hostitelský soubor. Červ se tak velmi často šíří prostřednictvím elektronické pošty, kdy se sám rozešle na adresy, které nalezne v adresáři napadeného e-mailového
4
Nejčastěji jde o kancelářský balík Microsoft Office, a to zejména z důvodu jeho velkého rozšíření.
5
První červ se objevil již v roce 1988, jako vůbec první zdokumentovaný výskyt škodlivého software. Jeho
tvůrce Robert T. Morris pro jeho šíření využil chyby v programu sendmail. 15
klienta. Může se však šířit třeba i pomocí internetových stránek, otevřených portů počítače a podobně. Nový červ se může šířit velmi rychle, proto někdy jeho šíření v interní síti nemusí zastavit ani rezidentní antivirový software, který je nakonfigurován pro automatické stahování vydaných aktualizací. Příslušná aktualizace nemusí být zatím k dispozici, jelikož ji výrobce antivirového programu zatím nestihl vydat. V těchto případech do jisté míry pomáhá určitá opatrnost uživatelů při práci s příchozími dokumenty. Velké riziko však spočívá v tom, že takovýto infikovaný dokument může přijít z e-mailové adresy například běžných obchodních partnerů, jelikož mají adresáta ve svém seznamu.
1.3. Podvodné jednání Pro tuto kategorii ohrožení je příznačné, že jednání útočníka není zaměřeno přímo proti informačnímu systému, ale pokouší se nějakým způsobem oklamat jeho uživatele. Od těchto uživatelů se útočník snaží získat zpravidla jejich přihlašovací údaje do systému, ke svému záměru často využívá metod sociálního inženýrství. Ochrana proti tomuto typu útoků je obecně velmi obtížná, neboť s informačním systémem pracují lidé různého stupně počítačových znalostí. Obranou je tak v první řadě školení uživatelů a seznámení s podobnými riziky, bezpečnostní politika firmy by pak měla výslovně zakazovat sdělovat komukoliv své přihlašovací údaje, a to i vlastním firemním informatikům či správcům sítě. Samozřejmostí by pak měl být také zákaz instalovat jakýkoliv software pro koncové uživatele. Velkou překážkou je pro útočníky při tomto typu útoku dvoufaktorová autentizace do informačního systému, která zvyšuje bezpečnost autentizace nutností zadat současně jak standardní přihlašovací údaje (zpravidla jméno a heslo, které však útočník může získat), tak připojením nějakého hardwarového zařízení, popřípadě zadáním kódu generovaného tímto zařízením. Autentizace je pak založena na dvou nezávislých skutečnostech – uživatel něco zná (přihlašovací jméno a heslo), současně však i něco má (hardwarové zařízení). Pro úspěšné proniknutí do informačního systému by tak útočník musel získat nejenom přihlašovací údaje, ale i odcizit příslušné hardwarové zařízení 6 . Příkladem takových
6
Některá tato zařízení mohou být chráněna PIN kódem, bez jehož zadání je není možné použít. V takovém
případě může být přihlášení umožněno na základě připojení zařízení (například do USB portu počítače) a zadání tohoto kódu, bez zadávání standardního uživatelského jména a hesla. 16
zařízení je například čipová karta CryptoPlus ve spojení se čtečkou Gemplus, nebo autentizátor (token) SecurID firmy RSA7, viz obrázek 2. Obrázek 2.
Čtečka Gemplus s čipovou kartou a token SecurID.
Zdroj: Fotografie autora práce. Faktorem autentizace uživatele může být i skutečnost, že autentizovaná osoba má biometrické údaje odpovídající těm, které jsou uloženy v systému. Takovýmito údaji jsou například otisky prstů, odpovídající oční duhovka či sítnice, hlasové charakteristiky a podobně. Používání těchto faktorů však zatím není běžnou praxí (alespoň v sektoru civilních firem). V informačním systému by měla být samozřejmostí politika přidělování minimálních nutných oprávnění pro daného uživatele, aby v případě vyzrazení přihlašovacích údajů měl útočník přístupné co nejmenší množství dat. V této souvislosti je třeba zmínit ještě poplašné zprávy (nazývané hoax), které jsou také zaměřeny přímo na uživatele systému a jejich důvěřivost. Neohrožují přímo bezpečnost dat, může však být ohrožena dostupnost zpravidla e-mailu, jelikož e-mailový server je zahlcen přeposílanými zprávami.
1.3.1. Falešné antiviry Dobrý antivirový program a jeho pravidelná aktualizace jsou jedním ze základních pilířů zabezpečení každého počítače. Této skutečnosti zneužívají různí jednotlivci či celé skupiny podvodníků, které se snaží buď prodat falešný antivirový program (v angličtině nazývaný
7
Více o těchto zařízeních je možné nalézt na internetových stránkách výrobců: http://www.monetplus.cz/ ,
http://www.gemalto.com/ , http://www.rsa.com/ . 17
scareware), nebo přinutit uživatele, aby sám stáhl na svůj počítač škodlivé programy, které se za antivirový software vydávají. K tomu využívají například falešná hlášení o výskytu viru na uživatelově počítači s nabídkou antivirového programu ke stažení, nebo třeba i reklamních bannerů na různých internetových stránkách. Tento typ útoku je tak poměrně nebezpečný, neboť nepoučený uživatel snadno podlehne falešným varováním, zejména pokud toto varování nebo nabídku obdrží na důvěryhodných internetových stránkách. Pod jejich dojmem pak dobrovolně nainstaluje například škodlivý software, veden snahou urychleně odstranit virus ze svého počítače. Známým případem je nabídka falešného antiviru na internetových stránkách listu The New York Times v září 20098, kdy byl čtenářům nabízen takovýto falešný antivir formou popup okna varujícího před virem, s přesměrováním na stránku s nabídkou příslušného antivirového programu pro jeho odstranění. Riziko útoku pomocí falešných antivirů se v dnešní době stále zvyšuje a stává se momentálně jednou z nejrozšířenějších hrozeb.
1.3.2. Phishing Phishingem rozumíme podvodné zprávy, které mají přimět důvěřivého uživatele k vyzrazení citlivých údajů, například přihlašovacích údajů do internetového bankovnictví. K šíření svých zpráv používají útočníci nejčastěji e-mail, do kterého umístí zprávu zpravidla vyžadující, aby uživatel zadal své přihlašovací údaje. Adresy v internetových odkazech ve zprávě vypadají velmi podobně, jako skutečná adresa, uživatele se však kliknutím na takový odkaz dostane na podvodné stránky. Stránky jsou často velmi přesnou napodobeninou originálních stránek, proto uživatel může v dobré víře provést požadované úkony a sám tak předat citlivé údaje útočníkovi. Vzhledem k tomu, že útočník většinou rozesílá své podvodné zprávy „naslepo“, aniž by znal konkrétní e-mailové adresy skutečných zákazníků napadené firmy, jsou útoky nejčastěji vedeny proti velkým firmám. U takových firem je největší šance, že zprávu obdrží skutečný zákazník dané firmy. Phishing je tak nejčastěji zaměřen na firmy jako jsou například PayPal, eBay nebo velké banky 9 . Hodně útoků je však v poslední době
8 9
Zdroj: http://www.nytimes.com/2009/09/15/technology/internet/15adco.html?_r=1 (cit 2010-01-15). Podrobnější
statistiky
o
nejvíce
napadaných
http://www.phishtank.com . 18
firmách
jsou
zveřejňovány
například
zde:
směřováno také na internetový vyhledávač Google (spolu s jeho dalšími službami) a sociální síť Facebook. Phishingovým útokům jsou však vystaveny i české firmy, dobře známý je například útok, který byl v minulosti veden na Českou spořitelnu.
1.4. Odcizení Při budování zabezpečené sítě je potřeba neustále pamatovat na to, že veškeré prostředky vynaložené na hardwarovou a softwarovou ochranu dat 10 jsou (s výjimkou dostatečně silného šifrování dat) neúčinné, pokud jsou servery a jejich disková pole nedostatečně chráněny proti fyzickému odcizení. Zabezpečení serverovny vhodnými prostředky fyzické ochrany (bezpečnostní dveře, mříže, ostraha objektu a podobně) proto musí být samozřejmostí. Důležité je i vést evidenci vstupů do takto chráněných prostor, například pomocí různých elektronických čteček pro kontrolu přístupu se současným automatickým zápisem příslušného záznamu do paměti pro možnost pozdějšího vyhodnocení. Snadno zranitelným bodem jsou i zálohy dat uložené na různých zálohovacích médiích. Tato záložní média by měla být uchovávána na odlišném místě (například jiná budova), než jsou umístěny servery. Důvodem je, že tato média jsou primárně určena pro obnovu dat v případě jejich poškození či zničení, a to i v případě například požáru. Z hlediska bezpečnosti je však přeprava těchto záložních médií do jejich úložiště i jejich uchovávání dalším bezpečnostním rizikem. Tato místa je proto nutné chránit prostředky fyzické ochrany11. Důležité je dostatečně chránit nejenom servery a disková pole, ale i ostatní prvky počítačové sítě. Snadného fyzického přístupu například k aktivním síťovým prvků by mohl zneužít například hacker pro odposlech dat.
10
Například na firewally, IDS systémy (systémy detekce narušení), antivirové programy a podobně.
11
Ve velkých firmách jsou zálohy prováděny do oddělených středisek, vybavených zálohovacími roboty
připojenými k interní počítačové síti, odpadá tudíž riziko odcizení při přepravě médií. 19
2.
Představení Oracle Advanced Security
Oracle Advanced Security12 je volitelná a samostatně licencovaná komponenta13 RDBMS Oracle. Pomocí tohoto produktu je možné dosáhnout vyšší bezpečnosti v databázovém systému Oracle, a to šifrováním, zajištěním datové integrity a silnějším ověřováním identity uživatele. Takto zvýšené zabezpečení se stává dalším prvkem ochrany počítačové sítě jako celku podle principů hloubkové ochrany.[9] Produkt však není k dispozici v každé zakoupené verzi databázového software Oracle. Firma Oracle dodává svůj databázový software v různých verzích, takzvaných edicích, takže zákazník si může vybrat edici podle plánovaného využití databázového systému a podle svých předpokládaných potřeb. Edice se pak liší jak možnostmi využití různých doplňkových funkčností, tak samozřejmě cenou produktu. Zákazník tak může podle svých potřeb vybírat z několika edic. Ve verzi Oracle Database 11g je tak možné vybírat od nejjednodušší edice Personal Edition určené pro jednoho uživatele, přes edice Standard Edition One a Standard Edition, až k nejvyšší edici Enterprise Edition, zamýšlené zejména pro rozsáhlé databáze velkých firem a institucí. Edice databázového software Enterprise Edition je také základním předpokladem pro možnost využívat funkčností produktu Oracle Advanced Security. V ostatních edicích produktu nejsou tyto funkčnosti k dispozici. K šifrování ve verzích Standard Edition a Enterprise Edition bez produktu Oracle Advanced Security je však možné použít s databázovým systémem standardně dodávané PL/SQL package DBMS_CRYPTO nebo dřívější
DBMS_OBFUSCATION_TOOLKIT
(tato
package
měla
být
novější
DBMS_CRYPTO nahrazena, ale zatím je stále dodávána[11]). Tyto package však mají určitá omezení. Spočívají v podpoře menšího množství šifrovacích algoritmů a podpoře menšího množství datových typů, které mohou být šifrovány. Zcela zásadní rozdíl ovšem spočívá v nutnosti upravit aplikace, používající v databázi uložená data, takovým způsobem, aby byly za použití vybrané package schopné pracovat s šifrovanými daty.
12
Produkt se nazývá Oracle Advanced Security až od verze RDBMS Oracle 8i, dříve byl nazýván Advanced
Networking Option (jeho funkčnosti byly orientované na síťové přenosy, neumožňoval šifrovat data uložená v databázi). 13
Firma Oracle řadí Oracle Advanced Security mezi volitelné komponenty RDBMS Oracle (takto se rovněž
instaluje), vzhledem k samostatnému licencování a specifickým nabízeným funkčnostem se však bude dále v textu hovořit o produktu, nikoliv o komponentě. 20
Instalace vlastního software produktu Oracle Advanced Security se nijak neliší od instalace ostatních komponent databázového software Oracle. V rámci instalace software RDBMS Oracle se do volitelně instalovaných komponent pouze přidá další produkt. Pro Oracle Advanced Security se toto přidání provede označením příslušné volby (Oracle Advanced Security _číslo verze_) ve skupině produktů Enterprise Edition Options (viz obrázek 3). Obrázek 3.
Výběr produktu Oracle Advanced Security v průběhu instalace
na databázovém serveru.
Zdroj: Kopie obrazovky upravená autorem práce.
Jednotlivé obrazovky z instalace kompletního software Oracle Database verze 11g včetně produktu Oracle Advanced Security jsou zachyceny v příloze 1. Produkt je možné doinstalovat i později do již existující instalace software RDBMS Oracle, opět spuštěním instalátoru databázového software Oracle a označením příslušné volby produktu. Po spuštění instalace jsou pak doinstalovány pouze nově přidané produkty. Produkt je ovšem nutné nainstalovat i na straně klienta databáze. K tomu je zapotřebí spustit „Custom“ instalaci (jednotlivé obrazovky z instalace klienta je možné dohledat v příloze 2), ve firmách je instalace klientů řešena zpravidla silent instalací, kdy se automaticky nainstalují komponenty podle předem připraveného konfiguračního souboru (tento soubor je nazýván response file). Podobně jako při instalaci serveru se označí políčko Oracle Advanced Security (+ číslo verze klienta). 21
Obrázek 4.
Výběr produktu Oracle Advanced Security v průběhu instalace
na klientovi Oracle databáze.
Zdroj: Kopie obrazovky upravená autorem práce.
Konečná cena za implementaci RDBMS Oracle s produktem Oracle Advanced Security je součtem ceny licence na vlastní databázový software Oracle v edici Enterprise Edition pro příslušnou platformu a ceny za licenci k produktu Oracle Advanced Security. Jelikož jsou ceny licencí odvozovány buď od počtu uživatelů14, nebo od počtu procesorů serveru, na kterém je RDBMS Oracle nasazen, může být konečná cena velmi vysoká 15 . Při analýzách a plánování nasazení produktu Oracle Advanced Security je proto nezbytné velmi pečlivě zvážit, zda výsledná cena za ochranu dat bude adekvátní citlivosti a ceně vlastních chráněných dat. Důvodem pro nasazení tohoto produktu však mohou být i legislativní požadavky, nebo požadavky oborových standardů, například PCI-DSS16.
14
V případě licencování podle počtu uživatelů je stanoven i minimální počet uživatelů, pro něž je potřeba
zakoupit licence, ve verzi Enterprise Edition je toto minimum 25 uživatelů na každý procesor. 15
Ceny Oracle Advanced Security viz http://www.oracle.com/corporate/pricing/technology-price-list.pdf ,
případně https://oraclestore.oracle.com (2010-01-08). 16
Payment Card Industry – Data Security Standard, standard předních vydavatelů platebních karet, více
o standardu viz https://www.pcisecuritystandards.org . 22
2.1. Šifrování uložených dat Databázový systém Oracle standardně poskytuje mechanismy pro zabezpečení dat v databázi, ale databázové soubory uložené v operačním systému jsou proti případnému zneužití chráněny pouze prostředky operačního systému. Produkt Oracle Advanced Security však umožňuje šifrovat citlivá data uložená v databázi, čímž je zvýšena odolnost databázového systému i proti případnému útoku vedenému z operačního systému. Firma Oracle nazývá funkčnost, která umožňuje šifrování dat ve sloupcích tabulek nebo v celém tabulkovém prostoru (viz dále) souhrnně jako Transparent Data Encryption. V rámci Transparent Data Encryption jsou podporovány tyto šifry: - 3DES v tříklíčové verzi (3DES168), s efektivní délkou klíče 168 bitů, - AES s šifrovacím klíčem délky 128, 192 nebo 256 bitů17. Defaultním je šifrovací algoritmus AES-192 pro šifrování sloupců v tabulkách, v případě šifrování tabulkových prostorů je to AES-128. Více informací o těchto šifrovacích algoritmech viz příloha 3. Šifrování v rámci Transparent Data Encryption bylo poprvé umožněno ve verzi databázového software Oracle Database 10g release 2. Ve verzi Oracle Database 11g je pak možné šifrovat i celé tabulkové prostory (viz kapitola 2.1.2). Současně však tato vyšší verze zlepšuje zabezpečení dat v tabulkových prostorech používaných pro dočasná data odkládaná například v rámci třídění či sortování (takzvané temporary tablespaces). Důvodem je, že verze 11g pracuje v rámci těchto operací s zašifrovanými daty i v těchto dočasných tabulkových prostorech, verze 10gR2 zde data odkládala v čitelném tvaru. Šifrování je pro aplikace, které šifrovaná data používají, zcela transparentní. Není tedy nutný žádný zásah do aplikačního kódu pro zachování funkčnosti aplikace, šifrování a dešifrování dat je kompletně řízeno databázovým systémem. Aplikační nebo databázový administrátor tak nemusí vytvářet žádné pomocné prostředky pro zpřístupnění šifrovaných dat, například pomocí databázových triggerů, pohledů a podobně. Rovněž ze strany uživatelů není vyžadována jakákoliv součinnost při práci se šifrovanými daty, uživatel si skutečnosti, že data jsou šifrována, vůbec nemusí být vědom. Vlastní šifrování je založeno na řízení přístupů pomocí klíčů. Konkrétní způsob použití klíčů závisí na tom, jaký typ šifrování je v rámci Transparent Data Encryption použit a na
17
Které jsou nazývány jako AES-128, AES-192 a AES-256. 23
zvoleném způsobu šifrování. Podrobněji je používání klíčů rozebíráno v rámci příslušných kapitol. Šifrování však s sebou přináší i některé problémy, jako například zvýšení zátěže systému z důvodu výpočtů šifrovacích algoritmů. V této souvislosti je třeba zmínit, že šifrování pomocí stávajících PKI algoritmů spotřebovává podstatně větší množství systémových zdrojů, než šifrování za pomoci symetrického klíče. Proto například použití PKI klíčů jako hlavního šifrovacího klíče (viz následující kapitola) pro Transparent Data Encryption může mít za následek větší výkonnostní degradaci při přístupu k šifrovaným datům. Před produkčním nasazením je proto vhodné provést výkonnostní testy pro zjištění, zda jsou systémové zdroje dostatečné.[10] Jiné problémy s výkonem se však mohou objevit i ve vlastní databázi, například pokud je šifrovaný sloupec indexován. Index se v takovém případě stává nepoužitelný. Pokud má být index například používán pro zrychlení vyhledávání na základě rovnosti v podmínce select příkazu 18 , po zašifrování je index nepoužitelný, neboť uložené hodnoty jsou šifrované. Optimalizátor 19 tak nemůže vzít index v potaz při hledání nejvhodnějšího prováděcího plánu, místo vyhledávání pomocí indexu je proto proveden full table scan, který může být významně dražší z hlediska potřeby zdrojů potřebných pro vykonání příkazu. V podobných případech je doporučováno vytvořit pomocný identifikátor, který je možné mít nešifrovaný a současně je možné podle něj jednoznačně identifikovat řádek v tabulce. Unikátní hodnoty pro identifikátor je možné generovat například pomocí sekvencí20.[11] Druhou možností je v případě šifrování sloupců tabulek pomocí Transparent Data Encryption nepoužívat defaultní volbu SALT. Tato standardní volba způsobuje, že je k datům v čitelné formě před jejich zašifrováním přidán náhodný řetězec znaků, data jsou pak zašifrována včetně tohoto řetězce. Tím je zajištěna větší odolnost dat proti neoprávněnému dešifrování. Zašifrovaný sloupec bez použití SALT pak může být
18
Například: SELECT jmeno FROM zamestnanci WHERE cislo_karty = 1111222233334444 ;
19
Optimalizátor je součást databázového systému Oracle vyhledávající optimální způsob, jakým bude SQL
příkaz proveden. Při rozhodování o prováděcím plánu optimalizátor přihlíží k celé řadě parametrů (například statistiky o objektech, podmínky v dotazu, priority optimalizátoru apod.), podle kterých rozhodne, jak bude vypadat prováděcí plán pro daný SQL příkaz – zda použije index, provede full table scan a podobně. 20
Sekvencí v tomto případě rozumíme unikátní celé číslo generované sekvenčním generátorem. V DBS
Oracle je možné vytvořit novou sekvenci příkazem CREATE SEQUENCE. 24
standardní způsobem indexován. Toto lze provést uvedením volby NO SALT při zadávání příslušného SQL příkazu při vytváření šifrovaného sloupce. Šifrování na úrovni tabulkových prostorů (viz dále) však tyto problémy řeší, je možné používat i indexy bez těchto problémů.
2.1.1. Šifrování sloupců v tabulkách Pokud některé sloupce v tabulce obsahují citlivé údaje, jako jsou rodná čísla nebo čísla kreditních karet, je možné příslušné sloupce zašifrovat. Pokud je v jedné tabulce šifrováno více sloupců, je používán stále tentýž klíč pro zašifrování všech šifrovaných sloupců. Tento klíč je nazýván šifrovací klíč sloupců. Klíče ze všech tabulek, které obsahují šifrované sloupce, jsou zašifrovány hlavním šifrovacím klíčem databázového serveru a uloženy v datovém slovníku databáze. Všechny klíče, které jsou uložené v databázi, jsou tak zašifrované. Hlavní šifrovací klíč je uložen mimo databázi a je přístupný pouze pro jeho správce21. Tento klíč je ukládán v Oracle walletu. Ke správě hlavního šifrovacího klíče jsou používány SQL příkazy, klíč je generován náhodně. V případě využití PKI je pak používán nástroj Oracle Wallet Manager. Obrázek 5.
Šifrovaný sloupec tabulky.
Zdroj: Obrázek vytvořen autorem práce.
Šifrování sloupců tabulek však přináší i jistá omezení. Jelikož každá tabulka má unikátní šifrovací klíč sloupců, není možné šifrovat sloupce, které slouží jako cizí klíč jiné tabulky. Současně není možné používat některé databázové funkce a utility Oracle, jako například export/import, transportovatelné tabulkové prostory nebo indexy jiných typů než B-tree. Kompletní výčet těchto omezení lze nalézt v dokumentaci Oracle.[10] Důvodem těchto omezení je, že data jsou šifrována a dešifrována na SQL vrstvě. Pokud není tato vrstva
21
Může jím být i databázový administrátor, běžnějším postupem v oblasti bezpečnosti však je určit tímto
správcem jinou osobu - bezpečnostního administrátora. 25
danou utilitou či nástrojem používána (SQL vrstva je tedy obcházena), nemohou být v důsledku tyto utility použity. Pro šifrování pouze vybraných sloupců v tabulkách je nezbytné nejdříve identifikovat, které sloupce obsahují citlivá data. Provést takovou analýzu může být velmi obtížné v případě rozsáhlých aplikací s velkým množstvím dat v mnoha tabulkách. Od verze RDBMS Oracle 11g je však možné šifrovat i celé tabulkové prostory.
2.1.2. Šifrování tabulkových prostorů Šifrování tabulkových prostorů umožňuje zvýšit zabezpečení dat uložených v databázi podobně jako šifrování vybraných sloupců v tabulkách. Navenek je rozdíl pouze v granularitě, v případě šifrování tabulkových prostorů je najednou šifrována větší část databáze, než je tomu v případě vybraných sloupců. Je zde však velký rozdíl ve vlastní práci se šifrováním - data jsou šifrována a dešifrována v jiné části paměti na úrovni jiných serverových procesů. Tato skutečnost má následně vliv na práci s šifrovanými daty. Nemohou se zde vyskytovat problémy s nepoužitelnými indexy, jako je tomu v případě šifrování sloupců tabulek. Data ukládaná do jednotlivých tabulek jsou v Oracle ukládána v logických jednotkách nazývaných tabulkový prostor (tablespace). Fyzicky jsou pak uložena v datových souborech (datafiles), což již jsou soubory uložené na disku a obsluhované operačním systémem22. Jeden tabulkový prostor může mít jeden nebo více datových souborů, celková velikost tabulkového prostoru je pak dána velikostí všech příslušných datových souborů23. Pokud je tedy zašifrován celý tabulkový prostor, jsou tím zašifrovány všechny objekty (tabulky, pohledy a podobně), které tento tabulkový prostor obsahuje, jak je znázorněno na následujícím obrázku:
22
Jak bude soubor uložený na disku vypadat záleží na typu operačního systému a také na tom, jak je
konfigurován vlastní Oracle. Je možné používat raw devices nebo ASM instanci pro správu datových souborů na disku. V takovém případě nejsou datové soubory uloženy v běžné adresářové struktuře, jejich dohledání na discích připojených k serveru a případné zneužití ze strany operačního systému je proto o něco obtížnější. 23
Toto neplatí pro tabulkové prostory pro dočasná data (temporary tablespaces). Tyto tabulkové prostory
alokují prostor na disku až v případě potřeby, proto nemusí souhlasit velikost příslušných souborů na disku s údaji o velikosti v datovém slovníku. 26
Obrázek 6.
Šifrování tabulkového prostoru.
Zdroj: Nákres autora práce.
Aplikace zpravidla používají pouze několik tabulkových prostorů (v závislosti na rozsáhlosti dané aplikace). Pomocí šifrování tabulkových prostorů je tak možné velmi snadno šifrovat celou aplikaci, navíc také odpadá u šifrování sloupců tabulek zmíněný problém s nutností identifikace sloupců s citlivými daty. Nasazení šifrování na úrovni tabulkových prostorů tak klade (opět ve srovnání s šifrováním vybraných sloupců tabulek) celkově menší nároky na analýzu a případné úpravy před nasazením šifrování. Nevýhodou pak je větší spotřeba zdrojů nutných na šifrování kompletního obsahu tabulkových prostorů. Při šifrování tabulkových prostorů je nutné si uvědomit, že šifrována jsou pouze data ukládaná interně v tabulkovém prostoru. Pokud některá tabulka v šifrovaném tabulkovém prostoru obsahuje sloupce s externími daty, například datového typu BFILE 24 , není takovýto sloupec zašifrován, neboť ve vlastní tabulce je uložen pouze pointer odkazující na externí soubor. Šifrována však mohou být také veškerá data přenášená po síti klientům nebo aplikačním serverům, čímž je rozšířeno zabezpečení dat na další oblast. Data jsou tak chráněna nejenom ve svém úložišti, ale i při transportu po síti.
2.2. Šifrování a datová integrita síťové komunikace V dnešní době je naprostou samozřejmostí připojení téměř všech počítačů do počítačové sítě, neboť jejich uživatelé ke své práci využívají firemní informační systém a sdílí data. Počítačové sítě jsou tak často velmi rozsáhlé, s množstvím fyzických síťových prvků. Některá odloučená pracoviště pak mohou být připojena pomocí zranitelných mikrovlnných
24
Datový typ BFILE ukládá nestrukturovaná binární data v souborech přímo v operačním systému. 27
spojení, pracovníci v terénu se mohou připojovat třeba prostřednictvím wi-fi sítí. Na všech takových místech hrozí riziko odposlechu síťového provozu Pro ochranu komunikace klientů a aplikačních serverů Oracle s databází Oracle je proto možné přenášená data šifrovat a zamezit tak případnému zneužití odposlechnutých dat, jelikož nebudou čitelná. Pro šifrování síťové komunikace je možné použít šifry DES, 3DES, AES a RC4. Lze využít i SSL šifrování. Pro jednotlivé šifry jsou podporovány následující délky klíčů: - RC4 s šifrovacím klíčem délky 40, 56, 128 a 256 bitů, - DES s 56-bitovým klíčem, ale také se 40-bitovým z důvodu zpětné kompatibility25, - 3DES ve dvou a tříklíčové verzi, s efektivní délkou klíče 112 a 168 bitů, - AES s šifrovacím klíčem délky 128, 192 nebo 256 bitů Pro výměnu klíčů je používán kryptografický protokol Diffie-Hellman, který umožňuje provést bezpečnou distribuci klíčů přes nezabezpečené prostředí mezi komunikujícími stranami. Tento protokol však neposkytuje ochranu proto MITM útoku, jelikož neprovádí autentizaci komunikujících stran. Z tohoto důvodu produkt Oracle Advanced Security zesiluje zabezpečení tím, že kombinuje klíč relace (session) s dalším prvkem – takzvaným sdíleným tajemstvím (z originálního shared secret). Jde o řetězec, který je ustanoven, když se klient přihlašuje k severu. Je znám pouze těmto dvěma komunikujícím stranám. Výsledkem je, že klíč používaný pro relaci je zesílen kombinací dvou prvků, čímž se stává odolný proti MITM útoku. Toto zesílené zabezpečení je standardním rysem produktu, proto nevyžaduje žádnou dodatečnou konfiguraci ze strany administrátorů. Pokud budou koncová klientská připojení na aplikační servery využívat zabezpečené přenosy (protokol HTTPS 26 ), bude veškerá komunikace mezi databází a koncovým klientem zabezpečena. Připojení z aplikačních serverů ke koncovým uživatelům je však třeba řešit samostatně, ošetření těchto připojení není úkolem produktu Oracle Advanced Security. Oblasti komunikace, které je možné zabezpečit nasazením produktu Oracle Advanced Security jsou znázorněny na následujícím obrázku:
25
40-bitový klíč se používal v exportní verzi Oracle Advanced Security určené pro použití mimo území USA
a Kanady (v dřívějších verzích RDBMS Oracle) z důvodu omezení exportu šifrovacích technologií vládními směrnicemi USA.[10] 26
Přenášená data jsou pak šifrována pomocí protokolu SSL, popřípadě TLS. 28
Obrázek 7.
Oblast komunikace zabezpečené pomocí Oracle Advanced Security.
Zdroj: Nákres autora práce.
Pomocí Oracle Advanced Security lze zabezpečit nejenom nativní klientská připojení, ale i připojení z Java aplikace pomocí tenkého JDBC27 klienta. Datová integrita umožňuje zjistit, zda přenášený datový paket nebyl změněn. Děje se tak na základě kontrolního součtu, který je generován podle obsahu paketu a tajného klíče. Byl-li obsah paketu změněn, nebude souhlasit kontrolní součet, neboť tento není možné bez znalosti klíče vygenerovat. Paket je v takovém případě odmítnut. V Oracle Advanced Security je možné používat algoritmy SHA-1 nebo MD5. SHA-1 je o něco pomalejší než MD5, je ovšem odolnější proti útokům. Více informací o těchto algoritmech je uvedeno v příloze 3. Pro bezpečnou výměnu klíčů je, stejně jako v případě šifrování, používán kryptografický protokol Diffie-Hellman. Částečnou nevýhodou použití integritních algoritmů při zabezpečení datových přenosů je menší zvýšení režie při generování kontrolních součtů, potřebných pro zajištění datové integrity. Naproti tomu kontrola datové integrity zabrání dvěma typům útoků. Prvním možným typem je modifikace přenášených dat (útok MITM), kdy útočník například změní hodnoty v přenášených datech a takto změněná data odešle původnímu cíli. Druhým typem je útok opakováním (replay attack), kdy je k cíli opakovaně vysílána kompletní sada zachycených platných dat.[10]
27
Java Database Connectivity. 29
Datová integrita a šifrování jsou na sobě nezávislé, je proto možné konfigurovat komunikaci například pouze pro zajištění datové integrity bez nasazení šifrování.
2.3. Silná autentizace Autentizací rozumíme ověření identity uživatele. Existuje několik různých výkladů pojmu „silná autentizace” 28 , není však standardizováno, co přesně by měla silná autentizace splňovat. Silná autentizace je tak často spojována s dvoufaktorovou autentizací, jindy je za silnou autentizaci považováno ověřování s využitím šifrovacích procesů, někdy také za použití vzájemné autentizace v obou směrech (klient-server a naopak). Silná autentizace v pojetí Oracle se tak v praxi pohybuje mezi těmito výklady, neboť například použití dvoufaktorové autentizace již závisí na konfiguraci produktu třetí strany, pro který Oracle pouze poskytuje adaptér. Pokud tedy za podmínku silné autentizace považujeme dvoufaktorovou autentizaci, je nutné mít příslušným způsobem nakonfigurovánu používanou autentizační službu. Uživatel databázového systému Oracle standardně prokazuje svoji identitu pouze na základě znalosti uživatelského jména a hesla. Produkt Oracle Advanced Security umožní zavést silnou autentizaci pomocí adaptérů pro podporu autentizačních služeb třetích stran. Podporována je autentizace pomocí následujících metod ověření: Kerberos, RADIUS, SSL, podporována je také infrastruktura PKI firmy Entrust Technologies, Inc. - Entrust/PKI, která však dále nebude podrobněji rozebírána. Základním předpokladem pro nasazení příslušného adaptéru k dané autentizační službě do prostředí databázového systému Oracle je mít v rámci firemního informačního systému implementovánu příslušnou infrastrukturu pro danou službu. Produkt Oracle Advanced Security poskytuje pouze adaptéry pro připojení těchto služeb, implementace silné autentizace tak řeší pouze připojení ke zvolené službě. Po implemetaci příslušných adaptérů je tak autenticita uživatele ověřována prostřednictvím těchto adaptérů autentizačním serverem mimo prostředí databázového systému Oracle. V případě, že uživatel požaduje připojení do databázového systému Oracle, je tento požadavek databázovým systémem předán prostřednictvím adaptéru na používaný autentizační server, který provádí vlastní autentizaci, viz následující obrázek.
28
V anglickém jazyce Strong Authentication. 30
Obrázek 8.
Autentizace prostřednictvím služby třetí strany.
Zdroj: Nákres autora práce.
Podpora výše uvedených metod ověření je zvláště výhodná v případech, kdy je v dané firmě silná autentizace pomocí služeb třetích stran již využívána pro autentizaci do ostatních částí informačního systému. Je tak možné využívat jediné přihlášení (SSO – single sign-on) pro ověření uživatele. Uživatel se tak přihlásí pouze jednou a není vyzýván k zadání autentizačních údajů při přihlašování ke každému z dalších systémů. To s sebou nese výhody jak pro uživatele, který si nemusí pamatovat množství hesel do různých systémů, tak i pro firmu, neboť se sníží potřeba podpory v případech zapomenutých hesel. Proces přihlášení do databázového sytému pak probíhá podle následující postupu: 1. Uživatel žádá o autentizaci autentizační server, prokazuje se přihlašovacím jménem a heslem, popřípadě podle konfigurace i hardwarovým zařízením, například bezpečnostním tokenem. 2. Autentizační server ověřuje identitu uživatele a přiděluje credentials29 (nebo ticket, podle typu autentizační služby) zpět uživateli. 3. Uživatel pošle svůj požadavek na přihlášení databázovému serveru Oracle spolu s přidělenými credentials. 4. Databázový server pošle credentials zpět autentizačnímu serveru pro autentizaci. 5. Autentizační server ověří credentials a potvrdí platnost zaslaných credentials databázovému serveru. 6. Pokud autentizační server schválil uživatelem zaslané credentials, povolí databázový server přihlášení uživatele. V opačném případě spojení odmítne.
29
Tento anglický název se často používá i v češtině, lze jej přeložit jako pověřovací listiny, nebo možná
příhodněji jako doporučení (reference). 31
Tento přihlašovací proces je graficky znázorněn na následujícím obrázku: Obrázek 9.
Přihlašovací proces při využití autentizačního serveru.
Zdroj: Nákres autora práce.
2.3.1. SSL autentizace SSL je protokol používaný pro zabezpečení síťových spojení. Velkou výhodou tohoto protokolu je, že je používán jako průmyslový standard. Je založen na principu asymetrické šifry, takže každá z komunikujících stran používá dvojici klíčů, soukromý a veřejný. Pro autentizaci SSL používá digitální certifikáty založené na standardu X50930.
2.3.2. RADIUS autentizace RADIUS31 je bezpečnostní protokol pro klient/server komunikaci poskytující autentizaci a přístup vzdálených připojení. Poskytuje takzvanou AAA (Authentication, Authorization, Accounting, to je autentizaci, autorizaci, správu účtů) správu pro připojené počítače používající síťové služby. Protokol RADIUS může být používán s různými rozšiřujícími autentizačními mechanismy. Je tak možné používat například dvoufaktorovou autentizaci za použití různých bezpečnostních tokenů32 nebo čipových karet, pokud podporují protokol RADIUS.
30
Více o aktuálním standardu X509 verze 3 lze nalézt na stránkách Internet Engineering Task Force -
http://www.ietf.org/ . 31
Zkratka z anglického názvu Remote Authetication Dial in User Service.
32
Je podporován například autentizátor RSA SecurID, viz Obrázek 2. 32
2.3.3. Kerberos autentizace Kerberos33 je síťový autentizační protokol navržený pro zajištění silné autentizace zejména aplikací typu klient/server. Identita obou stran požadujících komunikaci je ověřena bezpečným způsobem, i když je jejich komunikace prováděna po nezabezpečené síti. Protokol Kerberos je založen na využití šifrování pomocí symetrického klíče, pro svoji činnost vyžaduje důvěryhodnou třetí stranu (certifikační autoritu). Kerberos je možné konfigurovat i tak, aby využíval infrastrukturu veřejného klíče v některých fázích autentizace.
2.4. Šifrování záloh Důležité je šifrovat nejenom data, která jsou uložena v databázi a leží tak zpravidla na diskovém poli, ale i data, která jsou ukládána v rámci záloh například na magnetické pásky. Pokud je záloha databáze prováděna z operačního systému, jsou samozřejmě šifrovaná data ve stejné podobě přenesena i na záložní pásky. Dnes je však obvyklejší zálohování Oracle databází pomocí nástroje Oracle RMAN 34 , která poskytuje sofistikovanější možnosti jak zálohování, tak zejména případné obnovy. I v tomto případě zůstávají data na páskách v šifrované podobě, pokud byl původní zdroj (sloupec tabulky nebo tabulkový prostor) šifrován. Je však možné šifrovat i kompletní zálohu celé databáze, to znamená, že i v databázi nešifrovaná data jsou na záložním médiu uložena zašifrovaná. Pokud je současně šifrována i síťová komunikace, nevyskytují se v rámci zálohovací procedury žádná místa vně databáze, kde by bylo možné získat data v čitelné podobě.
2.5. Zhodnocení možností produktu V předchozích kapitolách byly představeny možnosti, který produkt Oracle Advanced Security poskytuje pro zvýšení zabezpečení dat. Je tedy zřejmé, že některá rizika uvedená v první části je možné tímto produktem eliminovat velmi dobře, některá ohrožení však tímto produktem není možné pokrýt. Důvodem může být jak celkově obtížná minimalizace těchto rizik, tak i primární zaměření některých druhů ohrožení na jiné oblasti, než jsou databáze.
33
Více o protokolu Kerberos viz http://web.mit.edu/kerberos/ (2010-01-12).
34
Recovery Manager (RMAN) je nativní nástroj Oracle pro automatizovanou správu zálohování a obnovy.
Je instalován současně s databázovým softwarem. 33
Je nutné si též uvědomit, že databázový systém ukládá data na disky, kde mohou být uložena šifrovaně, ale v době jejich zpracování se nacházejí v nezabezpečené formě například v paměti serveru. Přehled nejčastějších rizik a možnost jejich pokrytí produktem Oracle Advanced Security je uveden v následující tabulce: Tabulka 1.
Vybraná rizika a jejich pokrytí produktem Oracle Advanced Security.
Ohrožení
Pokrytí
ohrožení
produktem
Oracle
Advanced Security Eavesdropping
Ano
Integrita dat
Ano
Útok z operačního systému
Ano, v oblasti uložených dat.
Přístup neautorizovaných uživatelů
Ano, posílením standardních mechanismů.
Podvodné jednání (sociální inženýrství)
Částečně ano, v závislosti na typu útoku, za předpokladu
použití
silné
autentizace
s doplňkovým hardwarovým zařízením. SQl Injection
Ne
Session stealing
Ano,
v oblasti,
která
je
produktem
zabezpečena. Buffer overflow
Ne
Dos a DDos
Ne
Škodlivé programy
Nedefinováno, záleží na typu a zaměření škodlivého programu, produkt není obecně určen na pokrytí tohoto rizika..
Zdroj: Tabulka vytvořena autorem práce.
Je však nutné předem upozornit, že nasazení tohoto produktu je nutné posoudit komplexně v rámci bezpečnostní analýzy firmy, tak aby poměrně značné prostředky vynaložené na tento produkt byly v důsledku též prostředky efektivně vynaloženými. Předem provedená bezpečnostní analýza definuje rizika týkající se konkrétní firmy, na základě této analýzy je pak možné objektivně posoudit, zda nasazení produktu pokryje stávající slabá místa v zabezpečení. Z analýzy může vyplynout, že stávající stav v oblasti bezpečnosti
34
kompletního informačního systému je neuspokojivý a priority pro okamžité řešení problémů mohou být určeny v jiných oblastech.
35
3.
Implementace Oracle Advanced Security
V předchozí kapitole byly podrobně ukázány možnosti, které produkt Oracle Advanced Security nabízí pro zvýšení bezpečnosti. Tato kapitola ukáže, jak nasadit vybrané funkčnosti do prostředí databázového systému Oracle verze 11g na platformě Linux. Předpokladem zprovoznění konkrétních funkčností produktu je jeho instalace do prostředí databázového systému Oracle (viz kapitola 2 a přílohy 1 a 2).
3.1. Nástroje pro konfiguraci a správu K nasazení šifrování i silné autentizace je vhodné35 použít nástroj firmy Oracle nazývaný Oracle Net Manager, v případě nasazení šifrování za pomoci infrastruktury veřejného klíče (PKI) pak i nástroj Oracle Wallet Manager. Tento nástroj je však možné použít i v případě, kdy není infrastruktura PKI používána, například pro správu walletu s hlavním šifrovacím klíčem (viz kapitola 3.4.1).
3.1.1. Oracle Net Manager Oracle Net Manager je grafický nástroj určený pro konfiguraci síťových služeb Oracle Net. Současně je však používán i pro konfiguraci funkčností Oracle Advanced Security, které služby Oracle Net používají. Jde o tyto funkčnosti: -
šifrování síťové komunikace pomocí RC4, DES, 3DES, AES a SSL
-
zajištění datové integrity pomocí MD5 a SHA-1
-
silná autentizace pomocí RADIUS, Kerberos i SSL
Program Oracle Net Manager se v Linux (obecně UNIX) prostředí spouští příkazem netmgr z $ORACLE_HOME/bin, jelikož jde o grafický nástroj, je nutné mít spuštěnu podporu pro X Window36. Obrázek 10. Spuštění Oracle Net Manageru.
Zdroj: Výřez z kopie obrazovky.
35
Například konfigurační soubory Oracle Net pro nasazení šifrování síťové komunikace je možné upravit
i ručně, ale hrozí zde riziko zavlečení chyb či překlepů. 36
X Window System poskytuje podporu pro GUI v prostředí UNIX (též bývá označován jako X nebo X11). 36
Po startu programu se zobrazí okno (viz Obrázek 11), v levé části je navigační panel, v pravé části je pak kontextové pole měnící se v závislosti na vybrané položce v navigačním panelu. Obrázek 11. Prostředí Oracle Net Manageru.
Zdroj: Kopie obrazovky.
Volby pro Oracle Advanced Security jsou k dispozici po zvolení Local/Profile v navigačním panelu a volbě Oracle Advanced Security ze seznamu v kontextovém poli37. Obrázek 12. Výběr produktu Oracle Advanced Security v Oracle Net Manageru.
Zdroj: Výřez z kopie obrazovky.
3.1.2. Oracle Wallet Manager Program Oracle Wallet Manager se podobně jako výše uvedený Net Manager spouští z $ORACLE_HOME/bin příkazem owm, opět jde o grafický nástroj, tudíž je nutné podpora X Window.
37
Občas se může vyskytnout problém s nezobrazováním volby Oracle Advanced Security, problematika je
podrobněji rozebírána v kapitole 4. 37
Obrázek 13. Spuštění Oracle Wallet Manageru.
Zdroj: Výřez z kopie obrazovky.
Obrázek 14. Prostředí Oracle Wallet Manageru.
Zdroj: Kopie obrazovky.
3.2. Šifrování síťové komunikace Motivací pro nasazení šifrování síťové komunikace je možnost zachytit data přenášená mezi serverem a klientem, jak bude ukázáno v následujícím příkladu. Pro zachycení komunikace lze použít například program tcpdump 38 . Tento program je možné spustit a nechat vypisovat komunikaci probíhající na vybraném portu na obrazovku, či přesměrovat výstup do souboru pro pozdější využití. Pokud v klientovi39 připojeném do databáze vybereme například všechny zaměstnance, jejichž příjmení začíná na H, dostaneme tento výsledek:
38
Program tcpdump slouží k analýze síťových paketů, umožňuje mimo jiné zachytit a zobrazit síťovou
komunikaci. 39
V tomto případě je jako klient použit nativní nástroj Oracle – SQL*Plus, který je instalován v rámci
instalace databázového klienta Oracle (viz příloha č. 2). 38
Obrázek 15. Výsledek dotazu na zaměstnance zobrazený v klientském prostředí.
Zdroj: Výřez z kopie obrazovky.
Pokud ve stejnou dobu útočník zachycuje komunikaci například na příslušném portu databázového serveru, zachytí mimo jiné i data, která byla zobrazena uživateli, který zadal dotaz na svém klientovi: Obrázek 16. Výpis zachycené síťové komunikace mezi databázovým serverem a klientem, přenášené v nešifrované formě.
Zdroj: Kopie obrazovky s výpisem síťové komunikace upravená autorem práce.
Jelikož přenášena data nejsou zašifrována, útočník je může relativně snadno číst, jak je patrné z výše uvedeného obrázku. Tímto způsobem se může dostat k veškerým datům vyměňovaným mezi databázovým serverem a klientem. Síťová komunikace může být šifrována buď pomocí nativních 40 šifrovacích algoritmů, nebo za použití SSL.
40
Nativním šifrovacím algoritmem v tomto případě rozumíme vestavěný algoritmus, který je možné použít
bez dalších instalací či konfigurací. Nejde tedy o vlastní šifrovací algoritmy firmy Oracle. 39
3.2.1. Nativní šifrování Při konfiguraci síťových spojení je možné současně podporovat více algoritmů jak pro vlastní šifrování, tak pro kontrolu datové integrity. Server při vytváření spojení rozhodne, který algoritmus bude použit (pro každé spojení může být použit pouze jeden algoritmus pro šifrování a jeden pro datovou integritu). Při tomto rozhodnutí vybírá z algoritmů, které má specifikovány v konfiguračním souboru sqlnet.ora 41 . Současně přihlíží k tomu, zda klientské připojení má daný algoritmus také dostupný. Použit je první algoritmus v seznamu serveru, pro který je nalezena shoda, to znamená, že je dostupný na straně serveru i na straně klienta. Oracle z tohoto důvodu doporučuje umísťovat do konfiguračních souborů preferované algoritmy na prvních místech, s doporučením zařadit na přednější místa i klíče o větší délce (tedy silnější).[10] Následující konfigurace je provedena pro použití šifrovacího algoritmu AES-256 42 , používán je nástroj Oracle Net Manager (viz kapitola 3.1.1). V nástroji Oracle Net Manager jsou volby pro šifrování dostupné v záložce Encryption. Je nutné specifikovat následující volby: Encryption – zde se vybírá, zda se jedná o konfiguraci serveru či klienta. Encryption Type – tato volba je používána při „vyjednávání“ v přihlašovacím procesu, kdy se rozhoduje, zda bude zapnuto šifrování a kontrola integrity. Je možné vybírat ze 4 různých nastavení: 1.
Accepted – při zadání této volby není zabezpečení vyžadováno, ale je použito
v případě, že druhá strana má nastavenu volbu Requested nebo Required. 2.
Rejected – při použití této volby není zabezpečení použito, a to ani v případě, že
jej požaduje druhá strana komunikace. 3.
Requested – zajistí, že je spojení zabezpečené v případě, že jej povolí druhá
strana a je nalezen shodný algoritmus. Zabezpečení je tedy požadováno, ale není nutné.
41
Konfigurační soubory pro Oracle Net jsou na straně serveru standardně umístěny v adresáři
$ORACLE_HOME/network/admin. 42
Například program Oracle SQL Developer však používá pro připojení JDBC klienta, který algoritmus AES
nepodporuje. V takovém případě je nutné použít jiný šifrovací algoritmus (či povolit alternativní). 40
4.
Required
–
volba
pro
zajištění
výhradně
zabezpečeného
spojení.
Nezabezpečená spojení nejsou povolena, pokud není nalezen shodný algoritmus, není spojení uskutečněno. Defaultní je hodnota Accepted, volba Rejected poskytuje minimální bezpečnost pro komunikaci mezi serverem a klientem, volba Required naopak zajišťuje maximální síťovou bezpečnost. Některé volby jsou vzájemně nekompatibilní a pokus o komunikaci mezi takto nastaveným serverem a klientem tak skončí chybou 43 – jde zejména o oba směry v kombinaci voleb Required/Rejected. Chyba se však objeví například i v případě kombinace Accepted/Required za předpokladu, že není nalezen shodný algoritmus. Vzájemná kompatibilita položek a výsledný stav je uveden v tabulce 2. Uvedený výsledný stav vychází z předpokladu, že je nalezen společný algoritmus. Tabulka platí obousměrně, to znamená, že hodnoty platí i v případě, že se pořadí serveru a klienta v prvním a druhém sloupci obrátí (údaj záhlaví tabulky v závorce). Tabulka 2.
Možné kombinace požadavků na šifrování.
Server (Klient)
Klient (Server)
Šifrování
Accepted
Accepted
Vypnuto
Accepted
Rejected
Vypnuto
Accepted
Requested
Zapnuto
Accepted
Required
Zapnuto
Rejected
Rejected
Vypnuto
Rejected
Requested
Vypnuto
Rejected
Required
Nelze - chyba spojení
Requested
Requested
Zapnuto
Requested
Required
Zapnuto
Required
Required
Zapnuto
Zdroj: Tabulka vytvořena autorem práce s použitím[10].
43
Pokus o spojení je ukončen s chybovým hlášením ORA-12650 - "No common encryption or data integrity
algorithm". 41
Encryption Seed – nepovinná volba, zadá se mezi 10 – 70 náhodnými znaky, které jsou dále používány pro generování unikátního klíče pro každou session (připojení). Tyto náhodné znaky by měly být rozdílné pro server a klienta. Available/Selected Methods – z dostupných (pole Available Methods) algoritmů se zde vyberou ty algoritmy, které mají být používány (pomocí tlačítek se přesunou do pole Selected Methods). V modelovém případě je pak pro stranu serveru výsledné nastavení ukázáno v obrázku 17. Nastavení pro generování konfigurace pro stranu klienta je totožné s tím, že v poli Encryption je vybrána volba Client a je zadán jiný náhodný řetězec v poli Encryption Seed. Obrázek 17. Prostředí pro konfiguraci šifrování v Oracle Net Manageru.
Zdroj: Výřez z kopie obrazovky.
Po zadání příslušné konfigurace je nutné ji uložit. Toto se provede v menu – po výběru File se zvolí Save Network Configuration (viz Obrázek 18). Tím jsou volby uloženy v příslušném konfiguračním souboru. Nástroj Oracle Net Manager takto přidal do souboru sqlnet.ora podle výše uvedeného nastavení pro konfiguraci na serveru tyto 3 řádky: SQLNET.ENCRYPTION_SERVER = required SQLNET.CRYPTO_SEED = 'kii8wshd604mfie838djdo38939dfhffr9' SQLNET.ENCRYPTION_TYPES_SERVER= (AES256)
42
Pro konfiguraci na straně klienta jsou pak tato nastavení: SQLNET.ENCRYPTION_CLIENT = required SQLNET.CRYPTO_SEED = 'kjig5884dew994kre39k3k990w2' SQLNET.ENCRYPTION_TYPES_CLIENT= (AES256) Obrázek 18. Uložení síťové konfigurace v Oracle Net Manageru.
Zdroj: Výřez z kopie obrazovky.
Pokud útočník zachytí přenášená data po zapnutí šifrování podle výše uvedeného postupu, obdrží následující výstup (přenášená data jsou shodná s těmi, která jsou ukázána v motivačním případu v úvodu kapitoly – jde o totožný select): Obrázek 19. Výpis zachycené síťové komunikace mezi databázovým serverem a klientem, přenášené v šifrované formě
Zdroj: Kopie obrazovky s výpisem síťové komunikace upravená autorem práce. 43
V případě zachycení přenášených dat z nich tedy útočník nemůže získat žádné smysluplné informace, které by mohl potenciálně zneužít. Na závěr je třeba poznamenat, že uživatelská hesla není možné postupem uvedeným v motivačním příkladu (ani jiným podobným způsobem) zachytit, a to ani v případě, kdy není použit produkt Oracle Advanced Security. Důvodem je standardní chování RDBMS Oracle, kde jsou hesla vždy automaticky šifrována 44 před jejich přenosem po síti. Vyzrazení hesla jeho odchycením při přenosu po síti tudíž není možné45.
3.3. Datová integrita přenášených dat Potřebné změny pro zprovoznění kontroly datové integrity je vhodné provést, podobně jako v případě šifrování síťové komunikace, pomocí nástroje Oracle Net Manager. Je nutné specifikovat následující volby: Integrity – zde se označí, zda se konfiguruje strana serveru či klienta. Checksum Level – stejně jako v případě šifrování jsou k dispozici čtyři volby se shodným významem a funkčností (viz Tabulka 2) – Accepted, Rejected, Required, Requested. Available Methods/Selected Methods – z dostupných algoritmů (pole Available Methods) se zde vyberou ty algoritmy, které mají být používány (pomocí tlačítek se přesunou do pole Selected Methods). Po nastavení jednotlivých voleb podle požadavku je nutné konfiguraci uložit (menu File, volba Save Network Configuration). V konfiguraci, která je zobrazena na obrázku 20, vygeneruje nástroj Oracle Net Manager následující řádky do konfiguračního souboru sqlnet.ora: SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER= (SHA1) SQLNET.CRYPTO_CHECKSUM_SERVER = required Pro stranu klienta jsou to potom tyto řádky: SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT= (SHA1) SQLNET.CRYPTO_CHECKSUM_CLIENT = required Tato konfigurace zajistí nejvyšší dosažitelnou úroveň zabezpečení datové integrity. Kontrolu, zda jsou kontrolní součty pro zajištění datové integrity počítány, lze provést
44
K šifrování je používán algoritmus AES.
45
Samozřejmě za předpokladu, že útočník neprolomí šifrovací algoritmus. 44
v trasovacím souboru (*.trc) generovaném Oracle Net trace, kde musí být záznam „cryptochecksumming is active“. Obrázek 20. Prostředí pro konfiguraci kontroly integrity v Oracle Net Manageru
Zdroj: Výřez z kopie obrazovky.
3.4. Šifrování uložených dat Jak již bylo řečeno ve druhé kapitole, pomocí Transparent Data Encryption je možné šifrovat buď celé tabulkové prostory, nebo pouze vybrané sloupce tabulek. Šifrování kompletních tabulkových prostorů je výhodné v případech, kdy existuje požadavek na zabezpečení celé aplikace. Aplikace je uložena zpravidla pouze v jednom či několika tabulkových prostorech (podle složitosti a komplexnosti vlastní aplikace a objemu využívaných dat), proto lze její kompletní zabezpečení provést relativně rychle bez rozsáhlé úvodní analýzy. Nasazení šifrování celých tabulkových prostorů je podrobně rozebráno v kapitole 3.4.2. Citlivé údaje jsou však většinou uloženy pouze v několika tabulkách, respektive bez znalosti údajů ve sloupcích z těchto tabulek je nemožné z ostatních dat získat smysluplné informace. V těchto případech pak lze použít pouze šifrování vybraných sloupců tabulek. Podmínkou je však identifikovat tyto sloupce v rámci úvodní analýzy, pokud nejsou předem známy například z aktuální aplikační dokumentace. I v takovém případě je však v rámci analýzy nutné provést kontrolu, zda je reálný stav skutečně v souladu s popisem v dokumentaci. Šifrování vybraných sloupců tabulek a jeho implementace je předmětem kapitoly 3.4.3. 45
Úvodním předpokladem pro možnost šifrovat kterýmkoliv z obou uvedených způsobů je existence hlavního šifrovacího klíče. Tento se vytváří postupem uvedeným v následující kapitole.
3.4.1. Vytvoření hlavního šifrovacího klíče Pro implementaci šifrování je třeba nejprve vytvořit (nebo nastavit) hlavní šifrovací klíč. Toto se provede SQL příkazem ALTER SYSTEM SET ENCRYPTION KEY 46 . Pokud neexistuje žádný Oracle wallet, je současně tímto příkazem vytvořen v cestě specifikované v konfiguračním souboru Oracle Net sqlnet.ora. Není-li cesta v tomto souboru specifikována, je vytvořen v defaultním umístění47. V sqlnet.ora může být cesta k walletu specifikována ve dvou parametrech: -
ENCRYPTION_WALLET_LOCATION
-
WALLET_LOCATION
Transparent Data Encryption se pokouší nejprve použít wallet v cestě specifikované parametrem ENCRYPTION_WALLET_LOCATION. Pokud není tento parametr nastaven, použije WALLET_LOCATION, v případě neúspěchu pak defaultní cestu. Firma Oracle doporučuje specifikovat parametr ENCRYPTION_WALLET_LOCATION, aby bylo zajištěno exkluzivní používání daného walletu k ukládání hlavního šifrovacího klíče pro Transparent Data Encryption. Wallety umístěné v cestách určených defaultním nastavením nebo parametrem WALLET_LOCATION mohou být využívány i dalšími komponentami Oracle a být tudíž sdíleny. Samozřejmostí také musí být nastavení minimálních přístupových práv v operačním systému v cestě pro umístění walletu tak, aby wallet nebyl přístupný pro neoprávněné uživatele. Specifikovat cestu parametrem ENCRYPTION_WALLET_LOCATION je nezbytné v případě, že je pro ukládání šifrovacího klíče místo Oracle walletu použito z důvodu zvýšení bezpečnosti nějaké hardwarové zařízení (firma Oracle je obecně nazývá Hardware Security Module, HSM)48.
46
Je však možné použít i Oracle Wallet Manager nebo utilitu mkwallet.
47
Toto umístění závisí na platformě, například na OS UNIX jde o /etc/ORACLE/WALLETS/oracle.
48
Šifrovací operace s použitím zde uloženého hlavního šifrovacího klíče jsou pak prováděny v HSM, nikoliv
v operační paměti serveru. 46
- Editace sqlnet.ora49: Obrázek 21. Výpis řádků přidaných do sqlnet.ora pro cestu k walletu.
Zdroj: Výřez z kopie obrazovky.
- Vytvoření hlavního šifrovacího klíče (heslo je nutné uzavírat do uvozovek, jinak dojde k nesprávnému rozlišení hesla), toto se provede pomocí následujícího SQL příkazu (s individuálně zvoleným heslem): ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY ”heslo”; Databázový systém potvrdí, že došlo ke správnému provedení příkazu vypsáním „System altered.“. Provedením příkazu došlo k vytvoření vlastního walletu, jeho otevření a vytvoření klíče. V operačním souboru je viditelný vlastní wallet: Obrázek 22. Výpis souboru s walletem v operačním systému.
Zdroj: Výřez z kopie obrazovky.
Po každém restartu databáze je nutné wallet znovu otevřít, jelikož při shutdownu databáze je wallet automaticky uzavřen. Otevřením walletu se umožní provádění šifrovacích operací nad sloupci tabulek, které jsou zašifrovány. Otevření walletu se provádí opět pomocí SQL příkazu s příslušným heslem uzavřeným do uvozovek: ALTER SYSTEM SET WALLET OPEN IDENTIFIED BY ”heslo12”; Wallet je samozřejmě možné pomocí SQL příkazu ALTER SYSTEM SET i uzavřít, což se může použít třeba v případě, že zašifrované sloupce tabulek nemají být z nějakého důvodu dostupné: ALTER SYSTEM SET WALLET CLOSE; V obou výše uvedených případech databázový systém opět potvrdí správné provedení příkazu vypsáním „System altered.“.
49
V případě použití HSM je potřeba uvést v položce method údaj HSM (METHOD=HSM). 47
Oracle wallet je však možné nechat otevřít i automaticky po startu databáze. K tomu je vhodné použít Oracle Wallet Manager (viz kapitola 3.1.2), který toto nastavení umožňuje provést velmi jednoduše. Wallet je potřeba nejprve otevřít z menu Wallet/Open, po vyhledání správné cesty k walletu a zadání hesla je potom pouhým zaškrtnutím volby Auto Login a uložením walletu (Save) automatické otevírání walletu povoleno: Obrázek 23. Vytvoření automaticky otevíraného walletu.
Zdroj: Kopie prostředí nástroje Oracle Wallet Manager upravená autorem práce.
Po uložení walletu se zaškrtnutým automatickým otevíráním se v příslušné cestě s walletem v operačním systému vytvoří další soubor s příponou .sso, který automatické otevírání zajišťuje: Obrázek 24. Výpis walletů v operačním systému.
Zdroj: Výřez z kopie obrazovky.
Pokud je povoleno automatické otevírání walletu, není možné zakázat přístup do zašifrovaných sloupců v tabulkách pouhým uzavřením walletu příkazem ALTER SYSTEM SET WALLET CLOSE. Automatické otevírání walletu v takovém případě způsobí, že při požadavku na data v těchto zašifrovaných sloupcích bude wallet opět automaticky otevřen, čímž dojde ke zpřístupnění zašifrovaných dat bez ohledu na předtím vydaný příkaz pro uzavření walletu. Pro zamezení přístupu k datům je tak v tomto případě nutné ještě zajistit
48
nedostupnost vlastního walletu, například přejmenováním souboru s walletem pro automatický start (cwallet.sso) na úrovni operačního systému.
3.4.2. Šifrování tabulkových prostorů Šifrování celých tabulkových prostorů umožňuje zvýšit zabezpečení dat uložených v databázi bez dohledávání jednotlivých sloupců tabulek obsahujících citlivá data. Motivací pro nasazení šifrování dat budiž následující příklad. V prostředí připraveném podle jednoduchých skriptů z přílohy 4 máme k dispozici následující tabulku ZAMESTNANCI: Obrázek 25. Výpis tabulky ZAMESTNANCI.
Zdroj: Výřez z kopie obrazovky.
Tabulka je uložena v tabulkovém prostoru PERSONALNI s jedním datovým souborem '/home/zela/oracle/RZOAS/personalni01.dbf'. Tento soubor je viditelný v operačním systému a je možné ho například pomocí příkazu strings 50 číst, jak je zobrazeno na následujícím obrázku: Obrázek 26. Zobrazení obsahu datového souboru příkazem strings.
Zdroj: Výřez z kopie obrazovky.
Ještě lépe demonstruje viditelnost dat uložených na disku v databázovém souboru příkaz od –cx51:
50
Příkaz strings zobrazuje řetězce tisknutelných znaků ze souborů.
51
Příkaz od vypíše soubor v nastaveném formátu (defaultně osmičkovém). 49
Obrázek 27. Zobrazení obsahu datového souboru příkazem od.
Zdroj: Výřez z kopie obrazovky.
V uvedené části výpisu je možné dohledat všechna data v tabulce, zvýrazněné je příjmení „Sadil“, dále v řádku následuje jméno a ve třetím řádku číslo platební karty. Je pravděpodobné, že v praxi by nebyl pro výhradně číselná data použit datový typ VARCHAR jako ve výše uvedeném modelovém případě, přirozenější je použití datového typu NUMBER. V takovém případě nejsou data z těchto sloupců viditelná takto snadno, je nutné je dohledat a převést do čitelné podoby v desítkové soustavě. Jejich získání je však již pouze otázkou pracnosti. Z výše uvedeného vyplývá, že v případě z jakéhokoliv důvodu méně zabezpečeného serveru je ohrožena i bezpečnost v databázi uložených dat. Útočníkovi k získání dat stačí získat přístup k datovým souborům databáze. Šifrování však pomůže ochránit uložená data v tabulkových prostorech i v případě, že dojde k úspěšnému prolomení zabezpečení operačního systému a tím i k přístupu k uloženým datovým souborům. Aby mohl být vytvořen šifrovaný tabulkový prostor, musí být na úvod splněny dva předpoklady. Prvním předpokladem je mít nastaven parametr COMPATIBLE minimálně na hodnotu 11.0.0. Tento parametr určuje, se kterou verzí RDBMS Oracle musí být udržována zpětná kompatibilita. Jelikož šifrování tabulkových prostorů je nová funkčnost od verze 11g, není v tomto případě možné udržovat zpětnou kompatibilitu s některou předchozí verzí. V případě, že daná databáze existovala již v předchozích verzích, je nutné v rámci upgrade na verzi 11g (nebo nejpozději před nasazením šifrování tabulkových prostorů) parametr zvýšit. Kontrolu lze provést výpisem příslušného inicializačním souboru databáze na úrovni operačního systému (soubor init nebo spfile), nebo vypsáním parametru COMPATIBLE přímo z databáze: Obrázek 28. Zobrazení parametru COMPATIBLE.
Zdroj: Výřez z kopie obrazovky.
50
Druhým předpokladem pro možnost vytvoření šifrovaného tabulkového prostoru je existence hlavního klíče (viz kapitola 3.4.1). Příslušný wallet s tímto klíčem pak musí být otevřen. Pro vytvoření šifrovaného tabulkového prostoru slouží příkaz CREATE TABLESPACE se syntaxí podle schématu 1. Schéma zachycuje pouze část obsáhlé syntaxe tohoto příkazu, s důrazem na tu část, která je relevantní pro šifrování. Schéma 1. Syntaxe příkazu CREATE TABLESPACE.
Zdroj: Oracle Database SQL Language Reference[12], syntaxe je setříděna a upravena autorem práce.
Uvedená syntaxe obsahuje klauzuli ENCRYPTION, ve které je možné blíže specifikovat volby pro šifrování tabulkového prostoru.52Navíc je však nutné uvést výraz ENCRYPT při nastavování defaultních parametrů pro ukládání objektů v klauzuli STORAGE. Tato klauzule je použita v okamžiku, kdy je vytvářen nějaký nový objekt v daném tabulkovém prostoru. Vytvářený objekt použije uvedené parametry z této klauzule jako výchozí pro své uložení do tabulkového prostoru, proto bude každý objekt v tomto tabulkovém prostoru ukládán zašifrovaně. Bez uvedení klauzule ENCRYPT vrátí příkaz pro vytváření tabulkového prostoru chybu 53 a tabulkový prostor není vytvořen. Pro vytvoření tabulkového prostoru, který bude šifrován pomocí šifrovacího algoritmu AES256, je možné použít v souladu se syntaxí uvedenou ve schématu 1 například následující příkaz:
52
Pokud není specifikován šifrovací algoritmus, je použit pro šifrování tabulkových prostorů defaultní
algoritmus AES128. 53
ORA-28372: missing ENCRYPT storage option for encrypted tablespace. 51
CREATE TABLESPACE encrypt_personalni DATAFILE
/home/zela/oracle/RZOAS/encrypt_personalni01.dbf
SIZE 4M ENCRYPTION USING AES256 DEFAULT STORAGE (ENCRYPT); Databázový systém potvrdí správné vytvoření tabulkového prostoru vypsáním „Tablespace created.“. S výjimkou šifrovacího algoritmu není možné specifikovat další možnosti pro šifrování54, není tudíž podporována ani možnost zašifrovat tabulkový prostor s NO SALT volbou. Tato volba není podle dokumentace podporována z bezpečnostních důvodů. Kontrolu, zda je daný tabulkový prostor skutečně šifrován, lze provést dotazem do systémového pohledu DBA_TABLESPACES: Šifrované tabulkové prostory mají ve sloupci ENCRYPTED (ENC) uvedeno YES. Obrázek 29. Výpis všech šifrovaných tabulkových prostorů.
Zdroj: Výřez z kopie obrazovky.
Tabulkový prostor, který byl vytvořen jako šifrovaný, není možné zpětně dešifrovat. Pokud již není požadováno ukládat data v konkrétním tabulkovém prostoru zašifrovaná (například po migraci aplikace, kdy již nadále nejsou citlivá data uložena v tomto tabulkovém prostoru), je nutné vytvořit jiný, nešifrovaný tabulkový prostor a příslušné objekty buď přemístit, nebo znovu vytvořit v tomto nešifrovaném tabulkovém prostoru (například tabulku lze takto přemístit pomocí SQL příkazu ALTER TABLE ...MOVE... nebo vytvořit příkazem CREATE TABLE...AS SELECT...).
3.4.3. Šifrování sloupců tabulek Motivace pro nasazení šifrování sloupců tabulek je stejná jako v případě uvedeném v předchozí kapitole. V tomto případě je však rozhodnuto šifrovat pouze konkrétní sloupce z tabulky, tedy například sloupec obsahující čísla platebních karet. Vytvořit šifrované sloupce v tabulce je možné třemi způsoby – vytvořením nové tabulky se šifrovaným sloupcem (nebo více sloupci), zašifrováním již existujícího sloupce v tabulce a přidáním nového šifrovaného sloupce do tabulky.
52
K vytvoření tabulky se šifrovaným sloupcem slouží SQL příkaz CREATE TABLE spolu s klauzulemi pro šifrování. Syntaxe relevantní pro vytvoření tabulky se šifrovanými sloupci je zobrazena ve schématu 2: Schéma 2. Syntaxe příkazu CREATE TABLE.
Zdroj: Oracle Database SQL Language Reference[12], syntaxe je setříděna a upravena autorem práce.
Vytvoření tabulky s šifrovanými sloupci se tak provede pomocí standardního DDL příkazu pro vytváření tabulky, příkaz je pouze jednoduše rozšířen přidáním klauzule ENCRYPT k definici sloupců, které mají být šifrovány, například podobným způsobem: CREATE TABLE personalni.zamestnanci (cislo_zamestnance NUMBER(5), prijmeni VARCHAR(25) ENCRYPT, jmeno VARCHAR2(20), cislo_karty CHAR(16) ENCRYPT); V tomto případě budou příslušné sloupce (prijmeni a cislo_karty) zašifrovány defaultním algoritmem, jelikož volby pro nastavení šifrování nejsou blíže specifikovány. Není použita volba NO SALT, proto budou navíc přidány náhodné řetězce dat do těchto sloupců. Tyto sloupce tudíž nebude možné indexovat. Zašifrování již existujícího sloupce v tabulce se provede pomocí příkazu ALTER TABLE podle syntaxe uvedené ve schématu 3:
54
Nemožnost zadat tyto volby je probírána ještě v kapitole 4. 53
Schéma 3. Syntaxe příkazu ALTER TABLE...MODIFY.
Zdroj: Oracle Database SQL Language Reference[12], syntaxe je setříděna autorem práce.
K zašifrování sloupce s číslem platební karty v tabulce ZAMESTNANCI z modelového příkladu (viz obrázek 25) se použije například tento příkaz: ALTER
TABLE
personalni.zamestnanci
MODIFY
(cislo_karty
ENCRYPT USING AES256 NO SALT); Úspěšné provedení příkazu databázový systém potvrdí vypsáním „Table altered.“. Tento příkaz, na rozdíl od defaultních voleb, 55 používá silnější šifrování AES256 místo standardního AES192, navíc je zadána volba NO SALT, aby sloupec s číslem platební karty mohl být indexován. Přidání nového šifrovaného sloupce do tabulky lze provést opět pomocí příkazu ALTER TABLE podle syntaxe uvedené ve schématu 4. Schéma 4. Syntaxe příkazu ALTER TABLE...ADD.
Zdroj: Oracle® Database SQL Language Reference[12], syntaxe je setříděna autorem práce.
55
Defaultní volby není nutné uvádět, příkaz používající tyto volby by tedy mohl být zadán ve tvaru ALTER
TABLE xy MODIFY (cislo_karty ENCRYPT); 54
V tabulce existují tři sloupce s údaji o zaměstnanci, viz výpis na následujícím obrázku: Obrázek 30. Výpis popisu tabulky před přidáním sloupce.
Zdroj: Výřez z kopie obrazovky.
Tabulka má být rozšířena o další sloupec, který bude obsahovat číslo služební platební karty zaměstnance. Data ve sloupci mají být zašifrována pomocí algoritmu 3DES, sloupec bude indexován. Výsledný SQL příkaz pro provedení podle tohoto zadání bude následující: ALTER
TABLE
personalni.zamestnanci
ADD
(cislo_karty
VARCHAR(16) ENCRYPT USING 3DES168 NO SALT); Úspěšné provedení příkazu databázový systém potvrdí vypsáním „Table altered.“. Kontrolu na úrovni databáze lze ve všech uvedených případech provést vypsáním popisu tabulky – datový typ u sloupce, který byl zašifrován, musí obsahovat navíc slovo ENCRYPT, jak je znázorněno na následujícím obrázku. Obrázek 31. Kontrola šifrování sloupce tabulky.
Zdroj: Výřez z kopie obrazovky upravený autorem práce.
Pokud mají šifrované sloupce znakový datový typ, lze jednoduše provést i kontrolu databázových souborů na úrovni operačního systému,56 například stejně jako v motivačním příkladu pomocí příkazu strings. Tento příkaz však v tomto případě nesmí vrátit žádné hodnoty, jak je zobrazeno v obrázku 32. Obrázek 32. Kontrola šifrování sloupců tabulek v operačním systému.
Zdroj: Výřez z kopie obrazovky.
56
Problémy šifrování existujících sloupců tabulek příkazem ALTER TABLE jsou dále rozebírány v kapitole 4. 55
3.5. Implementace SSL Pro používání SSL je vhodné, aby již byla v dané firmě používána infrastruktura veřejného klíče (PKI), která pak bude následně využívána i produktem Oracle Advanced Security. Existence této infrastruktury s sebou nese i veškeré ostatní předpoklady (včetně administrativních), že používané certifikáty budou důvěryhodné a bude tudíž možné je používat pro zabezpečení komunikace či autentizaci. Je samozřejmě možné vytvořit si pro použití v prostředí Oracle vlastní certifikáty a používat je, toto je však vhodné pouze pro testovací účely. Tímto způsobem je implementováno i SSL v této kapitole, pro produkční nasazení by bylo nutné nechat podepsat certifikační požadavky důvěryhodnou certifikační autoritu, která současně řídí i platnosti certifikátů (délka platnosti, zneplatnění odvolaných certifikátů a podobně).
3.5.1. Certifikáty Pro použití SSL je nutné založit příslušný wallet a vygenerovat certifikační požadavek. Po podepsání požadavku důvěryhodnou certifikační autoritou se pak tento podepsaný certifikát naimportuje zpět do walletu, kde je uložen. Pro správu Oracle walletů se používá nástroj Oracle Wallet Manager (viz 3.1.2). Po spuštění nástroje je nutné buď otevřít existující wallet, nebo vytvořit nový (volbou Wallet/New z menu). Jakmile je wallet k dispozici, je možné vytvořit certifikační požadavek. Toto se provede volbou Operations/Add Certifikate Request z menu. Následně je nutné vyplnit jednotlivé pole ve vlastním certifikačním požadavku. Povinná jsou pole Common Name, Country a Key Size: -
Common Name – zadá se jméno uživatele nebo služby
-
Organizational Unit – vyplní se jméno organizační jednotky firmy
-
Organization – jméno firmy
-
Locality/City + State/Province – pole pro zadání adresy
-
Country – ze seznamu se vybere stát, ve kterém firma sídlí
-
Key Size – ze seznamu se vybere používaná délka klíče
Délku klíče je možné vybrat v hodnotách 512, 768, 1024, 2048, 3072 a 4096 bitů. Za bezpečné jsou v současné době považovány klíče s délkou alespoň 1024 bitů.
56
Obrázek 33. Položky certifikačního požadavku.
Zdroj: Kopie obrazovky.
Nepovinná pole nejsou v příkladu na obrázku 33 vyplněna, jelikož jde o testovací certifikát. U certifikátů pro standardní používání by však měla být vyplňována i tato pole pro jednoznačnější identifikaci žadatele. Po stisknutí tlačítka OK je vygenerován certifikační požadavek, který je možné volbou Operations/Export Certificate Request exportovat do souboru a poté zaslat certifikační autoritě k podepsání. Po obdržení podepsaného certifikátu je možné provést jeho import. Po otevření Oracle Wallet Manageru a otevření příslušného walletu se import provede z menu Operations volbou Import User Certifikate. Pokud je certifikát v souboru, je třeba zvolit příslušnou volbu – Select a file that contains the certifikate a poté vybrat příslušný soubor. Po stisknutí OK se certifikát naimportuje, po dokončení se ve spodní části okna Wallet Manageru objeví hlášení „Your certificate has been successfully imported“, stav u certifikátu se musí změnit na Ready, viz následující obrázek:
57
Obrázek 34. Certifikát připravený k používání.
Zdroj: Kopie prostředí Oracle Wallet Manageru upravená autorem práce.
V implementaci tohoto modelového případu je používán nástroj orapki. Tento nástroj je ovládán pomocí příkazové řádky, umožňuje mimo jiné 57 vytvořit pro testovací účely certifikát, který při vytváření ověří sám sebe. Vytvoření se provede pomocí následujících dvou příkazů (příkazy již obsahují konkrétní použité hodnoty parametrů): orapki wallet create -wallet ROOT_CERT orapki
wallet
add
-wallet
ewallet.p12
-keysize
1024
-
self_signed -validity 365 -dn CN=RZOAS_ROOT_TEST,C=CZ
3.5.2. Konfigurace SSL na serveru Jakmile je k dispozici wallet s podepsaným certifikátem pro server, je třeba specifikovat do síťových konfiguračních souborů Oracle (listener.ora a sqlnet.ora), kde je tento wallet uložen. Toto se provede pomocí nástroje Oracle Net Manager (viz 3.1.1). Po spuštění nástroje je třeba vybrat Local/Profile v navigačním panelu a dále zvolit položku Oracle Advanced Security ze seznamu v kontextovém poli. V záložce SSL je pak možné pomocí tlačítka Browse vyhledat adresář s walletem a dále zvolit, že je konfigurováno SSL pro server.
57
Nástroj umožňuje nejenom pracovat s wallety a certifikáty, ale také spravovat CRL (certificate revocation
lists). 58
Obrázek 35. Specifikace uložení walletu na serveru.
Zdroj: Výřez z kopie obrazovky.
Provedený výběr je možné uložit z menu File volbou Save Network Configuration, čímž se provedené změny uloží do konfiguračních souborů, cesta k walletu je uložena v listener.ora i sqlnet.ora: Obrázek 36. Lokalizace walletu v konfiguračních souborech.
Zdroj: Výřez z kopie obrazovky.
Mimo cesty k walletu jsou současně do konfiguračních souborů uloženy i další nastavení volitelných parametrů v defaultním tvaru. Tyto parametry jsou podrobněji popisovány v kapitole 3.5.4. Dále je nutné přidat do souboru listener.ora konfiguraci pro použití TCP/IP s SSL (firma Oracle doporučuje používat při použití SSL port 2484[10]): Obrázek 37. Konfigurace listeneru pro použití SSL.
Zdroj: Výřez z kopie obrazovky.
Pokud není požadována komunikace na jiných portech (například na standardním portu 1521 pro nezabezpečenou komunikaci), měly by být příslušné konfigurace ze souboru listener.ora odstraněny, aby nemohlo dojít ke komunikaci bez použití SSL.
59
3.5.3. Konfigurace SSL na klientovi Nejprve je třeba upravit síťový konfigurační soubor tnsnames.ora pro použití zabezpečeného protokolu, současně je třeba nastavit číslo portu na číslo, které je použito na serveru v konfiguračním souboru listener.ora, v tomto případě tedy 2484. Tabulka 3.
Změny provedené v tnsnames.ora na klientovi.
Zdroj: Výřez z kopie obrazovky upravený autorem práce.
Následně je třeba upravit soubor sqlnet.ora. Toto se může provést pomocí nástroje Oracle Net Manager, popřípadě ruční editací souboru. Použití Oracle Net Manageru je však vhodnější z důvodu zamezení výskytu chyb a překlepů v konfiguračním souboru při ruční editaci. Tento nástroj navíc současně zajistí i konfiguraci volitelných parametrů (viz 3.5.4) v defaultním tvaru. Po spuštění je třeba (stejně jako v případě serveru) zvolit v navigačním panelu položku Profile a v kontextovém poli vybrat Oracle Advanced Security. Poté je třeba zadat cestu k walletu a vybrat, že konfigurace je prováděna pro klienta, jak je znázorněno níže: Obrázek 38. Specifikace uložení walletu na klientovi.
Zdroj: Výřez z kopie obrazovky.
Provedený výběr je možné uložit z menu File volbou Save Network Configuration, čímž se cesta k walletu uloží do konfiguračního souboru sqlnet.ora. Formát zápisu v souboru je stejný jako v případě konfigurace na serveru (s příslušnou cestou), viz obrázek 36. 60
Po provedení těchto změn je již používána zabezpečená komunikace mezi databázovým serverem a klientem, podobně jako při použití nativních šifrovacích protokolů. Data tak nejsou přenášena v čitelném tvaru, jak ukazuje výpis části komunikace na následujícím obrázku (použit je stejný příkaz, jako v případě použití nativního šifrování v kapitole 3.2). Obrázek 39. Komunikace mezi databázovým serverem a klientem při použití SSL.
Zdroj: Kopie obrazovky s výpisem síťové komunikace upravená autorem práce
Současně je možné využívat autentizaci do databázového systému pomocí klientova certifikátu a je tedy možné přihlásit se z klientské stanice bez nutnosti zadávání hesla. Aby však bylo možné se tímto způsobem přihlásit, je nejprve potřeba vytvořit v databázovém systému uživatele, který má být autentizován externí službou a přidělit tomuto uživateli příslušná oprávnění: Obrázek 40. Vytvoření externě autentizovaného uživatele.
Zdroj: Výřez z kopie obrazovky.
V apostrofech musí být uvedeno rozlišovací jméno (DN – distinguished name) přesně ve tvaru, který odpovídá tvaru DN v příslušném certifikátu uživatele uloženém ve walletu. Pokud má uživatel výše uvedeným způsobem vytvořen účet v databázi, může se již přihlásit bez zadávání jména a hesla:
61
Obrázek 41. Připojení klienta s ověřením pomocí certifikátu.
Zdroj: Výřez z kopie obrazovky.
Je však potřeba znovu upozornit, že přihlašování tímto způsobem by mělo být umožněno pouze za předpokladu, že je k dispozici PKI infrastruktura s důvěryhodnou certifikační autoritou. Je také vhodné ukládat wallety s klientskými certifikáty v bezpečném úložišti, například na čipové karty (viz Obrázek 2).
3.5.4. Konfigurace volitelných parametrů Pomocí nástroje Oracle Net Manager je možné na straně klienta i serveru specifikovat další volby, které umožňují nastavit konfiguraci SSL přesně podle požadavků. Obrázek 42. Konfigurace SSL pro server.
Zdroj: Kopie obrazovky.
62
Configuration Method – umožňuje upřesnit, kde se nachází wallet, pokud není použita standardní cesta do adresáře v souborovém systému. Cipher Suite Configuration – po stisknutí tlačítka Add je možné upřesnit, které sady šifer (vždy celistvá sada pro autentizaci, šifrování a datovou integritu) mají být používány při komunikaci. Pokud je vybrána pouze konkrétní sada či sady, musí být k dispozici na straně serveru i klienta. Seznam sad, které jsou k dispozici, je patrný z následujícího obrázku: Obrázek 43. Seznam sad šifer.
Zdroj: Kopie obrazovky.
Revocation Check – specifikuje, zda a jakým způsobem bude kontrolována platnost certifikátu v CRL. Kontrolovány jsou pouze uživatelské certifikáty. Require SSL Version – tímto parametrem je možné definovat verzi SSL, která bude používána pro komunikaci. Defaultní volba je Any, která zajistí výběr verze jako první shodné v pořadí TLS 1.0, SSL 3.0 a SSL 2.0. V dalších volbách je možné vynutit použití pouze jedné konkrétní verze - SSL 3.0 nebo TLS 1.0. Require Client Authentication – zaškrtnutí této volby zajistí, že klientské připojení bude autentizováno za použití SSL. Volby pro konfiguraci klienta jsou téměř totožné s volbami pro server, jak ukazuje i následující obrázek s volbami pro konfiguraci klienta:
63
Obrázek 44. Konfigurace SSL pro klienta.
Zdroj: Kopie obrazovky.
Oproti konfiguraci serveru je zde pouze volba Match server X.509 name, která umožňuje vynutit kontrolu, zda odpovídá rozlišovací jméno (DN) serveru jménu služby. V takovém případě je pak pomocí SSL zajištěno, že certifikát je skutečně z příslušného serveru, spojení je úspěšné pouze za předpokladu shody ve jménech.
64
4.
Výsledky
Cíl práce se mi podařilo dosáhnout, všechny součásti produktu, které jsem implementoval, ve výsledku fungovaly v dokumentaci popsaným způsobem a umožňovaly tak zvýšit zabezpečení uložených i přenášených dat. Při vlastní implementaci jsem však narazil na několik problémů, jejich řešení nebylo v dokumentaci k produktu předestřeno, v jednom případě pak řešení z dokumentace ukazovalo na jinou příčinu problému, skutečná příčina nebyla zmíněna. Tyto problémy podrobněji rozepisuji v textu dále. Současně je však potřeba znovu připomenout v úvodu zmíněnou skutečnost, že popsané problémy se mohou vztahovat pouze ke mnou používanému modelovému prostředí, na jiných platformách se tyto problémy nemusí projevit (a samozřejmě se mohou vyskytnout jiné). Firma Oracle podporuje rozsáhlou řadu platforem pro své jednotlivé produkty, podporované platformy i produkty Oracle se pak nabízejí v mnoha verzích. Dosažené výsledky je tak třeba posuzovat v kontextu modelového prostředí. Při plánovaném nasazení produktů firmy Oracle by mělo být samozřejmostí studium certifikačních matic, které firma Oracle zveřejňuje na svých stránkách. Z těchto matic je možné zjistit různé podporované kombinace platforem a produktů. V případě, že daná kombinace není podporována, nemusí uživatel produktů získat požadovanou podporu v případě výskytu problémů.
4.1. Oracle Network Manager Po nainstalování Oracle software a spuštění Oracle Network Manageru jsem neměl k dispozici volbu Oracle Advanced Security, jak je zobrazeno na následujícím obrázku: Obrázek 45. Neexistující volba Oracle Advanced Security.
Zdroj: Výřez z kopie obrazovky.
Podle
dokumentace
není
tato
volba
k dispozici
v případě,
že
v příslušném
ORACLE_HOME není instalován vlastní produkt Oracle Advanced Security. Produkt však instalován byl, což jsem ověřil kontrolou nainstalovaného software pomocí Oracle 65
Universal Installeru. 58 Po zobrazení úvodní obrazovky jsem pomocí tlačítka Installed Product vyvolal seznam instalovaných Oracle produktů na serveru, po zvolení příslušného ORACLE_HOME jsem zkontroloval, že produkt Oracle Advanced Security je skutečně nainstalován59: Obrázek 46. Kontrola instalovaných produktů pomocí Oracle Universal Installeru.
Zdroj: Výřez z kopie obrazovky upravený autorem práce.
Tento problém s nezobrazováním volby Oracle Advanced Security v seznamu, i když je produkt instalován, se občas vyskytoval již v předchozích verzích RDBMS Oracle. Příčina spočívá v nekorektním vyplnění příslušné položky s instalovanými komponentami v konfiguračním souboru. Pro nápravu je nutné upravit příslušný konfigurační soubor NetProperties, který se nalézá v cestě $ORACLE_HOME/network/tools/, pro opravu stačí přidat položce installedcomponents volbu ANO (zkratka z původního názvu Advanced Networking Option) nebo ASO (zkratka z Advanced Security Option), například následovně60:
58
Oracle Universal Installer lze vyvolat spuštěním runInstaller z příslušného ORACLE_HOME v cestě
$ORACLE_HOME/oui/bin, podmínkou pro zobrazení v UNIX prostředí je spuštěná podpora X-Window. 59
Stisknutím tlačítka Details lze získat detaily o vybrané komponentě (interní a externí jméno, čas instalace
a podobně). 60
Zdroj: http://metalink.oracle.com , Note 156345.1 - Oracle Net Configuration Tools Do Not Show
Advanced Security Pulldown (cit 2010-02-14). 66
Obrázek 47. Úprava položky installedcomponents v NetProperties.
Zdroj: Výřez z kopie obrazovky upravený autorem práce.
Po přidání této položky se již volba Oracle Advanced Security korektně zobrazovala, tento správný stav je zobrazen na následujícím obrázku: Obrázek 48. Zobrazená volba Oracle Advanced Security.
Zdroj: Výřez z kopie obrazovky.
4.2. Šifrování existujících sloupců tabulek Při šifrování sloupců tabulek příkazem ALTER TABLE jsem narazil na problém s nadále viditelnými údaji v datovém souboru, ačkoliv příslušný sloupec již byl zašifrován: Obrázek 49. Viditelná data uložená v šifrovaném sloupci tabulky.
Zdroj: Výřez z kopie obrazovky upravený autorem práce.
Po insertu dalšího řádku do tabulky však tento nový řádek viditelný nebyl:
67
Obrázek 50. Nečitelnost dat vložených po zašifrování sloupce tabulky.
Zdroj: Výřez z kopie obrazovky upravený autorem práce.
Tabulku jsem proto zkusil přemístit do jiného tabulkového prostoru pomocí SQL příkazu ALTER TABLE ...MOVE: ALTER TABLE personalni.zamestnanci MOVE TABLESPACE USERS; Příkaz se korektně dokončil. Ačkoliv již tabulka byla fyzicky umístěna v jiném tabulkovém prostoru, v datovém souboru příslušejícímu původnímu tabulkovému prostoru byly údaje nadále viditelné: Obrázek 51. Data viditelná v původním datovém souboru.
Zdroj: Výřez z kopie obrazovky.
Zkusil jsem tedy v původním tabulkovém prostoru vytvořit novou tabulku a plnit ji níže uvedenou jednoduchou smyčkou až do maximálního zaplnění tabulkového prostoru: CREATE TABLE test_table (sloupec1 CHAR(4)); BEGIN FOR i IN 1 .. 1000000 LOOP INSERT INTO test_table VALUES ('test'); COMMIT; END LOOP; END; / 68
Obrázek 52. Chybové hlášení z důvodu zaplnění tabulkového prostoru.
Zdroj: Výřez z kopie obrazovky.
Po zaplnění tabulkového prostoru již původní nezašifrované údaje nebyly viditelné: Obrázek 53. Nečitelnost dat v datovém souboru.
Zdroj: Výřez z kopie obrazovky.
Problém pravděpodobně spočívá ve skutečnosti, že po zašifrování již existujících dat jsou tato data uložena na jiné místo na disku a je pouze zrušen ukazatel na původní umístění. Podrobný popis procesu šifrování jsem v dokumentaci firmy Oracle nenalezl, nicméně výše uvedenou teorii podporuje skutečnost, že po zaplnění tabulkového prostoru novými údaji (a tím přepsání starých hodnot) již nejsou původní data viditelná. Současně nejsou viditelná data, která byla do sloupců vložena až poté, kdy již byl sloupec zašifrován. Výše popsané chování je nutné zohlednit v plánování přípravy nasazení šifrování sloupců tabulek pomocí produktu Oracle Advanced Security. Pokud budou některé již existující sloupce tabulek dodatečně zašifrovány, je vhodné následně přemístit celý obsah příslušného tabulkového prostoru do jiného, například pouze dočasného tabulkového prostoru. Původní tabulkový prostor je pak možné zrušit, vytvořit znovu a kompletní obsah z dočasného tabulkového prostoru přemístit zpět. Tím bude zajištěno, že původní čitelná data již nebudou na úrovni datových souborů viditelná. V opačném případě hrozí, že případný útočník bude moci tato data získat až do doby, kdy budou příslušná místa na disku přepsána. Firma Oracle navíc upozorňuje na skutečnost, že v databázových souborech mohou být uloženy staré, z databáze již nepřístupné kopie dat v nepoužitých datových blocích. Z tohoto důvodu doporučuje přemístit data do nového tabulkového prostoru a původní poté zrušit. Příslušné datové soubory je navíc vhodné smazat pomocí příkazu pro bezpečné
69
smazání (například příkaz shred na platformě Linux), aby je nebylo možné číst z operačního systému.61
4.3. Vytvoření šifrovaného tabulkového prostoru Při vytváření šifrovaného tabulkového prostoru jsem se jej pokusil vytvořit i s volbou NO SALT, což je podle syntaktického schématu v dokumentaci povolená volba při specifikaci šifrování. Příkaz pro vytvoření tabulkového prostoru však vrátil chybu z důvodu neplatné volby pro vytvářeni tabulkového prostoru, viz obrázek 54. Obrázek 54. Neplatná volba při vytváření šifrovaného tabulkového prostoru.
Zdroj: Výřez z kopie obrazovky upravený autorem práce.
Podle popisu chyby však není volba NO SALT platná při vytváření šifrovaného tabulkového prostoru. Při podrobnějším studiu dokumentace jsem dohledal poznámku, že volba NO SALT není z bezpečnostních důvodů povolena v případě šifrování celých tabulkových prostorů. Chování databázového systému je tedy správné, syntaktické schéma u příkazu CREATE TABLESPACE v dokumentaci je pouze uvedeno v kompletním tvaru pro specifikaci šifrovacího algoritmu, jeho část však není pro tento případ relevantní. V textovém popisu je pak uvedena poznámka, kterou část je možné použít. V dokumentaci k vlastnímu produktu Oracle Advanced Security je již pouze relevantní část syntaxe a několik příkladů, které jsou uvedeny správně, tedy bez možnosti zadat volbu NO SALT. Stejným způsobem je ošetřena syntaxe i u příkazu ALTER TABLESPACE, tedy v syntaktickém schématu je uvedena kompletní specifikace pro šifrování, textová
61
Zdroj:
http://www.oracle.com/technology/deploy/security/database-security/pdf/advanced-security-11g-
whitepaper.pdf (cit 2010-02-27). 70
poznámka pak uvádí, že tabulkový prostor není možné dodatečně zašifrovat, tudíž tato specifikace není relevantní.
4.4. Použití indexů Neplatnost volby NO SALT v případě použití při vytváření tabulkového prostoru mne inspirovala k prověření, zda v testovacím prostředí skutečně budou fungovat indexy pracující nad sloupci tabulek vytvořenými s NO SALT volbou. Dále jsem ještě vyzkoušel, zda indexy fungují v šifrovaných tabulkových prostorech, kde volba NO SALT vůbec není povolena. Očekávané chování podle dokumentace je, že ve výše uvedených případech je možné indexy použít. Pokud je šifrován pouze sloupec tabulky a je zašifrován s defaultní volbou SALT, index podle dokumentace použít možné není. Pro testování jsem vytvořil jednoduchou tabulku (DDL příkaz viz příloha 5), do které jsem naimportoval přibližně 90 tisíc řádek, jak je zachyceno na následujícím obrázku. Obrázek 55. Popis a počet řádků v tabulce pro testování indexů.
Zdroj: Výřez z kopie obrazovky.
Provedl jsem analýzu tabulky, aby měl optimalizátor správné statistiky62: BEGIN DBMS_STATS.GATHER_TABLE_STATS (OWNNAME => 'personalni', TABNAME => 'test_index_table', ESTIMATE_PERCENT => 100); END; / Následně jsem zobrazil prováděcí plán pro výběr jednoho z řádků tabulky v tomto stavu, to je zatím bez vytvořeného indexu:
71
Obrázek 56. Prováděcí plán zkoušeného příkazu SELECT bez indexu.
Zdroj: Výřez z kopie obrazovky upravený autorem práce.
Z prováděcího plánu vyplývá, že optimalizátor pro vyhledání daného záznamu použil prohledání celé tabulky (full table scan), což je očekávaný stav, jelikož nemá k dispozici žádnou pomocnou strukturu (index). Následně jsem vytvořil nad sloupcem ID index, jeho analýza pro zajištění správných statistik je provedena automaticky63: CREATE INDEX test_index ON test_index_table (ID); Potom jsem opět vypsal prováděcí plán: Obrázek 57. Prováděcí plán zkoušeného příkazu SELECT s indexem.
Zdroj: Výřez z kopie obrazovky upravený autorem práce.
62
Příkaz ANALYZE používaný v dřívějších verzích RDBMS Oracle pro sběr statistik je již podporován
pouze kvůli zpětné kompatibilitě, Oracle však doporučuje tento příkaz již nepoužívat.[12] 63
Nové chování od předchozí verze 10g, při vytváření nebo přestavění indexu již není nutné statistiky počítat
(například pomocí klauzule COMPUTE STATISTICS v rámci vytváření nebo přestavění indexu). 72
V tomto případě optimalizátor použije index pro vyhledání příslušného řádku v tabulce. Následně jsem v tabulce zašifroval indexovaný sloupec pomocí algoritmu AES256 s použitím volby NO SALT a ověřil, že sloupec je skutečně šifrován: Obrázek 58. Zašifrování sloupce tabulky,
Zdroj: Výřez z kopie obrazovky upravený autorem práce.
Index byl i po zašifrování sloupce ve stavu VALID (tedy použitelný), přesto jsem jej pro jistotu nezkreslených výsledků přestavěl: ALTER INDEX test_index REBUILD; Po přestavění indexu jsem opět vypsal prováděcí plán: Obrázek 59. Prováděcí plán zkoušeného příkazu SELECT s indexem nad sloupcem šifrovaným s NO SALT volbou.
Zdroj: Výřez z kopie obrazovky.
Prováděcí plán vypovídá o skutečnosti, že index je použit stejně jako v předchozím prováděcím plánu, který jsem si vypsal před zašifrováním sloupce. Index tedy skutečně funguje i nad zašifrovaným sloupcem. Odpovídá i Plan hash value, optimalizátor tedy vyhodnotí jako optimální naprosto totožný prováděcí plán (v případě nějakých odchylek by došlo ke změně čísla prováděcího plánu). Jako další krok jsem zkusil vytvořit indexy nad sloupcem zašifrovaným s implicitní volbou SALT, podle dokumentace by za této situace index neměl fungovat. Databázový systém mě 73
toto vůbec nenechal provést, při pokusu o změnu sloupce přidáním SALT i při pokusu o vytvoření indexu nad sloupcem zašifrovaným se SALT se zobrazila chyba ORA-28338 a příkaz byl odmítnut: Obrázek 60. Pokusy o vytvoření indexu nad šifrovaným sloupcem se SALT volbou.
Zdroj: Výřez z kopie obrazovky upravený autorem práce.
Na úrovni, kdy jsou šifrovány pouze sloupce v tabulkách tedy s indexy není problém, vše funguje definovaným způsobem. Přistoupil jsem tedy k šifrování na úrovni tabulkových prostorů, kdy volba NO SALT není vůbec podporována a indexy podle dokumentace mají fungovat. Vytvořil jsem tedy šifrovaný tabulkový prostor a přesunul do něj testovací tabulku64. ALTER
TABLE
personalni.test_index_table
MOVE
TABLESPACE
encrypt_personalni; Nad tabulkou jsem za pomoci analogických příkazů jako výše vytvořil index, analyzoval tabulku i tento vytvořený index a vypsal jsem prováděcí plán:
64
Přislušný sloupec jsem před přesunem dešifroval, aby nemohlo dojít k ovlivnění výsledků. 74
Obrázek 61. Prováděcí plán zkoušeného příkazu SELECT s indexem v šifrovaném tabulkovém prostoru.
Zdroj: Výřez z kopie obrazovky.
Výsledkem je tedy opět použití indexu pro vyhledání příslušného záznamu, prováděcí plán je znovu totožný s plánem, který byl vytvořen při použití indexu nad nešifrovaným sloupcem tabulky. Indexy tedy bez problémů fungují i nad daty uloženými v tabulkách v zašifrovaném tabulkovém prostoru.
4.5. Čitelnost dat v indexech Je nutné si uvědomit, že vlastní index v sobě také obsahuje data, která jsou v dané tabulce zašifrována (ať již na úrovni sloupců tabulek, nebo na úrovni tabulkového prostoru). Útočník se tedy může dostat k těmto datům v datovém souboru, který je příslušející k tabulkovému prostoru, v němž je index vytvořen. Opět také platí, že pokud byl index vytvořen před zašifrováním, zůstávají původní data v datovém souboru čitelná až do doby, než budou přepsána. S tím je tedy třeba počítat v rámci přípravy na implementaci Oracle Advanced Security a naplánovat například i zrušení tabulkového prostoru s příslušnými indexy a jeho následné nové vytvoření. Problém by však mohla způsobit i následující odlišnost v chování jednotlivých druhů šifrování, v tomto případě již jde o zašifrovaná data v tabulce: Při testování indexů jsem zjistil, že indexy se chovají rozdílně v závislosti na tom, zda jsou vytvořeny
nad
zašifrovaným
sloupcem,
nebo
nad
sloupcem
tabulky
uložené
v zašifrovaném tabulkovém prostoru. Pokud je index vytvořen nad zašifrovaným sloupcem tabulky (sloupec samozřejmě musí být zašifrován s NO SALT volbou), není možné přečíst data ani v indexu. Naopak v případě, že je index vytvořen nad sloupcem tabulky, která je uložena v šifrovaném tabulkovém prostoru, je možné data v indexu přečíst. 75
Případný problém s čitelností dat při použití šifrování kompletních tabulkových prostorů lze elegantně vyřešit zašifrováním všech aplikačních tabulkových prostorů. Ve výsledku tak jsou zašifrovány nejenom tabulkové prostory, v nichž jsou ukládány vlastní data, ale i tabulkové prostory s indexy65.
65
Uložit data a indexy je možné i do stejného tabulkového prostoru, toto však není vhodné z výkonnostních
důvodů. 76
Závěry a doporučení Mé zkušeností z implementace Oracle Advanced Security ukazují, že tento produkt může posunout zabezpečení databázového systému v produktem pokrytých oblastech na daleko vyšší úroveň. Veškeré implementované komponenty produktu fungovaly v modelovém prostředí v dokumentaci definovaným způsobem, pro řešení některých problémů při vlastní implementaci je však vhodné mít přístup na internetové stránky technické podpory firmy Oracle, jelikož z dokumentace nemusí být zřejmé, jak daný problém řešit. V rámci přípravy je nutné plánovat nejenom vlastní nasazení produktu, ale po jeho nasazení je potřeba provést i testování vhodným způsobem. Testování by mělo být samozřejmou součástí každého projektu, v tomto případě však jde o produkt, jehož funkčnost není na první pohled nijak viditelná. Databáze nadále funguje standardním způsobem a činnost implementovaného produktu není na první pohled nijak zřejmá, proto je vhodným způsobem provedená kontrola jak vlastní funkčnosti produktu, tak zejména jeho správné implementace velmi důležitá, Produkt Oracle Advanced Security a jeho přínos pro zvýšení zabezpečení databázového systému je však potřeba hodnotit v kontextu adekvátního zabezpečení ostatních komponent informačního systému. Tento produkt sám o sobě nemůže sloužit jako jediné zabezpečení, ale je potřeba jej posuzovat jako jednu ze součástí hloubkové ochrany dat v informačním systému. Je tedy nutné mít chráněny veškeré součásti informačního systému, tudíž hlavním předpokladem je existence bezpečnostní politiky ve firmě. V souladu s touto bezpečnostní politikou pak musejí být zabezpečeny veškeré součásti informačního systému. Zabezpečení tak začíná již dostatečnou fyzickou ochranou serverovny a síťových prvků firemní počítačové sítě, přes odpovídající zabezpečení operačních systémů serverů i personálních počítačů, až po používání pravidelně aktualizovaného antivirového software. Součástí prvků ochrany informačního systému je pak samozřejmě i nasazení odpovídajícím způsobem
nakonfigurovaných
firewallů,
systémů
detekce
narušení,
pravidelné
vyhodnocování různých systémových logů, auditních záznamů a podobně. Jestliže jsou splněny předpoklady z předchozího odstavce, má smysl zhodnotit přínos nasazení Oracle Advanced Security. Toto musí být opět provedeno v souladu s bezpečnostní politikou, jejíž součástí je i provedená bezpečnostní analýza. Tato analýza mimo jiné ohodnotila i firemní aktiva, je tedy známa cena dat uložených v databázi. Vhodnost nasazení produktu je pak otázkou poměru ceny dat a ceny vlastního produktu
77
Oracle Advanced Security pro konkrétní prostředí. Přiměřenost nákladů na nasazení produktu se tedy nutně bude lišit podle oborů činnosti různých firem, charakteru uchovávaných dat a mnoha dalších okolností. Výjimkou může být nutnost nasazení produktu pro splnění zákonných předpisů či oborových standardů, jako je například v úvodu zmíněný standard PCI-DSS. V takovém případě je nutné produkt nasadit i v případě, že tato implementace vzhledem k ceně v databázi uchovávaných aktiv nebude odpovídající vynaloženým nákladům. Pokud budu hodnotit pouze technickou stránku implementovaného produktu, musím konstatovat, že velký přínos pro lepší zabezpečení jak přenášených, tak v databázi uložených dat, je nesporný. Tento produkt může vhodně rozšířit a doplnit zabezpečení dat, uplatnění tak lze očekávat zejména v oblastech, které z povahy své činnosti pracují s velmi citlivými údaji, tedy například ve zdravotnictví nebo bankovnictví a pojišťovnictví.
78
Seznam použité literatury
1. DOSEDĚL, Tomáš. Počítačová bezpečnost a ochrana dat. Brno: Computer Press, 2004. 190 s. ISBN 80-251-0106-1. 2. DOSTÁLEK, Libor a kolektiv. Velký průvodce protokoly TCP/IP: Bezpečnost. Praha: Computer Press, 2001. 566 s. ISBN 80-7226-513-X. 3. DOSTÁLEK, Libor; VOHNOUTOVÁ, Marta. Velký průvodce infrastrukturou PKI a technologií elektronického podpisu. Brno: Computer Press, 2007. 534 s. ISBN 80251-0828-7. 4. FINNIGAN, Pete. Oracle Database Security Auditing. York: PeteFinnigan.com Limited. Oracle University Celebrity seminar. Praha, 3. - 4.11.2009. 5. KESTNER, Peter. Oracle Security Products. Praha, 12.3.2008. Přednáška v rámci odborného semináře Oracle Database Vault. 6. KOSTRZEWA, Michal. Oracle Platform for Secure Data Processing. Praha, 12.3.2008. Přednáška v rámci odborného semináře Oracle Database Vault. 7. KUDĚLKA, Tomáš. Úvod do informační bezpečnosti. Praha, 18.9.2007. Přednáška v rámci Oracle Security Day. 8. LITCHFIELD, David. The Oracle Hacker’s Handbook: Hacking and Defending Oracle. Indianopolis: Wiley Publishing, 2007. 190 s. ISBN 978-0-470-08022-1. 9. NORTHCUTT, Stehen, et al. Bezpečnost sítí: Velká kniha. Brno: CP Books, 2005. 590 s. ISBN 80-251-0697-7. 10. Oracle Corporation. Oracle Database Advanced Security Administrator's Guide 11g Release 1 (11.1), Part Number B28530-02, CD-ROM . s.l. . 11. Oracle Corporation. Oracle Database Security Guide 11g Release 1 (11.1), Part Number B28531-02, CD-ROM . s.l. . 12. Oracle Corporation. Oracle Database SQL Language Reference 11g Release 1 (11.1), Part Number B28286-02, CD-ROM . s.l. . 13. THERIAULT, Marlene; NEWMAN, Aaron. Bezpečnost v Oracle. Brno: Computer Press, 2004. 516 s. ISBN 80-722-6979-8.
79
Seznam zkratek
CRL – Cerificate Revocation List, datová struktura obsahující seznam odvolaných certifikátů, součást PKI. CRM – Customer Relationship Management, systém pro řízení vztahu se zákazníky. DNS – Domain Name System, hierarchický systém domén pro překlad jmen počítačů na IP adresy a naopak. DDL – Data Definition Language, část jazyka SQL určená pro definici dat. GUI – Grafic User Interface, grafické uživatelské rozhraní – umožňuje uživateli ovládat počítač pomocí grafického rozhraní. HTTPS – Hypertext Transfer Protocol Secure, zabezpečená verze protokolu HTTP rozšířením o SSL/TLS protokol, umožňuje tak zabezpečený přenos dat. JDBC – Java Database Connectivity, rozhraní pro připojení Java programů do databázového systému. MITM – Man In The Middle, bezpečnostní útok proti komunikaci přicházející ze třetí strany. PKI – Public Key Infrastructure, infrastruktura veřejného klíče, prostředí pro kompletní správu certifikátů, kryptografických klíčů a jejich využití. RDBMS - Relational Database Management System, systém řízení báze dat (SŘBD). SSL – Secure Sockets Layer, protokol pro bezpečnou síťovou komunikaci za použití PKI. SQL – Structured Query Language, strukturovaný dotazovací jazyk používaný v relačních databázových systémech.
80
Seznam schémat, tabulek a obrázků
Seznam schémat Schéma 1.
Syntaxe příkazu CREATE TABLESPACE. ............................................... 51
Schéma 2.
Syntaxe příkazu CREATE TABLE. ............................................................ 53
Schéma 3.
Syntaxe příkazu ALTER TABLE...MODIFY. ............................................ 54
Schéma 4.
Syntaxe příkazu ALTER TABLE...ADD. ................................................... 54
Seznam tabulek Tabulka 1.
Vybraná rizika a jejich pokrytí produktem Oracle Advanced Security....... 34
Tabulka 2.
Možné kombinace požadavků na šifrování. ................................................ 41
Tabulka 3.
Změny provedené v tnsnames.ora na klientovi. .......................................... 60
Seznam obrázků Obrázek 1.
Útok typu MITM na síťovou komunikaci. .................................................. 12
Obrázek 2.
Čtečka Gemplus s čipovou kartou a token SecurID. ................................... 17
Obrázek 3.
Výběr
produktu
Oracle
Advanced
Security
v průběhu
instalace
na databázovém serveru. ..................................................................................................... 21 Obrázek 4.
Výběr produktu Oracle Advanced Security v průběhu instalace na klientovi
Oracle databáze.................................................................................................................... 22 Obrázek 5.
Šifrovaný sloupec tabulky. .......................................................................... 25
Obrázek 6.
Šifrování tabulkového prostoru. .................................................................. 27
Obrázek 7.
Oblast komunikace zabezpečené pomocí Oracle Advanced Security. ........ 29
Obrázek 8.
Autentizace prostřednictvím služby třetí strany. ......................................... 31
Obrázek 9.
Přihlašovací proces při využití autentizačního serveru. .............................. 32
Obrázek 10.
Spuštění Oracle Net Manageru. ................................................................... 36
Obrázek 11.
Prostředí Oracle Net Manageru. .................................................................. 37
Obrázek 12.
Výběr produktu Oracle Advanced Security v Oracle Net Manageru. ......... 37
Obrázek 13.
Spuštění Oracle Wallet Manageru. .............................................................. 38
Obrázek 14.
Prostředí Oracle Wallet Manageru. ............................................................. 38 81
Obrázek 15.
Výsledek dotazu na zaměstnance zobrazený v klientském prostředí. ......... 39
Obrázek 16.
Výpis zachycené síťové komunikace mezi databázovým serverem
a klientem, přenášené v nešifrované formě. ........................................................................ 39 Obrázek 17.
Prostředí pro konfiguraci šifrování v Oracle Net Manageru. ...................... 42
Obrázek 18.
Uložení síťové konfigurace v Oracle Net Manageru................................... 43
Obrázek 19.
Výpis zachycené síťové komunikace mezi databázovým serverem
a klientem, přenášené v šifrované formě ............................................................................. 43 Obrázek 20.
Prostředí pro konfiguraci kontroly integrity v Oracle Net Manageru ......... 45
Obrázek 21.
Výpis řádků přidaných do sqlnet.ora pro cestu k walletu. .......................... 47
Obrázek 22.
Výpis souboru s walletem v operačním systému. ....................................... 47
Obrázek 23.
Vytvoření automaticky otevíraného walletu. .............................................. 48
Obrázek 24.
Výpis walletů v operačním systému. ........................................................... 48
Obrázek 25.
Výpis tabulky ZAMESTNANCI. ................................................................ 49
Obrázek 26.
Zobrazení obsahu datového souboru příkazem strings. .............................. 49
Obrázek 27.
Zobrazení obsahu datového souboru příkazem od. ..................................... 50
Obrázek 28.
Zobrazení parametru COMPATIBLE. ........................................................ 50
Obrázek 29.
Výpis všech šifrovaných tabulkových prostorů. ......................................... 52
Obrázek 30.
Výpis popisu tabulky před přidáním sloupce. ............................................. 55
Obrázek 31.
Kontrola šifrování sloupce tabulky. ............................................................ 55
Obrázek 32.
Kontrola šifrování sloupců tabulek v operačním systému. ......................... 55
Obrázek 33.
Položky certifikačního požadavku............................................................... 57
Obrázek 34.
Certifikát připravený k používání. ............................................................... 58
Obrázek 35.
Specifikace uložení walletu na serveru. ...................................................... 59
Obrázek 36.
Lokalizace walletu v konfiguračních souborech. ........................................ 59
Obrázek 37.
Konfigurace listeneru pro použití SSL. ....................................................... 59
Obrázek 38.
Specifikace uložení walletu na klientovi. .................................................... 60
Obrázek 39.
Komunikace mezi databázovým serverem a klientem při použití SSL. ...... 61
Obrázek 40.
Vytvoření externě autentizovaného uživatele. ............................................ 61
Obrázek 41.
Připojení klienta s ověřením pomocí certifikátu. ........................................ 62
Obrázek 42.
Konfigurace SSL pro server. ....................................................................... 62 82
Obrázek 43.
Seznam sad šifer. ......................................................................................... 63
Obrázek 44.
Konfigurace SSL pro klienta. ...................................................................... 64
Obrázek 45.
Neexistující volba Oracle Advanced Security. ............................................ 65
Obrázek 46.
Kontrola instalovaných produktů pomocí Oracle Universal Installeru. ...... 66
Obrázek 47.
Úprava položky installedcomponents v NetProperties................................ 67
Obrázek 48.
Zobrazená volba Oracle Advanced Security. .............................................. 67
Obrázek 49.
Viditelná data uložená v šifrovaném sloupci tabulky. ................................. 67
Obrázek 50.
Nečitelnost dat vložených po zašifrování sloupce tabulky. ......................... 68
Obrázek 51.
Data viditelná v původním datovém souboru. ............................................. 68
Obrázek 52.
Chybové hlášení z důvodu zaplnění tabulkového prostoru. ........................ 69
Obrázek 53.
Nečitelnost dat v datovém souboru. ............................................................ 69
Obrázek 54.
Neplatná volba při vytváření šifrovaného tabulkového prostoru. ............... 70
Obrázek 55.
Popis a počet řádků v tabulce pro testování indexů. ................................... 71
Obrázek 56.
Prováděcí plán zkoušeného příkazu SELECT bez indexu. ......................... 72
Obrázek 57.
Prováděcí plán zkoušeného příkazu SELECT s indexem. .......................... 72
Obrázek 58.
Zašifrování sloupce tabulky, ....................................................................... 73
Obrázek 59.
Prováděcí plán zkoušeného příkazu SELECT s indexem nad sloupcem
šifrovaným s NO SALT volbou. ......................................................................................... 73 Obrázek 60.
Pokusy o vytvoření indexu nad šifrovaným sloupcem se SALT volbou. ... 74
Obrázek 61.
Prováděcí plán zkoušeného příkazu SELECT s indexem v šifrovaném
tabulkovém prostoru. ........................................................................................................... 75
83
Seznam příloh
1. Instalace modelového prostředí – databázový server. 2. Instalace modelového prostředí – databázový klient. 3. Algoritmy používané v Oracle Advanced Security pro šifrování a integritu. 4. DDL příkazy pro vytvoření testovacího prostředí. 5. DDL příkazy pro vytvoření tabulky pro testování použití indexů.
84
Příloha č. 1 Instalace modelového prostředí – databázový server V příloze jsou zachyceny kopie obrazovek z průběhu instalace modelového prostředí.
Instalace databázového SW Oracle verze 11.1.0.6. ./runInstaller
Je nutné vybrat buď Enterprise Edition, kde je produkt Oracle Advanced Security implicitně instalován, nebo volbu Custom a Oracle Advanced Security vybrat mezi instalované produkty zaškrtnutím. Ve Standard Edition není produkt Oracle Advanced Security zahrnut. Zde je vybrána volba Custom.
[root@racek2 11.1.RZ]# ./root.sh Running Oracle 11g root.sh script...
The following environment variables are set as: ORACLE_OWNER= oracle
ORACLE_HOME= /oracle/product/db/11.1.RZ
Enter the full pathname of the local bin directory: [/usr/local/bin]: The file "dbhome" already exists in /usr/local/bin. Overwrite it? (y/n) [n]: The file "oraenv" already exists in /usr/local/bin. Overwrite it? (y/n) [n]: The file "coraenv" already exists in /usr/local/bin. Overwrite it? (y/n) [n]:
Entries will be added to the /etc/oratab file as needed by Database Configuration Assistant when a database is created Finished running generic part of root.sh script. Now product-specific root actions will be performed. Finished product-specific root actions.
Upgrade databázového SW na verzi 11.1.0.7. ./runInstaller
[root@racek2 11.1.RZ]# ./root.sh Running Oracle 11g root.sh script...
The following environment variables are set as: ORACLE_OWNER= oracle ORACLE_HOME= /oracle/product/db/11.1.RZ
Enter the full pathname of the local bin directory: [/usr/local/bin]: The file "dbhome" already exists in /usr/local/bin. Overwrite it? (y/n) [n]: The file "oraenv" already exists in /usr/local/bin. Overwrite it? (y/n) [n]: The file "coraenv" already exists in /usr/local/bin. Overwrite it? (y/n) [n]:
Entries will be added to the /etc/oratab file as needed by Database Configuration Assistant when a database is created Finished running generic part of root.sh script. Now product-specific root actions will be performed. Finished product-specific root actions.
Vytvoření databáze pomocí nástroje Database Configuration Assistant: ./dbca
Příloha č. 2 Instalace modelového prostředí – databázový klient V příloze jsou zachyceny kopie obrazovek z průběhu instalace modelového prostředí. setup.exe
Konfigurační asistent pomáhá při nastavení připojení pomocí Oracle Net do databáze. Je možné jej podle úvahy přeskočit (pokud již existují konfigurační soubory) nebo například nechat nastavit typickou konfiguraci a použít ji jako vzor.
Příloha č. 3 Algoritmy používané v Oracle Advanced Security pro šifrování a integritu
Šifrovací algoritmy: AES – Advanced Encryption Standard – symetrická bloková šifra, může zpracovávat 128bitové bloky za použití šifrovacího klíče o délce 128, 192, nebo 256 bitů. Tento algoritmus je v současné době doporučován jako bezpečný. DES – Data Encryption Standard – symetrická bloková šifra, která standardně používá klíč o délce 56 bitů. V současnosti již tento algoritmus není považován za dostatečně bezpečný. 3DES – Triple DES – symetrická bloková šifra, která vícekrát aplikuje algoritmus DES, v Oracle Advanced Security je používán ve dvouklíčové (112 bitů) a tříklíčové verzi (168 bitů). Vzhledem k vícenásobné aplikaci algoritmu je pomalejší než AES (a samozřejmě DES). RC4 – proudová šifra, výhodou je velká rychlost šifrování s minimálním výkonnostním dopadem. Integritní algoritmy MD5 – Message Digest - 5, tento algoritmus generuje z přenášených dat hash (otisk) o velikosti 128 bitů. SHA-1 – Secure Hash Algorithm - 1, generuje otisk o délce 160 bitů. Tento algoritmus je bezpečnější než MD5, současně je ovšem o něco pomalejší.
Příloha č. 4 DDL příkazy pro vytvoření testovacího prostředí
CREATE TABLESPACE personalni DATAFILE '/home/zela/oracle/RZOAS/personalni01.dbf' SIZE 4M;
CREATE USER personalni IDENTIFIED BY personalni DEFAULT TABLESPACE personalni TEMPORARY TABLESPACE temp; GRANT create session, create table TO personalni; ALTER USER personalni quota unlimited ON personalni;
CREATE TABLE personalni.zamestnanci (cislo_zamestnance VARCHAR(5), prijmeni VARCHAR2(25), jmeno VARCHAR2(20), cislo_karty VARCHAR(16));
INSERT INTO personalni.zamestnanci VALUES (501, 'Novak', 'Petr', 1111222233334444); INSERT INTO personalni.zamestnanci VALUES (102, 'Kusy', 'Martin', 2222333344445555); INSERT INTO personalni.zamestnanci VALUES (333, 'Novakova', 'Lucie', 3333444455556666); INSERT INTO personalni.zamestnanci VALUES (458, 'Herman', 'Rudolf', 4444555566667777); INSERT INTO personalni.zamestnanci VALUES (52, 'Koblasova', 'Marie', 5555666677778888); INSERT INTO personalni.zamestnanci VALUES (896, 'Sadil','Pavel', 6666777788889999); INSERT INTO personalni.zamestnanci VALUES (79, 'Nosek', 'Karel', 7777888899991111);
Příloha č. 5 DDL příkazy pro vytvoření tabulky pro testování použití indexů
CREATE TABLE personalni.test_index_table (id NUMBER(8), jmeno VARCHAR2(85), kategorie vARCHAR2(32)); INSERT INTO personalni.test_index_table SELECT id, name, entlevel FROM test_data.data_list;
