• Artykuł

     

OpsMgr: Audit Collection Service jako usługa zarządzania logiem zabezpieczeń na platformie Windows, cz. 1

Udostępnij na: Facebook

Autor: Joanna Subik

Opublikowano: 2010-11-05

Wprowadzenie

Zarządzanie logami w szerokim kontekście jest zagadnieniem, na którego temat powstało sporo fachowej literatury. Zazwyczaj mówi się o zarządzaniu w dwóch aspektach – monitorowania bezpieczeństwa oraz retencji danych. W jaki sposób monitorować i przechwytywać zdarzenia w sieci, przychodzące z różnych systemów dostępnych w środowisku? Jak radzić sobie z ich zbieraniem, archiwizowaniem i zarządzaniem zgodnie z ogólnie przyjętymi normami oraz wewnętrznymi politykami organizacji? I wreszcie – w jaki sposób wykorzystać zebrane informacje do ich analizy w czasie rzeczywistym, tworzenia pewnego rodzaju wzorców, uruchamiania alarmów i informowania wskazanych osób o wystąpieniu określonego zdarzenia?

Z problemem zarządzania logami od lat borykają się administratorzy systemów i sieci oraz zespoły odpowiedzialne za zapewnienie bezpieczeństwa w przedsiębiorstwie. Jeśli chodzi o zarządzanie logami w Windows Server, to trzeba zaznaczyć, że możliwość kontroli nad tym, co znajduje się w Dzienniku Zdarzeń (Event Viewer) pojawiła się już w pierwszej edycji Windows Server i sukcesywnie była ulepszana w kolejnych odsłonach. Nadal jednak służy do zarządzania logami w podstawowym zakresie, co oznacza, że nie spełnia wielu wymogów, jakie są stawiane przed nowoczesnym systemem zarządzania zdarzeniami. Odpowiedzią na taką potrzebę rynku jest usługa ACS (Audit Collection Service) – jeden z subkomponentów System Center Operations Manager, który został zaprojektowany specjalnie na potrzeby zarządzania logiem bezpieczeństwa w systemach Windows. To bardzo ważne dlatego,  że na dzień dzisiejszy usługa ACS innych logów nie potrafi zbierać. Tę funkcjonalność można rozszerzyć poprzez wykorzystanie aplikacji firm trzecich, o tym jednak będzie mowa w kolejnych sekcjach tematycznych niniejszego artykułu.

Zawartość strony:

1.      Zawartość logu zabezpieczeń w systemach Windows

2.      Dziennik Zdarzeń w Windows Server 2003 i Windows Server 2008

3.      Architektura usługi Audit Collection Service

4.      Instalacja usługi ACS

Zawartość logu zabezpieczeń w systemach Windows

