Zabezpečení Oracle databáze

Bankovní institut vysoká škola Praha Katedra matematiky, statistiky a informačních technologií

Zabezpečení Oracle databáze Diplomová práce

Autor:

Bc. Luděk Holý Informační technologie a management

Vedoucí práce:

Praha

Ing. Jiří Rezler

Duben, 2012

Prohlášení:

Prohlašuji, ţe jsem diplomovou práci zpracoval samostatně a v seznamu uvedl veškerou pouţitou literaturu.

Svým podpisem stvrzuji, že odevzdaná elektronická podoba práce je identická s její tištěnou verzí, a jsem seznámen se skutečností, že se práce bude archivovat v knihovně BIVŠ a dále bude zpřístupněna třetím osobám prostřednictvím interní databáze elektronických vysokoškolských prací.

V Praze, dne 21. 4. 2012

Luděk Holý

Poděkování: Na tomto místě bych rád poděkoval několika lidem, kteří měli významný vliv na podmínky vzniku této práce a bez jejichž podpory by tato diplomová práce nevznikla. V první řadě chci poděkovat mé manželce Jitce a dceři Veronice, dále mým i manželčiným rodičům za osobní podporu po celou dobu mého studia. V neposlední řadě též samozřejmě vedoucímu práce Ing. Jiřímu Rezlerovi za citlivé vedení, dobré a užitečné rady, bez kterých by tato práce nemohla být v této podobě dokončena.

Anotace Diplomová práce zpracovává téma ochrany dat Oracle databáze a má poskytnout ucelený přehled o moţnostech zabezpečení databázových dat, mapuje různé bezpečnostní prvky Oracle databází a popisuje pouţívané bezpečnostní normy. Dále si klade za cíl implementaci bezpečnostních prvků na databázi ASR, které jsou vyţadované normou PCI DSS, a zabezpečit tak citlivá klientská data uchovávaná v této databázi. Práce je rozdělena do dvou částí, teoretické a praktické. V teoretické části popisuji pouţívané pojmy, bezpečnostní komponenty a běţně pouţívané metody databázové bezpečnosti. Dále popíši existující bezpečnostní normy aplikovatelné na Oracle databáze a ostatní aspekty ochrany dat. V praktické části pak zhodnotím dotazníkový průzkum a v rámci přípravy projektu provedu „Proof of Concept“ zabezpečení databáze v souladu s poţadavky normy PCI DSS. Klíčová slova: Bezpečnost, Oracle, Databáze, Audit, TDE, Database Vault, Projekt, PCI DSS

Annotation The subject of the Diploma thesis is the issue of data protection. It should also provide a comprehensive overview of the Oracle database security capabilities. It focuses on various security features and describes the database security standards. The thesis aims to implement the security features in the ASR database that are required by PCI DSS, and to secure sensitive client data stored in this database. The thesis is divided into two parts, theoretical and practical. The theoretical part describes the concepts used, safety components and commonly used methods of database security. It describes the existing safety standards applicable to Oracle Database and other aspects of data protection. In the practical part I will evaluate the questionnaire survey and during the preparation of the project I will create a Proof of Concept of database security hardening in accordance with the requirements of PCI DSS. Key words: Security, Oracle, Database, Audit, TDE, Database Vault, Project, PCI DSS

Obsah Úvod ...................................................................................................................................... 7 Zvolené metody zpracování ................................................................................................ 8 1 Moţnosti zabezpečení databáze .................................................................................. 9 1.1 Základní oblasti bezpečnosti ................................................................................... 9 1.2 Hrozby .................................................................................................................... 9 1.2.1 Hrozby zevnitř samotné organizace .............................................................. 10 1.2.2 Hrozby z venkovního prostředí ..................................................................... 11 1.2.3 Bezpečnostní problémy ................................................................................. 12 1.2.4 Vnější zabezpečení databáze ......................................................................... 13 1.3 Základní termíny ................................................................................................... 15 1.3.1 Autentizace .................................................................................................... 15 1.3.2 Třívrstvá architektura .................................................................................... 18 1.3.3 Autentizace na straně klienta ......................................................................... 18 1.3.4 Oracle Identity Manager ................................................................................ 18 1.3.5 Uţivatelské účty ............................................................................................ 18 1.3.6 Profily ............................................................................................................ 20 1.3.7 Autorizace...................................................................................................... 22 1.3.8 Systémová oprávnění..................................................................................... 22 1.3.9 Objektová oprávnění ..................................................................................... 23 1.3.10 Databázové role ............................................................................................. 24 1.3.11 Přiřazení práv................................................................................................. 25 1.4 Další bezpečnostní prvky ...................................................................................... 26 1.4.1 Audit .............................................................................................................. 26 1.4.2 Fine Grained Auditing ................................................................................... 29 1.4.3 LogMiner ....................................................................................................... 29 1.4.4 ADR Command Interpreter .......................................................................... 29 1.4.5 Triggery ......................................................................................................... 29 1.4.6 Pohledy .......................................................................................................... 30 1.4.7 Access Control List ....................................................................................... 30 1.4.8 Šifrování dat .................................................................................................. 31 1.4.9 Oracle Wallet ................................................................................................. 31 1.4.10 Virtuální privátní databáze ............................................................................ 32 1.4.11 Oracle Label Security .................................................................................... 32 1.4.12 Oracle Database Vault ................................................................................... 33 1.4.13 Oracle Audit Vault ........................................................................................ 34 1.5 Oracle Advanced Security Option ........................................................................ 35 1.5.1 Transparentní šifrování dat ............................................................................ 36 1.5.2 Šifrování síťové komunikace......................................................................... 36 1.5.3 Silná autentizace ............................................................................................ 38 1.5.4 Oracle Database Firewall............................................................................... 39 1.5.5 Oracle Data Masking ..................................................................................... 39 2 Bezpečnostní normy .................................................................................................. 41 1.6 PCI DSS ................................................................................................................ 41 1.7 ITIL ....................................................................................................................... 43 1.8 COBIT .................................................................................................................. 45 1.9 Ostatní normy a pouţívané standardy ................................................................... 47

2

Ostatní aspekty databázové bezpečnost .................................................................. 49 2.1 Aplikační zabezpečení .......................................................................................... 49 2.1 Bezpečnost dat ...................................................................................................... 49 2.2 Vysoká dostupnost ................................................................................................ 50 2.2.1 Cold failover cluster ...................................................................................... 50 2.2.2 Oracle Real Application Clusters .................................................................. 51 2.2.3 Oracle Data Guard ......................................................................................... 52 3 Aplikace bezpečnostních politik v bankovním prostředí ....................................... 53 3.1 Trendy v databázové bezpečnosti ......................................................................... 53 3.2 Základní kroky k zabezpečení databáze ............................................................... 54 3.3 Průzkumy bezpečnostní situace ............................................................................ 56 3.4 Anketa o bezpečnostních otázkách Oracle databáze ............................................ 58 3.5 Výsledky ankety.................................................................................................... 59 3.6 Splnění normy PCI DSS pro systém ASR ............................................................ 66 3.7 Zabezpečení databáze ASR................................................................................... 66 3.8 Projekt ................................................................................................................... 71 3.8.1 Obecný ţivotní cyklus projektu v bankovním prostředí................................ 71 3.8.2 Etapa I – Zahájení projektu ........................................................................... 72 3.8.3 Etapa II – Plánování a výběr řešení ............................................................... 75 3.8.4 Etapa III – realizace řešení ............................................................................ 76 3.8.5 Etapa IV – Provoz a údrţba databázového systému ...................................... 78 3.9 Praktická realizace PCI DSS na databázi.............................................................. 80 3.9.1 Databázová instalace ..................................................................................... 80 3.9.2 Vyhodnocení proof of conceptu .................................................................... 91 Závěr ................................................................................................................................... 92 Seznam pouţité literatury ................................................................................................. 94 Definice, akronymy a zkratky .......................................................................................... 96 Seznam pouţitých obrázků:.............................................................................................. 98 Seznam pouţitých tabulek: ............................................................................................... 98 Přílohy ................................................................................................................................ 99

Úvod V dnešním světě se téměř ţádná organizace neobejde bez pouţití informačních technologií. Pokud daná organizace zpracovává a uchovává jakákoliv data v elektronické podobě, nejčastěji si jako vlastní úloţiště dat volí databázový systém. Podle svých potřeb si především vybírá z komerčních databázových produktů firem Oracle, Microsoft, IBM a dalších, případně si můţe pro uchování svých dat zvolit open source databázové produkty, například databázový produkt MySQL, přestoţe především v bankovnictví panuje nedůvěra ke kvalitě zabezpečení podobných produktů, z tohoto důvodu se tedy vyuţívají především komerční produkty, za kterými stojí silná společnost. Pracovníci odpovědní za rozvoj, správu a provoz ICT musí nejpozději v době implementace nového informačního systému zvolit úroveň poţadovaného zabezpečení databázových dat, neboť jejich případné zneuţití či vyzrazení můţe fatálně poškodit provoz organizace reputačními a finančními ztrátami a zároveň právními následky plynoucími z nesplněných závazků a povinností vůči klientům, obchodním partnerům i státním institucím a nezvratně tak poškodit důvěryhodnost firmy v očích jejích partnerů. V závislosti na povaze, provozním reţimu a důleţitosti informačního systému je nutné zvolit kompromis mezi důleţitosti uchovávaných dat a náklady jejich zabezpečení. S rozvojem nových platebních kanálů a stále se rozšiřujících moţností, jak klienti komunikují se svou bankou, stojí bankovní ústavy před povinností splnit různé certifikační standardy. Budu se především věnovat standardu karetní asociace - normě PSI DSS1. Ve své práci budu pracovat s databázovým systémem firmy Oracle v aktuální verzi 11gR2 a postupně představím a popíši moţnosti zabezpečení databáze, zmíním i další moţné prostředky k zajištění vyšší bezpečnosti a navrhnu realizaci robustně zabezpečeného databázového systému ASR v prostředí finanční instituce, které plní poţadavky normy PCI DSS na zabezpečení informaci z karetních transakcí.

1

PCI DSS - Payment Card Industry Data Security Standard

7

Zvolené metody zpracování Ve své práci budu vycházet ze studia odborné literatury z oblasti administrace a bezpečnosti Oracle databází, dále z poţadavků bezpečnostních norem, které se zabývají problematikou databází. Pro zjištění aktuálních trendů v databázové bezpečnosti budu studovat dostupné výzkumy renomovaných agentur týkající se bezpečnostních otázek Oracle databází a také provedu vlastní průzkum trendů mezi databázovými administrátory. V neposlední řadě budu stavět na vlastních zkušenostech databázového administrátora, který je odpovědný za bezpečnostní nastavení databází, jeţ spravuje, a ve své praxi se dennodenně potýká s bezpečnostními problémy a je nucen plnit poţadavky z auditních nálezů. Ve své diplomové práci nahlíţím na popisovanou problematiku z pozice databázového administrátora a můj pohled můţe být ovlivněn mou profesní zkušeností. Tento přístup se snaţí doplnit a rozšířit stávající pohled auditorů, IT architektů a provozních manaţerů o další, moţná méně zřejmá fakta a skutečnosti.

8

1 Moţnosti zabezpečení databáze 1.1 Základní oblasti bezpečnosti Databázový administrátor spravující Oracle databáze ve své praxi řeší následující výzvy. Jak zajistit, aby instalace a konfigurace databáze byla bezpečná. Jak zajistit bezpečnostní aspekty uţivatelských účtů, jak vytvořit správnou politiku hesel, jak vytvářet a přiřazovat role, jak zpřístupnit data pouze oprávněným uţivatelům. Jak zabezpečit síťové spojení do databáze. Jak zašifrovat citlivá data. Jak opravit bezpečnostní díry a ochránit databázi před útočníky. Pravidelně sledovat zveřejněné bezpečnostní problémy a záplatovat databázi. Nastavit potřebnou úroveň auditování. V malé společnosti všechny tyto povinnosti dokáţe zabezpečit samotný databázový správce, ve větších firmách tyto poţadavky řeší specializované týmy.

1.2 Hrozby Kaţdé uchovávání dat s sebou nese nebezpečí jejich zničení či zneuţití. Důvody k takovému činu mohou být zamýšlené či nezamýšlené a je především na správci těchto dat, aby v maximální míře tyto rizika eliminoval. Důvodem k narušení bezpečnosti pak můţe být zvědavost, nedbalost, obohacení se nebo snaha poškodit organizaci. Mezi hlavní hrozby patří[7]: smazání dat nebo zničení celých systémů, účelová či neúčelová změna dat, zcizení a následné zneuţití dat. Typy útoků a útočníků se mohou různit podle typu uchovávaných dat v dané organizaci, jiní bývají útočníci v bankovním nebo finančním sektoru, ve státních úřadech či organizacích 9

(armáda, tajné sluţby), v ostatních průmyslových odvětvích (průmyslová špionáţ) či v neziskovém sektoru. Útočníci mohou být osamocení nebo organizovaní, můţe se jednat dokonce o státem podporované skupiny nebo můţe jít o osamoceného jedince, který je veden snahou poškodit danou organizaci nebo si jen dokázat vlastní schopnosti. Šíře a různorodost potenciálních útoků samozřejmě činí ochranu velice komplikovanou a nákladnou. Je tedy vţdy na zváţení, jaký stupeň zabezpečení nastavit. Jiné prostředky na ochranu dat bude mít armáda či stát, jiné finanční instituce a jiné malé firmy, případně neziskový sektor. Hrozby přicházejí ze dvou hlavních míst: zevnitř samotné organizace, z venkovního prostředí. 1.2.1

Hrozby zevnitř samotné organizace

Mezi potenciální útočníky v rámci organizace můţeme zařadit následující skupiny uţivatelů databází.[7] Administrátoři databází - jedná se o uţivatele s maximálními právy v databázích. Je v podstatě velmi těţké omezit jejich práva, neboť je potřebují k administraci. Pro jejich částečné omezení lze vyuţít produkty obsaţené v extra placené Oracle Advance Security Option. Jinak zbývá jen následná kontrola, především pomocí auditních záznamů, které musí být ale zároveň v reálném čase odsouvány z databázového serveru, aby se předešlo nebezpečí následné úpravy, a musí být vybudován proces kontroly těchto auditních záznamů. Aplikační uţivatelé - v dnešní době jde o preferovanou metodu přístupu do databáze vyuţívající třívrstevnou architekturu. Aplikační účet drţí sadu potřebných oprávnění, v ideálním případě pouze DML2. Heslo na aplikační účet by mělo být na aplikačním serveru bezpečně uloţeno (zašifrováno) a neměl by ho znát nikdo kromě správce daného aplikačního serveru. Koncoví uţivatelé - jedná se o uţivatele s přímým přístupem do databáze za pouţití klientského programu. Koncový uţivatel má být poučený a znalý SQL jazyka 2

DML – Data Manipulation Language, součást jazyka SQL

10

a případných kapacitních dopadů spuštěného příkazu. V dnešní době, kdy existuje tlak na vyuţívání třívrstvé aplikační architektury, by přístup koncových uţivatelů do databáze měl být pouze v reţimu read-only a prostřednictvím aplikačních rolí. Servisní účty - jedná se o účty určené pro zvláštní příleţitosti, například pro servisní zásahy dodavatele. Účet bývá standardně uzamčený, mívá stejná nebo vyšší práva neţ aplikační účet. Jeho pouţití by mělo být ošetřeno standardním postupem, který definuje podmínky pouţití, oprávněné uţivatele. Jeho otevření by mělo být zaprotokolované. Standardně na tomto typu účtů bývá nastavený plný audit. Vţdy by měla platit zásada přidělování minimálního počtu práv a přístup do databáze by měla získat pouze oprávněná osoba (musí být definován proces získání přístupu do databáze) a její činnost v databázi by měla být monitorovaná. Je také výhodnější nepřenechávat bezpečnost na aplikaci, ale vţdy ji řešit i na databázové úrovni. Zamezíme tak nebezpečí, ţe se bude útočník po prolomení aplikační ochrany maskovat za tuto aplikaci. Velký vliv na bezpečnost má také velikost organizace (rizika vyplývající z anonymity ve velké organizaci jsou větší neţ v malé firmě, kde se všichni vzájemně znají), ochrana fyzických serverů (útočník, který má fyzický přístup k serveru, se do něho dříve či později dokáţe prolomit), organizační struktura, jasně nastavené kompetence a také obecná úroveň informační gramotnosti uţivatelů. K zabezpečení databáze by se mělo přistupovat zodpovědně nebo dokonce s jistými prvky paranoidního očekávání. Loajální zaměstnanec nemusí zůstat loajálním navţdy, navíc můţe být k nezákonnému jednání donucen. 1.2.2

Hrozby z venkovního prostředí

Na rozdíl od útoku zevnitř firmy externí útočníci nemají přímý přístup do sítě společnosti a často ani neznají topologii a infrastrukturu napadené firmy. Pro průnik do interního systému se tedy snaţí nejprve shromaţďovat informace, vyhledávat slabá místa ochrany a bezpečnostní díry. Vlastní kapitolou je ochrana síťového prostředí firmy, zda je například umoţněno připojení neznámého zařízení do firemní domény, zdá existují seznamy povolených MAC adres, jak je zabezpečena WIFI síť či zda je pro přihlášení vyuţito certifikátů, HW tokenů či biometrických zařízení.

11

Z hlediska bezpečnosti, v případě systémů komunikujícím v prostředí internetu, je nezbytným minimem korektně nakonfigurovaný firewall, který jeho správce pravidelně monitoruje, objevené bezpečnostní chyby záplatuje a v pravidelných intervalech provádí penetrační testy. To samé platí samozřejmě pro aplikační servery a ostatní pouţité síťové prvky. V dnešní době nad databázemi často pracuje portálový aplikační server.

Z hlediska

bezpečnosti je rozumné, a v bankovním prostředí naprosto nezbytné, aby byl aplikační server fyzicky oddělen od databázového serveru. Kromě bezpečnostních důvodů to má i finanční důvod, v případě, ţe se platí databázová licence na procesor, je firma nucena platit i CPU spotřebované provozem aplikačního serveru, takţe se ji klidně můţe stát, ţe nakonec zaplatí dvakrát za stejný počet CPU. Pokud je to moţné, aplikační server by neměl s databázovým serverem komunikovat napřímo, ale například přes další vrstvu ( enterprise messaging systém). Z důvodu minimalizace rizik, pokud by se útočník dostal přes firewall i aplikační server, stále mu bude stát v cestě bariera před databázovým serverem. I zde platí, ţe celý systém je tak silný, jako jeho nejslabší prvek. 1.2.3

Bezpečnostní problémy

Pokud mluvíme o bezpečnostních problémech, máme zpravidla na mysli konfigurační chyby, chyby v aplikačních dodávkách dodavatelů a uţivatelské chyby.[7] Konfigurační chyby – systémy, a databáze nevyjímaje, jsou po prvotní instalaci často nastaveny na základní hodnoty. Systémové účty jsou otevřené, mají defaultní hesla, uţivatelé komunikují na přednastavených portech a nešifrovaně, nastavená politika hesel je benevolentní. Před uvedením databáze do produkčního provozu je tedy nutné provést hloubkovou kontrolu. Pokud je tato kontrola jasně definovaná (předpřipravený kontrolní skript, metodický předpis s posloupností kontrol), výrazně se tím sniţuje toto riziko. Administrátor dále musí během celého ţivotního cyklu sledovat produkt, v našem případě databázi, a v pravidelných intervalech instalovat bezpečnostní záplaty a upgradovat programové vybavení tak, aby měl stalé garantovanou plnou podporu výrobce.

12

