Windows 7 AppLocker

Autor: Ondřej Výšek

Obdobné nástroje jsou k dispozici již z dob uvedení Windows XP a Windows Server 2003, kde jsou známé pod pojmem Software Restriction Policy (SRP). AppLocker si klade za cíl vyřešit všechny problémy, které vznikaly při nasazení a správě SRP.

Po několik generací operačních systémů Windows, pokud jste potřebovali omezit využívaný, resp. spouštěný software koncovými uživateli byla jedinou možností právě Software Restriction Policy nebo nástroje třetích stran, jako například Bit9 Parity. Při použití SRP nebylo možné jednoduše vytvořit politiku a následně ji spravovat, pokud se měnily verze používaných software, což SRP odsunulo do pozice téměř nevyužívané technologie. V průběhu času, při vydání Windows Vista byly přidány pouze drobné úpravy, které se týkaly například tzv. „Network zone rules“ a byl přidán nový typ uživatele „Basic User“. Kompletní změna přišla právě až ve Windows 7 a s tím přišlo i přejmenování na AppLocker. Nepočítejte s tím, že vás AppLocker spasí, ale změny, které jsou v této technologii ve srovnání se Software Restriction Policy jsou dost zásadní a když nic jiného, činí s AppLockeru použitelnou technologii v podnikovém prostředí.

Letmý pohled na AppLocker

Před tím, nežli budete schopni plně využít a ocenit AppLocker, je nutné porozumět tomu, jak funguje, jak fungovaly Software Restriction Policy a proč vlastně nebyly tolik použitelné. AppLocker využívá stejná pravidla, jako tomu bylo v případě Software Restriction Policy, ale tato pravidla jsou pomocí AppLockeru mnohem lépe spravovatelná a to především s ohledem na životní cyklus aplikací.

Software Restriction Policy jsou založena na několika typech pravidel, můžete vytvořit pravidla na základě certifikátu aplikace, hashe souboru, cestě k souboru, internetových zónách a síťových umístění. Pojďme se na jednotlivé typy pravidel podívat blíže.

Pravidla na základě certifikátu aplikace

Tento typ pravidel je pravděpodobně tím nejbezpečnějším způsobem využití jednotlivých typů pravidel. V tomto případě se při spouštění aplikace kontroluje digitální podpis aplikace, kterou uživatel spouští a na základě tohoto podpisu je určeno, zdali ji může uživatel spustit či nikoliv. Problém při uvedení Windows XP na trh (a tím i uvedení SRP) byl fakt, že pouze málo z vydavatelů software připojovalo k aplikacím digitální podpisy. Tato situace se od doby vydání Windows XP podstatně zlepšila, ale neustále i v této době existují vydavatelé software, kteří své aplikace nevybavují digitálním podpisem.

Při použití tohoto typu pravidla, řekněme, že povolíme aplikace, které jsou podepsány Microsoftem, budou všechny aplikace s tímto digitálním podpisem spouštěny, resp. koncový uživatel bude mít možnost takové aplikace spouštět. Pokud bychom chtěli některé specifické aplikace uživateli blokovat, není nic jednoduššího, nežli vytvořit jiné pravidlo s vyšší prioritou, které bude tyto specifické aplikace blokovat.

Pravidla na základě hash souboru aplikace

Druhým typem pravidel jsou pravidla, která využívají hash spustitelného souboru aplikace. Idea je taková, že Windows vytvoří matematický hash spustitelného souboru, pomocí kterého se bude při spuštění aplikace kontrolovat. V dnešní době je tento typ pravidla prakticky nevyužitelný, nicméně v minulosti to byl opravdu dobrý nápad. Proč vlastně tento typ pravidla nemá velkého využití? Jedná se především o situaci, kdy aktualizace pro různé aplikace jsou vydávány tak často, že po každé změně aplikace byste museli měnit pravidla, aby odpovídala hash aktualizovaným aplikacím. Pokud byste takovou změnu neprovedli, nebylo by možné aplikaci spustit.

Pravidla na základě cesty k souboru

