Blokowanie aplikacji przy użyciu zasad ograniczeń oprogramowania

Autor: Chris Corio i Durga Prasad Sayana

Opublikowano: 24 listopada 2008

Zawartość strony

	W jaki sposób działają zasady ograniczeń oprogramowania
	Definiowanie zasad ograniczeń oprogramowania
	Tworzenie spisu aplikacji w środowisku
	Tworzenie dodatkowych reguł
	Reguły stref internetowych
	Wymuszanie zasad
	Działanie w kontekście Użytkownika standardowego
	Aktualne zastosowania zasad ograniczeń oprogramowania
	Zawężająca zasada ograniczania oprogramowania

Gdy profesjonaliści IT szukają sposobu na zredukowanie całkowitego kosztu posiadania (TCO) maszyn typu desktop, zazwyczaj przychodzą im do głowy dwie kluczowe strategie. Pierwsza polega na wyłączeniu kont użytkowników pulpitu z grupy Administratorzy, a druga na ograniczeniu aplikacji, które mogą być uruchamiane przez użytkowników. Radzenie sobie z tego typu problemami może stanowić niemałe wyzwanie w środowisku korporacyjnym, lecz system Windows Vista® oferuje pewne technologie, które mogą pomóc w osiąganiu tych celów.

System Windows Vista i jego funkcja Kontroli konta użytkownika (User Account Control - UAC) pomaga profesjonalistom IT powiązać konta domenowe z grupami użytkowników (Użytkownicy standardowi). Funkcja UAC zmienia domyślny kontekst zabezpieczeń dla wszystkich aplikacji na kontekst użytkownika zamiast administratora. Migracja do grupy użytkowników nadal stanowi nieco onieśmielające zadanie, ale ponieważ branża IT dostosowuje się do nowego paradygmatu, z czasem zadanie to będzie stawać się coraz łatwiejsze.

Po przeanalizowaniu wyzwania, jakie stanowi przeniesienie użytkowników do grupy Użytkownicy (lub czasem jeszcze w trakcie tego procesu), wielu administratorów analizuje, jakie aplikacje muszą być uruchamiane przez użytkowników i rozważa kroki konieczne do zezwolenia jedynie na te aplikacje. Funkcja Zasady ograniczeń oprogramowania (Software Restriction Policy) została zaprojektowana po to, aby pomóc specjalistom IT w realizowaniu tego zadania.

Określa się po prostu, które aplikacje mogą być uruchamiane, a następnie wdraża zasadę przy użyciu Zasad grupy. Wymuszanie takich zasad w obrębie całej korporacji pozwala zredukować koszt TCO, ponieważ blokada ograniczy występowanie problemów związanych z niewspieranymi aplikacjami. Można także użyć zasad ograniczeń oprogramowania na kilka interesujących i bardzo ekstremalnych sposobów, które zostały omówione w ramce zatytułowanej "Zawężająca zasada ograniczania oprogramowania".

W jaki sposób działają zasady ograniczeń oprogramowania

Zasady ograniczeń oprogramowania dążą do szczegółowego kontrolowania, jaki kod może być wykonywany przez użytkownika na maszynie Windows Vista. My, jako administratorzy, tworzymy zasady, które definiują, co może (lub nie może) być uruchamiane w naszym środowisku. Zasady są następnie brane pod uwagę zawsze i wszędzie tam, gdzie istnieje perspektywa wykonania kodu. Między innymi podczas tworzenia procesu, w wywołaniu ShellExecute oraz w czasie uruchamiania skryptu (co omówimy za chwilę).

W przypadku ustalenia, że aplikacja posiada zezwolenie na wykonywanie, zostanie ona uruchomiona. Jednak jeśli okaże się, że nie może być ona uruchamiana, aplikacja zostanie zablokowana, a użytkownik powiadomiony. Na przykład, jeśli spróbujemy uruchomić Pasjansa (Solitaire) z menu Start, a gra ta nie jest dozwolona, zobaczymy okno dialogowe podobne do zaprezentowanego na Rysunku 1.

Rysunek 1: Okno dialogowe pojawiające się, gdy aplikacja jest zablokowana.

