Windows 7

Wprowadzenie do bezpieczeństwa w Windows 7

Opublikowano: 24 lipca 2009

Zawartość strony
 Windows Biometric Framework  Windows Biometric Framework
 Rozszerzenie protokołów uwierzytelniania  Rozszerzenie protokołów uwierzytelniania
 Podstawowe rozszerzenia funkcji BitLocker  Podstawowe rozszerzenia funkcji BitLocker
 BitLocker To Go  BitLocker To Go
 Ulepszenia UAC  Ulepszenia UAC
 AppLocker  AppLocker
 Zatwierdzenie DNSSec  Zatwierdzenie DNSSec
 Globalne SACL i szczegółowa inspekcja  Globalne SACL i szczegółowa inspekcja
 Podsumowanie  Podsumowanie

 

W system Windows Vista wprowadzono wiele nowych technologii bezpieczeństwa, które miały znaczący wpływ na ekosystem Windows. Funkcja User Account Control (Kontrola konta użytkownika) jasno pokazała, że Microsoft chciał ułatwić uruchamianie systemu Windows użytkownikom nienależącym do grupy Administratorzy. BitLocker wprowadził pełne szyfrowanie woluminu dla klienta Windows, a Internet Explorer w trybie chronionym pomagał w bezpieczniejszym przeglądaniu Internetu.

W systemie Windows 7 Microsoft nadal inwestuje w zabezpieczenia, dodając nowe technologie, a także rozszerzając wiele technologii wprowadzonych w Windows Vista. W tym artykule podaję przegląd nowych funkcji bezpieczeństwa i rozszerzeń, które można znaleźć w Windows 7.

Windows Biometric Framework

Windows Vista zawierał przeprojektowanie działania Winlogon. Usunięto infrastrukturę GINA (Graphical Identification and Authentication) i dodano model rozszerzenia Credential Provider (Dostawca poświadczeń). Infrastruktura Credential Provider stanowiła zbiór interfejsów pozwalających na zachowanie spójności, gdy inne firmy rozszerzały zadania użytkownika na użytkowników podających poświadczenia i jest zintegrowana z typowym oknem dialogowym poświadczeń w systemie Windows.

W Windows 7 Microsoft dodał nowe narzędzie, Windows Biometric Framework (WBF). Wraz z rosnącą popularnością czytników odcisków palców, stało się jasne, że zdefiniowanie wspólnej struktury dla prezentacji, zarządzania i wykorzystania tych technologii jest konieczne w celu popchnięcia do przodu rozwoju i niezawodności. WBF ma na celu ułatwienie obsługi urządzeń biometrycznego uwierzytelniania. W Windows 7 WBF obsługuje tylko czytniki odcisków palców, ale w przyszłości może być rozszerzone.

Podstawowa platforma WBF składa się z następujących głównych komponentów:

• Windows Biometric Driver Interface (WBDI)

• Windows Biometric Service (WBS)

• WBF API

• WBF User Experience and Integration Points

• WBF Management

Windows Biometric Driver Interface (WBDI) ma stanowić interfejs wspólnego sterownika dla urządzeń biometrycznych. Składa się z różnych interfejsów, które prezentują odpowiednie struktury danych i kontrolki wejścia/wyjścia IOCTL (Input/output controls) pozwalające zintegrować urządzenia biometryczne ze strukturą biometryczną. Sterowniki można zaimplementować w dowolnej popularnej strukturze sterowników, w tym w modelu Windows Driver Model, w trybie jądra Kernel Mode Driver Framework oraz w trybie użytkownika User-Mode Driver Framework (UMDF). UMDF jest jednak zalecaną strukturą sterowników dla urządzeń biometrycznych, gdyż zapewnia dodatkowe korzyści w postaci większej niezawodności w systemie Windows w przypadku awarii sterownika urządzenia biometrycznego.

Windows Biometric Service (WBS) jest kluczowym komponentem łączącym WBF w całość. WBS jest sprzężony ze sterownikami urządzeń biometrycznych oraz prezentuje API Windows Biometric Framework, pozwalając aplikacjom komunikować się z tymi urządzeniami.