Tento typ pravidel je jedním z nejméně bezpečných způsobů kontroly. Pravidlo umožňuje blokovat aplikace na základě cesty ke spustitelnému souboru, kam byla aplikace instalována. Takovou cestou může být souborový systém nebo registry. Problém s tímto typem pravidla je především u uživatelů, kteří mají dostatečná práva na instalaci aplikací. Pokud mají taková oprávnění, pak mají oprávnění i na přepsání původní aplikace, která byla povolena, jinou aplikací a tím tak docílit spuštění „nepovolené“ aplikace. Příklad může být jednoduchý, pravidlo povoluje spuštění „C:\Program Files\Microsoft Office\Office14\WINWORD.EXE“, stačí tuto aplikaci přepsat aplikací „C:\Windows\notepad.exe“ a hle, uživatel, byť měl zakázané spouštět notepad, může tuto aplikaci spustit.

Pravidla na základě internetových zón

Tento typ pravidla je typickým příkladem dobrého nápadu, který byl špatně nebo lépe ne zcela ideálně implementován. Základní idea závisí na internetových zónách definovaných v Internet Exploreru (v organizaci ideálně pomocí skupinových politik), kde z určitých internetových zón může uživatel stahovat a instalovat aplikace. To odkud je možné stahovat a instalovat závisí právě na přítomnosti dané stránky v odpovídající zóně. S tímto nápadem však souvisí také několik problémů.
Primárním problémem je pravděpodobně to, že se toto nastavení týká pouze souborů MSI (balíčky Windows Installer). Dalším problémem může být například to, že pravidlo je uplatňováno pouze v čase stahování aplikace. Pokud tedy uživatel stáhne zip archív, který obsahuje exe aplikaci, může tuto aplikaci instalovat/spustit.

Pravidla na základě umístění v síti

Pravidla na základě umístění v síti jsou obdobná pravidlům založených na internetových zónách. Na rozdíl od internetu jsou kontrolována síťová umístění, odkud je aplikace instalována nebo kopírována. Můžete tedy například vytvořit pravidlo, které bude definovat, zdali aplikace má být instalována na lokální počítač. V praxi je tento typ pravidla využitelný pouze v případě, kdy se jedná o síťovou aplikaci – je nainstalována na síťovém sdílení.

Jádro problému

Zmínili jsme možné využití jednotlivých pravidel, jejich výhody a nevýhody. Jádro problému je však ve vlastní Software Restriction Policy, která je navržena tak, aby blokovala určité typy aplikací. Proč je to tedy problém? Důvodem je fakt, že vždy je provozovaný známý počet aplikací a neznámý počet aplikací, které se mají blokovat. Je tedy mnohem snazší pracovat se známým (a podstatně menším) počtem aplikací, což však Software Restriction Policy neumožňuje. Nyní pojďme k technologii AppLocker. AppLocker umožňuje pracovat i přesným opakem, nežli SRP, tedy tím správným způsobem – explicitně zakázat a povolit pouze používané aplikace.

V následujících částech článku si představíme jednotlivé možnosti AppLocker a také projdeme důležité informace, které je zapotřebí mít na paměti ještě před vytvořením prvního pravidla pro AppLocker. Při práci s technologií AppLocker se držte zlatého českého přísloví – „dvakrát měř, jednou řež“, protože konfiguraci, kterou připravíte pro vaše koncové uživatele, se jich dotkne a v případě chybně připravené politiky pro AppLocker a nedostatečného testování znemožníte uživatelům práci a právě tito uživatelé vám připraví horké chvilky.

Kompatibilita AppLocker

Přestože je AppLocker technicky novější verze Software Restriction Policy, tak není kompatibilní s existujícími pravidly pro SRP. Pokud tedy používáte SRP, můžete tato pravidla používat i nadále a budou funkční i v případě, kdy koncovým klientem bude Windows 7. Pokud připravíte nová pravidla pro AppLocker a tato politika bude definována na stejné organizační jednotce jako politika pro SRP, bude politika SRP ignorována a použije se pouze politika pro AppLocker – tedy za předpokladu, že koncovým počítačem jsou Windows 7. Pokud koncovým počítačem jsou Windows XP nebo Windows Vista, bude se používat politika SRP i nadále. Tato situace je proto, že AppLocker je implementovaný pouze ve Windows 7.

Omezení

AppLocker nabízí celou řadu nových možností ve srovnání se Software Restriction Policy, ale i přesto má několik omezení. Největším omezením je pravděpodobně fakt, že v případech, kdy je uživatel správcem na svém počítači, kde je aplikováno nastavení AppLocker, může koncový uživatel díky svým oprávněním obejít aplikaci politik AppLocker.

