Zabezpečení dat v systému Windows 2000

V následujícím článku se ve stručné formě pokusíme přiblížit metodiku možných postupů pro návrh řešení zabe...


V následujícím článku se ve stručné formě pokusíme přiblížit metodiku možných
postupů pro návrh řešení zabezpečení aplikací v prostředí operačního systému
Windows 2000.
Jednou z klíčových otázek zabezpečení jakéhokoliv systému, tedy i operačního
systému, je ověření totožnosti při vstupu do něj. Po každém takovém ověření (ať
už se jedná o ochranu při vstupu do budovy nebo při přihlášení do počítače)
musí být daný systém zabezpečení schopen určit, k jakým prostředkům má uživatel
(zprostředkovaně proces) oprávněný přístup. Tento postup je označován jako
"ověřením totožnosti při přihlášení do systému" a Windows 2000 poskytují
některé komplexní a užitečné možnosti včetně schopnosti zařadit váš vlastní
zákaznický systém ověření do provozované sítě. Klíčem k této flexibilitě je
rozhraní SSPI (Security Support Provider Interface).

Ověření totožnosti
Než budou popsány rámcové detaily, jak celá konstrukce pracuje, zopakujme si
základní principy ověření totožnosti. Zásady by měly být obecně platné pro
libovolný zabezpečený operační systém, nikoliv pouze pro Windows 2000. Strážný
neboli proces řízení přístupu, který uděluje právo přístupu k prostředkům, musí
vhodným způsobem zkontrolovat totožnost přihlašujícího se uživatele nebo
procesu. V mnoha analogických situacích figuruje definovaná autorita, s níž je
prováděna konzultace kontroly totožnosti.
Když si jde např. klient do banky vyzvednout peníze, je vyzván k předložení
průkazu totožnosti samozřejmě, že úředník zkontroluje fotografii, ochranné
prvky a v podstatě důvěřuje autoritě, která doklad vystavila. Autoritou však
nemusí být jen zástupce státní organizace, může jí být i databáze informací,
která je nutná při elektronickém ověřování podle otisků prstů nebo oční sítnice
uživatele. Okamžitě se objeví navazující otázky na zajištění integrity
databáze, bezpečnost komunikačních linek, ale podstata je stejná jde o princip
dotazování se definované autority.
Složitost procesu ověření závisí na významu a citlivosti chráněného subjektu.
Pro maximální zabezpečení lze použít vše od průkazu totožnosti přes hesla a
otisky prstů až po kontrolu řetězce DNA. Na druhé straně ale požadujeme, aby
byl celý proces jednoduchý, rychlý a v neposlední řadě aby náklady na něj byly
co nejnižší. Každá legrace takříkajíc "něco stojí", takže i požadavky na návrh
systémů zabezpečení výpočetních systémů obsahují řadu možných řešení, ale i
kompromisů.
Ačkoliv přesné kroky přístupu do zabezpečené síťové komunikace závisejí na
konkrétním způsobu realizace vzájemného odsouhlasení obou komunikačních
protějšků, ověření klientského přístupu do sítě se řídí některým ze společných
modelů postupu. Transakce zpracování ověření je obvykle zahájena klientem a
strana systému redukuje počáteční vzájemnou výměnu na několik bitů, které
představují úvod do této komunikace. Aby server prověřil uživatele a rozhodl,
zda uživatel má přiřazena odpovídající přístupová práva, dotazuje se na klienta
důvěryhodné autority. Jakmile je bezpečný vztah vybudován, klient a server si
mohou začít vyměňovat (důvěrné) informace, protože si jsou jisti, kdo je jejich
protějškem.
Na první pohled to vypadá velice jednoduše, ale je třeba si uvědomit, že jako
komunikační prostředek může být použita podniková síť nebo dokonce Internet a
protokol TCP/IP. Dále musíme vzít do úvahy, že komunikace může procházet přes
velký počet směrovačů a systémů, které ji zprostředkovávají. Tehdy do ní mohou
vstupovat i třetí strany, a to často s úmyslem komunikační spojení poškodit.
Určitým stupněm zabezpečení je, když se klient a server dohodnou na vzájemném
zašifrování přenášených dat a použijí některou z dostupných šifrovacích metod.
Tento způsob závisí přinejmenším na jednom z použitých šifrovacích klíčů, který
by měl být dostatečnou ochranou proti vniknutí slídilů. Navazujícím komplexním
problémem je tedy zajistit, aby šifrovací klíče nebyly odhaleny.
Jinou možností je ochrana komunikačních spojení pomocí tzv. Message
Authentication Code, který sice nechrání obsah přenášené komunikace před
přístupem narušitele, ale nedovolí modifikaci obsahu přenášených zpráv. Jedinou
částí zpráv, která musí být zašifrována, je hodnota kontrolního součtu (CRC),
což je ve většině případů dostatečně účinné a není nutno šifrovat celý obsah
zprávy. Jak lze odhadnout, i poměrně jednoduchý dotaz na datovou informaci ze
serveru může narůst do velmi složité přenosové transakce.
Protokoly zabezpečení
Logika a detaily zpracování jednotlivých kroků jsou určeny protokolem
zabezpečení, který je v síti použit. Obě strany, které se komunikace účastní,
musejí použití protokolu odsouhlasit, jinak komunikační spojení nebude
ustaveno. Je zvykem, že protokol určuje server, a jestliže klient není schopen
se přizpůsobit nebo podmínkám vyhovět, nebude mít k prostředkům sítě přístup.
Existuje množství síťových protokolů, které jsou pro tyto účely dostupné, ale v
samotných Windows je jich pouze několik málo obecně použitelných. Předchozí
verze Windows NT využívají jako základní protokol ověření totožnosti Windows NT
LAN Manager (NTLM) tzv. "challenge-response" protocol. Naproti tomu implicitním
protokolem síťového ověření ve Windows 2000 je Kerberos v5. Název je mimochodem
odvozen od jména mytického tříhlavého psa, který hlídá vstup u brány do
podsvětí. V současnosti je tento protokol považován za internetový standard,
který Microsoft ve Windows 2000 akceptoval. Požadavky, které vyplývají z
materiálů RFC (Request for Comments) 1510, definují Kerbera jako základní
protokol, který byl navržen v MIT jakožto součást projektu Athena a je určen
pro zabezpečení uživatelského ověření totožnosti. (Microsoft používá
nedefinované datové pole, které obsahuje některé implementace komunikace
protokolu Kerberos s operačním systémem Windows.) Existuje pochopitelně
množství dalších protokolů, například SSL, který je často používán WWW
aplikacemi.
Proces ověření pomocí NTLM se zcela liší od toho, který je použit v protokolu
Kerberos rozdíl je znázorněn na obrázku.
Na nejvyšší úrovni v průběhu celého ověřovacího procesu s protokolem NTML
probíhá komunikace mezi klientem a serverem, kdy server ve spolupráci s
autoritou kontroluje důvěryhodnost klienta. Jeden z podstatných rozdílů mezi
NTML a Kerberem spočívá ve využití paměti cache. V případě protokolu Kerberos
klient obdrží od autority tzv. tiket ověření, který je uložen do cache pracovní
stanice klienta, a veškerá komunikace s autoritou se uskutečňuje v jediné
interakci při získávání tohoto tiketu. Protokol NTLM ukládání do cache
nepodporuje, takže každý dotaz ze strany klienta inicializuje opakovaný
požadavek na autoritu ověření totožnosti.