Ważną funkcją WBS jest fakt, że nigdy nie ujawnia danych biometrycznych użytkownika nieuprawnionym aplikacjom. Jest to ważne, gdyż w przeciwieństwie do haseł bardzo trudno zmienić czyjś podpis biometryczny po jego ujawnieniu. Zamiast tego WBS podaje uchwyt (zwykle GUID lub SID), który pozwala aplikacji na pracę z danymi biometrycznymi w sposób pośredni.

WBS zarządza także pulami urządzeń uwierzytelniania biometrycznego. Pozwala to na kontrolę sposobu, w jaki urządzenia biometryczne są używane. Określone urządzenia mogą być używane z dowolną wersją okna dialogowego poświadczeń (Credential Dialog), jak zgłoszenie logowania lub zgłoszenie UAC. Można na przykład ustawić w domowym systemie kontrolę rodzicielską (Parental Controls) i, gdy potrzebne jest podniesienie uprawnień, można przejechać palcem, aby je zapewnić. Ta pula urządzeń biometrycznych określana jest jako pula systemowa (System). Istnieją jeszcze dwie pule urządzeń. Jest pula prywatna (Private), która pozwala aplikacjom na oferowanie uwierzytelnienia, które nie jest zintegrowane z infrastrukturą uwierzytelniania Windows. Jest też pula nieprzypisana (Unassigned) dotycząca urządzeń, które, jak się można domyśleć, nie pasują do żadnej z dwóch pozostałych pul.

Każde urządzenie stanowiące część puli urządzeń jest oddzielane przez WBS za pomocą klasy danych określanej jako Biometric Unit (Jednostka biometryczna). Jednostkę biometryczną podłącza się do dostawcy WBS, Biometric Service Provider (BSP), który implementuje zasady i zachowania specyficzne dla zbioru urządzeń biometrycznych. Dzięki Biometric Unit BSP może zapewnić możliwości, które nie są obsługiwane przez konkretne urządzenie, takie jak przechowywanie danych o odciskach palców lub przetwarzanie danych odcisków palców po ich pobraniu przez urządzenia.

Trzeci główny komponent WBF to zbiór interfejsów API, znany jako WinBio* API, który może być używany przez aplikacje i komponenty trybu użytkownika do bezpośredniej interakcji z urządzeniami. Obejmuje to interakcję podczas oryginalnego procesu rejestrowania w celu uzyskania odcisku palca użytkownika i skorelowania go z kontem tego użytkownika, a także zadanie weryfikacji użytkownika w celu logowania lub kontroli konta. Te API podają także dane dotyczące określonego urządzenia biometrycznego i jego charakterystyki. Ponadto API WBF można rozszerzyć tak, aby pozwalały aplikacji na interakcję z firmowymi aspektami danego urządzenia.

WBF pokazuje dwie główne metody skonfigurowania sposobu korzystania z urządzeń biometrycznych. Dla użytkowników końcowych mamy aplet Control Panel (Panel sterowania), który jest dostępny w kilku lokalizacjach. Panel sterowania urządzeniami biometrycznymi (Biometric Devices Control Panel) można znaleźć w części Hardware and Sound (Sprzęt i dźwięk). Z tej lokalizacji użytkownik może uruchomić aplikację zarządzania odciskami palców innego producenta. Windows 7 nie zapewnia wbudowanej aplikacji zarządzania odciskami palców, więc każdy inny sprzedawca lub dostawca OEM będzie musiał napisać ją sam. (Zwróćmy uwagę, że Windows Biometric Framework obsługuje logowanie lokalne i domeny, a także UAC oparte na odciskach palców, za pośrednictwem dostawcy Biometrics Credential Provider).

Struktura Windows Biometric Framework może też być zarządzana za pośrednictwem Zasad grupy. Administrator może włączyć lub wyłączyć całą strukturę, a także zarządzać typami logowania, jakie mogą być używane w biometrii (na przykład loginy lokalne i domeny mogą być różnie skonfigurowane).

 Do początku strony

Rozszerzenie protokołów uwierzytelniania

