Je třeba si uvědomit, že každý SW prochází zpravidla během svého vývoje několika různými prostředími. Běžně se jedná o vývojové, testovací a produkční prostředí. Vzhledem k tomu, že testovací prostředí se může ve velkých společnostech dále dělit na integrační a akceptační, jsme postaveni před poměrně nelehký úkol: zajistit zachování důvěrnosti, integrity a dostupnosti informačních aktiv během celého životního cyklu vývoje softwaru a to ve všech těchto čtyřech prostředích. Podívejme se nyní společně na největší rizika, kterým musíme čelit.

Riziko: narušení důvěrnosti

Hrozba: Únik důvěrných dat z vývojového a testovacího prostředí. Je zajímavé, že zatímco data v produkčním prostředí bývají velice často chráněna a společnosti vydávají nemalé prostředky na jejich ochranu, tak ve vývojovém a testovacím prostředí tomu tak není. Podle průzkumu, který provedla společnosti Compuware a organizace Ponemon Institute, používá většina společností při vývoji a testování aplikací skutečná data.

Opatření: Ve vývojovém a testovacím prostředím nepracovat s reálnými daty. Pokud je to možné, mělo by se provést jejich zneplatnění, např. formou kódování, scrambling, apod. V opačném případě musí být před přenesením skutečných dat do vývojového nebo testovacího prostředí zajištěn souhlas vlastníka. Vlastník by měl být s rizikem úniku důvěrných dat prokazatelně seznámen, toto riziko akceptovat a s testováním nad reálnými daty souhlasit. Podepisování nejrůznějších NDA je sice možné, ale v praxi vás to stejně před únikem důvěrných dat neochrání.

Riziko: narušení integrity

Hrozba: Neupravený konfigurační soubor může způsobit, že server z vývojového nebo testovacího prostředí bude komunikovat přímo se serverem z produkčního prostředí. Může se tak snadno stát, že např. požadavek na smazání vybraných záznamů se místo na DB serveru v testovacím prostředí provede na DB serveru v produkčním prostředí. Pokud se na tuto skutečnost nepřijde včas, může to mít pro společnost zcela katastrofální následky.

Opatření: Jako vhodné řešení se jeví oddělit od sebe vývojové, testovací a produkční prostředí a to tak, aby servery z jednoho prostředí nemohly komunikovat se servery z druhého prostředí.

Hrozba: Osoba s přístupem do produkčního i testovacího prostředí může provést úmyslný nebo úmyslný a z pohledu společnosti nežádoucí zásah do SW vybavení a dat

Opatření: Vývojářský tým by měl mít přístup pouze do vývojového a integračního prostředí, neboť nemá dělat nic jiného než unitní a integrační testy. Testovací tým by měl mít přístup zase jen do akceptačního prostředí.

Hrozba: Osoba s přístupem do více prostředí si může splést prostředí v jakém pracuje a provést nežádoucí změnu v SW vybavení a datech.

Opatření: Pokud chce společnost toto riziko co nejvíce eliminovat, je asi nejlepším řešením zablokovat uživateli po dobu testování přístup do konkrétní aplikace v produkčním prostředí a po skončení testů mu ho zase odblokovat. Vzhledem k tomu, že se každé testování velice pečlivě plánuje (předpokládám, že váš Plán testování obsahuje všechny náležitosti), tak kdo a kdy bude testovat je v dostatečném časovém předstihu známo a tak by pro vás neměl být problém účet testera do aplikace v produkčním prostředí zablokovat. Je na test managerovi, aby si ověřil a zajistil, že přístupy testerů do aplikace v testovacím prostředí jim budou aktivovány až poté, co jim bude zablokován přístup do aplikace v produkčním prostředí. Výhodou tohoto řešení je, že pracovník se nemusí nikam stěhovat a může testování provádět ze svého pracoviště. Tímto způsobem lze výrazně ušetřit, neboť není nutné budovat speciální pracoviště a vybavovat ho dalšími počítači, které by byly navíc mimo testování nevyužity.