Interfejs użytkownika służący do definiowania zasad ograniczeń oprogramowania jest udostępniany za pośrednictwem Edytora obiektów zasad grupy (Group Policy Object Editor - GPOE) i stanowi miejsce, w którym tworzone są zasady blokowania. Istnieje wiele różnych metod definiowania, jaki kod może i nie może być uruchamiany. Po ukończeniu i przetestowaniu zasady można ją rozmieścić.

 Do początku strony

Definiowanie zasad ograniczeń oprogramowania

Pierwszą podstawową decyzją, którą musimy podjąć i która dramatycznie wpłynie na sposób działania zasad ograniczeń oprogramowania w naszym środowisku, jest wybranie domyślnego typu reguły. Zasady ograniczeń oprogramowania mogą być wdrożone w jednym z dwóch trybów: Listy dozwolonych lub Listy odmówionych. Zasadniczo decydujemy, czy chcemy stworzyć zasadę opisującą każdą aplikację, której wolno działać w naszym środowisku, czy też zasadę definiującą każdą aplikację, której działać nie wolno.

W trybie listy dozwolonych domyślną regułą w zasadzie jest Niedozwolone i blokowane będą wszystkie aplikacje, którym bezpośrednio nie zezwolimy na uruchamianie. W trybie listy odmówionych domyślną regułą jest Bez ograniczeń i blokowane będą jedynie aplikacje, które zostaną w sposób jawny umieszczone na liście.

Tryb listy odmówionych jest, jak można się domyślić, nierealistycznym podejściem w przypadku dążenia do redukcji kosztów TCO na szeroką skalę i korzyści w zakresie bezpieczeństwa płynących z ograniczania aplikacji. Tworzenie i utrzymywanie obszernej listy, która blokuje wszystkie złośliwe programy oraz problematyczne aplikacje, byłoby prawie niemożliwe. A zatem zaleca się implementowanie zasad ograniczeń oprogramowania w trybie listy dozwolonych, co oznacza, że domyślną regułą jest Niedozwolone.

 Do początku strony

Tworzenie spisu aplikacji w środowisku

Jeśli planujemy projektowanie zasady określającej, które aplikacje mogą być uruchamiane, musimy ustalić, jakich dokładnie aplikacji potrzebują użytkownicy. Funkcja Zasady ograniczeń oprogramowania oferuje zaawansowana funkcję rejestrowania z bardzo prostą zasadą, która pomaga w szczegółowym rozpoznaniu aplikacji działających w naszym środowisku.

We wzorcowym zbiorze maszyn w naszym środowisku wdrażamy zasady ograniczeń oprogramowania z domyślnym zestawem reguł ustawionym na Bez ograniczeń i usuwamy wszystkie pozostałe reguły. Plan jest taki, że włączymy zasadę ograniczeń oprogramowania, ale nie pozwolimy jej na blokowanie aplikacji. Zamiast tego wykorzystamy ją jedynie do monitorowania uruchamianych programów.

Następnie stworzymy w rejestrze poniższą wartość w celu włączenia zaawansowanej funkcji rejestrowania i ustawienia ścieżki, w której ma zostać zapisany plik dziennika:

"HKLM\SOFTWARE\Policies\Microsoft\Windows\Safer\

CodeIdentifiers"

String Value: LogFileName, <ścieżka do pliku dziennika>

Teraz gdy aplikacja zostanie uruchomiona i przeanalizowana zostanie zasada ograniczeń oprogramowania (jest ona analizowana mimo iż zezwala na uruchamianie wszystkich plików), w pliku dziennika rejestrowany zostanie wpis.

Każdy wpis dziennika zawiera nazwę procesu wywołującego zasadę ograniczeń oprogramowania oraz identyfikator wywołującego procesu (PID), analizowany cel, typ reguły w zasadzie ograniczeń oprogramowania, która została zastosowana oraz identyfikator reguły. Oto przykładowy wpis wygenerowany po dwukrotnym kliknięciu przez użytkownika pliku notepad.exe:

explorer.exe (PID = 3268) identified

C:\Windows\system32\notepad.exe as Unrestricted using

path rule, Guid =

{191cd7fa-f240-4a17-8986-94d480a6c8ca}