Obvykle je tato situace komentována způsobem „koncovým uživatelům byste neměli přiřazovat administrátorská oprávnění, měli by fungovat jako Standard user“. Reálný svět však ukazuje něco jiného, kde se ve výjimečných případech administrátor na koncovém počítači objeví. V některých organizacích, pravděpodobně z důvodů jednoduchosti, jsou všichni uživatelé administrátory. Doba, kdy tato situace byla standardní je dávno pryč – Windows 7 fungují i pro standardního uživatele naprosto bez problémů a to i v případech, kdy se jedná o mobilního uživatele – tedy zamyslete se nad možnou změnou uživatelů z administrátorů na standardního uživatele.

V případech, kdy uživatel vyžaduje plný administrátorský přístup k počítači je možné opět pomocí nastavení skupinových politik omezit přístup k administračním nástrojům. Příkladem může být zákaz přístupu k editoru registry nebo Windows PowerShell, nicméně opět, přemýšlejte dvakrát. Například při řešení problémů nebo hromadné konfiguraci počítačů může být přístup k těmto nástrojům zapotřebí.

Základní strategie při práci s AppLocker

Tak jak jsem zmínil, je možné použít několik typů pravidel při nastavování politiky AppLockeru, kde tato pravidla jsou víceméně identická s těmi, která jsou součástí Software Restriction Policy. Ve skutečnosti je velice jednoduché se dostat do potíží při práci s AppLockerem, pokud přesně nevíme, jak pracuje. Z tohoto důvodu doporučuji tuto kapitolu bedlivě přečíst.

Předpokladem, pro bezpečné (a účinné) využití AppLockeru je nutné pochopit filozofii, kterou Microsoft ukryl za jednotlivá pravidla. Tato filozofie by se dala zobecnit (ostatně jak jsem psal výše) ne konstatování, že jsou v organizacích provozovány konkrétní, pojmenované aplikace. V kontrastu proti tomuto konstatování je možné zmínit, že budeme blokovat neznámý počet, neznámých aplikací, které organizace nevyužívá. Je také důležité se oprostit od vnímání aplikací v tradičním pohledu a spíše aplikace vnímat jako jednotlivé spustitelné soubory. Pokud bychom převedli předchozí konstatování do praxe, budeme chtít blokovat některé „aplikace“, které nejsou schválené v rámci organizace, starší verze aplikací, různé hry, mallware a tak by seznam mohl dále pokračovat.

Tímto příkladem jsem chtěl pouze poukázat na skutečnost, že existuje mnoho aplikací, které by uživatel neměl/nemusel používat ve srovnání s aplikacemi, které potřebuje pro svou práci. Opět se můžeme vrátit k tvrzení, že je snazší vytvořit seznam povolených aplikací nežli bojovat s větrnými mlýny aplikací nepovolených. Toto by se dalo označit za filozofii, která je obsažena v pravidlech AppLockeru.

I v případě, že byste si ze článku neodnesli nic dalšího, mějte na vědomí, že pravidla AppLockeru jsou organizována do skupin. V rámci takových skupin je možné explicitně zakázat či povolit aplikace, nicméně pravidla AppLockeru budou spíše využívána pro grantování přístupu k něčemu – aplikaci. Další důležitou informací je, že při vytvoření jednoho pravidla nebo skupiny pravidel Windows budou předpokládat, že aplikace, které nejsou definovány v těchto pravidlech, jsou zakázané. Pro příklad si můžeme uvést situaci, kdy si přejete povolit uživatelům Microsoft Office a Internet Explorer, vytvoříte tedy pravidlo, které umožňuje uživatelům spustit tyto aplikace a zakázat spouštění ostatních aplikací a to včetně vlastního operačního systému. Věřte nebo ne, je velice snadné „zničit“ celý operační systém pomocí chybně vytvořených pravidel v AppLocker. Právě předcházení těmto skutečnost je předmětem následujících kapitol.

Poslední věcí v této kapitole, o které bych rád pohovořil, jsou zákazy. Můžete namítnout, že jsem tuto problematiku dříve zmiňoval, kde v případech uživatele – administrátora je možné zakázat přístup k administračním nástrojům, ale vytvořit výjimku například pro helpdesk. Toto je něco, čemu se budeme věnovat v dalších kapitolách, nicméně pro tuto chvíli chci pouze poukázat na to, že vypracování takovéto složitější konfigurace vyžaduje trochu více přemýšlení.