Opatření: Přístup do testovacího prostředí umožnit jen z počítačů, které budou umístěny v chráněných a oddělených prostorách společnosti. Na takové pracoviště se bude muset pracovník před započetím testu dostavit. V praxi se bohužel ukazuje, že ani přesun pracovníka na jiný počítač není dostatečnou zárukou. Je možné si to vysvětlit tím, že většina kancelářských prostor vypadá úplně stejně, takže za chvíli pracovník už ani neví, kde že to vlastně sedí.

Opatření: Jednotlivá prostředí od sebe odlišit např. odlišnou barvou okna, změnou promptu, titulku okna, jiným pozadím pracovní plochy apod.. Bohužel, stejně jako v předchozím případě i zde se ukazuje, že toto opatření v praxi selhává, protože v okamžiku, kdy mají testeři současný přístup do více prostředí a mezi jednotlivými prostředími se přepínají, vždy se najde někdo, kdo se splete. Toto opatření lze nasadit snad jen jako doplněk k předchozím opatřením, samo o sobě riziko moc nesnižuje.

Riziko: narušení dostupnosti

Hrozba: Nežádoucí síťová komunikace iniciována servery z vývojového nebo testovacího prostředí může vést až k zahlcení produkčních serverů a síťové infrastruktury.

Opatření: Jako vhodné řešení se jeví oddělit od sebe vývojové, testovací a produkční prostředí. To lze provést např. za použití firewallů a nastavení příslušných pravidel spočívající v povolení komunikaci pouze pro konkrétní IP adresu, protokol a port.

Závěr: Je zajímavé, že ač společností investují nemalé prostředky do vybudování jednotlivých prostředí, tak jejich zabezpečení spočívající v implementaci vhodných opatření věnují minimální nebo vůbec žádnou pozornost. A jak výše uvedená rizika zvládáte vy ve vaší společnosti?

Related posts:

1. Testovací log
2. Testovací scénář
3. Testovací případ

Bezpečnost obecně je chápána jako ochrana něčeho před poškozením, zničením, ztrátou nebo zcizením. Informační bezpečnost si potom můžeme dle výše uvedené definice vyložit jako ochranu informace před poškozením, zničením, ztrátou nebo zcizením. V odborné literatuře se však místo poškození informace používá pojem narušení integrity, o zničení informace se hovoří jako o narušení dostupnosti a ztráta nebo zcizení informace zase bývá označována jako narušení důvěrnosti.

Abychom měli úplně jasno, měli bychom vědět z jakých částí se skládá informační systém. Uvažujme proto takto. DATA se obvykle nacházejí na nějakém MÉDIU (HD, CD, DVD, flash disk). Abychom s médiem mohli pracovat, potřebujeme k tomu nějaký HW (osobní počítač, server). Ten sám o sobě nestačí, musí na něm být nainstalován nějaký SW (OS, APLIKACE). Pokud mají být data přístupná pro více uživatelů, jsou obvykle uložena na nějakém serveru a přistupuje se k nim prostřednictvím SÍTĚ (LAN, MAN, WAN). Všechno je umístěno v nějakých PROSTORÁCH a  o celý systém se někdo stará a někdo ho používá. Ano, jsou to LIDÉ.

Mimochodem touto naprosto jednoduchou úvahou jsme vlastně provedli to, čemu se odborně říká dekompozice informačního systému a identifikace aktiv. Pokud vás napadají ještě nějaká další aktiva, vězte, že budou patřit do některé z těchto skupin:

• DATA
• MEDIA
• HW
• SW
• SÍŤ
• PROSTORY
• LIDÉ

Pokud máme zavést vhodná opatření k zajištění bezpečnosti informací, je zřejmé, že budeme muset odpovídajícím způsobem chránit všechna výše uvedená aktiva a zajistit bezpečnost informací během celého jejich životního cyklu. Podívejme se proto znovu na aktiva, která jsme si již identifikovali a zamysleme se nad tím, jak jejich bezpečnost zajistit.