Ten plik dziennika reprezentuje każdy element kodu wykonywalnego, jaki kontrować będzie zasada ograniczeń oprogramowania, gdy zostanie włączona i ustawiona w celu blokowania aplikacji. To oznacza, że musimy rozważyć każdy wpis w pliku dziennika i zadecydować, czy powinien on zostać umieszczony na liście dozwolonych aplikacji. Należy zauważyć, że niektóre sprawdzane programy stanowią składniki systemu Windows® i są nieodzowne dla działania systemu.

Opisana technika rejestrowania oferuje czytelny sposób analizowania aplikacji, które zasada ograniczeń oprogramowania napotka w naszym środowisku. Jednak nie jest to jedyna metoda realizowania tego zadania.

Narzędzie Inventory Collector dostarczane w ramach pakietu Microsoft® Application Compatibility Toolkit 5.0 daje nam możliwość tworzenia spisu aplikacji wykorzystywanych w naszym środowisku. Narzędzie to oferuje wiele różnych sposobów odkrywania, jakie aplikacje zostały zainstalowane w naszym środowisku, a także konsoliduje wyniki w centralnej bazie danych.

 Do początku strony

Tworzenie dodatkowych reguł

Gdy już dysponujemy listą aplikacji, które muszą mieć możliwość działania w naszym środowisku, jesteśmy gotowi do stworzenia właściwych reguł, które zezwolą na uruchamianie tych aplikacji. Funkcja Zasady ograniczeń oprogramowania wykorzystuje dwa sposoby identyfikowania kodu, jedna bazuje na właściwościach kryptograficznych aplikacji (takich jak wartość mieszania), a inna definiuje zaufaną ścieżkę lub inny folder, w której powinny znajdować się zaufane aplikacje.

Rysunek 2 ilustruje, gdzie dodajemy reguły zezwalające na uruchamianie aplikacji w węźle Zasady ograniczeń oprogramowania (Software Restriction Policies) przystawki GPOE (gpedit.msc). Najprostszy sposób definiowania aplikacji w naszym środowisku polega na stworzeniu reguły mieszania dla każdego pojedynczego pliku, na który natrafiliśmy w fazie rejestrowania.

Rysunek 2: Wykorzystanie konsoli gpedit.msc do tworzenia zasad ograniczeń oprogramowania.

Ponieważ wartość mieszania jest wartością unikatową dla określonego zestawu bitów, każdy plik w zasadzie będzie posiadał inną wartość mieszania. To podejście jest wyjątkowo bezpieczne i zezwala na uruchamianie jedynie plików określonych w zasadzie.

Oczywiście podejście to posiada również pewne wady. Na przykład w środowisku może znajdować się kilka tysięcy plików. Stworzenie wszystkich reguł za pośrednictwem interfejsu użytkownika zasad ograniczeń oprogramowania stanowiłoby uciążliwe zadanie, a znaczny wzrost liczby reguł mógłby negatywnie wpłynąć na wydajność. Ponadto ponieważ każda aktualizacja aplikacji wymaga wdrożenia w naszym środowisku jednej lub więcej nowych reguł, aktualizacja tak obszernej zasady w przypadku aktualizacji aplikacji mogłaby stanowić ogromne obciążenie.

Na szczęście możemy uniknąć tego problemu, dzięki dostępności dwóch innych sposobów identyfikowania kodu, które ułatwiają stosowanie zasad ograniczeń oprogramowania w naszym środowisku. Podążając dalej ścieżką zabezpieczania kryptograficznego, możemy stworzyć regułę, która zezwoli jedynie na uruchamianie plików podpisanych przy użyciu określonego certyfikatu.

To pomoże w uproszczeniu zadania utrzymywania listy reguł, ponieważ gdy aplikacja jest aktualizowana, nowe pliki są z reguły podpisane przy użyciu tego samego certyfikatu co stare. Jednak jeśli nie chcemy, aby poprzednia wersja pliku mogła być uruchamiana w naszym środowisku, będziemy musieli dodać regułę mieszania Niedozwolone.

Domyślnie analiza reguł certyfikatu jest wyłączona dla zasad ograniczeń oprogramowania. Istnieją dwa argumenty przemawiające za takim rozwiązaniem.

