Na začátek krátké shrnutí. V minulých dílech jsme popsali možnosti systémů Windows v oblasti připojování externích zařízení a jejich použití uživateli. Do verze Windows XP (včetně) jsou možnosti velmi omezené a pro "rozumné" nasazení je třeba použít některý z nástrojů třetích stran. Minule jsme si ukázali, že většinou fungují na principu kernelového driveru (filtru). S jeho pomocí lze kontrolovat, řídit a sledovat chování uživatelů až na úroveň konkrétního zařízení a typ operace. Dnes si ukážeme druhou stranu těchto nástrojů, kterou představuje centrální serverová část, jež je nezbytná pro nasazení ve firemním síťovém prostředí.
Popíšeme si dva typy řešení, se kterými se v praxi setkáme nejčastěji, a pokusíme se nabídnout jejich krátké srovnání. Obě jsou založena na principu klient-server, a to v podobě dvou- nebo třívrstvé architektury. V případě třívrstvé architektury je v cestě mezi klientem a serverem vložen jeden nebo více aplikačních serverů (viz obrázek).
Hlavním úkolem serveru je ukládat nastavení klientů, shromažďovat logovací informace z klientů a provádět audit akcí administrátora. V praxi se používají dva typy. První je založen na použití samostatného databázového serveru. Druhý představuje integrace do systémových politik v rámci Active Directory. Pro ovládání nastavení a kontrolu systému se v obou případech pro jednoduchost používá samostatná konzolová aplikace. U systémových politik nelze z důvodů jejich šifrování provádět nastavení přímo ve správci politik.
Každý z typů má své výhody i nevýhody. Databáze je samostatným systémem, nezávislým na prostředí. Lze použít i volně dostupné databázové systémy (MSDE, 2005 Express...) v jejich defaultní konfiguraci a instalaci. Systémové politiky respektují architekturu a rozložení struktury Active Directory. V databázi je nutné strukturu vytvořit samostatně, ale na druhou stranu může být odlišná od Active Directory a tím pádem i flexibilnější.
Architektura serveru určuje způsob sběru a ukládání logovacích a auditovacích informací. V případě použití databáze není problém do databáze ukládat také tyto informace a v konzole pro správu je následně jednoduše zobrazit a zpracovávat. U řešení založeném na systémových politikách je nutné systém rozšířit o centrální úložiště dat a poskytnout nástroj pro jejich (před)zpracování. Nejčastěji ve formě sdíleného síťového adresáře, do kterého klienti pravidelně ukládají své informace (v šifrované podobě), a samostatné aplikace, která z těchto logů generuje reporty (např. html). Jednou z nevýhod tohoto řešení je, že neumí jednoduše auditovat činnosti administrátorů, provedené v rámci správcovské konzoly. Databázové řešení navíc umožňuje nastavit a rozlišit jemnější práva přístupu (administrátor, auditor, globální administrátor atd.). Ostatní vlastnosti jsou spíše na zvážení administrátorů. Zda je jednodušší spravovat vše v rámci jednoho úložiště nebo mít dvě různá, ale především zda je bezpečné mít pro ně v síti sdílený adresář (skrytý), pro který mají uživatelé právo na čtení i zápis, nebo zda je vše bezpečnější skryté v databázi a uživatelsky přímo nepřístupné.
Na architektuře serveru také přímo závisí typ komunikace mezi klientem a serverem. V případě integrace do Active Directory je komunikace směrem ze serveru na klienta integrována do standardního mechanismu Windows, opačná komunikace (přenos z klienta na server - logy) má pak formu sdíleného adresáře, tedy probíhá prostřednictvím portů pro sdílení adresářů. Druhá varianta využívá komunikaci prostřednictvím aplikačního serveru. Důvodem je omezení přímé komunikace klientů s databázovým serverem. Na databázovém portu komunikuje jen aplikační server, klienti využívají pro komunikaci s aplikačním serverem některý z TCP/IP portů pro obousměrnou komunikaci (šifrovanou). Výhodou řešení je jednodušší směrovatelnost a kontrolovatelnost v různě rozsáhlých sítích a omezení nebezpečí, plynoucích ze standardně používaných portů Windows.
Výhoda použití aplikačních serverů spočívá také v možnosti rozložení komunikační zátěže mezi klienty a server, při použití více serverů také v možném zajištění ochrany proti výpadku některého z nich. Klient se sice umí automaticky přepnout do off-line režimu, ale ten většinou neodpovídá on-line režimu. Přes aplikační server komunikuje i konzola pro správu systému.
Poslední, ale důležitou vlastností je možnost v případě potřeby provést okamžitý update nastavení na klientech a stáhnout aktuální informace z klientů. S tím mají problémy řešení založená na politikách, protože klient neumí sám převzít informaci o tom, že je nutné provést aktualizaci politik. Možností je provedení aktualizace pomocí doplňkových nástrojů pro update politik. Řešení založená na komunikaci s aplikačním serverem standardně poskytují možnost jednoduchého provedení okamžité aktualizace nastavení jednotlivého počítače nebo skupiny počítačů. Stejně tak i obrácené přenosy z klienta na server. U řešení pomocí politik je nutné počkat na uložení informací do sdíleného adresáře (interval ukládání lze nastavit).
Co říci závěrem? O tom, které řešení je lepší nebo použitelnější, je nejlepší se přesvědčit instalací testovacího prostředí a ověřením jeho vlastností. Z pohledu robustnosti a možností se v současnosti jako lepší jeví řešení založené na databázovém serveru, jehož typickým představitelem jsou produkty SecureWave. Obecně platí, že každá nová verze přináší vylepšení a nové vlastnosti, které odstraňují problematické nebo chybějící funkčnosti. To, co je dnes nevýhodou, již tedy v další verzi nemusí platit.
Pavel Náplava pracuje ve společnosti Strom B-systems.
PŘEDPLATNÉ
ČLÁNKY DO MAILU