Personální bezpečnost

Představují lidé, kteří IS spravují a používají, pro informace nějaké nebezpečí? Jistěže ano. Uvádí se, že až 80% bezpečnostních incidentů je způsobeno vlastními zaměstnanci. Z těchto důvodů je třeba vybírat kvalitní lidi, udržet si je, provádět jejich školení, hodnocení a v případě nutnosti se věnovat i jejich propouštění. Této problematice se věnuje personální bezpečnost.

Fyzická bezpečnost

V prostorách společnosti se nachází HW, média, lidé a ty je třeba chránit nejen před přírodními hrozbami, jako je například oheň nebo voda, ale i před fyzickými útočníky. Ochranu těchto hmotných aktiv má obecně na starost fyzická bezpečnost.

Logická bezpečnost

Ke zpracování dat je obvykle nutný nějaký SW, běžně se jedná o aplikaci, databázi a operační systém. Pokud má být zajištěna důvěrnost, integrita a dostupnost dat, je potřeba k nim řídit přístup, což má na starost logická bezpečnost.

Komunikační bezpečnost

Data jsou přenášena po síti a ta může být útočníkem odposlouchávána nebo může být zahlcena. Ochranu proti těmto hrozbám má na starost komunikační bezpečnost.

Organizační bezpečnost

Řízení bezpečnosti, ustanovení odpovědnosti a povinnosti jednotlivých skupin a osob v organizaci nejčastěji formou bezpečnostní politiky a bezpečnostních standardů má na starost organizační bezpečnost, někdy nazývaná též jako administrativní bezpečnost.

Z výše uvedeného vyplývá, že ochrana informací vyžaduje zavedení vhodných opatření na úrovni fyzické, logické, personální, komunikační a organizační bezpečnosti. To, jaká opatření by to přesně měla být, je možné zjistit jen na základě analýzy rizik, které bych se rád věnoval v některém svém dalším článku.

Related posts:

1. Informační bezpečnost: životní cyklus informace
2. Bezpečnost-náklady-použitelnost
3. Vývojové-testovací-produkční prostředí a rizika

Už jste někdy učinili rozhodnutí na základě informací uvedených ve spreadsheetu? Ať už jste na tuto otázku odpověděli kladně nebo záporně, měli byste si přečíst tento článek. Problém je v tom, že zatímco původní data jsou pořizována, zpracovávána a uchovávána v relativně bezpečných systémech, tak poté jsou exportována do velice zranitelných spreadsheetů, ve kterých lze velice obtížně zajistit požadovanou integritu. A je jedno, zda se jedná o spreadsheet vytvořený v produktu OpenOffice.org Calc nebo MS Excel. Je třeba si uvědomit, že v podstatě kdokoliv může ve spreadsheetech velice snadno provést jakoukoliv změnu, a to od prosté změny hodnot, až po změnu výpočetní logiky, která nebude nikde dokumentována. Spreadsheet je specifický právě tím, že obsahuje v jednom souboru jak vlastní data, tak i výpočetní logiku, tedy něco, co běžně bývá od sebe nějakým způsobem důsledně odděleno.

Spreadsheety jsou také velice často používány jako vstupní data pro vznik dalších spreadsheetů a nezřídka také dochází k propojování spreadsheetů mezi sebou, to znamená, že chyba v jednom se tak může velice rychle přenést i do dalších spreadsheetů. Spreadsheety jsou pak běžně používány napříč organizační strukturou. Nižší, střední i vrcholový management organizace je používá jako zdroj informací pro operativní, taktické a strategické řízení. Je zvláštní, že ač jsou na základě informací v nich uvedených činěna velice závažná rozhodnutí, není kvalitě spreadsheetů věnována dostatečná pozornost! Je asi zbytečné zdůrazňovat, že takovýto přístup může vést k chybným a nevratným rozhodnutím s velice vážnými následky. Většina společnosti si rizika spojená s používáním spreadsheetů neuvědomuje (v podstatě se jedná o nevědomou retenci rizik).