Po pierwsze reguły certyfikatów w zasadach ograniczeń oprogramowania są definiowane przez to, co znajduje się w systemowym magazynie Zaufani wydawcy. Ponieważ magazyn Zaufani wydawcy służy także do innych celów, gdy chcemy użyć go do stosowania reguł zasady ograniczeń oprogramowania, wymaga on więcej czasu i uwagi.

Po drugie, w celu ustalenia, czy podpis pliku jest prawidłowy, trzeba wyliczyć wartość mieszania pliku i porównać ją z informacją z podpisu. Mieszanie pliku to bardzo kosztowna operacja wymagająca odczytania z dysku i przetworzenia całego pliku.

Aby włączyć reguły certyfikatów, musimy przejść do węzła Zasady ograniczeń oprogramowania i zaznaczyć obiekt Wymuszanie (Enforcement) w zaprezentowanym oknie. Następnie klikamy go dwukrotnie w celu otworzenia okna dialogowego jego właściwości i zaznaczamy opcję wyboru Wymuszanie reguł certyfikatów (Enforce certificate rules).

Inny powszechny sposób identyfikowania kodu bazuje na zastosowaniu ścieżek kodu na maszynie lokalnej. Jest to efektywna i skuteczna technika, ale posiada ona jedną wadę, musimy zapewnić odpowiednią konfigurację zabezpieczeń w wybranym folderze.

Jeśli dodamy określoną regułę ścieżki, a zdefiniowana ścieżka umożliwia użytkownikom zapisywanie w niej plików (np. na pulpicie), użytkownicy będą mogli uruchomić, co tylko zechcą, umieszczając plik wykonywalny w tym folderze. Jednak jeśli użytkownicy nie należą do grupy administratorów, zasadniczo nie posiadają oni możliwości modyfikowania czegokolwiek w katalogach Program Files lub Windows. To oznacza, że jeśli wszystkie nasze aplikacje znajdują się w katalogu Program Files i użytkownicy nie są administratorami, warto abyśmy rozważyli opcję zastosowania reguł ścieżki w celu uzyskania bardzo prostej i efektywnej zasady.

Reguły ścieżki oferują również inne funkcje, które dostosowują je do potrzeb określonych środowisk. Umożliwiają stosowanie symboli wieloznacznych oraz zmiennych środowiskowych, co ułatwia definiowanie reguł, które możemy swobodnie przenosić w obrębie środowiska — w końcu nie dla każdego użytkownika %systemdrive% to c:\.

Jest to prawdopodobnie najmniej kłopotliwy sposób identyfikowania kodu pod względem wydajności i utrzymywania. Reguły ścieżki są opcją, którą zdecydowanie należy wziąć pod uwagę, ale trzeba pamiętać o dodatkowych względach bezpieczeństwa.

 Do początku strony

Reguły stref internetowych

Zasady ograniczeń oprogramowania zawierają typ reguły o nazwie Reguła strefy internetowej, jednak odradza się jego stosowanie. Pierwotnie reguły te bazowały na koncepcji, że źródło określonego kodu wykonywalnego mogło być identyfikowane i zaufane, a zatem kod otrzymałby zezwolenie na wykonanie. Niestety trudno jest spełnić to założenie i w związku z tym mechanizm ten nigdy nie działał szczególnie dobrze. Obecnie ten typ reguły nie jest wymuszany w większości punktów wejściowych dla zasad ograniczeń oprogramowania.

W przypadku gdy większość aplikacji jest instalowana w katalogu %Program Files%, ale istnieją inne pliki wykonywalne, które są instalowane w innych miejscach i podpisywane przy użyciu określonego certyfikatu, wykorzystanie rożnego typu reguł ma sens. Wystarczy kilka reguł mieszania i parę reguł ścieżki i otrzymujemy zasadę zgodną z naszymi potrzebami.

Należy tylko pamiętać, że istnieje określona kolejność przetwarzania reguł (jak pokazano na Rysunku 3). Reguły certyfikatu są najbardziej precyzyjne, reguły mieszania są następne, dalej reguły ścieżki, a następnie reguły ścieżki z użyciem symboli wieloznacznych. A zatem jeśli fragment kodu jest identyfikowany przez regułę mieszania i regułę ścieżki, przeważy poziom zabezpieczeń reguły mieszania.

Rysunek 3: Kolejność przetwarzania reguł.

 Do początku strony