Chyby v aplikačních dodávkách – aplikační systémy v dnešní době procházejí překotným vývojem, coţ s sebou nese zvýšené nároky na rychlost a kvalitu vyvíjeného programového kódu aplikací. Jedním z kroků vedoucích ke zrychlení a zefektivnění vývoje je pouţití aplikačních frameworků. Dalším bývá snaha pouţít co nejjednodušší a nejméně pracné řešení, které ale můţe být na úkor bezpečnosti. Bankovní ústav by měl vţdy vyţadovat aplikační dodávky splňující nezbytné bezpečnostní poţadavky a dodaný kód by měl projít standardním kolem testů v akceptačním prostředí a teprve po akceptaci gestorem posunut do produkčního prostředí. Uţivatelské chyby – uţívání aplikací, nejenom těch, které spolupracují s databázemi, by mělo být intuitivní a transparentní. Bohuţel, ne vţdy se tak děje a ne vţdy je to moţné. Aplikace by měly provádět základní kontrolu postupů, aby například nemohl pokladní uzavřít transakci, aniţ by zapsal kontaktní údaje nebo do políčka s číslem účtu nevloţil text. Některé typy uţivatelských chyb bohuţel nejde předem ošetřit a pak zbývá pouze následná kontrola. V oblasti bezpečnosti se nejčastěji setkáváme s problémy v problematice uţivatelských hesel, zamykání a expiraci účtů. 1.2.4

Vnější zabezpečení databáze

Všechny následně prezentované moţnosti zabezpečení Oracle databáze jsou neúčinné, pokud není dostatečně zabezpečen operační systém nebo není zajištěna fyzická ochrana hardware. Kromě vlastní databázové ochrany je tedy třeba věnovat pozornost i následujícím aspektům.[4] Zabezpečení operačního systému – databázový software by měl být nainstalován pod speciálním uţivatelem. Tento účet, běţně nazvaný oracle, má mít zakázaný remote login, přihlašování na server se děje pomocí jmenných účtů, je nastavena restriktivní politika na vlastnictví souborů. Práva na databázové soubory má pouze vlastník oracle. Je třeba zakázat i potenciálně snadno napadnutelné sluţby, jako jsou protokoly FTP a Telnet. Databázový server musí být umístěn v zabezpečeném prostoru, aby byl případnému útočníkovi znemoţněn fyzický přístup k serveru. Databázové zálohy je nutné skladovat pouze na zabezpečeném místě a přístup by k nim měli mít pouze oprávnění pracovníci.

13

Organizace musí mít nastavený proces na přidělování přístupu do databáze a kontrolovat oprávněnost vyuţívání. Organizace by také měla klást důraz na obecné vzdělávání zaměstnanců v otázkách bezpečnosti.

14

1.3 Základní termíny V úvodu práce je nutné vymezit základní pouţívané termíny. 1.3.1

Autentizace

Autentizace je proces, ve kterém se zjišťuje a ověřuje identita uţivatele. Je to také základní prvek ochrany databáze. Autentizací sledujeme tyto cíle.[14] Určení odpovědnosti – konkrétní uţivatelé jsou odpovědní za svou činnost v databázi. Důvěryhodnost dat – v prostředí, kde jsou uţivatelé odpovědní za své činy, roste důvěryhodnost a kvalita dat. Škálovatelnost přístupových oprávnění – jednotlivým uţivatelům je moţné nastavit různé úrovně databázových oprávnění. Dohledatelnost chování jednotlivých uţivatelů – databáze umoţňuje detailní zrekonstruování činnosti uţivatelů. Při databázové autentizaci je moţně vyuţít kombinaci jména a hesla, prostředků operačního systému, speciálního softwaru, adresářových sluţeb či certifikátu. 1.3.1.1 Databázová autentizace Databázová autentizace je nejčastějším případem je autentizace. Databázoví uţivatele se ověřují vůči běţící databázi, která má potřebné údaje uloţené v datovém slovníku (Oracle Data Dictionary). [15] Datový slovník obsahuje: jména databázových uţivatelů, oprávnění a role, definice všech databázových objektů ve všech schématech, informace o uloţení a alokaci jednotlivých objektů, specifikaci datových sloupců a typů, definice integritních omezení, auditní informace, ostatní informace potřebné pro běh databáze.

15

Tabulky datového slovníku jsou uloţeny v systémovém tabulkovém prostoru SYSTEM a jsou vlastněny uţivatelem SYS. Pro lepší přehlednost jsou nad tabulkami vytvořeny systémové pohledy pro snadnější administraci (DBA_TABLES, USER_TABLES…). Pro přístup k těmto informacím je vyţadováno systémové oprávnění SYSDBA. Nastavením inicializačního parametru 07_DICTIONARY_ACCESSIBILITY na hodnotu FALSE lze ochránit datový slovník před zásahy uţivatelů, kteří mají přidělená DDL3 oprávnění typu ANY (DROP ANY TABLE). 1.3.1.2 Autentizace administrátora databáze V některých specifických situacích, kdy databáze není ve stavu open , je moţné vyuţít ověření prostředky operačního systému nebo souboru hesel (password file). Administrátor se díky tomu připojí jako uţivatel SYS.[3] Jde především o následující situace. Start a stop databáze. Havárie z důvodu HW nebo SW chyby. Offline záloha databáze. Obnova databáze. Klon databáze na jiný server. V těchto případech je pro ověření administrátora připraven soubor hesel, který obsahuje seznam oprávněných uţivatelů a příslušné systémové oprávnění. SYSOPER – oprávnění umoţňuje spuštění a zastavení databáze, zálohování a obnovu databáze a připojení k databázi, která je ve stavu RESTRICTED SESSION. SYSDBA – oprávnění zahrnuje všechna oprávnění jako SYSOPER a navíc umoţňuje vytvářet a zrušit databázi a přidělovat ostatním uţivatelům tato dvě zmíněná oprávnění. SYSASM – oprávnění umoţňuje spravovat ASM4 instanci. Soubor hesel je uloţen v zabezpečeném adresáři na souborovém systému. Je moţné ho znovuvytvořit, tím ale ztratíme jeho obsah a musíme ho znovu naplnit oprávněními. Databázi lze za běţných podmínek spravovat bez souboru hesel. 3 4

DDL – Data Definition Language, součast jazyka SQL ASM - Automatic Storage Management

16

Druhou moţností je ověření prostředky operačního systému. Tato moţnost má přednost před ověřením za pomoci souboru s hesly. V případě, ţe je uţivatel ve stejné skupině jako vlastník databáze, po připojení do databáze vystupuje jako uţivatel SYS. Další moţnosti je nastavení inicializačního parametru OS_AUTHENT_PREFIX (obyčejně na hodnotu OPS$). Po přihlášení do operačního systému pak uţivatel nemusí zadávat heslo, a přesto se do databáze připojí. Podmínkou pro tuto funkčnost je vytvoření databázového uţivatele s klauzulí IDENTIFIED EXTERNALLY.

Obrázek č. 1: Diagram autentizačních metod

Zdroj: Mistrovství v Oracle Database 11g

1.3.1.3 Síťová autentizace V případě síťové autentizace je moţné vyuţít sluţeb třetích stran.[7] Protokol Secure Socket Layer (SSL) – protokol byl původně vyvinut pro pouţití ve WWW prohlíţečích, vyţaduje instalaci serverového certifikátu a úpravu konfigurace databázového listeneru. Distributed Computing Environment (DCE) – tento produkt podporuje distribuované aplikace v heterogenních prostředích a umoţňuje SSO5 autentizaci.

5

SSO – Single Sign-on – technologie jediného přihlášení

17

Kerberos – bezpečnostní produkt umoţňující SSO autentizaci. Public Key Infrastructure (PKI) - produkt pouţívá SSL protokol, k zajištění bezpečné autentizace se vyuţívají soukromé a veřejné klíče. Remote Authentication Dial-In User Service (RADIUS) – protokol určený pro autentizaci, autorizaci a účtování sluţeb. 1.3.2

Třívrstvá architektura

Další moţností, jak můţe uţivatel pracovat s databází, je vyuţití třívrstvé architektury, kdy se do databáze připojuje pouze aplikační server s právy aplikačního uţivatele za vyuţití www rozhraní. 1.3.3

Autentizace na straně klienta

Tento způsob autentizace je vyuţíván ve vícevrstevném prostředí, především v případě, ţe se uţivatelé nacházejí v zabezpečeném prostředí a kdyţ jednotliví uţivatelé nemají administrátorská práva na pracovní stanice. Toto řešení autentizace není v současné době doporučováno, neboť zabezpečení přenechává na slabém článku (pracovní stanici), která můţe být snadno překonána. 1.3.4

Oracle Identity Manager

Oracle Identity Manager (IM) je součástí Oracle Application Serveru a poskytuje sluţby pro centrální správu uţivatelských účtů pro všechna prostředí, produkty a www sluţby. Centralizace se příznivě promítá do bezpečnosti i nákladů na provoz IS. Informace o přístupovém oprávnění (autentizace i autorizace) jsou kromě IM redundantně uloţena i v databázi a jsou vzájemně synchronizována. Na rychlost a robustnost synchronizace jsou kladeny velké nároky. 1.3.5

Uţivatelské účty

Uţivatel se do databáze můţe připojit a přistupovat k databázovým objektům na základě uţivatelské účtu, který mu zřídí administrátor nebo pověřený pracovník. Ve větších společnostech bývá správa přístupových oprávnění zajištěna specializovaným produktem, například IBM Tivoli Identity Manager. Při vytváření uţivatelského účtu administrátor specifikuje následující parametry. Uţivatelské jméno – jedinečné jméno v rámci databáze.

18

Způsob autentizace a heslo – lze pouţít různé způsoby, nejběţnější je vyuţití databázového hesla. Default tablespace – nepovinný parametr, který určuje uloţení objektů uţivatele. Temporary tablespace – nepovinný parametr, který určuje uloţení dočasných objektů uţivatele. Quota – nepovinný parametr, určuje velikost prostoru - kvótu, kterou je uţivatel oprávněn alokovat v přiděleném tabulkovém prostoru (tablespace). Profile – nepovinny parametr, který určuje další charakteristiky uţivatele (například délku a komplexnost hesla).

CREATE USER user1 IDENTIFIED BY heslo DEFAULT TABLESPACE users QUOTA 10M ON users TEMPORARY TABLESPACE temp PROFILE SECURITY; Účet je moţné také při vytvoření uzamknout a omezit tak nebezpečí, ţe někdo zneuţije prvotní heslo. Uţivateli je pak účet odemčen bezprostředně před prvním přihlášením a vypršením hesla při vytvoření účtu je donucen si heslo ihned změnit. Pro prvotní přihlášení potřebuje uţivatel systémové oprávnění CREATE SESSION. Při vytvoření databáze vynikne v závislosti na nainstalovaných komponentách základní soubor systémových účtů, u kterých je nutné ihned změnit prvotní hesla a případně je uzamknout. Správce databáze ve své denní praxi vyuţívá především účty SYS, SYSTEM, DBSNMP či SYSMAN. Pro některé typy databázových účtů se pouţívá označení schéma. Míní se tím, ţe tyto účty vlastní rozsáhlé databázové objekty (tabulky, indexy, procedury, triggery a jiné). Databázové účty můţeme dělit podle způsoby pouţití. Systémové účty. Administrátor databáze. Aplikační schéma. Aplikační účty. Servisní účty.

19

Běţní uţivatelé. 1.3.6

Profily

Další moţností, jak zajistit poţadovanou bezpečnostní politiky hesel, jsou databázové profily. Standardní profile, který vznikne během vytvoření databáze, se jmenuje DEFAULT a pokud není specifikováno jinak, dostane ho kaţdý nově vytvořený uţivatel. V běţné praxi se pouţívá několik různých profilů v závislosti na typu účtu. Default profile zůstává pro nově zaloţené uţivatele (například klasickým change managementem), druhý pro běţné databázové uţivatele (často nejrestriktivnější nastavení), třetí pro databázové administrátory, čtvrtá pro aplikační účty a schémata (poţadavek na sloţité heslo, ale zároveň zákaz uzamčení hesla z důvodu vypršení platnosti či zadání špatného hesla), které sice znamená jisté sníţení ochrany, ale z hlediska stability provozu je neakceptovatelné, aby docházelo k haváriím z důvodu vypršení platnosti hesla nebo jen tím, ţe se někdo pokusí několika vědomými pokusy zadat špatné heslo pro aplikační účet a tím způsobí jeho uzamčení a následnou havárii. Posledním typem profilu bývá profil pouţívaný pro systémové účty. O konkrétním nastavení se vedou spory, protoţe jednotliví aktéři mají různé zájmy, které jdou často proti sobě. Je tady nutné najít optimální vyváţení z hlediska bezpečnosti, stability provozu a uţivatelské přívětivosti. FAILED_LOGIN_ATTEMPT = 10 PASSWORD_GRACE_TIME 7 (dny) PASSWORD_LIFE_TIME 180 (dny) PASSWORD_LOCK_TIME 1 (dny) PASSWORD_REUSE_MAX UNLIMITED PASSWORD_REUSE_TIME UNLIMITED

20

Obrázek č. 2: Příklad profilu

Zdroj:Vlastní úprava

V rámci profilu lze také uţivateli nastavit limity čerpání systémových zdrojů. SESSIONS_PER_USER – maximální počet relací (session) uţivatele. CPU_PER_SESSION – maximální čas CPU na relaci (ms). CPU_PER_CALL - maximální čas CPU na jedno volání. CONNECT_TIME - maximální doba připojení (min). IDLE_TIME – maximální doba nečinnosti (min). LOGICAL_READS_PER_SESSION - maximální počet přečtených bloků. LOGICAL_READS_PER_CALL - maximální počet přečtených bloků na call. COMPOSITE_LIMIT - celková cena čerpaných prostředků. PRIVATE_SGA – maximální velikost alokované paměti v SGA6. V praxi se nám nastavení parametrů upravující čerpání systémových prostředků neosvědčilo. Oracle 11g zavádí citlivost hesla na malá a velká písmena. V případě, ţe na tuto funkčnost nejsou připravené aplikace, lze vrátit původní funkčnost nastavením inicializačního parametru SEC_CASE_SENSITIVE_LOGON na hodnotu FALSE. 6

SGA – System Global Area, paměťová oblast oracle instance. Obsahuje shared pool, database buffer cache, a další buffery.

21

Komplexnost uţivatelských hesel v databázi zajišťuje funkce VERIFY_FUNCTION. Jedná se o program napsaný v PL/SQL a specifikovaný v rámci profilu. Modifikací funkce nastavujeme poţadované kontroly na komplexnost hesla. Standardní nastavení zabezpečuje tyto poţadavky. Heslo nesmí být stejné jako uţivatelské jméno. Heslo má minimálně sedm znaků. Heslo není stejné jako název serveru. Heslo není jedno z nejčastějších slov ( welcome, password, database, abcdefg). Bankovní bezpečnostní standardy vyţadují výrazně restriktivnější nastavení, poţadují délku deset a více znaků, musí obsahovat čísla a číslice, nesmí být sloţené z názvu účtu, nesmí existovat v základním slovníku. 1.3.7

Autorizace

Autorizace je po ověření uţivatele dalším stupněm ochrany databáze. Kontroluje se při ní oprávnění uţivatele přistupovat k databázovým objektům a prostředkům a specifikuje podmínky jejich pouţití. [14] Vyuţívá se při tom komplex systémových a objektových oprávnění, které mohou být přidělována přímo či prostřednictvím rolí. Oprávněním se míní právo přistupovat k databázovým objektům a pracovat s nimi. Oprávnění jsou přidělována DCL příkazy7 GRANT a odebírána REVOKE. Práva lze přiřadit uţivateli, roli či speciální roli PUBLIC, která zahrnuje všechny uţivatele databáze. Administrátor databáze v odůvodněných případech můţe převzít identitu cizího uţivatele. Po změně hesla je schopen se na tento účet připojit a po skončení práce (vyuţívá se při testování nebo hledání chyb) nastaví původní heslo (ALTER USER X IDENTIFIED BY VALUES 'F93D38A08E9EF8A4'). 1.3.8

Systémová oprávnění

Systémové oprávnění umoţňuje provádět akci nad kterýmkoli objektem v databázi, případně muţe jít o oprávnění změnit systémové parametry, vytváření uţivatelů nebo změny stavů databáze. 7

DCL – Data Control Language, součást jazyka SQL

22

Ve verzi 11g existuje 206 systémových oprávnění. Jejich seznam lze vypsat dotazem z tabulky SYSTÉM_PRIVILEGE_MAP.[5] Mezi nejčastější pouţívaná systémová oprávnění patří alter system, alter database, audit systém, create, alter a drop table, create, alter a drop any table, create, alter a drop index, create a alter session, create, alter a drop user, select any table, select any dictionary a další. Oprávnění je moţné uţivateli přidělovat s parametrem ADMIN OPTION, coţ mu umoţňuje toto konkrétní oprávnění předávat dalším uţivatelům. Seznam přidělených oprávnění je moţné nalézt v pohledech v datovém slovníku (DBA_SYS_PRIVS). 1.3.9

Objektová oprávnění

Na rozdíl od systémových oprávnění umoţňují objektová oprávnění akce pouze nad specifickými strukturami, například nad tabulkou, procedurou nebo sekvencí. Existuje celkem patnáct objektových práv, v přehledu uvádím pouze osm nejčastějších. SELECT – umoţňuje číst data z tabulky, pohledu a materializovaného pohledu, umoţňuje získat hodnotu ze sekvence. INSERT – umoţňuje vkládat data do tabulky, pohledu nebo materializovaného pohledu. UPDATE - umoţňuje měnit data v tabulce, pohledu nebo materializovaném pohledu. DELETE - umoţňuje mazat data z tabulky, pohledu nebo materializovaného pohledu. EXECUTE – umoţňuje spustit proceduru, funkci nebo proceduru z balíčku. REFERENCE – umoţňuje vytvořit pohled nebo cizí klíč. INDEX – umoţňuje vytvořit index. ALTER – umoţňuje změnit strukturu tabulky nebo definici sekvence. Mezi ty zbylé patří DEBUG, FLASHBACK, ON COMMIT REFRESH, QUERY REWRITE, READ, UNDER, WRITE. Uţivatel má automaticky přidělená objektová práva na své objekty a můţe tato oprávnění delegovat na ostatní uţivatele. Uţivateli není moţno odebrat práva na jeho objekty. Uţivatel, pokud k tomu má oprávnění, můţe pracovat s objekty ostatních uţivatelů specifikováním vlastníka objektu.

23

SELECT * FROM HR.EMP; Objektová práva na tabulky umoţňují přidělit práva pouze na specifické sloupce. Jednou z cest, jak zajistit uniformitu vykonávaných příkazů, je vyuţití procedur. Nepřidělujeme tedy uţivatelům práva přímo na objekty, ale pouze práva na spuštění procedur, v jejichţ rámci dojde k vykonání poţadované činnosti. Má to kromě bezpečnostních důvodů (uţivatelé přistupují k datům pouze předdefinovaným způsobem) i velký dopad na zatíţení databázového serveru, neboť SQL příkaz v proceduře je neměnný (místo hard-parse soft-parse) a měl by být dostatečně zoptimalizovaný, aby databázi zatěţoval co nejméně. Vlastník procedury musí mít objektové právo na dotazované objekty přiděleno přímo, ne přes roli. 1.3.10 Databázové role Hlavní důvod vyuţití databázových rolí je snaha o zjednodušení a zprůhlednění celého procesu přidělování práv. Místo přidělování stovek objektových a systémových práv novému uţivateli, administrátor uţivateli přidělí pouze roli podle jeho zařazení (analytik, programátor, pokladník).

Obrázek č. 3: Vyuţití databázových rolí

Zdroj: Oracle Database 11g DBA HANDBOOK

Oracle databáze obsahuje podle nainstalovaných komponent několik základních databázových rolí.[2] CONNECT – základní role umoţňující vytvoření relace. V 11g došlo ke zpřísnění a nyní obsahuje pouze systémové právo CREATE SESSION. RESOURCE – role vyuţívaná vývojáři.

24

