![]() Specializovaný týdeník o výpočetní technice |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
![]() |
Seriál o bezpečnosti a informačním soukromí |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Část 40 - CW 5/98
Bezpečnost a síťová architekturaJaroslav Dočkal
V minulém díle jsme se podívali na specifické hrozby bezpečnosti v sítích a také na možnosti volby vhodných bezpečnostních mechanismů. V dnešním pokračování se zaměříme blíže na otázku síťové architektury a také nahlédneme do menu několika dalších dílů seriálu. V rámci doplňku ISO 7498-2 byla také provedena dekompozice jednotlivých služeb a mechanismů do vrstev síťové architektury -- viz tabulka. Takovýto přístup se však ukázal jako dosti nepraktický a těžkopádný, nakonec jako celá architektura OSI. Reálné problémy reálných sítí ukázaly, že pro praxi je vhodnější dekompozice do 4 úrovní (viz obrázek), které nakonec odpovídají i dnes dominující protokolové sadě TCP/IP: 1. aplikační, 2. koncových systémů (transportní úroveň), 3. podsítí (síťová úroveň), 4. k lince (fyzická úroveň). Nejprve si proveďme hrubou rozvahu na téma, kam raději bezpečnostní služby umístit: blíže k aplikaci (nahoru) anebo co nejblíže k lince (dolů)? · Na úrovni fyzického propojení je nutné zabezpečit veškerý provoz, který je na dané lince multiplexován. Pokud je z něj utajováno například jen jedno procento paketů, není to příliš efektivní přístup a je lépe bezpečnost zajišťovat na některé vyšší úrovni. · Čím nižší úroveň zabezpečení bloků dat, tím je více zabezpečováno záhlaví. Zabezpečení na aplikační úrovni vede k tomu, že záhlaví na nižších úrovních (transportní, síťové) jsou přenášena nezabezpečená. Záleží na zvolené bezpečnostní politice, je-li to považováno za závadu. · Na fyzické úrovni lze přihlédnout k charakteristikám linky; pokud jsou známy trasy, po kterých se budou chráněné pakety pohybovat, stačí chránit pouze linky (případně podsítě) na těchto trasách a ne všechny linky v síti. · Umístění bezpečnostních služeb na aplikační úrovni znamená zahrnout je do každé aplikace na každém koncovém systému. Volba linkové úrovně zase znamená implementovat bezpečnost na každém konci každé síťové linky. Z tohoto hlediska se tedy ukazuje jako nejvhodnější umístit prvky doprostřed architektury (koncových systémů nebo podsítí). Zhodnoťme nyní jednotlivé konkrétní možnosti: Řešení na aplikační úrovni vychází ze skutečnosti, že některé bezpečnostní služby jsou spojeny přímo s odesílatelem nebo příjemcem (autentizace zdroje dat, zamezení popírání atd.) a těžko je lze realizovat na nižší než aplikační úrovni. Jako příklad umístění bezpečnostní služby na aplikační úroveň lze uvést důvěrnost vybraného pole zprávy (např. PINu při finanční transakci), integritu vybraného pole zprávy (např. při podpisu dokumentu) či nepopiratelnost (např. příjmu oběžníku). Koncové řešení vychází z předpokladu, že koncové systémy jsou zabezpečené, zatímco komunikační prostředí, které je propojuje, není. Volba koncového řešení vede k transparentním řešením pro aplikace (při přidání nové aplikace není nutné se znovu zabývat její bezpečností), je efektivnější, protože jsou zabezpečována data, která jsou už z aplikace sdružena do transportních jednotek. Lze zde také chránit transportní záhlaví. Nakonec -- bezpečnostní administrátor systému může definovat jednotnou bezpečnostní politiku pro celý koncový systém a nemusí ji definovat zvlášť pro každou aplikaci. Na koncové úrovni bývá řešen problém ztráty, resp. zdvojení paketů (u některých přenosových systémů i chyb přenosu). Je zcela přirozené tyto kontroly rozšířit o kontroly integrity. Protože se pro zajištění důvěrnosti používají stejné mechanismy jako pro kontrolu integrity, je vhodné se vyhnout dvojí funkcionalitě umístěním obou bezpečnostních funkcí na stejnou úroveň síťové architektury. Řešení na úrovni podsítí (s využitím směrovačů, paketových filtrů atd.) přesouvá zodpovědnost za bezpečnost od správce systému na správce sítě. Je to zároveň řešení úsporné, protože umožňuje definovat a realizovat bezpečnostní politiku pro jeden síťový prvek místo pro desítky, stovky, resp. tisíce koncových zařízení. Řešení na fyzické úrovni je transparentní ke všem protokolům vyšších vrstev. Nutně však vede k hardwarové realizaci, což se při větším počtu linek v síti může značně prodražit. Navíc zde mohou být i vysoké operační náklady při nastavování větších množství geograficky vzdálených zařízení. Přitom je zde zabezpečován vztah pouze mezi dvojicí fyzicky propojených systémů a navíc bezpečnost uvnitř těchto systémů (rozbočovačů, mostů, přepínačů, směrovačů) není zajištěna. Tradiční bezpečnostní službou je zde zajištění důvěrnosti přenosu šifrováním. Na jaké úrovni a jakými mechanismy bychom řešili na počátku článku uvedené konkrétní útoky proti protokolové sadě TCP/IP? · proti odposlechu se lze bránit šifrováním na libovolné úrovni, ale také výběrem vhodného typu sítě (např. 100VG-AnyLAN), resp. síťových komponent (přepínačů, "bezpečných" rozbočovačů atd.) tj. řízením přístupu na úrovni linky, · proti přehrávání paketů se lze bránit výběrem vhodného mechanismu autentizace na aplikační úrovni, · proti změnám paketů se lze bránit kontrolami integrity na aplikační úrovni (např. mechanismem digitálního podpisu) anebo na síťové úrovni (autentizační záhlaví), · proti zásahům do směrovačů se lze bránit jejich autentizací, tj. na síťové úrovni, · proti záplavám paketů se lze bránit mechanismy řízení přístupu opět na síťové úrovni, · proti krádeži paketů se lze bránit pevně nastavenými směrovacími tabulkami, ale také monitorováním síťového provozu, · použití zdrojového směrování se lze vyhnout jeho zákazem v rámci konfigurace směrovačů, · proti ICMP přesměrování se lze bránit autentizačními vlastnostmi směrovačů, · proti SYN útoku se dnes lze bránit pomocí firewallů anebo jednodušeji vhodnějším řízením přístupu k soketům (např. s využitím časování, vyhazováním přespočetných SYN atd.), · proti odhadu očekávání při navazování TCP spojení se lze bránit náhodnou volbou čísla prvního bajtu spojení, řízením přístupu do sítě atd. Ochraně nejvýznamnějších aplikačních protokolů a dalším klíčovým problémům bezpečnosti sítě budou věnovány následující díly seriálu.
A o čem tedy budou: · Distribuce klíčů, což je jeden z největších problémů bezpečnosti počítačové sítě. Článek bude probírat centralizované a decentralizované metody s využitím symetrických i asymetrických klíčů. Budou zde popsány a porovnány protokoly ISAKMP, OAKLEY a SKIP. · Autentizační protokoly, kdy autentizační servery ověřují autenticitu daného klienta a na základě tohoto ověření zvláštní server přiděluje práva na využití služeb jednotlivých serverů. Článek provede porovnání metod založených na symetrických a asymetrických metodách šifrování, tj. známý Kerberos s SPX firmy DEC. · Řízení přístupu, dříve známé jen z oblasti databází a nyní používané i v rámci počítačových sítí. · PGP (Pretty Good Privacy), program pro zabezpečení elektronické pošty, hojně používaný při vzájemné komunikaci v Internetu. Nově umožňuje i jednoduchou podporu ochrany souboru na desktopu. Bude diskutována integrace PGP do poštovního programu a využití PGP k zajištění důvěrnosti, integrity a autenticity. · X.400, pošta standardizovaná ITU (International Telecommunication Union), u které se s komplexním zabezpečením přenosu počítalo již při jejím návrhu. Článek objasní, jak se tato pošta vypořádává s jednotlivými bezpečnostními hrozbami, jaké zajišťuje bezpečnostní služby a jak jsou tyto služby uspořádány do jednotlivých profilů bezpečnostních tříd. · EDI (Electronic business data interchange) je software zajišťující elektronickou výměnu obchodních transakcí (objednávky, faktury, platební příkazy atd.), obvykle nad poštou X.400. Článek bude obsahovat rozbor příslušných právních norem, analýzu rizik prostředí EDI, popis jednotlivých typů EDI a použitých bezpečnostních mechanismů, budou též diskutovány implementační problémy. · Elektronické obchodování. Článek objasní jeho podstatu, výhody a nevýhody, popíše problémy a hrozby. Vysvětlí fungování komerčních a bankovních služeb na elektronické bázi, homebanking, virtuální bankovnictví, platební systémy a služby finančního investování. Ukáže, v čem je budoucnost elektronického obchodování. · Protokoly SHTTP, SSL a PCT, sloužící pro bezpečnou komunikaci s Weby. Článek bude obsahovat porovnání výhod a nevýhod jednotlivých protokolů a popis současného stavu v oblasti jejich použití. · SET (Secure Electronic Transactions), protokol pro bezpečnou komunikaci mezi zákazníkem, obchodníkem a jejich bankami. Článek poskytne představu co protokol umí (zajistit autentizaci držitele karty a obchodníka a bezpečnost elektronické transakce) a co neumí (např. zamezit popření provedení platby). · Firewally by měly vymezit okruh, za kterým jsou zabezpečené vnitřní sítě uživatelů. Článek objasní výhody a nevýhody základních typů firewallů i další služby poskytované firewally (kvantitativní omezení toku dat, transformaci adres atd.). Dále naznačí postup při výběru vhodného firewallu pro daného uživatele, resp. organizaci.
Vztah služeb a mechanismů k jednotlivým vrstvám síťové architektury
| COMPUTERWORLD - seriál o bezpečnosti | COMPUTERWORLD | IDG CZ homepage | |