Windows 7 rozszerza możliwości wersji domowej systemu i małych sieci o funkcję o nazwie Homegroup. Użytkownicy mogą współdzielić dane, takie jak pliki medialne, między komputerami w domu i korzystać z ID online w celu uwierzytelnienia się między komputerami. Aby ta funkcja działała, użytkownicy muszą jawnie połączyć swoje konto użytkownika Windows z ID online. Uwierzytelnienie jest włączane przez nowy, oparty na kluczu publicznym protokół o nazwie PKU2U (Public Key-based User to User).

Windows 7 wprowadza także rozszerzenia do pakietu negocjowania uwierzytelnień, Spnego.dll. SpNego jest funkcją, która decyduje, który protokół uwierzytelniania będzie wykorzystywany. Przed Windows 7 był to zwykle wybór pomiędzy protokołem Kerberos i NTLM (Windows Challenge/Response). Rozszerzenie NegoEx jest traktowane przez Windows jak protokół uwierzytelniania i obsługuje dwóch dostawców obsługi zabezpieczeń firmy Microsoft: PKU2U i Live. Jest także rozszerzalny, co pozwala na projektowanie innych dostawców obsługi zabezpieczeń.

Obie te funkcje działają podczas łączenia się z innym komputerem w grupie domowej (Homegroup) za pomocą ID online. Gdy jedna maszyna łączy się z drugą, rozszerzenie negocjacyjne wywołuje dostawcę obsługi zabezpieczeń PKU2U na komputerze logowania. Dostawca obsługi zabezpieczeń PKU2U otrzymuje certyfikat z mechanizmu zasad urzędu certyfikacji i wymienia zasady (razem z innymi metadanymi) między komputerami równorzędnymi. Po zatwierdzeniu na równorzędnie podłączonym komputerze, certyfikat jest wysyłany do strony logowania w celu zatwierdzenia, certyfikat użytkownika jest odwzorowywany na token zabezpieczeń i proces logowania zostaje zakończony.

  Do początku strony

Podstawowe rozszerzenia funkcji BitLocker

W systemie Windows Vista Microsoft wprowadził funkcję BitLocker. Jest to szyfrowanie całego woluminu przeznaczone do ochrony danych na laptopach i komputerach biurkowych, takich jak serwery w oddziałach, nawet wtedy, gdy komputer zostanie zgubiony lub wpadnie w nieodpowiednie ręce. W Windows 7 dokonano wielu rozszerzeń zarządzania funkcją BitLocker. Obejmują one spójne wprowadzenie we wszystkich interfejsach (interfejs użytkownika, narzędzie wiersza poleceń manage-bde oraz dostawca WMI) i oddzielne ustawienia Zasad grupy dla ustalonych stacji dysków z danymi. Są też nowe ustawienia Zasad grupy, pozwalające na aktualizację swoich haseł i integrację ze Smart Cards na stacjach spoza systemu operacyjnego; można także zmieniać działanie związane z automatycznym odblokowywaniem.

Użytkownicy systemu Windows Vista narzekali na trudności z podziałem systemowej stacji dysków na partycje w celu przygotowania instalacji BitLocker – zwłaszcza gdy system operacyjny był już zainstalowany. Problem został rozwiązany za pomocą dwóch rozszerzeń dostępnych w Windows 7. Pierwsze jest domyślne podczas instalowania Windows 7, a użytkownicy otrzymują oddzielną aktywną partycję systemową, której wymaga BitLocker, aby współpracować z napędami systemu operacyjnego. Eliminuje to drugi krok, który był wymagany w wielu środowiskach. Ponadto można podzielić napęd na partycje na potrzeby BitLocker jako element instalacji BitLocker, jeśli nie mamy jeszcze oddzielnej partycji systemowej (patrz rysunek 1).

Rysunek 1: Przygotowanie napędu na potrzeby BitLocker.

  Do początku strony

BitLocker To Go