DBA – role určená pro administrátory databáze. SELECT_CATALOG_ROLE – role pro dotazování v tabulkách datového slovníku. EXECUTE_CATALOG_ROLE – role pro spouštění systémových procedur. DELETE_CATALOG_ROLE – role umoţňující mazat bezpečnostní záznamy. EXP_FULL_DATABASE – role umoţňující vyexportovat celou databázi. IMP_FULL_DATABASE – role umoţňující provést plný import. Kromě jiţ zmíněných rolí se můţeme setkat i rolemi pro ovládání AQ8, HS9, SNMP10 a DBMS_SCHEDULER. Kromě jiţ zmíněných předdefinovaných rolí je moţné vytvářet aplikační role a podle poţadavků je plnit systémovými a objektovými právy a případné i dalšími rolemi. Role je defaultně vytvořena s parametrem NOT IDENTIFIED, ale je moţné pouţití role na dodatečnou autentizaci. Identified by password. Identified externally. Identified globaly. Identified using verification_function. Uţivatel se při pouţití této role znovu musí autentizovat (například zadat heslo pro konkrétní roli). Tato funkčnost je pouţívaná zřídka, především v případě, ţe je poţadovaná vysoká úroveň zabezpečení databáze. 1.3.11 Přiřazení práv Přiřazení práv a rolí jednotlivým uţivatelům se liší podle jejich pracovního zařazení a úrovně jejich znalostí. Databázový administrátor má z charakteru své práce nejvyšší oprávnění, běţně vyjádřené rolí DBA a přístupem na SYS uţivatele, případně SYSDBA rolí. V některých případech je část pravomocí databázového administrátora delegována na pracovníky útvaru přístupových oprávnění, kteří mají ve své náplni práce user management. 8

AQ – Oracle Advanced Queuing – replikační sw. HS – Oracle Heterogeneous Services 10 SNMP – Simple Network Management Protocol 9

25

Těmto pracovníkům je pak přiřazována silná systémová práva CREATE, ALTER a DROP USER. V dnešní době jsou asi nejběţnější aplikační účty. Potřebná DML11 práva jsou sdruţena v aplikačních rolích. Pro práci s daty se vyuţívají procedury a programové balíčky (packages) a umoţňují plnou kontrolu nad vykonávaným příkazem (optimální exekuční plán). S aplikačními účty souvisejí servisní účty dodavatele, které mají většinou stejná nebo vyšší práva neţ aplikační účty a umoţňují řešit incidenty a nestandardní poţadavky. Tyto účty bývají uzamčené a jsou povolovány pouze na základě oficiální ţádosti. Dalším typem účtů jsou běţní uţivatele. Pro tento typ účtu je charakteristické seskupování práv do aplikačních rolí, které umoţňují přesně specifikovanou činnost nad logickými celky dat. V současné době je tento typ účtů a přístupu na ústupu, trendem doby je vyuţití třívrstvé architektury, kdy uţivatel přistupuje do databáze prostřednictvím aplikačních účtu a pro vlastní přístup nepouţívá desktopové oracle klienty (tlustý klient), ale WWW prohlíţeč. Jsou pro to architektonické, bezpečnostní a finanční důvody. Pro účty s analytickým zaměřením je typický pouze read only přístup bez moţnosti manipulovat s daty.

1.4 Další bezpečnostní prvky 1.4.1

Audit

Oracle databáze obsahuje vestavěné auditní mechanismy pro sledování přístupu uţivatelů k databázovým objektům. Neumí sice zabránit neoprávněnému uţití oprávnění, ale dokáţe zpětně poskytnout potřebné údaje o činnosti uţivatele. Je několik důvodů, proč sledovat činnost uţivatelů v databázi.[15] Přiřazení odpovědnosti za činnost v databázi konkrétnému uţivateli. Odhalení bezpečnostních incidentů (kdo smazal data, kdo vytvořil uţivatele s DBA právy). Nastavení procesu odhalování incidentů (vyţaduje následný proces vyhodnocování auditních záznamu, automatické notifikace, atd.). Monitoring databázových objektů z výkonnostních důvodů. 11

DML – Data Manipulation Language, součást jazyka SQL.

26

Legislativní poţadavky. Oracle databáze umoţňuje několik způsobů, jak sledovat uţivatele. Audit příkazů – záznam SQL příkazů jednotlivého uţivatele nebo skupiny uţivatelů. AUDIT SELECT TABLE BY ACCESS WHENEVER NOT SUCCESSFULL Audit oprávnění – audit systémových oprávnění (create table) vyuţitých konkrétním uţivatelem nebo skupinou uţivatelů. AUDIT DELETE ANY TABLE BY ACCESS Audit objektů – sledování SQL příkazů nad konkrétním objektem. AUDIT SELECT TABLE, UPDATE TABLE BY USER1 BY ACCESS Rozšířený audit – sledování přístupu k tabulkám a oprávněním na základě datového obsahu objektů (FGA12). Jedná se podrobnější sledování pouze určitých řádků či sloupců tabulky, za vyuţití DBMS_FGA procedur. Auditovat lze v případě úspěšně provedeného příkazu, či v případě neúspěšného pokusu, nebo v obou případech. Auditovat lze při kaţdém výskytu události (BY ACCESS), nebo pouze při prvním výskytu (BY SESSION). Druha varianta je výchozí. Uţivatele přihlášené jako SYSDBA či SYSOPER je po nastavení databázového parametru AUDIT_SYS_OPERATION moţné auditovat do operačního systému. Ukládání auditních záznamů se řídí databázovým parametrem AUDIT_TRAIL a umoţňuje následující nastavení. DB – auditní záznamy se ukládají do databáze, konkrétně do tabulky SYS.AUD$. DB, EXTENDED – stejně jako předchozí volba, navíc se ukládají pouţité SQL příkazy včetně vázaných proměnných. OS – auditní záznamy se ukládají do filesystému operačního systému. XML – auditní záznamy se ve formě XML záznamů ukládají do filesystému operačního systému. XML, EXTENDED – auditní záznamy včetně SQL příkazů se ve formě XML záznamů ukládají do filesystému operačního systému.

12

FGA – Fine-grane object auditing

27

V případě ukládání auditních záznamů do databáze jsou pro pohodlné vyhledávání připravené databázové pohledy (DBA_AUDIT_TRAIL a jiné). Ukládání auditních informací do databáze je komfortnější a umoţňuje snadné prohledávání SQL příkazy. Nicméně z hlediska zabezpečení auditních dat je ukládání do filesystému povaţováno za bezpečnější a snadněji udrţovatelné. Auditní záznamy jsou pak samozřejmě přístupné i v případě databázové odstávky (třeba i následkem akce útočníka). Další moţností je nastavení inicializačního parametru AUDIT_SYSLOG_LEVEL na platformě UNIX, kterým zajistíme posílání auditních záznamů přímo do auditních logů operačního systému za pouţití utility SYSLOG a odstíníme tak databázového správce, v případě ţe nemá systémová root privilegia, od vlastních záznamů. Je velmi důleţité nastavit odpovídající úroveň auditu, neboť ţádné či slabé nastavení nebude schopno následně poskytnout relevantní údaje a identifikovat problémy a naopak silné nastavení můţe negativně ovlivňovat výkon a dostupnost databáze. Případné vytečení systémové tabulky, kde jsou auditní záznamy ukládány, můţe vést k nemoţnosti přihlášení uţivatelů a tím pádem i výpadku sluţeb. Auditní data tedy musejí být udrţována a po určité době odmazávaná. Databáze v bankovním prostředí mají obvykle nastaven auditing na zaznamenávání DDL operací a neúspěšných přihlášení, dále se auditují některé speciální typy databázových účtů (povolované silné servisní účty). Toto neplatí pro databáze s citlivými daty, jako jsou čísla platebních karet. Tyto databáze auditují velké mnoţství operací, včetně DML příkazů. Aby měl auditing smysl, získané údaje musí někdo vyhodnocovat. Je bohuţel smutnou pravdou, ţe i v bankovním prostředí se toto často neděje a databáze se auditují pouze z důvodu, ţe to poţadováno v auditním nálezu externí auditorské firmy. Navíc údrţbu a auditní nastavení mají většinou na starosti databázoví administrátoři, přestoţe právě proti nim je často auditing zaměřen a měl by umoţňovat jejich zpětnou kontrolu. Na trhu existují komplexní auditní řešení, která umoţňují údrţbu a online čtení či přesouvání auditních záznamů mimo databázi a mimo dosah databázových uţivatelů. Tyto systémy mají vlastní datové úloţiště, umoţňují tvorbu sestav a automatické zasílání výstrah v případě incidentů. V této práci se zmíním o Oracle Audit Vault, ale existují i jiné moţnosti, například od firmy Palladium.

28

1.4.2

Fine Grained Auditing

Fine Grained Auditing (FGA) rozšiřuje moţnosti auditu v Oracle databázi. Na rozdíl od klasického auditu, který umoţňuje sledovat, k jakým objektům kdo přistupuje (jistou výjimku představují hodnoty parametru audit_trail DB nebo XML s rozšířením EXTENDED, kdy je také zobrazován vykonávaný SQL příkaz).

FGA nabízí detailní auditování rozšířením

o podmínky where nebo specifikací sloupců. Pro nastavení se vyuţívá funkčnost procedur y balíku DBMS_FGA. Záznamy z FGA jsou dostupné v pohledu DBA_FGA_AUDIT_TRAIL. Data získaná z FGA auditu bývají podkladem pro stanovení detailních zásad autorizace uţivatelů. 1.4.3

LogMiner

Utilita LogMiner slouţí k procházení online a archivních redologů, které zaznamenávají transakční aktivitu i ostatní změny (DDL, DML) Oracle databáze, a umoţňuje zrekonstruovat běh databáze ve formě SQL příkazů (zároveň generuje UNDO SQL příkazy). Lze ho pouţít k analýze chyb, které vedly k porušení aplikační transakční integrity, analýze chybového chování aplikací či uţivatelů, k trendovým analýzám a kapacitnímu plánování. Zároveň je moţné pouţít LogMiner pro sledování chování uţivatele (zjištění, kdo a kdy smazal inkriminované záznamy apod.) a umoţňuje získat návratové SQL. Pro vlastní práci jsou vyuţívány procedury z balíku DBMS_LOGMNR, zjištěné výsledky lze selektovat ze systémového pohledu V$LOGMNR_CONTENTS. LogMiner nepodporuje některé specifické datové typy a objekty. 1.4.4

ADR Command Interpreter

Utilita ADR Command Interpreter slouţí od verze 11 ke komfortnější práci administrátora. Umoţňuje rychle zjišťovat databázové problémy, zobrazovat varování, procházet alert logy a trace soubory. Přestoţe s příchodem verze oracle 11g jsou některé chybové a diagnostické soubory v XML formátu, zůstala zachována i ASCII verze zmíněných souborů. 1.4.5

Triggery

Triggery neboli spouštěče, jsou další moţností řízení uţivatelského přístupu do databáze nebo k datům, případně k auditování specifických činnosti uţivatele. Triggery (systémové, aplikační) je moţné dělit podle okamţiku, kdy jsou aktivovány, na after nebo before triggery.

29

After logon triggery jsou často pouţívány k monitorování či řízení přihlašování uţivatelů do databáze, kdy lze sledovat (či dokonce vyţadovat) například korektní pouţití aplikačních účtů. 1.4.6

Pohledy

Jednou z moţností, jak řídit přístup k datům, je pouţití databázového pohledu (view). Pohled je ve své podstatě virtuální tabulka, umoţňující přístup k datům fyzické tabulky nebo její části, či dokonce mnoţiny tabulek.[6] Vlastník pohledu definuje jeho parametry a jedním z kriterií můţe být i bezpečnostní hledisko. Pohled lze vyuţít k zobrazení jen určitých sloupců (column-level security) nebo jen určitých dat (value-based security). Přidělením objektových práv na pohledu je moţné dále řídit přístup k těmto datům. 1.4.7

Access Control List

Oracle databáze umoţňuje volat některé systémové balíky, které zabezpečují různé způsoby komunikace vně databáze. Jsou to například[4]: UTL_SMTP – pouţívá se k zasílání zpráv mezi servery, UTL_HTTP – pouţívá se ke komunikaci s www serverem, UTL_TCP – umoţňuje komunikaci mezi dvěma servery bez pouţití db linků, UTL_MAIL – umoţňuje emailovou komunikaci, UTL_INADDR – podporuje internetové adresování (API pro získání host name a IP adresy). Ve starších verzích byla oprávnění execute přidělena uţivateli PUBLIC a mohli ho tedy vyuţít všichni uţivatele. Tento stav znamenal jisté bezpečnostní riziko a odstranění tohoto oprávnění bývalo v poţadavcích auditorů. Od verze 11g je tento problém řešen pomocí mechanismu Access Control List, kdy jsou oprávnění defaultně přidělovaná konkrétním uţivatelům. K nastavení jsou pouţívány procedury CREATE_ACL, ADD_PRIVILEGE a ASSIGN_ACL z balíku DBMS_NETWORK_ACL_ADMIN.

30

1.4.8

Šifrování dat

Šifrování dat můţe výraznou měrou přispět k bezpečnosti ukládaných dat. Oracle databáze poskytuje hned několik metod šifrování dat. Poţadavek na šifrování citlivých údajů lze nalézt v několika zákonných úpravách a průmyslových standardech (např. PCI DSS). Pro šifrování je moţné pouţít od verze 10g

procedury balíku DBMS_CRYPTO

(v předchozích verzích DBMS_OBFUSCATION_TOOLKIT) nebo transparentní šifrování dat (TDE) z volitelné komponenty OASO13. DBMS_CRYPTO vyuţívá algoritmus AES14, umoţňuje vygenerovat privátní klíče a pracovat s vlastními klíčem, oproti minulosti došlo k rozšíření počtu podporovaných datových typů. Je moţně šifrovat jednotlivé sloupce s citlivými údaji v tabulkách nebo v případě existence OASO i celé tabulkové prostory (tablespace). Kromě zřetelných přínosů přináší šifrování i některá negativa a omezení, především sloţitější správu databáze a souvisejících aplikací. V případě šifrování sloupců můţeme narazit na problém v indexování šifrovaného sloupce (nemoţnost pouţití index range scan). Dalším problémem můţe být zvýšení HW nároku na server v závislosti na typu pouţitého šifrovacího klíče. 1.4.9

Oracle Wallet

Oracle Wallet neboli peněţenka slouţí jako heslem chráněné úloţiště pro privátní klíče a certifikáty. Wallet je moţné pouţít i pro TDE. Konfigurace probíhá v následujícím pořadí: vytvoření

adresářové

struktury

walletu

a

sqlnet.ora

definice

parametru

ENCRYPTION_WALLET_LOCATION, vytvoření walletu s šifrovacím klíčem (mater key), otevření walletu, zašifrování dat. Aktuální

stav

otevření

walletu

je

moţné

sledovat

v systémovém

pohledu

DBA_ENCRYPTED_COLUMNS. Peněţenka a klíč musí být pečlivě zálohován, v případě ztráty jiţ nebude moţné zašifrovaná data přečíst. 13 14

OASO – Oracle Advanced Security Option AES – šifrovací algoritmus Advanced Encryption Standard

31

1.4.10 Virtuální privátní databáze Virtuální privátní databáze (VPD), která byla představena jiţ ve verzi 8, rozšiřuje moţnosti řízení přístupů k databázovým objektům bez ohledu na přístup k datům. Jde o zabezpečení na úrovni řádek a sloupců (row-level security). V principu jde o dynamické přidávání omezující podmínky k SQL příkazům.[2] V prvním kroku je nutné definovat funkci s konkrétní podmínkou (například nezobrazení určitého řádku) a poté pomocí procedur z balíku DBMS_LRS definovat pravidla (specifikace objektu a omezující funkce). Toto nastavení způsobí, ţe uţivatel, který má práva na tabulku, dostane v případě selektu bez omezujících podmínek z tabulky pouze data, která nejsou v konfliktu s nadefinovanými pravidly. Spolu s VPD je moţné vyuţít funkčnosti aplikačního nebo systémového kontextu. Uţivateli jsou například zobrazena pouze data odpovídající hodnotě, kterou vrátí funkce SYS_CONTEXT (např. záznamy o jeho osobě). Na uţivatele se SYSDBA právy se omezení VPD nevztahuje. 1.4.11 Oracle Label Security Další moţností, jak řídit přístup k datům na úrovni řádků (row-level security), je Oracle Label Security (OLS). Pro řízení přístupu a klasifikaci dat se vyuţívají jiţ předpřipravené mechanismy (security labels) nastavování a kontroly přístupu k objektům, čímţ se také liší od VPD, kde je nutné omezující funkce naprogramovat. Pouţití OLS je také vhodné v situaci, kdy data nejsou sdruţena do vyšších logických celků, ale vykazují vysoký stupeň granularity (například řešení postavená na frameworku). Při konfiguraci OLS nastavujeme politiky přístupu a jednotlivé labely neboli štítky[16]. Data label – specifikuje stupeň důvěrnosti dat (např. důvěrná, citlivá, veřejná). User label – nastavuje úroveň oprávnění uţivatele při přístupu k datům chráněným OLS. Chráněné objekty – při nastavení OLS pro konkrétní tabulku je do ní přidán skrytý sloupec, který obsahuje informace pro řízení přístupu k datům dané tabulky.

32

Obrázek č. 4: Oracle Label Security

Zdroj: Oracle® White Papers – Oracle Label Security

1.4.12 Oracle Database Vault V Oracle databázi má administrátor s oprávněním SYSDBA v podstatě neomezená práva. Jednou z moţností, jak tyto privilegia omezit, je funkcionalita Oracle Database Vault. Umoţňuje nastavit detailní kontrolu přístupu k citlivým datům, kterou nedokáţe obejít ani administrátor databáze. Database Vault se pouţívá z následujících důvodů.[5] Zabraňuje privilegovaným uţivatelům a administrátorům k přístupu k datům, na které ze své funkce nemají právo. Odděluje správu databáze od správy bezpečnostní problematiky. Umoţňuje detailní moţnosti nastavení přístupu k datům. Funkcionalita Database Vaultu je postavena na třech pilířích. Realms – skupiny nebo oblasti (ochranné zóny), do kterých jsou zařazeny do chráněné objekty. Mohou obsahovat schémata, tabulky, role. Command Rules – kolekce pravidel, kterými jsou kontrolovány SQL příkazy, pracují s různými omezujícími faktory (čas, IP adresa, aplikačně definované atributy, …), k práci s nimi se pouţívá Database Vault Administration nebo procedury balíčku DVSYS.DBMS_MACADM. Vícefaktorová autentizace – sady pravidel, která při autentizaci berou v potaz více faktorů a omezení na základě předpisů a norem.

33

Funkcionalita Database Vaultu na všech úrovních systematicky separuje práva a odpovědnosti administrátora databáze od aplikačního obsahu databáze a rozděluje odpovědnost mezi následující týmy. Správa uţivatelských účtů. Správa bezpečnosti – zavádí pozici bezpečnostního administrátora, který spravuje realmy, command rules a faktory. Správa databáze – databázový administrátor se stará pouze o technický chod databáze, zabezpečuje zálohy a obnovy databáze, ladění výkonu, na chráněná aplikační data ale nemá přístup. 1.4.13 Oracle Audit Vault Oracle Audit Vault (AV) je bezpečnostní produkt umoţňující automatický sběr auditních dat do zabezpečeného úloţiště na Audit Vault serveru s grafickým rozhraním a s vyuţitím přístupu přes webovou konzoli. Umoţňuje odstínění databázového administrátora od problematiky sběru a údrţby auditních dat a plní tím jeden z obvyklých poţadavků bezpečnostních norem. Fyzicky se AV skládá z těchto komponent. Audit Vault Server – aplikační server, který je umístěn spolu s upravenou databází na specializovaném serveru mimo monitorované databáze. Audit Vault Collection Agent – agent běţící na monitorované databází, který zajišťuje sběr, přenos (SQL*Net) a údrţbu auditních záznamů. Mezi hlavní funkce AV patří: automatizovaný sběr auditních dat a následný monitoring a reporting, detekce bezpečnostních problémů a následná notifikace, údrţba a čištění auditních záznamů cílových systémů, konsolidace auditních záznamů z mnoha systémů, podpora různých databázových verzí a rozličných platforem (Oracle, MS SQL Server, IBM DB2, Sybase).