Do logu zabezpieczeń systemu Windows zwykle się zagląda, gdy w sieci dzieje się coś niedobrego. Mimo woli staje przed oczami stary, dobrze znany Dziennik Zdarzeń (Event Viewer), w którym zdarzenia kwalifikujące się do umieszczenia w logu zabezpieczeń można podzielić na dziewięć grup inspekcji:

  1. zdarzeń związanych z użyciem uprawnień (Audit privilegeuse) – należy skonfigurować, gdy wymagane jest logowanie przypadków skorzystania z prawa użytkownika;
  2. dostępu do obiektów (Audit objectaccess) – należy skonfigurować, gdy logowaniu mają być poddawane zdarzenia typu uzyskanie dostępu przez użytkownika do takich obiektów, jak: plik, folder, klucz rejestru, drukarka, baza SAM itp., dla których określono systemową listę kontroli dostępu (SACL). Listę SACL można skonfigurować na obiekcie systemu plików, używając karty Zabezpieczenia w oknie dialogowym Właściwości dla tego obiektu;
  3. zdarzeń systemowych (Audit system events) – należy skonfigurować, gdy wymagane jest logowanie zdarzeń systemowych, np. próby zmiany czasu systemowego lub włączenia/wyłączenia komputera;
  4. zdarzeń logowania na kontach (Audit account logon events)– należy skonfigurować, jeżeli w logu mają być umieszczane zdarzenia logowania lub wylogowania się użytkownika z komputera. Zdarzenia logowania na kontach są generowane, gdy konto użytkownika domeny jest uwierzytelniane na kontrolerze domeny. To zdarzenie jest rejestrowane w dzienniku zabezpieczeń kontrolera domeny. Zdarzenia logowania są generowane, gdy użytkownik lokalny jest uwierzytelniany na komputerze lokalnym. To zdarzenie jest rejestrowane w lokalnym dzienniku zabezpieczeń (zdarzenia wylogowania z kont nie są generowane);
  5. zdarzeń logowania (Audit logon events) – należy skonfigurować, gdy konieczne jest śledzenie zdarzeń logowania na koncie. Tego typu zdarzenia są generowane na kontrolerach domeny (gdy dotyczą aktywności konta domeny) i na komputerach lokalnych (gdy dotyczą aktywności na kontach lokalnych). Jeśli są włączone kategorie zasad inspekcji logowania i logowania na kontach, logowania z użyciem konta domeny generują zdarzenia logowania lub wylogowania na stacji roboczej lub serwerze, a na kontrolerze domeny generują zdarzenia logowania na koncie. Ponadto interakcyjne logowania na serwerze członkowskim lub stacji roboczej z użyciem konta domeny generują zdarzenia logowania na kontrolerze domeny, gdy skrypty i zasady logowania są odbierane podczas logowania użytkownika;
  6. zdarzeń zarządzania kontami (Audit account management) – należy skonfigurować, gdy logowaniu mają podlegać zdarzenia zarządzania kontami na komputerze. Przykładowe zdarzenia zarządzania kontami to: utworzenie, zmiana lub usunięcie konta użytkownika lub grupy użytkowników, zmiana nazwy, wyłączenie lub włączenie konta użytkownika, ustawienie lub zmiana hasła;
  7. śledzenia procesów (Audit processtracking) – należy skonfigurować, gdy logowaniu mają być poddawane informacje dotyczące takich zdarzeń, jak: aktywacja programu, zakończenie procesu, duplikacja dojścia i niebezpośredni dostęp do obiektu;
  8. dostępu do usługi katalogowej (Audit directory service access) – należy skonfigurować, gdy logowaniu mają być poddawane zdarzenia polegające na dostępie użytkownika do obiektu usługi Active Directory, dla którego określono systemową listę kontroli dostępu (SACL);
  9. zmiana zasad (Audit policy change) – po skonfigurowaniu tej wartości inspekcji będą poddawane wszystkie zdarzenia zmiany zasad przypisywania praw użytkowników, zasad inspekcji lub zasad zaufania.

Uważny czytelnik zapewne domyślił się, że ustawienia te można dowolnie skonfigurować na wypadek porażki, sukcesu lub wystąpienia zdefiniowanychprzypadków. Można również pozostawić ustawienia nieskonfigurowane, jednak nie jest to najlepsze rozwiązanie. Aby ustawić polityki audytu, należy uruchomić przystawkę służącą do edycji polis GPO, a następnie, przechodząc do gałęzi ComputerConfiguration/Windows Settings/Security Settings/Audit Policy, skonfigurować odpowiednie polityki w zależności od wymaganych potrzeb. Polityki mogą działać lokalnie lub domenowo, przy czym większą centralizację i kontrolę nad środowiskiem zapewniają oczywiście polityki skonfigurowane domenowo. W niniejszym artykule nie będzie rozpatrywany inny przypadek ze względu na wykorzystanie usługi ACS do zbierania logów bezpieczeństwa, gdyż usługa ta do prawidłowego działania wymaga obecności Active Directory.

Dziennik Zdarzeń w Windows Server 2003 i Windows Server 2008

Samo zarządzanie logami (nie tylko zabezpieczeń) jest złożonym procesem, który obejmuje wiele etapów: od zbierania wymaganych informacji zgodnie z normami i procedurami określonymi przez prawo i wewnętrzne procedury przedsiębiorstwa, poprzez ich analizę, porównywanie wzorców, filtrowanie, zapisywanie, raportowanie, aż do tworzenia na ich podstawie określonych alarmów lub podejmowania wymaganych akcji. Zarządzanie logami w Windows Server istnieje od pierwszej wersji serwerowego systemu operacyjnego, jednak nie spełnia ono wszystkich wymagań stawianych przed nowoczesnym systemem zarządzania logami.

