Inspekcja i zgodność w systemie Windows Server 2008

Opublikowano: 1 sierpnia 2008

Zawartość strony

	Problemy stwarzane przez inspekcję
	Prowadzenie inspekcji zdarzeń związanych z zabezpieczeniami
	Opracowywanie planu inspekcji

W świecie informatyki ciągłe zmiany są czymś naturalnym. Jeśli Twój dział IT jest taki jak większość innych, to znajdujesz się pod stale rosnącą presją pozostawania na bieżąco ze zmianami zachodzącymi w Twoim środowisku. W miarę wzrostu stopnia złożoności oraz skali środowisk IT zwiększa się również znaczenie błędów administracyjnych oraz niezamierzonego ujawniania danych. Współczesne społeczeństwo oczekuje odpowiedzialności za tego typu zdarzenia, więc obecnie organizacje podlegają prawnej odpowiedzialności za ochronę powierzonych im informacji.

Rezultatem tej sytuacji jest wzrost znaczenia ewidencjonowania zmian zachodzących w danym środowisku. Dlaczego? Prowadzenie ewidencji dostarcza odpowiednich środków pozwalających na zrozumienie i zarządzanie zmianami zachodzącymi we współczesnych, rozległych i w dużym stopniu rozproszonych, środowiskach IT. W tym artykule omówione zostaną: typowe problemy, z jakimi boryka się większość organizacji, przegląd zagadnień związanych ze zgodnością oraz z regulacjami obowiązującymi w branży IT, pewne podstawy dotyczące prowadzenia inspekcji w systemie Windows®,a także sposób, w jaki funkcjonalność systemu Windows Server® 2008 oraz usługi Audit Collection Services (ACS), stanowiącej cześć oprogramowania Microsoft® System Center Operations Manager 2007, może uzupełniać rozbudowaną strategię ewidencjonowania zmian.

Problemy stwarzane przez inspekcję

Już pobieżny rzut okiem na skróty najważniejszych wiadomości pokazuje, że ujawnianie danych staje się codziennym problemem. Wiele z tego typu incydentów wiąże się z określonymi działaniami prawnymi, stratami finansowymi oraz problemami związanymi z publicznym wizerunkiem odpowiedzialnych za nie organizacji. Możliwość wyjaśnienia, jakie zmiany miały miejsce, lub szybkiego zidentyfikowania danego problemu stanowi kluczowy czynnik pozwalający na zminimalizowanie negatywnych skutków przypadków ujawnienia danych.

Przypuśćmy np., że Twoja organizacja jest odpowiedzialna za zarządzanie informacjami osobistymi (PII - Personally Identifiable Information) przechowywanymi w bazie danych jednego ze swoich klientów. Pomimo istnienia wielu sposobów ochrony informacji znajdujących się w zarządzanych przez Ciebie systemach, nadal może dojść do ich kompromitacji. Prawidłowe prowadzenie inspekcji pozwoli organizacji dokładnie wskazać skompromitowane systemy, a prawdopodobnie określić również, jakie dane zostały utracone. Bez odpowiedniej inspekcji skutki utraty danych mogłyby być znacznie poważniejsze, głównie z powodu braku możliwości oceny rozmiarów kompromitacji.

Dlaczego więc działy IT tego nie robią? Faktem jest, że większość organizacji nie rozumie w pełni technicznych aspektów prowadzenia inspekcji. O ile wyższa kadra kierownicza generalnie rozumie takie pojęcia, jak archiwizacja i odtwarzanie danych, to nieodłączna złożoność procesów ewidencjonowania zachodzących w środowisku zmian często nie spotyka się z właściwym zrozumieniem. W rezultacie pytanie o inspekcję często pada dopiero po wystąpieniu poważniejszego incydentu. Np. w systemie mógł zostać włączony podstawowy poziom inspekcji, ale jeśli z powodu braku odpowiedniego planowania w systemie nie zostanie włączone prowadzenie inspekcji konkretnych zmian, to informacje takie nie będą gromadzone.

Co więcej, z prowadzeniem inspekcji zdarzeń związanych z bezpieczeństwem wiążą się nierozłącznie pewne kwestie, z którymi muszą sobie radzić pracownicy działów IT. Jedną z takich trudności jest rozproszenie systemów we współczesnych dużych środowiskach komputerowych, w których gromadzenie i agregowanie informacji o zachodzących zmianach staje się poważnym problem, ponieważ zmiany mogą zachodzić w każdym systemie lub zbiorze systemów, praktycznie w każdej chwili. To z kolei prowadzi do kolejnego problemu – korelacji. Poznanie prawdziwego znaczenia rejestrowanych zdarzeń często wymaga przetłumaczenia wzajemnych relacji pomiędzy zdarzeniami z jednego lub z kilku systemów. Następnym problemem jest fakt, że procesy prowadzenia inspekcji często wykraczają poza tradycyjne granice podziałów organizacyjnych. Z różnych powodów w firmie mogą istnieć różne struktury organizacyjne lub zespołowe, pomiędzy którymi kooperacja może nie być łatwa. Wiele organizacji posiada zespół odpowiedzialny za funkcjonowanie usług katalogowych, zespół odpowiedzialny za infrastrukturę poczty elektronicznej i zespół odpowiedzialny za funkcjonowanie komputerów użytkowników, ale zwykle istnieje tylko jeden zespół odpowiedzialny za bezpieczeństwo we wszystkich tych obszarach. Co więcej, pracownicy odpowiedzialni za bezpieczeństwo mogą nie być obecni w każdej lokalizacji zajmowanej przez daną organizację. Np. biura regionalne często polegają na jednej osobie lub na niewielkim zespole zajmującym się wszystkimi zadaniami, włącznie z zarządzaniem dziennikiem zdarzeń Zabezpieczenia (Security).