34

Obrázek č. 5: Oracle Audit Vault

Zdroj: Oracle® White Papers – Oracle Audit Vault

Přestoţe Database Vault chrání citlivá aplikační data, správce databáze má moţnost DV vypnout (v UNIX systémech relinkem programového vybavení a vypnutím pomocí DVCA15), například při instalaci softwaru třetích stran, během upgradů a podobně. S Database Vault se pojí i další prvky bezpečnosti databáze z OASO (TDE) a administrativní opatření( omezení pouţití SYSDBA účtů) a pokročilé auditní funkcionality.

1.5 Oracle Advanced Security Option V případě poţadavku na silně zabezpečenou databázi je moţné vyuţít volitelnou, zvlášť placenou komponentu Oracle Advanced Security Option (OASO). Zabezpečuje poţadovanou důvěrnost a integritu dat, umoţňuje šifrovat veškerá aplikační data (PAN, čísla platebních karet) na úrovni tabulky nebo tabulkového prostoru, šifruje komunikaci vně databáze a umoţňuje i online transparentní šifrování záloh. Umoţňuje single sign-on a další moţnosti autentizace. Tyto poţadavky mohou vycházet z potřeby splnit podmínky vyţadované různými zákonnými úpravami, jako například Sarbanes-Oxley ACT, Payment Card Industry (PCI) Data Security Standard (DSS), Health Insurance Portability and Accountability Act (HIPAA). OASO ve verzi 11gR2 vyţaduje existenci Oracle Net 11gR2 a je dostupná pouze v Enterprise edici. Na některých platformách (MS Windows) není garantovaná plná funkčnost všech komponent. OASO nabízí tři hlavní funkčnosti. Transparentní šifrování dat (Transparent Data Encryption). 15

DVCA – Oracle Database Vault Configuration Assistant

35

Šifrování síťové komunikace (Network Encryption). Silnou autentizaci (Strong Autentication). 1.5.1

Transparentní šifrování dat

Oracle Transparent Data Encryption (TDE) je moţné pouţít k šifrování jednotlivých sloupců nebo celého tabulkového prostoru. Častěji se vyuţívá šifrování tabulkového prostoru. Oracle uvádí výkonnostní dopad šifrování 5-10% u běţných OLTP databází. Objekty je moţné nově vytvořit nebo stávající data přesunout pomocí CREATE TABLE AS SELECT, ALTER TABLE MOVE, nebo pomocí Oracle Data Pump. Obrázek č. 6: Schéma Oracle TDE

Zdroj: Oracle® Database Advanced Security Administrator's Guide

Šifrovací klíč je moţné uloţit buď v Oracle Wallet nebo v externím hardwarovém bezpečnostním modulu (HSM), například produkty RSA, Safenet, Thales, Utimaco. V případě ztráty šifrovacího klíče dojde k nevratné ztrátě dat, je tedy nutné klíč pečlivě zálohovat. 1.5.2

Šifrování síťové komunikace

Citlivé data uloţené v databázi nebo data, která jsou přenášena nechráněnou sítí, je nutné šifrovat. Takto chráněná data není schopen útočník bez klíče rozšifrovat. Data můţeme šifrovat jak v případě spojení klient vs. databáze, tak samozřejmě i v případě spojení aplikační server vs. databáze[16]. 36

Obrázek č. 7: Šifrování komunikace

Zdroj: Oracle® Database Advanced Security Administrator's Guide (11.2)

1.5.2.1 Podporované šifrovací algoritmy Výběr vhodného šifrovacího algoritmu závisí na poţadované úrovni zabezpečení (síla klíče) s ohledem na charakter zdrojových dat a na výkonnostních charakteristikách databázového systému. V minulosti americká vláda omezovala pouţití nejsilnějších algoritmů pouze na území USA. Oracle Advanced Security Option vyuţívá pro zajištění důvěrnosti přenášených dat následující šifrovací algoritmy[16]. 1.5.2.1.1 RC4 RC4 šifrovací modul pouţívá RSA šifrovací modul. Pomocí tajného, náhodně generovaného klíče jedinečného pro kaţdé připojení je šifrován celý síťový provoz včetně SQL příkazů, vloţených procedur, hodnot a vrácených výsledků. Šifrovací modul je pro pouţití v Oracle databázi optimalizován a poskytuje vysokou úroveň bezpečnosti při minimálních hardwarových nárocích. Vyuţívají se šifrovací klíče o délce 40, 56, 128 a 256bitů. 1.5.2.1.2 AES AES (Advanced Encryption Standard) je šifrovací algoritmus, vyvinutý jako náhrada původního DES. AES je symetrická bloková šifra, která můţe zpracovávat bloky o velikosti 128 bitů, pomocí šifrovacích klíčů o délce 128, 192 a 256 bitů, které jsou označovány jako AES-128, AES-192 a AES-256.

37

1.5.2.1.3 DES Oracle Advanced Security implementuje DES (Data Encryption Standard) standardně s optimalizovaným 56bitovým šifrovacím algoritmem a kvůli zpětné kompatibilitě i DES40, coţ je 40bitový klíč. 1.5.2.1.4 3DES Oracle Advanced Security také podporuje 3DES šifrování (Triple-DES), které šifruje data třemi průchody DES šifry. 3DES poskytuje vyšší úroveň bezpečnosti, bohuţel uţ za cenu vyšších hardwarových nároků a vlastní šifrování trvá trojnásobek doby v porovnání se standardní DES. Dodává se 112 a 168bitovou délkou klíče. 1.5.2.2 Datová integrita Oracle Advanced Security Option umoţňuje vyuţít pro zajištění integrity dat při přenosu generování hashovací MD5 nebo SHA-1 funkcí16, tento hash přikládá ke kaţdé přenášené zprávě. Generování hashe neboli otisku představuje pouze malé hardwarové nároky a zajišťuje data před těmito nebezpečími. Modifikace dat. Smazání paketů. Replay útoky17. 1.5.3

Silná autentizace

Autentizace slouţí k ověření identity uţivatele. Kromě standardního ověření pomocí hesla, byť silného, nabízí OASO další moţnosti centralizované autentizace pomocí single sign-on (SSO) funkcionality. Uţivatelé po prvotním přihlášení mohou přistupovat na další systémy, aniţ by znovu museli zadávat jméno a heslo, coţ jednak přispívá k jejich uţivatelskému komfortu a zároveň to zvyšuje obecnou bezpečnost.[16] OASO podporuje následující moţnosti silné autentizace při vyuţití produktů třetích stran. Kerberos.

16

MD5 a SHA-1 – jsou kryptografické hashovací algoritmy, prokazující integritu dat (otisk zprávy).SHA-1 je pomalejší, ale pokytuje vyšší úroveň zabezpečení neţ MD5. 17 Replay útok - útok na volně přenášená, nezašifrovaná data po síti.

38

RADIUS18 - kromě jiného umoţňuje k vyuţití autentizace HW zařízení (Smart karty, tokeny). SSL19 - protokol lze vyuţít pro autentizaci, šifrování a zajištění datové integrity, vyuţívá se například v Oracle Wallet. Entrust/PKI. 1.5.4

Oracle Database Firewall

Oracle Database Firewall (ODF) je vyuţíván jako první stupeň ochrany databáze před vnějším útokem a v reálném čase monitoruje SQL příkazy jdoucí vůči databázi. Dokáţe analyzovat strukturu SQL příkazu, odhalovat odchylky (SQL injektáţ) v kódu a vyhodnocovat soulad daného SQL s nastavenou bezpečnostní politikou. Řídí se při tom souborem pravidel, které jsou definovány v následujících politikách. White list – soubor povolených SQL příkazů. Black list – soubor definovaných objektů a SQL příkazů, které jsou zakázané. Výjimky – soubor výjimek z předchozích skupin na základě definovaných atributů (SQL příkaz, čas, uţivatel, aplikace, IP adresa). ODF umoţňuje volitelnou úroveň ochrany, kromě analýzy a blokování škodlivého SQL kódu dokáţe nahrazovat podezřelý kód povolenou syntaxí (která například vrátí „no records found“), dokáţe logovat veškerou aktivitu, vyvolávat varovné zprávy nebo generovat reporty. Kromě Oracle databází dokáţe ODF pracovat s celou řadou ostatních databázových produktů (MySQL, Microsoft SQL Server, IBM DB2, Sybase). Funkcionalita ODF je v souladu s legislativou definující bezpečnostní poţadavky (SOX, PCI DSS a jiné). 1.5.5

Oracle Data Masking

Společnosti často řeší otázku, jak efektivně a zároveň bezpečně testovat nové produkty a

změny

funkčností

programového

vybavení.

Vytvoření

dostatečného

velkého

a reprezentativního vzorku dat většinou z mnoha důvodů nepřichází v úvahu a při pouţití kopie produkčních dat hrozí velké riziko jejich zneuţití. 18 19

RADIUS – Remote Authentication Dial-Ín User Service SSL – Secure Socket Layer

39

Tento problém řeší programový balík Oracle Data Masking (ODM), který dokáţe nevratně zamaskovat produkční data, aby je bylo moţné bez nebezpečí zneuţití pouţít pro testy a zároveň aby data neztratila smysl. Nabízí maskování do podoby čísel kreditních karet, telefonních čísel a dalších běţných identifikátorů. Maskování dat lze provádět na základě navolených podmínek a při zachování logických souvislostí, aby nedošlo k porušení aplikační logiky. Maskovací algoritmus je moţné vygenerovat do PL/SQL kódu, umoţňuje provádět v něm provádět změny a případně ho zapracovat do automatizovaných klonovacích postupů. Kromě Oracle databáze je moţně techniky ODM pouţít i pro IBM DB2 a Microsoft SQL Server. Funkcionalita ODM je v souladu s legislativou definující bezpečnostní poţadavky (SOX, PCI DSS a jiné).

40

2 Bezpečnostní normy Při ochraně dat Oracle databáze můţeme vycházet z existujících bezpečnostních norem, které vydávají organizace zabývající se standardizací produktů a sluţeb v oblasti finančnictví a bankovnictví. V některých konkrétních případech je vyţadovaná certifikace úrovně dosaţené bezpečnosti, která je potřebná pro provozování vybraných sluţeb (například karetní platby).

1.6 PCI DSS Payment Card Industry Data Security Standard (PCI DSS) je soubor bezpečnostních standardů, jejichţ aplikace pomáhá zabezpečit citlivá data o drţitelích platebních karet. Ve své podstatě se jedná o dvanáct hlavních poţadavků, které musejí organizace zpracovávající a uchovávající tyto citlivá data splnit. Tyto hlavní poţadavky se pak dále rozpadají do dílčích bodů[17]. Popis seznamu poţadavků jsem umístnil do příloh.

Obrázek č. 8: Seznam poţadavků PCI DSS 2.0

Zdroj: PCI DSS Requirements and Security, Version 2.0

Mezi citlivá data patří údaje uvedené na platební kartě, ať jiţ vytištěné nebo uvedené na magnetickém prouţku, nebo zadané majitelem karty:

41

PAN20 – číslo karty, PIN, datum vypršení platnosti karty, CAV2/CID/CVC2/CVV2 – třímístný údaj v podpisovém poli, informace uloţené v magnetickém prouţku. Bezpečnostní prvky standardu PCIU DSS platí pro všechny dotčené systémové komponenty. Mezi ně se počítají součásti síťové infrastruktury, serverů, databází či aplikací spojené se systémy, které drţí data o platebních kartách a provedených transakcích. Aktuální verze PCI DSS je verze 2.0 a je platná od října 2010. Výsledky testování (ověření shody s pravidly PCI DSS) ukládá hodnotitel ve formě tabulky s patřičným komentářem. Obrázek č. 9: Ověřovací tabulka

Zdroj: PCI DSS Requirements and Security Assessment Procedures, Version 2.0

Na základě tohoto ověřování se v případě nesplnění provádějí nápravná opatření. Tyto poţadavky pak poskytovatel sluţby (banka, obchodník) musí splnit, v případě jasně definovaných výjimek, které nejdou proti smyslu PCI DSS, se uplatňují Pracovní tabulky náhradní kontroly (Compensating Controls Worksheet).

20

PAN – Primary Account Number

42

V případě splnění poţadavků vydá kvalifikovaný hodnotitel bezpečnosti (QSA21) potvrzení Osvědčení o shodě poskytovatele sluţby se standardem bezpečnosti dat odvětví platebních karet (PCI DSS).

1.7 ITIL ITIL®22 je ucelený soubor publikací, které popisují „best-practises“ metodiky a postupy ve správě sluţeb IT. Poskytuje rámec pro zvládnutí IT v organizaci, komplexně popisuje sluţby a zaměřuje se na neustálé měření a zlepšování kvality dodávaných sluţeb IT z pohledu managementu i z pohledu zákazníka. Nejnovější řada ITIL V3 byla představena v roce 2007 a skládá se z oficiálního úvodu, pěti klíčových knih a dalších doplňkových materiálů. Na rozdíl od předchozí verze se nyní zaměřuje především na pokrytí celého ţivotního cyklu sluţby. Poslední aktualizace proběhla v roce 2011.[12] Mezi hlavní přínosy metodiky ITIL se řadí: zvýšená spokojenost uţivatelů a zákazníků se sluţbami IT, zlepšená dostupnost sluţeb, coţ vede ke zvýšeným ziskům a obratu společnosti, finanční úspory plynoucí z redukce duplicitních činností, ztraceného času, zlepšené správy a vyuţití zdrojů, redukce doby potřebné pro uvedení nových produktů a sluţeb na trh, zlepšení podkladů pro rozhodování managementu a optimalizace rizik. Pět klíčových knih pokrývá všechny fáze ţivotního cyklu sluţeb[13]. Strategie sluţeb (Service Strategy) - plánuje strategie businessu včetně sběru poţadavků, budování portfolia sluţeb a finančních rozvah a z ní vyplývající strategie sluţeb IT. Snaţí se o sladění businessu a IT útvaru, aby si vzájemně přinášely nejvyšší hodnotu, a zajišťují, aby v kaţdém okamţiku ţivotního cyklu sluţeb byla zachována orientace na business a jeho cíle. Návrh sluţeb (Service Design) - definuje vlastní návrh sluţeb, podpůrných procesů, infrastruktury, měření, metrik a podpůrných systémů. Kromě nových sluţeb optimalizuje i stávající s cílem zachovat či zvýšit přidanou hodnotu pro zákazníky v průběhu ţivotního cyklu sluţby. 21 22

SQA – Qualified Security Assessor ITIL - Information Technology Infrastructure Library

43

Přechod sluţeb (Service Transitiv) - pokrývá implementaci (přechod) sluţby do provozního prostředí včetně testování, vlastní nasazení, školení. Kniha zavádí nově pojem Systém správy znalostí o sluţbách (Service Knowledge Management System), který obsahuje veškeré znalosti o sluţbě nutné pro rozhodování a její správu. Provoz sluţeb (Service Operation) - pokrývá všechny provozní aspekty sluţby, mezi které patří správa událostí, správa incidentů, provádění poţadavků a další. Definuje například service desk. Neustálé

zlepšování

sluţeb

(Continual

Service

Improvement)

-

pojednává

o průběţném zlepšování sluţeb v oblasti obchodu, technologií a procesů. Tato kniha klade velký důraz na měření a zlepšování sluţeb.

Obrázek č. 10: ITIM rámec

Zdroj: An Introductory Overview of ITIL® V3

Otázkám bezpečnosti databází se ITIL věnuje pouze okrajově, především v čtvrté knize Provoz sluţeb, a dává obecné návody, jak optimálně spravovat databázové systémy. Databázový tým musí úzce spolupracovat s aplikačním týmem, v některých organizacích je dokonce databázový a aplikační tým spojen do jednoho celku.

44

Databáze jsou spravovány buď přímo aplikačním týmem, nebo dedikovaným databázový týmem. Případně se tento tým můţe dělit i do specializovaných sub-týmů podle zaměření aplikace (OLTP, DWH a jiné). Správci databáze se snaţí zajistit optimální výkon databáze, funkčnost a vyţadovaný stupeň bezpečnosti dat. Mezi jejich povinnosti patří. Vytváření a udrţování databázových standardů a politik (mimo jiné bezpečnostních). Prvotní návrh databáze, její vytváření a testování. Dohled nad dostupností a výkonností databáze, kapacitním plánováním a celkovou odolností. Zvyšování robustnosti databáze replikací dat, vytváření HA23 řešení. Dohledem nad databázovými objekty s cílem minimalizovat zatíţení systému. Zajištění pravidelné údrţby dat a jejich zálohování. Proaktivní přístup při řešení provozních rizik, ať jiţ bezpečnostních, či výkonnostních. Monitoring provozu a generováním reportů managementu o provozu, bezpečnostních problémech a vytíţení systému. Poskytováním S3 podpory souvisejícím útvarům při řešení incidentů a problémů.

1.8 COBIT COBIT24 je všeobecně přijímaný rámec (framework) vytvořený mezinárodní asociací ISACA25 pro správu a řízení oblasti informačních technologií (IT Governance).[9] Jedná se o soubor praktik (systém cílů a metrik), které by měly umoţnit dosaţení strategických cílů organizace díky efektivnímu vyuţití dostupných zdrojů a minimalizaci IT rizik. COBIT se skládá ze sady dokumentů. Manaţerský souhrn (Executive Summary). Rámec metodiky (Framework).

23

HA – High Availability – vysoká dostupnost systémů Cobit – Control Objectives for Information and related Technology 25 ISACA – www.isaca.org 24

45

Směrnice pro řízení (Management Guidelines). Detailní kontrolní cíle (Detailed Control Objective). Směrnice pro audit (Audit Gudelines). Sada nástrojů na implementaci metodiky (Implementation Tool Set). COBIT je primárně určen vyššímu managementu k posouzení fungování ICT auditorovi při provádění auditu systému řízení ICT (ITIL je primárně určen IT managementu).[1] COBIT rozděluje IT do 4 základních skupin[11]. Plánování a organizace (PO – Plan and Organise). Akvizice a implementace (AI – Acquire and Implement). Dodání a podpora (DS – Deliver and Support). Monitorování a vyhodnocování (ME – Monitor and Evaluate). V rámci těchto domén je popsáno 34 procesů. Tyto procesy jsou pak poměřovány z hlediska 7 informačních kriterií (efektivnost, výkonnost, důvěrnost, integrita, dostupnost, soulad, spolehlivost). Výsledná zjištění přiřazuje 5 zdrojům (personál, aplikace, technologie, vybavenost, data)[11]. Bezpečnostním otázkám se COBIT věnuje v DS5 - Ensure systems security (účty, hesla, bezpečnostní testování a monitoring, definice incidentů). COBIT dále zavádí model zralosti procesů (Maturity Model), které se odvozují od stupně zvládnutí provádění procesů v podnikové informatice (na základě měkkých metrik)[1]. COBIT je v současné době k dispozici ve verzi 4.1, verze 5.0 by měla vyjít 10. dubna 2012 a má konsolidovat COBIT 4.1, VAL IT 2.0, Risk IT a více čerpat z BMI26 a ITAF27.

26 27

BMI – Business Model for Information Security ITAF – IT Assurance Framework

46

Obrázek č. 11: COBIT

Zdroj: COBIT 4.1: Framework for IT Governance and Control 2009