Patrząc krytycznym okiem na sposób zarządzania logami w Windows Server 2003 (rys. 1), można dostrzec następujące problemy:

  • decentralizacja zbieranych zdarzeń – są one zapisywane lokalnie na maszynach,
  • brak reakcji systemu na zdarzenie,
  • brak możliwości raportowania i zaawansowanego filtrowania logów,
  • brak możliwości wygodnego zbierania logów w celu tworzenia bazy zdarzeń,
  • brak wysokiej dostępności.

Rys 1. Log zabezpieczeń w Windows Server 2003.

Patrząc równie krytycznie na sposób zarządzania logami w Windows Server 2008 (rys. 2), zauważamy, że nadal brakuje możliwości raportowania i zaawansowanego filtrowania logów oraz wygodnego gromadzenia logów w celu tworzenia bazy zdarzeń. Nie pojawiło się także żadne rozwiązanie ułatwiające wdrożenie wysokiej dostępności w kontekście zarządzania logami. Uczciwie jednak należy dodać, że wprowadzone zostało rozwiązanie subskrypcji logów, co pozwala na ich zbieranie na jednej centralnej maszynie. Ważną zmianą jest także możliwość reakcji na zdarzenie – jeśli w systemie zarejestrowany zostanie określony incydent, system podejmie jedną z trzech akcji zdefiniowanych uprzednio przez administratora: wyśle wiadomość mailową, wyświetli komunikat lub uruchomi określoną aplikację (może to być również skrypt lub zadane polecenie konsolowe).

Rys. 2. Log zabezpieczeń w Windows Server 2008.

Odpowiedzią na opisane problemy i ograniczenia jest usługa Audit Collection Service (ACS), jeden z subkomponentów SCOM (System Center Operations Manager), służący do zarządzania logiem zabezpieczeń w szeroko pojęty sposób: od zbierania logów, poprzez zapisywanie ich do bazy danych, aż do tworzenia raportów i monitorowania określonych zdarzeń oraz podejmowania uprzednio zdefiniowanych akcji.

Architektura usługi Audit Collection Service