Pokud bychom kompletně opomněli AppLocker, můžeme kompletně zakázat pomocí skupinové politiky přístup k administračním nástrojům pro všechny uživatele. Dále je možné konfiguraci rozšířit o pouze specifické cílení takového nastavení – zakaž přístup k administračním nástrojům, vyjma podpory.

První kroky s AppLockerem

V této kapitole se zaměříme především na informace, které se týkají použití technologie AppLocker a úvodní konfiguraci, která musí být provedena ještě před tím, nežli vytvoříte první pravidlo. Zaměříme se také na to, jak se vyhnout zamčení systému i pro vás, coby administrátora, který připravuje pravidla pro AppLocker.

Konzola AppLocker

Přístup do konzole AppLockeru je velice jednoduchý, jedná se o běžný MMC modul, který je součástí Editoru zásad skupiny, můžete jej otevřít v: Konfigurace počítače | Nastavení systému Windows | Nastavení zabezpečení | Zásady řízení aplikací | AppLocker. AppLocker je možné také využít v lokálních zásadách zabezpečení za použití Místních zásad zabezpečení v položce Nastavení zabezpečení | Zásady řízení aplikací | AppLocker. Po otevření můžete vidět rozhraní AppLockeru jako je na následujícím obrázku:

Obrázek 1 – konzola AppLocker.

Sekce Začínáme

Jak je vidět na obrázku 1, konzole je rozdělena do třech částí. V první sekci – Začínáme je důležité varování, o kterém jsem psal již výše, jakmile začnete vytvářet pravidla pomocí AppLocker, budou povoleny pouze ty aplikace, které definujete, ostatní budou zakázané. Také můžete shlédnout informace, které jsou uvedeny pod odkazy v této sekci.

Sekce Konfigurovat vynucování pravidel

Při prvním spuštění konzole AppLocker se zobrazuje varování, které říká, že pro vynucení pravidel musí být spuštěna služba Identita Aplikace (Application Identity). Pokud se podíváte na následující obrázek, zjistíte, že tato služba není ve výchozím stavu nastavena pro automatické spouštění, viz obrázek 2.

 
Obrázek 2 – nastavení služby Identita aplikace.

Pokud experimentujete se technologií AppLocker na jednom počítači, bude asi nejjednodušší tuto službu spustit ručně ve správci služeb a nastavit službu Identita aplikace na automatický start. Pokud však plánujete nasadit AppLocker v organizaci, je pravděpodobně tou nejjednodušší cestou konfigurovat tuto službu pomocí Skupinových politik na všech stanicích najednou. Systémové služby jsou umístěny v cestě Nastavení Počítače | Nastavení Windows | Nastavení zabezpečení | Systémové služby.

Pokud se opět podíváte na první obrázek, můžete si všimnout, že sekce Konfigurovat vynucování pravidel obsahuje odkaz „Konfigurovat vynucování pravidel“. Po kliknutí na tento odkaz je otevřeno okno s nastavením jako na následujícím obrázku 3.

Obrázek 3 - nastavení vynucování pravidel.

Tak jak vidíte na obrázku 3, pravidla AppLocker nejsou ve výchozím nastavení povolena a vynucována. Nenechejte se tímto dialogovým oknem zmást. Dokumentace Windows 7 říká, že není-li vynucování povoleno nebo nakonfigurováno, ale i přesto jsou přítomna pravidla / skupiny pravidel, tato pravidla jsou vynucována.

Myslete na tuto důležitou informaci, jakmile začnete vytvářet pravidla. Aplikace, které nejsou explicitně definovány, nebude možné spustit a to i v případě, že jste nezaškrtli vynucení pravidel v předchozím dialogu!

Abychom předešli nechtěnému „uzamčení“ operačního systému, doporučuji zvolit všechna 3 zaškrtávací pole a u každého z nich zvolit konfiguraci „Pouze audit“, tak, jak ukazuje následující obrázek 4.

Obrázek 4 – nastavení audit módu.

Jakmile jsou pravidla nastavena pouze v auditním módu, nejsou pravidla, která jsou definována vynucena. Při auditním módu jsou informace o povolení či zakázání aplikace při jejím spuštění zapsána do EventLogu AppLocker.