Jednym z najbardziej widocznych i najważniejszych dodatków jest BitLocker To Go, przeznaczony do ochrony danych na wymiennych stacjach dysków. Pozwala na skonfigurowanie szyfrowania BitLocker Drive Encryption dla pamięci flash USB i na zewnętrznych dyskach twardych. Cele projektu BitLocker To Go dotyczyły funkcji łatwej w użyciu, pracującej na stacjach zewnętrznych, pozwalającej w razie potrzeby na odzyskanie danych oraz umożliwiającej wykorzystanie danych w systemach Windows Vista i Windows XP.

Jest wiele rozszerzeń związanych z zarządzaniem dla menedżerów IT, z których mogą skorzystać wraz z tą funkcją. Najważniejszym jest nowe ustawienie Zasad grupy, które pozwala na skonfigurowanie napędów wymiennych jako napędów tylko do odczytu (Read Only), o ile nie są one zaszyfrowane za pomocą BitLocker To Go. Jest to idealny krok w kierunku zapewnienia ochrony ważnych danych korporacyjnych w sytuacji, gdy pamięć flash USB zostanie źle użyta przez pracownika.

Warta uwagi jest też możliwość odzyskiwania danych z urządzenia BitLocker To Go, gdy dane są niedostępne. Technologia ta, określana jako Data Recovery Agent (Agent odzyskiwania danych), została przeniesiona z funkcji Encrypted File System (EFS) i pozwala na łatwe odzyskiwanie danych korporacyjnych na napędach przenośnych, za pomocą klucza utworzonego w przedsiębiorstwie.

Aby funkcja BitLocker To Go działała w systemach Windows XP i Windows Vista, wymagało nieco przekształceń podstawowych możliwości BitLocker. W tym celu zespół przebudował sposób, w jaki BitLocker chroni woluminy FAT. Zachowanie BitLocker zostało zmienione tak, aby zasłonić "wolumin odnajdowania” przez oryginalny wolumin fizyczny i wirtualizować nadpisywane bloki. Wolumin wyszukiwania zawiera czytnik BitLocker To Go Reader, jak również plik readme. Nosi to nazwę napędu hybrydowego Hybrid BitLocker. Domyślnie, podczas szyfrowania napędu FAT, tworzony jest hybrydowy napęd BitLocker. Napęd wyszukiwania jest widoczny tylko w systemach operacyjnych Windows XP i Windows Vista.

Czytnik będzie także dostępny w ośrodku pobierania plików firmy Microsoft po wypuszczeniu na rynek Windows 7. Aplikacja zapewnia dostęp tylko do odczytu dla napędów BitLocker, które wykorzystują ochronę klucza hasła. Zauważmy, że uwierzytelnianie za pomocą smart card nie jest dostępne, gdy korzystamy z czytnika BitLocker To Go Reader.

  Do początku strony

Ulepszenia UAC

Kontrola konta użytkownika (User Account Control, UAC) to technologia często źle rozumiana. Na pierwszy rzut oka jest to zestaw funkcji, a nie tylko zgłoszenie systemu. Funkcje te obejmują przekierowywanie plików i rejestrów (File and Registry Redirection), Wykrywanie instalatora (Installer Detection), zgłoszenie UAC, usługę ActiveX Installer Service i jeszcze więcej. Funkcje te zostały zaprojektowane, aby pozwolić użytkownikom Windows działać na kontach, które nie należą do grupy Administratorzy. Konta te określa się zwykle jako użytkowników standardowych (Standard Users) i są one ogólnie opisywane jako działające z minimalnymi przywilejami. Kluczową sprawą jest fakt, że użytkownicy działający z kont standardowych działają bardziej bezpiecznie i niezawodnie.

Celem wielu projektantów oprogramowania było tworzenie aplikacji, które dobrze funkcjonują na poziomie użytkowników standardowych. Firmy mają teraz wyraźniejszą ścieżkę wdrażania kont standardowego użytkownika, co pozwala obniżyć koszty obsługi i ogólne koszty posiadania (TCO, total cost of ownership) swoich komputerów. W domu rodziny używają kont użytkownika standardowego dla dzieci, co wraz z kontrolą rodzicielską (Parental Controls) pozwala utworzyć bezpieczniejsze środowisko.