1.9 Ostatní normy a pouţívané standardy Bankovní ústav musí kromě výše zmíněných norem, které definují poţadavky na systém managementu bezpečnosti informací (např. ISO 27001 a 27002), a bezpečnostních rámců věnovat pozornost i celé řadě oborových norem a nařízení bankovního dohledu České národní banky. Jednou z nich je i „Opatření České národní banky č. 2 ze dne 3. února 2004 k vnitřnímu řídícímu a kontrolnímu systému banky“28, které kromě jiného obsahuje poţadavky na kontrolní systémy banky, řízení rizik, poţadavky na bezpečnost informačních systémů banky, komunikačních sítí a interní audit. Jedním z kroků ke zvýšení bezpečnosti Oracle databáze i testování nastavení neboli benchmarking.

28

http://www.cnb.cz/miranda2/export/sites/www.cnb.cz/cs/legislativa/vestnik/2004/download/v_2004_03_102045 10.pdf

47

Jedním z produktů, kterým lze testovat bezpečnostní nastavení, je i Security Configuration Benchmark For Oracle Database Server 11g vydaný Centrem pro internetovou bezpečnost (The Center for Internet Security)29. Zaměřuje se nastavení systému, instalace programového vybavení, záplatování, nastavení práv na soubory a adresáře, auditní nastavení, politiku hesel a přístupů. Kromě Oracle databáze umoţňuje i testování Microsoft SQL Serveru. Tento benchmark nabízí dvě úrovně nastavení. Level I – tato úroveň je určena administrátorům s jakoukoli úrovní znalosti a změny bezpečnostního nastavení nemohou mít „destruktivní“ vliv na funkčnost testovaného systému. Level II - tato úroveň je určena administrátorům s pokročilými znalostmi v oblasti databázové bezpečnosti, zaměřuje se na pokročilé bezpečnostní nastavení a síťovou architekturu.

29

http://benchmarks.cisecurity.org/

48

2 Ostatní aspekty databázové bezpečnost 2.1 Aplikační zabezpečení Při ochraně dat není moţné pominout zabezpečení aplikací pracujících s danou databází. V dnešní době, kdy se systémy především z úsporných důvodů konsolidují a centralizují, se stále častěji vyuţívá třívrstvá aplikační architektura, kdy se běţní uţivatelé prostřednictvím webového prohlíţeče připojují na aplikační server, který na databázová data přistupuje přes sdílený aplikační účet. Autentizace a autorizace koncového uţivatele je tedy nutné řešit na úrovni mimo databázi. Existuje silný tlak, aby se uţivatel ověřoval pouze při prvotním přihlášení a do ostatních systémů přistupoval na základě technik single sign-on a potřebná oprávnění byla uloţena na LDAP systémech, nejčastěji v Microsoft Active Directory, coţ umoţňuje snadnější centrální správu uţivatelských přístupů.

2.1 Bezpečnost dat Databázová bezpečnost by se neměla soustředit pouze na problematiku zneuţití a ochrany dat. Důleţitou oblastí je také ochrana dat před jejich ztrátou, kterou můţe způsobit útočník, ale která můţe nastat i z běţných důvodů, jako jsou uţivatelské chyby, selhání personálu, závada programového vybavení nebo hardwarového zařízení nebo takzvanou vyšší mocí, coţ můţe být například přírodní katastrofa. Z důvodu všech výše uvedených hrozeb musejí být data dostatečně chráněna a zálohována. Databáze se dnes v bankovním prostředí provozují na infrastruktuře SAN30 polí (např. HP XP24000, IBM DS8300, EMC DMX-4), kde jsou data chráněna na mnoha úrovních. Z hlediska Oracle databází se nejčastěji řeší RAID konfigurace, v praxi se pouţívají především RAID 1 pro maximální bezpečnost, RAID 1+0 pro maximální výkon a RAID 5 pro efektivní vyuţití diskového prostoru při zachování přijatelné odolnosti proti výpadkům a dobrého výkonu. V naší společnosti jsem v poslední době testoval výkonové rozdíly mezi RAID1+0 a RAID 5 (coţ je běţný SAN standard) při ladění OLTP databáze na poli EMC Symmetrix DMX-4 a v praxi naměřené výsledky byly téměř shodné. 30

SAN – Storage Area Network – datová síť slouţící k připojení diskových polí a zálohovacích zařízení k serverům

49

Výběr vhodného reţimu a způsobu zálohování závisí na důleţitosti dat a na ceně za tuto ochranu. V bankovním sektoru je bezpečnost dat na jednom z předních míst a je tedy zřejmé, ţe se pouţívají robustní zálohovací systémy. Databáze jsou aţ na výjimky zálohované pomocí utility RMAN na enterprise zálohovací systémy, kde jsou data uchovávána na fyzických či virtuálních páskách (VTL31). V případě vysokých poţadavků na rychlost zálohy či obnovy je moţné ve specifických případech pouţít klonovací technologie diskového pole (Sync and Split Technology). Bezpečnost dat závisí kromě uloţení záloh i na formě provádění záloh. Z důvodu poţadavku na obnovu a zotavení databáze do určitého okamţiku se pouţívá téměř výlučně online zálohy, ať jiţ plné nebo různé formy přírůstkových záloh. V naší společnosti je postavena zálohovací politika Oracle databází na víkendové plné záloze a záloze archivních redologů, další dny pak na kumulativní přírůstkové záloze a opět záloze redologů. Tento způsob zkracuje délku trvání zálohy, sniţuje zatíţení infrastruktury (zálohuje se pouze malá část změněných dat), sniţují se poţadavky na alokovaný prostor v zálohovacím systému, který muţe být díky velikosti databází a poţadavkům retenční politiky značný. Tyto výhody jsou ale vykoupeny prodlouţením délky obnovy (v případě havárie je nejprve nutné obnovit data z plné zálohy, pak aplikovat přírůstkové zálohy a nakonec aplikovat pedology při zotavení databáze). Pouţití přírůstkových záloh není vhodné pro všechny databáze. Problematice záloh, ochrany dat a vysoké dostupnosti jsem se podrobně věnoval ve své bakalářské práci.[20]

2.2 Vysoká dostupnost S bezpečností systémů souvisí také jejich dostupnost. Systémy, které nepouţívají ţádnou z forem clusteru, jsou zranitelnější. Clusterové řešení je robustnější, coţ je i poţadavek mnoha aplikací v bankovním sektoru. Existují různé formy clusterů, které se pouţívají ve spojení s Oracle databázemi. 2.2.1

Cold failover cluster

V této variantě databázová instance běţí pouze na primárním serveru, souborový systém pod databází se replikuje na záloţní server. Synchronní replikace probíhá buď na úrovní 31

VTL – Virtual Tape Library – páskovou mechaniku supluje pouţití SAN pole. Pro aplikaci je ale pouţití transparentní, vyuţívá se především na menší a časté zálohy.

50

operačního systému (host based mirroring, např. LVM32), nebo na úrovni diskového pole (např. CA33, SRDF34, PPRC35). Tato varianta je robustnější, méně citlivá na různé výpadky, ale podle mých zkušeností pomalejší neţ replikace pomocí diskového pole. V případě havárie je instance databáze přesunuta na záloţní server, vlastní přesun je odstávkový. Existují různé implementace cold failover clusterů (např. IBM dodává hned dva hlavní typy – PowerHA a Extended Model). Colf failover cluster v podstatě nevyuţívá ţádnou clustrovou funkčnost Oracle databáze, v případě provozu na záloţním uzlu méně neţ deset dní za rok se platí databázová licence pouze za primární server, coţ vede k vysoké oblibě tohoto modelu. 2.2.2

Oracle Real Application Clusters

Oracle Real Application Clusters (RAC) je clusterové řešení Oracle databáze, kdy na různých serverech běţí samostatné instance jedné Oracle databáze (koncept MAA36). Toto řešení plní několik funkcí, především kapacitní, kdy je moţné škálovat výkon databáze přidáváním dalších instancí a rozprostírat tak zátěţ, tak funkci vysoké dostupnosti, kdy v případě výpadku jednoho serveru zůstává databáze dostupná pro uţivatele (v případě, ţe i aplikační software umoţňuje failover na jiné instance). Oracle udává, ţe je moţné efektivně pouţít aţ 100 instancí zároveň, coţ představuje obrovský výkonnostní potenciál. RAC je také moţné v dnešní době efektivně vyuţit jako náhradu drahých hi-endových řešení, protoţe umoţňuje spojením levnějších mid-range komponent dosáhnout stejného vysokého výkonu za celkově niţší pořizovací cenu. Pro funkčnost RAC je nutné vyuţít nějakou formu sdílení datových souborů mezi instancemi, nejčastěji formou clusterových souborových systémů nebo pomocí ASM37 a Oracle CRS38. Jednotlivé instance mezi sebou sdílí obsah paměťové oblasti SGA. RAC je velmi citlivý na kvalitu a rychlost meziclusterové komunikace.

32

LVM – Logical Volume Mirroring – zrcadlení souborového systému na platformě IBM AIX. CA – replikační technologie Continuous Access firmy HP. 34 SRDF – replikační technologie Symmetrix Remote Data Facility firmy EMC. 35 PPRC – replikační technologie Peer to Peer Remote Copy firmy IBM. 36 MAA – Oracle Maximum Availibility Architecture 37 ASM -Automatic Storage Management – Oracle produkt umoţňující správu databázových souborových systémů 38 Oracle CRS – Oracle Cluster Ready Services – clusterový software firmy Oracle 33

51

2.2.3

Oracle Data Guard

Další moţností, jak zajistit ochranu dat a vyšší dostupnost, je technologie Oracle Data Guard. Na vzdáleném serveru vnikne jedna nebo více kopií primární produkční databáze, která je občerstvována aplikováním archivních redologů a v případě havárie produkční databáze převezme její roli. V konfiguraci Active Data Guard je moţné přesunout část produkční zátěţe (například reporting) na tuto záloţní databázi. Synchronizace primární a záloţní databáze můţe probíhat ve třech reţimech[20]. V reţimu maximální ochrany – transakce jsou na primárním systému potvrzené aţ po úspěšném zapsání redologů na druhý server, v případě problémů s přenosem se primární databáze zastaví. V reţimu maximální dostupnosti - transakce jsou na primárním systému potvrzené aţ po úspěšném zapsaní redologů na druhý server, v případě problémů s přenosem primární databáze pokračuje a po odstranění problému je přenos redologů dokončen. V reţimu maximálního výkonu – transakce jsou na primárním systému potvrzeny a redology jsou přeneseny na záloţní server aţ následně. Záloţní databázi je moţné provozovat ve dvou reţimech. Fyzická záloţní databáze – záloţní databáze je přesnou kopii primární databáze, lze ji dokonce vyuţít pro zálohování místo primární databáze. Logická záloţní databáze – záloţní databáze můţe obsahovat některé struktury, například indexy, které primární databáze nemá a které usnadňují reporting.

52

3 Aplikace bezpečnostních politik v bankovním prostředí 3.1 Trendy v databázové bezpečnosti Databázový administrátor se v současné době setkává s poţadavky na stálé zvyšování zabezpečení, které nezřídka jde i za rozumné hranice. Tyto poţadavky lze rozdělit do dvou základních proudů: vlastní zabezpečení databáze, zabezpečení databázové aplikace. Nepřekvapivě se auditní nálezy a doporučení zaměřují především na vlastní databázi, neboť je přehlednější a snadněji aplikovatelná. Nejčastější změny v zabezpečení míří na nastavení přísnější politiky hesel, omezování přístupu uţivatelů a obzvláště oblíbená oblast auditních nálezů je snaha co nejvíce ztíţit ţivot správci databáze. Spíše výjimečně se auditor zaměřuje na vlastní databázovou aplikaci, protoţe většinou nerozumí poţadované funkcionalitě, případné změny musejí být konzultovány s obchodním útvarem a často vyţadují komplikované zásahy do aplikačního kódu, coţ bývá drahé a zdlouhavé (změna často vyţaduje nastartování projektu). Samostatnou kapitolou bývá snaha projektových vedoucích protlačit změnu nebo novou aplikaci do produkčního provozu za kaţdou cenu, především na úkor bezpečnosti. V praxi se setkávám s paradoxy, kdy je databáze umístěna do silně chráněného síťového segmentu, na bezpečnost je kladen velký důraz, a přesto si projekt vybojuje předání databázového exportu z produkčního prostředí externímu dodavateli (za souhlasu vlastníka dat i útvaru bezpečnosti). Častý je také jev, kdy je vynuceno podrobné nastavení auditu, nicméně auditní data nikdo neodebírá a nekontroluje. Přes všechny tyto problémy se úroveň zabezpečení zvyšuje. V praxi lze vysledovat následující trendy v oblasti zabezpečení databází. Zavedení jmenných účtů na úrovni OS i databáze.

53

Omezení přístupu v OS na vlastníka databáze (nejčastěji zákaz remote přístupu na účet oracle) a uzamčení databázových účtů SYS a SYSTÉM. Odebírání objektových práv účtu PUBLIC, vyuţití ACL ochran systémových utilit. Zpřísňování nastavení auditingu. Podrobné a důsledné vedení provozní dokumentace, zavádění ITIL procedur. Pokusy o anonymizaci databázových struktur (nic neříkající názvy tabulek, indexů, cizích klíčů a aplikačních účtů). Přesouvání databází do chráněných síťových segmentů, do kterých je povolen přístup pouze při pouţití VPN a různých forem certifikátů. Omezování administrativních protokolů (zákaz telnet, ftp, omezení SSH). Snaha odstavit databázové administrátory od aplikačních dat (zavádění DV). Zavedení Single sign on autentizace. Postupný přesun k třívrstvé aplikační architektuře, coţ je provázeno masivním poklesem počtu databázových uţivatelských účtů. Snaha o unifikaci prostředí. Přenesení provozní podpory na dohledová centra v Asii za účelem sníţení provozních nákladů, z toho plynoucí snaha o zjednodušování provozní administrace. Snahy o plnění norem a získání bezpečnostní certifikace. Mnohé ze zmíněných trendů jsou ve vzájemném rozporu, protoţe vedou ke zvyšování sloţitosti systémů a aplikaci, přestoţe se firmy zároveň snaţí o zlevnění a zjednodušení celého procesu podpory.

3.2 Základní kroky k zabezpečení databáze Poţadovaná úroveň bezpečnosti se přímo odvíjí od konkrétní aplikace, jiné poţadavky má malá repository databáze pod intranetovou aplikaci a jiné má databáze, ve které jsou uloţena například čísla kreditních karet zákazníků. V praxi databázový administrátor obvykle řeší následující situace. Zabezpečení databáze po prvotní instalaci a konfiguraci.

54

Zabezpečení uţivatelských účtů

- nastavení délky platnosti hesla, zamykání

a odemykaní účtů, vynucení silného hesla. Nastavení přístupových oprávnění – přidělování oprávnění a aplikačních rolí. Zabezpečení síťové komunikace. Nastavení vyššího stupně kontroly při přístupu k datům – šifrování sloupců a tabulkových prostorů, pouţití Virtuální privátní databáze nebo Oracle Label Security, případně zavedení Database Vault. Nastavení auditingu a sběr auditních dat. Pro zajištění vyšší úrovně zabezpečení databáze společnost Oracle nabízí následující produkty. Šifrování a maskování dat Oracle Advanced Security Option. Oracle Secure Backup. Oracle Data Masking. Řízení přístupů Oracle Database Vault. Oracle Label Security. Auditing a stopování činností uţivatelů Oracle Audit Vault. Oracle Configuration Management. Oracle Total Recall. Zamezení přístupu a monitoring Oracle Database Firewall.

55

3.3 Průzkumy bezpečnostní situace Databázový administrátor i útvar bezpečnosti ve finanční instituci by měli pravidelně sledovat aktuální zprávy a analýzy bezpečnostní situace a vyvozovat z nich závěry. Pro ilustraci situace uvádím výsledky renomovaných společností, které se zaměřují na prozkum trhu, v tomto případě jsou průzkumy zaměřené na databázovou bezpečnost.

Obrázek č. 12: Porovnání zabezpečení databází

Zdroj: Forrester Database Security Market Report 2009

Z uvedeného průzkumu vyplývá, ţe produkty společnosti Oracle patří k absolutní špičce na poli databázové bezpečnosti, v závěsu za ní se objevují databázové produkty firem IBM, Microsoft a SAP (SAP oznámil akvizici SYBASE v roce 2010).

56

Obrázek č. 13: Porovnání počtu zneuţití dat

Zdroj: Verizon – Data Breach Investigations Report 2010

Průzkum provedený firmou Verizon v roce 2010 potvrzuje všeobecně uznávaný názor, ţe finanční sektor je nejčastějším cílem bezpečnostních útoků. A v rámci finančního sektoru se nejčastěji setkáváme s útoky a zneuţitím dat v oblasti platebních karet, jak ukazuje následující graf.

Obrázek č. 14: Porovnání zneuţití dat podle typu dat

Zdroj: Verizon – Data Breach Investigations Report 2010

57

3.4 Anketa o bezpečnostních otázkách Oracle databáze Pro zjištění názorů administrátorů Oracle databází jsem pouţil dotazník, pokládané otázky se týkaly bezpečností problematiky v Oracle databází. K vytvoření jsem pouţil internetový portál www.google.com, protoţe aplikace Google Docs nabízí moţnost interaktivního vytvoření anketních otázek, jejich publikaci a následné automatické vyhodnocení. Zvolil jsem sérii otevřených a uzavřených otázek a prostřednictvím emailové ţádosti jsem oslovil komunitu Oracle administrátorů ve finančních institucích v Praze. Obrázek č. 15: Otisk obrazovky s průzkumem na docs.google.com

Zdroj: Vlastní úprava

58

Anketa je dostupná na následující webové stránce: https://docs.google.com/spreadsheet/viewform?formkey=dHZ6ZEh6VWpPYkNWaWFLZUh YYUQydEE6MA&ifq

3.5 Výsledky ankety Na anketní otázky odpovědělo v průběhu února a března 2012 celkem 39 Oracle administrátorů, jejich odpovědi byly automaticky zpracovány ve formě grafů systémem Google Docs. Lze z nich vyvodit následující závěry.

Všichni administrátoři, kteří se zúčastnili ankety, mají zkušenosti s Oracle databázemi, téměř polovina z nich má zkušenosti s ostatními databázovými produkty, především IBM DB2 a Microsoft SQL Serverem. Právě poměrně úzké zaměření ankety na databázové produkty Oracle bylo příčinou, proč jsem stejně jako mnoho mých kolegů z BIVS neţádal ostatní studenty o vyplnění ankety, protoţe výsledky by byly zkreslené.

Plných 79% respondentů má zkušenosti s Oracle databázemi delší neţ 5 let, coţ dává závěrům ankety vyšší důvěryhodnost.

59

Z výsledků plyne, ţe respondenti z 51% spravují spíše menší mnoţství produkčních databází. Pokud ale tuto hodnotu poměřím se stavem v naší společnosti, je nutné toto číslo vynásobit minimálně 3x (vývojové a integrační, akceptační a produkční prostředí), abychom získali představu o celkovém počtu spravovaných databází.

Z odpovědí plyne, ţe většina administrátorů povaţuje bezpečnostní nastavení jimi spravovaných databází za dostatečné a odpovídající poţadavkům. Z vlastní zkušenosti vím, ţe administrátor často přeceňuje zabezpečení svého systému. Je to ale pochopitelné, děje se to částečně z neznalosti nejnovějších bezpečnostních problémů a nových technologií, navíc většinou kaţdé zpřísnění bezpečnosti znamená náročnější správu databáze a člověk má spíše snahu si práci zjednodušovat.

Názory administrátorů na tuto otázku jsou poměrně vyrovnané v případě prvních dvou odpovědí a také není překvapením, ţe se podceňuje bezpečnost po skončení provozu systému. Podle mých zkušeností je to proto, ţe mnoho systémů tak často nekončí, mají spíše snahu přeţívat „navţdy“. Ve své praxi jsem se setkal s případy, ţe databáze, ve kterých se během

60