I u tvorby spreadsheetu je proto vhodné, stejně jako u vývoje jakéhokoliv jiného software, použít nějakou metodiku vývoje software, která obvykle začíná definicí požadavků, analýzou, návrhem, odsouhlasením, pokračuje vlastním vývojem, testováním a končí nasazením a údržbou. Možná vám to na první pohled připadá zbytečné, ale když si uvědomíte, pro koho jsou spreadsheety určeny, k čemu slouží, a jak složité výpočty se v nich často provádějí, tak zjistíte, že to až tak přehnané požadavky vlastně nejsou. Jsem přesvědčen, že v okamžiku, kdy zavítáte na stránky http://www.eusprig.org/stories.htm, kde jsou uvedeny skutečné příklady špatných rozhodnutí na základě informací uvedených ve spreadsheetech, nebudete už vůbec pochybovat o smyslu zavedení nějaké metodiky.

Minimálně byste měli stanovit závazná pravidla pro:

• vývoj a změnu spreadsheetů, resp. pro celý životní cyklus spreadsheet,
• testování, které by měla kromě autora provádět minimálně ještě jedna nezávislá osoba,
• pojmenování spreadsheetů, kde by již z názvu mělo být patrné jaké informace obsahuje,
• číslování verzí, často existuje tolik verzí, že nikdo neví, který spreadsheet je aktuální,
• evidenci spreadsheetů (jaké spreadsheety se vytváří, k čemu slouží, jaké je jejich úložiště, pro koho jsou určeny)
• zálohování a archivaci spreadsheetů,
• řízení přístupu ke spreadsheetům.

Dále byste měli zajistit, že

• součástí spreadsheetu bude vždy aktuální dokumentace – nejlépe na prvním listu,
• ve spreadsheetu bude uvedeno:
  • jméno autora spreadsheetu, – toho, kdo spreadsheet vytvořil a je odpovědný za jeho správnou funkčnost,
  • jméno vlastníka spreadsheetu – toho, kdo do spreadsheetu zadal data a je odpovědný za jejich správnost.
  • jaký je jeho klasifikační stupeň – např. tak jak jsme si uvedli v článku důvěrnost.
• veškeré změny ve spreadsheetu budou dokumentovány a auditovány.

Při vlastní tvorbě spreadsheetu je vhodné dodržovat tato pravidla:

• Navrhnout spreadsheet tak, aby bylo možné jej číst přirozeně, to znamená zleva doprava a shora dolů. Stejně tak listy v sešitu by měly jít za sebou v takovém pořadí, v jakém mají být čteny.
• Barevně od sebe odlišit buňky, do kterých se zadávají hodnoty, od těch ve kterých se zobrazují výsledky a kde probíhají výpočty. V legendě byste poté měli uvést, co jednotlivé barvy znamenají.
• V některý případech je vhodné mít jeden list pro zadávání hodnot, druhý list pro výpočty a třetí list pro zobrazení konečných výsledků.
• Pojmenovat buňky tak, aby jasně vystihovaly co je jejich obsahem.
• Konstanty uvádět v samostatných buňkách.
• Dlouhé vzorce raději rozdělit do více buněk.
• Provádět kontrolu hodnot na vstupu i na výstupu.
• Využívat možnosti komentáře v buňkách k popisu toho, co obsahují nebo výpočtu, který se v nich odehrává.
• Všechny buňky, do kterých se nezadávají hodnoty, zamknout a případně i chránit heslem, aby se zabránilo náhodnému nebo úmyslnému smazání či změně jejich obsahu.
• Pokud spreadsheet obsahuje makra, měla by být doplněna vhodnými komentáři a chráněna heslem, aby se zabránilo jejich náhodné nebo úmyslné nežádoucí modifikaci.

Odkazy:

http://www.eusprig.org/smbp.pdf – popisuje životní cyklus vývoje spreadsheetu v 6 fázích a to Scope->Specify->Design->Build->Test->Use