Zjednodušení zabezpečení
Jak si jistě každý umí představit, nasazení a podpora několika protokolů v
jediné aplikaci se může podobat těžké noční můře, podobné zajištění datových
přístupů do několika nezávislých databázových strojů. Avšak jen do okamžiku,
než se objevilo ODBC, které je schopno poskytnout rozumné uniformní rozhraní
pro přístup do libovolné relační databáze, která je schopna s ODBC ovladačem
komunikovat. Pro realizaci zabezpečené komunikace existuje tzv. rozhraní
zprostředkovatele SSPI (Security Support Provider Interface), které dokáže
poskytnout uniformní rozhraní pro nasazení odpovídajícího ověřovacího protokolu
ve Windows 2000. SSPI je "microsoftí" verzí rozhraní zprostředkovatele v
souladu s komunikačním standardem Generic Secure Service API (GSSAPI je popsán
ve specifikacích Internet Task Forces RFC 1508 a 1509).
Abychom se vyhnuli nutnosti psát kód pro každou dostupnou volbu v aplikaci,
SSPI umožňuje přístup aplikace k dynamickým knihovnám, které obsahují společná
ověřovací a šifrovací datová schémata. Tyto DLL knihovny jsou označovány jako
zprostředkovatelé bezpečnostní podpory Security Support Provider (SSP), a každá
z nich implementuje jeden určitý protokol zabezpečení ten pak může být ve
Windows 2000 použit, aby zajistil vrstvu oddělení aplikace a protokolu.
Zprostředkovatelé SSP představují jednu nebo několik programových sad
zabezpečení, které jsou aplikacím dostupné. Ty pak mapují různé funkce rozhraní
SSPI k odpovídajícím protokolům a pracují jako překladač nebo styková vrstva
mezi aplikací a zprostředkovatelem. Aplikace, která implementuje rozhraní SSPI,
může použít jakoukoliv sadu programů, která je v rámci systému dostupná, aniž
musí znát detaily o protokolech zabezpečení, které daná sada zabezpečení
implementuje.