provozu data pečlivě chránila, se po ukončení provozu prostě vyexportovala na médium. To se následně předalo určené osobě a nedá se předpokládat, ţe by tento pracovník tato data nějak bezpečně uloţil.

Z odpovědí vyplývá, ţe nejčastější způsob zabezpečení přihlášení je pomocí profilů a triggerů. Respondenti mohli doplnit i další moţné způsoby, nicméně to nikdo z nich neudělal. Je otázka, zda proto, ţe opravdu nikdo ţádný další způsob nepouţívá.

Zabezpečení profilu DEFAULT bývá většinou prvním auditním nálezem auditora, proto nepřekvapí, ţe většina administrátorů tento profile zabezpečila. Osobně v tomto kroku vidím jisté úskalí, neboť to klade vyšší nároky na změnové řízení. Osobně se mi opakovaně stalo, ţe instalace zhavarují právě z důvodu, ţe vývojář vytváří nové aplikační účty a schémata a v instalačním skriptu jim navolí slabé heslo. Osobně spíše preferuji nepouţívání DEFAULT profilu.

61

Oslovení administrátoři se nejčastěji setkávají s neoprávněným přístupem na cizí, aplikační a schéma účty. Řešením by mohlo být, kromě administrativních opatření a trestání takové činnosti, plošné zavádění single sign on autentizace.

Odpovědi na tuto otázku mě překvapily a ukazují, ţe ne všichni administrátoři své databáze zálohují pomocí utility RMAN. Osobně povaţuji zálohování pomocí utilit EXP a EXPDP za nesmyslné a zálohování prostředky OS za zastaralé.

Z odpovědí administrátorů vyplývá, ţe naprostá většina databázové zálohy nešifruje. Částečně to jistě ukazuje důvěru k robustnosti a zabezpečení pouţívaných enterprise zálohovacích systémů.

Stejné výsledky jako v předchozím případě jsem dostal i na otázku, zda oslovení administrátoři maskují data při klonování databází do neprodukčních prostředí. Přestoţe to bývá jeden z hlavních poţadavku, v praxi se to skutečně téměř nikdy neděje. Maskování naráţí na architekturu pouţívaných aplikací, těţko lze čekat něco jiného, kdyţ jsou citlivá

62

data (PAN – čísla účtů, čísla klientů, čísla karet) na vrcholu datové struktury. Pokud je zamaskujeme, většinou přestane celá aplikace fungovat díky porušeným vazbám a tudíţ ani nebývá co testovat.

Odpovědi na otázku ukázaly, ţe většina databází se audituje, byť většinou pouze na úrovni DDL změn. Toto nastavení nemívá většinou ţádné negativní vlivy na výkon databáze. Poměrně málo administrátorů pouţívá pokročilé auditní řešení (FGA).

Z výsledků odpovědí vyplývá, ţe třetina respondentů pouţívá (nebo někdy pouţila?) při řešení bezpečnostních incidentů Logminer. Osobně mi přijde, ţe to je poměrně vysoké číslo.

Zadávání hesel na aplikační databázové role je další z evergreenů auditních nálezů. Odpovědi respondentů ukazují, ţe tuto funkčnost nikdo nevyuţívá. V naprosté většině případů by to znamenalo zásadní redesign aplikací. Bezpečnost dat lze řešit jinými prostředky efektivněji a oprávněnost pouţití lze vynutit v naprosté většině přidělením nebo nepřidělením konkrétní role.

63

Z odpovědí respondentů jasně vyplývá, ţe v okamţiku incidentu poskytují dodavateli veškeré potřebné údaje. Jen v případě OCM není situace tak jednoznačná. Osobně jsem při pouţití těchto nástrojů opatrný, administrátor nemá nad poskytovanými údaji plnou kontrolu. V naší firmě se OCM nevyuţívá.

Odpovědi respondentů ukazují, ţe všeobecně kladou důraz na instalaci aktuální PSU a CPU. Auditní nálezy a různé „best practice“ metodiky většinou doporučují mít programové vybavení aktuální, ale v praxi bývá výhodnější být spíše lehce konzervativní. Některé verze patchsetu v minulosti budily dojem, ţe se zákazník instalací tohoto softwaru stává spíše beta testerem neţli spokojeným uţivatelem. Je jistě výhodnější a bezpečnější, pokud softwarové chyby objeví horliví zákazníci před vámi. V případě velkých a komplexních systémů, kde kaţdý upgrade databáze znamená spuštění velkého projektu a nutnost náročného testování, bývá v bankovním sektoru zaţitý zvyk upgradovat databázový software aţ na druhý release dané verze (Release 2).

64

Odpovědi respondentů ukazují, ţe ve většině případu ve firmách existuje standardní politika vytváření uţivatelských účtu, byť se často z důvodu úspor přenáší břemeno vytváření účtu na administrátora databáze, přestoţe je na trhu mnoţství nástrojů, které jsou schopny automatizovaného vytváření účtů.

Více neţ dvě třetiny oslovených databázových administrátorů spatřuje slabá místa jinde, neţ ve svých databázích. Je samozřejmě otázka, zda to odpovídá realitě a není to jen jejich přání. Na základě výsledků anketních otázek lze konstatovat, ţe naprostá většina databázových administrátorů si uvědomuje důleţitost zabezpečení dat a v praxi své databáze skutečně zabezpečuje, nicméně i zde lze nalézt velké rezervy. Z výsledků lze odvodit, ţe administrátoři při zabezpečení pouţívají pouze základní bezpečnostní prvky a nepouţívají sofistikovanější bezpečnostní produkty, jako jsou Oracle Database Vault, Oracle Audit Vault, Oracle Label Security, implementace single sign-on autentizace a další. Je otázka, proč se tak neděje. Odpovědí je z části cena těchto produktů, svou roli hraje i náročnost implementace a následné změny v návrhu aplikací i v nutných organizačních změnách. V době permanentní hospodářské krize navíc existuje tlak na úspory a zakonzervování současného stavu. Přes všechny tyto překáţky jsou databáze postupem času stále bezpečnější.

65

3.6 Splnění normy PCI DSS pro systém ASR Banka, jakoţto poskytovatel sluţeb společností MasterCard a Visa, je povinna splnit poţadavky PCI DSS, které vyplývají ze zpracování a uchovávání chráněných informací platebních karet (PAN, jméno vlastníka karty, data expirace karty, servisního kódu a dat uloţených na magnetickém prouţku) v systému ASR. Na implementaci standardu PCI DSS existuje právní nárok, v případě nesplnění existuje nebezpečí postihu od karetních asociací, v krajním případě i odejmutí licence nabízet produkty zmíněných společností. Kromě této skutečnosti je splnění poţadavků PCI DSS, neboť vede k zajištění vyšší bezpečnosti bankovních systémů a minimalizuje tedy nebezpečí zneuţití citlivých dat a z toho plynoucí finanční nebo reputační škodu. Implementace vyšší úrovně bezpečnostní politik musí proběhnout na všech dotčených systémech bez výjimky, neboť úroveň bezpečnosti celého komplexu se odvíjí od nejslabšího článku. Tyto poţadavky musí zároveň splnit i její smluvní partneři, kteří jsou součástí její obchodní sítě, stejně jako dodavatelé třetích stran (v případě outsourcingu sluţeb a aplikačních systémů). Systém ASR se skládá z 9 komponent, mezi kterými jsou obsaţeny aplikační servery, spravované externími firmami, Oracle databázovým serverem na platformě AIX, MS SQL databázovým serverem na platformě MS Windows Server 2003, souborovým úloţištěm, doménovým LDAP serverem, síťovými prvky a zálohovacím systémem IBM TSM. V rámci přípravy projektu QSA provede podrobnou analýzu současného stavu připravenosti na splnění PCI DSS. Na základě této analýzy (GAP analýza) budou připraveny akční plány změn, které budou implementovány s maximální prioritou. Po skončení fáze implementace QSA provede zhodnocení stavu a vydá Osvědčení o shodě poskytovatele sluţby se standardem bezpečnosti dat odvětví platebních karet (PCI DSS).

3.7 Zabezpečení databáze ASR Cílem projektu bude splnění následujících poţadavků obchodního útvaru karetních produktů zastoupeným IRM útvarem na zabezpečení databáze a zároveň se otestuje schopnost ICT vytvořit a udrţovat prostředí připravené v souladu s PCI DSS. V rámci přípravy projektu bude proveden „Proof of Concept“, v rámci kterého dojde vytvoření zabezpečené databáze ASR podle poţadavků PCI DSS.

66

V rámci analýzy zjistil QSA nesoulad mezi poţadavky PCI DSS a aktuálním stavem databáze ASR a navrhl akční plán změny, který obsahuje hlavní oblasti, v kterých by měl nesoulad řešit: Oddělení databáze od aplikačního serveru. Vznik databáze v samostatném zabezpečeném síťovém segmentu. Upgrade databáze na aktuální verzi 11.2.0.3. Pravidelná instalace bezpečnostních záplat. Zašifrování citlivých dat pomocí TDE na úrovni tabulkového prostoru. Nastavení šifrované síťové komunikace mezi aplikačním a databázovým serverem ve veřejném prostředí (komunikace se děje pouze v rámci uzavřeného bankovního prostředí, takţe tento poţadavek není nezbytný). Omezení přístupu administrátora k aplikačním datům (implementace DV). Zavedení granularity přístupových práv na úrovni tabulky (sloupce, řádky). Ochrana auditních záznamů a jejich přesun na centrální server. Mnoho z následujících poţadavků znamená citelný zásah do dosavadních provozních postupů a zvýšení náročnosti na správu prostředí, coţ se samozřejmě odrazí i ve zvýšení provozních nákladů. Zvýšení bezpečnosti na poţadovanou úroveň dále zahrnuje. Vznik standardní dokumentace, která bude obsahovat instalační a konfigurační údaje, musí zohledňovat a ohodnocovat soulad s poţadavky PCI DSS a skutečným stavem. Instalace a konfigurace má být provedena jednotnou instalační procedurou, aby byla zajištěna uniformita prostředí a nastavení. Musí vzniknout databázový standard instalací, z kaţdé instalace musí vzniknout instalační protokol. Zabezpečení AIX serveru. o Instalace (verze 6.1 TL6 -6) a konfigurace musí být provedena podle standardního postupu v souladu s poţadavky, z kaţdé instalace musí vzniknout instalační protokol.

67

o Oprávnění pro databázové soubory musejí být jednotná a restriktivní, práva by měl mít pouze vlastník databázového programového vybavení a databáze, nikdo jiný (umask 022). o

Vytvoření jmenných účtů všech uţivatelů, uzamčení servisních účtů, pro jejich otevření a pouţití musí existovat protokolovatelná procedura (ITIM). Nastavení účtů musí splňovat poţadavky na silná hesla (délka, komplexnost, opakování…). Zákaz remote login pro vlastníka databáze, poţadavek auditování činností a pouţití pouze v oprávněných případech.

o V rámci pravidelné údrţby serveru musí být zaveden postup implementace bezpečnostních oprav a kritických problémů. Oddělení produkčního a testovacího prostředí. o Oddělení na úrovni HW (samostatný LPAR) od ostatních systémů. o Oddělení na úrovni síťového segmentu, zamezení propojení na úrovni databázových linků. o Oddělení na úrovni koncových stanic a tnsnames.ora (zvláštní pro produkční a testovací prostředí), případně striktní dodrţování pravidla neuvádět víc připojení, neţ je nutné. o Zamezit administrativním opatřením propojení PROD a ACC prostředí na úrovni aplikačních a messaging systémů, enterprise busů atd. o Udrţovat striktní a pečlivě dokumentovanou politiku řízení změn (DEV, INT, ACC, PROD). Zabezpečení síťového provozu. o Zamezení přístupu na server pomocí nezabezpečených protokolů (telnet,ftp) o Zabezpečení www databázového spojení pomoci https mezi db agentem a GRID konzolí, zabezpečení komunikace pomocí https mezi wwww prohlíţečem a GROD konzolí. o Zabezpečení SQL*Net komunikace mezi agentem a cílovou databází pomocí technik OASO39 (šifrování).

39

OASO - Oracle Advanced Security Option

68

o Zabezpečení SQL*Net komunikace mezi GRID konzolí a GRID databází pomocí technik OASO. o Zabezpečení SQL*Net komunikace mezi GRID konzolí a cílovou databází pomocí technik OASO. o Zabezpečení SQL*Net komunikace mezi databázovými klienty a cílovou databází pomocí technik OASO (zřejmě nebude nutné). o Zákaz online konfiguraci na úrovni listeneru. Zabezpečení databáze. o Upgrade na verzi 11.2.0.3. o Revize instalovaných databázových komponent (pravidlo pouţití pouze nutných komponent). o Nahrát aktuální bezpečnostní záplaty (PSU) a nastavit proces pravidelného záplatování.40 o Nepouţití UTL_FILE_DIR. o Ošetření práv dba_directory. o Revize a případný zákaz ANY privilegii. o Revize práv public účtů. o Revize databázových účtů a rolí (pravidlo nastavenou pouze nutných oprávnění). o Vytvoření šifrovaného tabulkového prostoru pomocí TDE. o Údrţba šifrovacího klíče (pouţití Oracle Wallet), zajištění procedury zpřístupnění master key pří otevření databáze. o Přesun všech poţadovaných objektů do připraveného tabulkového prostoru. o Instalace a konfigurace Oracle DV, vytvoření realmů (struktury obsahující PAN) a umoţnění přístupu (zvýšená granularita přístupových oprávnění) pouze pro určené uţivatele (princip „need to know“) atd.

40

Pravidelnou notifikaci o vydání Critical Patch Update lze po vytvoření účtu poţádat na http://www.oracle.com/technetwork/topics/security/securityemail-090378.html.

69

o Separace práv a rolí v DV (databázový administrátor, bezpečnostní administrátor, administrátor přístupů). o Nastavení auditingu (FGA na struktury obsahující PAN) a automatické odlévání na centrální server, zabezpečit následné zpracování a vyhodnocování auditních záznamů. Zváţit zavedení vytváření databázových záloh pomocí Orace Secure Backup. o PCI DSS splňuje jiţ pouţití TDE, zálohovaná data obsahující PAN budou šifrovaná. Nastavit a udrţovat správu uţivatelských přístupů v souladu s PCI DSS. o Provést analýzu pouţitých databázových profilů a poţadavku na databázová hesla. o Zabezpečit odpojování neaktivních session. o Nastavit proceduru čištění nepouţívaných účtů. o Zváţit zavedení single sign-on autentizace.

70

3.8 Projekt 3.8.1

Obecný ţivotní cyklus projektu v bankovním prostředí

Kaţdá velká změna funkcionality nebo zavedení nového IS je v bankovním prostředí realizována formou projektu. Realizace zavedení principů bezpečnostní normy PCI DSS znamená velký zásah do fungování ICT a návazných obchodních útvarů a neobejde se bez velké finanční investice jak do pořízení IS, tak do změny současných pracovních postupů, tak i do změn odpovědností útvarů za provoz IS. Správci IS i koncoví uţivatelé budou muset být na novou situaci dobře připraveni interním školením. Velký důraz bude nutné klást na následné dodrţování nově nastavených pravidel, jinak investice do zvýšené bezpečnosti IS ztratí smysl. Celý proces implementace IS lze rozdělit do čtyř základních etap.[1] 1. Etapa I – Zahájení projektu a. Analýza potřeb. b. Vize a stanovení cílů. c. Tvorba strategie. d. Zadání projektu. e. Rozhodnutí managementu o změně informačního systému. f. Sestavení projektového týmu. 2. Etapa II – Plánování a výběr řešení a. Výběr vhodných komponent systému, který bude zajišťovat nově požadované funkčnosti systému. b. Provedení analýzy způsobu realizace. c. Uzavření smlouvy o zavedení nového systému. 3. Etapa III – Realizace řešení a. Vlastní implementace. b. Sestavení týmů pro vytvoření nových pracovních postupů. c. Pilotní provoz IS. 4. Etapa IV – Provoz a údržba databázového systému a. Zaškolení pracovníků, vypracování dokumentace. b. Zahájení ostrého provozu nového IS.

71

Obrázek č. 16: Ţivotní cyklus projektu

Zdroj: ŠEBEK V.: Projektové řízení

3.8.2

Etapa I – Zahájení projektu

Přípravná fáze má stěţejní vliv na úspěch projektu, její podcenění vede k váţným komplikacím v průběhu projektu a můţe být důvodem i celkového selhání. Je nutné provést detailní fundovanou analýzu potřeb změny, zmapovat situaci na trhu, a zodpovědět otázku, zda je tato změna proveditelná a na základě této analýzy navrhnout řešení, případně dodat podklady pro více variant. Analýza vyústí ve stanovení budoucí vize, která bude v souladu se zadáním projektu a stanoví konkrétné cíle. Analýzou bude pověřen útvaru architektury ICT, který během přípravy bude spolupracovat se všemi zainteresovanými stranami. SWOT analýza implementace PCI DSS V této fázi projektu se standardně pouţívá SWOT analýza, která pomáhá identifikovat slabá a silná místa i moţné příleţitosti a eventuální hrozby ( SO - vyuţití silných stránek pro získání výhod z příleţitostí podniku, WO – eliminace slabých stránek za pomoci příleţitostí, ST – vyuţití silných stránek pro eliminaci hrozeb, WT – eliminace slabých stránek a vyhnutí se hrozbám).

72

Tabulka č. 1: SWOT analýza

Vnější prostředí

Vnitřní prostředí

SWOT analýza Silné stránky (S)

Slabé stránky (W)

