Get-EventLog -LogName Security – log zdarzeń bezpieczeństwa

Get-EventLog -LogName Security zwraca zdarzenia z dziennika bezpieczeństwa — wymaga uprawnień administratora do odczytu wpisów audytu.

Get-EventLog i dziennik Security — czym jest odczyt zdarzeń bezpieczeństwa

Polecenie Get-EventLog -LogName Security służy do pobierania wpisów zapisanych w dzienniku bezpieczeństwa systemu Windows. Dziennik ten gromadzi informacje związane między innymi z logowaniem użytkowników, próbami użycia nieprawidłowych danych uwierzytelniających, zmianami uprawnień, dostępem do wybranych zasobów oraz działaniami wykonywanymi przez konta systemowe. W praktyce stanowi jeden z podstawowych śladów pozwalających ustalić, co wydarzyło się na komputerze i w jakiej kolejności.

Wynik polecenia ma postać obiektów PowerShell, dlatego nie jest jedynie tekstem przeznaczonym do wyświetlenia na ekranie. Każdy obiekt może zawierać identyfikator zdarzenia, źródło, typ wpisu, datę, nazwę użytkownika, opis oraz inne właściwości dostępne dla danego systemu. Dzięki temu dane można filtrować, sortować, zapisywać do pliku i łączyć z kolejnymi poleceniami. Do odczytu wpisów audytu z dziennika Security zwykle potrzebne są uprawnienia administratora. Brak takich uprawnień może skutkować komunikatem o odmowie dostępu, pustym wynikiem albo ograniczonym zakresem danych.

Znaczenie ma także konfiguracja zasad audytu. Samo użycie polecenia nie powoduje utworzenia brakujących wpisów. Jeżeli rejestrowanie logowania, zmian kont lub dostępu do obiektów nie zostało wcześniej włączone, w dzienniku nie pojawią się informacje o tych czynnościach. Z tego powodu analiza powinna uwzględniać nie tylko wynik odczytu, lecz także ustawienia systemu, czas działania komputera oraz to, czy dziennik nie został wyczyszczony lub nadpisany.

Parametr -LogName Security a nowsze metody analizy

W poleceniu parametr -LogName Security wskazuje konkretny dziennik. Jest to wygodny sposób pracy ze starszym mechanizmem Get-EventLog, jednak w nowszych wersjach Windows często zaleca się również użycie Get-WinEvent. Oba polecenia mogą odczytywać zdarzenia, lecz różnią się zakresem obsługiwanych dzienników, sposobem filtrowania i wydajnością. Get-EventLog jest łatwy do zapamiętania i przydatny przy prostych zadaniach, natomiast Get-WinEvent lepiej sprawdza się przy dużej liczbie wpisów, precyzyjnym filtrowaniu oraz pracy z dziennikami opartymi na nowocześniejszym modelu zdarzeń.

Różnica jest podobna do porównania szybkiego wyszukania kilku dokumentów z przeszukiwaniem rozbudowanego archiwum według wielu kryteriów. Proste wywołanie Get-EventLog -LogName Security może zwrócić dużą liczbę rekordów, dlatego przydatne jest ograniczenie zakresu. Można filtrować wpisy według daty, identyfikatora zdarzenia, typu wpisu lub użytkownika. Warto pamiętać, że nazwy właściwości i dostępne wartości mogą zależeć od wersji Windows, ustawień językowych oraz rodzaju konkretnego zdarzenia.

Przykładowe polecenie ograniczające wynik do nowszych wpisów może wyglądać następująco:

Get-EventLog -LogName Security -Newest 50

Takie użycie pobiera ostatnie rekordy, ale nie odpowiada jeszcze na pytanie, czy dane zdarzenie oznacza problem. Sama obecność wpisu nie jest równoznaczna z incydentem. Wpis informujący o poprawnym logowaniu może być całkowicie prawidłowy, a wiele nieudanych prób może wynikać z błędnie zapisanych danych w usłudze działającej w tle. Interpretacja wymaga zestawienia czasu, konta, nazwy komputera oraz innych zdarzeń występujących w tym samym okresie.

Get-EventLog Security — typowe problemy z odczytem

Najczęstszą przeszkodą jest brak uprawnień. Uruchomienie PowerShell bez podwyższonych praw może uniemożliwić dostęp do dziennika Security. W takiej sytuacji należy sprawdzić, czy używane konto ma odpowiednie uprawnienia i czy konsola została uruchomiona w trybie administratora. Nie powinno się jednak automatycznie nadawać szerokich uprawnień każdemu użytkownikowi. Bezpieczniej jest ograniczyć zakres dostępu do osób, które rzeczywiście zajmują się diagnostyką lub utrzymaniem systemu.