Wymuszanie zasad

Funkcja Zasady ograniczeń oprogramowania zapewnia szerokie pokrycie zabezpieczanego systemu. Koncepcja jest taka, że każda lokalizacja umożliwiająca wykonywanie kodu powinna być zintegrowana z zasadami ograniczeń oprogramowania i w związku z tym powinna sprawdzać zasadę, aby upewnić się, czy kod wykonywalny może być uruchamiany.

Chociaż istnieje wiele miejsc, w których sprawdzane są zasady ograniczeń oprogramowania, najprostszym punktem wejściowym jest CreateProcess. W czasie pracy API CreateProcess zasada jest analizowana w celu ustalenia, czy plik reprezentuje aplikację posiadającą zezwolenie na wykonywanie. Kontrola zasady jest dokonywana przez publicznie udokumentowany interfejs API SaferIdentifyLevel. Ogólny proces został zilustrowany na Rysunku 4 (interfejs API SaferIdentifyLevel zostanie za chwilę omówiony w sposób bardziej szczegółowy).

Rysunek 4: Wykorzystanie SaferIdentifyLevel do określania, czy plik może zostać wykonany.

Oprócz CreateProcess, kolejnym najczęściej wykorzystywanym API, w którym wymuszane są zasady ograniczeń oprogramowania, jest ShellExecute. Jest to interfejs API wywoływany, gdy użytkownik kliknie aplikację w menu Start lub dwukrotnie kliknie obiekt znajdujący się na pulpicie.

Interfejs API ShellExecute może być wywoływany dla plików w wielu różnych formatach. W przypadku plików takich jak .txt wywołanie interfejsu API ShellExecute na pliku nie powoduje z technicznego punktu widzenia wykonania pliku, a jedynie jego otworzenie. Z tego względu zasady ograniczeń oprogramowania zawierają listę typów plików wykonywalnych, aby mogły kontrolować, jakiego typu pliki mają być poddawane sprawdzeniu po wywołaniu ShellExecute. Tę listę typów plików wykonywalnych można dostosowywać za pośrednictwem interfejsu użytkownika zasad ograniczeń oprogramowania.

Poza CreateProcess oraz ShellExecute, istnieją dwa inne kluczowe punkty integracji: LoadLibrary oraz hosty skryptów. LoadLibrary to oczywiście ważne miejsce sprawdzania kodu wykonywalnego, lecz niestety pociąga ono za sobą pewne specjalnego ograniczenia.

Większość aplikacji posiada jeden plik wykonywalny i kilka bibliotek DLL, które są ładowane. A w każdym systemie uruchamianych jest zwykle wiele aplikacji. To oznacza, że LoadLibrary wymagałoby dokonywania wielu sprawdzeń zasady. W zależności od zasady identyfikowania kodu stosowanie wymuszania w tym punkcie wejściowym mógłby być bardzo kosztowne. Wyobraźmy sobie sprawdzanie reguły mieszania dla każdej biblioteki DLL ładowanej do systemu, co wiązałoby się z wyliczaniem wartości mieszania dla pliku, a następnie porównywaniem jej z listą nawet tysięcy wartości mieszania.

Ta funkcjonalność jest domyślnie wyłączona, ale możemy ją uaktywnić własnoręcznie. W tym celu przechodzimy do węzła Zasady ograniczeń oprogramowania (Software Restriction Policies) w konsoli gpedit.msc i dwukrotnie klikamy obiekt Wymuszanie (Enforcement). Następnie zaznaczamy opcję wyboru Wszystkie pliki oprogramowania (All software files).

Jak wspominaliśmy, zasady ograniczeń oprogramowania są zintegrowane z większością hostów skryptów w systemie, między innymi cmd, VBScript, Cscript oraz JScript®. Te punkty wejściowe podobnie jak inne wykorzystują podstawowy interfejs API wymuszania zasad ograniczeń oprogramowania: SaferIdentifyLevel.

API SaferIdentifyLevel API określa, czy dany plik wykonywalny powinien otrzymać zezwolenie na uruchomienie, wyszukując informacje identyfikujące w odpowiedniej zasadzie ograniczeń oprogramowania. Jest to publicznie udokumentowany interfejs API. Zewnętrzne hosty skryptów i środowiska uruchamiania plików wykonywalnych mogą i powinny wykorzystywać go do integrowania się z zasadami ograniczeń oprogramowania, aby zasada mogła determinować, czy uruchomienie danego elementu kodu wykonywalnego powinno być dozwolone.

 Do początku strony