http://www.eusprig.org/hdykysir.pdf – obsahuje užitečné rady a praktické příklady včetně ukázek zdrojových kódů některých maker.

A na základě jakých informacích se rozhodujete vy? Jsou ve vaší společnosti zavedená některá výše uvedená pravidla? A dodržujete je?

No related posts.

Nežádoucí odhalení (Disclosure), modifikace (Alteration) nebo zničení (Destruction) určitých informací může vést k finanční ztrátě, poškození dobrého jména společnosti a v nejhorším případě i k ohrožení života jejich zaměstnanců nebo klientů. Z těchto důvodů je nutné informace před narušením důvěrnosti (Confidentality), dostupnosti (Availability) a integrity (Integrity) odpovídajícím způsobem chránit a to během celého jejich životního cyklu.

Vždy je třeba zvážit, jak vysoký stupeň ochrany si daná informace opravdu zaslouží.  tj. jaký soubor opatření na úrovni organizační, logické a fyzické bezpečnosti je třeba přijmout. Především proto, že zavedení těchto opatření bude něco stát a přinese určitá omezení při práci s informacemi. Stanovit skutečně odpovídající úroveň ochrany je možné jedině na základě detailní analýzy rizik. Vzhledem k tomu, že v praxi není dost dobře možné, aby si každý vlastník informace prováděl analýzu dopadů, hrozeb a zranitelností sám, protože na to většinou nemá čas a často ani odpovídající znalosti, je běžné, že vrcholový management společnost nechá za tímto účelem provést analýzu rizik.

Cílem takové analýzy je identifikace informací, které společnost zpracovává a dále určení hrozeb, které by mohly ohrozit důvěrnost, integritu a dostupnost těchto informací. Pro jednotlivé typy informací se poté na základě takto provedené analýzy rizik určí formou nějakého závazného dokumentu klasifikační stupně a zároveň se pro jednotlivé klasifikační stupně rozhodne o zavedení příslušných opatření, které musí všichni zaměstnanci dodržovat, aby byla zajištěna důvěrnost, integrita a dostupnost těchto informací.

Dostupnost a důvěrnost
Pokud budeme klást důraz jen na zajištění dostupnosti a důvěrnosti informací bez ohledu na zajištění jejich integrity, může dojít k situaci, že informace jsou sice oprávněné osobě dostupné v okamžiku, kdy je potřebuje, avšak tato osoba nemá žádnou záruku, že nedošlo k jejich nežádoucí modifikaci.

Veškerá pozornost byla soustředěna jen na zajištění dostupnosti a důvěrnosti a otázka integrity byla podceněna.

Důvěrnost a integrita
Pokud budeme klást důraz jen na zajištění důvěrnosti a integrity informací bez ohledu na zajištění jejich dostupnosti, může dojít k situaci, že informace jsou sice dostatečně chráněny proti nežádoucí modifikaci a vyzrazení, ale nejsou dostupné v okamžiku, kdy s nimi oprávněná osoba potřebuje pracovat.

Veškerá pozornost byla soustředěna jen na zajištění integrity a důvěrnosti a otázka dostupnosti byla podceněna.

Integrita a dostupnost
Pokud budeme klást důraz jen na integritu a dostupnost bez ohledu na zajištění důvěrnosti, můžeme se dostat do situace, že informace sice bude dostatečně chráněna proti nežádoucí modifikaci, ale dostane se i k osobě, která není oprávněna se s ní seznamovat.

Veškerá pozornost byla soustředěna jen na zajištění integrity a dostupnosti a otázka důvěrnosti byla podceněna.

