Instrukcja oparta na dokumentacji Microsoft dostępnej 17 października 2026 r. Nazwy menu mogą różnić się zależnie od języka portalu.
Pracownik zgłasza nietypową prośbę o potwierdzenie logowania albo informuje, że jego konto było używane w nieznanym miejscu. Pierwszym krokiem technicznym jest sprawdzenie odpowiednich zdarzeń. Dzienniki logowań Microsoft Entra ID pomagają ustalić, jakie konto, aplikacja i sposób uwierzytelnienia wystąpiły w danym czasie.
Poradnik dotyczy odczytu i udokumentowania danych przez uprawnioną osobę. Jeżeli podejrzenie przejęcia konta jest aktualne, równolegle uruchom uzgodnioną procedurę obsługi incydentu. Oczekiwanie na pełny raport nie powinno opóźniać decyzji osoby odpowiedzialnej za reakcję.
Przygotuj zakres sprawdzenia i dostęp
Zapisz konto użytkownika, przybliżoną godzinę, strefę czasową oraz opis problemu. Ustal, czy chodzi o pocztę, konkretną aplikację czy całe konto służbowe. To pozwoli ograniczyć przegląd danych do potrzebnego zakresu.
Microsoft wskazuje Reports Reader jako minimalną rolę do odczytu dzienników aktywności. Dostępność danych zależy również od licencji. Uprawnienia do konfiguracji przesyłania logów to odrębna kwestia. Microsoft — dostęp do dzienników aktywności.
Poproś administratora o właściwy dostęp zgodnie z zasadami organizacji. Samo zadanie odczytania logów nie uzasadnia przekazywania pełnego konta administracyjnego. Jeżeli pracujesz dla kilku organizacji, potwierdź, w której aktualnie działasz.
Krok 1 — otwórz dziennik logowań
Wejdź do centrum administracyjnego Microsoft Entra. Po zalogowaniu przejdź do Entra ID → Monitoring & health → Sign-in logs. W polskim interfejsie szukaj odpowiedników dotyczących monitorowania i dzienników logowań. Oficjalne ścieżki dostępu.
Jeżeli nie widzisz dziennika, sprawdź z administratorem rolę, właściwy katalog i zakres licencji. Widok własnej aktywności użytkownika nie jest równoważny dostępowi do danych całej organizacji.
Krok 2 — zawęź wyszukiwanie
Wybierz okres obejmujący zgłoszenie i dodaj filtr użytkownika. Przy pierwszej analizie pozostaw rozsądny zapas czasu przed zdarzeniem i po nim. Dalsze filtry, np. wynik lub aplikację, dodawaj pojedynczo. Zapisz, jakie ograniczenia zastosowano.
Przykład modelowy: zgłoszenie dotyczy konta jan.kowalski@example.com około 10:00. Zacznij od tego użytkownika i okna obejmującego kilka godzin. Domenę example.com użyto wyłącznie jako bezpieczny przykład; w rzeczywistym wyszukiwaniu wybierz zweryfikowane konto organizacji.
Ustal także typ logowania. Aktywność użytkownika, działanie aplikacji i procesy wykonywane w tle nie zawsze pojawiają się w tym samym widoku. Rodzaj zdarzenia ma znaczenie dla późniejszej interpretacji.
Schemat instruktażowy DataOne. Nie jest zrzutem ekranu i nie przedstawia danych klienta.
Krok 3 — otwórz szczegóły zdarzenia
Sprawdź czas, użytkownika, aplikację, rezultat, adres IP i dostępne informacje o urządzeniu. Odczytaj szczegóły uwierzytelnienia oraz zastosowania zasad dostępu warunkowego. Zapisz identyfikatory potrzebne do odnalezienia tego samego zdarzenia. Microsoft — znaczenie szczegółów logowania.
Adres IP i przybliżona lokalizacja są wskazówkami. VPN, operator komórkowy lub infrastruktura pośrednicząca mogą utrudnić powiązanie ich z fizycznym miejscem pobytu. Nie uznawaj samego innego miasta za dowód przejęcia konta.
Podobnie informacja o spełnieniu wymogu MFA wymaga odczytania kontekstu. Może wiązać się z wcześniej uzyskanym potwierdzeniem w sesji. Zestaw ją z opisem szczegółów i pozostałymi zdarzeniami, zanim sformułujesz wniosek o zachowaniu użytkownika.
Krok 4 — zachowaj wynik i opisz ograniczenia
Portal umożliwia pobranie danych w CSV lub JSON. Wybierz właściwy zakres, pobierz plik i sprawdź jego zawartość. Przy dużym zakresie może być potrzebne podzielenie pobierania; szczegóły i ograniczenia opisuje dokumentacja. Microsoft — pobieranie dzienników.
Plik przechowuj w miejscu przeznaczonym na materiały sprawy, z ograniczonym dostępem. Zapisz datę eksportu, filtry, strefę czasową i osobę wykonującą czynność. Do raportu dla kierownictwa zwykle wystarczy podsumowanie; pełne dane techniczne zachowaj dla uprawnionych osób.
| Pole notatki | Przykładowy sposób uzupełnienia |
|---|---|
| Powód sprawdzenia | Zgłoszenie użytkownika i numer sprawy |
| Zakres | Katalog, konto, aplikacja, przedział czasu |
| Ustalenia | Co wynika bezpośrednio z rekordów |
| Otwarte pytania | Co wymaga potwierdzenia przez użytkownika lub IT |
| Materiał | Chroniony odnośnik do eksportu i identyfikatory |
| Decyzja | Dalsza analiza, eskalacja lub uzasadnione zamknięcie |
Co oznacza brak wyników
Najpierw sprawdź zakres czasu, katalog, użytkownika i typ logowania. Następnie zweryfikuj dostępność danych dla danego okresu oraz ewentualny błąd pobierania. Pusty widok bez tych ustaleń nie pozwala stwierdzić, że żadnej aktywności nie było.
Jeżeli podobne sprawdzenia są potrzebne często, warto zaplanować centralne zbieranie zdarzeń i kontrolę ich aktualności. Integracja z SIEM wymaga ustalenia uprawnień, kosztów, retencji i testów kompletności. Ręczny eksport jest przydatny w konkretnej sprawie, ale wymaga osobnego procesu regularnego monitorowania.
DataOne może pomóc ustalić, które logi Microsoft 365 są dostępne i jak wykorzystać je w monitoringu bezpieczeństwa. Rozmowę możemy zacząć od używanych licencji, obecnej konfiguracji oraz rodzaju zdarzeń, które chcesz wykrywać. Porozmawiaj o monitoringu Microsoft 365 z DataOne.