Drugim problemem jest niepełna historia. Dzienniki mają określony rozmiar i mogą być konfigurowane tak, aby starsze wpisy były nadpisywane. Jeżeli komputer był długo używany albo generował wiele zdarzeń, poszukiwany rekord mógł zostać usunięty wskutek normalnego działania mechanizmu przechowywania. Brak wpisu nie dowodzi więc, że dane zdarzenie nie miało miejsca.

Wątpliwości może powodować również nieczytelny opis zdarzenia. Właściwość Message często zawiera dłuższy komunikat z nazwą konta, kodem błędu, identyfikatorem procesu lub adresem źródłowym. Niektóre pola mogą być puste, skrócone albo zależne od zainstalowanych składników systemu. Przydatne jest wyświetlenie pełnych właściwości rekordu, na przykład przez potok do Format-List, a następnie zapisanie wyników do pliku w celu spokojnego porównania.

Trzeba też uważać na pomylenie czasu lokalnego z czasem zapisanym w innym środowisku. Przy analizie kilku komputerów różnica ustawień zegara lub stref czasowych może sprawić, że zdarzenia pozornie nie pasują do siebie. Przed wyciągnięciem wniosków warto sprawdzić aktualny czas systemowy, synchronizację oraz ustawienia regionalne.

Praktyczne wskazówki dla Get-EventLog -LogName Security

Analizę najlepiej rozpoczynać od wąskiego pytania. Zamiast przeglądać cały dziennik, można ustalić przedział czasu, interesujące konto albo konkretny identyfikator zdarzenia. Ograniczenie wyników ułatwia zauważenie powtarzalnego wzorca i zmniejsza ryzyko pominięcia istotnego wpisu wśród wielu komunikatów.

• Najpierw należy sprawdzić, czy dziennik jest dostępny i czy polecenie zostało uruchomione z właściwymi uprawnieniami.
• Następnie warto zapisać czas pierwszego i ostatniego analizowanego zdarzenia.
• Powtarzające się wpisy powinny być grupowane według identyfikatora, konta i źródła.
• Przydatne jest porównanie udanych i nieudanych prób logowania w tym samym okresie.
• Wyniki diagnostyki dobrze zachować w pliku tekstowym lub tabelarycznym wraz z informacją o dacie wykonania polecenia.

Przy większej liczbie wpisów korzystne może być przekazanie wyniku do poleceń sortujących i wybierających konkretne właściwości. Należy zachować ostrożność przy automatycznym filtrowaniu, ponieważ różne typy zdarzeń mogą mieć odmienny układ komunikatu. Lepiej opierać reguły na stabilnych polach, takich jak identyfikator i czas, niż na całym tekście opisu.

Nie należy czyścić dziennika tylko po to, aby usunąć niepotrzebne komunikaty z ekranu. Wyczyszczenie może utrudnić późniejszą analizę i pozbawić ważnego materiału diagnostycznego. Jeżeli wymagane jest uporządkowanie danych, bezpieczniejszym rozwiązaniem jest eksport wybranych rekordów i praca na kopii. Szczególną uwagę należy zwrócić na informacje dotyczące kont użytkowników, ponieważ zapisany opis może zawierać dane, których nie powinno się udostępniać osobom postronnym.

Kiedy zgłosić problem z dziennikiem Security do serwisu

Pomoc serwisu może być uzasadniona, gdy dziennik bezpieczeństwa nie otwiera się mimo poprawnych uprawnień, wpisy znikają szybciej niż oczekiwano, komputer samoczynnie zmienia ustawienia audytu albo w krótkim czasie pojawia się wiele nietypowych prób logowania. Warto zgłosić również sytuację, w której komputer działa niestabilnie, a analiza zdarzeń ma pomóc rozdzielić problem systemowy od kłopotu z kontem, sterownikiem lub konfiguracją zabezpieczeń.

W Warszawskim Pogotowiu Komputerowym 24/7 można przekazać komputer do sprawdzenia wraz z opisem objawów i przybliżonym czasem ich występowania. Przydatne będzie wskazanie, czy problem dotyczy jednego konta, wszystkich użytkowników, uruchamiania systemu czy konkretnej aplikacji. Nie należy samodzielnie usuwać wpisów przed diagnostyką, ponieważ może to ograniczyć możliwość odtworzenia przebiegu zdarzeń. Po zakończeniu analizy można otrzymać wyjaśnienie, które rekordy są normalne, które wymagają dalszej obserwacji oraz jakie ustawienia warto uporządkować.

W przypadku komputera używanego do pracy szczególne znaczenie ma zachowanie ciągłości działania i danych. Dziennik Security jest jednym ze źródeł informacji, lecz nie zastępuje kopii zapasowej, aktualizacji ani rozsądnego zarządzania kontami. Najlepszy efekt daje połączenie odczytu zdarzeń z oceną stanu systemu, sprawdzeniem aktualnych ustawień oraz dokumentowaniem zmian wykonywanych podczas naprawy.