Je hned několik důvodů, proč začít pouze s módem audit. Prvním z nich – jste v bezpečí. Jakékoliv změny, které provedete, jsou pouze zapisovány do logu, žádná z nich není vynucena a uživatelé (včetně vás) nejsou omezeni. Druhým důvodem je testování připravených pravidel – v logu událostí uvidíte co přesně se děje, jakým způsobem je zapotřebí konfiguraci modifikovat tak, aby přesně odpovídala vašim požadavkům. Zde je dobré zmínit, že je možné využít SCOM pro sběr informací z koncových počítačů a jejich vyhodnocení, případně EventLog forwarding. S ohledem na to, že budou události umístěny na jednom počítači, bude mnohem snazší zajistit nápravu případných chyb. Na druhou stranu můžete také zjistit, že vámi připravená pravidla jsou příliš restriktivní a brání uživateli v práci. V této oblasti vám opět napomůže auditní mód, ladit pravidla pro koncové uživatele, aniž to má na uživatele restriktivní dopad.

Rozšířené nastavení AppLocker

Pokud se ve vlastnostech AppLocker přepnete na záložku Upřesnit, máte možnost instruovat AppLocker o tom, že se mají vytvářet také pravidla pro DLL knihovny, tak jak je na následujícím obrázku 5 

Obrázek 5 – Pravidla pro soubory DLL.

První věcí, které si na obrázku 5 všimnete, je zvýrazněná informace o dopadu pravidel na výkon operačního systému. Důvod, proč je toto nastavení na separátní záložce se dá jednoduše vysvětlit. Pokud toto pravidlo povolíte, musíte povolit všechny jednotlivé DLL knihovny (a to včetně těch, které jsou v operačním systému). Asi si dokážete představit, že je to velký kus práce a je velice snadné některou knihovnu vynechat. Informace, která je na obrázku zvýrazněna zmiňuje dopad na výkon systému. To je především z toho důvodu, že veškeré knihovny při přístupu k funkcím v těchto knihovnách musí být pokaždé zkontrolovány.

Pravidla týkající se DLL knihoven jsou velmi užitečná, pokud řeším velmi zabezpečené výpočetní prostředí. Pro běžnou organizaci pravidla DLL knihoven však přinesou více starostí nežli užitku. Tedy opět, dvakrát přemýšlejte, nežli pravidlo povolíte.

Před prvním pravidlem

Doposud jsme hovořili o tom, jak AppLocker funguje, jaké jsou typy pravidel, které lze využít při práci s AppLocker a jak provést základní nastavení technologie AppLocker. Nyní se pojďme zaměřit na práci s pravidly, jejich tvorbu a úpravu. Pokud jste přeskočili předchozí kapitoly, dovolte mi připomenout, že pravidla v rámci AppLockeru explicitně povolují a nedefinované (nepovolené) aplikace jsou zakázané. Pokud tedy nevytvoříte pravidla precizně, můžete se dostat do složitých situací a to včetně nefunkčního systému Windows. Ještě než začnete vytvářet pravidla a experimentovat s nasazením technologie AppLocker, doporučuji provést zálohu skupinových politik a testovacího počítače, pokud pracujete s AppLocker pouze v rámci lokálních skupinových politik, pak proveďte zálohu tohoto počítače.

AppLocker umožňuje použití třech různých módů vynucení pravidel – Není nakonfigurováno, Vynucení pravidla, Pouze audit. Pokud je vytvořené nějaké pravidlo, pak je vynucováno při konfigurovaných módech „vynucení pravidla“ a „není konfigurováno“.  Z tohoto důvodu doporučuji na začátek využití audit módu, tak jak je popsáno v předchozí kapitole.

Výchozí pravidla

Jakmile začnete využívat technologii AppLocker, doporučuji začít s výchozími pravidly, která jsou přítomná po úvodní konfiguraci. Dříve jsem také zmínil že „šikovnou konfigurací“ pravidel můžete blokovat vlastní operační systém. Výchozí pravidla jsou navržena tak, aby této situaci předešla.

Naneštěstí tato výchozí pravidla nejsou přítomna automaticky, ale je nutné pomocí konzole tato pravidla vytvořit. Nejedná se o nic složitého. Otevřete konzolu Správy skupinových politik (gpmc.msc) a v sekci Nastavení počítače | Nastavení Windows | Nastavení zabezpečení | Zásady řízení aplikací | AppLocker | Pravidla pro spustitelné soubory. Nyní pomocí pravého kliku myší vyberte „Vytvořit výchozí pravidla“.
Jakmile jsou vytvořena tato výchozí pravidla, zopakujte akci pro „Pravidla Instalační služby systému Windows“ a Pravidla pro skripty“. Tímto postupem jste vytvořili výchozí pravidla, která zajistí chod aplikací, které jsou součástí operačního systému a operačního systému jako takového.