Komplexní finanční sluţby, finanční síla a stabilita firmy, dlouhodobá spolupráce se systémovými integrátory a dodavateli, jedinečné know-how ICT ve správě IT sluţeb, údrţba spravovaných IT systémů na vysoké úrovni, zvýšení bezpečnosti globálně, nejen pro produkty spojené s platebními kartami, vyspělá řízení HR zdrojů, obchodní značka, reputace, nákladová výhoda (vyplývající z mnoţstevních slev objednávaných sluţeb a licenčních poplatků, exkluzivní přístup k informačním zdrojům.

Není jasný celkový rozsah implementace norem, nebezpečí vzniku nových poţadavků, nedostatečná pruţnost v reakcích na nové výzvy, zkostnatělost velké společnosti, vyšší náklady na implementaci v porovnání s malými dodavateli, omezený rozpočet ICT plynoucí z úspor a redukce plánovaných rozpočtů, omezené znalosti produktů, které se v rámci plnění PCI DSS budou pořizovat, nízká kvalita některých sluţeb, vysoká fluktuace zaměstnanců na některých pozicích, omezený mzdový rozpočet.

Příleţitosti (O)

Hrozby (T)

Rozvoj a vyuţití nových distribučních kanálů (další rozvoj elektronických kanálů), oslovení širšího spektra zákazníků, zvýšení úrovně bezpečnosti produktů, prezentace jako bezpečná banka, zavádění nových technologií a produktů, u kterých lze očekávat, ţe se prosadí jako standard, outsourcing produktů třetích stran (splnění PCI DSS povede ke zvýšení atraktivity banky v poskytování karetních sluţeb pro malé banky a finanční společnosti).

Příchod konkurence na trh (levné nové progresivní banky, za kterými stojí silná finanční skupina), cenová strategie (dumpingové ceny) „válka“ mezi bankami, změna ţivotního stylu obyvatelstva, odklon od pobočkové sítě ve prospěch nových internetových kanálů, nové elektronické kanály jsou snáze napadnutelné útočníkem neţ konzervativní, dopady hrozící hospodářské recese (pokles kupní síly obyvatel, nutnost vzniku dalších opravných poloţek na nesplácené úvěry), vzrůstající kurz dolaru, za který jsou licence nakupovány.

Zdroj: Vlastní úprava

Vyhodnocení SWOT analýzy, vytyčení strategií SO – Orientace na zvyšování bezpečnosti produktů. WO – Vyuţití poznatků z implementace vyššího stupně bezpečnosti i v dalších projektech. ST – Expanze na trhu, být první na bankovním trhu s certifikací PCI DSS. WT – Zavedení programu úspor. V dalším kroku přichází na řadu tvorba konkrétní strategie, určení finančních a lidských nároků na implementaci změny, vznik projektového týmu.

73

Na základě zjištěných informací, které jsou zpracovány ve formě studie proveditelnosti, rozhoduje komise SC41 o realizaci projektu. Na základě rozhodnutí SC je zadán projekt ve formě dokumentu Project Charter, který jiţ obsahuje detailní informace o projektu, o jeho časování, způsobech provedení, finančních a lidských nárocích. Posledním krokem této fáze je vznik projektového týmu, který se podílí na přípravě a následné realizaci projektu. Projektový tým má následující zástupce. Projektový vedoucí (project manager) – hlavní osoba, která řídí ostatní členy projektového týmu. Je zodpovědný za dodrţování termínů, rozpočtu, kvality dodávky. Řeší aktuální problémy, které při běhu projektu vznikají, koordinuje spolupráci v rámci projektového týmů s ostatními útvary ICT, reportuje průběh projektu v poţadované formě projektové kanceláři a sponzorovi, je zodpovědný za finální dodávku včetně dokumentace a zaškolení uţivatelů. Vlastník procesu (process owner) – je osoba odpovědná za proces a vše, co s ním souvisí. V tomto konkrétním projektu je vlastníkem jmenovaný zástupce karetního útvaru. Sponzor projektu (project sponsor) – jedná se o zástupce obchodního útvaru, který změnu financuje. V tomto případě jde o ředitele karetního útvaru. Projektový koordinátor -

je osoba, na kterou projektový vedoucí deleguje část

pravomocí a která koordinuje výkonné týmy. Členové projektového týmu – jedná se o pracovníky různých ICT týmů, kteří jsou alokováni na daný projekt. V našem případě se bude jednat o zástupce týmu databázové, serverové, aplikační a síťové podpory. Odborný expert – můţe se jednat o zástupce dodavatele, pokud je zvoleno řešení dodávkou od externí společnosti. Administrativní pracovník – v případě rozsáhlého projektu má na starosti zajištění běţné agendy, plánování schůzek a zápisy z projektových porad. V případě menších projektů tuto činnost zajišťuje projektový vedoucí nebo projektový koordinátor.

41

SC – Steering Committee

74

3.8.3

Etapa II – Plánování a výběr řešení

V případě, ţe je start projektu schválen a jsou odsouhlaseny kroky vedoucí k řešení uvedené v Project charteru, vybírá projekt jednotlivé komponenty a dodavatele řešení. Na základě objektivního srovnání produktů a sluţeb na trhu se projekt rozhoduje, zda poţadované funkčnosti bude implementovat interně, v případě, ţe disponuje dostatečnými zdroji a zkušenostmi, nebo pořídí produkt třetí strany. V případě pořízení produktu třetí strany, proběhne standardní dvoukolový výběr, jsou oslovení moţní dodavatelé, po zaslání jejich nabídek jsou na základě hrubého výběru vybraní 3 dodavatelé, po zpřesnění scope a cenových nabídek proběhne jemný výběr, na základě kterého je vybrán vítězný dodavatel, s kterým je sepsána smlouva o dodávce. ICT útvar nemá dostatečné zdroje a zkušenosti s vývojem poţadovaných produktů a funkcionalit, proto se projekt rozhodl pořídit jiţ existující produkty. Dalším důvodem byla potřeba certifikace pro poţadavky normy PCI DSS, v případě interního vývoje by projekt musel projít dalšími koly certifikací, coţ vnáší nejistý prvek (finanční náklady, projektové termíny) do projektu a ve výsledku by celý projekt v případě nezískání certifikace mohl ohrozit. Další problémem, který řešil projektový tým, byl způsob implementace změn v dotčené Oracle databázi. Projekt vybírá z následujících variant. Kompletní dodávka na “na klíč“ od dodavatele databáze firmy Oracle. Implementace poţadovaných produktů a funkcionalit zvoleným systémovým integrátorem firmou Wincor Nixdorf. Implementace poţadovaných funkcionalit interními ICT týmy. Vzhledem k finanční náročnosti prvních dvou variant projekt rozhodl, ţe poţadované funkčnosti budou implementovat útvary ICT. V případě problémů pak budou konzultovat dodavatele v rámci provozní podpory. V rámci otestování této zvolené moţnosti bude proveden proof of concept zavedení poţadavků normy PCI DSS na databázi ASR, kterou provede databázový tým. Na základě zvolených řešení uzavírá projektový vedoucí (ve spolupráci s Útvarem nákupu) smlouvu o nákupu licencí s dodavatelem. V rámci interních procesů pak poţádal o alokaci potřebných ICT týmů.

75

3.8.4

Etapa III – realizace řešení

Po uzavření smluv o způsobu dodávky přichází na řadu implementační fáze. Termíny jednotlivých instalací jsou určeny projektovým plánem, na jejich dodrţování dohlíţí projektový manaţer. Dohlíţí zároveň i na průběţné čerpání kapacit projektu. V této práci budu popisovat pouze provádění akcí na databázi ASR, neboť zmapování veškerých prací na celém systému ASR jde daleko za rámec této práce. Jednotlivé kroky na databázi ASR budou prováděny v následujícím pořadí. Instalace v kapacitním prostředí – v rámci potřeb projektu vznikne kopie produkčního prostředí. o Prostředí bude zupgradováno na poslední verzi databáze (11.2.0.3). o Budou provedeny dodatečná nastavení bezpečnosti podle poţadavků normy, kromě databáze bude zabezpečen i operační systém. o Nastavení TDE, tabulka obsahující citlivé údaje bude převedena do šifrovaného tabulkového prostoru. o Bude nastaven DV. o Bude nastaven AV nebo jiný způsob zpracování auditních záznamů. o Bude proveden BR test. o Bude proveden základní penetrační test. o Bude proveden základní kapacitní test. Instalace ve vývojově integračním prostředí. o Prostředí bude zupgradováno na poslední verzi databáze (11.2.0.3). o Budou provedeny dodatečná nastavení bezpečnosti podle poţadavku normy, kromě databáze bude zabezpečen i operační systém. o Nastavení TDE, tabulka obsahující citlivé údaje bude převedena do šifrovaného tabulkového prostoru. o Bude nastaven DV. o Bude nastaven AV nebo jiný způsob zpracování auditních záznamů. Instalace v akceptačním prostředí.

76

o Prostředí bude zupgradováno na poslední verzi databáze (11.2.0.3). o Budou provedeny dodatečná nastavení bezpečnosti podle poţadavku normy, kromě databáze bude zabezpečen i operační systém. o Nastavení TDE, tabulka obsahující citlivé údaje bude převedena do šifrovaného tabulkového prostoru. o Bude nastaven DV. o Bude nastaven AV nebo jiný způsob zpracování auditních záznamů. o Bude proveden kapacitní test systému cílem zjistit, zda se pouţité bezpečnostní prvky neprojeví zásadně negativně na zátěţi a průchodnosti systému. K testu bude vyuţita kombinace aplikační a simulované zátěţe pomocí Oracle RAT42. o Bude proveden základní funkční a akceptační test (UAT), v případě akceptace výsledků bud řešení posunuto do produkce. Instalace v produkčním prostředí během migračního víkendu. o Prostředí bude zupgradováno na poslední verzi databáze (11.2.0.3). o Budou provedeny dodatečná nastavení bezpečnosti podle poţadavku normy, kromě databáze bude zabezpečen i operační systém. o Nastavení TDE, tabulka obsahující citlivé údaje bude převedena do šifrovaného tabulkového prostoru. o Bude nastaven DV. o Bude nastaven AV nebo jiný způsob zpracování auditních záznamů. o Budou provedeny aplikační smoke testy43, penetrační testy (schváleným vzdorem podle PCI DSS poţadavků) a DRP testy44. o Pilotní provoz. V rámci akceptace řešení do provozu bude vypracována provozní dokumentace, zaškolen personál a nastaveny standardní procesy platné pro produkční prostředí.

42

Oracle RAT – Oracle Real Application Testing umoţňuje nahrát provozní zátěţ systému (capture) a přehrát (replay) ji na cílovém systému, případně zanalyzovat exekuční plány SQL příkazů 43 Smoke test – „zahořovací“ test, test základní funkcionality po nasazení změny 44 DRP test – Disater Recovery Plan test neboli test havarijního plánu systému

77

3.8.5

Etapa IV – Provoz a údrţba databázového systému

Inovovaný systém postupně přejde z pilotního provozu do standardního provozu a budou nastaveny platné provozní postupy, které řeší následující poţavky. Provozní monitoring – systém je pravidelně kontrolován a udrţován pověřeným týmem databázové podpory, k monitoringu se vyuţívají interní kontroly na bázi skriptů a nepřetrţité sledování pomocí agenta Oracle Grid Control, vybrané události jsou formou SNMP45 trapů odesílány do dohledového centra (dostupnost databáze a jejích komponent, informace o přetíţení systému, informace o závaţných chybách). Bezpečnostní monitoring – auditní záznamy jsou odesílány z databáze do určeného úloţiště, kde jsou zpracovány a kontrolovány, na základě zachyceného problému se startuje definovaný proces řešení (upozornění, bezpečnostní incident,…). Problematiku uţivatelských účtů – je definován a dodrţován proces pokrývající ţádost uţivatele o přístup do databáze, schvalovací proceduru a následnou kontrolu chování uţivatele v systému. Pro transparentnost je pouţit systém ITIM46, ţádost o účet uţivatele zakládá jeho vedoucí a do schvalovací procedury je zahrnut i aplikační gestor a správce systému. V případě schválení ITIM učet automaticky zaloţí. ITIM v naší organizaci zajišťuje celý user management. Údrţbu systému – správce systému udrţuje celý systém v chodu, řeší problémy, ladí výkon a udrţuje softwarové vybavení v aktuálním stavu. V naší organizaci se databáze pravidelně upgradují na nejnovější stabilní verze a jsou pravidelně záplatovány čtvrtletními PSU47 a nutnými one-off záplatami. Řízení změn (change management) – proces zavádění změn je popsaný a dodrţovaný, pro podporu procesu je vyuţíván modul Release Change aplikace HP Service Center48. Vedení provozního deníku – pečlivé zaznamenávání provozních událostí. Řízení problémů a incidentů (incident management) – proces řízení řešení incidentů je popsán a dodrţován, pro evidenci problémů je vyuţíván modul Incident aplikace HP Service Center. 45

SNMP – Simple Network Management Protocol ITIM – IBM Tivoli Identity Manager 47 PSU – Patch Set Update – kumulativní záplata obsahující i CPU (Critical Patch Update) 48 HP Service Center – program z rodiny produktů HP OpenView pro system and network managent IT společností 46

78

Dostupnost systému – je pravidelně kontrolována a její úroveň je definována v SLA49 ICT organizace s obchodním útvarem, v rámci plnění SLA jsou pravidelně prováděny testy DRP. Auditní kontroly – systém podléhá kaţdoroční auditní kontrole, kterou provádí útvar IRM50 a dále také externí auditorská firma. Na základě provedené kontroly a zjištěných auditních nálezů je správce systému povinen realizovat nápravná opatření.

49 50

SLA -Service Level Agreement – smlouva o garantované úrovni sluţeb IRM – Information Risk Management – útvar interní bezpečnosti

79

3.9 Praktická realizace PCI DSS na databázi V rámci druhé etapy projektu (Plánování a výběr) bude ověřen záměr nastavení bezpečnostních prvků databáze podle poţadavků PCI DSS proof of concept. Tento test bude vycházet z poţadavků QSA, v našem případě zastoupeného firmou Wincor Nixdorf, na zajištění databázového systému ASR tak, aby splňoval normu PCI-DSS. 3.9.1

Databázová instalace

Instalace databázového software proběhla podle standardního popsaného postupu. Klon databáze. Obrázek č. 17: Klon databáze

Zdroj: Vlastní úprava

V rámci testu bylo rozhodnuto, ţe nesmí být afektováno ţádné standardní prostředí. Z tohoto důvodu padlo rozhodnutí provést test na určeném vývojovém serveru, kam bude RMAN funkcionalitou proveden databázový klon z akceptační databáze ASR. Upgrade databáze pomocí DBUA51.

51

DBUA – Database Upgrade Assistent - GUI nástroj pro upgrade oracle databáze

80

Obrázek č. 18: Upgrade databáze 1

Zdroj: Vlastní úprava Obrázek č. 19: Upgrade databáze 2

Zdroj: Vlastní úprava

Stávající akceptační databáze ASR je stále na verzi 10.2.0.5, coţ neodpovídá poţadavkům a zároveň v červenci 2012 vyprší zvláště placená licence Extended Support. Bylo proto

81

rozhodnuto o upgradu na poslední verzi 11.0.2.3. Upgrade byl proveden GUI nástrojem DBUA a proběhl bez problémů. Nahrání aktuálních záplat. Obrázek č. 20: Nahrání záplat

Zdroj: Vlastní úprava

Do databáze byl aplikován poslední dostupný PSU kumulativní patch verze 11.2.0.3.1 obsahující poslední CPU JAN2012 a šest specifických one-off patchů. Konfigurace databáze. V rámci konfigurace databáze podle standardního postupu proběhlo. o Vytvoření standardní OPS uţivatele, který je pouţíván pro automatické údrţbové procedury. o Aktivace auditu, nastavení poţadovaných parametrů, údrţbové procedury, nastavení úlohy v plánovači (scheduler job). o Nastavení partitioningu, parametrických tabulek, procedur a úloh v plánovači. o Vytvoření verify function podle bezpečnostních poţadavků. o Vytvoření databázových profilů (DEFAULT, DBA, SECURITY, APPL) s příslušnými restrikcemi podle bezpečnostních poţadavků. 82

o Vytvoření aplikačního uţivatele pro tvorbu auditních sestav. o Nastavení AWR52 a inicializačních parametrů. o Nastavení ACL na systémové UTL procedury. o Uzamčení systémových účtů a změna defaultních hesel. o Validace objektů a restart databáze, aby se promítla změna inicializačních parametrů. o Spuštění kontrolního skriptu. Obrázek č. 21: Konfigurace databáze

Zdroj: Vlastní úprava

Dodatečná instalace komponent Oracle Label Security a Oracle Database Vault. Po dodatečném ověření poţadavků na funkčnost Oracle DV bylo rozhodnuto o oddělení softwarové instalace a byla vytvořena speciální, pouze pro potřeby proof of concept testu. Rámci nové instalace softwaru byly doinstalovány komponenty DV a OLS, které nejsou standardní součástí Enterprise edice, navíc při testech DV je vyţadován relink komponent, coţ by v případě sdíleného programového vybavení ovlivnilo i ostatní databáze na vývojovém prostředí. Nakonec bylo provedeno opětovné opatchování PSU Jan2012 a 6 one-off patchi. 52

AWR – Authomatic Workload Report – součást Oracle Diagnostic Pack), náhrada Statspack reportů

83

Obrázek č. 22: Dodatečná instalace komponent OLS a DV

Zdroj: Vlastní úprava

Vytvoření walletu. Obrázek č. 23: Vytvoření walletu

Zdroj: Vlastní úprava

Následně byl vytvořen adresář pro wallet a vytvořen primární šifrovací klíč a nastavena příslušná práva na soubor v OS. Informace o umístění klíče je přítomna v sqlnet.ora. Vytvoření šifrovaného tabulkového prostoru.

84

Obrázek č. 24: Vytvoření šifrovaného tabulkového prostoru

Zdroj: Vlastní úprava

V dalším kroku byl vytvořen šifrovaný tabulkový prostor a ověřeno otevírání walletu. Přesun objektů do šifrovaného tabulkového prostoru. Obrázek č. 25: Přesun určených objektů do šifrovaného tabulkového prostoru

Zdroj: Vlastní úprava

Citlivé údaje (PAN) se nacházejí v tabulce PRF.TRANSACTION. Tato tabulka byla přesunuta do šifrovaného tabulkového prostoru PRF_DATA_ENC. Spolu s ní byl přesunut

85

i primární klíč a index. V nešifrované části databáze se nenacházejí ţádná další data obsahující PAN. Test šifrování. Obrázek č. 26: Ověření přístupu na šifrovanou tabulku

Zdroj: Vlastní úprava

V případě, ţe není dostupný primární šifrovací klíč, není moţné získat informace v otevřené podobě. Test tedy ověřoval moţnost dotazu nad šifrovanou tabulkou v případě, ţe není dostupný šifrovací klíč nebo není otevřený wallet. Při uzavřeném walletu dostane uţivatel chybu, po otevření walletu jsou poţadovaná data zobrazena. Nastavení automatického otevření walletu. Pro běţný provoz je třeba zautomatizovat otevírání walletu. Není moţné klíč uloţit ve startovacím skriptu databáze. Pro tyto účely se pouţívá utilita ORAPKI.

86

Obrázek č. 27: Nastavení automatického otevření walletu

Zdroj: Vlastní úprava

Běţně dostupné materiály uvádějí zpomalení dotazů nad šifrovanou tabulkou o 5-10%. Konkrétní výsledky jsou závislé na povaze šifrovaných dat, na pouţité síle šifrovacího klíče a na HW konfiguraci serveru. Šifrování síťové komunikace mezi aplikačním serverem a databázovým serverem. Podle dohody s QSO není nutné šifrování síťové komunikace implementovat, neboť komunikace mezi databází a aplikačním serverem probíhá v uzavřeném síťovém prostředí banky a není tedy nezbytně nutné tuto komunikaci šifrovat. Šifrování záloh. V dalším kroku proběhlo šifrování databázové zálohy pomocí utility RMAN na disk (set encryption on). V produkčním prostředí se předpokládá implementace OSB53.

53

OSB – Oracle Secure Backup

87

Obrázek č. 28: Šifrování zálohy databáze

Zdroj: Vlastní úprava

Databázová instalace DV a OLS. Obrázek č. 29: Databázoví instalace DV a OLS

Zdroj: Vlastní úprava

Kromě instalace softwarového vybavení OLS a DV je nutné doinstalovat pomocí DBCA i databázovou část. Během instalace je nutné zadat silné heslo na vlastníka DV (Database 88

Vault Owner) a správce účtů (Account Manager) skládající se z 8-30 znaků (minimálně 1 písmeno, 1 číslice a 1 speciální znak). Konfigurace DV a zavedení granularity přístupových oprávnění. Obrázek č. 30: Test DV

Zdroj: Vlastní úprava

Za normální situace dokáţe SYS uţivatel vytvářet a měnit databázové účty bez omezení, stejně jako ostatní uţivatelé s DBA rolí. Po instalaci DV se rapidně změnila situace, uţivatel SYS ztratil právo měnit status účtu a nově ho získal správce účtů (account manager). Poté, co vlastník DV vytvoří nový realm PROT_TABLE a vloţí do něho aplikační tabulku, ztratí uţivatel SYS a ostatní administrátorské účty přístup k této tabulce. Standardně má k tabulce přístup vlastník schématu a aplikační uţivatel s přidělenými objektovými právy. Tato nová situace je zobrazena na obrázcích č. 31 a č. 32.

89

Obrázek č. 31: Nastavení realmu

Zdroj: Vlastní úprava Obrázek č. 32: Test přístupu k aplikační tabulce

Zdroj: Vlastní úprava

90

Obrázek č. 33: Zobrazení pokusů o neoprávněný přístup

Zdroj: Vlastní úprava