Nyní se již můžeme zamyslet nad tím, jak souvisí požadavky na zajištění důvěrnosti, integrity a dostupnosti informací s předmětem podnikání a tedy i typem zpracovávaných informací a poskytovaných služeb. Z výše uvedeného vyplývá, že ve většině případů je třeba věnovat pozornost všem bezpečnostním atributům, ne vždy je však možné a efektivní věnovat všem atributům stejnou pozornost, protože každé opatření něco stojí. V praxi se tak klade na některý atribut větší důraz. Jako příklad si vezmeme např. transakční systém v bance. Je v celku logické, že bude kladen spíše větší důraz na integritu a dostupnost než na důvěrnost, to především proto, že veškeré transakce, které se uskutečňují v elektronické podobě, musí být správně a v požadovaném čase zaúčtovány. Důvěrnost je jistě také důležitá a její zajištění je navíc vyžadováno zákonem, nicméně možná ztráta plynoucí z narušení důvěrnosti je ve většině případů mnohem nižší, než ztráta způsobená narušením integrity nebo dostupnosti. Je tomu tak proto, že za únik informací o klientech nebo jejich transakcích, pokud se na to přijde, může být sice udělena pokuta, např. na základě série občanských stížností a rozhodnutí o náhradě škody, ale ta zdaleka nedosahuje výše možných ztrát v případě narušení integrity nebo dostupnosti.

Je třeba vzít v úvahu, že nejvyšší pokuta, kterou může úřad pro ochranu osobních údajů udělit právnické osobě je 5.000.000 Kč, v případě fyzické osoby 1.000.000 Kč. Položme si dále otázku, kolik pokut úřad za své existence jednotlivým firmám uložil a jaká byla výše těchto pokut. Zamysleme se také nad tím, jaká je nabídka a poptávka na trhu po produktech k zajištění dostupnosti a integrity a produktech pro zajištění důvěrnosti. Vezměme také v úvahu skutečnost, že zatímco v případě narušení dostupnosti informací se o tom jejich vlastník často hned dozví, tak v případě narušení integrity je šance na odhalení již mnohem nižší a v případě narušení důvěrnosti mohou informace z firmy dlouhodobě unikat a daná firma se o tom dokonce vůbec nemusí dozvědět, neboť konkurence těchto informací použije pro sebe. Lze se proto jen domnívat, že obdobný přístup k důvěrnosti, integritě a dostupnosti bude zaujímat nejspíš většina podniků, a nelze ho odmítat, protože má své jasné opodstatnění. Pokud jde o důvěrnost, ta je na prvním místě např. v armádě.

Poznámka: Důvěrnost (Confidentality), integrita (Integrity) a dostupnost (Availability) se označuje jako CIA triáda. Jejím opakem je DAD triáda: odhalení (Disclosure), modifikace (Alteration) nebo zničení (Destruction). Můžeme také říci, že vlastník usiluje o CIA a útočník o DAD.

Related posts:

1. CIA: Integrita
2. CIA: Dostupnost
3. CIA: Důvěrnost

O nežádoucí modifikaci (alteration) se proto v informační bezpečnosti hovoří jako o narušení integrity (Integrity). V případě integrity je třeba si uvědomit, že pokud dojde k nežádoucí změně dat, a to ať už úmyslně, náhodou, nebo technickým selháním v důsledku působení vyšší moci, nemusí být tato nežádoucí změna vůbec odhalena a může uplynout dlouhá doba, než si někdo něčeho všimne. Čím později se na tento bezpečnostní incident přijde, tím závažnější bude jeho dopad.

Problém spočívá v tom, že je velice obtížné dohledat jaký byl původní záznam, protože nebudeme vědět, kdy přesně ke změně došlo. Navíc změn může být mezitím provedeno několik, v takové situaci potom bude zhola nemožné dohledat, jaká byla původní hodnota. Na tomto místě je třeba také zdůraznit, že opatření určené pro zajištění dostupnosti jako je zálohování a archivace vám příliš nepomohou, protože daná poslední změna se bude pravděpodobně nacházet i na záložních a archivních médiích a vy pokud nebude mít k dispozici logy o činnostech v systému, nebude vědět, k jakému dni máte data obnovit.