Usługa ACS składa się z czterech komponentów:

  1. Forwarder – to element usługi, o którego instalację nie należy się martwić: jest instalowany razem z agentem SCOM, natomiast domyślnie jest wyłączony, by niepotrzebnie nie zagrabiać zasobów systemu operacyjnego. Przy planowaniu systemów biorących udział w przekazywaniu zdarzeń do collectora warto zastanowić się, które z nich mają brać w tym udział, by niepotrzebnie nie generować ruchu w sieci. Zazwyczaj takimi systemami są kontrolery domen, które ze względu na pełnioną rolę (centrum uwierzytelniania i autoryzacji) generują bardzo dużą ilość zdarzeń w logu zabezpieczeń. Innymi systemami mogą być np. serwery odpowiadające za zdalne uwierzytelnianie użytkowników do zasobów sieciowych (np. serwery VPN) oraz systemy uznane przez administratora za szczególnie istotne (np. serwery SQL lub IIS). Aby móc wykorzystać możliwości komponentu forwarder, należy najpierw skonfigurować collector oraz bazę danych (omówionych  tu w dalszych podpunktach).
  2. Collector – komponent usługi ACS, odpowiedzialny za zbieranie danych z forwardera, odpowiednie ich parsowanie i przesyłanie do bazy w postaci znormalizowanej. Nieprzetworzone dane zawierają zwykle zbyt dużo informacji i wiele z nich jest redundantne, co powoduje, że informacje zapisywane do bazy są niepotrzebnie powielane. Komunikacja z klientem przekazującym (forwarder) odbywa się po porcie 51909, więc należy również pomyśleć o poprawnym skonfigurowaniu zapory systemowej, by uniknąć blokowania wymaganego portu. Collector jest odpowiedzialny za decyzję, jakie dane powinny zostać zachowane i zatrzymuje tylko te, które są konieczne. Na przykład opis zdarzenia może zostać odrzucony, bo taka informacja już istnieje w bazie i nie ma potrzeby jej powielania. Collector może zostać zainstalowany tylko na Management Serverze, co oznacza, że podczas planowania wdrożenia usługi ACS należy się zastanowić, który Management Server będzie pełnił ww. rolę. Należy też mieć na uwadze, że ACS wykorzystuje zasoby systemu na zbieranie i normalizację danych, zatem dobrze byłoby mieć dedykowany serwer MS tylko dla potrzeb ACS, co zresztą jest zgodne z najlepszymi praktykami Microsoft. Ograniczeniem w wersji SCOM 2007 RTM była relacja jeden do jednego dla collectora i bazy, co oznaczało, że jeden collector mógł zapisywać dane tylko do jednej bazy danych. A co w przypadku, gdy obciążenie pierwszego collectora było tak duże, że należało uruchomić drugi? Wtedy trzeba było zainstalować dodatkowy collector i osobną, tylko dla niego dedykowaną bazę SQL. Jak łatwo się domyślić, było to rozwiązanie dosyć niewygodne, zwłaszcza do tworzenia raportów (trzeba było tworzyć zapytania łączące dane z dwóch baz, zamiast z jednej). Począwszy od wersji SCOM 2007 SP1, możliwe jest uruchomienie dwóch collectorów zapisujących do tej samej bazy danych, co można wykorzystać przy budowaniu wysoko dostępnego środowiska usługi ACS. Aktualnie nie ma możliwości uruchomienia serwera collector w typowym klastrze, jaki znamy np. z usług SQL. Jeżeli wymagany jest automatyczny failover i failback, trzeba poszukać niestandardowego rozwiązania, np. można utworzyć monitor, który będzie sprawdzał, czy usługa odpowiedzialna za działanie serwera collector jest uruchomiona i na wypadek awarii podejmie próbę jej uruchomienia na zapasowym serwerze collector.
  3. Baza danych – wymogiem koniecznym do spełnienia jest wykorzystanie Microsoft SQL Server 2005 z SP1 lub Microsoft SQL Server 2008 z SP1, przy czym zalecane jest wykorzystanie oprogramowania w wersji Standard lub Enterprise. Oczywiście z naciskiem na wersję Enterprise, a to dlatego, że nie zrywa ona połączenia z collectorem w czasie, gdy baza będzie w tzw. cyklu maintenance.  Wersja Standard zatrzymuje zapisywanie danych przychodzących od klientów przekazujących podczas okna serwisowego (maintenance). Mówiąc prościej: podczas używania wersji Standard collector nie będzie przesyłał zdarzeń do bazy, co spowoduje ich kolejkowanie. Jeśli kolejka ulegnie przepełnieniu, forwarder zostanie odłączony i nie będzie mógł przesyłać nowych eventów, w efekcie czego zostaną one utracone. Aby tego uniknąć, można przydzielić więcej miejsca na kolejkę (domyślnie mieści się w niej 262 144 zdarzenia).

Kolejny problem, jaki może się pojawić podczas wykorzystania wersji SQL Standard, to możliwa dziura bezpieczeństwa. Podczas rozpoczęcia cyklu maintenance zbierane dane są podatne na atak, ponieważ mogą ulec zmodyfikowaniu. Jeżeli intruz zna ramy czasowe, w jakich wykonywany jest cykl maintenance, może zaatakować system np. poprzez wstrzyknięcie własnego eventu eliminującego jego działania w systemie operacyjnym. Jest to mało prawdopodobne, ale możliwe. SQL Server w wersji Enterprise zapewnia ciągłe połączenie collectora z bazą danych – wprawdzie przesyłanie zdarzeń podczas cyklu maintenance odbywa się znacznie wolniej, jednak wykluczona zostaje możliwość modyfikacji danych. Zalecane jest zainstalowanie bazy danych na innej maszynie niż collector (oczywiście można zainstalować obydwa komponenty na jednym komputerze, jednak ze względów wydajnościowych i bezpieczeństwa nie jest to optymalne rozwiązanie). Wykorzystanie bazy MSSQL eliminuje wszystkie te problemy, które występowały podczas zarządzania logiem za pomocą standardowego Dziennika Zdarzeń, wbudowanego w Windows Server, tj. filtrowanie, raportowanie, porównywanie danych itp. Mówiąc sentencjonalnie: w kwestii zbierania danych oraz ich obróbki ogranicza administratora jedynie jego własna wyobraźnia.

  1. Report Server – serwer raportujący, który będzie odpowiadał za generowanie i dostarczanie raportów. Do poprawnego działania wymaga zainstalowania SQL Reporting Services w wersji 2005 z SP1 lub w wersji 2008 z SP1 na serwerze, który będzie serwerem raportów. Wymagane jest ponadto zainstalowanie roli Web Server (IIS). Warto również pamiętać o odpowiednich uprawnieniach – podczas instalacji Reports Server wymagane jest członkostwo m.in. w grupie Operations Manager Reports Operator oraz zapewnienie sobie dostępu do bazy ACS. Jeżeli w planowanej instalacji usługi ACS wymagana jest całkowita separacja komponentów, wskazane jest zainstalowanie serwera raportującego na osobnej maszynie. Usługa ACS posiada domyślnie ok. 30 zdefiniowanych raportów, które należy doinstalować. Możliwe jest również stworzenie własnych raportów oraz wykorzystanie gotowych rozwiązań firm trzecich (np. SecureVantage ma w swojej ofercie ponad 700 różnego rodzaju kombinacji raportów dla usługi ACS).