Ponadto, sama ilość rejestrowanych zdarzeń stanowi wyzwanie samo w sobie. Ewidencjonowane zdarzenia dotyczące zabezpieczeń występują w znacznie większej ilości niż inne rodzaje rejestrowanych zdarzeń. Liczba gromadzonych zdarzeń utrudnia efektywne zachowywanie i przeglądanie dzienników. Co więcej, wymuszane różnymi przepisami okresy przechowywania tego typu informacji nie pomagają w zredukowaniu obciążeń związanych z utrzymywaniem współczesnych infrastruktur komputerowych.

W przeszłości, prowadzenie ewidencji dostępu do informacji można było sprowadzić do wymogu rejestrowania dostępu oraz posiadania wiedzy, że odbył się on w sposób bezpieczny. Obecnie, gdy organizacje oraz ich wyższa kadra kierownicza są prawnie odpowiedzialne za utratę informacji lub brak jej należytej ochrony, znajomość regulacji prawnych przez administratorów działów IT mogących mieć zastosowanie w danym środowisku nabiera krytycznego znaczenia. Wyzwania stojące przed firmami o zasięgu globalnym są nawet jeszcze większe, ponieważ każdy kraj posiada własne regulacje prawne dotyczące informacji oraz ich ochrony. Na rysunku 1 wymienionych zostało kilka przykładów istniejących regulacji prawnych, wraz z wynikającymi z nich wymaganiami nakładanymi na działy IT.

Regulacja prawna	Wymagania
Ustawa Sarbanes-Oxley Act z roku 2002 (SOX)	Sekcja 404 dotyczy roli systemów informacyjnych i nakłada na spółki giełdowe, znajdujące się w publicznym obrocie, obowiązek corocznego publikowania raportu na temat wewnętrznej kontroli raportów finansowych.
Ustawa o odpowiedzialności i przenoszalności danych w ubezpieczeniach zdrowotnych (HIPPA - Health Insurance Portability and Accountability Act)	Dotyczy bezpieczeństwa oraz prywatności danych zdrowotnych; część zatytułowana "Security Rule" (Reguły bezpieczeństwa) poświęcona jest administracyjnym, fizycznym i technicznym środkom ochrony tych danych.
Electronic Discovery (eDiscovery)	Definiuje standardy przechowywania oraz dostępu do dokumentów, włącznie z ewidencjonowaniem kto i w jaki sposób korzysta z dokumentów.
Federalna ustawa z 2002 o zarządzaniu bezpieczeństwem informacji (FISMA - Federal Information Security Management Act)	Wymóg federalny nakładający na agencje rządowe U.S.A. obowiązek zapewniania wyczerpujących systemów bezpieczeństwa informacji (INFOSEC), koordynacji z różnymi agencjami odpowiedzialnymi za przestrzeganie prawa, ustanowienia systemów kontroli i zatwierdzania stosowanych produktów komercyjnych oraz funkcji oprogramowania. Sekcja 3544 tego dokumentu poświęcona jest odpowiedzialności agencji, włącznie z określeniem zakresu kontroli i odpowiedzialności działów IT.
Federalne standardy przetwarzania informacji (FIPS - Federal Information Processing Standards Publication 200)	Określają minimalne wymagania w zakresie bezpieczeństwa, jakie muszą spełniać informacje federalne i systemy informacyjne, i zawierają zarys stosowania zaleceń wymienionych w specjalnej publikacji Narodowego Instytutu Bezpieczeństwa (NIST Special Publication 800-53). Sekcja AU-2 (Auditable Events - Ewidencjonowane zdarzenia) publikacji NIST SP800-53 zawiera wymóg nakazujący systemom informacyjnym zapewnianie możliwości kompilowania rekordów inspekcji pochodzących z różnych składników w jeden ogólnosystemowy i skorelowany czasowo zapis inspekcji, umożliwiający zarządzanie ewidencjonowanymi zdarzeniami z podziałem na pojedyncze składniki, a także wymaga od organizacji okresowego przeprowadzania przeglądu ewidencjonowanych zdarzeń.

 

Rysunek 1: Regulacje prawne i ich znaczenie dla pracowników działów IT (Stany Zjednoczone)

Co więc powinni zrobić pracownicy działów IT w związku z całą tą presją prawną? Kierownicy działów IT oraz technicy powinni przygotować jasny i zwięzły opis, który będą mogli zaprezentować osobom z wnętrza danej organizacji, jak również osobom spoza niej. Obejmuje to przygotowanie właściwej strategii prowadzenia inspekcji, co wymaga aktywnego podjęcia określonych działań oraz poczynienia pewnych inwestycji. Kluczowe znaczenie ma w tym przypadku przyjęcie koncepcji, w myśl której do kwestii inspekcji nie można podchodzić po etapie projektowania, gdyż wtedy zwykle jest już na to za późno.

Tego typu wyzwania pojawiające się przed działami IT można zwykle rozwiązać poprzez odpowiednie połączenie osób, procedur i technologii. W przypadku inspekcji najważniejsze są procedury. Dlatego pierwszym krokiem powinno być opanowanie podstaw, tak by można było spełniać oczekiwania i potrzeby danej organizacji w zakresie zgodności z wymogami prawnymi. Zajmijmy się zatem podstawami prowadzenia inspekcji w systemie Windows, a potem przejdziemy do omówienia zmian wprowadzonych w systemie Windows Server 2008 i Windows Vista®.

 Do początku strony

Prowadzenie inspekcji zdarzeń związanych z zabezpieczeniami

Wszystkie zdarzenia inspekcji są rejestrowane w dzienniku zdarzeń systemu Windows, o nazwie Zabezpieczenia (Security). Zdarzenia te zwykle nie wymają podejmowania natychmiastowych działań i często mają charakter jedynie informacyjny. Każde zdarzenie rejestruje prosty komunikat typu Sukces inspekcji (Audit Success) lub Niepowodzenie inspekcji (Audit Failure) dla określonego rodzaju dostępu, który miał miejsce. Różni się to od dzienników zdarzeń Aplikacja (Application) lub System (System), w których występujące problemy można zidentyfikować za pomocą kolorów (wskazówka: chcąc odszukać źródło problemu, należy poszukiwać zdarzeń oznaczonych kolorem czerwonym).