Předpokládejme, že máme databázi pacientů, která obsahuje jejich osobní údaje, informace o prodělaných nemocech, ošetření apod. Předpokládejme, že nemocnice si je vědoma toho, že tato důvěrná data je třeba chránit a proto je při ukládání šifruje a řídí k nim přístup. Jak může být narušena integrita dat, když  jsou data šifrována? Mám na mysli nějaký složitější útok než ten, že útočník data poškodí, to by bylo moc jednoduché. Na takovýto bezpečnostní incident by se hned přišlo, protože data by se nepovedlo dešifrovat. Na první pohled se zdá, že pokud útočník nezná klíč, kterým jsou data šifrována, bude jakékoliv narušení integrity dat ihned odhaleno.

Útok však může být mnohem sofistikovanější, útočník může zjistit, např. podle názvů sloupců co je nejspíš jeho obsahem. Dále je třeba si uvědomit, že většinou se nešifrují všechny informace, ale i kdyby se šifrovaly, proti útoku, který má útočník v úmyslu provést by nám to stejně nepomohlo. Je třeba si uvědomit, že pokud se bude v daném sloupci nacházet stejná hodnota, bude i výsledek šifrování dané hodnoty stejný. Útočník tak vůbec nepotřebuje dešifrování provádět, on ani nepotřebuje vědět, co přesně je v daném poli uloženo za hodnotu! Útočník např. pouze prohodí zašifrovaný text ve sloupci krevní skupina u několika pacientů stejného věku, které se lečí u stejného doktora, nebo prohodí diagnózu, předepsané léky apod. Takováto změna by mohla  vést až k úmrtí a pokud ji útočník provede jen u malého procenta pacientů nemusí být jeho útok nikdy odhalen.

Jak se ale proti takovému útoku, spočívajícímu v narušení integrity, bránit? Nejjednodušší je auditovat všechny změny, aby bylo možné zjistit, kdy a kým byla změna provedena. Toto opatření by však mělo být použito pouze jako součást sady opatření. Jako vhodné řešení se jeví použití vícevrstvé architektury, kde data budou šifrována v aplikaci a do databáze budou ukládána v zašifrovaném tvaru, takže ani administrátor DB nebude vědět, co se v DB nachází za data. Před uložením dat do databáze by se pak pro vybraná data provedl v aplikaci kontrolní součet za použití jednocestné funkce např. SHA256, ten by se zašifroval a uložil do databáze. Aplikace by pak po načtení dat z databáze spočítala kontrolní součet a porovnala by ho s dešifrovaným kontrolním součtem uloženým v DB. Pokud by byl výsledek porovnání stejný, znamenalo by to, že data nebyla v databázi modifikována. Samozřejmě, že slabé místo se nám posunulo z databázové vrstvy na aplikační, protože ten kdo zná klíč použitý k šifrování, je schopen i data změnit. Nicméně dalo by se třeba uvažovat o použití nějaké ho HW modulu, který by šifrování prováděl.

Výše uvedený útok by mohl postihnout jakoukoliv společnost, tedy ne jen nemocnici. U společností, jejichž předmětem podnikání je nákup a prodej by se mohlo např. jednat o prohození adresy, což by mělo za následek, že zboží by občas přišlo někam jinam, než původně mělo. U banky mohlo dojít třeba ke změně kurzovního lístku a tím by se zrealizovaly obchody pro banku v nevýhodném kurzu. V armádním systému by mohlo dojít ke změně souřadnic vlastních a nepřátelských jednotek nebo ke změně barev signalizující oblasti, které jsou neutrální a oblastí, kde se nachází vlastní jednotky a nepřítel.

Poznámka: Tento článek se nesnaží přinést odpověď na otázku, jak data co nejlépe zabezpečit. Výše uvedený příklad slouží pouze pro ilustraci a aby si čtenář uvědomil, proč je zajištění integrity tak důležité.

Related posts:

1. CIA: Důvěrnost-Integrita-Dostupnost
2. CIA: Důvěrnost
3. CIA: Dostupnost