Rysunek 3 przedstawia schemat usługi ACS zaprojektowanej w wysokiej dostępności, przy czym wszystkie komponenty składowe zostały rozdzielone na osobne maszyny.

Rys. 3. Schemat usługi ACS zaprojektowanej w wysokiej dostępności z podziałem na komponenty.

Instalacja usługi ACS

Stan wyjściowy jest znany: istnieje środowisko SCOM, zbudowany został klaster SQL dla bazy ACS, wybrano Management Server, który będzie pełnił rolę ACS Collector i zainstalowano serwer raportujący (Report Server).

Instalację usługi ACS rozpocząć należy od uruchomienia funkcjonalności ACS Collectora, podczas którego zostanie utworzona dedykowana baza ACS, w której zapisywane będą zdarzenia zebrane przez klientów przekazujących (forwarders). Należy zaopatrzyć się w nośnik instalacyjny SCOM 2007, uruchomić go na wybranym Management Serverze i wybrać opcję: Install Audit Collection Server, co przedstawia rys. 4.

Rys. 4. Okno startowe instalacji ACS Collector.

W oknie powitalnym kreatora instalacji usługi ACS należy wybrać Next (rys. 5).

Rys. 5. Okno kreatora usługi instalacji usługi ACS Collector.

* *

Następnie wymagane jest zaakceptowanie postanowień licencyjnych (rys. 6).

Rys. 6. Okno akceptacji postanowień licencyjnych.

Kolejne okno stawia administratora przez wyborem: można użyć istniejącej bazy danych lub utworzyć nową. Domyślna baza danych zostaje nazwana OperationsManagerAC (rys. 7).

Rys. 7. Wybór opcji instalacji bazy danych.

Następny krok polega na wybraniu źródła danych (ODBC Data Source Name), które będzie używane do komunikacji z bazą danych ACS. Domyślny DSN dla usługi ACS to OpsMgrAC (rys. 8).

Rys. 8. Wybór źródła danych.

* *

Po wyborze źródła DSN pora na wybór serwera SQL (rys 9). Możliwe jest wybranie serwera SQL rezydującego lokalnie na management serwerze, na którym właśnie dokonywana jest instalacja usługi ACS Collector (oczywiście warunkiem koniecznym jest wcześniejsze zainstalowanie wymaganych komponentów SQL na ww. maszynie). Druga z dostępnych opcji zezwala na wybór serwera zdalnego i może to być dowolny serwer SQL spełniający wymogi usługi ACS. W poniższym przykładzie wskazany został klaster SQL, który będzie odpowiedzialny za zapewnienie dostępności bazy danych ACS. Kreator wymaga jeszcze (opcjonalnie) podania nazwy instancji oraz nazwy bazy danych. Jak już zostało wcześniej wspomniane, jest to baza OperationsManagerAC.

Rys. 9. Wybór serwera SQL, nazwy instancji oraz bazy danych.

Po dokonaniu powyższych ustaleń trzeba wybrać metodę uwierzytelnienia do wskazanej bazy danych (rys. 10). Możliwe są dwie opcje – uwierzytelnianie Windows oraz SQL. Wybierając uwierzytelnianie Windows, będzie można uzyskiwać dostęp do bazy na podstawie poświadczeń konta użytkownika Windows z wykorzystaniem usługi katalogowej, np. Active Directory. Taka praktyka jest powszechnie stosowana i zalecana przez Microsoft. Jeżeli serwer SQL i collector znajdują się w jednej domenie, należy użyć uwierzytelniania Windows. Uwierzytelnianie SQL nie wykorzystuje protokołu Kerberos, więc użytkownik będzie musiał podać login i hasło (zwykle inne niż to, które wykorzystuje, by uzyskać dostęp do serwera), by móc przeprowadzać operacje na bazie danych. Ten typ jest zwykle wykorzystywany, gdy baza danych i collector nie znajdują się w jednej domenie, lub gdy między domenami nie ma utworzonych odpowiednich relacji zaufania. 