Dziennik zdarzeń Zabezpieczenia (Security) różni się pod tym względem, ponieważ ewidencjonowane zdarzania są często ukryte w swej ilości i, jak już wspomniano poprzednio, korelacja danych związanych z bezpieczeństwem może stanowić poważny problem. Nawet proste naruszenie danych w pojedynczym systemie może być problematyczne. Każdy taki przypadek może wymagać analizy dziennika zdarzeń Zabezpieczenia (Security) w celu określenia, które konto zostało użyte do uzyskania dostępu do danych, a to może wymagać od administratora prześledzenia wstecz dziennika zdarzeń. Niestety, współczesne skomplikowane ataki są często rozproszone i skoordynowane, znacznie utrudniając ich ofiarom przeprowadzanie tego rodzaju analizy.

Dlatego tak ważną rolę odgrywa znajomość kluczowych elementów umożliwiających rejestrowanie informacji w dzienniku zdarzeń systemu Windows Zabezpieczenia (Security): Zasad inspekcji (Audit Policy) oraz systemowych list kontroli dostępu (SACL - System Access Control List). Zasady inspekcji (Audit Policy) to ustawienia komputera lokalnego, które można konfigurować za pomocą Zasad grupy (Group Policy) lub Lokalnych zasad zabezpieczeń (Local Security Policy), definiując w ten sposób zestaw zdarzeń typu sukces oraz niepowodzenie dla konkretnych rodzajów dostępu. Wymienione poniżej podstawowe kategorie Zasad inspekcji (Audit Policy) są obecne w systemie Windows już od wielu lat (więcej informacji o nowych Szczegółowych zasadach inspekcji (Granular Audit Policy), dostępnych w systemie Windows Server 2008, znajduje się w dalszej części tego artykułu):

  •  Przeprowadź inspekcję zdarzeń logowania na kontach (Audit account logon events)

  •  Przeprowadź inspekcję zarządzania kontami (Audit account management)

  •  Przeprowadź inspekcję dostępu do usługi katalogowej (Audit directory service access)

  •  Przeprowadź inspekcję zdarzeń logowania (Audit logon events)

  •  Przeprowadź inspekcję dostępu do obiektów (Audit object access)

  •  Przeprowadź inspekcję zmian zasad (Audit policy change)

  •  Przeprowadź inspekcję użycia uprawnień (Audit privilege use)

  •  Przeprowadź inspekcję śledzenia procesów (Audit process tracking)

  •  Przeprowadź inspekcję zdarzeń systemowych (Audit system events)

Potrzeba definiowania Zasad inspekcji (Audit policy) i wymienionych powyżej związanych z nimi kategorii jest zwykle dobrze zrozumiana przez większość działów IT, ale Zasady inspekcji (Audit policy) reprezentują jedynie część rozwiązania. W implementacji całościowego planu prowadzenia inspekcji ważną rolę odgrywają również listy SACL. Informacje zwracane do dziennika zdarzeń Zabezpieczenia (Security) przez dwie konkretne kategorie Zasad inspekcji (Audit policy), inspekcję dostępu do usługi katalogowej oraz inspekcję dostępu do obiektów, są w pełni uzależnione od list SACL. Czy więc dokładnie są listy SACL?

Każdy obiekt, plik, rejestr systemu lub usługa katalogowa posiada własną listę kontroli dostępu (ACL - Access Control List), zawierającą jeden lub więcej wpisów kontroli dostępu (ACE - Access Control Entry), należących do jednej z dwóch kategorii: poufnej listy kontroli dostępu (DACL - Discretionary Access Control List) lub listy SACL (druga z tych list definiuje ustawienia rejestrowania prób dostępu do zabezpieczonych obiektów). Każdy z wpisów ACE, występujących na liście SACL, określa rodzaj prób dostępu podejmowanych przez wskazane konto lub grupę, które powinny być rejestrowane w dzienniku zdarzeń systemu Zabezpieczenia (Security). Wpisy ACE definiują rejestrowanie udanych lub nieudanych prób dostępu do określonego obiektu. Rysunek 2 przedstawia zastosowanie wobec obiektu listy SACL w celu generowania zdarzeń dla określonych rodzajów dostępu.

Rysunek 2: Użycie wobec obiektu listy SACL.

Znajomość relacji istniejących pomiędzy Zasadami inspekcji (Audit policy) a listami SACL ma krytyczne znaczenie, ponieważ rejestrowanie „właściwych” zdarzeń inspekcji, związanych ze zmianami zachodzącymi w danym środowisku, wymaga odpowiedniej konfiguracji. Jak już wspomniano, zasady inspekcji dostępu do usługi katalogowej oraz inspekcji dostępu do obiektów jedynie włączają możliwość generowania w dzienniku Zabezpieczenia (Security) zdarzeń inspekcji dla tych konkretnych kategorii, ale odpowiednie zdarzenia będą generowane tylko dla obiektów posiadających na swojej liście SACL skonfigurowany wpis ACE dla tego typu inspekcji. Dopiero połączenie tych elementów spowoduje generowanie odpowiednich zdarzeń przez lokalny urząd zabezpieczeń systemu Windows (LSA - Local Security Authority) i zapisywanie ich w dzienniku zdarzeń Zabezpieczenia (Security).