Podívejme se na výchozí pravidla

Výchozí pravidla, jak jsem napsal výše, jsou primárně určena pro zajištění chodu Windows jako takových, ale také mohou být v rozporu s předpisy nebo pravidly, které máte ve vaší organizaci. Dalším krokem tedy může být doladění těchto výchozích pravidel a obvykle tomu tak i bude.

Obrázek 6 – výchozí pravidla pro spustitelné soubory.

Tak jak můžete vidět na obrázku 6, jsou vytvořena 3 výchozí pravidla pro spustitelné soubory (a situace je stejná i v případě Instalační služby systému Windows a skriptů). První pravidlo, které je vytvořeno zajišťuje skupině Everyone spuštění souborů ve složce %PROGRAMFILES% (adresáře C:\Program Files a C:\Program Files (x86) pokud je váš operační systém na disku C: ). Další pravidlo opět skupině Everyone umožňuje spouštět aplikace v adresáři %WINDIR% (adresář C:\Windows) a poslední pravidlo umožňuje skupině administrátorů spouštět vše.

Obecně by se dalo říci, že poslední, tedy třetí výchozí pravidlo by nemělo být modifikováno a omezit se na konstatování, že skupina BUILTIN\Administrators potřebuje kompletní přístup k systému. Na druhou stranu se dá říci, že první pravidla by měla být modifikována, je lepší umožnit spouštění specifických aplikací, nežli kompletní přístup ke všem aplikacím nainstalovaných v Program files.

Nezáleží na tom, jak budou pravidla připravena a aplikována, je nutné mít na paměti to, že pravidla umožňují uživateli aplikaci spustit, nikoliv instalovat. Pro instalaci aplikace musí mít uživatel potřebná oprávnění, tedy mimo jiné i právo zápisu k adresáři Program Files. Zde je další zajímavá situace, ve výchozím nastavení má uživatel oprávnění čtení a zápisu do adresáře Temp v uživatelském profilu (nikoliv v adresáři Windows). Může se tedy za jistých okolností podařit instalace aplikace do Temp adresáře v uživatelském profilu a aplikaci následně spustit – adresář C:\Users není definován v žádném výchozím pravidle.

Před tím, nežli se pustíme do modifikace pravidel, podíváme se na pravidla, která se týkají Instalační služby systému Windows (Windows Installer). Obdobně jako jsou vytvořena výchozí pravidla pro Spustitelné soubory, i zde je sada výchozích pravidel, tak jak je na následujícím obrázku (Obr. 7) 

Obrázek 7 – výchozí pravidla pro Instalační službu systému Windows (Windows Installer).

První z těchto pravidel umožňují instalaci aplikaci uživateli v případě, že je instalační soubor (.msi) digitálně podepsaný. Nezáleží na tom, kdo tento soubor podepsal nebo odkud byl stažený,… Soubor je digitálně podepsaný, uživatel jej může instalovat.

Druhým pravidlem umožňujeme uživateli instalovat soubory, které se nacházejí v adresáři %systemdrive%\Windows\Installer. V takovém případě instalační soubory nemusí být podepsané. V tomto adresáři se ukládají instalační soubory již nainstalovaných aplikací pro účely jejich modifikací či odebrání. Standardní uživatel nemá oprávnění v tomto adresáři cokoliv vytvářet ani zapisovat.
Posledním pravidlem je opět povolení pro BUILTIN\Administrators, kteří mohou spouštět jakékoliv instalace na systému a opět, toto pravidlo by nemělo být modifikováno.

Modifikace výchozích pravidel

Z předchozí kapitoly je vidět, že výchozí pravidla nijak zásadně neomezují uživatele, což může být skoro až k pláči. V dalších kapitolách se podíváme na vytváření a modifikaci pravidel, aby odpovídala přesně vašim požadavkům. Tak jak jsem zmínil, výchozí pravidla jsou tu především s ohledem na zajištění chodu systému jako takového, nikoliv na omezování uživatelů.