Rys. 10. Wybór metody uwierzytelniania.

Kolejnym krokiem (rys. 11) jest wybór lokalizacji plików bazy danych. Ponieważ baza SQL składa się zwykle z przynajmniej dwóch plików (baz danych oraz logów), najlepszymi praktykami jest umieścić je na oddzielnych dyskach (przy czym byłoby doskonale, gdyby te dyski działały w RAID0, oczywiście w celu zapewnienia lepszej wydajności). Można zatem wybrać, czy dane będą przechowywane w lokalizacji domyślnej, czy też w miejscu wskazanym przez administratora.

Rys. 11. Wybór lokalizacji plików bazy danych.

Istotne jest odpowiednie zaplanowanie retencji zdarzeń oraz czasu okna serwisowego dla bazy SQL. Retencja zdarzeń powinna przypadać na takie godziny, w których spodziewane jest najmniejsze obciążenie. Domyślnie kreator proponuje godzinę 02:00. Należy jeszcze podać czas, w jakim zdarzenia będą przechowywane w bazie danych, i w tym przypadku domyślna wartość wynosi 14 dni (rys. 12).

Rys. 12. Planowanie retencji zdarzeń oraz czasu okna serwisowego dla bazy SQL.

* *

Ostatnim krokiem jest wybór formatu czasowego, co ma wpływ na sposób, w jaki tworzone są kwerendy do bazy SQL. Kreator podpowiada, by pozostawić wartość domyślną (rys. 13).

Rys. 13. Wybór formatu czasowego.

Okno podsumowania wyświetla wartości wybrane podczas konfigurowania collectora (rys. 14). Po zatwierdzeniu zmian zostanie rozpoczęta instalacja serwera collector.

Rys. 14. Okno podsumowania.

Po pomyślnym ukończeniu instalacji w konsoli SCOM, na zakładce Monitoring w węźle Microsoft Audit Collection Service możliwe jest podejrzenie stanu nowo zainstalowanego serwera collector, który będzie odpowiadał za przekazywanie zdarzeń do bazy ACS (rys. 15).

Rys. 15. Okno konsoli SCOM, gdzie można podejrzeć aktualny stan serwera collector.

Po zainstalowaniu bazy ACS oraz serwera collector należy przystąpić do konfiguracji klientów przekazujących (forwarders). W konsoli SCOM na zakładce Monitoring w węźle Operations Manager należy rozwinąć folder Agent oraz wybrać widok Agent HealthState. Po wybraniu klientów, którzy będą przekazywać zdarzenia, należy włączyć dla nich usługę ACS (Enable Audit Collection), co przedstawia rys. 16.

Rys. 16. Konfiguracja klientów przekazujących – krok 1.

* *

Następnie wymagane jest potwierdzenie uruchomienie zadania „Enable Audit Collection” (rys. 17).

Rys. 17. Konfiguracja klientów przekazujących – krok 2.

Po wykonaniu zadania zastanie wyświetlone jego podsumowanie (rys. 18).

Rys. 18. Konfiguracja klientów przekazujących – krok 3.

* *

Po pomyślnym włączeniu usługi ACS dla wymaganych serwerów możliwe jest podejrzenie ich stanu w konsoli SCOM na zakładce Monitoring, w węźle Microsoft Audit Collection Service w katalogu Forwarders (rys. 19).

Rys. 19. Okno konsoli SCOM, gdzie można podejrzeć aktualny stan klientów przekazujących.

* *