Rejestrowane zdarzenia składają się z dwóch osobnych obszarów: nagłówka, który ma charakter statyczny i jest wstępnie zdefiniowany dla każdego identyfikatora zdarzenia (Event ID), oraz z treści, która ma charakter dynamiczny i dla różnych zdarzeń może zawierać różne informacje szczegółowe. Rysunek 3 pokazuje te dwie części dla przykładowego zdarzenia zabezpieczeń systemu Windows Server 2008. Znajomość tych składników zdarzenia jest ważna na etapie analizy każdego projektu dotyczącego inspekcji i ma szczególne znaczenie pod względem sposobu prezentowania informacji przez takie narzędzia, jak np. usługa ACS.

Rysunek 3: Nagłówek i treść zdarzenia inspekcji.

Podsystem Windows Eventing 6.0

Znając już naturę problemu można zapytać, w jaki sposób system Windows Server 2008 pomaga organizacjom zmierzyć się ze stojącymi przed nimi wyzwaniami? System Windows Server 2008 jest pierwszą serwerową wersją systemu operacyjnego, zawierającą nowy podsystem zdarzeń Windows Eventing 6.0, który znacznie poprawia możliwości zarządzania zdarzeniami związanymi z zabezpieczeniami. Należy podkreślić, że artykuł ten koncentruje się na systemie Windows Server 2008, ale około 95% jego nowej funkcjonalności istnieje również w systemie Windows Vista. Jedną z pierwszych rzeczy, dostrzeganą przez większość osób korzystających z podsystemu Windows Eventing 6.0, jest nowy interfejs użytkownika. Nowa przystawka zarządzająca MMC (Microsoft Management Console) o nazwie Podgląd zdarzeń (Event Viewer) oferuje doskonałą stronę Przegląd i podsumowanie (Overview and Summar), elastyczne Widoki niestandardowe (Custom Views) oraz znacznie rozszerzony Tekst wyjaśnienia (Explain Text). Wymienione elementy interfejsu mogą ułatwić użytkownikowi końcowemu lub administratorowi wyszukiwanie informacji o odpowiednim zdarzeniu i konfigurowanie ważnych opcji dziennika zdarzeń, bezpośrednio z poziomu przystawki Podgląd zdarzeń (Event Viewer).

Jednym z kluczowych problemów, który często dotykał gromadzonych w dzienniku zdarzeń danych na temat zabezpieczeń, był okres zachowywania danych. W poprzednich wersjach, podsystem Dziennika zdarzeń (Event Log) (obejmujący wszystkie dzienniki) posiadał ograniczone limity skalowalności. Przekroczenie tych limitów powodowało, że cały podsystem przestawał rejestrować zdarzenia. Podsystem Windows Eventing 6.0 pozbawiony jest już takiego ograniczenia, a jedynym ograniczeniem dla ilości rejestrowanych zdarzeń jest obecnie tylko ilość wolnego miejsca na dysku. Należy jednak pamiętać, że ponieważ filtrowanie zdarzeń wymaga przeprowadzania oceny każdego pojedynczego wpisu dziennika, analizowanie bardzo dużych dzienników zdarzeń może być dość kłopotliwe i dlatego rozmiar dzienników powinien bezwzględnie być utrzymywany na rozsądnym poziomie.

Oczywiście do administratora działu IT nadal należeć będzie opracowanie odpowiedniego planu archiwizowania dzienników zdarzeń z wielu różnych systemów. Aby ułatwić realizację tego zadania na poziomie lokalnego serwera, podsystem Windows Eventing 6.0 oferuje nową opcję o nazwie Archiwizuj dziennik po zapełnieniu, nie zastępuj zdarzeń (Archive the log when full, do not overwrite events). W poprzednich wersjach systemu Windows opcję tę można było włączyć jedynie poprzez bezpośrednią modyfikację wartości rejestru o nazwie AutoBackupLogFiles. O ile opcja ta dostarcza mechanizmu lokalnego archiwizowania dzienników, to nie rozwiązuje ona problemu zarządzania tego typu plikami w dłuższym okresie czasu, ani nie rozwiązuje problemów powstających podczas agregowania danych pochodzących z kilku systemów. Kompletne rozwiązanie w tym zakresie oferują Usługi gromadzenia inspekcji (Audit Collection Services), którymi zajmiemy się za chwilę.

Nowy interfejs użytkownika to zaledwie początek. Prawdziwe możliwości podsystemu Windows Eventing 6.0 kryją się w nowej usłudze Dziennik zdarzeń systemu Windows (Windows Event Log) oraz w wykorzystywanym przez tę usługę motorze opartym na formacie XML. To właśnie te składniki zapewniają zwiększoną skalowalność, dostępność oraz za bardziej rozbudowane opcje zarządzania. Rejestrowane zdarzenia są obecnie przechowywane w elastycznym formacie XML, co umożliwia tworzenie niestandardowych rozwiązań sięgających do tych informacji w naturalny sposób. Podsystem Windows Eventing 6.0 oferuje także możliwość skojarzenia z konkretnymi zdarzeniami akcji administracyjnych. Odbywa się to poprzez integrację usługi Kolektor zdarzeń systemu Windows (Windows Event Collector) oraz usługi Harmonogram zadań (Task Scheduler), które wspólnie oferują możliwość generowania zdarzeń opartych na zadaniach. Jest to nowy model korzystania z usługi Harmonogram zadań (Task Scheduler), która w poprzednich wersjach systemu mogła wyzwalać zaprogramowane zdarzenia jedynie w oparciu o czas. Kreator uruchamiany za pomocą polecenia Dołącz zadanie do tego zdarzenia (Attach Task to this Event) (które dostępne jest w menu kontekstowym każdego zdarzenia wyświetlanego w systemie Windows Server 2008 przez przystawkę Podgląd zdarzeń (Event Viewer)) oferuje łatwy sposób uruchomienia programu, wysłania wiadomości e-mail lub wyświetlenia komunikatu, za każdym razem, gdy w systemie zarejestrowane zostanie określone zdarzenie. Możliwość taka może być bardzo użyteczna przy próbach zidentyfikowania konkretnych działań zachodzących w danym środowisku, które można powiązać z konkretnymi zdarzeniami zabezpieczeń. Np. w przypadku prowadzenia na posiadanych kontrolerach domeny inspekcji zmian klucza rejestru typu „Dozwolona aktualizacja schematu” można utworzyć zadanie wysyłające do określonych administratorów zabezpieczeń wiadomość e-mail, powiadamiającą ich o modyfikacji tego klucza rejestru.