Windows 7 obejmuje szereg rozszerzeń poprawiających korzystanie z opcji standardowego użytkownika oraz nowe ustawienia konfiguracyjne zapewniające większą kontrolę nad zgłoszeniem UAC, podczas pracy w trybie zatwierdzania przez administratora (Administrator Approval Mode). Celem jest poprawa użyteczności, przy jednoczesnym jasnym przesłaniu do producentów oprogramowania, że domyślnym kontekstem zabezpieczeń jest standardowy użytkownik i w tym kierunku trzeba kierować swoje prace. W praktyce wprowadzone zmiany oznaczają, że w Windows 7 użytkownicy nie dostają zgłoszeń przy wykonaniu ogólnych zadań administracyjnych. Jest to ustawienie mówiące: „Powiadamiaj mnie tylko wtedy, gdy program chce dokonać zmiany w moim komputerze”.

Sposób działania jest prosty. Podczas tworzenia procesu sprawdzane są zasady, aby zobaczyć, czy to ustawienie jest włączone. Jeśli tworzony proces jest częścią systemu Windows, weryfikowaną przez sprawdzenie podpisu w plikach katalogu Windows, proces zostaje utworzony bez żadnego zgłoszenia. Ustawienie to nie powoduje zgłoszenia, gdy zmieniamy ustawienie Windows, lecz zamiast tego pozwala skupić się na zmianach administracyjnych żądanych przez aplikacje spoza systemu Windows (jak instalacja nowego oprogramowania). Dla osób, które chcą mieć większą kontrolę, gdyż często zmieniają ustawienia systemu Windows bez dodatkowych powiadomień, ustawienie to skutkuje mniejszą liczbą zgłoszeń systemu i pozwala użytkownikom skupić się na pozostałych kluczowych powiadomieniach, które się pojawiają.

Inną znaczącą zmianą jest fakt, że kilka komponentów już nie wymaga uprawnień Administratora. Na przykład użytkownicy mogą skonfigurować, czy ich komputery biurkowe będą wyświetlać wyniki w trybie High DPI, co jest często stosowane w czasach, gdy rozmiar ekranów komputerowych powiększa się, a wielkość pikseli się zmniejsza. Innym przykładem jest możliwość resetowania połączenia sieciowego przez standardowych użytkowników, pod warunkiem, że są fizycznie zalogowani na danym komputerze. Jest to dość częste życzenie wyrażane pod adresem firmy Microsoft przez użytkowników domowych i korporacyjnych.

Rysunek 2: Kontrola konta użytkownika podczas instalacji Kontrolki ActiveX.

Rysunek 2 Kontrola konta użytkownika podczas instalacji Kontrolki ActiveX

Zmniejszenie liczby zgłoszeń oznacza także większą płynność w obszarach, gdzie jedno działanie użytkownika wywoływało wiele zgłoszeń. Na przykład w Windows 7 instalacja kontrolek ActiveX w Internet Explorer jest znacznie bardziej płynna. W Windows Vista Internet Explorer 7 tworzył proces IEInstal.exe, który wykonywał instalację kontrolki ActiveX. Dawało to w wyniku zgłoszenie UAC z pytaniem, czy chcemy „Instalować dodatki IE”, aby pracować z przywilejami administracyjnymi. Zgłoszenie to nie niosło informacji o tym, co dokładnie ma być zainstalowane, zaś Internet Explorer natychmiast pytał nas, czy akceptujemy określoną kontrolkę. W systemie Windows 7 z Internet Explorer 8 proces instalacji został tak zmodyfikowany, że korzysta z usługi ActiveX Installer Service, która wyodrębnia informacje publikowane na temat kontrolki ActiveX i wyświetla je podczas prowadzenia instalacji (patrz rysunek 2). Nowe podejście usuwa też drugie zgłoszenie podczas instalacji kontrolki ActiveX.

  Do początku strony

AppLocker

Możliwość kontroli aplikacji, które mogą być uruchamiane przez użytkownika lub zbiór użytkowników, znacznie zwiększa niezawodność i bezpieczeństwo komputerów biurkowych w przedsiębiorstwie. Ogólnie zasady blokowania aplikacji mogą zmniejszyć koszt TCO komputerów w przedsiębiorstwie. W Windows 7 dodano AppLocker, nową funkcję, która kontroluje wykonywanie aplikacji i ułatwia budowanie firmowych zasad blokowania aplikacji.