Działanie w kontekście Użytkownika standardowego

Niezbyt dobrze znaną funkcją zasad ograniczeń oprogramowania jest możliwość filtrowania uprawnień określonych aplikacji, gdy są one uruchamiane. Funkcjonalność ta została wprowadzona w systemie Windows XP, ale została udostępniona w interfejsie użytkownika zasad ograniczeń oprogramowania dopiero w systemie Windows Vista.

W ten sposób funkcja ta stała się prekursorem funkcji UAC w systemie Windows Vista, ponieważ można było wykorzystywać ją do uruchamiania aplikacji w kontekście użytkownika standardowego, nawet jeśli użytkownik był członkiem grupy administratorów. To właśnie dzieje się, gdy tworzymy regułę i ustawiamy poziom zabezpieczeń (Security Level) na Użytkownik podstawowy (Basic User) w interfejsie użytkownika reguły dodatkowe (Additional Rules).

Zarówno możliwość filtrowania uprawnień w funkcji UAC, jak i reguły Użytkownika podstawowego w zasadach ograniczeń oprogramowania wykorzystują wewnętrzne API, które implementuje to samo zachowanie co API CreateRestrictedToken. Jednak ogólne architekturalne różnice obu technologii są bardzo znaczące. Funkcja UAC różni się od zasad ograniczeń oprogramowania pod kilkoma kluczowymi względami.

Po pierwsze, w systemie Windows Vista z włączoną funkcją UAC każda aplikacja jest domyślnie uruchamiana z początkowym tokenem zabezpieczeń podobnym do tokenu członka grupy użytkowników, nawet jeśli użytkownik pełni funkcję administratora. Ten sam efekt można osiągnąć przy użyciu zasady ograniczeń oprogramowania, jednak nie zapewnia ona możliwości uruchomienia aplikacji we właściwym dla użytkownika kontekście administratora, na przykład gdy użytkownik chce zainstalować aplikację. Zmiana w domyślnym kontekście zabezpieczeń oraz łatwość, z jaką użytkownik może uzyskać dostęp do pełnego tokenu administratora, to kluczowe zalety funkcji UAC.

Druga różnica polega na tym, że w przypadku plików wykonywalnych sam kod sygnalizuje, jakiego poziomu uprawnień potrzebuje do prawidłowego działania. Funkcja ta jest bardzo istotna, ponieważ niezależni dostawcy oprogramowania (ISV) i programiści najlepiej znają potrzeby własnego kodu. Na przykład, jeśli aplikacja panelu sterowania potrzebuje możliwości edycji, do której niezbędne są uprawnienia administratora, może określić to wymaganie w swoim manifeście. A zatem dostawca ISV może opisać uprawnienia, których potrzebuje aplikacja, zamiast godzić się narzuconym poziomem uprawnień bez możliwości jego późniejszego zmodyfikowania.

Na razie powinniśmy unikać wykorzystywania reguł Użytkownik podstawowy, chyba że naprawdę dobrze rozumiemy mechanizm ich działania. Funkcja UAC stanowi doskonałe narzędzie, które pomaga nam w wykluczeniu użytkowników pulpitu z grupy administratorów i powinniśmy poważnie rozważyć możliwość pozostawienia po prostu funkcji UAC w swoim środowisku korporacyjnym.

 Do początku strony

Aktualne zastosowania zasad ograniczeń oprogramowania

Istnieje wiele zmiennych czynników, które musimy wziąć pod uwagę, gdy stosujemy zasady ograniczeń oprogramowania. Mimo to stosowane są one częściej niż można by pomyśleć i w rzeczywistości możemy nawet nieświadomie wykorzystywać zasady ograniczeń oprogramowania. Na przykład, gdy uruchamiamy Kontrolę rodzicielską w systemie Windows Vista, używamy zasad ograniczeń oprogramowania do kontrolowania wykonania aplikacji.