Ostatnim krokiem podejmowanym przy konfigurowaniu usługi ACS jest uruchomienie dedykowanych raportów. W przeciwieństwie do większości raportów, które są dostępne w SCOM po zainstalowaniu określonego Management Packa, raporty usługi ACS należy zainstalować oddzielnie. Jak już zostało wcześniej wspomiane, usługa raportowania do poprawnego działania wymaga SQL Reporting Services 2005 z SP1 lub 2008 z SP1, przy czym można użyć instancji przeznaczonej dla Operations Manager Reporting lub zainstalować oddzielną na osobnej maszynie. Wdrożenie ACS Reporting na tej samej instancji SQL Server Reporting Services co Operations Manager Reporting powoduje, że członkowie grupy Operations Manager Report Operator Role będą mieli dostęp do wszystkich raportów w SCOM, łącznie z raportami ACS (ze względów bezpieczeństwa nie zawsze jest to pożądane). Aby móc uruchamiać raporty ACS, członkowie grupy Operations Manager Reporting Role muszą mieć uprawnienie db_datareader przypisane do bazy ACS (OperationsManagerAC) – jest to konieczne i niezależne od obecności Operations Manager Reporting. W poniższym przykładzie ACS Reporting zostanie zainstalowany na tej samej instancji, co SQL Server Reporting Services. Proces został przedstawiony poniżej.

Najpierw należy zalogować się na serwerze, który będzie hostował ACS Reporting z poświadczeniami użytkownika-administratora instancji SRS (Server Reporting Services), następnie utworzyć folder tymczasowy (np. C:\ACS) i skopiować do niego zawartość \ReportModels\acs znajdującą się na nośniku instalacyjnym Operations Managera. Następnie na tym nośniku należy przejść do katalogu \SupportTools i skopiować plik ReportingConfig.exe do katalogu tymczasowego (c:\acs), który został już utworzony. Kolejno należy uruchomić narzędzie wiersza poleceń cmd, przejść do katalogu c:\acs i wykonać poniższe polecenie: UploadAuditReports “AuditDBServer\Instance” “Reporting_Server_URL” “ścieżka_do_utworzonego_katalogu_acs”, co przedstawia rys. 20.

Rys. 20. Instalacja raportów ACS.

Podczas wykonywania polecenia pojawia się ostrzeżenie o utworzeniu nowego źródła danych (Db Audit) oraz przesłaniu modeli raportowania Audit.smdl, Audit5.smdli wszystkich raportów z katalogu acs\reports.

Następnie należy uruchomić przeglądarkę Internet Explorer i wpisać adres strony SQL Reporting Services Home: http://<yourReportingServerName>/Reports$<InstanceName>, np. http://cerberos/reports, wybrać Audit Reports i kliknąć Show Details, co przedstawia rys. 21.

Rys. 21. Konfiguracja ACS Reporting.

Kolejnym krokiem konfiguracyjnym jest wybór źródła danych Db Audit oraz sprawdzenie, czy zaznaczona została opcja Windows Integrated Security. Jeżeli nie, należy ją zaznaczyć i zatwierdzić akcję (rys. 22).

Rys. 22. Konfiguracja ACS Reporting.

* *

Po poprawnym skonfigurowaniu raportów ACS powinny być one widoczne w konsoli SCOM (rys. 23), na zakładce Reporting w węźle Audit Reports. Domyślnie jest dostępnych ok. 30 różnych raportów, które można rozszerzać o własne propozycje, lub importować raporty dostarczone przez dostawców.

Rys. 23. Podgląd dostępnych raportów ACS w konsoli SCOM.

Podsumowanie

Powyższy artykuł miał na celu pokazanie roli Audit Collection Service w zbieraniu logów bezpieczeństwa z komputerów działających pod kontrolą Windows. Przedstawione zostały słabości standardowych mechanizmów zarządzania logami w Windows Server 2003 oraz 2008, oraz pokrótce omówiono architekturę i możliwe przykłady instalacji ACS w środowisku rozproszonym. Niewątpliwą zaletą ACS jest możliwość zapewnienia wysokiej dostępności oraz bardzo zaawansowana konfiguracja poszczególnych jej elementów. Istnieje również możliwość dokonania jej optymalizacji, dodatkowego zabezpieczenia – te elementy zostaną przedstawione w drugiej części niniejszego artykułu. Warto wspomnieć, że istniejące aplikacje firm trzecich pozwalają na rozszerzenie możliwości usługi ACS o zbieranie i analizę logów dotyczących aplikacji, ustawień, systemu itd. Możliwe jest również dołączenie usługi ACS do innego, większego systemu typu SIEM (Security Information and Event Management) za pomocą pilotów czy innych aplikacji, co pozwala na zaawansowane filtrowanie logów, analizę występujących wzorców oraz innych funkcji zapewnianych przez rozbudowane systemy zarzadzania logami.