Hovořili jsme o různých pravidlech, jako jsou spustitelné soubory, instalace aplikací a skripty. Je důležité si také uvědomit, které soubory se kontrolují v jednotlivých pravidlech. U spustitelných souborů to jsou soubory .EXE a .COM. Ano, dá se namítnout, že je celá řada spustitelných souborů jako například .BAT, .PIF a další, nicméně AppLocker se omezuje pouze na tyto dva typy spustitelných souborů. V případě Windows Installer se restrikce týkají souborů .MSI a .MSP u skriptů jsou to pak soubory .JS, .PS1, .VBS, .CMD, .BAT. Mimo DLL souborů, o který jsem psal výše, je možné využívat v jednotlivých pravidlech tyto typy souborů a připravit tak odpovídající pravidla.

Anatomie pravidel

Klíčem k vytváření nových pravidel nebo k modifikaci existujících pravidel AppLockeru je znalost základních komponent, které tvoří kompletní pravidlo a jak tyto komponenty spolupracují. Jakmile porozumíte těmto základním komponentám, můžete začít jednoduše upravovat výchozí pravidla, která jste připravili v konzoli v předchozí kapitole. Úpravu pravidel provedete buďto dvojkliknutím na pravidlo anebo kliknutím pravým tlačítkem myši a volbou položky Vlastnosti z nabídky.
Pokud vytvoříte nové pravidlo, je spuštěný průvodce, který vám pomůže pravidlo vytvořit. Na rozdíl od tohoto průvodce znamená pozdější úprava pravidla ruční práci, zde již žádný průvodce není. V obou případech pak upravujete stejné položky a proměnné, které modifikují pravidlo.
Pokud se podíváte na obrázek 8., vidíte okno s vlastnostmi pravidla, které můžete modifikovat. První možností je název pravidla, popis a stav pravidla – zdali je povolené či zakázané. Z mé vlastní zkušenosti je dobré do popisu pravidla zapsat co dané konkrétní pravidlo dělá, značně to zjednoduší život ve chvílích hledání a řešení problémů. Poslední volbou, která je na první záložce je volba skupiny, které se dané pravidlo týká a bude na ni uplatňované.

 Obrázek 8 – základní vlastnosti pravidla.

Další vlastnosti pravidel jsou nastavovány na záložce cesta. Na této záložce definujeme, kterých aplikací se bude dané pravidlo týkat. Na obrázku 9 je vidět stejné pravidlo jako v předchozím případě a cesta je zapsána jako hvězdička (*), což značí, že se pravidlo týká všech aplikací v rámci systému, dalo by se označit jako „jakákoliv cesta“.

Obrázek 9 – nastavení cesty k aplikacím.

Poslední záložkou, která slouží pro úpravu pravidel je záložka Výjimky. Jak již jméno napovídá, je možné definovat výjimky, na které se pravidlo nebude vztahovat – viz. obrázek 10.

Výjimka může být vydavatel aplikace, souborový hash nebo cesta k aplikaci. Jak je uvedeno v předchozím příkladu, které definuje, že skupina Administrators  má možnost spouštět jakékoliv aplikace, ale výjimkou může být složka C:\Program Files\Windows Media Player, tak jak je na obrázku 11.

Obrázek 10 – nastavení výjimek v pravidle

Obrázek 11 – nastavená výjimka pravidla.

Takto připravená výjimka při spuštění souboru způsobí hlášení (viz obrázek 12) a uživateli je odepřeno spustit aplikaci.

Obrázek 12 – odmítnutí spuštění aplikace podle pravidla

Pokud bychom identickou výjimku nastavili na první výchozí pravidlo, které se týká skupiny Everyone a poslední výchozí pravidlo nechali bez jakékoliv výjimky, pak běžný uživatel nebude mít možnost aplikaci spustit, členové skupiny Administrators aplikaci spustí bez problémů.

Pokud hovoříme o výjimkách, je asi dobré zmínit také fakt, proč je možné vytvořit pravidlo, které mi zakazuje a povoluje aplikace, když jsem dříve zmínil, že technologie AppLocker pracuje na principu „co není povolené, je zakázané“. Principem pravidel, která zakazují je s ohledem na existenci výjimek, která povolí spouštění aplikace. Je tedy možné pravidlo postavit tak, že skupina Everyone bude mít zákaz a výjimkou bude skupina Administrators, která bude mít spouštění povoleno. Příklad může být následující. Skupina everyone bude mít odepřený přístup do adresáře C:\Program Files\Microsoft, výjimka bude skupině administrátorů přístup udělovat (pozor, toto je pouze příklad!!) tedy vyjma administrátorů žádný uživatel nespustí aplikaci z C:\Program Files\Microsoft.