Zasady ograniczeń oprogramowania stanowiły ważny rozwój technologiczny, gdy zostały wprowadzone po raz pierwszy w systemie Windows XP. Jednak kwestia blokowania aplikacji tak naprawdę dopiero teraz zaczęła przyciągać uwagę profesjonalistów IT.

Funkcja Zasady ograniczeń oprogramowania w systemie Windows Vista posiada pewne niedociągnięcia, które wymagają dopracowania, ale administratorzy ewidentnie chcą posiadać większą kontrolę nad tym, co jest uruchamiane w ich środowiskach. Na szczęście dla nas wszystkich technologia ta będzie nadal ewoluowała i ułatwiała profesjonalistom IT zarządzanie systemami oraz obniżała koszt utrzymywania środowiska Microsoft Windows.

 Do początku strony

Zawężająca zasada ograniczania oprogramowania

Jedno z zastosowań zasady ograniczeń oprogramowania polega na stworzeniu zasady, która blokuje system Windows w trybie kiosku. Firma Microsoft stworzyła wprawdzie zestaw narzędzi o nazwie SteadyState™ służący do tworzenia tego kiosku. Jednak jeśli interesuje nas jedynie możliwość blokowania aplikacji, które mogą być uruchamiane, możemy osiągnąć ten cel w łatwiejszy sposób.

Aby zezwolić na minimalny zestaw aplikacji koniecznych do zalogowania się do systemu Windows Vista, należy stworzyć zasadę, która umożliwia uruchamianie plików logonui.exe oraz userinit.exe z katalogu %windir%\system32. Większość użytkowników prawdopodobnie będzie również potrzebowała zezwolenia na uruchamianie następujących aplikacji:

dllhost.exe, rundll32.exe, control.exe (także w %windir%\system32)....

Jeśli potrzebujemy domyślnej powłoki systemu Windows, powinniśmy dodać także windir%\explorer.exe.

Możemy również zdecydować się na rozruch prosto do aplikacji, takiej jak Internet Explorer®. W tym przypadku musimy umieścić na liście iexplore.exe zamiast explorer.exe.

Innym aspektem tej zasady zawężającej jest to, że użytkownicy nie powinni należeć do grupy administratorów. Dzięki temu nie będą oni mieli możliwości ominięcia zasady. Jednak ponieważ użytkownicy mogą uruchamiać jedynie bardzo podstawowy zestaw aplikacji i nie posiadają uprawnień administratora, nie będą mieli prawa do instalowania aplikacji i utrzymywania systemu.

Będziemy potrzebowali jakiegoś sposobu realizowania wspomnianych zadań dla tych maszyn. Jeśli planujemy aktualizować i utrzymywać maszyny, logując się lokalnie przy użyciu konta administratora, powinniśmy zaznaczyć pole wyboru, które powoduje zastosowanie zasad ograniczeń oprogramowania dla wszystkich użytkowników poza administratorami lokalnymi. Zasada powinna także obejmować pliki consent.exe oraz cmd.exe. To umożliwi administratorowi uruchamianie dowolnych opcji administracyjnych z wiersza polecenia.

Warto zauważyć, że funkcja UAC domyślnie ogranicza uprawnienia tokenu zabezpieczeń użytkownika, sprawiając wrażenie, że nie jest on członkiem grupy Administratorzy. Nawet jeśli skonfigurujemy powyższe ustawienie tak, aby zasada nie była stosowana dla administratorów, nadal będzie się ona odnosiła do użytkowników. Dopiero po przejściu przez proces podnoszenia uprawnień w funkcji UAC, Administrator faktycznie otrzyma pełne uprawnienia administratora i zasada ograniczeń oprogramowania nie będzie stosowana.

A autorach

Chris Corio przez ponad pięć lat był członkiem zespołu Windows Security w firmie Microsoft. Specjalizuje się w technologiach zabezpieczania aplikacji oraz zarządzania, które służą do ochrony systemu Windows. Można skontaktować się z nim za pośrednictwem adresu winsecurity@chriscorio.com.

Durga Prasad Sayana pełni funkcję Software Design Engineer/Test w zespole Windows Core Security. Interesuje się głównie technologiami zabezpieczeń i testowaniem oprogramowania. Można skontaktować się z nim za pośrednictwem adresu durgas@microsoft.com.

Do początku strony

---