Razem z Durga Prasad Sayana omawiałem zasady blokowania aplikacji w zeszłorocznym wydaniu dotyczącym bezpieczeństwa, w artykule zatytułowanym „ Application Lockdown with Software Restriction Policies ” (Blokowanie aplikacji według zasad ograniczania oprogramowania). W artykule podaliśmy szczegółowo wyzwania, które firma musi przezwyciężyć, tworząc takie zasady. Niektóre z tych wyzwań obejmują:

• Zrozumienie, jakie oprogramowanie jest używane w danym środowisku

• Wiedza, jacy użytkownicy powinni mieć prawo uruchamiać dane aplikacje

• Wiedza, jak opracować niezbędne zasady

• Ustalenie, czy zasady będą po wdrożeniu działać poprawnie

Odpowiadając na te problemy, AppLocker oferuje nowe podejście, które umożliwia inspekcję sposobu, w jak będą działać zasady blokowania aplikacji. Zapewnia możliwość kontroli metody uruchamiania przez użytkowników wszystkich typów aplikacji – wykonywalnych, skryptów, plików instalatora Windows i DLL. Oferuje ponadto nowe, elementarne zasady blokowania aplikacji, które są bardziej szczegółowe i nie jest tak łatwo je złamać podczas aktualizowania aplikacji. Windows 7 zawiera także obsługę starych reguł Software Restriction Policy (SRP), ale nie ma obsługi nowych reguł AppLocker w systemach Windows XP i Windows Vista.

Tryby wprowadzania w życie są implementowane w ramach agenta wymuszania zasad w AppLocker, który jest implementowany w sterowniku appid.sys. Sterownik ten oferuje możliwość wprowadzenia sprawdzania zasad w trybie jądra dla takich zdarzeń, jak tworzenie procesów i ładowanie DLL. Dla aplikacji, które implementują to w trybie użytkownika (User Mode), stosowany jest stary API SaferIdentifyLevel w celu określenia, czy aplikacja może być uruchomiona. Jednak Safer-IdentifyLevel będzie teraz przekazywał sprawdzenie zabezpieczeń do usługi wykonującej samą weryfikację binariów i zasad. Jest to znaczące rozszerzenie architektury w porównaniu z poprzednią funkcją Software Restriction Policies.

AppLocker ma ułatwić pracę specjalistów IT przy tworzeniu zbioru zasad wyrażających wszystkie aplikacje dozwolone do uruchamiania i do zapewnienia odporności tych zasad wobec aktualizacji aplikacji.

Do opracowania zasad AppLocker służy nowa przystawka UX AppLocker MMC w przystawce UX Edytora obiektów zasad grupy (Group Policy Object Editor), która oferuje niezwykłą poprawę w procesie tworzenia reguł AppLocker. Jest też kreator pozwalający na utworzenie jednej reguły i drugi, automatycznie generujący reguły na podstawie własnych preferencji i wybranego folderu (patrz rysunek 3).

Rysunek 3: Automatyczne generowanie reguł dla zasad AppLocker.

Można sprawdzić analizowane pliki i usunąć je z listy, zanim zostaną dla nich utworzone reguły. Można nawet otrzymać pożyteczne statystyki zawierające informacje, jak często plik był blokowany, lub przetestować zasady AppLocker dla danego komputera.

W poprzednich zasadach Software Restriction Policies szczególnie trudno było tworzyć zasady, które byłyby bezpieczne i jednocześnie nie wyłamywały się z aktualizacji oprogramowania. Wynikało to z braku szczegółowości reguł certyfikatów i nietrwałości reguł skrótu, które były łamane podczas aktualizacji binarnej wersji aplikacji. Aby rozwiązać ten problem, AppLocker pozwala opracować reguły łączące certyfikat z nazwą produktu, nazwą pliku i wersją pliku. Ułatwia to stwierdzenie, że to, co jest podpisane przez danego sprzedawcę dla produktu o określonej nazwie, może być uruchamiane.