Automaticky generovaná pravidla

Jak postupně prohlubujete znalosti týkající se AppLockeru a pravidel, která je možné využít, tak je si můžete všimnout, že po pochopení principu není AppLocker zase tak složitou technologií. Samozřejmě můžete využít kompletní manuální cestu a pravidla vytvářet ručně, ale existuje také průvodce, který vám s přípravou nových pravidel pomůže a díky tomu ušetří velkou spoustu času.

Pokud tedy chcete připravit pravidla pro počítače, není nic jednoduššího, nežli kliknout pravým tlačítkem myši na odpovídající skupině pravidel (aplikace, installer, skripty) a zvolit „Automaticky generovat pravidla“ – viz obrázek 13. 
 
 
Obrázek 13 – průvodce automatickým generováním pravidel.

Po kliknutí je spuštěný průvodce, kde odpovíte několik vcelku jednoduchých dotazů, jako je cesta, kde jsou instalovány aplikace atd. Co se cesty k aplikacím týče, dejte pozor, jakou bitovou verzi operačního systému používáte x86 či x64. Byť je cesta k programovým souborům reprezentována identicky %PROGRAMFILES%, tak některé soubory nemusí být dostupné v obou adresářích apod. Jakmile projdete průvodcem a rozhodnete se, jaká pravidla generovat, průvodce analyzuje počítač a připraví pravidla pro vás. Výstup průvodce je pak na obrázku 14.
 

Obrázek 14 – Dokončení průvodce automatického generování pravidel.

Ještě před vlastním vytvořením pravidel si můžete prohléhnout, jaké soubory byly analyzovány a jaká pravidla s jakými parametry budou vytvořeny.

Při práci s průvodcem doporučuji pracovat na koncové stanici, která je nainstalována pomocí tzv. standardní image, tedy instalace, kterou koncoví uživatelé používají. Nedoporučuji spouštět průvodce na serveru nebo administrátorské stanici, mnohé aplikace nemusí být nainstalovány a naopak jsou instalovány některé aplikace navíc. Výsledek by tedy nemusel odpovídat realitě a použití koncovým uživatelem. Vytvořená pravidla pomocí průvodce jsou na obrázku 15.
 

Obrázek 15 – výchozí pravidla a pravidla vytvořená pomocí průvodce.

Po vytvoření pravidel můžete samozřejmě tato pravidla libovolně modifikovat a rozšiřovat dle potřeby.

Na závěr

Na začátku článku jsme se zabývali původní technologií na blokování aplikací – software Restriction Policy a postupně jste se seznámili s novou technologií Windows 7 – AppLocker. Na závěr lze říci jen to, že AppLocker je neobyčejně velkým vylepšením oproti SRP, které splní nejedny požadavky i ve velké organizaci. Nicméně i v této oblasti existují produkty, které nabídkou funkcí AppLocker převyšují, nicméně se jedná o další, placené produkty. Proč tedy nevyužít funkce, které nabízí operační systém a svou funkcionalitou odpovídají požadavkům organizace.

Z mých osobních zkušeností lze AppLocker také označit jako dobrého sluhu a zlého pána, přemýšlejte před nasazením pravidel a provádějte řádné testování.

Windows 7 obsahují další velice užitečnou funkci, která se skrývá pod názvem UAC (User Account Controll – Řízení uživatelských účtů). Při vhodném nastavení a nasazení UAC, AppLocker a standardních uživatelů se můžeme dostat do stavu, kdy nemusí být zapotřebí souborový antivirus (hovořím hypoteticky). UAC mi nedovolí zápis souborů do systémových částí, potažmo uživatelského profilu (Internet Explorer se zapnutým UAC má nižší oprávnění nežli standardní uživatel), naproti tomu AppLocker zajistí to, že i v případě uložení aplikace nebude tato aplikace spuštěna. AppLocker je velice silnou technologií, která napomůže především v podnikovém prostředí ke standardizaci IT prostředí.
 

Články ze série Microsoft TechNet nevytváří redakce Živě.cz, ale partneři programu Microsoft TechNet. Jsou publikovány v rámci mediálního partnerství Živě.cz a společnosti Microsoft.