Oprócz nowych możliwości gromadzenia i przechowywania bardzo dużej ilości wpisów zdarzeń, obecnie możliwe jest także dokładniejsze kontrolowanie, jakie zdarzenia będą rejestrowane w dzienniku zdarzeń. Można to osiągnąć dzięki nowej funkcjonalności o nazwie Szczegółowe zasady inspekcji (GAP - Granular Audit Policy). W poprzednich wersjach systemu Windows podział zdarzeń na dziewięć dość szerokich kategorii często prowadził do przeładowania dzienników rejestrowanymi zdarzeniami. Tych dziewięć kategorii najwyższego poziomu można obecnie kontrolować za pomocą pięćdziesięciu szczegółowych kategorii podrzędnych, z których każda reprezentuje odpowiedni podzbiór zdarzeń.

Daje to możliwość odfiltrowywania z dziennika zdarzeń informacji o mniejszym znaczeniu, bez utraty widoczności zdarzeń na poziomie kategorii. Np. jeśli w konkretnym systemie wymagane jest monitorowanie tylko zmian zachodzących w rejestrze, ale nie w systemie plików, to poprzednio istniała możliwość włączenia jedynie inspekcji sukcesów lub niepowodzeń dla kategorii Dostęp do obiektów (Object Access). Obecnie, dzięki szczegółowym zasadom inspekcji możliwe jest odfiltrowanie takich podkategorii, jak System plików (File System), Usługi certyfikacji (Certification Services) lub Udział plików (File Share) i rejestrowanie zdarzeń tylko z podkategorii Rejestr (Registry). Podkategorie szczegółowych zasad inspekcji, dostępne w systemie Windows Server 2008, można poznać korzystając w oknie wiersza poleceń z podwyższonym poziomem uprawnień, z polecenia Auditpol . W celu wyświetlenia listy dostępnych podkategorii szczegółowych zasad inspekcji, należy wykonać następujące polecenie:

auditpol /list /subcategory:*

Aby uzyskać listę skonfigurowanych w systemie podkategorii szczegółowych zasad inspekcji, należy wykonać polecenie:

auditpol /get /category:*

Należy pamiętać, że szczegółowych zasad inspekcji nie można konfigurować za pomocą standardowego interfejsu Zasad grupy (Group Policy), lecz konieczne jest posługiwanie się w tym celu programem auditpol.exe. Opis sposobu wdrażania za pomocą Zasad grupy (Group Policy) ustawień szczegółowych zasad inspekcji w systemie Windows Server 2008 oraz Windows Vista znajduje się w artykule z bazy wiedzy firmy Microsoft (Microsoft Knowledge Base), dostępnym pod adresem support.microsoft.com/kb/921469.

System Windows Server 2008 może również rejestrować w dzienniku zdarzeń Zabezpieczenia (Security) stare i nowe wartości dla określonych rodzajów zdarzeń. W poprzednich wersjach systemu Windows podsystem inspekcji rejestrował jedynie nazwę atrybutu obiektu usługi katalogowej Active Directory® lub nazwę zmienianej wartości rejestru, ale nie rejestrował poprzedniej i aktualnej wartości zmienianego atrybutu. Ta nowa możliwość dotyczy Usług domenowych w usłudze Active Directory (Active Directory Domain Services), Usług LDAP w usłudze Active Directory (Active Directory Lightweight Directory Services) oraz rejestru systemu Windows. Włączając Inspekcję sukcesów (Audit Success) lub Inspekcję niepowodzeń (Audit Failure) dla podkategorii „Rejestr” (Registry) lub „Zmiany usługi katalogowej" (Directory Service Changes) i konfigurując odpowiednie listy SACL, wykonywanie operacji na tych obiektach powodować będzie rejestrowanie w dzienniku szczegółowych zdarzeń. Można to osiągnąć wykonując następujące polecenia auditpol:

auditpol /set /subcategory:"Rejestr" /success:enable

auditpol /set /subcategory:"Zmiany usługi katalogowej" /success:enable

Zmiany rejestru będą rejestrowane jako zdarzenia z wartością identyfikatora zdarzeń równą 4657, tak jak to pokazano na rysunku 4.

Rysunek 4: Rejestrowanie wartości przed oraz po zmianie rejestru.

Ta funkcjonalność jest szczególnie przydatna w przypadku śledzenia zmian dokonywanych na obiektach usługi katalogowej Active Directory. W przypadku podkategorii Zmiany usługi katalogowej (Directory Service Changes) wykonywane zmiany rejestrowane są jako para zdarzeń o identyfikatorze równym 5136, tak jak to zostało pokazane na rysunku 5. Każde takie zdarzenie posiada w ciele zdarzenia opis Obiektu (Object), Atrybutu (Attribute) oraz Operacji (Operation) wykonanej na usłudze katalogowej. W przypadku zmian atrybutów z istniejącymi danymi widoczne będą dwie operacje: Wartość usunięta (Value Deleted) oraz Wartość dodana (Value Added). W przypadku atrybutów, które nie zostały jeszcze ustawione, zapis danych do tych atrybutów powodować będzie odnotowanie jedynie operacji Wartość dodana (Value Added). Np. w przypadku udanej operacji modyfikacji atrybutu obiektu typu użytkownik, takiego jak np. Numer telefonu (telephoneNumber), usługa katalogowa Active Directory zarejestruje w szczegółowych wpisach dziennika zdarzeń poprzednią oraz bieżącą wartość tego atrybutu.