Zasady AppLocker w systemie Windows 7 mają także inne zalety, łącznie z rozdzieleniem różnych typów wykonania (mianowicie plików EXE, DLL oraz hostów skryptów MSI). Te typy plików są umieszczone w czterech porcjach nazwanych kolekcjami reguł, a wymuszenie jest skonfigurowane dla każdego z nich osobno. Na przykład administratorzy mogą włączyć sprawdzanie AppLocker dla plików wykonywalnych bez włączenia sprawdzania plików skryptów.

Zasady AppLocker są zapisane w kluczu HKLM\Software\Policies\Microsoft\Windows\SrpV2. Są one zapisane w formacie XML i tłumaczone przez usługę Application Identity (AppID). Gdy zasady są przetwarzane, sterownik appid.sys jest powiadamiany o nowych zasadach usługi przez IOCTL_SRP_POLICY i dokonuje ich przeładowania.

Pierwszym zadaniem przy podejściu do zmian w danym środowisku IT jest ocena sposobu jego funkcjonowania w bieżącej chwili. Wtedy można uważnie zaplanować i przetestować zmiany, aby wprowadzić je bez problemów. Jest to celem wprowadzenia trybu samej inspekcji (Audit only).

Inspekcja wprowadzania zasad App-Locker jest niezwykle ważna. Nie tylko pozwala na testowanie zasad przed ich wprowadzeniem, lecz oferuje także możliwość obserwowania sposobu działania zasad w czasie pracy. Zdecydowanie warto wiedzieć, czy określony zbiór użytkowników wymaga, aby aplikacja pracowała w określonej chwili. Można to stwierdzić, łącząc się z systemem i przeglądając informacje inspekcji AppLocker, aby zobaczyć, czy zasada blokowania aplikacji uniemożliwia działanie określonej aplikacji.

Podstawowy kanał dla zdarzeń AppLocker znajduje się w Dzienniku aplikacji (Application Log) i Dzienniku usług (Service Log), które można oglądać w Przeglądarce zdarzeń (Event Viewer, eventvwr.msc). Aby oglądać te pozycje dziennika, trzeba poszukać dzienników EXE i DLL i MSI i Script w kanale zdarzeń Microsoft\Windows\AppLocker\. Może być wygenerowanych wiele różnych zdarzeń, łącznie z tym, czy aplikacja została dopuszczona, czy zablokowana oraz czy zasady zostały zastosowane w systemie.

  Do początku strony

Zatwierdzenie DNSSec

W ciągu kilku ostatnich lat eksploity związane z DNS stały się powszechnym problemem w Internecie. Coraz lepsza jest wiedza na temat sposobów zatruwania serwerów DNS, zaś napastnicy zaczynają wykorzystywać te informacje. Oznacza to, że użytkownik może potencjalnie odwiedzić witrynę Web, nie mając całkowitej pewności, czy nie znajduje się na innej, szkodliwej witrynie. Windows Server 2008 R2 i Windows 7 wprowadzają obsługę DNSSEC zgodnie z bieżącymi standardami (RFC 4033, RFC 4034 oraz RFC 4035). Windows Server 2008 R2 pozwala na udostępnianie przez serwer DNS artefakty źródła pochodzenia oraz integralności danych. W zasadzie serwer będzie mógł dołączać podpisy cyfrowe do danych DNS w odpowiedziach, a także zatwierdzać dane otrzymane z innych serwerów DNS.

Windows 7 jest pierwszym klienckim systemem operacyjnym, który zawiera potrzebne elementy pozwalające klientowi na zweryfikowanie bezpieczeństwa połączenia z serwerem DNS i sprawdzenie, czy serwer wykonał w jego imieniu zatwierdzenie DNSSEC. Technologia ta jest teraz testowana, aby zapewnić jej maksymalną zgodność z bieżącą infrastrukturą Internetu i aby w przyszłości odgrywała stałą rolę w zabezpieczeniu danych DNS.

  Do początku strony

Globalne SACL i szczegółowa inspekcja