Řízení programových sad
Obecně existují v rozhraní SSPI čtyři základní kategorie aplikačního
programového rozhraní (API): řízení programových sad, řízení oprávnění, řízení
kontextu a řízení zpracování zpráv. Funkce řízení programové sady vyhodnocují a
určují atributy v sadě zabezpečení zprostředkovatele SSP. Na svém výstupu
poskytují seznam sad zabezpečení, které jsou v rámci systému dostupné a umožní
si jednu aplikaci pro podporu svých požadavků vybrat. Funkce řízení oprávnění
umožňují aplikacím vytvořit a získat přístup k tzv. komitentům oprávnění.
Komitent je entita rozlišovaná v rámci systému zabezpečení (např. koncoví
uživatelé nebo autonomní procesy). Funkce řízení kontextu umožňují aplikacím
vytvořit a použít odpovídající kontexty zabezpečení. Těmi jsou data
zabezpečení, která jsou relevantní pro dané spojení (zahrnují data, jako jsou
klíč relace a doba trvání relace). Jak klient, tak i server musejí při tvorbě
kontextu zabezpečení vzájemně spolupracovat. Potom mohou v průběhu existence
spojení použít kontext zabezpečení spolu s funkcemi řízení zpracování zpráv pro
zajištění integrity a důvěrnosti předávaných zpráv. Toto představuje největší
část rozhraní SSPI a spolu se šifrováním a dešifrováním zahrnuje metody pro
manipulaci a údržbu kontextů zabezpečení.
Funkce podpory zpracování zpráv zajišťují přenos zpráv, které nesmějí být
neoprávněně falšovány. Pracují s jednou nebo více vyrovnávacími pamětmi, které
obsahují zprávu a asociovaný kontext zabezpečení, který byl vytvořen funkcemi
řízení kontextu. Jednou z důležitých schopností zabezpečení v rámci operačního
systému Windows 2000 je tzv. zosobnění doslova představuje klíč k hierarchii
zabezpečení. K zosobnění dochází tehdy, když Windows umožňují jednomu procesu
převzít atributy zabezpečení jiného procesu. Základním smyslem zosobnění je
umožnit, aby kontroly přístupu byly provedeny jménem totožnosti klienta, což
může způsobit, že přístup bude buďto povolen, nebo omezen, a to v závislosti na
tom, jaká má klient oprávnění dané činnosti provádět. Ve skutečnosti pod pojmem
zosobnění rozumíme to, že klient dovolí serveru, aby jej "zastupoval". Míra, v
níž klient postupuje autoritu serveru, je úrovní zosobnění. Jednotlivé úrovně
určují, jaká část oprávnění klienta bude předána serveru (popř. službě), který
má klienta zastupovat. Windows 2000 podporují 4 úrovně zosobnění anonymní,
ztotožnění, zosobnění a delegování.
Anonymní úroveň (Anonymous) klient je pro server anonymní. Proces serveru může
klienta zosobnit, ale token zosobnění neobsahuje žádné informace o klientovi.
Úroveň ztotožnění (Identify) implicitní pro chování systému, kdy server může
získat totožnost klienta a použít tyto informace ve svém vlastním mechanismu
zabezpečení, ale nemůže klienta zosobnit.
Úroveň zosobnění (Impersonate) server (nebo služba) se může zosobnit do
kontextu zabezpečení klienta, když působí jménem klienta a na počítači klienta.
Jestliže se jedná o službu na vzdáleném počítači, může zosobnit klienta pouze
tehdy, jestliže zpřístupňuje prostředky počítače služby.
Úroveň delegace (Delegate) jedná se o nejúčinnější úroveň zosobnění, kdy se
server nebo služba mohou zosobnit do kontextu zabezpečení klienta pouze v
případě, jestliže působí jménem klienta. Tato úroveň může zpřístupnit
prostředky na počítači služby, ale také prostředky na jiném počítači. Je
podporována pouze v rámci OS Windows 2000 a vyšší. V průběhu postoupení
autority serveru mohou být příslušná oprávnění klienta předána jakémukoliv
počtu strojů. Závěr
Význam konceptu rozhraní SSPI spočívá v tom, že nezáleží, jaký protokol
zabezpečení aplikace používá, pokud protokol definuje požadavky zabezpečení pro
ověření totožnosti komunikace, integritu zpracování zpráv, soukromí přenášených
zpráv a kvalitu použitých služeb zabezpečení. Při splnění těchto požadavků může
být rozhraní SSPI použito jako společná abstraktní vrstva pro zajištění a
ovládání potřebných služeb a umožňuje operačnímu systému Windows 2000 využít je
jako dostatečně flexibilní infrastrukturu zabezpečení.