Rysunek 5: Zdarzenia rejestrowane przed oraz po operacji typu Zmiana usługi katalogowej (Directory Service Change).

W przypadku tworzenia nowego obiektu zarejestrowane zostaną wartości atrybutów ustawianych w chwili tworzenia tego obiektu. Jeśli obiekt zostanie przeniesiony w obrębie domeny, zarejestrowane zostanie jego poprzednie oraz nowe położenie (w formie jednoznacznej nazwy wyróżniającej). Ta funkcjonalność rejestrowania „starych i nowych” wartości jest włączona domyślnie, jeśli stosowane są odpowiednie ustawienia Zasad grupy (Group Policy). W przypadku atrybutów, które powinny pozostać prywatne, takich np. jak zmiany identyfikatora pracownika, możliwe jest jawne wykluczenie takich atrybutów poprzez wykonanie prostej modyfikacji schematu. Po zmianie w schemacie wartości właściwości searchFlags na 0x100 (wartość 256, oznaczająca - NEVER_AUDIT_VALUE), tak jak to zostało pokazane na rysunku 6, zmiany tego atrybutu nie będą już powodować generowania zdarzenia kategorii Zmiany usługi katalogowej (Directory Service Changes).

Rysunek 6: Wykluczanie atrybutu z kategorii Zmiany usługi katalogowej (Directory Service Changes).

Na koniec, jedną z doskonałych nowych funkcji podsystemu Windows Eventing 6.0 jest funkcjonalność Subskrypcji zdarzeń (Event Subscriptions). Jak już wspomniano wcześniej, używanie i przeglądanie dzienników zdarzeń jest jednym z kluczowych zadań w administrowaniu systemem. Nowa funkcjonalność Subskrypcji zdarzeń (Event Subscriptions) oferuje możliwość bezpośredniego przekazywania zdarzeń pomiędzy systemami. Funkcja Subskrypcji zdarzeń (Event Subscriptions) składa się z kolektora zdarzeń, który gromadzi zdarzenia, oraz ze źródeł zdarzeń, dla których skonfigurowano przekazywanie zdarzeń do określonego hosta. Możliwość pochłaniania zdarzeń oferowana jest przez usługę Kolektor zdarzeń systemu Windows (Windows Event Collector) (jest to nowy składnik podsystemu Windows Eventing 6.0), a funkcjonalność subskrybowania zdarzeń jest wbudowana w usługę Dziennik zdarzeń systemu Windows (Windows Event Log). Kolektor zdarzeń można skonfigurować w taki sposób, aby gromadził zdarzenia pochodzące z wielu różnych źródeł zdarzeń, którymi mogą być systemy Windows Server 2008 lub Windows Vista.

Wszystkie dane zgromadzone ze skonfigurowanych źródeł zdarzeń znajdują się w osobnym dzienniku zdarzeń o nazwie Przekazane zdarzenia (Forwarded Events) (w pliku ForwardedEvents.evtx) i są zarządzane przez usługę Dziennik zdarzeń (Event Log), działającą na komputerze gromadzącym zdarzenia. Wymaga to odpowiedniej konfiguracji po obu stronach (po stronie źródła i kolektora), którą można wykonać automatycznie (za pomocą polecenia winrm quickconfig –q po stronie źródła oraz polecenia wecutil qc /q po stronie kolektora). Należy w tym miejscu podkreślić, że ta funkcjonalność subskrybowania zdarzeń nie została zaprojektowana z myślą o dużych przedsiębiorstwach lub o zastąpieniu systemów dostarczających zdarzenia do zewnętrznej bazy danych.

Jednym z przykładów wykorzystania tej funkcjonalności jest niewielka farma serwerów webowych. Przypuśćmy, że dysponujemy niewielkim zestawem systemów skojarzonych z konkretną witryną webową (obejmującym serwery webowe oraz serwery SQL). Korzystając z nowej funkcjonalności Subskrypcji zdarzeń (Event Subscription) wszystkie te systemy mogą skonsolidować w jednym systemie informacje zawarte w swoich dziennikach zdarzeń Zabezpieczenia (Security). Większe środowiska będą zwykle wymagać bardziej zaawansowanych narzędzi do konsolidacji zawartości dzienników zdarzeń.

Usługi gromadzenia inspekcji (Audit Collection Services)

Biorąc pod uwagę wszystkie nowe możliwości systemu Windows Server 2008, prawdziwym rozwiązaniem zapewniającym długoterminowe zarządzanie i archiwizowanie informacji zawartych w dziennikach zdarzeń Zabezpieczenia (Security) jest zastosowanie centralnej bazy danych gromadzącej wszystkie informacje związane z inspekcją. Usługi gromadzenia inspekcji (ACS - Audit Collection Services) są podstawową funkcją oprogramowania System Center Operations Manager 2007. Usługa ACS zapewnia mechanizmy przekazywania, gromadzenia, magazynowania i analizowania danych zapisanych w zdarzeniach zabezpieczeń. Zdarzenia zabezpieczeń są gromadzone w czasie niemal rzeczywistym i są zapisywane w centralnym repozytorium SQL. Usługa ACS oferuje również organizacjom możliwość oferowania dostępu do danych inspekcji przy użyciu minimalnego poziomu uprawnień, ponieważ przeglądanie tych danych nie wymaga fizycznego dostępu do systemów, na których faktycznie prowadzona jest inspekcja. Przyjrzyjmy się zatem jak działa usługa ACS.