Ovládat DV je moţné SQL příkazy, ale správce DV a správce účtů mohou administrovat DV také přes Database nebo GRID Control, jak je znázorněno na obrázku č. 33. Nastavení row-level security. Pouţití DV je často kombinováno s bezpečnostními produkty, které mají za úkol další zpřesnění přístupových práv (VPD, OLS). V tomto případě další dělení nemá opodstatnění, neboť se jedná o logovací tabulku s čísly kreditních karet. Pověření analytici i aplikační účty musejí mít přístup ke všem datům v tabulce. Ochrana auditních záznamů a jejich skladování na bezpečném místě. V produkčním prostředí bude implementováno nastavení zápisu auditních dat do SYSLOGu operačního systému a tyto auditní záznamy budou následně přesouvány na ArcSight server, kde budou dohledovým centrem vyhodnocovány. Administrátor databáze tak ztratí moţnost auditní záznamy prohlíţet a případně měnit. 3.9.2

Vyhodnocení proof of conceptu

V rámci testů nastavení databáze podle poţadavků PCI DSS nebyl shledán ţádný závaţný problém, který by neumoţňoval provést změny v ostatních standardních prostředích. Databázi se podařilo úspěšně zupgradovat na poslední dostupnou verzi, provést u ní základní poţadované zabezpečení, přesunout určené objekty do šifrovaného tabulkového prostoru, nastavit proces otvírání walletu a nastavit šifrování záloh. Instalací a nastavením DV byla splněna podmínka separace práv.

91

Závěr Cíle této diplomové práce je moţné rozdělit na dvě části související části. První, teoretická, si stanovila za cíl zmapovat existující moţnosti zabezpečení Oracle databázi a popsat pouţívané bezpečnostní prvky vyššího stupně zabezpečení. Druhá, praktická, si kladla formou ankety za cíl zmapovat úroveň bezpečnosti existujících databází a zjistit názory Oracle administrátorů na bezpečnostní problematiku. V druhé části se pak zabývá reálným projektem v bance, který v rámci poţadavků na certifikaci normy PCI DSS kromě jiných systémů řeší zvýšení zabezpečení databáze ASR, ve které jsou uloţeny informace z karetních transakcí v nešifrované podobě, coţ je v zásadním rozporu s jiţ zmiňovanou normou. Přestoţe bance hrozí za nesplnění těchto poţadavků reálné sankce, neboť na aplikaci poţadované úrovně zabezpečení existuje právní nárok, a nehledě na nebezpečí skutečného bezpečnostního incidentu, který by na banku měl výrazně negativní finanční i reputační dopad, se banka rozhodla o odloţení projektu na pozdější dobu. Měla pro to několik důvodů, přes stále hrozící finanční problémy plynoucí z probíhající hospodářské krize aţ po fatální podcenění náročnosti implementace normy. Databázová část, jak mimo jiné prokázal uskutečněný test, sice byla schůdná technicky, ale projekt nepočítal s vysokou cenou za některé pouţité produkty. Některé poţadavky normy znamenají i nemalé organizační změny, například by mělo vzniknout dohledové centrum pro sledování auditních záznamů, rozdělení pravomocí způsobené implementaci technologie Database Vault zase vyţaduje vytvoření skupiny bezpečnostních administrátorů. Celkově se projekt dále dostal do konfliktu s dalšími běţícími projekty globální ICT skupiny (například unifikací pracovních stanic pro všechny dceřiné společnosti, globalizací DNS a Active Directory serverů v rámci celé evropské ICT skupiny). Díky těmto skutečnostem se mu stále nekontrolovatelně rozrůstal počet systémů, který musel v rámci přípravy certifikace na PCI DSS zabezpečit. S rozvojem nových platebních kanálů a stále se rozšiřujících moţností, jak klienti online pracují se svými účty, se banka nevyhne nutnosti přizpůsobovat své systémy na vyšší úroveň bezpečnosti. 92

Lze tedy očekávat, ţe budoucnost patří posilování zabezpečení bankovních systému a plněním nových bezpečnostních poţadavků a norem. Minimálně z tohoto pohledu tedy vynaloţená práce při zabezpečení databáze ASR měla smysl, neboť ukázala schopnost ICT útvarů tuto výzvu zvládnout.

93

Seznam pouţité literatury Kniţní zdroje: [1] BASL, J.; BLAŢÍČEK, R. Podnikové informační systémy: podnik v informační společnosti. Praha: Grada Publishing, 2008. 285 s. ISBN 978-80-247-2279-5. [2] BRYLA, B.; LONEY, K. DBA Handbook:Oracle Database 11g. The McGraw-Hill Companies, 2008. ISBN 978-0-07-149663-6. [3] BRYLA, B.; LONEY, K. DBA Handbook:Oracle Database 10g. The McGrawHill/Osborne, 2005. ISBN 0-07-223145-9. [4] BRYLA, B.; LONEY, K. Mistrovství v Oracle Database 11g. Brno: Computer Press, 2009. ISBN 978-80-251-1289-4. [5] LONEY Kevin. Oracle Database: Kompletní průvodce. Brno: Computer Press, 2010. ISBN 978-80-251-2489-5. [6] SOLAŘ Tomáš. Oracle Database 11g Hotová řešení. Brno: Computer Press, 2010. ISBN 978-80-251-2886-2. [7] THERIAULT, M.; NEWMAN, A. Bezpečnost v Oracle. Brno: Computer Press, 2004. ISBN 80-722-6979-8. Internetové zdroje: [8]

ANAND, Sanjit. Oracle Advanced Security: TDE (Transparent Data Encryption). OracleApps Epicenter [online]. 2011 [cit. 2012-02-28]. Dostupné z WWW: http://www.oracleappshub.com/category/oracle-application/security

[9]

COBIT 4.1: Framework for IT Governance and Control. ISACA [online]. 2012 [cit. 2012-04-06]. Dostupné z WWW: http://www.isaca.org/Knowledge-Center/COBIT/Pages/Overview.aspx

94

[10] ČERMÁK, Miroslav. PCI DSS: konkrétní bezpečnostní opatření. CleverAndSmart [online]. [cit. 2012-04-01]. Dostupné z WWW: http://www.cleverandsmart.cz/pci-dss-konkretni-bezpecnostni-opatreni/ [11] ČERMÁK, Miroslav. COBIT. CleverAndSmart [online]. [cit. 2012-04-07]. Dostupné z WWW: http://www.cleverandsmart.cz/cobit-tajemstvi-zbaveny/ [12] ITIL. ITIL [online]. 2012 [cit. 2012-02-07]. Dostupné z WWW: http://www.itil.cz/index.php?id=982 [13] ITIL. ITIL [online]. 2012[cit. 2012-02-07]. Dostupné z WWW: http://www.itil-officialsite.com/home/home.aspx [14] Oracle® Database Administrator's Guide (11.2). Oracle Database Documentation Library [online]. 2012 [cit. 2012-04-01]. Dostupné z WWW: http://docs.oracle.com/cd/E11882_01/server.112/e25494/toc.htm [15] Oracle® Database Security Guide11g Release 2. Oracle Database Documentation Library [online]. 2012 [cit. 2012-01-25]. Dostupné z WWW: http://docs.oracle.com/cd/E11882_01/network.112/e16543/toc.htm [16] Oracle® Database Advanced Security Administrator's Guide (11.2). Oracle Database Documentation Library [online]. 2012 [cit. 2012-01-24]. Dostupné z WWW: http://docs.oracle.com/cd/E11882_01/network.112/e10746/toc.htm [17] Overview. PCI Data Security Standards. [online]. [cit. 2012-04-01]. Dostupné z WWW: https://www.pcisecuritystandards.org/organization_info/index.php [18] COBIT. Wikipedia [online]. [cit. 2012-04-07]. Dostupné z WWW: http://cs.wikipedia.org/wiki/COBIT Podklady k přednáškám [19]

ŠEBEK, Václav. Projektové řízení. Praha, 2011. Podklady k předmětu M108RPP. Bankovní institut vysoká škola Praha.

Vysokoškolská kvalifikační práce: [20] HOLÝ, Luděk. Ochrana dat Oracle databázového stroje. Praha, 2010. 53 s. Bakalářská práce. Bankovní institut vysoká škola Praha. 95

Definice, akronymy a zkratky ACL

Access Control List

AES

Advanced Encryption Standard

AQ

Oracle Advance Queueing

ASM

Automatic Storage Management

BR

Backup/ Recovery

COBIT

Control Objectives for Information and related Technology

CPU

Critical Patch Update

CRS

Oracle Cluster Ready Services

DBCA

Database Configuration Assistent

DBUA

Database Upgrade Assistent

DCE

Distributed Computing Environment

DCL

Data Control Language

DDL

Data Definition Language

DES

Data Encryption Standard

DML

Data Manipulation Language

FGA

Fine Grained Auditing

GUI

Grafical User Interface

HA

High Availibility

HS

Heterogeneous Services

ICT

Information and Communication Technologies

ITIL

Information Technology Infrastructure Library

ITIM

IBM Tivoli Identity Manager

LVM

Logical Volume Mirroring

MAA

Oracle Maximum Availibility Architecture

OASO

Oracle Advanse Security Option

OAV

Oracle Audit Vault

ODF

Oracle Database Firewall

ODM

Oracle Data Masking

ODV

Oracle Database Vault

OIM

Oracle Identity Manager

OLS

Oracle Label Security

96

OLTP

Online Transaction Processing

OSB

Oracle Secure Backup

PAN

Primary Account Number

PCI DSS

Payment Card Industry Data Security Standard

PKI

Public Key Infrastructure

PL/SQL

Procedural Language/Structured Query Language

PSU

Oracle Patch Set Update

QSA

Qualified Security Assessor

RAC

Real Application Clusters

RADIUS

Remote Authentication Dial-In Service

RAT

Oracle Real Application Test

RMAN

Recovery Manager

SAN

Storage Area Network

SGA

Systém Global Area

SLA

Service Level Agreement

SNMP

Simple Network Management Protocol

SSL

Secure Socket Layer

SSO

Single Sign-on

SWOT

Strengths, Weaknesses, Opportunities, and Threats

TDE

Transparent Data Encryption

VPD

Virtual Private Database

VTL

Virtual Tape Library

97

Seznam pouţitých obrázků: Obrázek č. 1: Diagram autentizačních metod ........................................................................... 17 Obrázek č. 2: Příklad profilu .................................................................................................... 21 Obrázek č. 3: Vyuţití databázových rolí .................................................................................. 24 Obrázek č. 4: Oracle Label Security ......................................................................................... 33 Obrázek č. 5: Oracle Audit Vault ............................................................................................. 35 Obrázek č. 6: Schéma Oracle TDE........................................................................................... 36 Obrázek č. 7: Šifrování komunikace ........................................................................................ 37 Obrázek č. 8: Seznam poţadavků PCI DSS 2.0 ....................................................................... 41 Obrázek č. 9: Ověřovací tabulka .............................................................................................. 42 Obrázek č. 10: ITIM rámec ...................................................................................................... 44 Obrázek č. 11: COBIT .............................................................................................................. 47 Obrázek č. 12: Porovnání zabezpečení databází ...................................................................... 56 Obrázek č. 13: Porovnání počtu zneuţití dat ............................................................................ 57 Obrázek č. 14: Porovnání zneuţití dat podle typu dat .............................................................. 57 Obrázek č. 15: Otisk obrazovky s průzkumem na docs.google.com ........................................ 58 Obrázek č. 16: Ţivotní cyklus projektu .................................................................................... 72 Obrázek č. 17: Klon databáze ................................................................................................... 80 Obrázek č. 18: Upgrade databáze 1 .......................................................................................... 81 Obrázek č. 19: Upgrade databáze 2 .......................................................................................... 81 Obrázek č. 20: Nahrání záplat .................................................................................................. 82 Obrázek č. 21: Konfigurace databáze ....................................................................................... 83 Obrázek č. 22: Dodatečná instalace komponent OLS a DV..................................................... 84 Obrázek č. 23: Vytvoření walletu ............................................................................................. 84 Obrázek č. 24: Vytvoření šifrovaného tabulkového prostoru................................................... 85 Obrázek č. 25: Přesun určených objektů do šifrovaného tabulkového prostoru ...................... 85 Obrázek č. 26: Ověření přístupu na šifrovanou tabulku ........................................................... 86 Obrázek č. 27: Nastavení automatického otevření walletu ...................................................... 87 Obrázek č. 28: Šifrování zálohy databáze ................................................................................ 88 Obrázek č. 29: Databázoví instalace DV a OLS ...................................................................... 88 Obrázek č. 30: Test DV ............................................................................................................ 89 Obrázek č. 31: Nastavení realmu .............................................................................................. 90 Obrázek č. 32: Test přístupu k aplikační tabulce...................................................................... 90 Obrázek č. 33: Zobrazení pokusů o neoprávněný přístup ........................................................ 91

Seznam pouţitých tabulek: Tabulka č. 1: SWOT analýza.................................................................................................... 73

98

Přílohy Příloha č. 1: Hodnocení shody s PCI DSS Příloha č. 2: COBIT domény Příloha č. 3: Oracle Security Alert

99

Příloha č. 1 Hodnocení shody s PCI DSS.

Hodnocení shody se standardem PCI DSS probíhá v následujících oblastech[10]. Vybudování a udrţení bezpeční sítě. o Poţadavek č. 1: Instalovat a udrţovat konfiguraci firewallů k ochraně dat drţitelů – vyţaduje instalaci a konfiguraci firewallů, nastavení definovaných pravidel, udrţování dokumentace, popis odpovědností, definování procesu změn a pravidelné kontroly (minimálně co šest měsíců). o Poţadavek č. 2: Nepouţívat pro systémová hesla a jiné bezpečnostní parametry výchozí nastavení od dodavatele – vyţaduje změnu defaultních hesel, zákaz nepouţívaných sluţeb, deinstalaci nepotřebných komponent, změny nastavení základních bezpečnostních parametru na vyšší stupeň zabezpečení, šifrovat administrativní přístupy (SSH), nesdílet prostředí pro další sluţby. Ochrana dat drţitelů karet. o Poţadavek č. 3: Chránit uchovávaná data drţitelů karet - vyţaduje, aby byla uchovávána pouze nezbytná data a po nezbytnou dobu, maskovat nebo zkracovat data při komunikaci, pouţívat pouze silná kryptografie. Správa klíčů by měla být popsána, šifrovací klíče by měly být bezpečně distribuovány, ukládány, likvidovány, měly by se periodicky měnit a přístup k nim by měl být omezen. Dešifrovací klíče nesmí být spojeny s uţivatelskými účty. o Poţadavek č. 4: Zašifrovat přenos dat drţitelů karet po otevřených veřejných sítích – vyţaduje nasazení silného šifrování, SSL/TLS nebo IPSEC protokol, zákaz implementace WEP. Číslo karty by nemělo být posíláno mailem apod. Provozování programu kontroly zranitelnosti. o Poţadavek č. 5: Pouţívat a pravidelně aktualizovat antivirový program - je vyţadováno nasazení ochrany proti škodlivému kódu, zajištění automatického update, kontroly a logování běhu těchto programů.

1

o Poţadavek č. 6: Vyvíjet a spravovat bezpečné systémy a aplikace – je vyţadováno, aby bylo programové vybavení stále obnovováno a záplatováno, pověření zaměstnanci musí neustále sledovat bezpečnostní situaci (bulletin, pravidelně vydávané zpravodaje), měly by být stanoveny zásady vývoje bezpečných aplikací, nasazování změn mělo dodrţovat bezpečnostní pravidla (oddělená prostředí a role, apod.). Zavedení důkladných opatření ke kontrole přístupu. o Poţadavek č. 7: Omezit přístup k datům drţitelů karet jen podle potřeby – je vyţadováno, aby přístup k datům byl řízen na principu potřeby znalosti (need-to-know) a uţivatel disponoval pouze nezbytně nutnými právy. Zavedení systému kontroly přístupu. o Poţadavek č. 8: Přidělení jedinečného ID kaţdé osobě s přístupem do počítačového systému – je poţadováno zajištění unikátnosti přístupu uţivatele (ţádné sdílené účty), zavedení VPN přístupů a dvoufaktorové autentizace. Nastavení politiky hesel (změna kaţdých 90 dní, minimální délka 7 znaků, poţadavek na komplexnost hesla, nastavení historie hesel na hodnotu 4 a maximálně 6 pokusů o přihlášení, neţ dojde k uzamčení účtu na 30 minut). o Poţadavek č. 9: Omezit fyzický přístup k datům drţitelů karet – je vyţadováno, aby fyzický přístup k zařízením měla pouze skupina vybraných osob, kaţdá osoba by měla nosit viditelně visačku s označením, prostor ve výpočetním centru by měl být monitorován a autorizován (například tokenem či biometrikou), záznamy ze sledování osob by měly být bezpečně uchovávány minimálně po dobu tří měsíců. Pravidelné sledování a testování sítí. o Poţadavek č. 10: Sledovat a monitorovat všechny přístupy k síťovým zdrojům a datům drţitelů karet – je vyţadována specifikace nastavení auditingu, zamezení moţnosti úpravy auditních záznamů (například okamţitým přesunem mimo sledovaný systém do centrálního úloţiště). Auditní záznamy mají být chráněny, přístup k nim má mít úzká skupina lidí, mají být uchovávány po dobu jednoho roku a minimálně 1x denně vyhodnocovány. o Poţadavek č. 11: Pravidelné testování bezpečnostních systémů a procesů – je vyţadováno, aby se skenování zranitelnosti sítí prováděly interně i externě, 2

minimálně v 3 měsíčním intervalu a po kaţdé významné změně. Interní a externí penetrační testy se mají provádět minimálně 1 ročně a téţ po kaţdé významné změně. Analýza IDS/IPS by měla proběhnout minimálně kaţdé čtvrtletí. Udrţování pravidel pro bezpečnost informací. o Poţadavek č. 12: Udrţovat pravidla zaměřená na bezpečnost informací pro zaměstnance a dodavatele – je vyţadováno, aby vznikla a byla udrţována bezpečnostní politika v souladu s principy PCI DSS a s ní související bezpečností standardy, minimálně 1x ročně by měla být prověřována. S touto politikou mají být seznámeni všichni zaměstnanci a minimálně kaţdý rok znovu proškolováni. Má vniknout pohotovostní plán reagující na případně narušení bezpečnosti a nastavit související procesy (dohledové centrum). Má vzniknout program monitorující program Shody s PCI DSS poskytovatele sluţeb. Kromě výše popsaných poţadavků obsahuje PCI DSS ještě přílohy, ve které jsou uvedeny další poţadavky (například dodatečné poţadavky PCI DSS na poskytovatele sdíleného hostingu – Shared Hosting Providers).

Zdroj: vlastní úprava

3

Příloha č. 2 COBIT domény Plánování a organizace (Plan and Organise) – 10 procesů: PO1 Define a strategic IT plan. PO2 Define the information architecture. PO3 Determine technological direction. PO4 Define the IT processes, organisation and relationships. PO5 Manage the IT investment. PO6 Communicate management aims and direction. PO7 Manage IT human resources. PO8 Manage quality. PO9 Assess and manage IT risks. PO10 Manage projects. Akvizice a implementace (Acquire and Implement) – 7 procesů: AI1 Identify automated solutions. AI2 Acquire and maintain application software. AI3 Acquire and maintain technology infrastructure. AI4 Enable operation and use. AI5 Procure IT resources. AI6 Manage changes. AI7 Install and accredit solutions and changes. Dodání a podpora (Deliver and Support) – 13 procesů: DS1 Define and manage service levels. DS2 Manage third-party services. DS3 Manage performance and capacity. DS4 Ensure continuous service. 1

DS5 Ensure systems security. DS6 Identify and allocate costs. DS7 Educate and train users. DS8 Manage service desk and incidents. DS9 Manage the configuration. DS10 Manage problems. DS11 Manage data. DS12 Manage the physical environment. DS13 Manage operations. Monitorování a vyhodnocování (Monitor and Evaluate) – 4 procesy: ME1 Monitor and evaluate IT performance. ME2 Monitor and evaluate internal control. ME3 Ensure compliance with external requirements. ME4 Provide IT governance.

Zdroj: vlastní úprava

2

Příloha č. 3 Oracle Security Alert

Zdroj: Oracle

1