Návrh a vývoj aplikace
Při návrhu zabezpečení zákaznické aplikace s využitím rozhraní SSPI existují v
podstatě 2 základní možnosti návrhu aplikace. Jednou je samozřejmě použití
rozhraní SSPI přímo s odpovídacím zprostředkovatelem SSP, což může být
relativně obtížná záležitost, v jednotlivých dílčích detailech i nepříjemně
náročná. Tato metoda používá pro implementaci protokolů aplikace zprávy typu
dotaz/odpověď, které přenášejí data zabezpečení.
Druhou možností je zajistit zabezpečenou komunikaci na vyšší úrovni s použitím
různých systémových služeb, které jsou v rámci rozhraní SSPI dostupné. Vývojář
má k dispozici několik takových systémových služeb, které jsou vestavěny přímo
v rozhraní SSPI včetně distribuovaných prvků COM (DCOM). Ty může volat
prostřednictvím vzdáleného volání procedur (RPC), COM+, Winsock 2.0 a WinInet
pomocí připojení přes vrstvu SSL (Secure Sockets Layer).
Návrh a vytvoření zabezpečených aplikací pomocí DCOM a COM+ nevyžaduje žádné
speciální generování kódu ani na straně klienta, ani na straně serveru. Tyto
programové moduly ukrývající potřeby zabezpečení jednotlivých komponent
požadují, aby odpovídající komponenty byly schopny zpracovat zabezpečení
klientské aplikace. V DCOM jsou tyto služby řešeny částečně tajuplně, mnohem
výhodnější je využití schopností, které jsou zabudovány přímo do COM+, jejichž
použití je podstatně jednodušší, než předcházející použitím služeb. Podobně
jakákoliv aplikace vzdáleného volání procedur může použít vlastní RPC rozhraní
API.
V případě Wincocku je zprostředkovatel SSP prostřednictvím společně
definovaného rozhraní integrován do síťového zásobníku a poskytuje jak služby
zabezpečení, tak i služby přenosu. Využívá schopnosti zabezpečení, které jsou
přímo zabudovány do zprostředkovatele SSP.
1 0615 / wep









Komentáře
K tomuto článku není připojena žádná diskuze, nebo byla zakázána.