Usługa ACS składa się z trzech głównych składników. Pierwszym z nich jest Moduł przekazywania (Forwarder), będący częścią agenta oprogramowania Operations Manager, przesyłający dane z dziennika zdarzeń klienta do infrastruktury usługi ACS. Moduły przekazywania przesyłają dane do drugiego składnika, Modułu kolektora (Collector), który prowadzi nasłuch po stronie serwera. Moduły przekazywania łączą się w bezpieczny sposób z przypisanymi im modułami kolektorów, przy użyciu portu TCP numer 51909. Przed rozpoczęciem transmisji dane z dziennika zdarzeń zostają poddane normalizacji do formatu XML, co oznacza odrzucenie nadmiernych informacji i podsumowanie informacji ze zdarzeń w pola oparte na nagłówkach oraz informacjach z treści konkretnych zdarzeń. Po dotarciu tych informacji do modułu kolektora zostają one przesłane do trzeciego i ostatniego składnika – Bazy danych usługi ACS (ACS Database). Baza ta staje się repozytorium dla długoterminowego przechowywania informacji pochodzących ze zdarzeń zabezpieczeń. Po zapisaniu informacji w bazie danych możliwe jest ich bezpośrednie przeszukiwanie za pomocą zapytań SQL lub wyświetlanie za pomocą raportów w formacie HTML, przy użyciu usług raportujących SQL Server® Reporting Services. Usługa ACS oferuje trzy domyślne widoki, które zostały wymienione na rysunku 7.

Nazwa widoku usługi ACS	Przeznaczenie
AdtServer.dvHeader	Informacje z nagłówków zgromadzonych zdarzeń.
AdtServer.dvAll	Informacje z nagłówków oraz z treści zgromadzonych zdarzeń.
AdtServer.dvAll5	Informacje z nagłówków oraz z pierwszych pięciu łańcuchów znakowych z treści zgromadzonych.

 

Rysunek 7: Widoki usługi ACS.

Z punktu widzenia wydajności, pojedynczy moduł kolektora usługi ACS może obsługiwać w szczycie do 100 000 zdarzeń na sekundę, a w dłuższym okresie czasu maksymalnie 2 500 zdarzeń na sekundę. Dla potrzeb planowania można przyjąć, że w oparciu o domyślne ustawienia Zasad inspekcji (Audit Policy) pojedynczy moduł kolektora usługi ACS może obsługiwać do 150 kontrolerów domeny, 3000 serwerów członkowskich lub 20 000 stacji roboczych. W jednym z przetestowanych rzeczywistych scenariuszy około 150 kontrolerów domeny dostarczało maksymalnie około 140 zdarzeń na sekundę, przy średnim poziomie 500 000 zdarzeń na godzinę. W ciągu zaledwie 14 dni (jest to domyślny okres zachowywania danych dla usługi ACS) prowadzi do zapisania w bazie danych serwera SQL Server ponad 150 GB danych pochodzących ze zdarzeń zabezpieczeń. Zastosowanie bardziej agresywnych zasad inspekcji i skojarzonej z nimi konfiguracji list SACL doprowadzi oczywiście do generowania jeszcze większej ilości danych (na godzinę, w ciągu dnia oraz dla całego okresu zachowywania danych).

Bardzo ważne jest uświadomienie sobie, że przy takiej ilości danych żaden człowiek nie będzie w stanie przejrzeć wszystkich zdarzeń rejestrowanych w typowym środowisku dużego przedsiębiorstwa. Nie oznacza to jednak, że organizacje powinny obawiać się prezentowanych w tym artykule liczb. Znajomość zmian zachodzących w posiadanym środowisku odbywa się bowiem kosztem analizowania bardzo dużych ilości danych.

To właśnie na tym polu może zabłysnąć usługa ACS. Korzystając z usług raportujących SQL Server Reporting Services oraz z usługi ACS możliwe jest przekształcenie problemów skrywających się zwykle wśród informacji zarejestrowanych w dzienniku zdarzeń Zabezpieczenia (Security), w dające się łatwo zidentyfikować przekazy, na podobieństwo kodowanych kolorami zdarzeń z dziennika zdarzeń Aplikacja (Application). Wprawdzie usługa ACS zawiera zestaw domyślnych raportów, ale w prosty sposób można je rozszerzyć, dostosowując do specyficznych wymogów własnego środowiska.

Rozważmy następujący scenariusz: ze względu na podatność posiadanego środowiska na zewnętrzne relacje zaufania zarząd firmy poprosił o sporządzenie raportu dostarczającego szczegółowych informacji o przypadkach tworzenia Relacji zaufania usługi Active Directory (Active Directory Trusts). Po przeprowadzeniu niewielkich poszukiwań można ustalić, że tworzeniu relacji zaufania odpowiada utworzenie obiektu trustedDomain w kontenerze cn=System, znajdującym się w kontekście nazwy określonej domeny usługi Active Directory. Po przeprowadzeniu edycji listy SACL dla tego kontenera, pozwalającej na prowadzenie inspekcji pomyślnych przypadków tworzenia dowolnych relacji zaufania międzydomenowego, istnieje możliwość rejestrowania zdarzeń zabezpieczeń towarzyszących tworzeniu każdego obiektu tego typu. Zdarzenia tego typu są rejestrowane w dzienniku zdarzeń Zabezpieczenia (Security) na kontrolerze domeny, na którym miało miejsce utworzenie relacji zaufania, z wartością identyfikatora zdarzenia równą 566. W celu pobrania tych informacji z bazy danych usługi ACS, można posłużyć się następującym, prostym zapytaniem w języku SQL:

select * from AdtServer.dvAll 

where EventID = '566' and

String05 like '%trustedDomain%'

order by CreationTime desc

Aby nadać tym informacjom formę raportu, należy skorzystać z wersji programu Visual Studio® 2005, która została dołączona do usług raportujących SQL Server 2005 Reporting Services, ponieważ jest to wersja przystosowana specjalnie do tworzenia raportów. Korzystając z odpowiedniego kreatora można łatwo przygotować raport, który będzie bardzo podobny do raportu przedstawionego na rysunku 8. Co więcej, za pomocą równie efektownych raportów można podsumowywać wszelkie zmiany środowiska, które mogą być reprezentowane w dzienniku zdarzeń Zabezpieczenia (Security).

