Security Management - Bezpečnost a ochrana utajovaných informací

Transkript

Security Management - Cesta k bezpeþné infrastruktuĜe IT
Computer Associates CZ, s.r.o.
PobĜežní 3, 186 00 Praha 8
1 Security Management
Jedním z nejdĤležitČjších IT témat je i nadále bezpeþnost. Podniky musí mnohem intenzivnČji než dĜíve chránit
rostoucí poþet rĤzných zdrojĤ a spravovat další interní a externí uživatele. SouþasnČ jsou vystaveni stále
poþetnČjším útokĤm a jiným z hlediska bezpeþnosti rozhodujícím jevĤm. Široké spektrum potenciálních
uživatelĤ informaþních zdrojĤ podnikĤ sahá od pracovníkĤ pĜes zákazníky a konkurenty až k obávaným
hackerĤm. Jednoduchý patchwork z bezpeþnostních kontrol proto již delší dobu nestaþí. Požadováno je spíše
obsáhlejší Ĝešení, které usnadĖuje proaktivní management bezpeþnostního prostĜedí. Odvracení útokĤ na
informaþní zdroje a udržení produktivity pracovníkĤ vyžaduje na všech úrovních bezpeþností infrastruktury
reakce zamČĜené na potĜeby. Jakmile bude instalováno, bude obsáhlé Ĝešení pro Security Management nabízet
nejrĤznČjší užitek: menší náklady, dobu výpadkĤ a ztráty produktivity a lepší dodržování smČrnic. Když podnik
ví, že jsou jeho informaþní aktiva a zdroje bezpeþné, mĤže se plnČ koncentrovat na svĤj obchodní provoz.
1.1
Bezpeþnost – souþást celku
Spoleþnost Computer Associates (CA) poskytuje svými eTrust Security Management Ĝešeními svou expertizu
v oblasti management softwaru také pro problémy dnešního managementu bezpeþnosti. Silný management
bezpeþnosti, jaký nabízí eTrust Security Management, je pĜedpokladem k zachování rozsáhlého pĜehledu o stále
komplexnČjších bezpeþnostních prostĜedích. Jde o to zajistit, aby bezpeþností data byla využitelná pro
rozhodnutí, v pĜípadČ potĜeby rychle získat odpovČdi na kritické otázky a na základČ tČchto odpovČdí moci cílenČ
a proaktivnČ jednat. To je cesta k ochranČ aktiv a informací celého podniku – nezávisle na obchodím modelu
nebo na struktuĜe podniku.
2 Nový standard pro Vaši bezpeþnost: management
eTrust Security Management Ĝešení od spoleþnosti CA nabízejí flexibilitu, která je nezbytná k pĜizpĤsobení
bezpeþnostních opatĜení obchodním požadavkĤm Vašeho podniku. Díky automatizaci, zjednodušení a racionalizaci procesĤ a také zviditelnČní reálného þasu mnoha každodenních bezpeþnostních jevĤ mohou být v pravý
þas pĜijímána ta pravá opatĜení. Tímto zpĤsobem se zvyšuje operativní efektivita a lze tlumit náklady a rizika.
SouþasnČ je zajištČno dodržování pĜedpisĤ.
K Ĝešením eTrust Security Management spoleþnosti CA patĜí oblasti Ĝešení eTrust™ Identity and Access
Management, eTrust™ Threat Management a eTrust™ Security Information Management. Tato Ĝešení nabízejí
celistvý základ pro všechny bezpeþností aspekty. Je možné je plynule vzájemnČ integrovat a spolupracovat s již
dostupnými bezpeþnostními systémy. Lze tak dosahovat dalších úspor nákladĤ a vylepšené úrovnČ bezpeþnosti.
eTrust Identity and Access Management
x
Nabízí efekty úspor.
x
Vylepšuje produktivitu uživatelĤ.
x
UsnadĖuje dodržování pĜedpisĤ.
S eTrust Identity and Access Management je možné prostĜednictvím zadávacích, implementaþních a kontrolních
funkcí efektivnČ spravovat identity uživatelĤ a pĜístupová oprávnČní. Digitální identity je možné spravovat po
celou dobu jejich životního cyklu. Dále jsou k dispozici nástroje jako automatizované pracovní postupy
a schvalovací procesy, pĜidČlování zdrojĤ na základČ uživatelĤ, zabezpeþený pĜístup, Single Sign-On a samosprávní funkce. Bezpeþnost aplikací, které jsou podnik kritické, je rozsáhle chránČna – nezávisle na provozním
systému, platformČ a podnikovém softwaru, a nezávisle na tom, zda zdroje pocházejí ze sítČ nebo jsou
distribuovány heterogenními systémy. eTrust Identity and Access Management Ĝešení nabízejí výkonné
kontrolní funkce pro dodržování bezpeþnosti dat, pro zabránČní neoprávnČným pĜístupĤm a pro dodržování
pĜedpisĤ. Centrální Ĝízení a konzistentní prosazování smČrnic podporuje redukci nákladĤ, operativní efektivitu
a snižování rizik. Tato Ĝešení navíc nabízejí nejsilnČjší dostupnou ochranu jak pĜed interními, tak i pĜed
externími narušeními bezpeþnosti a zajišĢují tak i dodržování pĜedpisĤ.
Security and Protection of Information 2005
141
eTrust Threat Management
x UmožĖuje proaktivní snižování rizik.
x Minimalizuje doby výpadkĤ systému.
x Krátké doby odezvy díky centrálnímu Ĝízení.
eTrust Threat-Management Ĝešení chrání Vaše systémy vysoce úþinnými preventivními opatĜeními a urychlenou
reakcí na bezpeþnostní události. NejmodernČjší technologie odvracejí viry, spamy a závadné obsahy, které
ohrožují Váš e-mailový styk a Vaše obchodní aplikace. Váš bezpeþností IT personál získává možnost
identifikovat ve Vaší infrastruktuĜe hrozby a slabá místa. Lze tak pĜijímat vhodná opatĜení k tomu, aby se
událostem dalo pĜedem zabránit.
eTrust Security Information Management
x ZajišĢuje dostupnost bezpeþnostních dat pro rozhodnutí.
x Zvyšuje pohotovost k obranČ.
x Zvyšuje administrativní efektivitu a snižuje náklady.
eTrust Security Information Management Ĝešení vytváĜejí z toku dat dodaných z rĤzných systémĤ a aplikací
využitelné informace a solidní podklady pro rozhodnutí. Data jsou analyzována a roztĜídČna a poté pĜehlednČ
znázornČna. Minimalizuje se tak riziko pĜerušení obchodních procesĤ a lze dodržovat pĜedpisy. eTrust Security
Information Management Ĝešení Vám dopomohou k celkovému pĜehledu, který Vám poskytne úþinnou podporu
pĜi kontrole nákladĤ, získávání podkladĤ pro rozhodnutí a pĜi zvyšování efektivity Vašeho bezpeþnostního
managementu – neboĢ pĜi tom není nic dĤležitČjší než schopnost pĜijmout v pravou chvíli rozhodnutí.
3 eTrust Identity and Access Management: management „Who's Who”
Správa uživatelĤ – tedy správa digitálních identit zamČstnancĤ, zákazníkĤ, obchodníkĤ a partnerĤ a jejich
pĜístupových práv – pĜedstavuje pro podniky velkou výzvu. Pracovníci odpovČdní za bezpeþnost IT se musí dbát
na postarat o to, aby interní uživatelé mohli co nejrychleji online aktivnČ a proaktivnČ pracovat. SouþasnČ musí
být umožnČn pĜístup externích uživatelĤ a partnerĤ k podnikovým zdrojĤm, ovšem také kontrolován. Tento úkol
je vysoce komplexní, neboĢ jediný uživatel mĤže potĜebovat pĜístup na velké množství platforem, systémĤ
a aplikací. Zdržování pĜístupu externích zákazníkĤ a partnerĤ k obchodním systémĤm mohou zpĤsobit
významné náklady. SouþasnČ však musí být také zajištČna ochrana citlivých podnikových dat. A k dodržování
pĜedpisĤ musí být koneþnČ v rámci celého podniku prosazena silná bezpeþnostní smČrnice a pĜípadnČ musí
docházet k protokolování (Audit Trail).
eTrust™ Identity and Access Management Suite od spoleþnosti CA v souþasné dobČ nabízí rozsáhlé nástroje
zadávání, implementaci a kontrole identit a pĜístupových práv. Tato Ĝešení umožĖují centrální a automatické
vytváĜení uživatelských úþtĤ a pracovních tokĤ, poskytování IT a dalších zdrojĤ a souþasnČ snížení nákladĤ díky
automatizovaným postupĤm. Navíc zvyšují produktivitu uživatelĤ integrovaným Single Sign-On a personalizovanými, na portále založenými samosprávnými funkcemi, mj. pro obnovování hesel. PodpoĜeny silnými
mechanismy pĜístupových oprávnČní a archivem identit, který lze podrobnČ pĜizpĤsobit aktuálním a budoucím
potĜebám, spravují eTrust nástroje k managementu identit digitální identity podniku ve všech jejich aspektech.
Od prvního dne, kdy nový zamČstnanec zahájí svou práci, ozve se obchodní partner nebo zákazník reaguje na
nabídku služeb, bude tento vztah transparentnČ a kontrolovanČ spravován. V pĜípadČ zmČny obchodní spolupráce
budou automaticky provedeny nezbytné úpravy pro pĜístup k systému. Bude tak zamezeno „osiĜelým“
uživatelským úþtĤm, zbyteþnému hromadČní práv a narušením bezpeþnosti.
eTrust Identity and Access Management Ĝešení mohou pro všechny platformy, provozní systémy a obchodní
aplikace implementovat pĜísné pĜístupové smČrnice, lhostejno zda zdroje pocházejí ze sítČ nebo nikoli. Centrální
management, personalizace zvyšující produktivitu a konzistentní aplikace smČrnic pĜispívají ke snížení nákladĤ.
eTrust nástroje k Access Management jsou v souþasné dobČ nejsilnČjšími a nejproaktivnČjšími dostupnými
bezpeþnostními Ĝešeními. Celopodnikovou kontrolou narušení pĜístupu nabízejí ochranu jak pĜed vnitĜními, tak
pĜed vnČjšími napadeními.
142
eTrust Identity and Access Management Ĝešení od spoleþnosti CA pĜedstavují základ efektivního auditování
uživatelĤ a jejich pĜístupu k podnikovým zdrojĤm v souladu s ochranou dat. eTrust Identity and Access
Management zahrnuje:
x
eTrust™ Access Control - umožĖuje jednotnou, efektivní úpravu pĜístupu pro pĜidČlené platformy
a provozní systémy. Toto Ĝešení nabízí kontrolu pĜístupu vycházející ze smČrnic, kterou se zjišĢuje, kteĜí
uživatelé mají pĜístup k urþitým systémĤm, aplikacím a souborĤm, která oprávnČní právČ teć mají
a v kterých dobách je pĜístup poskytován.
x
eTrust™ Admin - podporuje automatické pĜiĜazování IT a dalších zdrojĤ uživatelĤm, obnovování
hesel uživateli samotnými a synchronizaci hesel pro On-Demand prostĜedí.
x
eTrust™ Single Sign-On - prostĜednictvím jednoúrovĖového pĜihlašovacího Ĝízení („Single Sign-On“)
automatizuje bezpeþný pĜístup k aplikacím.
x
eTrust™ Site Minder - úpravou pĜístupu k webovým zdrojĤm a službám s flexibilními metodami
oprávnČní k pĜístupu a vyhrazeným, odstupĖovaným oprávnČním chrání online investice a kritické
webové služby podniku.
4 eTrust Threat Management: rozsáhlá ochrana pĜed negativními vlivy
nejnovČjší technologie
Podniky dnes chtČjí využívat výhod internetu a jejich prostĜednictvím rozšiĜovat popĜ. zdokonalovat své
možnosti komunikace, aniž by se pĜitom vystavovaly možným útokĤm. Každý den se objevují nové umČle
vykonstruované viry, které jsou schopné ochromit obchodní provoz podniku. Neodhalená napadení mohou zniþit
datové zdroje, snížit produktivitu a poškodit dobré jméno spoleþnosti, jestliže napĜíklad zároveĖ infikují data
obchodních partnerĤ nebo zákazníkĤ. Navzdory vyspČlým obranným technologiím jsou viry a další útoky
i nadále velkým problémem. BČhem nČkolika málo vteĜin mĤže být úspČšným kybernetickým útokem
zpochybnČna po léta budovaná identita znaþky, prvotĜídní služba zákazníkĤm a vysoká produktivita pracovníkĤ.
eTrust Threat Management Ĝešení od spoleþnosti CA proaktivnČ rozeznávají, analyzují, varují a odstraĖují
napadení v celém prostĜedí IT – a to efektivním zpĤsobem s pĜíznivými náklady. Protože k úþinné reakci na útok
je nezbytné mít o nČm pĜesné znalosti, jsou Ĝešení spoleþnosti CA podporována CA Security Advisory Teamem,
celosvČtovou sítí Rapid Response center, v nichž odborníci na bezpeþnost a profesionálové z technické podpory
identifikují a izolují nové útoky – nezávisle na tom, kde se na síti objevily. V další etapČ mĤže být další šíĜení
utlumeno s pomocí centralizovaného filtrování a implementace smČrnic. ěešení eTrust Threat Management
chrání všechny kritické servery a pracovní stanice pĜed rozmanitými nebezpeþími z internetu tak, že závadné
obsahy a e-mailové pĜílohy infikované viry jsou odchytávány již pĜi Gateway. Dochází tak k proaktivnímu
zamezování porušení síĢových smČrnic. OdstraĖovány jsou koneþnČ i bezpeþnostní nedostatky, a to ještČ pĜed
tím než mohou být útoþníky využity – a tak je zajištČn bezporuchový provoz.
S eTrust Threat Management Ĝešeními od spoleþnosti CA mĤže podnik sledovat aktivní, upravitelnou strategii
k pĜizpĤsobení své bezpeþnostní ochrany na nové situace a souþasnČ snížit náklady na bezpeþnostní
management. eTrust Threat Management zahrnuje:
x
eTrust™ Antivirus - nabízí výkonnou ochranu proti témČĜ všem formám nákladných virových útokĤ –
od perimetrĤ až po PDA.
x
eTrust™ CA-Examine® Auditing - provádí automatické kontroly integrity systému pro z/OS. ěešení
navíc poskytuje dĤležité informace pro systémovou bezpeþnost a integritu a pro kontrolní mechanismy,
které lze v jiných zdrojích nalézt pouze stČží.
x
eTrust™ EZ Armor™ - obsahuje Personal Firewall, rozsáhlou antivirovou ochranu a ochranu proti
škodlivým pĜílohám e-mailĤ a nabízí Vám tak provozuschopné bezpeþnostní Ĝešení proti velkému poþtu
hrozeb z internetu. Toto a jiná Ĝešení z nabídky my-eTrust.com zjednodušují komplikovaný úkol chránit
Vaši individuální soukromou sféru a zajistit Váš poþítaþ doma nebo na pracovišti proti dnešním
nebezpeþím.
x
eTrust PestPatrol Anti-Spyware - rozeznává a odstraĖuje široké spektrum hrozeb nezpĤsobených viry
a chrání v soukromí a pĜi práci používané PC pĜed neoprávnČnými pĜístupy, krádežemi informací
a redukovaným výkonem systému.
143
x
eTrust™ Secure Content Manager - kombinuje v integrovaném Ĝešení ochranu proti rozmanitým
nebezpeþím, jako jsou viry, spamy nebo nepovolené používání internetu zamČstnanci. eTrust Secure
Content Manager nabízí obsáhlé a upravitelné Ĝešení pro ochranu obsahu.
x
eTrust™ Vulnerability Manager - umožní Vašemu podniku proaktivnČ a cílenČ odstraĖovat slabiny.
Toto obsáhlé Ĝešení managementu slabin Vám poskytuje know-how, metodu a technologii, které
potĜebujete k odstraĖování slabin pĜed tím, než jich budou moci využít hackeĜi, þervi a jiné hrozby.
5 eTrust Security Information Management: zdolat pĜíval informací
V každém podniku zatím existují þetné bezpeþnostní systémy, které vyhledávají data prostĜednictvím
bezpeþných zdrojĤ a vydávají pĜíslušná varovná hlášení. Každý z tČchto systémĤ generuje data rĤzným
zpĤsobem a v rĤzných formátech. Rozdíly jsou dále i mezi místy uložení a pĜíjemci, jimž jsou zprávy zasílány.
Tento nepĜetržitý tok dat a jevĤ, které jsou rozhodující pro bezpeþnost, z nekompatibilních systémĤ není
nakonec možné zvládnout. Útržkovitý základ vede témČĜ nevyhnutelnČ k vícenásobnému zpracování úkolĤ,
enormní režii, menší ochranČ a k nedostatku auditových požadavkĤ.
S eTrust Security Information Management Ĝešeními od spoleþnosti CA podniky získávají úplnou kontrolu nad
jejich bezpeþnostními informacemi a tedy i nad jejich bezpeþnostní infrastrukturou. V pĜípadČ tČchto inovaþních
Ĝešen se používají vizualizace a nejmodernČjší forenzní analytické metody k tomu, aby se z nezpracovaných dat
týkajících se fyzického a IT prostĜedí získaly solidní podklady pro rozhodnutí. Centrálním Ĝízením mĤže
administrátor efektivním zpĤsobem realizovat integraci s jinými Ĝešeními a realizovat automatizaci úkolĤ
a zvýšit bezpeþnost. NejdĤležitČjší však je, aby tyto nástroje pomáhaly zabraĖovat jevĤm, které by se mohly
negativnČ projevit na prĤbČhu þinnosti, a aby Vám poskytovaly bezpeþnostní názory, které potĜebujete
k dodržování smČrnic. eTrust Security Information Management zahrnuje:
144
x
eTrust™ 20/20™ - jedineþné Ĝešení, které data, jež jsou z hlediska bezpeþnosti významná,
shromažćuje pĜes fyzické pĜístupy a technické IT pĜístupy ke zdrojĤm z celého podniku, koreluje,
analyzuje a znázorĖuje v intuitivním uživatelském prostĜedí.
x
eTrust™ Network Forensics - eviduje nezpracovaná data síĢového provozu a pracuje s nejmodernČjšími forenzními metodami k tomu, aby provČĜilo dopady útokĤ na síĢ, interního zneužití dat
a porušení bezpeþnostních nebo personálních smČrnic na Váš majetek.
x
eTrust™ Security Command Center - nabízí kompletní Ĝešení ke kontrole a správČ všech aspektĤ
podnikové bezpeþnosti z jedné centrální Ĝídící konzole. Na základČ integrace základních bezpeþnostních
a systémových dat, která jsou evidována za pomoci nejrĤznČjších technologií, poskytuje eTrust Security
Command Center nástroje a schopnosti k tomu, aby bylo vybudováno nebo zlepšeno Security
Operations Center – od identifikace až po odstranČní.
Cisco Network Admission Control
Ivo NČmeþek
[email protected]
Cisco Systems Czech Republic s.r.o.
V Celnici 10, 117 21 Praha
1 Proþ Cisco Network Admission Control ?
Vysokým rizikem pro síĢ jsou nezabezpeþené stanice. Mohou to být stanice, které nemají aktivovanou
a aktualizovanou antivirovou ochranu nebo nemají nainstalovány nezbytné opravy a aktualizace operaþního
systému.
Network Admission Control (NAC) ovČĜí, zda stanice, které se pĜipojují do sítČ, vyhovují bezpeþnostním
pravidlĤm stanoveným ve firmČ. Stanice, které definovaným pravidlĤm vyhovují, mohou dostat neomezený
pĜístup do sítČ. PĜístup stanic, které definovaným pravidlĤm nevyhovují, bude omezen síĢovým zaĜízením do té
doby, než budou odstranČny nedostatky. Po odstranČní nedostatkĤ získá stanice opČt plný pĜístup do sítČ, viz
obrázek 1.
Obr 1: Network Admission Control
Network Admission Control pomáhá správcĤm sítČ udržovat stanice v aktualizovaném stavu. V první fázi
programu jde zejména o aktualizaci anitivirové ochrany a bezpeþnostních oprav v operaþním systému, v dalších
fázích budou možnosti NAC výraznČ širší.
145
2 Co je NAC a jaké jsou jeho souþásti?
NAC je technologický program firmy Cisco Systems. Na programu spolupracuje Ĝada partnerských firem,
v první fázi zejména dodavatelé antivirové ochrany. V první fázi zahájily spolupráci v programu firmy Cisco
Systems, Trend Micro, NAI (McAfee) a Symantec. Podporu programu ohlásily firmy IBM, Microsoft, CA
a nČkolik desítek dalších. Program je otevĜený, zapojují se do nČj nepĜetržitČ další firmy.
ěešení má nČkolik souþástí:
x
Cisco Trust Agent (CTA). Tento software zjišĢujČ informace o koncové stanici a pĜedává je
autentizaþnímu serveru.
x
AV klient. Antivirový software pĜedává Cisco Trust Agentu informace o stavu antivirové ochrany.
Mezi tyto informace patĜí verze scan engine, verze DAT souboru, aktivace online antivirové ochrany
apod.
x
Cisco Security Agent (CSA). CSA chrání koncovou stanici a CTA pĜed napadením a nedovolenou
manipulací. PĜedává Trust Agentu rozšíĜené informace o operaþním systému, napĜíklad o instalovaných
hotfixech a opravných souborech.
x
PĜístupová síĢová zaĜízení (smČrovaþe, pĜepínaþe, VPN koncentrátory, PIX firewally, bezdrátové AP).
Dávají podnČt k vyhodnocení stavu koncové stanice, komunikují s autentizaþním serverem, omezují
pĜístup nevyhovujících stanic do sítČ.
x
Autentizaþní server (Cisco Secure ACS verze 3.3). Na tomto serveru definuje správce pravidla pro
vyhodnocování stavu koncových stanic.
x
Policy server antivirové ochrany. Server od AV dodavatele vyhodnocující stav antivirové ochrany na
stanici a formulující pravidla, kterým musejí vyhovovat stanice z hlediska antivirové ochrany.
x
Server pro správu a monitorování (Cisco Works SIMS pro NAC). Monitoruje souþásti NAC,
zaznamenává události a vyhodnocuje je.
Nezbytnými souþástmi NAC jsou CTA, pĜístupové síĢové zaĜízení a autentizaþní server. Ostatní souþásti jsou
volitelné.
146
3 Jak funguje Network Admission Control ?
Zakladní princip je znázornČn na obrázku 2. Na stanici je nainstalován software Cisco Trust Agent (CTA). PĜi
pĜipojování do sítČ naváže hraniþní zaĜízení komuikaci s CTA a vyzve jej k provČĜení stavu stanice. Informace o
stavu stanice pĜedá CTA pĜes hraniþní síĢové zaĜízení [1] autentizaþnímu (AAA) serveru [2]. Autentizaþní server
provČĜí pĜedané informace. PĜi vyhodnocování se mĤže ACS obrátit na policy servery dodavatelĤ aplikací [2a].
Autentizaþní server informace vyhodnotí [3] a pĜedá pokyn hraniþnímu zaĜízení sítČ [4]. Hraniþní zaĜízení podle
pokynĤ autentizaþního serveru povolí, omezí nebo zablokuje pĜístup stanice do firemní sítČ [5]. Obvykle povolí
pĜístup do služebního segmentu, odkud je možné zajistit nápravu stavu koncové stanice. Pokyny mĤže pĜedat
uživatelĤm pĜes svoje rozhraní CTA [6], pĜípadnČ mĤže být uživatel pĜesmČrován na služební web stránky. Poté,
co je stav stanice napraven (napĜíklad se aktualizuje antivirový DAT soubor a aktivuje se online antivirová
ochrana), provede CTA nové vyhodnocení stavu stanice a uživatel mĤže získat plný pĜístup do sítČ. Další
vyhodnocování se provádí v pravidelných intervalech.
Obr 2: Princip þinnosti NAC
147
4 Jak se dá využít Network Admission Control ?
NAC mĤžeme využít v mnoha scénáĜích, napĜíklad:
x
Na poboþkách provČĜíme stanice pĜed pĜístupem do centra na hraniþním smČrovaþi, pĜipojujícím
poboþku do WAN sítČ.
x
Stanice provČĜíme pĜed pĜístupem do sítČ pĜes VPN.
x
Stanice provČĜíme pĜed pĜístupem do sítČ pĜes telefonní spojení (dial-up).
x
ProvČĜíme stanice pĜed pĜístupem do sítČ pĜes bezdrátový access point.
x
Stanici provČĜíme pĜed pĜístupem do lokální sítČ na LAN pĜepínaþi, ke kterému je stanice pĜipojena.
x
PĜed pĜístupem do Internetu provČĜíme stanice na hraniþním smČrovaþi nebo firewallu.
x
ProvČĜíme stav stanic pĜipojujících se z laboratorních segmentĤ na smČrovaþi, oddČlujícím laboratorní
segment od firemní sítČ.
5 Fáze programu
Technologie NAC je implementována ve tĜech fázích. PostupnČ se bude rozšiĜovat podpora operaþních systémĤ,
aplikací, hraniþních zaĜízení i funkce technologie. Fáze vývoje NAC shrnuje následující tabulka:
Fáze 1 (od 7/2004)
Fáze 2 (polovina roku
2005)
Fáze 3
Hraniþní síĢové
zaĜízení
SmČrovaþe 83x-72xx
PĜepínaþe Catalyst,
koncentrátory VPN3000
(v4.7)
PIX, WLAN AP
Podpora CTA
Windows NT, 2000, XP
Windows 2003, Linux,
Solaris
IP telefony, MaC,
HPUX, AIX
Integrace aplikací
Antiviry
Další aplikace
Další aplikace
Autentizace
L3 EAP/UDP
L2 EAP/802.1x
HTTP/SSL
ZaĜízení bez CTA
Spoleþné omezení
RĤzná pravidla
Stažení appletu
Vynucení pravidel
L3 ACL
VLAN, PACL
QoS
6 Odkazy
[ 1 ] http://www.cisco.com/go/selfdefend
[ 2 ] http://www.cisco.com/go/nac
148
ěešení spoleþnosti Crypto AG pro zabezpeþení rádií
Dr. Richard Weber and Axel Hosemann, Crypto AG
ERICSSON, spol. s r.o.
Sokolovská 79 þp. 192, 186 00 Praha 8
1 ProstĜedí uživatele
1.1
Systémový koncept
Následující obrázek vysvČtluje systémové zakotvení ěešení zabezpeþení rádií HC-7665 a HC-2650. Existují tĜi
typy zaĜízení, které mají pĜístup k HC-7665/2650:
V oblasti „Setup“ (Nastavení) existuje stĜedisko Ĝízení, které pĜenáší šifrovaná data zabezpeþení do SDC
(Security Data Carrier – Smarcard, Nosiþ zabezpeþovacích dat – Chytrá karta). SDC mĤže být zapojen do HC7665/2650 k vložení nových dat do databáze zabezpeþení jednotky. Jako budoucí rozšíĜení systému bude
zaĜízení zajištČného generování decentralizovaného klíþe užiteþné obzvláštČ v taktickém scénáĜi. Místní
ovládaný osobní poþítaþ mĤže být použit pro nastavení s jistými omezeními. Pro místní správu je k disposici
server sítČ web v rámci jednotky. PĜístup s pomocí standardního prohlížeþe existuje, jestliže ten server sítČ web
byl zmocnČn správcem zabezpeþení. Každá akce na webovém serveru musí pĜinutit uživatele k pĜihlášení
v zavedeném MMI (Man Machine Interface, rozhraní þlovČk – stroj).
V oblasti „ěízení“ jsou všechna zaĜízení a Ĝídící poþítaþe, které Ĝídí HC-7665/2650. Pro úþely Ĝízení na dálku
v nastavení systému je na zadní stranČ zaĜízení konektor nabízející spojení pĜes IEEE 802.3E, RS-232 nebo RS485. Výbava pro Ĝízení na dálku mĤže provozovat to zaĜízení prostĜednictvím jazyka pĜíkazové Ĝádky (command
line language). Existuje definovaný soubor povolených pĜíkazĤ vydávaných na dálku v zabezpeþeném prostĜedí.
PĜístup vzdáleného Ĝadiþe musí být zmocnČn správcem zabezpeþení. PĜenosný poþítaþ (laptop) mĤže být
propojen s konektorem na pĜední stranČ jako lokální dohlížecí prvek. V tomto pĜípadČ je zadní propojení
ukonþeno (RS-232 a RS-485).
V oblasti „Provoz“ jsou standardní komunikaþní zaĜízení (sluchátko, poþítaþ jako digitální koncové zaĜízení
(Data Terminal Equipment, DTE), VF rádiové zaĜízení). HC-7665/2650 budou sluþitelné zpĤsobem, který
nevyžaduje modifikace existující výbavy.
Obr 1: PĜehled systému HC-7665 / 2650
149
2 Konfigurace systému
2.1
Zabezpeþení rádia s HC-2650
x
Šifrování hlasu na VKV/UKV/VF.
x
Poloduplex.
x
ÚplnČ sluþitelné s novou architekturou zabezpeþení Crypto.
x
Všechny zabezpeþovací parametry a parametry IT (Information Technology, informatika) mohou být
vymČnČny prostĜednictvím zaĜízení SDC.
x
Datová komunikace je možná s interním modemem (STANAG 4285).
x
Mód s analogovým hlasem není v tomto pĜípadČ interoperabilní (=schopný pracovat spoleþnČ) s HC265 (=pĜedchĤdce systému HC-2650; pouze hlas).
x
Pro zákazníky, kteĜí nemají jednotky HC-265 .
Obr 2: Sestava komunikace a správy s HC-2650
Data pro distribuci pĜes SDC mohou být buć generována spoleþnČ s na webu založeném MMI nebo na vloženém
MMI samotné jednotky.
150
2.2
Šifrování rádia HC-2650/HC-265
x
Šifrování hlasu na VKV/UKV/VF.
x
Poloduplex.
x
Veškerá digitální komunikace je založena na algoritmu unikátním pro urþitého zákazníka (HCA-480).
x
Digitální data jsou sluþitelná s novou architekturou zabezpeþení Crypto; pĜídavné parametry HC-265
mohou být Ĝízeny rozšíĜeným MMI.
x
Všechny zabezpeþovací parametry a parametry IT mohou být vymČnČny prostĜednictvím zaĜízení SDC;
výjimka – mezi HC-2650 a HC-265 parametry nemohou být vymČnČny!
x
Datová komunikace je možná s interním modulem (STANAG 4285).
x
Mód s analogovým hlasem je interoperabilní s HC-265.
x
Systém by mČl být prodán jen tČm zákazníkĤm, kteĜí již mají jednotky HC-265.
Obr 3: UspoĜádání komunikace a Ĝízení HC-2650 / HC-265
Data pro distribuci pĜes SDC mohou být buć generována spoleþnČ s na webu založeném MMI nebo na MMI
samotné jednotky.
151
2.3
Šifrování dat s HC-7665
x
Šifrování dat na VKV/UKV/VF.
x
Plný duplex.
x
Komunikace založená na algoritmu unikátním pro urþitého zákazníka (HCA-480).
x
Instalace a administrace zabezpeþení je sluþitelná s novou architekturou zabezpeþení Crypto.
x
Soubor komunikaþních klíþĤ (CK) systému HC-7660 je sluþitelný s HC-7665.
x
MMI je zmČnČn pro správu CK systému HC-7665.
x
Všechny zabezpeþovací parametry a parametry IT mohou být vymČnČny s jinými HC-7665
prostĜednictvím zaĜízení SDC.
x
Mohou být þteny pĤvodní chytré karty HC-7660.
x
Na pĤvodní karty zaĜízení HC-7660 lze provádČt záznam.
x
Datová komunikace je možná s vnČjším modemem.
x
Není podporován žádný hlasový mód.
x
ZaĜízení by mČlo být prodáváno jen jako jednokanálová šifrovací jednotka interoperabilní s HC-7660.
x
Náhrada zaĜízení HC-7660 je možná díky možnosti montáže do police.
Obr 4: UspoĜádání komunikace a Ĝízení HC-7665 / HC-7660
Data pro distribuci pĜes SDC mohou být buć generována spoleþnČ s na webu založeném MMI nebo na MMI
samotné jednotky.
152
Outsourcing kontrol a auditĤ fyzické ostrahy a bezpeþnostní studie
F.S.C. BEZEýNOSTNÍ PORADENSTVÍ, a. s.
Vítkovická 20, 702 00 Ostrava
Tel.: 596 617 044-45; Fax.: 596 638 499
E-mail: [email protected]
1 Úvod
Bezpeþnostní systém prochází kontinuálním vývojovým procesem, který je dĤsledkem trvalého rozvoje vČdy
a techniky, postupĤ a zkušeností. Na základČ tČchto výsledkĤ se v souþasné dobČ prosazuje externí zajištČní
bezpeþnosti, tzv. outsourcing. Mezi þinnosti zajišĢované externím zpĤsobem patĜí také:
x
kontroly a audity fyzické ostrahy;
x
zpracování bezpeþnostních studií.
Výše citované oblasti, kterým je vČnován tento þlánek, vyžadují vysokou odbornost, odpovČdnost a povČdomí
o bezpeþnostním systému jako celku.
2 Outsourcing kontrol a auditĤ fyzické ostrahy
Podstatou bezpeþnosti je zajištČní funkþního systému ochrany osob, majetku a informací. Jednou ze souþástí
bezpeþnostního systému je þinnost fyzické ostrahy (dále jen „FO“), která dnes nahrazuje vlastní zamČstnance
orgánĤ státu a organizací.
V dĤsledku absence právních pĜedpisĤ v oblasti FO je nutné nastavit jednoznaþná pravidla mezi pĜíslušnými
subjekty prostĜednictvím smlouvy a schválením interních pĜedpisĤ, které efektivnČ upravují její þinnost
v pĜíslušné míĜe. Výše citované dokumenty musí být v souladu s platnými právními a interními pĜedpisy
a normami.
Za úþelem dodržování striktnČ definovaných postupĤ a eliminace rizika selhání lidského faktoru je nezbytné
provádČt kontroly FO nejlépe v nepravidelných lhĤtách. Cílem samotných kontrol není nalézat jen nedostatky,
ale pĜedevším trvale zvyšovat kvalitu poskytovaných služeb FO.
2.1
Výhody outsourcingu kontrol a auditĤ fyzické ostrahy
Outsourcing kontrol a auditĤ FO má pĜedevším tyto pĜednosti:
x
nezávislost na poskytovateli FO;
x
objektivnost (neexistence místních vazeb a ani vazeb na dodavatelích);
x
komplexní pohled na bezpeþnostní systém;
x
úspornost finanþních prostĜedkĤ (nejsou vynaloženy pro platy vlastních zamČstnancĤ);
x
Ĝešení deficitu pracovních pozic, zabývajících se kontrolní þinností;
x
nepravidelnost kontrol;
x
zajišĢování kontrol specialisty vyškolenými v oboru;
x
znalost smČrnic pro výkon FO a smluvních podmínek;
x
prokazatelnost závČrĤ z kontrol zdokumentováním.
Základem pro provedení samotných kontrol a auditĤ je obeznámení auditorĤ s objektem a jeho specifikami,
a následné zpracování postupĤ, které jsou závazné pro provádČní periodických i hloubkových kontrol a auditĤ.
153
Dle þasového þlenČní mohou být kontroly a audity jednorázového nebo periodického typu. Kontroly a audity se
zpravidla zamČĜují na kvalitu výkonu, plnČní smluvnČ garantovaných podmínek pro zajišĢování FO a definovaných povinností zamČstnancĤ FO.
Kontroly a audity FO Ĝeší tuto problematiku komplexnČ, tj. vþetnČ vazeb na technická zabezpeþení a režimovou
ochranu. Souþástí prĤbČhu kontroly nebo auditu je posouzení rozsahu a zpĤsobu výkonu FO, aktuálnosti
zpracovaných bezpeþnostních dokumentací a dalších podmínek pro její výkon. Výstupem kontroly nebo auditu
je nejen pĜehled neshod (nedostatkĤ), ale také nápravná doporuþení pro další práci s dodavatelem.
V rámci standardních kontrol a auditĤ se zejména posuzuje:
x
pochĤzková þinnost FO;
x
režim vstupu a vjezdu;
x
úroveĖ vystupování zamČstnancĤ FO k návštČvníkĤm objektu;
x
znalost základních povinností;
x
úroveĖ vedení záznamĤ o prĤbČhu služby;
x
stĜídání stanovišĢ a smČn;
x
znalost opatĜení požární ochrany (dále jen „PO“) a bezpeþnosti a ochrany zdraví pĜi práci (dále jen
„BOZP“);
x
vybavení zamČstnancĤ FO a stanovišĢ FO;
x
postup pĜi vzniku mimoĜádných událostí a krizových situací.
2.2
Kontroly a audity zajišĢované spoleþností F.S.C. BEZPEýNOSTNÍ
PORADENSTVÍ, a. s.
Za úþelem kvalitního provedení kontrolního výkonu je zpracována vlastní metodika, která se neustále aktualizuje
a pĜizpĤsobuje novým poznatkĤm a trendĤm. Samotný kontrolní systém se dle metodiky aplikuje individuálnČ
a berou se v úvahu veškeré zvláštnosti pĜíslušných subjektĤ. Metodika je souþástí dokumentace managementu
jakosti spoleþnosti certifikované dle ýSN EN ISO 9001: 2001.
Dle dohody s objednatelem jsou pĜi kontrolní nebo auditní þinnosti FO provádČny penetraþní testy, napĜ.
v podobČ:
x
neoprávnČného vstupu þi vjezdu;
x
odloženého zavazadla;
x
požadavku na služby, které ostraha nesmí zajišĢovat;
x
vynášení majetku bez povolení;
x
pĜekonání technického zabezpeþení.
Dle požadavkĤ klienta je možné rozsah kontrol nebo auditĤ rozšíĜit na další oblasti, které lze ovČĜit souþasnČ
s kontrolou FO, napĜ.:
154
x
funkþnost a rozsah technického zabezpeþení a vedení provozní dokumentace;
x
dodržování zásad PO a BOZP;
x
dodržování ekologických pĜedpisĤ;
x
dodržování režimových opatĜení zamČstnanci objednatele;
x
úroveĖ zpracování bezpeþnostních dokumentací a jejich aktuálnost.
RovnČž je možné využít nČkterý z dalších bezpeþnostních auditĤ, které F.S.C. nabízí:
x
audit fyzické bezpeþnosti;
x
audit informaþní bezpeþnosti;
x
audit ochrany osobních údajĤ;
x
audit ochrany utajovaných skuteþností;
x
audit krizového Ĝízení;
x
audit havarijního plánování;
x
audit souþasného stavu ochrany osob, majetku a informací;
x
audit BOZP a PO;
x
audit shody dokumentace objektové bezpeþnosti.
3 Bezpeþnostní studie
Podstatou souþasného pohledu na bezpeþnost je integrace dílþích bezpeþnostních opatĜení, a proto je vhodné
vzájemnou souþinnost technického zabezpeþení, režimových opatĜení a FO navrhnout již v pĜedprojektové
pĜípravČ, a to v bezpeþnostní studii. Dle již platných norem ýSN EN Ĝady 5013 pro poplachové systémy je
bezpeþnostní studie (bezpeþnostní posouzení) základním podkladem pro zpracování projektové dokumentace.
Výše uvedeného cíle je možné dosáhnout prostĜednictvím nezávislého pĜístupu bez vazby na instalaþní firmy
a dodavatele bezpeþnostních technologií. Tento zpĤsob zpracování zaruþuje zavedení funkþního bezpeþnostního
systému a pĜedevším úsporu finanþních prostĜedkĤ pĜi jeho realizaci.
3.1
ZpĤsob zpracování bezpeþnostní studie
Nový návrh bezpeþnostních opatĜení není možné provést bez zjištČní stávajícího stavu, provedení analýzy rizik
a vzájemných konzultací.
Bezpeþnostní studie Ĝeší tuto problematiku v níže uvedených krocích:
x
posouzení stávajícího stavu;
x
analýza rizik;
x
návrh technického zabezpeþení;
x
návrh systému režimové ochrany;
x
návrh systému FO;
x
kalkulace nákladĤ na realizaci navrhovaných opatĜení.
Bezpeþnostní studie rovnČž obsahuje množství pĜíloh, napĜ.:
x
schémata rozmístČní prvkĤ zabezpeþení;
x
pĜíslušná bodová hodnocení pro stanovení míry rizika;
x
grafy znázorĖující úroveĖ rizika;
x
požadavky na bezpeþnostní technologie.
155
Návrh technického zabezpeþení i dalších bezpeþnostních opatĜení je možné zpracovat ve více variantách,
a to vþetnČ kalkulace nákladĤ. Po schválení bezpeþnostní studie je pak možné vybranou variantu rozpracovat
dĤkladnČji a použít ji jako zadávací dokumentaci pro výbČr dodavatele technického zabezpeþení. Ve fázi výbČru
dodavatele lze tímto zpĤsobem uspoĜit náklady ve zpracování projektové dokumentace technického zabezpeþení,
kterou pak zpracuje až vybraný dodavatel realizace technického zabezpeþení pro konkrétní technologii. Tento
požadavek vyhovuje i ustanovením zákona þ. 40/2004 Sb., o veĜejných zakázkách, ve znČní pozdČjších pĜedpisĤ,
dle kterých nemá zadávací dokumentace obsahovat konkrétní technologie.
Mezi základní výhody zpracování bezpeþnostních studií nezávislou poradenskou firmou patĜí:
x
komplexní pohled na bezpeþnostní systém (nejen z pohledu instalaþní firmy);
x
omezení komerþních zájmĤ dodavatelĤ bezpeþnostních technologií;
x
návrh zabezpeþení na základČ analýzy rizik;
x
využití zkušeností z návrhĤ obdobných bezpeþnostních systémĤ;
x
využití specialistĤ pĜíslušných profesí;
x
aplikace aktuálních poznatkĤ o bezpeþnostních technologiích a možnostech jejich integrace.
Další þinnosti navazující na zpracování bezpeþnostních studií
3.2
Zpracovaná bezpeþnostní studie je základním dokumentem pro provedení navazujících þinností, které jsou
podstatné pro kvalitní a funkþní zavedení bezpeþnostních opatĜení. V rámci zachování kontinuity návrhu
bezpeþnostního systému je vhodné zajistit zpracovatelské úkoly dodavatelským subjektem.
Navazující dokumentace:
x
zadávací dokumentace pro výbČr dodavatelĤ a projektové dokumentace systémĤ technického
zabezpeþení (CCTV, EZS, EPS ...);
x
bezpeþnostní dokumentace (provozní Ĝád bezpeþnostních systémĤ, dokumentace objektové bezpeþnosti
apod.).
Navazující þinnosti:
x
odborné posouzení nabídek uchazeþĤ zaslaných do soutČže;
x
technický dozor pĜi realizaci zabezpeþení;
x
odborná pĜejímka díla;
x
inspekce technického zabezpeþení v pĜedem stanovených periodách.
4 ZávČr
Úþinná ochrana osob, majetku a informací je stále více podporována pĜíslušnými právními pĜedpisy a normami,
které je nutné aplikovat vhodným zpĤsobem. Realizace požadavkĤ platných právních pĜedpisĤ a norem vyžaduje
seriózní a kvalifikovaný pĜístup výrobcĤ a dodavatelĤ, jenž je nadĜazen vlastním zájmĤm. Dodržet tento
požadavek za všech okolností je ve vČtšinČ pĜípadĤ problematický a praktické zkušenosti potvrzují, že zapojení
nezávislé firmy do procesu zajištČní vhodných bezpeþnostních opatĜení je pĜínosem.
Uvedené poznatky jsou výsledkem více než 7-mi leté zkušenosti specialistĤ F.S.C. z již realizovaných bezpeþnostních kontrol a auditĤ, a zpracovaných bezpeþnostních studií. Za úþelem poskytování kvalitních služeb se
klade také dĤraz na kontinuální kvalifikaþní a profesní rĤst zamČstnancĤ spoleþnosti, z nichž je Ĝada soudními
znalci, þi uznávanými specialisty v oboru.
F.S.C. uplatĖuje prezentované produkty u vČtšiny orgánĤ státu, vþetnČ Ministerstva obrany ýR, a organizací.
Na vyžádání je spoleþnost pĜipravena poskytnout pĜehled referencí. Další informace jsou uvedeny na adrese
www.fsc-ov.cz a na stánku C2 v pavilonu G2 BrnČnského výstavištČ na veletrhu IDET 2005.
156
Nasazení nástroje pro dohled bezpeþnosti
David C. HÁJÍýEK
GiTy, a. s.,
[email protected]
1 Úvod
Tento þlánek se zabývá problematikou sledování incidentĤ a jejich zpČtnou prokazatelností v IT prostĜedí. Jako
zdroj volí log síĢových zaĜízení. ýlánek je pĜípadovou studií popisující jednu z implementací takového systému.
ZároveĖ v þlánku nezapomínáme na další dĤležité souþásti budování komplexního bezpeþnostního systému –
zajištČní integrity a þasové autenticity logĤ.
2 Od dat k informacím
2.1
Pozice logu
Analýza logu, která je detekþní souþástí Ĝízení bezpeþnosti, se dá bez nadsázky považovat za neopomenutelnou
souþást snažení bezpeþnostních správcĤ. Bez detekce není reakce a pochopitelnČ ani následných preventivních
krokĤ.
Opomeneme-li speciální pĜípady, kdy provozovateli informaþního systému pĜímo þi nepĜímo vyplývá povinnost
auditní þi log soubory zpracovávat a uchovávat (napĜ. zákon þ. 148/1998 Sb.), zpravidla se setkáme se zájmem
specialistĤ odpovČdných za bezpeþnost logy pro jejich þinnost využívat. Bohužel ne všude je toto odhodlání
dovedeno do zdárného konce a nezĜídka konþí jen zbožným pĜáním. Kupodivu klíþovým okamžikem k eliminaci
takové situace je rozhodnutí a odhodlání Ĝešit. Protože potĜeba nevzniká na manažerských pozicích, ale v úrovni
„vojákĤ v poli,“ pĜedchází rozhodnutí pĜesvČdþení odpovČdných osob. V závČsu na nČm ovšem nalézáme
nutnost alokace potĜebných zdrojĤ. Nutno dodat, že v pĜípadČ, na který se zamČĜíme dosahují investice
sedmiciferné þástky.
Zopakujme však, že pĜes nesnadnost manipulace s log soubory plynoucí z jejich rĤznorodosti a objemu, kterých
dosahují, jde o nepostradatelnou souþást každé organizace, odrážející jejich historii a kulturu. Zatímco jejich
využíváním dostává tým odborníkĤ kvalitní a užiteþné informace, jejich ztrátou naopak nejenže ztrácí náskok
pĜed útoþníky, jejich zcizením dokonce dává významnou výhodu do jejich rukou.
Logy však nemají pouze momentální informaþní hodnotu, ale jsou dĤležité zpČtnČ, pro sledování trendĤ a vývoje
situace. Z toho dĤvodu je nezbytné se zamČĜit také na jejich bezpeþnost v kontextu uchovávání, tedy na zajištČní
jejich dostupnosti, integrity, dĤvČrnosti a v neposlední ĜadČ nepopiratelnosti autorství jejich vzniku, po urþené
þasové období.
2.2
Jak log zpracovat
Ve spoustČ organizací, které využívají log záznamy pro Ĝízení bezpeþnosti je možné se setkat s nástroji rĤzných
úrovní a kvalit. Od produktovČ orientovaných programĤ dodávaných výrobcem (Cisco, Symantec, Enterasys, aj.)
se pĜes pomocníky z dob poþítaþovČ „dĜevních“ (grep, sed...) dostáváme až k systémĤm, které mají ambice být
platformovČ a produktovČ nezávislými a zpracovávat log soubory bez ohledu na výrobce zaĜízení, ze kterých
pocházejí. Takové nástroje pochopitelnČ staví na principech normalizace logĤ, což znamená syntaktické
a sémantické zvládnutí logĤ všech podporovaných zaĜízení na softwarové úrovni.
Jedním z takových je i ISM verze 5.2 (Intellitactics Security Manager, www.intellitactics.com, hodnocení viz
Gartner group Magic quadrant), který jsme zvolili pro naši pĜípadovou studii díky jeho vyspČlosti v dobČ
realizace projektu. Vzhledem k charakteru log souborĤ nedochází pĜi normalizaci k žádné ztrátČ ani zkreslení
informace. Na obrázku þ. 1 je vidČt, jakým jak jsou log data sbírána a zpracována.
157
SbČr dat
Normalizace
Analýza
Prezentace
Datové zdroje
•Syslog
•SNMP
•SMTP
•FTP
•SCP
•…
Surová data
Parsovaná data
Sumární data
Incidenty
Tok dat
Postup prĤzkumu
Obrázek 1: PrĤbČh dat systémem
Vyjdeme-li z obrázku þ. 1, surovými daty jsou oznaþovány záznamy v pĤvodní podobČ. Pro pĜehlednost jsou
uchovávána pro každé zaĜízení zvlášĢ, a to v adresáĜové struktuĜe /var/nsm/raw/{device}/. Z uvedené
struktury je patrné, že v tomto pĜípadČ bylo zvoleno Ĝešení na UNIX/LINUX platformČ (konkrétnČ RHEL 3).
Jejich uchování je nezbytné pro následné prokazování, pĜípadnČ pro komunikaci s výrobcem zaĜízení, napĜíklad
pĜi Ĝešení reklamací.
Na obrázku þ. 2 je systém zálohování zakreslen pouze jako jedna samostatná komponenta. Celý zpĤsob
zálohování a následného získávání dat je mnohem komplikovanČjší. Vedle zálohovacího zaĜízení s dostateþnou
kapacitou je tĜeba definovat politiku Ĝešící uchovávání dat a logiku, která bude politiku realizovat v praxi.
V našem systému jsou na prezentaþních serverech instalováni agenti jejichž þinnost se aktivuje požadavkem
uživatele na data stáĜí vČtšího, než ta, která jsou na serveru skuteþnČ pĜítomna. Agent potom z centrálního
archivu pĜesune požadovaná data na prezentaþní server a jeho aktivita pokraþuje až po úspČšném ukonþení
operace agenta.
Pro uchovávání dat bude dĤležitou informací objem dat. LogĤ mohou dennČ v organizaci vzniknout až gigabyty.
PĜi archivování surových dat mĤžeme dosáhnout komprese až 1:10. Sumární data (viz obrázek 1) nám zvýší
objem na cca 15 % pĤvodní velikosti a budeme-li pĜedpokládat, že pouze 5 % všech dat jsou skuteþnČ incidenty
(tedy spolu se sumárními daty ukládány v databázi), dostáváme se ke kompresi 1:5 (v našem pĜípadČ bylo
dosaženo skuteþného pomČru 1:6). I tato velikost je však nezanedbatelná.
V našem pĜípadČ je zachování pĤvodního záznamu dĤležité rovnČž z dĤvodu zajištČní detekce integrity záznamu
a þasové autenticity. Celkové Ĝešení je totiž koncipováno tak, že využívá další z komponent – nezávislou
þasovou autoritu.
Jak je u GiTy zvykem, pro tyto úþely využívá vlastního robustního Ĝešení – služeb elektronického notáĜe.
Výhody tohoto pĜístupu oproti prostého Time Stampingu, pĜípadnČ kolektivního svČdectví bylo již mnohokráte
vysvČtleno (dokonce i v rámci této konference – viz [1]). Nezávislá þasová autorita oznaþí záznam informací
o dobČ jejich vzniku (resp. o dobČ, v jejímž okamžiku již jistČ existovala). ýasová autentizace mĤže probíhat
v zásadČ dvČma základními zpĤsoby:
158
1.
centrálnČ – na serveru, který shromažćuje data – pro skupinu záznamĤ rĤzných zaĜízení dohromady,
a to v þasových intervalech,
2.
individuálnČ – data z každého zaĜízení, jehož log je využíván, projdou samostatnČ, v pravidelných
intervalech komponentou þasového serveru.
Centrální oznaþování logu neklade tak vysoké nároky na jednotlivá síĢová zaĜízení, která mají log posílat, ani na
úpravu jejich software. Realizace centrálního þasového razítkování je zjednodušeno navíc vlastnostmi nástroje
ISM. Podklady pro þasové razítko je možné vzít z adresáĜe /var/nsm/summary/, pĜípadnČ
z /var/nsm/parsed/{date}/. Druhý ze jmenovaných adresáĜĤ obsahuje soubory s log záznamy
rozdČlenými dle pravidel normalizátorĤ a informacemi pĜiĜazenými jednotlivým promČnným. První ze
jmenovaných adresáĜĤ v sobČ skrývá sumární informace.
Varianta druhá, pĜestože první je šetrnČjší k výkonu a kapacitám serveru provádČjícímu sbČr dat, dovoluje zajistit
dĤvČryhodnost (resp. nepopiratelnost pĤvodu). DĤvČryhodnost (a potažmo integrita) je garantována tím, že
nČkterá ze zaĜízení vlastní dvojici podpisových klíþĤ a certifikát. Komplikací mĤže být nesnadnost
implementace, velký objem dat a fakt, že logika a architektura nČkterých zaĜízení takový zásah neumožĖuje.
Realizátor se navíc musí zabývat otázkou, která ze zaĜízení je skuteþnČ smysluplné takto vybavit.
Vzhledem k našim potĜebám jsme zvolili centrální þasové razítkování. Celkové schéma je potom znázornČno na
obrázku þ. 2. Jak je z nČj patrné, je zajištČna þasová autenticita. V nČkterých pĜípadech dĤvČrnost
a dĤvČryhodnost a tím pádem integrita, aþkoliv to z obrázku nevyplývá.
Obrázek 2: Topologie systému (varianta 1)
Systém v takovéto konfiguraci bohužel nedokáže zajistit ani dĤvČrnost veškeré komunikace, protože nČkterá
zaĜízení tuto možnost nenabízejí. V pĜípadČ dĤvČryhodnosti je situace podobná. Bohužel není možné se obecnČ
vyhnout ani pĜípadĤm, kdy útoþník pĜedstírá IP adresu nČkterého ze zaĜízení a posílá mystifikující informace.
Výše uvedené pĜekážky mĤže odbourat realizace systému ve variantČ 2 þasového razítkování.
Problém rovnČž bude tvoĜit možnost škodlivé aktivity administrátora. Ta je však Ĝešitelná vhodnou distribucí
pĜístupových zpráv a rozesláním informace o vybraných operacích (pĜihlášení s úþtem administrátora, vytvoĜení
uživatele, zmČna pĜístupových práv k urþitým souborĤm a pod.) na více jiných zaĜízení v síti schopných tuto
zprávu pĜijmout.
Po propojení systému s nČkterým z nástrojĤ Ĝady „Vulnerability Scanners“ (napĜíklad NESSUS), kterým se však
v tomto þlánku nebudeme zabývat, nám zbývá už jen utkat se s otázkou, jak log správnČ interpretovat
a prezentovat.
159
2.3
Jak log interpretovat a prezentovat
Tato kapitola bude velmi struþná. Jejím obsahem jsou dvČ dĤležitá schémata. Prvním z nich je korelaþní model
nástroje ISM (obrázek þ. 3)
Security
Data
Available
Knowledge
Bases
IntelliTaxonomy
MultiDimensional
Feature
Alert
Managemen
Correlation
Feature Map
Alert
Algorithms
Institutional
Knowledge
Tax. Mapping
Creation
DOS
recon
compromise
misuse
exploit
insecure
auth
anomaly
error
virus
Traffic Flow
Aggregated
RDBMS
(Summary Store)
Auto
Assessment
Window
Compressed
(Parsed Store)
Tab Delimited
Incident
Response
…
Correlation^2
Normalized
Assurance
Views
…
Bitstream
Compressed
(Raw Store)
Bitstream
…
Acquisition
Obrázek 3: Korelaþní model nástroje ISM
Je na nČm uveden zpĤsob, jakým jsou data z logu pĜemČĖovány v informace. Po jeho pochopení a akceptaci má
þtenáĜ pĜehled o tom, které informace mĤže od popisovaného prostĜedí oþekávat, a které naopak systém
poskytnout neumí.
Druhým je prĤmČrný þas a postup aktivit od vzniku a následné detekce útoku, až po jeho klasifikaci a,
pochopitelnČ, zabránČní dalším škodám.
160
Obrázek 4: TCT - Time Critical Targeting (pĜevzato z mateirálĤ spoleþnosti Intellitactics)
Obrázek þ. 4 je, pĜiznejme si optimistickým, odhadem efektivity práce bezpeþnostního týmu a dob odezvy
(pochopitelnČ pĜi použití kombinace vhodných nástrojĤ). PomĤže þtenáĜi posoudit efektivitu investic
vynaložených na vybudování bezpeþnostního dohledového prostĜedí.
3 ZávČr
ZávČrem lze Ĝíci snad jen tolik, že vše skuteþnČ souvisí se vším. Neberme to však jako konstatování nihilistické –
naopak. Díky architektuĜe, kterou jsme bČhem projektu vybudovali, má zákazník nyní jen malý a finanþnČ velice
zajímavý krĤþek k realizaci PKI (digitální podepisování a šifrování s využitím veĜejného klíþe). Nezbývá než
zopakovat, že bezpeþnost je skuteþnČ nikdy nekonþícím procesem. ObzvlášĢ jde-li o vaše data.
[1]
David C. HÁJÍýEK: Electronic notary services, Security and Protection of Information 2003, Technical
Report, Military Academy in Brno, April 2003, Czech Republic, ISBN: 80-85960-50-8, page 55 - 59
161
162
Šifrovací brány arbitrem bezpeþné výmČny dat
ICZ a.s., divize informaþní bezpeþnosti
[email protected]
Princip budování zabezpeþeného kanálu, jež tvoĜí základ komunikaþní bezpeþnosti, je dnes bČžnČ používanou
technologií. Pro zajištČní datového spoje pomocí mechanismĤ kryptografie existuje velké množství specializovaných HW zaĜízení a programových nástrojĤ. Veškerá tato Ĝešení jsou však tČsnČ svázána s použitou
komunikaþní cestou.
Šifrovací brána je oproti bČžným komunikaþním šifrátorĤm aktivním zaĜízením v informaþním systému. Je to
prvek, jehož prostĜednictvím lze realizovat procedury pro uvolnČní a pĜedání informací mimo hranice systému
a naopak i procedury pro pĜíjem a verifikaci informací do systému vstupujících z vnČjšího prostĜedí. Základním
principem zaĜízení je aplikaþní šifrování pĜenášených dat, které je na jedné stranČ doplnČno o funkce pro import
a export dat z konkrétních aplikací v informaþním systému. Na druhé stranČ zaĜízení jsou však data exportována
a importována ve formátu šifrovaných souborĤ, které mohou být automatizovanČ þi manuálnČ pĜedávány do
dalších nezávislých systémĤ napĜíklad prostĜednictvím datového média. PĜi vhodné implementaci tak získáme
prostĜedek, který umožní pĜedávání dat ve tvaru obecných datových souborĤ mezi navzájem oddČlenými
systémy a zároveĖ poskytující mechanismy zajištČní integrity a utajení dat spoleþnČ s jejich automatickým
vstupem do aplikaþních modulĤ uvnitĜ IS.
1 Aplikaþní potĜeby
Použití šifrovacích bran má význam pĜedevším v oblasti pĜedávání utajovaných informací mezi nezávislými
systémy, které jsou vzájemnČ propojeny prostĜednictvím nezabezpeþené komunikaþní linky. Šifrovací brána
slouží v takovém pĜípadČ jednak jako nástroj pro uplatnČní požadavkĤ integrity a utajení pĜenášených dat, ale
hlavním pĜínosem Ĝešení je však možnost implementace dalších funkcí, potĜebných pro vyĜešení problematiky
bezpeþné implementace procedur na uvolĖování a pĜíjem informací z prostĜedí mimo hranice vlastního
informaþního systému.
Z uvedených skuteþností tedy vyplývá, že šifrovací brána není urþena jako náhrada komunikaþního šifrátoru,
který zpravidla propojuje rĤzné þásti jednoho informaþního systému. Brána bude vždy pracovat ve funkci
ochranného hraniþního prvku mezi rĤznými informaþními systémy.
2 Možnosti využití
Pro využití šifrovacích bran existují dvČ základní možnosti jejich nasazení:
x
První možností využití je zajištČní bezpeþné výmČny utajovaných (citlivých) dat mezi rĤznými systémy
za souþasného požadavku realizace pĜenosu prostĜednictvím nezabezpeþeného spoje.
x
Druhou možností je nasazení brány za úþelem bezpeþné realizace procedur uvolĖování neutajovaných
dat ze systému zpracovávajícího utajované skuteþnosti do neutajovaného prostĜedí.
163
3 Návrh architektury
Crypto Gateway
Transmit
module
External
environment
Encrypt
Encryption and
verification module
Verification
Transmit Path
Encryption
Device
Export module
Procedural
block
Communication
block
Application
server
Database
Signalization and
quarantine module
Logs
Splitting
device
Receive
module
Receive Path
Verification
Decrypt
System management
server
Decryption and
verification module
Procedural
block
Communication
block
Import module
Šifrovací brána musí být aktivním zaĜízením v informaþním systému, které je vybudováno na dĤvČryhodné
výpoþetní základnČ a pro svou práci využívá dĤvČryhodný (nejlépe certifikovaný) kryptografický prostĜedek.
VnitĜní architektura zaĜízení musí umožĖovat pĜenos informací obČma smČry a zajistit, že se tyto smČry
nemohou vzájemnČ ovlivĖovat. Základní rozdČlení vnitĜní architektury je proto na pĜijímací a odesílací cestu.
3.1
PĜijímací cesta
PĜijímací cesta zajišĢuje vstup informací z vnČjšího prostĜedí do interních aplikací. Na tento vstup jsou kladeny
podmínky pĜedevším pro zajištČní integrity vstupních dat. PĜijímací cesta je rozdČlena do tĜí samostatných
modulĤ, které spolu vzájemnČ komunikují metodou pĜedávání dat na lokálním souborovém systému. PĜijímací
cesta ve zkratce plní následující funkce:
1.
Bezpeþný vstup dat.
2.
Dešifrování a verifikace integrity pĜijatých dat.
3.
Procedurální testy datové integrity.
4.
Import dat do vnitĜních aplikací.
Vlastní vstup dat do šifrovací brány je realizován „pĜijímacím modulem“. Tento modul aktivním zpĤsobem
naþítá data dovnitĜ šifrovací brány napĜíklad z externího datového média nebo jiného oddČlovacího zaĜízení.
Data nelze aktivnČ vkládat z vnČjšího prostĜedí dovnitĜ šifrovací brány, ale vstup musí být vždy Ĝízen pĜijímacím
modulem. Architektura pĜijímacího modulu je navržena tak, aby vlastní realizace vstupu nemohla ohrozit
funkcionalitu dalších þástí zaĜízení.
PĜijatá data jsou pĜedána „Dešifrovacímu a verifikaþnímu modulu“. Tento modul má za úkol zajistit, že pĜijatá
data budou správnČ dešifrována a garantovat, že byla odeslána autorizovaným odesílatelem a nebyla v prĤbČhu
pĜenosu modifikována. Tyto úlohy jsou realizovány pomocí standardních kryptografických mechanismĤ a veškeré pĜípadné chyby mají za následek pĜedání pĜijatých dat signalizaþnímu a karanténnímu modulu.
SprávnČ dešifrovaná a zkontrolovaná data jsou pĜedána importnímu modulu. Tento modul je prakticky závislý na
konkrétní implementaci zaĜízení. Modul se skládá z procedurálního a komunikaþního bloku, které od sebe
oddČlují þásti, jež jsou zodpovČdné za vlastní import dat do konkrétní aplikace a za realizaci procedur zajišĢující
aplikaþní integritu pĜijatých dat. V praktické realizaci bude komunikaþní blok vkládat pĜedpĜipravená data
pomocí napĜ. ODBC rozhraní do databáze nČkterého aplikaþního serveru v IS. Procedurální blok naproti tomu
bude kontrolovat formát pĜijatých dat, rozsah hodnot a provádČt další funkce jako napĜíklad antivirovou
kontrolu. Veškeré nestandardní stavy a chyby dat zjištČné pĜi kontrolách zpĤsobí pĜedání dat signalizaþnímu
modulu.
164
3.2
Odesílací cesta
Realizace odesílací cesty musí zajistit, že nedojde k nežádoucímu pĜenosu informací z vnitĜku systému mimo
jeho hranice. Tento požadavek je zajištČn tak, že vlastní implementace poskytuje vysokou míru záruk toho, že
veškerá data, která opouští odesílací cestu jsou adekvátním zpĤsobem zašifrována. To v prostĜedí certifikovaných systémĤ znamená, že na výstupu odesílací cesty jsou pouze informace zašifrované certifikovaným
kryptografickým prostĜedkem a tedy se nachází ve tvaru neutajovaných dat. V takovém pĜípadČ zĤstává rizikem
implementace pouze možnost porušení pravidla need-to-know, protože dešifrovací klíþe se nachází jen
v cílovém systému, který musí být rovnČž certifikován na zpracování informací stupnČ utajení, který je do tohoto
systému prostĜednictvím šifrovací brány zasílán. Odesílací cesta ve zkratce plní následující funkce:
1.
Export dat z aplikací.
2.
Procedurální testy datové integrity.
3.
Šifrování a podpis odesílaných dat.
4.
Bezpeþný výstup dat.
Vstup dat do odesílací cesty zajišĢuje „exportní modul“. Tento modul je tČsnČ svázán s konkrétní implementací
obdobnČ jako modul importní. Modul se opČt skládá z procedurálního a komunikaþního bloku. Komunikaþní
blok exportního modulu je obdobný stejnému bloku v modulu importním. Hlavní úlohou exportního modulu je
zajistit, že pĜijatá data jsou získávána ze správného zdroje a nejsou výsledkem nČjakého nežádoucího datového
toku (napĜ. z dĤvodu zavirování sítČ).
Procedurální blok exportního modulu je nejkritiþtČjší þástí celé šifrovací brány. ZpĤsob realizace tohoto bloku
má zásadní vliv na záruky, že se mimo hranice IS dostanou pouze požadovaná data. Modul je zodpovČdný za
verifikaci aplikaþní konzistence odesílaných dat. Návrh musí zajistit, že tyto testy jsou provádČny s dostateþnou
mírou záruk spolehlivosti. V pĜípadČ výskytu chyb pĜi provádČných testech jsou pĜenášená data pĜedána signalizaþnímu modulu.
Šifrovací a verifikaþní modul má za úkol odesílaná data pĜevést do tvaru vhodného pro transport. Prakticky to
znamená, že jsou datové soubory pĜevedeny do tvaru archivu, který je zašifrován a podepsán. K archivu pak
mĤže být pĜi použití PKI pĜipojeno napĜ. CRL, þi jiná data potĜebná pro realizaci kryptografických operací na
pĜijímací stranČ. Po pĜevedení dat do transportního tvaru provede modul jejich následnou verifikaci, která musí
zajistit, že data jsou opravdu správnČ zašifrována a podepsána.
NáslednČ jsou data v transportním tvaru pĜedána odesílacímu modulu, jehož úkolem je zajistit bezpeþný výstup
dat ze zaĜízení šifrovací brány. Aktivita na výstupu musí být vyvolána pouze na stranČ šifrovací brány. Praktickou realizací je ukládání výstupních dat na externí datové médium, þi jejich automatizované pĜedávání na
bezpeþné oddČlovací zaĜízení.
4 VnitĜní dohled
Šifrovací brána je kritickým prvkem systému, protože má k dispozici mechanismy pro realizaci pĜenosĤ dat
mimo hranice systému. Dalším kritickým faktorem je skuteþnost, že realizuje funkce, jejichž výsledek rozhoduje
o tom, jaká data lze ze systému uvolnit a naopak zda data, která do systému vstupují nemohou systému provoznČ
uškodit. Z tČchto dĤvodĤ je nutnou podmínkou bezpeþného provozu implementace mechanismu dohledu v reálném þase. Tento dohled musí zajistit neprodlené odesílání auditních dat mimo vlastní zaĜízení, aby v pĜípadČ
útoku nemohlo dojít k jejich zniþení. Tuto funkcionalitu v pĜípadČ šifrovací brány zajišĢuje „karanténní a signalizaþní modul“, který je navázán na systém centrálního dohledu IS. Modul pĜi bČžném provozu prĤbČžnČ odesílá
logové informace na systém centrálního dohledu. V pĜípadČ výskytu chyby v prĤbČhu testĤ ostatních modulĤ
zajišĢuje informování dohledu a úschovu dat, která chybu zpĤsobila pro pozdČjší vyhodnocení. V pĜípadČ
výskytu kritické situace je modul zodpovČdný za odeslání alertu a vypnutí zaĜízení.
165
166
SSL VPN
VUMS DataCom
RozšíĜená 15, Praha 8, 182 00, tel.:+420-284688680, mail: [email protected]
1 Úvod
PĜístup k informacím 24x7 je dnes samozĜejmým požadavkem.Cesta k jeho zajištČní však pĜináší Ĝadu otázek
a komplikací. Ideální Ĝešení by mČlo vypadat následovnČ, viz obrázek 1.
Obrázek 1. Požadavky na pĜístup k informacím
Každý uživatel by mČl mít pĜístup k libovolné aplikaci a to kdykoliv, odkudkoliv a z libovolného zaĜízení. To
vše bezpeþnČ, jednoduše a s maximálním využitím všeho co je k dispozici. Není problém zajistit pĜístup pro
omezenou skupinu uživatelĤ s firemním notebookem a VPN klientem. RovnČž lze zajistit univerzální pĜístup za
cenu implementace portálu a vývoje webových aplikací. Taková Ĝešení však splní vždy jen þást výše uvedených
kriterií a to z dĤvodu omezení stávajících technologií.
2 SSL VPN
V souþasné dobČ se stále více prosazuje technologie SSL VPN, která dokáže splnit všechny výše uvedené
požadavky.
Protokol Secure Socket Layer byl vyvinut spoleþností Netscape. Jeho základními úkoly jsou zabezpeþení dat
šifrováním a ovČĜení totožnosti uživatele. Dnes je SSL respektive HTTPS souþástí prakticky všech webových
prohlížeþĤ. Proto se þasto mluví o SSL VPN jako „client-less“ technologii, jinými slovy klienta VPN zastoupí
webový prohlížeþ. SSL se nijak zásadnČ neliší od technologie IPSec, používá prakticky stejné algoritmy pro
šifrování i obdobné mechanismy pro ovČĜování uživatele. SSL je však protokol vložený mezi TCP/IP a aplikaþní
vrstvou, viz obrázek 2. Z toho vyplývá nČkolik vČcí. V prvé ĜadČ jednoduchost a univerzálnost používání.
Odpadají problémy napĜíklad s pĜekladem adres (NAT). Na druhé stranČ, díky tomu, že má k aplikacím „blíže“,
dokáže nabídnout mnohem vČtší granularitu z hlediska definování bezpeþnostních pravidel pĜístupu. Mimo jiné
lze pĜesnČ definovat URL pro webový pĜístup.
167
Obrázek 2. IPSec a SSL z pohledu modelĤ OSI a TCP/IP
Velice þasto se SSL VPN srovnává s technologií IPSec. Jedná se o jeho náhradu? Ano, ale ne ve všech
pĜípadech. Jako pomĤcku pro výbČr vhodné technologie lze použít následující tabulku, viz tabulka 1.
Typ aplikace
Typ zaĜízení
Vzdálená síĢ
Typ spojení
Typ VPN
Poboþky
Firemní
Ve správČ,
dĤvČryhodná
Permanentní
IPSec
Mobilní
zamČstnanci
Firemní i cizí
Cizí,
nedĤvČryhodná
Mobilní
SSL VPN
PartneĜi a
zamČstnanci,
extranet
Cizí
Cizí,
nedĤvČryhodná
Mobilní
SSL VPN
Tabulka 1. Volba SSL VPN a IPSec
Pokud se jedná o permanentní spojení mezi centrálou a poboþkou, bezpochyby je správnou volbou IPSec.
V pĜípadČ, že se jedná o pĜístup mobilních uživatelĤ nebo uživatelĤ, které nemáme pĜímo pod kontrolou
(dodavatelé, odbČratelé atd.), tady nabízí SSL VPN Ĝadu výhod. Toto srovnání je však nedostateþné. SSL VPN
pĜináší Ĝešení nejen vzdáleného pĜístupu, ale i extranetu. Odpadá nutnost vytvoĜení DMZ, vývoje webového
rozhraní pro aplikace, implementace portálu apod.
2.1 Výhody SSL VPN
Podívejme se na jednotlivé body v obrázku 1. Co si pod nimi lze pĜedstavit a do jaké míry se jedná o realitu?
2.1.1
Libovolný uživatel
IPSec VPN vyžaduje instalaci klienta. To není problém u vlastních zamČstnancĤ. Dohodnout se však na instalaci
nČjakého software na cizí zaĜízení (dodavatele, odbČratele atd.) je v mnoha pĜípadech neĜešitelné. I v pĜípadČ, že
partner takový požadavek akceptuje, zprovoznit dva IPSec VPN klienty na jednom PC je v naprosté vČtšinČ
pĜípadĤ témČĜ nemožné.
2.1.2
Libovolné místo
Uživatel mĤže pĜistupovat k informacím pomocí SSL VPN kdekoliv se dokáže pĜipojit k internetu – wireless
hot-spot, internetová kavárna. PĜístup je pomocí HTTPS na portu 443, který není prakticky nikde blokován. Jak
jsme zmiĖovali dĜíve, HTTPS rovnČž nemá problém s pĜekladem adres.
168
2.1.3
Libovolné zaĜízení
SSL je podporován všemi webovými prohlížeþi. Výhod SSL VPN mĤže využívat libovolné zaĜízení
s browserem ( PC, notebook, PDA, mobilní telefon atd.). Druhým aspektem pak je i vlastnictví zaĜízení, viz
bod 1.
2.1.4
Libovolná aplikace
Zde je mezi technologií IPSec a SSL VPN nejvČtší rozdíl. IPSec zpĜístupĖuje síĢ, z pohledu aplikací je prakticky
transparentní. SSL VPN funguje jako aplikaþní brána. Uživatel naváže spojení pomocí prohlížeþe s SSL VPN
bránou. Ta ukonþuje HTTPS a smČrem do vnitĜní sítČ komunikuje daným aplikaþní protokolem. Musí tudíž
rozumČt podporovaným aplikacím. To není problém pro webové aplikace, lepší Ĝešení pak podporují sdílení
souborĤ eventuálnČ nČkteré další. V principu však není možné vytvoĜit aplikaþní bránu pro veškeré existující
aplikace. StejnČ tak ne každá aplikace mĤže mít webové rozhraní. Využívá se jednoduchý nápad. Klienti vČtšiny
aplikací (SAP, CITRIX, PC Anywhere atd.) komunikují pĜes konkrétní TCP nebo UDP porty. Staþí tedy
odchytit na vzdáleném zaĜízení komunikaci na tČchto portech, zabalit ji do HTTPS a na druhé stranČ ji pak
transparentnČ rozbalit, viz obrázek 3. To už však prohlížeþ nedokáže. Na vzdáleném zaĜízení tedy musí bČžet
„klient“, který daný provoz bude odchytávat. Padá tedy pojetí „bez klienta“? Ano, ale ne docela. Díky tomu, že
se jedná v podstatČ o lokální pĜesmČrování a používá se JAVA nebo ActiveX plug-in o velikosti v Ĝádu stovek
KB, lze ho dynamicky nahrát pĜi navazování spojení a po ukonþení jej stejným zpĤsobem odstranit. RovnČž je
možné pĜesmČrovat i veškerou síĢovou komunikaci na tĜetí vrstvČ a získat úroveĖ pĜístupu jako u IPSec. Tímto
zpĤsobem lze zajistit podporu opravdu libovolné aplikace.
Obrázek 3. Podpora klient-server aplikací
Pro úplnost je vhodné poznamenat, že v tomto bodČ jsou i nejvČtší rozdíly mezi jednotlivými výrobci.
U mnohých je podpora aplikací omezena napĜíklad pouze na TCP aplikace apod.
2.1.5
Bezpeþnost
Z hlediska zabezpeþení pĜenosu je SSL VPN velmi obdobné jako IPSec, stejné šifrování atd. Z hlediska
granularity pĜístupu je zde naprosto zásadní rozdíl. IPSec pĜedstavuje L3 pĜístup. U SSL VPN lze definovat
velice detailnČ, kdo a kam mĤže a to dynamicky, pro každé jednotlivé spojení. Typické ovČĜení a pĜidČlení role
uživateli pak probíhá v následujících krocích.
JeštČ pĜed samotným pĜihlášením je provČĜeno zda uživatel disponuje digitálním certifikátem, z jakého zaĜízení
pĜistupuje (cizí, vlastní), v jakém stavu je dané PC, zda má aktuální antivir, nahrané bezpeþnostní záplaty atd.
Na základČ toho lze i odmítnout ovČĜení uživatele, tj. uživatel nedostane možnost se pĜihlásit, nebo bude
požadován konkrétní zpĤsob ovČĜení, tĜeba pomocí tokenu. Pak je uživateli pĜidČlena role platná pouze pro toto
konkrétní spojení. Role zahrnuje detailní pĜístupová práva. V pĜíštím spojení se mohou zmČnit, tĜeba na základČ
169
toho, že uživatel neprovedl update antiviru. DĤležitá je i fáze odhlášení. Na vzdáleném PC zĤstává vždy Ĝada
doþasných souborĤ. Ty je potĜeba odstranit. To vše je možné s využitím možností ActiveX nebo JAVA
(obdobnČ fungují napĜíklad Windows update). Tyto možnosti jsou úzce integrovány do SSL VPN brány. Jako
další krok v oblasti bezpeþnosti je dnes integrace na úrovni API s výrobci personálních firewallĤ (Sygate,
TrendMicro atd.).
Samostatnou kapitolu tvoĜí i úroveĖ bezpeþnosti samotného produktu – ICSA a EAL certifikace, provedení
v souladu s FIPS standardy atd.
2.1.6
Jednoduchost
Zde je mínČna pĜedevším jednoduchost z pohledu uživatele. Ten nemusí nic instalovat nebo konfigurovat.
Používá prostĜedí, které je pro nČj známé – prohlížeþ eventuálnČ nativního klienta dané aplikace. Z pohledu
správce se vše nastavuje centrálnČ na úrovni SSL VPN brány. Zde má správce Ĝadu nástrojĤ na definování
pravidel a pĜidČlování rolí. SamozĜejmostí je možnost definovat rĤzné úrovnČ pĜístupu pro správce, možnost
logování veškerých událostí a nezávislého auditu.Samostatnou kapitolu tvoĜí i jednoduchost zpĜístupnČní
vnitĜních aplikací.Odpadá nutnost pĜizpĤsobení aplikací pro web, vytváĜení DMZ, replikace serverĤ do DMZ,
jejich patch management atd. Na minimum se redukuje i potĜeba technického supportu.
2.1.7
Snadná integrace
ěada firem má ve své síti implementováno AAA Ĝešení, adresáĜové služby atd. Bylo by nesmyslné Ĝešit totéž
znovu pro SSL VPN. Nutností je jednoduché navázání na to, co je k dispozici – LDAP, RADIUS, NIS, RSA atd.
2.1.8
Vysoká dostupnost
Jedno zaĜízení pĜedstavuje single point of failure, kritické místo. Pro Ĝešení, které má fungovat 24x7 je nutná
podpora vysoké dostupnosti. Jinými slovy zaĜízení musí být schopno pracovat v clusteru, v ideálním pĜípadČ
i v geografickém clusteru. To znamená, že jednotlivá zaĜízení mohou být umístČna v rĤzných lokalitách.
Výpadek celé jednoho zaĜízení nebo i celé lokality pak neznamená výpadek služby.
3 ZávČr
SSL VPN dokáže vyĜešit prakticky veškeré požadavky na bezpeþný pĜístup. Jde o ideální Ĝešení pro mobilní
uživatele, aĢ už vlastní nebo cizí. PĜináší i zvýšenou bezpeþnost. Mezi výrobci jsou však výrazné rozdíly a je
nutné si dĤkladnČ ovČĜit, nejlépe podle pĜedchozích bodĤ, co je skuteþnČ podporováno. Další informace k této
problematice lze najít na http://www.juniper.net/products/ssl/.
170
Kompletní Ĝízení rizik
Využívání Ĝízení zranitelnosti a hrozeb
Vladimír Brož
[email protected]
McAfee, Inc.
www.mcafee.com
1 Shrnutí
Níže poskytujeme celkový pĜehled vývoje bezpeþnostních hrozeb pro firmy. Zkoumáme, jakým zpĤsobem rĤzné
organizace reagují na novou povahu tČchto hrozeb z hlediska strategie, integrace a proaktivního chování.
Požadavky na bezpeþnost, které vyplynuly z tohoto strategického pĜístupu, upozorĖují stále více vedoucí
pracovníky na nutnost revidovat zpĤsob, jakým pĜidČlují bezpeþnostní zdroje na ochranu kriticky dĤležitých
informací.
2 Úvod
Jak bylo zjištČno ve výzkumu provedeném spoleþností Q&A Research okolo 75% ze 300 dotazovaných IT
manažerĤ vČĜí, že jsou jejich poþítaþové sítČ zabezpeþeny lépe než pĜed rokem. PĜesto 81% z tČchto respondentĤ
zastupujících spoleþnosti s roþními pĜíjmy pĜesahujícími 30 milionĤ dolarĤ potvrdilo nárĤst poþtu útokĤ. Okolo
20% respondentĤ prohlásilo, že se do poþítaþové sítČ jejich spoleþností dokázali dostat hackeĜi. Statistiky ukazují
známou story. Zlí lidé se snaží proniknout do poþítaþĤ velkých i malých spoleþností a poškodit je. DobĜí lidé
pokraþují v neúnavné práci - pĜedvídají a reagují na hrozby tak, jak se postupnČ objevují. S tím, jak se blížíme
polovinČ desetiletí, dochází ke konvergenci urþitých trendĤ. ZásadnČ se mČní povaha hrozeb, kterým organizace
þelí. Stále více vedoucích pracovníkĤ je nuceno mČnit zpĤsob, jakým vybírají bezpeþnostní Ĝešení pro správu
a omezování rizik asociovanými s tČmito hrozbami.
3 MČnící se povaha bezpeþnostních hrozeb
StejnČ jako vše v digitálním svČtČ i úþinnost, sofistikovanost a efektivita
škodlivých programových kódĤ roste geometrickou Ĝadou. Firemní sítČ
musí být schopné reagovat nejen na stále vČtší poþet útokĤ, ale také na
zvyšující se pestrost hrozeb, které se pĜetváĜejí. VytváĜejí hybridní kmeny
virĤ, þervĤ, phishing emaily, nebo jiné škodlivé projevy hackerské
aktivity. Moderní viry mohou sloužit jako základna pro spuštČní þervĤ,
þervy mohou shromažćovat informace pro podvodné phishing emaily. Je
stále obtížnČjší udržovat jasné a þisté kategorie pro zaĜazení jednotlivých
typĤ hrozeb. Veškeré hrozby se rovnČž stávají po technické stránce
inteligentnČjší a nezávislejší. Škodlivé aktivity se zautomatizovaly do té míry, že jediný hacker mĤže mít
mnohonásobnČ vČtší vliv než pĜed pouhým rokem a pĤl. (Tento vliv je dále umocnČn vzrĤstající závislostí firem
na síĢových procesech uvnitĜ organizací a mezi organizacemi a zákazníky.) A v neposlední ĜadČ se komunita
hackerĤ rozrostla (nebo možná dospČla) mimo pĤvodní generaci hackerĤ, jejichž zájem spoþíval pouze
v narušení funkce nČjaké organizace, aby se tím mohli chlubit nebo prokázat svou programátorskou dovednost.
Nejrychleji rostoucí segment hackerské komunity je pohánČn zištnými motivy. HackeĜi své schopnosti využívají
pro aktivity, jejichž úspČch se mČĜí ztrátami jejich obČtí. Dá se to považovat za profesní kriminalizaci
jednotlivých segmentĤ hackerské komunity. Výsledkem tČchto trendĤ je, že stále vČtší procento hrozeb, kterým
jsou organizace vystaveny, je realizováno cílenČjším a strategiþtČjším zpĤsobem.
171
4 Zvyšující se potĜeba nového typu reakce
V posledních mČsících se hodnČ mluvilo a psalo o potĜebČ vyvinout pĜístup k zabezpeþení na bázi Protection-inDepth™. Avšak ménČ bylo uþinČno pro skuteþnou implementaci integrované a proaktivní strategie firemní
bezpeþnosti. Podle nedávného prĤzkumu Harris Interactive mezi spoleþnostmi ze seznamu FORTUNE 1000
existuje stále velká mezera mezi tím, co firmy Ĝíkají, že dČlají, a skuteþnČ pĜijatými opatĜeními pro snížení rizika.
VČtšina z dotazovaných vrcholových manažerĤ udČlila svým organizacím prĤmČrnou známku 2 pĜi popisu
schopnosti reagovat na pĜirozené i lidmi zpĤsobené katastrofy. Hodnocení manažerĤ zodpovČdných za
každodenní bezpeþnostní záležitosti bylo však zcela jiné. Pouze 58 % prohlásilo, že jsou lépe pĜipraveni než pĜed
rokem.
5 Proþ je tomu tak?
OdpovČć je spojena s nástrahami, vztahujícími se k nejbČžnČjším postupĤm, které v oblasti zabezpeþení svých
þinností organizace používají. VČtšina bezpeþnostních þinností spoþívá v nákupu a rozmístČní širokého spektra
jednoúþelových Ĝešení v reakci na specifické hrozby, které se již projevily. PĜestože bylo vyvinuto urþité úsilí pĜi
integraci tČchto Ĝešení, jsou stále pĜíliš rĤznorodé, a pĜedstavují Ĝadu taktických investic a aktivit, jejichž Ĝízení je
nároþné na þas i pracovní sílu. To pomáhá vysvČtlit, proþ bylo ve studii vydané IDC zjištČno, že poptávka po
odbornících na zabezpeþení informací celosvČtovČ poroste v pĜíštích nČkolika letech o 14 % za rok.
(Tzn. dvakrát rychleji než je celkový nárĤst pracovních míst v celé oblasti IT.)
V poslední benchmarkové studii spoleþnosti Nemertes Research byla vČtšina dotazovaných IT manažerĤ
nespokojená s dobou, která trvá antivirovému programu než detekuje novou virovou epidemii a vyhlásí poplach.
Respondenti naznaþili, že zpĤsoby vyhledávání, které umožní zkrátit þas mezi zjištČním a reakcí na potenciální
hrozby, jsou hlavní prioritou pro firemní IT komunitu.
Aby bylo možné reagovat na novou generaci hrozeb pro firemní systémy, je zapotĜebí nová životaschopná
alternativa, které nebude:
•
taktická,
•
jen þistČ reaktivní,
•
nároþná na pracovní sílu.
Zvyšující se poþet a stále vČtší sofistikovanost hrozeb pro firemní sítČ vyžadují,
aby organizace vytvoĜily a trvale aktualizovaly zásady zabezpeþení sítČ,
bezpeþnostní postupy a technologická Ĝešení. Vyžaduje se tedy integrovaný
a proaktivní pĜístup k Ĝízení životního cyklu bezpeþnostních hrozeb, který bude
cílenČ pĜedcházet incidentĤm a bezvadnČ pracovat se systémy, jež dynamicky Ĝídí
a reagují na systémová rizika. S vhodnými integrovanými a proaktivními
bezpeþnostními strategiemi mohou organizace získat víceúrovĖové obranné
systémy, které inteligentnČ pĜidČlují zdroje podle hodnoty a úrovnČ zranitelnosti
majetku. Dobrým výchozím bodem je integrace Ĝízení zranitelnosti (VM –
vulnerability management) s Ĝešeními IPS.
6 ZaþlenČní Ĝízení zranitelnosti
Pro Ĝízení bezpeþnostních síĢových rizik musí být organizace schopná objevit, inventarizovat a stanovit priority
jednotlivých souþástí sítČ. Dále musí organizace shromáždit a analyzovat znalosti o hrozbách a dát je do
souvislosti s jednotlivými síĢovými zaĜízeními. PotĜebný je rovnČž systém sledování a podávání zpráv
o manuálních i automatických nápravných opatĜeních, provedených s cílem identifikovat rizika. VM umožĖuje
systematickou analýzu toho, jak rĤzné složky rizika ovlivĖují firemní digitální prostĜedky. UmožĖuje
organizacím identifikovat, stanovovat priority a omezovat rizika na základČ rovnice ohrožení majetku ze které
vyplyne, jak jsou konkrétní síĢové komponenty pro spoleþnost dĤležité. Pro zavedení strategie VM je nezbytné
porozumČt základním složkám rizika.
172
Pro úþely této zprávy je riziko definováno následující rovnicí:
Riziko = hodnota majetku u zranitelnost u hrozba
Pojmy zranitelnost a hrozba netechniþtí manažeĜi a vedoucí pracovníci þasto používají jako synonyma pro
riziko. To vysvČtluje taktický (založený na Ĝešení na jednom místČ) pĜístup k zabezpeþení, který je pĜijímán
v mnoha oborech. Zranitelnost se vztahuje k aktuálnímu rozmístČní specifických hodnot vzhledem ke
specifickým hrozbám. NapĜíklad, pokud je router špatnČ nakonfigurován nebo na nČm není nainstalována záplata
na obranu pĜed známým virem nebo þervem, je zranitelný vĤþi této hrozbČ. Hrozby se vztahují k rozdČlení
škodlivých programových kódĤ, událostí a incidentĤ. Identifikace nových virĤ (nebo nových verzí þi kmenĤ
virĤ) bude napĜíklad pĜispívat k poþtu hrozeb, o kterých musí organizace vČdČt a být pĜipravena je omezit.
Existují známé a neznámé hrozby.
Pro potĜeby strategického Ĝízení rizika je dĤležité mít jasnou pĜedstavu:
•
o tom, jaké informace jsou kriticky dĤležité pro þinnost spoleþnosti;
•
o míĜe, v jaké jsou kritické prostĜedky zranitelné útokem;
•
o povaze skuteþných hrozeb - aktivního úsilí - vzhledem k pĜístupu, poškození nebo jinému narušení
digitálního majetku.
Pochopení závislostí mezi tČmito tĜemi promČnnými je základem pro rozhodnutí, jak na denním základČ co
nejlépe omezit a reagovat na rizika, se kterými se spoleþnosti setkávají. To reprezentuje základní odchylku od
tradiþních standardních provozních postupĤ vČtšiny bezpeþnostních organizací.
7 Vyzdvihnutí imperativĤ Ĝízení
VM mČní bezpeþnost z magické aktivity, reagující na specifické incidenty a pĜedstavuje základ, ze kterého lze
zavádČt více proaktivní strategii tak, aby se zajistilo, že jsou pro kritické prostĜedky, aplikace a procesy
vyþlenČny bezpeþnostní zdroje soumČĜitelné s jejich významem pro organizaci. NejdramatiþtČjším dĤsledkem
úspČšného zavedení VM bude obnova normálního stavu v bojovém prostoru informaþní bezpeþnosti. Schopnost
proaktivnČ identifikovat oblasti slabých (vysoce rizikových) míst, spíš než následná reakce na zuĜící poplach,
mĤže eliminovat atmosféru ohrožení, která vzniká kdykoliv dojde k sebemenšímu incidentu. Rozumná strategie
VM umožĖuje organizacím stanovit racionální úrovnČ tolerance rizik a pĜimČĜenČ Ĝídit odezvu na tato rizika.
Dovoluje organizacím vytvoĜit zvládnutelnou politiku bezpeþnosti založenou na kvalitČ majetku, který musí být
chránČn, a pĜidČlení odpovídajících zdrojĤ na základČ solidního porozumČní úrovnČ rizika pro organizaci.
„Spoleþnosti, které zavedou proces Ĝízení zranitelnosti
zaznamenají o 90 % ménČ úspČšných útokĤ …“
Mark Nicolett, Gartner
8 PĜemostČní mezery mezi techniky a managementem
Skuteþné snížení zatížení odborníkĤ na zabezpeþení pĜedstavuje integrace a automatizace iniciativ VM a IPS.
Pokud chtČjí organizace identifikovat kriticky dĤležitá zaĜízení, musí stanovit priority jednotlivých aplikací
a vybavení. Musí také identifikovat veškerý majetek, který je vysoce zranitelný. K dispozici jsou automatická
Ĝešení, která umožní stanovit priority majetku a identifikovat rozsah a závažnost zranitelnosti síĢového zaĜízení.
Na základČ standardních a na míru upravených pravidel umožĖují tato Ĝešení stanovit priority majetku rozlišením
mezi servery a pracovními stanicemi, mezi místními a síĢovými aplikacemi. Toto Ĝešení napĜíklad ohodnotí
zaĜízení, na kterém bČží sada webových serverĤ, výše než kanceláĜský poþítaþ sloužící jednomu uživateli. PĜi
spolupráci s Ĝešeními IPS, jsou systémy VM schopné dynamicky reagovat na informace o potenciálních síĢových
hrozbách a automaticky aktualizovat schopnosti IPS. ýím více nápravných akcí provádí IPS automaticky, tím
ménČ lidských nebo manuálních zásahĤ je zapotĜebí. To umožĖuje uspoĜit lidské i technické zdroje a vČnovat je
opodstatnČným aktivitám Ĝízení výjimek. VytvoĜení propojení mezi VM (identifikujícím systémy, jež musí být
chránČny v první ĜadČ a co nejlépe) a ve spojení se strategií IPS (peþlivČ vyváženou pro vynucování
dynamických zásad zabezpeþení v rĤzných þástech sítČ rĤznými avšak vhodnými zpĤsoby) se mĤže významnČ
zlepšit bezpeþnostní pozice firem za souþasného omezení rozsahu potĜebných lidských a technických zdrojĤ.
173
174
Návrh infrastruktury PKI
Ladislav Šolc
Microsoft ýeská a Slovenská republika
Aspekty, které významnČ ovlivĖují práci s digitálními certifikáty jsou napĜíklad zákony, interní pravidla,
standardy a software. V praxi je to systém digitálních certifikátĤ, certifikaþních autorit a dalších registraþních
autorit, které ovČĜují a potvrzují identitu každé strany, která je souþástí elektronických transakcí. Standardy pro
PKI se stále rozvíjejí. I pĜes to, je infrastruktura PKI široce rozšíĜená jako základ elektronické komerce
a bezpeþné komunikace.
Podniková infrastruktura obsahuje celou Ĝadu aplikací, technologií a scénáĜĤ, které závisejí na používání
digitálních certifikátĤ. PĜedtím, než se zaþnou digitální certifikáty používat, je nutné naplánovat a
implementovat infrastrukturu veĜejných klíþĤ (PKI, Public Key Infrastructure). To zahrnuje celou Ĝadu krokĤ. Z
þistČ technolo-gického pohledu jde zejména o konfiguraci jednotlivých parametrĤ, plánování hierarchie
certifikaþních autorit, šablon a vlastností certifikátĤ, s ohledem na aktuální požadavky organizace. Zcela zásadní
vČcí je potom vytvoĜení plánu pro implementaci, správu a zabezpeþení PKI.
1 Základní pohled na proces návrhu PKI
V organizacích se používá velké množství rĤzných technologií, které jsou zcela zásadní pro její správný chod.
MĤže jít napĜíklad o výmČnu informací o veĜejných zakázkách, vzdálený pĜístup k citlivým informacím, elektronický obchod a podobnČ.
Správná implementace PKI, resp. certifikaþních služeb pro vydávání a správu digitálních certifikátĤ, nabízí
cestu, jak tyto kritické interní i externí procesy zabezpeþit.
Implementovaná infrastruktura PKI umožní napĜíklad toto:
x
DigitálnČ podepisovat dokumenty a aplikace.
x
Ochránit elektronickou poštu pĜed neoprávnČným prohlížením.
x
Zabezpeþit komunikaci mezi poþítaþi, i když jsou spojené pĜes nezabezpeþenou síĢ ( napĜ. Internet,
bezdrátová síĢ).
x
RozšíĜit a zlepšit ovČĜení identity uživatelĤ (napĜíklad pomocí þipových karet).
I v pĜípadČ, že Vaše organizace již má nČjak implementovánu PKI nebo její þást, je dobré projít proces
plánování a návrhu. Je tak možné identifikovat, jaké požadavky již jsou vyĜešeny nebo stále þekají na vhodnou
technologii.
2 Základní kroky v návrhu PKI
2.1
Požadavky na digitální certifikát
Jedním z prvních krokĤ je stanovení požadavkĤ na digitální certifikáty.
Základní požadavky na digitální certifikáty se mohou rozdČlit podle následujících oblastí:
Použité aplikace a technologie
x
Aplikace mají specifické požadavky na délky klíþĤ, úþel za kterým byl certifikát vydán, konkrétní
hodnoty v atributech certifikátu a podobnČ.
x
PĜíklady aplikací:
Elektronická pošta a technologie S/MIME (NapĜ. Microsoft Outlook).
Šifrování souborového systému (Encrypted File System).
Šifrovaná komunikace mezi poþítaþi (SSL, IPSEC, PPTP).
175
Certifikáty pro uživatele a poþítaþe
x
Certifikáty jsou vydávány za úþelem identifikace do rĤzných systémĤ nebo pro použití v rĤzných
aplikacích.
x
PĜíklady použití uživatelských certifikátĤ:
PĜihlášení do adresáĜové služby Microsoft Active directory pomocí þipové karty.
Podepisování a šifrování elektronické pošty (napĜ. Microsoft Exchange a Outlook).
PĜístup k webovému serveru pomocí šifrované komunikace (SSL, TLS).
Zabezpeþení pĜístupu k bezdrátové síti (802.1X, RADIUS, Active Directory).
x
PĜíklady použití certifikátĤ pro poþítaþe:
OvČĜení identity serveru a stanice.
Zabezpeþená komunikace pomocí protokolĤ IPSEC.
Zabezpeþení pĜístupu k bezdrátové síti (802.1X, RADIUS, Active Directory).
Zabezpeþení pĜístupu k podnikové síti (802.1X, RADIUS, Active Directory).
VytvoĜení pravidel a postupĤ pro práci s digitálními certifikáty
x
2.2
Certifikáty jsou vydávány za urþitým úþelem, urþitým identitám a na urþitou dobu. Životní cyklus
certifikátu, pĜípady, kdy dojde k ztrátČ nebo zkompromitování, odpovČdné role pro vydávání a zneplatnČní certifikátĤ, zálohu a obnovu klíþĤ a mnoho dalších podrobností, je nutné velmi peþlivČ popsat
a stanovit pravidla a postupy pro práci s certifikáty.
Návrh hierarchie certifikaþních autorit
Pro správné a bezpeþné fungovaní aplikací, které využívají certifikátĤ, je nutné vytvoĜit hierarchii vzájemnČ
propojených certifikaþních autorit. PKI je zpravidla velmi komplexní a proto potĜebuje vícevrstvé uspoĜádání
složené z tzv. koĜenové autority (Root CA) a jedné nebo více podĜízených autorit (Subordinate CA). Tyto autority jsou potom odpovČdné za vydávání, ovČĜování, obnovování a zneplatnČní certifikátĤ.
Typické kroky pĜi návrhu hierarchie a implementace certifikaþních autorit (CA):
Návrh Infrastruktury Certifikaþních autorit
x
Naplánování základních vlastností (umístČní, úþel a další).
x
VýbČr modelu dĤvČry (interní nebo externí provozovatel CA, vzájemné propojení rĤzných CA).
x
Definování rolí v dĤvČryhodném prostĜedí (správci autorit, odpovČdné role za žádosti, schvalování
a vydávání certifikátĤ, záloha a obnova informací a další).
x
Konvence názvĤ certifikaþních autorit (na vydaných certifikátech je jméno autority a v budoucnosti
mĤže tato informace ovlivnit dĤvČru v samotnou službu).
x
UmístČní klíþĤ a databáze certifikaþní autority (klíþe musí být zabezpeþeny, napĜíklad hardwarovými
moduly, databáze mohou þasem pĜekroþit volné místo na systémových oblastech).
RozšíĜení hierarchie o více úrovní
176
x
PĜi plánování hierarchie dojde z pravidla ke zjištČní, že není vhodná jen jediná certifikaþní autorita.
x
Požadavkem na rozšíĜení mĤže být napĜíklad geografická rozdČlení, velké množství certifikátĤ pro
rĤzné úþely, spojení s další organizací a podobnČ.
2.3
Stanovení vlastností certifikátĤ
Po implementaci infrastruktury CA je možné zaþít s definicí vlastností jednotlivých certifikátĤ. Vlastnosti musí
odpovídat potĜebám uživatelĤ a bezpeþnostním požadavkĤm organizace.
Které kroky je nutné použít pĜi stanovení vlastností certifikátĤ?
VýbČr nebo vytvoĜení potĜebných šablon
x
Certifikáty se vydávají na základČ šablon s definovanými vlastnostmi.
x
Jde o stanovení délky klíþĤ, zálohu klíþĤ, dobu platnosti a podobnČ.
x
Ne každá certifikaþní autorita nabízí možnost tvorby vlastních šablon.
Zabezpeþení certifikátĤ
x
Je dobré rozdČlit rĤzným rolím oprávnČní pro žádost o certifikát, schválení certifikátu, vydání
certifikátu a zneplatnČní certifikátu.
x
Nastavení oprávnČní a pokus o zmČnu by mČlo podléhat auditu.
2.4
Plán pro práci s certifikáty
Jakmile je dokonþena konfigurace vlastností certifikátĤ, je možné certifikáty vydávat. Je však nutné, aby byl
vytvoĜen plán správu certifikátu bČhem jejich životního cyklu.
Následující oblasti by mČl plán pro práci s certifikáty rozhodnČ zahrnovat:
ZpĤsob žádosti o certifikát a zpĤsob obnovení vydaného certifikátu
x
Žádost o certifikát mĤže probíhat nČkolik zpĤsoby. V prostĜedí PKI založeném na systému Windows
Server 2003, má uživatel možnost žádat o certifikát sám, mĤže jej získat automaticky nebo za nČj
požádá držitel speciální role
x
Žádat je možné prostĜednictvím webového formuláĜe, speciální aplikace, skriptu nebo automaticky
s využitím systémových politik.
x
Automatické vydávání certifikátĤ je možné i pro poþítaþe ve firemní síti.
x
Potom, co je žádost uskuteþnČna, je možné certifikát vydat ihned (využívá se pĜed-ovČĜení protokolem
Kerberos), nebo poþkat na schválení odpovČdnou rolí.
Propojení uživatelských úþtĤ s certifikáty
x
AdresáĜové služby, jako je Active Directory, obsahují velké množství informací o uživatelských úþtech
v jednotlivých atributech. I certifikáty mohou být uloženy v jednom z tČchto atributĤ. Ostatní aplikace
zaþlenČné do adresáĜové služby, tak mohou certifikáty jednoduše využít.
VytvoĜení pravidel pro zneplatnČní certifikátĤ
x
Každodenní realitou je ztráta certifikátĤ nebo dalších citlivých þástí. Je proto velmi þastým požadavkem
zneplatnit vydané certifikáty, ještČ dĜíve, než vyprší jejich doba platnosti. V tomto kroku se musí
stanovit, kde se budou nacházet seznamy zneplatnČných certifikátĤ, jak se s nimi bude pracovat a jakou
roli budou hrát pĜi provozování PKI služeb
Plán pro zálohu a obnovu certifikátĤ, jejich klíþĤ a dalších údajĤ
x
StejnČ jako zálohování certifikaþní databáze, je nutné zálohovat informace o certifikátech. Jde pĜedevším o vlastní seznamy vydaných certifikátĤ, jejich klíþĤ a seznamy zneplatnČných certifikátĤ.
x
NČkteré certifikáty, napĜíklad certifikáty vydané za úþelem šifrování, mají jiná pravidla pro zálohování.
U tČchto certifikátĤ se zálohují (archivují) privátní klíþe bezprostĜednČ po vydání tak, aby v pĜípadČ
ztráty mohl být privátní klíþ obnoven. Uživatel potom mĤže dešifrovat potĜebné informace. Pro obnovu
privátních klíþĤ je zpravidla tĜeba administrativnČ ošetĜit, kdo bude mít potĜebná oprávnČní. MĤže to
být i více samostatných osob.
177
3 Nasazení PKI
Návrh, plán, testování v laboratoĜi a pilotní projekt je hotov. Je tedy možné zaþít s implementací PKI do produkþního prostĜedí. Disciplinovaný pĜístup pĜi nasazování PKI je naprosto základním pĜedpokladem úspČchu
bezpeþného prostĜedí a fungujících aplikací.
1.
Naplánování jednotlivých milníkĤ
2.
Instalace služeb certifikaþních autorit
3.
Konfigurace CDP a AIA
4.
Šablony certifikátĤ
5.
Pravidla pro vydávání a revokování certifikátĤ
6.
Systémová pravidla pro PKI, skupinové politiky
7.
UmístČní CRL
8.
VytvoĜení rolí pro správu CA
9.
Vydávání certifikátĤ
Dá se Ĝíci, že vČtšina þasu vČnovaná PKI se sestává z plánování. Vlastní implementace technologií zabere
podstatnČ ménČ þasu a v pĜípadČ prostĜedí Microsoft Windows Server 2003 jde také o minimální investice do
softwarového vybavení. Proto je dĤraznČ doporuþeno dokonþit proces plánování pĜed tím, než se zaþne s
implementací PKI.
Certifikaþní služby v produktu Microsoft Windows Server 2003 splĖují všechny požadavky, které mĤže pĜinést
proces plánování PKI. V souþasné dobČ probíhá certifikace Common Criteria na úroveĖ EAL4+. Jednou
významnou výhodou je také to, že tyto služby jsou standardní souþástí produktu a není tedy tĜeba platit za další
softwarové vybavení nebo licence. To pĜedstavuje proti ostatním komerþním Ĝešením podstatné snížení investic.
Leckdy i v Ĝádech miliónĤ korun.
4 Další zdroje:
[1]
Public key infrastructure overview – http://www.microsoft.com/pki/
[2]
Public Key Infrastructure for Windows Server 2003 –
http://www.microsoft.com/windowsserver2003/technologies/pki/default.mspx
[3]
Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure –
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/ws3pkibp.msp
x
178
Bezpeþnost a moderní databázové systémy
Petr Paukner
Oracle Czech, s.r.o.
Konsolidace aplikací a dat se stává prvoĜadým cílem celé Ĝady organizací. Tuto tendenci umožĖuje neustále se
zvyšující výpoþetní výkon a pĜenosová kapacita sítí, spolu s moderními pamČĢovými systémy. PĜednosti
konsolidace jsou zĜejmé a patĜí k nim, kromČ jiného, snížené náklady na IT infrastrukturu a lepší prostĜedí pro
podporu rozhodování (business inteligence).
Zlepšuje se však v konsolidovaném prostĜedí také bezpeþnost? Je opravdu možné mít pod kontrolou ochranu
osobních údajĤ? Nebyl jeden ze základních principĤ zabezpeþení informaþních systémĤ – princip poskytovat
pouze informace nutné pro vykonávání urþité þinnosti – jen dĤsledkem pĜedchozí fragmentace dat
v distribuovaných systémech? Rychlý nárĤst uživatelĤ z relativnČ malých skupin provČĜitelných zamČstnancĤ,
pĜistupujících k aplikacím v rámci lokálních sítí, k souþasnému stavu, kdy þasto pĜistupují tisíce uživatelĤ
k systémĤm pĜes internet, uþinil správu identit klíþovou komponentou bezpeþnostní architektury.
Navíc se objevují stále nové požadavky na vyšší míru zabezpeþení vývoje a provozu aplikací z hlediska
bezpeþnosti. NČkteré z tČchto požadavkĤ jsou dĤsledkem zmČn v infrastruktuĜe organizací, jiné jsou diktovány
novými legislativními požadavky. K tČm patĜí napĜíklad požadavky na ochranu osobních údajĤ, povinnost
informovat zákazníka (obþana) o možném ohrožení osobních dat, ochrana informací o pacientech (HIPAA)
a v neposlední ĜadČ zákony zajišĢující vyšší transparentnost mezinárodního obchodního a podnikatelského
prostĜedí (napĜ. zákon Sarbanes-Oxley). V uplynulých letech se dramaticky zvýšila informovanost
o problematice ochrany informací, ale souþasnČ se také výraznČ rozšíĜila potenciální ohrožení informaþních
systémĤ. Všichni zúþastnČní, tvĤrci aplikací, dodavatelé, integrátoĜi, zákazníci i jejich partneĜi by mČli vČnovat
zvýšenou pozornost problematice Ĝízení pĜístupĤ, prokazatelnosti a bezpeþnému provozu informaþních systémĤ.
V tomto þlánku se budeme zabývat možnostmi, které jim k tomu poskytují moderní databázové systémy.
1 Dodavatelé databází a bezpeþnost
Bezpeþnost se stala dĤležitým prvkem pĜi koncipování prvních komerþních relaþních databází firmami Oracle
a IBM na konci osmdesátých let. PĜední dodavatelé si vytvoĜili pracovní skupiny se zákazníky s vysokými
nároky na bezpeþnost. Toto vzájemné ovlivĖování umožnilo vytvoĜit z relaþních databází jednu z nejbezpeþnČjších komponent informaþních technologií. Urþitou formu záruky bezpeþnosti nabízených databázových
systémĤ poskytuje zákazníkĤm propracovaný systém nezávislých bezpeþnostních certifikací, které dosvČdþují
soulad s mezinárodními kriterii (napĜ. Common Criteria, ISO 15 408).
Moderní databázové systémy poskytují rozšíĜené bezpeþnostní funkce typu konceptu virtuální privátní databáze,
odstupĖovaného auditingu, enkrypce vybraných dat, bezpeþných aplikaþních rolí a globálního aplikaþního
kontextu. Pro zvýšení bezpeþnosti celé infrastruktury IS Ĝeší moderní databáze také problematiku silné
autentizace uživatelĤ a komponent v síti a enkrypce dat pĜi pĜenosech. V neposlední ĜadČ je bezpeþnost databází
tČsnČ spjata s komplexní správou identit uživatelĤ.
2 Správa identit uživatelĤ
Správa identit je proces, pomocí kterého je Ĝízen proces kompletního životního cyklu bezpeþné identifikace
uživatelĤ a komponent IS v dané organizaci. Správou identit se nejþastČji chápe správa aplikaþních uživatelĤ,
kde jednotlivé kroky zahrnují vytvoĜení úþtu, pozastavení jeho platnosti, zmČnu pĜístupových práv a zrušení
úþtu. Správa identit se však neomezuje jen na uživatele, ale zahrnuje i síĢové entity – zaĜízení, procesy, aplikace,
zkrátka vše co potĜebuje interagovat v síĢovém prostĜedí. Entity Ĝízené správou identit mohou zahrnovat
i uživatele mimo organizaci, napĜ. zákazníky, obchodní partnery, ale také webové služby.
Bezpeþnostní politiky Ĝídící pĜístupová práva mohou být konsistentnČ aplikována na všechny uživatele všech
aplikací za pĜedpokladu, že jsou uživatelé spravováni v jednom centralizovaném a zabezpeþeném úložišti
(repository).
Správa identit (Identity Management) pĜedstavuje dne s u pĜedních dodavatelĤ databází (tj. Oracle, IBM
a Microsoft) integrovanou komponentu správy infrastruktury. Správa identit dnes zpravidla zahrnuje adresáĜové
služby (na standardu LDAP), nástroje pro integraci adresáĜĤ, služby poĜízení a vybavení. ProstĜedí Oracle
179
Identity Management navíc poskytuje napĜíklad nástroje pro možnost delegování administrátorských þinností,
autentizaþní a certifikaþní služby a integrovanou certifikaþní autoritu. Klíþové požadavky na správu identit jsou:
x
Robustnost a škálovatelný výkon.
x
Snadná integrace s aplikacemi a službami.
x
Nástroje pro centrální správu uživatelĤ a síĢových entit.
x
Soulad s otevĜenými standardy.
x
Interoperabilita s Ĝešeními jiných dodavatelĤ (napĜ. certifikaþními autoritami).
3 ěízení pĜístupĤ, prokazatelnost a odpovČdnost
Konsolidace dat a pĜistup pĜes internet umožĖují organizacím využívat témČĜ neomezené možnosti pro
zvyšování efektivity, ale pĜinášejí také nové bezpeþnostní problémy. RozšíĜené možnosti pĜístupu k datĤm
vyžadují jemnČ odstupĖovaná pĜístupová práva. Organizace dnes mají þasto omezené informace o uživatelích,
kteĜí pĜistupují k jejich systémĤm. Dokonce i v pĜípadČ, že tyto informace mají, mĤže být pro organizace obtížné
zcela zabránit uživatelĤm pĜistupovat k informacím v rozporu s bezpeþnostními pravidly dané organizace. Je
proto dĤležité mít k dispozici nástroje, které umožĖují Ĝídit pĜístup k citlivým informacím a zamezit
nepovolenému pĜístupu k takovým informacím.
Moderní relaþní databázové systémy proto umožĖují omezit pĜístup pouze k urþitým ĜádkĤm databázových
tabulek. Co to ve skuteþnosti znamená? Tradiþní databázové systémy urþovaly pĜístupová práva na úrovni
objektĤ (tabulek). Moderní integrované komponenty (napĜ. Oracle Label Security) umožĖují vynucenČ omezit
pĜístup k pouze k urþitým ĜádkĤm vybraných sloupcĤ databázových tabulek. NapĜíklad obsahuje-li nČkterá
databázová tabulka data o zamČstnancích a jejich platech, umožĖuje tento mechanismus omezit pĜístup daného
zamČstnance jen na Ĝádku obsahující jeho vlastní údaje (v pĜípadČ managerĤ napĜ. jen na jejich podĜízené). Tento
mechanismus se mĤže zapínat automaticky v situaci, kdy je vyžadován pĜístup k informaci o platech a být
vypnut u dotazĤ, které nevyžadují žádnou chránČnou informaci.
Správa úrovní pĜidČlených pĜístupových práv (security clearances) je propojena se správou identit, v jejichž
adresáĜích se také informace o pĜístupových právech udržuje. To umožĖuje zjednodušení aplikací s tím, že
bezpeþnostní pravidla chránící citlivé informace jsou realizována uvnitĜ databáze a nekomplikují vrstvu aplikací.
OdstraĖuje se tím napĜíklad tradiþní problém nedostateþné ochrany dat, v pĜípadČ, že se k nim pĜistupuje
analytickým nástrojem mimo aplikace, které se doposud staraly o zabezpeþení.
4 Auditing
Další úrovní ochrany je auditing, který umožĖuje vylepšit ochranu informaþních systémĤ ve vetší hloubce.
NČkteré aplikace mají speciální požadavky na evidování þasu a identity osob, zpĜístupĖovaných dat
a zaznamenání pĜípadných modifikací. Zaznamenávání informací z prĤbČžného auditingu je nejužiteþnČjším
nástrojem pro detekci anomálií a poskytování dat k forenzním analýzám. UmožĖuje také zajistit požadavek
nepopiratelnosti pĤvodu jednotlivých transakcí nebo událostí.
Databáze typu IBM DB2 a Oracle poskytují pokroþilé vestavČné auditovací nástroje, umožĖující jednotný
pohled na standardní informaci z auditu a podrobnČjší informace, jdoucí až na úroveĖ jednotlivých update,
delete a insert operací. Také auditovací mechanismy jsou dnes zpravidla svázány s identitami uživatelĤ
udržovanými a adresáĜových službách správy identit.
Problematika auditingu vystupuje do popĜedí zvláštČ pĜi pĜechodu na moderní 3-vrstvé aplikace. VČtšina tČchto
aplikací totiž autentizuje uživatele proti stĜední vrstvČ (aplikaþnímu serveru nebo transakþnímu monitoru), která
se poté pĜipojuje k databázi jako privilegovaný super-uživatel, který vykonává všechny aktivity iniciované
koncovými uživateli. Souþasné databázové systémy proto ve spojení s aplikaþními servery (IBM WebSphere,
Oracle Aplication Server) poskytují zachování identity skuteþného koncového uživatele i pĜes stĜední vrstvu.
Tím mĤže být zajištČn konsistentní auditing všech akcí uživatelĤ bez ohledu na to, pĜes jaké vrstvy infrastruktury
byly vykonány.
180
5 Proxy autentizace
Možná nejdĤležitČjší bezpeþnostní vlastností v prostĜedí 3-vrstvých architektur je schopnost autentizovat identitu
uživatelĤ pĜes proxy komponentu až do databáze. Každá komponenta stĜední vrstvy mĤže mít delegováno právo
autentizace a vykonávání operací pro specifickou skupinu koncových uživatelĤ (informaþní portál, elektronický
obchod, intranetový business intelligence portál atd.). Proxy autentizace umožĖuje implementovat model
„omezené dĤvČryhodnosti“ pro jednotlivé servery stĜední vrstvy a tím odstranit problém plnČ privilegované
stĜední vrstvy. To znamená, že je možné pĜiĜadit vyšší práva vybraným aplikaþním serverĤm (napĜ. umístČným
uvnitĜ firemního prostĜedí chránČného firewallem) a omezit práva ostatních serverĤ (a jejich uživatelĤ). Pro
úþely takovéto autentizace je možné využít rozšíĜení pomocí jednoznaþného jména uživatele (Distinguished
Name), pĜípadnČ plných digitálních certifikátĤ (X.509).
Proxy autentizace aplikaþních uživatelĤ je zvláštČ cenná pro prostĜedí e-business aplikací s tisíci uživateli,
protože zajišĢuje chránČný pĜístup k datĤm na úrovni jednotlivých uživatelĤ a vyhovuje také vysokým nárokĤm
a výkon a robustnost takového prostĜedí.
6 Ochrana databází v síĢovém prostĜedí
Nástroje zabezpeþení databází v síti umožĖují organizacím vytváĜet Ĝešení, která zajišĢují komunikaci mezi
databázemi chránČnými komunikaþními kanály a dovolují selektivnČ enkryptovat data v databázích.
Distribuované databáze poskytují jistou míru ochrany svým fyzickým oddČlením. Informace spravované
jednotlivými jednotkami (obchod, marketing, výroba, distribuce atd.) jsou þasto zpracovávány separátními
databázemi – vznikají tak povČstné „ostrovy informací“. Toto oddČlení þasto omezuje možnost plnČ využít
informaþní bohatství dané organizace napĜíklad pro analytické úþely. Zvyšování hodnoty konsolidovaných dat
pro oprávnČné uživatele zvyšuje však bohužel i jejich hodnotu v pĜípadČ jejich zneužití pĜi neoprávnČném
pĜístupu. Moderní databáze využívají kombinované schéma zajištČní autentizace, pĜístupových práv a auditu,
spojené s integrovanými mechanismy automatické enkrypce dat pĜenášených v síti a mechanismĤ silné
autentizace.
VestavČné algoritmy pro enkrypci a integritu dat nevyžadují využívání certifikaþní autority. S každou novou
verzí databází od pĜedních dodavatelĤ jsou podporovány nejnovČjší enkrypþní mechanismy. Posledním
doplĖkem provČĜeným v IT prĤmyslu je standard AES (Advanced Encryption Standard). Podporovány jsou
obvykle standardy AES, RC4, 3DES, MD5 a SHA1.
7 Bezpeþnostní certifikace
V oblasti bezpeþnosti bohužel neexistuje pĜímý ekvivalent srovnávacího benchmarku jako jsou napĜ. TPC
benchmarky. NaštČstí však existují mezinárodní standardy typu International Common Criteria (ISO 15 408).
Zákazníci vyžadují produkty a systémy, které umožní plnČní jejich cílĤ, vþetnČ zajištČní urþité úrovnČ
zabezpeþení. Dodavatelé jsou nuceni navrhovat a vyvíjet bezpeþné systémy, které drží krok s rychle se mČnícím
IT prostĜedím a bezpeþnostními hrozbami. Zcela zákonitČ se proto ozývají následující otázky:
x
Jak si mohou zákazníci vybírat mezi produkty s ohledem na bezpeþnostní perspektivy?
x
Jaká jsou mČĜítka a standardy, pomocí kterých mohou být mČĜeny jednotlivé produkty z hlediska
kvality jejich bezpeþnostních mechanismĤ?
x
Kde a jak lze nalézt potvrzení jednotlivých dodavatelĤ ohlednČ bezpeþnostní robustnosti jejich
produktĤ?
Zde hrají dĤležitou roli bezpeþnostní ohodnocení (evaluace) a bezpeþnostní provČĜení pro stanovení hodnoty
jednotlivých produktĤ z hlediska bezpeþnosti. Bezpeþnostní ohodnocení poskytuje formální mČĜítko, oproti
kterému mĤže být daný produkt nebo systém certifikován, a tím potvrzeno, že splĖuje požadované mezinárodní
bezpeþnostní standardy. Celý proces je provádČn nezávislými (avšak autorizovanými a akreditovanými)
organizacemi.
Jednotliví dodavatelé IT produktĤ vČnují rĤznou míru investic do iniciování a podpory procesĤ bezpeþnostního
ohodnocování svých produktĤ. Výsledky takových certifikací pak nastavují uživatelĤm tČchto produktĤ úroveĖ
dĤvČry v kvalitu designu, implementace a fungování vestavČných bezpeþnostních mechanismĤ. Systémoví
integrátoĜi navíc získávají možnost vybrat vhodné komerþní produkty a integrovat je do systémĤ s požadovanou
urþitou úrovní bezpeþnosti.
181
Mezinárodní Common Criteria for Information Technology Security Evaluation (þasto odkazovaná jen jako
Common Criteria, pĜíp. CC) jsou výsledkem snahy o sjednocení (nejenom) amerických a evropských standardĤ.
Výsledkem je, že tato kriteria byla pĜijata v roce 1999 jako mezinárodní ISO norma (ISO 15408), který
nahrazuje starší US TCSEC a ITSEC kriteria.
Common Criteria zjednodušila výše uvedené procesy a stala se proto celosvČtovým standardem s cílem
vzájemného uznávání certifikátĤ podle CC kriterií jednotlivými þlenskými státy EU a NATO.
8 Shrnutí
Moderní databázové systémy pozvedly Ĝešení bezpeþnosti dat na novou úroveĖ. Nezávislé bezpeþnostní
certifikace na stranČ jedné a spolupráce dodavatelĤ databází a nároþnými uživateli na stranČ druhé pĜinášejí
ovoce ve vyšší míĜe dĤvČryhodnosti databázových technologií. Robustní podpora nástrojĤ jako je integrovaná
správa identit, jemnČ odstupĖovaný auditing, ochrana dat na úrovni Ĝádky, víceúrovĖová bezpeþnost, integrované
certifikaþní autority a selektivní enkrypce dat v databázi jsou jen þástí bezpeþnostních mechanismĤ využívaných
v moderních databázích. Provázaností uvedených mechanismĤ tvoĜí objektovČ-relaþní databáze ideální
platformu pro vytváĜení a provoz zabezpeþených aplikací v dnešním komplexním prostĜedí svČta propojeného
internetem.
182
Ochrana pĜístupu k aplikacím
REKONix
Karafiátová 60, Praha 10, 106 00, http://www.rekonix.cz
1 Úvod
Každý den se setkáváme s problémem bezpeþnosti pĜístupu ke službám na našich serverech, aĢ už z vnitĜní sítČ
nebo vzdálenČ pĜes internet. V osobním styku mĤžeme identifikovat druhou strany dle tváĜe nebo dle povČĜovacího dokumentu þi prĤkazu. V okamžiku, kdy dochází k elektronickému pĜístupu, je ovČĜení identity (identifikace, autentizace) obtížnČjší, protože identifikace mĤže být pravá nebo podvržená.
2 Metody ovČĜování identity uživatelĤ (autentizace)
PĜístup statickými hesly, nejobvyklejší metoda autentizace uživatele, je založen na jménČ uživatele a k nČmu
pĜíslušejícímu heslu. Dnes již tato autentizace není dostateþná a proto pĜicházejí pokroþilé metody autentizace.
V tomto pĜíspČvku pĜedstavujeme produkt Stadrin®, který je založen na technologiích spoleþnosti VASCO®
Data Security. PĜi ovČĜení identity uživatele statickým heslem je hlavním problém v mechanismu, jak udržet toto
heslo v tajno-sti a zachovat tak jeho bezpeþnost. Protože heslo je hlavní ovČĜovací údaj uživatele, je tĜeba zajistit,
že toto heslo zná pouze oprávnČný uživatel a nikdo jiný.
Protože hesla jsou obvykle spravována samotnými uživateli, jsou þasto velmi slabá, pĜedevším pak založená na
osobních údajích, jménech dČtí, zvíĜecích þi osobních miláþkĤ, datech narození a podobnČ. Tak je velmi snadné
je uhodnout a zneužít. NČkdy je situace lepší a uživatelé si skládají hesla z kombinací slov, þísel a zkratek.
Bohužel stále existuje hrozba odhalit hesla brutálními metodami útoku na ovČĜovací mechanismy podporovanými více þi ménČ dokonalými slovníkovými metodami. Se stále výkonnČjšími poþítaþi a rychlejšími sítČmi je
tento zpĤsob snazší. Statické heslo je bezpeþné pouze pokud není nikde uchována jeho kopie, není zaznamenáno
v digitální þi papírové podobČ nebo není pĜilepené na monitoru.
I v pĜípadČ, že máme silné statické heslo a je bezpeþnČ uložené, problém není stále zažehnán, protože bezpeþnost
mĤže být ohrožena dalšími faktory. Lze si snadno pĜedstavit trojského konČ, který zaznamenává naši aktivitu na
klávesnici a odesílá tyto záznamy potenciálnímu útoþníkovi. Dalším rizikem je odposlouchávání síĢové komunikace a získání hesla, které je v ten okamžik posíláno v nezašifrované podobČ.
ýasto staþí, když se nČkomu podíváme pĜes rameno a odeþteme, co zadává na klávesnici. Podobná je situace
i v pĜípadČ, kdy používáme magnetické karty, smart karty nebo biometrická zaĜízení. Je to proto, že heslo které
se pĜenáší od klienta k serveru pĜes komunikaþní kanál, je stále statické. Je možné Ĝešit tento problém?
SamozĜejmČ, že ano! Pojćme se podívat, jak snadné je Ĝešení takové situace. Kdykoli potĜebujeme zvýšit
bezpeþnost autentizace uživatele, mĤžeme použít dynamická (jednorázovČ použitá) hesla, tzv. OTP (One Time
Password). S touto metodou ovČĜování se dnes bČžnČ setkáme v bankovním a finanþním sektoru, kde data mají
skuteþnou vyþíslitelnou hodnotu. I v pĜípadČ, že je heslo vyzrazeno, nebo tĜeba odchyceno z klávesnice, není
bezpeþnost kompromitována, protože pro každé další použití je generováno nové heslo.
MĤžeme využít nČkolik metod (zpĤsobĤ, politik) pĜidČlování jednorázových hesel, vþetnČ pĜeddefinovaných
sekvencí OTP, speciálních softwarových komponent nebo hardwarových autentizaþních kalkulátorĤ, které jsou
dnes nepreferovanČjší metodou.
3 Zvýšení bezpeþnosti jednorázových hesel (OTP)
Ke zvýšení bezpeþnosti OTP je možné rozšíĜit autentizaþní proces nČkolika dalšími faktory. NejþastČji se
využívá PIN (Personal Identification Number) a výzva serveru (challenge). Pro ovČĜení, že jednorázové heslo
skuteþnČ pochází od dĤvČryhodné strany, server po obdržení uživatelského jména vygeneruje výzvu (challenge),
která vstupuje do procesu generování jednorázového hesla jako jeden z faktorĤ. Výzva je bČžnČ pĜenášena
použitím stejného komunikaþního kanálu, ale pro zvýšení úrovnČ bezpeþ-nosti je možné použít jiné komunikaþní
kanály, jako napĜíklad GSM SMS a podobnČ.
183
4 Možný kompromis
Jiná úroveĖ autentizace pĜístupu je použití kompromisní metody. NejznámČjším systémem je použití pĜeddefinovaných hesel (rozdílných pro každého uživatele) které jsou organizovány do maticové struktury. ObecnČ se
tato metoda nazývá „Grid Card“, kde každé políþko je reprezentováno oznaþením Ĝádku a sloupce. Každá tato
buĖka obsahuje tzv. Quasi One Time Password (QOTP). Server po pĜijetí uživatelského jména vyšle výzvu
(napĜíklad C4). Uživatel na základČ této výzvy použije heslo z matice QOTP a toto využije jako svoji identifikaci. V principu tento proces funguje jako autentizace dynamickým heslem.
5 Reálné Ĝešení
Na þeském i celosvČtovém trhu je Ĝada produktĤ, které v rĤzné šíĜi a na odlišných technologických platformách
pĜinášejí Ĝešení autentizace jednorázovými hesly. Spoleþnost REKONix uvedla na celosvČtový trh vlastní
produkt Stadrin® (http://www.stadrin.com) pro platformu operaþního systému Linux (Red Hat, Novell SuSE,
aj.). Produkt je založen na široce rozšíĜené autentizaþní architektuĜe PAM (Pluggable Authentication Module).
Tento produkt ve spojení s PAM architekturou pĜináší implementaci OTP do existujících systému bez nutnosti
modifikace aplikací a služeb. Vrstva PAM byla zvolena pro její rozšíĜenost. Systém je založený na použití
Stadrin® PAM modulu a autentizaþních kalkulátorech Digipass od spoleþnosti Vasco Data Security.
Obr 1: Základní typy tokenĤ firmy Vasco.
6 Autentizaþní kalkulátory
Pro generování jedorázových hesel Stadrin® využívá širokou Ĝadu autentizaþních kalkulátorĤ spoleþnosti Vasco.
Tyto kalkulátory bČžnČ nazýváme “tokeny”. Tokeny jsou vlastnČ terminály, které používá uživatel ke generování
hesla pro autentizaþní proces.
Vasco tokeny se používají po celém svČte již mnoho let a je tedy ovČĜená jejich odolnost proti zniþení, dlouhá
životnost a nízká poruchovost. Jsou velmi vhodné pro denní používání. Úloha tokenu je držet uživatelovy specifické informace (jednoznaþný identifikátor) a generovat hesla pomocí šifrovacího algoritmu na základČ vstupních dat. Vstupními daty pro šifrovací algoritmus jsou unikátní uživatelské informace uložené v tokenu, data
zadaná uživatelem z klávesnice a aktuální þas. Tato data vstupují jako parametry do 3DES šifrovacího algoritmu
a výsledek je zobrazen na displeji tokenu (viz obrázek výše). Token je chránČn proti zneužití uživatelsky
definovatelným PINem v závislosti na použitém tokenu.
7 Serverová strana
Server využívá implementaci Stadrin® PAM modulu, který využívá databázi pro uložení uživatelských dat
a informací o tokenech. Jako databázi lze zvolit úložištČ LDAP, MySQL nebo jinou datovou základnu dostupnou
pĜes ODBC rozhraní. Úloha administrátora je nadefinovat vazby mezi tokeny a uživateli systému a pĜiĜazení
metod autentizace jednotlivým službám, které chceme chránit. Je možné pĜiĜadit token více uživatelĤm a tak
umožnit jedné fyzické osobČ pĜistupovat k sytému v rĤzných uživatelských þi administrátorských rolích. Systém
mĤžeme nakonfigurovat pro využití tĜí autentizaþních metod – viz dále kap. 9, 10 a 11.
184
8 Metoda 1
Na bČžících systémech poskytujících služby a sdílené zdroje je možná autentizace statickým heslem. Je to
standardní metoda autentizace použitá v PAM architektuĜe. Pro první krok pĜi implementaci je možné autentizovat jen vybrané uživatele (zvýšená bezpeþnost) pomocí tokenĤ a zbytek uživatelĤ autentizovat dosavadní
metodou – statickým heslem. RozšíĜení autentizace použitím tokenĤ je velmi snadné a jednoduše jej dosáhneme
zmČnou politiky ovČĜování hesel koneþných uživatelĤ.
9 Metoda 2
Metoda “Response Only” (RO). První z nabízených metod ovČĜování uživatelĤ hesly generovanými tokenem je
režim “Response Only“ (pouze odpovČć). V pĜípadČ že uživatel používá svĤj token pro generování jednorázového hesla, po zapnutí zadá PIN, kalkulátor zobrazí na displeji jednorázové heslo. Toto heslo je poþítáno
šifrovacím algoritmem na základČ jednoznaþného identifikátoru uživatele (tokenu) a aktuálního þasu.
Variabilita hesla je pĜímo založena na þasovém þítaþi tokenu pĜi šifrovacím mechanismu. Každé generované
heslo má životnost 36 sekund, resp. každých 36 sekund se generuje nové jednorázové heslo. Z toho plyne, že
server musí udržovat správný aktuální þas, aby mohl korektnČ ovČĜovat hesla generovaná tokeny. Toto lze
snadno zajistit bČžnČ dostupnou implementací NTP synchronizace þasu.
StandardnČ lze jednorázové heslo generovat v rozsahu od 6-ti decimálních þíslic do 8-mi hexadecimálních
znakĤ. Defaultní délka hesla pro Stadrin® je 8 decimálních þíslic. Délka hesla je uživatelsky definovatelná pĜi
programování tokenu a lze ji na pĜání zákazníka zmČnit.
Seed value
ýas
+
DES / 3DES
Jednorázové heslo
Událost
Obr 2: Schema metody “Response Only” (RO).
10 Metoda 3
Metoda “Challenge/Response” (CR). Princip generování hesla je obdobný jako v pĜedešlém schématu. Zvýšení
bezpeþnosti je založeno na dalším faktoru, který vstupuje do šifrovacího mechanismu pĜi generování hesla – tzv.
výzvČ, kterou zobrazuje server pĜi zadání uživatelského jména.
SamozĜejmostí je, že uživatelské heslo generované metodou Challenge/Response také trvá standardnČ 36 sekund. Z uživatelského pohledu autentizace zaþíná zadáním uživatelského jména do pĜihlašovacího dialogu. Poté
dostane od serveru výzvu (challenge). Tuto výzvu zadá do tokenu pomocí integrované klávesnice. Na základČ
tohoto údaje, jednoznaþného identifikátoru a þasu je pomocí šifrovacího algoritmu vygenerováno jednorázové
heslo, které se zobrazí na displeji a uživatel jej použije pro pĜihlášení.
185
Seed
Výzva
(ýas)
DES / 3DES
Jednorázové heslo
Obr 3: Schema metody “Challenge/Response” (CR).
11 Metoda 4
Message Authentication Code (MAC). Oproti metodám ovČĜováni uživatele uvedeným výše je tokeny spoleþnosti Vasco Data Security podporována ještČ jedna, spíše autorizaþní, metoda. V tomto pĜípadČ autentizaþní
proces je pĜímo spojen s pĜenášenými daty. V prĤbČhu ovČĜování této metody je serverová strana v jednom
okamžiku schopna ovČĜit identitu uživatele a zároveĖ autenticitu pĜenášených dat v rámci aplikace. Jako v pĜípadČ Challenge/Response metody, kde challenge je generována na stranČ serveru pomocí speciálního PAM
modulu, lze do tokenu zadávat údaje až do délky 16-ti numerických þíslic pomocí integrované klávesnice.
To znamená, že token mĤže generovat nČco jako digitální podpis transakce, který obsahuje jednak jednoznaþnou
identifikaci uživatele a dále ovČĜení validity dat až do osmi pĜenášených položek. Tato metoda je používána
pĜedevším ve finanþním sektoru.
12 Implementace systému Stadrin®
Instalace autentizaþního systému Stadrin® je velmi jednoduchá díky instalaþnímu balíþku rpm, v jehož tvaru je
dodáván. Program vyžaduje linux kernel 2.2 a vyšší a glibc minimálnČ verze 2.2. Jako úložištČ dat lze použít
LDAP, MySQL nebo UnixODBC, které mohou být umístČny jak pĜímo na serveru se systémem Stadrin®, tak na
jiných serverech pĜístupných protokolem TCP/IP. Po samotné instalaci se automaticky spustí skript, který uživatele provede základním nastavením programu. Nejprve zvolíme backend pro uložení informací o uživatelích
a tokenech. Možnost umístČní databáze na vzdáleném serveru umožĖuje použití jedné centrální databáze pro
všechny poþítaþe chránČné systémem Stadrin®.
Všechny konfiguraþní údaje jsou umístČny v jediném souboru /etc/stadrin/stadrin.conf. Administrátor tak mĤže definovat umístČní úložištČ uživatelských dat, defaultní nastavení pĜihlašovacích metod vþetnČ
parametrĤ, parametry pro synchronizaci uživatelských úþtu a další potĜebná nastavení. ZmČna autentizace jednotlivých aplikací se provádí pomocí textových konfiguraþních souborĤ autentizaþní vrstvy PAM, uložených
zpravidla v adresáĜi /etc/pam.d výmČnou dosavadního autentizaþního modulu za PAM modul Stadrin®.
13 Definice uživatelĤ a tokenĤ
Poslední þinnost, která nás pĜi instalaci a konfiguraci þeká, je import uživatelĤ a definic tokenĤ do databáze
a jejich vzájemné pĜiĜazení. Pokud již máme v systému založeny uživatelské úþty mĤžeme je snadno naimportovat. V subsystému je možno definovati i uživatelé kteĜí nejsou vedeni jako systémoví, pĜedevším pak z dĤvodu
možnosti autentizovat aplikaþní vrstvy jako je Apache, Tomcat apod. Databáze tokenĤ je plnČna z definiþních
souborĤ, dodávaných spoleþnČ s tokeny, avšak z dĤvodu bezpeþnosti jinou transportní trasou. Úlohou administrátora je pĜiĜadit uživatelĤm tokeny a zajistit jejich distribuci. Zcela však odpadá password management.
14 ZávČr
Stadrin® je velmi kvalitní a snadno použitelný nástroj pro zvýšení zabezpeþení systémĤ, jeho místo je tam, kde
statická hesla nezajišĢují dostateþnou ochranu pĜed neautorizovaným pĜístupem. Autentizace jednorázovými
hesly se dĜíve používala zejména v bankovních a finanþních institucích, kde jsou kladeny vysoké nároky na bezpeþnost, nyní však je tato metoda dostupná pro široké použití bez omezení.
186
Managed Security Services
Tomáš Mezník
[email protected]
www.netguard.cz
Bezpeþnost je slovo skloĖované dnes a dennČ ve všech pádech a v nejrĤznČjších souvislostech. Je to nutné,
protože rizik a hrozeb na nás v kybernetickém prostoru þíhá opravdu požehnanČ. Kvalitní zabezpeþení informaþních systémĤ je tak otázkou pro zdatné profesionály. Tito jsou ale zpravidla drazí, nedostatkoví a kromČ
zajištČní kontinuálního provozu jsou zapotĜebí nárazovČ.
NicménČ i tak je možné zajistit bezpeþnost s vynaložením rozumných prostĜedkĤ a za pĜijatelných podmínek.
ěešení se jmenuje Managed Security Services (dále jen MSS).
1 Popis služby MSS
PĜedevším je zapotĜebí zdĤraznit, že MSS je právČ služba – nikoliv specializovaný produkt. V zásadČ se jedná
o pĜenechání starostí a péþe o þást informaþní bezpeþnosti specializované firmČ. Jedná se tedy o formu outsourcingu. NicménČ nejde o þistý outsourcing, protože služba není implementována ve formČ „zadej a zapomeĖ“, ale
zadavatel v jejím rámci získává nejen jistotu zabezpeþení, nýbrž také informace o stavu bezpeþnosti v rámci
lokální sítČ a možnost sledovat její aktuální stav.
Cílem služby je pĜevzít každodenní rutinní starosti o zajištČní bezpeþného provozu sítČ, dále pak nárazové
aktivity v dobČ zvýšených nárokĤ (epidemie internetových þervĤ, velké DoS útoky þi další podobná rizika)
a pĜedevším trvalé monitorování stavu bezpeþnosti a jeho Ĝízení. Služba má za cíl provádČt dohled a správu
bezpeþnostních prvkĤ jako jsou firewally, antivirové programy, VPN, systémy detekce prĤniku host-based þi
network-based apod.
Služba MSS tedy pĜenáší – v oblasti bezpeþnosti monitoring, Ĝízení a odpovídající reakce (tedy zodpovČdnost za
tyto þinnosti) – na externí tým profesionálĤ s tím, že ponechává interním pracovníkĤm dostateþný prostor volnosti a navíc jim dává celou Ĝadu hodnotných informací.
2 Výhody služeb MSS
Oproti Ĝešení problematiky informaþní bezpeþnosti takĜíkajíc „svépomocí“ má využití služby MSS pro zadavatele nČkolik nezanedbatelných výhod:
x
Odpadají starosti o každodenní rutinní zajišĢování informaþní bezpeþnosti.
x
Zadavatel získává jistotu, že o jeho zabezpeþení je postaráno 365x7x24 (365 dní v roce, 7 dní v týdnu,
24 hodin dennČ), což se interními silami zajišĢuje opravdu velmi obtížnČ.
x
Zadavatel se nemusí zabývat Ĝešením problémĤ v oblasti, která není jeho hlavním oborem – díky MSS
se mĤže soustĜedit na vlastní obor þinnosti a celou problematiku informaþní bezpeþnosti mĤže pustit
z hlavy.
x
Informaþní bezpeþnost není omezena nebo ohrožena odchody klíþových pracovníkĤ, neschopenkami þi
jinými podobnými potížemi s tzv. „lidským faktorem“.
x
MSS jsou poskytovány na bázi Service Level Agreement (SLA), kterými se dodavatel zavazuje k dodržování smluvené úrovnČ poskytovaných služeb. MSS tak garantují pĜenos zodpovČdnosti na externího
poskytovatele.
x
Na základČ svého zadání nebo požadovaného balíþku služeb získává zadavatel pĜesný pĜehled o aktuálním stavu informaþní bezpeþnosti v podobČ a formátu, které si vyžádá.
x
Zadavatel mĤže operativnČ dle aktuální situace (rozvoj firmy, zĜizování nových poboþek apod.) pružnČ
mČnit své požadavky.
x
Zadavatel má jistotu, že se obrací na skuteþné profesionály, kteĜí se plnČ vČnují dané problematice.
187
x
Využití externích služeb výraznČ redukuje bezpeþnostní rizika, protože se snižuje hrozba opomenutí,
pĜehlédnutí þi jednostranného pohledu.
x
Každý zásah do systému je možné monitorovat a srovnávat se stav pĜed zásahem a po nČm.
x
Cena za využití služby MSS je vždy nižší, než když problematiku informaþní bezpeþnosti Ĝešíte vlastními silami.
UpozorĖujeme, že služba MSS není jen pro velké spoleþnosti, ale také pro malé firmy, instituce nebo
organizace, které potĜebují Ĝešit otázku informaþní bezpeþnosti, ale které si nemohou dovolit vlastní oddČlení
nebo pracov-níka informaþní bezpeþnosti.
3 Pod praporem Symantecu
V ýeské a Slovenské republice poskytuje jako první služby MSS spoleþnost NetGuard, a.s. (www.netguard.cz).
Tato využívá vlastní dohledové centrum v kombinaci s osvČdþeným Ĝešením MSS od spoleþnosti Symantec,
která je celosvČtovým lídrem v oblasti informaþní bezpeþnosti.
Instalace MSS probíhá v závislosti na zvolené úrovni vybraných služeb a v závislosti na zvláštnostech infrastruktury zadavatele buć on-site (na místČ), nebo remote (vzdálenČ). ObČma zpĤsoby je možné instalovat
následující služby:
x
Monitored Firewall Service;
x
Monitored Host-Based IDS Service;
x
Monitored Network-Based IDS Service;
x
Monitored Internet Security Appliance Service;
x
Monitored and Managed Firewall Service;
x
Monitored and Managed Network-Based IDS Service;
x
Monitored and Managed Internet Security Appliance Service;
x
Managed Security Compliance Service;
x
Managed Internet Vulnerability Assessment Service.
Souþástí dodávaných MSS je také systém reakce na incidenty a vþasné výstrahy. Okamžitá reakce mĤže mít
napĜíklad podobu zablokování nČkterých nebezpeþných pĜíloh v pĜípadČ virových epidemií, a to až do okamžiku
vydání aktualizaþních ĜetČzcĤ. Vþasná výstraha v rámci systému Program for Global Notification on Emerging
Threats pak pĜedstavuje varování na novČ objevené nebo vznikající hrozby. Toto je velmi dĤležitá souþást služby, protože pĜináší varování ve svČtČ, kdy o vzniku kalamity nebo velkého útoku (a o tom, zdali bude þi nebude
úspČšný – stejnČ jako odpovČć na nČj) rozhodují minuty.
Zadavatel má u Symantec MSS znaþnou svobodu volby, protože má možnost vybrat si z nČkterého z pĜedpĜipravených balíþkĤ služeb nebo si nechat vytvoĜit informaþní bezpeþnost „na míru“. Má také možnost využít
celou paletu služeb MSS nebo jen jejich urþitou þást (kterou není schopen zajistit jinak, kterou považuje za
klíþovou apod.).
Díky rozhraní Secure Internet Interface (možnost použití v jakémkoliv prohlížeþi podporujícím 128bitové šifrování a java-skriptování) má zadavatel možnost sledovat v reálném þase stav bezpeþnosti a okamžité dopady
prĤbČžnČ pĜijímaných opatĜení na ni.
Krom výše uvedených všeobecných pĜedností MSS získává zadavatel se Symantec MSS ještČ následující
výhody:
188
x
Stabilitu organizace, která je kótována na americké burze (NASDAQ: SYMC) a která dlouhodobČ
vykazuje rĤst i finanþní zdraví.
x
Kredit, který Symantec dlouhodobČ a opakovanČ prokazuje na poli informaþní bezpeþnosti.
x
Technologický náskok pĜed konkurencí.
x
Díky lokální podpoĜe spoleþnosti NetGuard a.s. komplexní nabídku Ĝešení i služeb a zkušenosti v nejrĤznČjších oborech informaþní bezpeþnosti.
UpozorĖujeme ještČ, že aþ je MSS spoleþnosti NetGuard a.s. postavena na Ĝešení Symantec, jedná se o platformovČ nezávislou službu schopnou zajistit provoz Ĝešení od všech významnČjších svČtových dodavatelĤ. Jinými
slovy: její implementace nemá na chod organizace žádný dramatický vliv.
4 PĜíklad: MSS a firewall
K nejžádanČjším a nejvyužívanČjším službám z portfolia MSS patĜí Monitored/Monitored and Managed
Firewall Services (monitorování nebo monitorování a správa firewallu). Je urþena pro každého, kdo si
uvČdomuje, že firewall nestaþí pouze mít a používat, ale také prĤbČžnČ monitorovat, jím získaná data
zpracovávat a analyzovat. A v neposlední ĜadČ pak na zjištČné skuteþnosti reagovat.
Režim Monitored Firewall Services je urþen pro každého, kdo hledá výhody konstantního monitorování
firewallu v reálném þase, ale z jakéhokoliv dĤvodu si chce ponechat kontrolu nad konfigurováním
bezpeþnostních prvkĤ. Služba Monitored and Managed Firewall Services je pak urþena všem, kdo hodlají
využít v plné míĜe služeb profesionálĤ a kdo se nechtČjí správČ bezpeþnostních prvkĤ vČnovat.
V obou režimech je každopádnČ provádČna nepĜetržitá analýza incidentĤ i možných incidentĤ v reálném þase
s cílem rozpoznat i nejsofistikovanČjší hackerské útoky. KromČ toho zadavatel získává možnost vzdálené konfigurace a zmČn pravidel stejnČ jako zmČn ve VPN þi systémovou i softwarovou podporu. Navíc získává pĜístup
k Secure Internet Interface, kde mĤže v reálném þase sledovat stav bezpeþnosti. V pĜípadČ, že služba detekuje
ohrožení, zákazník je upozornČn a NetGuard a.s. spolupracuje se zákazníkem na nápravČ problému. Aktivní
zása-hy do konfigurace, aktualizace SW zaĜízení atd. provádí dle dohodnuté úrovnČ poskytované služby buć
sám zadavatel, anebo firma NetGuard.
189
190
PĜípadová studie Ĝešení bezpeþnosti informaþního systému
Ing. František Nemochovský
[email protected]
Unisys s.r.o.
Italská 35, 120 00 Praha 2
1 Úvod
ěešení bezpeþnosti by mČlo být nedílnou souþástí všech informaþních systémĤ, a to jak v podnikatelské sféĜe,
tak i ve státní správČ. Stav v oblasti bezpeþnosti informaþních technologií se pokusil opakovanČ zmapovat
prĤzkum stavu informaþní bezpeþnosti v ýeské republice, zpracovaný spoleþností Price Waterhouse Coopers za
podpory Národního bezpeþnostního úĜadu a þasopisu Data Security Management. Výsledky tČchto prĤzkumĤ
nebyly pĜíliš optimistické, i když ukázaly urþitý kladný posun. PĜesto však celkový stav Ĝešení bezpeþnosti
informaþních technologií nelze považovat za uspokojivý.
ObecnČ lze konstatovat, že ve vČtšinČ provozovaných informaþních systémĤ je implementována Ĝada
bezpeþnostních opatĜení, jako jsou napĜíklad identifikace a autentizace uživatelĤ, antivirová ochrana, vytváĜení
záloh, ochrana pĜed prĤnikem do systému z jeho okolí a další. Ve vČtšinČ pĜípadĤ však implementovaná
bezpeþnostní opatĜení nepokrývají všechny související oblasti a Ĝešení bezpeþnosti nenaplĖuje všechna
doporuþení norem na Ĝešení bezpeþnosti informaþních systémĤ. Pro Ĝadu informaþních systémĤ není zpracována
bezpeþnostní politika nebo nebyla zpracována analýza rizik jako východiska pro Ĝešení bezpeþnosti
informaþního systému.
2 Výchozí podmínky pro Ĝešení bezpeþnosti
x
spoleþnost XXX je vzhledem k pĜedmČtu svého podnikání významnou souþástí ekonomické
infrastruktury státu,
x
informaþní systém spoleþnosti XXX poskytuje informaþní podporu klíþovým procesĤm souvisejícím
s hlavním pĜedmČtem jejího podnikání,
x
ztráta informaþní podpory klíþových procesĤ nebo únik citlivých informací z informaþního systému
mohou vážnČ ohrozit podnikatelské aktivity a majetek spoleþnosti,
x
v informaþním systému spoleþnosti XXX byla implementována Ĝada bezpeþnostních opatĜení, jejichž
cílem bylo zajistit dĤvČrnost a integritu informací a dostupnost služeb informaþního systému pro jeho
uživatele,
x
doposud realizované Ĝešení bezpeþnosti však v plném rozsahu nenaplĖuje požadavky platné legislativy
a norem v oblasti bezpeþnosti informaþních technologií,
x
provoz informaþního systému spoleþnosti XXX zabezpeþuje na smluvním základČ externí firma,
x
v informaþním systému spoleþnosti XXX nejsou zpracovávány utajované skuteþnosti, z tohoto dĤvodu
nebylo nutné na Ĝešení bezpeþnosti aplikovat požadavky zákona þíslo 148/1998 Sb. o ochranČ
utajovaných skuteþností,
x
výbČr dodavatele Ĝešení nepodléhal zákonu þíslo 40/2004 Sb. o veĜejných zakázkách,
x
v rámci spoleþnosti XXX nebyla definována struktura Ĝízení bezpeþnosti v rámci informaþního systému,
x
spoleþnost XXX nemá vlastní specialisty na Ĝešení bezpeþnosti informaþních technologií,
x
ve spoleþnosti XXX je na velmi dobré úrovni propracován systém vydávání, schvalování a distribuce
interních firemních normativĤ,
x
Ĝešení bezpeþnosti informaþního systému mČlo podporu vedení spoleþnosti.
191
3 PrĤbČh Ĝešení bezpeþnosti informaþního systému
Zahájení Ĝešení
3.1
Spoleþnost XXX se obrátila na firmu Unisys s žádostí o poskytnutí odborných služeb pĜi Ĝešení bezpeþnosti
jejího informaþního systému.
Firma Unisys doporuþila spoleþnosti XXX Ĝešit bezpeþnost jejího informaþního systému systémovČ, což v praxi
znamenalo, že Ĝešení bezpeþnosti musí:
x
být Ĝízeným procesem,
x
naplnit požadavky platné legislativy,
x
být v souladu s doporuþeními platných norem.
x
probíhat po jednotlivých etapách životního cyklu,
x
zahrnout i další související oblasti.
Vzhledem k rozsahu Ĝešení firma Unisys doporuþila spoleþnosti XXX zahájit Ĝešení bezpeþnosti jejího
informaþního systému zpracováním studie proveditelnosti systémového Ĝešení, jejímž hlavním cílem bylo:
x
zhodnocení stávajícího stavu Ĝešení bezpeþnosti informaþního systému jako východiska pro další Ĝešení
bezpeþnosti,
x
ochrana investic již vložených do Ĝešení bezpeþnosti,
x
definování strategického cíle v oblasti bezpeþnosti informaþního systému,
x
návrh krokĤ vedoucích k dosažení definovaného strategického cíle,
x
definování zdrojĤ nutných pro dosažení definovaného strategického cíle,
x
zpracování a zhodnocení možných variant Ĝešení,
x
vytvoĜení kvalifikovaných podkladĤ pro strategické rozhodnutí managementu organizace o dalším
Ĝešení bezpeþnosti informaþního systému.
Obr 1: Grafické znázornČní významu studie proveditelnosti
systémového Ĝešení bezpeþnosti informaþního systému spoleþnosti XXX
192
Forma spolupráce Ĝešitele a zadavatele
3.2
ěešitelem studie proveditelnosti systémového Ĝešení bezpeþnosti byla firma Unisys. K jejímu zpracování za
svoji stranu spoleþnost XXX jmenovala vedoucího projektu, v jehož pĤsobnosti bylo zajistit i potĜebné kapacity
specialistĤ spoleþnosti XXX, nezbytné ke zpracování úvodní studie.
PĜed zahájením prací na studii proveditelnosti systémového Ĝešení bezpeþnosti byly definovány následující
formy spolupráce:
x
hodnocení stávajícího stavu Ĝešení bezpeþnosti probíhalo formou interview s tím, že hodnotitel
vyžadoval od spoleþnosti XXX doložení nČkterých uvádČných skuteþností,
x
pĜed zpracováním jednotlivých tematických blokĤ studie se uskuteþnil workshop, na kterém specialisté
firmy Unisys požadovali od zástupcĤ spoleþnosti XXX zodpovČzení otázek vztahujících se k Ĝešení
tematického bloku a jejich eventuální prodiskutování,
x
specialisté firmy Unisys následnČ zpracovali tematický blok samostatnČ (s obþasnými operativními
dotazy),
x
zpracovaný tematický blok byl pĜedán spoleþnosti XXX k pĜipomínkovému Ĝízení,
x
na závČr byla studie proveditelnosti systémového Ĝešení bezpeþnosti informaþního systému oponována
spoleþností XXX jako celek.
Lze konstatovat, že se tato forma spolupráce v praxi velmi osvČdþila, vedla k zapojení zástupcĤ spoleþnosti
XXX do Ĝešení a ke zkrácení þasu, nezbytného ke zpracování studie.
Obsah studie proveditelnosti systémového Ĝešení bezpeþnosti
3.3
Studii proveditelnosti systémového Ĝešení bezpeþnosti informaþního systému spoleþnosti XXX zpracoval
Ĝešitelský tým specialistĤ Unisys s následujícím základním obsahem:
x
výchozí stav pro další Ĝešení bezpeþnosti,
-
zhodnocení souþasného stavu,
-
identifikace již implementovaných bezpeþnostních opatĜení,
x
návrh cílĤ v oblasti bezpeþnosti informaþního systému,
x
definování krokĤ vedoucích k dosažení cílĤ,
x
x
x
-
životní cyklus Ĝešení bezpeþnosti,
-
základní cíl a obsah prací každé etapy životního cyklu,
analýza variant Ĝešení,
-
základní návrh obsahu služeb systémové integrace Ĝešení,
-
varianty zpĤsobu zajištČní služeb systémové integrace,
zdroje nezbytné k dosažení cílĤ,
-
legislativa,
-
normy pro Ĝešení bezpeþnosti,
-
lidské zdroje,
-
þasové zdroje,
-
finanþní zdroje,
doporuþení a zdĤvodnČní varianty Ĝešení.
193
3.4
Další postup prací
Studie proveditelnosti systémového Ĝešení bezpeþnosti informaþního systému spoleþnosti XXX:
x
prošla interním pĜipomínkovým Ĝízením ve spoleþnosti XXX,
x
byla schválena pĜíslušníkem managementu spoleþnosti s potĜebnou schvalovací pravomocí,
x
v souþasné dobČ probíhá Ĝešení podle doporuþení studie Ĝešením první etapy životního cyklu, to je
zpracováním bezpeþnostní politiky.
4 ZávČr
Lze konstatovat, že zpracovaná studie proveditelnosti systémového Ĝešení bezpeþnosti informaþního systému
spoleþnosti XXX splnila své cíle, neboĢ:
x
hodnocení stávajícího stavu konstatovalo, že dĤvČrnost a integrita informací spolu s dostupností služeb
sytému jsou na urþité úrovni zabezpeþeny, tuto úroveĖ je však tĜeba zvýšit pĜedevším v oblasti splnČní
doporuþení platných norem,
x
management spoleþnosti se ztotožnil s návrhem cílĤ v oblasti bezpeþnosti informaþního systému
a doporuþenou variantou Ĝešení,
x
schválením studie proveditelnosti se management spoleþnosti XXX zavázal vyþlenit potĜebné zdroje
pro navržené Ĝešení.
Analogický postup lze doporuþit i pro Ĝešení bezpeþnosti u obdobných informaþních systémĤ z následujících
dĤvodĤ:
194
x
zpracování studie (aĢ již vlastními silami nebo specialisty externí firmy) není þasovČ ani finanþnČ pĜíliš
nároþné,
x
již na poþátku Ĝešení je definován strategický cíl, ke kterému bude Ĝešení smČĜovat,
x
definování požadavkĤ na zdroje nezbytné k dosažení cíle na poþátku Ĝešení umožní analýzu, zda je
v podmínkách organizace reálné je vyþlenit,
x
schválením studie se management organizace zavazuje vytvoĜit podmínky a vyþlenit zdroje nezbytné
pro další Ĝešení,
x
další Ĝešení bezpeþnosti informaþního sytému podle navržených etap Ĝešení mĤže být sice v þase
rozloženo podle dostupnosti pĜedevším finanþních prostĜedkĤ, bude však stále smČĜovat k dosažení
definovaných cílĤ v oblasti bezpeþnosti informaþního systému.

Security Management - Bezpečnost a ochrana utajovaných informací

Transkript

Podobné dokumenty

informace o partnerech konference 3.–5. 5. 2005, areál veletrhů brno

Výroční zpráva ÚCL za rok 2009

vydání č. 5 - Asociace prádelen a čistíren

computerworld top 100

Zabezpečení CSR v dodavatelském řetězci ve společnosti Metrostav