W Windows 7 rozszerzono wcześniejsze mechanizmy inspekcji oferując nowe funkcje, które umożliwiają zarządzanie inspekcją dla użytkowników, a nie tylko obiektów, oraz zapewniając więcej informacji na temat niepowodzeń AccessCheck dla obiektów plików. Włącza to nowe scenariusze inspekcji i zapewnia znaczącą zmianę paradygmatu związanego z inspekcją.

W innych wersjach systemu Windows decyzję, czy dokonać inspekcji obiektu, opierano na tym, czy deskryptor zabezpieczeń obiektu zawarty we wpisie kontroli dostępu (access control entry, ACE) na jego liście SACL określa, że obiekt ma być poddany inspekcji. Dzięki temu monitorowanie określonego klucza rejestru lub pliku było łatwe i można było sprawdzić, jaki dostęp ma miejsce do obiektu. Niestety nie było sposobu zobaczenia, jaki użytkownik miał do niego dostęp. W tym scenariuszu trzeba było zapewne włączyć inspekcję dla każdego zasobu, z którym użytkownik mógł teoretycznie mieć interakcję, co powodowało, że każdy dostęp każdego użytkownika do zasobu był zapisywany w dzienniku inspekcji.

Włączenie inspekcji na dostatecznie szerokim zbiorze danych, aby przechwycić, do czego użytkownik mógł mieć dostęp, było procesem niezwykle uciążliwym. Każdy zasób musi być aktualizowany, aby dołączyć zasady inspekcji w ramach SACL, zaś każda zmiana tych zasad wymaga aktualizacji każdej z list SACL. Dla przezwyciężenia tego ograniczenia w Windows 7 wprowadzono funkcję Global Object Access Auditing (Globalna inspekcja dostępu do obiektu), która jest zarządzana przez auditpol.exe i można ją skonfigurować za pomocą Zasad grupy.

Inspekcja Global Object Access Auditing obejmuje „Global SACL”, czyli łańcuch SDDL zapisany w rejestrze wraz z innymi danymi związanymi z inspekcją. Zostały dodane dwa nowe API do zarządzania globalną listą SACL: AuditSetGlobalSacl i AuditQueryGlobalSacl. Aktualizacja globalnej listy SACL wymaga SeSecurityPrivilege, która chroni globalną listę SACL przed aktualizacją przez użytkownika bez uprawnień administracyjnych.

Dzięki inspekcji zabezpieczeń w Windows 7 można także zrozumieć, dlaczego dostęp do obiektu powiódł się lub nie. Jest to ważna informacja, jeśli szukamy błędów w aplikacji lub też próbujemy zrozumieć, czy nasze zasady zabezpieczeń są efektywne. Zarówno funkcja Global Object Access Auditing, jak i dodanie dodatkowych danych inspekcji na temat dostępu, są zaimplementowane w nowym API zabezpieczeń trybu jądra, SeAccessCheckEx. Dwa menedżery zasobów, które wykorzystują ten API, to NTFS oraz Detailed File Share w Windows 7. Gdy są one włączone, API będzie zapisywał w dzienniku inspekcji informacje o tym, dlaczego próba dostępu powiodła się lub nie. Funkcje te mają więc teraz zastosowanie do systemu plików oraz do udziałów plików i mogą zostać rozszerzone na inne menedżery zasobów w kolejnych wersjach systemu Windows.

  Do początku strony

Podsumowanie

W Windows 7 dostępne są nowe scenariusze, co sprawia, że system Windows jest znacznie bezpieczniejszy. Wiele z tych funkcji skupia się na działaniu użytkownika (dla użytkowników domowych, biznesowych oraz specjalistów IT) pozwalając, aby systemy Windows działały jeszcze lepiej.

O autorze

Chris Corio jest od ponad pięciu lat członkiem zespołu zabezpieczeń w firmie Microsoft. Jego głównym zainteresowaniem są techniki zabezpieczania aplikacji oraz technik zarządzania przy zabezpieczaniu systemu Windows. Można się z nim skontaktować pod adresem winsecurity@chriscorio.com.

  Do początku strony

Windows 7