Rysunek 8: Przykładowy raport usługi ACS.

 Do początku strony

Opracowywanie planu inspekcji

Zdając już sobie sprawę z trudności, a także z prawnych oraz z technicznych aspektów związanych z prowadzeniem inspekcji, w jaki sposób administratorzy z działów IT powinni podejść do opracowania „planu inspekcji” dla swojej organizacji? Podobnie jak w większości innych przypadków, opracowywanie wyczerpujących zasad prowadzenia inspekcji jest procesem składającym się z wielu kroków. Pierwszy krok polega na określeniu, co powinno zostać poddane inspekcji. Krok ten obejmuje przeprowadzenie analizy własnego środowiska i określenie, jakiego rodzaju zdarzenia i zmiany powinny być ewidencjonowane. Mogą to być proste przypadki, takie jak np. blokady kont, zmiany newralgicznych grup i relacji zaufania, albo złożone zmiany, takie jak np. modyfikacje elementów konfiguracji używanych w danym środowisku aplikacji. Kluczowe znaczenie ma w tym przypadku zaangażowanie zarządu w celu ustalenia, „co” należy objąć planem inspekcji. Takie ćwiczenie należy przeprowadzić na papierze i powinno ono być regularnie powtarzane, a nie dopiero po wystąpieniu poważniejszych przypadków.

Drugi krok polega na określeniu, w jaki sposób informacje uzyskiwane w procesie inspekcji i dotyczące konkretnych zmian są zwracane w formie zdarzeń zabezpieczeń. Informacje pozyskiwane w procesie inspekcji są czasami dość tajemnicze i niezbyt czytelne. Przed przejściem do fazy implementacji konieczne jest ustalenie korelacji zachodzących pomiędzy różnymi działaniami a zdarzeniami zabezpieczeń, tak by zrozumieć prawdziwe znaczenie tych zdarzeń. Po wystąpieniu niepożądanego incydentu nie będzie już czasu na szukanie relacji pomiędzy zdarzeniami a wywołującymi je działaniami.

Trzeci krok polega na implementacji przygotowanych Zasad inspekcji (Audit Policy) oraz list SACL, rozstrzygając o powodzeniu całego procesu lub o jego fiasku. Jak już wspomniano poprzednio, uzyskanie pełnego obrazu zmian zachodzących w usłudze katalogowej, systemie plików oraz w rejestrze systemu wymaga zdefiniowania w tych obszarach odpowiednich ustawień Zasad inspekcji (Audit Policy) (w celu umożliwienia generowania zdarzeń zabezpieczeń) oraz odpowiednich list SACL (w celu generowania zdarzeń inspekcji odpowiadających wybranym działaniom).

Wszystkie te kroki prowadzą do ostatniego, czwartego kroku - gromadzenia, wyzwalania wstępnie zdefiniowanych akcji i analizowania. W zależności od wielkości oraz wymagań danej organizacji zadania te można realizować przy pomocy standardowych funkcji systemu Windows Server 2008 lub za pomocą zaawansowanych rozwiązań, takich jak funkcjonalność Usługi gromadzenia inspekcji (Audit Collection Services), stanowiącej część oprogramowania System Center Operations Manager. Częstym błędem popełnianym przez większość organizacji jest konfigurowanie tylko Zasad inspekcji (Audit Policy), bez zdefiniowania odpowiednich list SACL. Ostatni krok w całości związany jest z implementacją rozwiązań technologicznych, służących do raportowania i współdzielenia danych pomiędzy udziałowcami danej organizacji. Jak już wspomniano wcześniej, większość organizacji posiada wydzieloną komórkę odpowiedzialną za bezpieczeństwo i jeśli tworzony plan inspekcji ma być efektywny, to powinien on opierać się na istniejących elementach organizacyjnych. Kluczem do powodzenia tego ostatniego kroku jest odpowiednie gromadzenie i prezentowanie informacji wszystkim osobom odpowiedzialnym za nadzorowanie zmian zachodzących w danym środowisku.

Większość działów IT potrzebuje zaledwie jednego poważniejszego zdarzenia, aby przejść od bliżej niesprecyzowanej wizji stworzenia wyczerpującego planu prowadzenia inspekcji do sytuacji, gdy taki plan będzie naprawdę potrzebny. W porównaniu do poprzednich wersji, system Windows Server 2008 oferuje udoskonalone mechanizmy służące do gromadzenia i analizowania danych zawartych w zdarzeniach zabezpieczeń. Zaawansowane technologie służące do gromadzenia danych i raportowania, takie jak np. usługa ACS, pozwalają na ujawnianie problemów, które poprzednio przesłaniane były przez ilość oraz rozproszony charakter zdarzeń sprawiając, że zachodzące w środowisku zmiany natychmiast stają się oczywiste.

Podobnie jak w przypadku większości innych problemów informatycznych, największe wyzwanie tkwi w procesach. Uzyskanie tego, czego oczekują kierownicy działów IT, zawsze wymagać będzie przeprowadzania dodatkowej konfiguracji i analizy i dlatego dokładne poznanie wymogów istniejących w środowisku oraz możliwości oferowanych przez platformę systemu Windows pozwoli na śmiałe stawienie czoła tym wyzwaniom. Owocnych poszukiwań.

O autorach

Rob Campbell i Joel Yoker

Rob Campbell jest starszym specjalistą (Senior Technical Specialist) a Joel Yoker starszym konsultantem (Senior Consultant) federalnego zespołu firmy Microsoft. Zarówno Rob, jak i Joel koncentrują się na opracowywaniu i wdrażaniu rozwiązań z zakresu bezpieczeństwa, przeznaczonych dla federalnych agencji rządu Stanów Zjednoczonych.

Do początku strony

---