Webové služby a aplikace jsou pochopitelně založeny na různých zdrojových souborech a dokumentech, k nimž je potřeba řídit přístup, a tím zásadně omezit rizika zneužití dat. Starší varianty služby IIS v této věci zásadně spoléhaly na spolupráci se souborovým systémem NTFS a jeho mechanizmem řízení přístupu – IIS tedy žádnou ochranu v této věci neposkytoval, což přinášelo některé koncepční nevýhody.
Přístup na NTFS může být udělen jen uživateli, který existuje v lokální databázi účtů operačního systému, nebo v Active Directory, a webová aplikace tak musela pracovat v zastoupení někoho takového. Další nevýhodou je nepřenositelnost těchto nastavení – jakmile byla aplikace přenesena na jiný webový server v podobě zdrojových dat, konfigurace zabezpečení souborových zdrojů musela být provedena samostatně v cílovém prostředí.
Nová koncepce ochrany přístupu ke zdrojům je označována jako IIS URL Authorization a pracuje na odlišné úrovni. Jednotliví „uživatelé“ webových aplikací jsou sice stále zakládáni jako místní účty ve Windows, ke zpřístupnění zdrojů však již není využíváno zabezpečení NTFS, ale nezávislé řízení přístupu.
Ne složky a soubory na NTFS, ale jednotlivé webové stránky tak mohou obdržet své nastavení s určením, kteří uživatelé či členové kterých skupin mohou k poskytovaným datům. Jedná se o poměrně zásadní změnu, neboť filtrování probíhá na úrovni požadované URL, a ne až posléze na případném žádaném souboru. Webový server vše obstará a na nikoho nespoléhá, což je jak bezpečnější, tak výkonnostně lepší a navíc přenositelné v rámci běžných webových konfiguračních souborů.
Nevkusný požadavek? Zahodit!
Léta provozu verzí IIS 4, 5 a 6 a mnohé bezpečnostní záplaty ukázaly, jak nebezpečné je dovolit klientům webových serverů zasílat prakticky libovolný řetězec s požadavkem. Mnoho nechvalně proslulých trhlin v bezpečnosti IIS bylo zapříčiněno zkrátka tím, že žádný mechanizmus nekontroloval, zdali URL neobsahuje podezřelé sekvence či není příliš dlouhý. Nový mechanizmus s názvem Request Filtering čelí právě těmto případným hrozbám.
Stejně jako řada jiných nastavení i filtrování požadavků, přesněji jejich řetězce URL, je zapsáno v konfiguračních souborech webových aplikací, což zásadně vylepšuje přenositelnost takto zabezpečených webů. Možnosti filtrování jsou vyhovující a dovolují připravit sadu účinných pravidel: server může hledat a blokovat požadavky s podezřelým řetězcem (či sekvencí), dále můžeme v požadavku výslovně povolit či odepřít zasílání souborů určitých přípon a také třeba zkontrolovat délku řetězce, a zamezit tak nepředpověditelnému chování v mezních situacích.
Na první pohled se může zdát, že jde o ochranu hrubou a přibližnou, ale to je přesně to, oč nám zde běží: rychlou kontrolou požadavku můžeme ihned zahodit celou škálu potenciálně nebezpečných volacích sekvencí a ušetřit webový server také výkonnostně.
Pestrá paleta
Vývojáři IIS se spolu se zabezpečením zaměřili také na stabilitu aplikací a výsledkem jsou některé zajímavé koncepční změny, jako jsou třeba oddělené prostory spouštění webových aplikací – application pools.
Webové aplikace mohou běžet ve svých výkonných „pracovních“ procesech, které pracují nezávisle, disponují vlastní identitou pro řízení přístupu a hlavně svou stabilitou neohrožují ostatní. V případě potíží s aplikací pak takovýto pracovní proces neovlivňuje procesy jiné a jeho případné narušení zabezpečení s sebou nestahuje ostatní stabilní aplikace a části IIS.
Další zajímavá změna, která je hodně spojena s výkonností služeb IIS, se také dotýká zabezpečení. Protokol SSL/TLS se stal naprosto dominantním mechanizmem pro zajištění bezpečného kanálu nejen pro obsah stránek, ale i autentizaci uživatelů, a výkonnostní požadavky si vyžádaly změnu implementace – nově pracuje podpora SSL v privilegovaném režimu jádra procesoru, což je běžně vyhrazeno třeba ovladačům hardwarových zařízení. Cílem je zrychlit jeho práci, a ve výsledku tak nalákat správce k jeho důsledné implementaci.
Další zajímavá změna je z trošku jiného soudku. Použití textových konfiguračních souborů přináší snadnější přenositelnost, ale mimo to je možné mnohem bezpečněji zapsat přímo do souborů také hesla k různým ověřovacím účelům.
Takovéto údaje jsou díky .NET Frameworku následně šifrovány silným mechanizmem s využitím moderního standardu AES. Lze tak vyřešit jinak tradičně velmi choulostivou situaci, pokud není jiného zbytí, než heslo někam opravdu zaslat.
Závěrem pak nezaškodí připomenout, že ke zvýšení zabezpečení rozhodně přispívá i možnost instalace varianty operačního systému Core, která nezavádí grafické uživatelské rozhraní. Právě GUI a jeho součásti představovaly značné riziko díky nalézaným bezpečnostním slabinám, a zprostředkovaně tak ohrožovaly aplikace na bázi IIS, přestože jim grafické knihovny většinou nechyběly.
PŘEDPLATNÉ
ČLÁNKY DO MAILU