Gdy po incydencie bezpieczeństwa pada pytanie „kto pobrał ten dokument?”, odpowiedź „plik był dostępny dla działu finansowego” jest za słaba. Trzeba ustalić konkretne konto, czas zdarzenia, rodzaj operacji, obiekt, którego dotyczyła, oraz — jeśli to możliwe — źródło dostępu. Jeszcze trudniej robi się przy pytaniu „kto otworzył dokument?”, bo techniczny wpis o dostępie do pliku nie jest automatycznie dowodem, że człowiek przeczytał jego treść.
To właśnie w tym miejscu wymagania NIS2 i znowelizowanej ustawy o krajowym systemie cyberbezpieczeństwa spotykają się z praktyką DMS. Przepisy nie nakazują przedsiębiorcy kupienia systemu DMS i nie zawierają uniwersalnego polecenia rejestrowania każdego otwarcia każdego pliku. Wymagają natomiast od podmiotów objętych KSC odpowiednich środków zarządzania ryzykiem, kontroli dostępu, zarządzania incydentami i możliwości wykazania, co wydarzyło się w systemach informacyjnych.
Na 6 października 2026 r. harmonogram jest już konkretny. Nowelizacja KSC weszła w życie 3 kwietnia 2026 r. Podmioty kluczowe i ważne, które spełniały kryteria w dniu wejścia ustawy w życie i podlegały samorejestracji, miały czas na wniosek o wpis do Wykazu KSC do 3 października 2026 r. Ten termin już minął. Do 3 kwietnia 2027 r. przypada koniec okresu dostosowawczego do nowych obowiązków, w tym wdrożenia wymaganych rozwiązań organizacyjnych i technicznych oraz rozpoczęcia korzystania z S46. Dla podmiotów kluczowych objętych odpowiednim obowiązkiem pierwszy audyt trzeba przeprowadzić do 3 kwietnia 2028 r. Nie oznacza to jednak, że każda polska firma podlega KSC. Najpierw trzeba ustalić sektor, rodzaj działalności, wielkość przedsiębiorstwa i szczególne kryteria ustawowe.
Dobry DMS zapisuje nie tylko „kto miał dostęp”, lecz także co faktycznie zrobił
Najczęstszy błąd podczas oceny systemu DMS polega na sprawdzeniu, czy administrator może wyświetlić listę użytkowników mających uprawnienia do folderu. To potrzebne, ale lista uprawnień nie jest historią zdarzeń.
Jeżeli dokument zawiera projekt umowy przejęcia spółki, dane klientów albo dokumentację techniczną, po podejrzeniu wycieku trzeba odpowiedzieć przynajmniej na kilka pytań:
- kto uzyskał dostęp do dokumentu,
- kto go pobrał na urządzenie,
- kto wykonał eksport albo masowe pobranie,
- czy dokument pobrał użytkownik, aplikacja czy konto serwisowe,
- kto zmienił treść lub metadane,
- kto zmienił uprawnienia,
- czy doszło do dostępu przez API,
- z jakiego konta i kiedy wykonano operację.
To różne zdarzenia i nie każdy system rejestruje je z taką samą dokładnością.
Przykład z praktyki: pracownik działu zakupów o 14:07 otwiera kartę kontrahenta, o 14:09 pobiera załącznik PDF, a o 14:13 aplikacja synchronizacyjna automatycznie pobiera dodatkową kopię dokumentu. Jeżeli DMS pokaże tylko trzy zdarzenia typu „access”, administrator może błędnie uznać je za trzy świadome odczyty użytkownika. Prefetch, synchronizacja, generowanie podglądu, antywirus, indeksowanie wyszukiwarki i integracje przez API potrafią tworzyć zdarzenia bez aktywnego działania człowieka.
Dlatego wpis „FileAccessed” czy jego odpowiednik oznacza przede wszystkim, że system odnotował określone zdarzenie dostępu. Nie dowodzi sam w sobie, że użytkownik przeczytał dokument, zrozumiał go albo nawet zobaczył jego pełną treść.
W Microsoft 365 w danych audytowych występują między innymi zdarzenia takie jak FileAccessed, FileDownloaded, FileModified i FileUploaded. To dobry przykład tego, jak powinno wyglądać rozdzielanie operacji. Nie wolno jednak zakładać, że każda instalacja DMS oferuje analogiczny poziom szczegółowości.
Przy zakupie albo audycie systemu warto wykonać prosty test zamiast bazować na prezentacji handlowej. Utwórz testowy dokument i wykonaj kolejno:
- podgląd dokumentu w przeglądarce,
- pobranie na komputer,
- zmianę treści,
- zmianę metadanych,
- zmianę uprawnień,
- dostęp z aplikacji mobilnej,
- dostęp przez API,
- operację z konta administracyjnego lub serwisowego.
Potem sprawdź, które z tych ośmiu operacji są rozróżnialne w logach.
Rozbudowana rejestracja zdarzeń ma sens w systemach zawierających dokumenty finansowe, techniczne, HR, dokumentację klientów, umowy, informacje objęte tajemnicą przedsiębiorstwa czy materiały istotne dla ciągłości działania. Nie ma natomiast sensu gromadzenie maksymalnej ilości logów „na wszelki wypadek”, jeżeli organizacja nie ma procedury ich analizy, właściwej retencji ani osób odpowiedzialnych za reakcję.
Log, którego nikt nie potrafi odczytać podczas incydentu, jest bardziej dekoracją audytową niż zabezpieczeniem.
Role i minimalne uprawnienia są ważniejsze niż efektowny panel historii
DMS może prowadzić świetną historię zmian, a mimo to być źle zabezpieczony. Wystarczy, że większość pracowników ma dostęp do całych bibliotek dokumentów albo administrator korzysta na co dzień z konta posiadającego pełne uprawnienia.
Zasada minimalnych uprawnień oznacza, że użytkownik otrzymuje taki zakres dostępu, jaki jest niezbędny do wykonywania jego obowiązków — nie większy.
W praktyce lepiej budować role na podstawie funkcji niż pojedynczych osób. Przykładowo:
- dział księgowości może odczytywać faktury i dodawać dokumenty kosztowe,
- kierownik finansowy może dodatkowo zatwierdzać określone dokumenty,
- dział HR ma dostęp do teczek pracowniczych, ale dział sprzedaży już nie,
- administrator techniczny może utrzymywać platformę, ale nie powinien automatycznie mieć biznesowego prawa do przeglądania każdej umowy,
- konto integracyjne otrzymuje dostęp tylko do repozytorium i operacji potrzebnych konkretnej integracji.
Wyobraźmy sobie firmę produkcyjną, w której system ERP eksportuje faktury do DMS. Integracja potrzebuje zapisywać pliki PDF oraz metadane: numer faktury, kontrahenta i datę. Nadawanie kontu integracyjnemu praw do usuwania dokumentów, zmiany konfiguracji całego repozytorium i odczytu dokumentacji HR byłoby niepotrzebnym rozszerzeniem powierzchni ataku.
Jeżeli później dane uwierzytelniające takiego konta wyciekną, różnica jest zasadnicza. Konto ograniczone do jednej biblioteki pozwala napastnikowi operować na niewielkim zbiorze. Konto z prawami globalnymi może otworzyć drogę do całego DMS.
Drugi problem to spójna tożsamość użytkownika. Log „administrator zmienił dokument” niewiele wyjaśnia, gdy pięciu informatyków zna hasło do wspólnego konta „admin”. Rozliczalność wymaga kont przypisanych do konkretnych osób, a konta serwisowe powinny być wyraźnie oddzielone od kont użytkowników.
W praktycznej ocenie DMS trzeba więc sprawdzić:
- czy użytkownicy mają indywidualne konta,
- czy system współpracuje z centralnym dostawcą tożsamości,
- czy można wymusić MFA tam, gdzie jest to uzasadnione,
- czy role można ograniczyć do konkretnych repozytoriów i operacji,
- czy administratorzy korzystają z odrębnych kont uprzywilejowanych,
- czy zmiana uprawnień pozostawia ślad,
- czy działania kont serwisowych są identyfikowane oddzielnie,
- czy odejście pracownika automatycznie blokuje jego dostęp.
Kiedy rozbudowany model ról nie ma sensu? W małym zespole pięciu osób stworzenie kilkudziesięciu nakładających się profili uprawnień może zwiększyć liczbę błędów zamiast ją zmniejszyć. Nadal jednak trzeba oddzielić przynajmniej zwykłego użytkownika, właściciela obszaru i administratora oraz ograniczyć dostęp do dokumentów szczególnie wrażliwych.
Granica jest prosta: im większe skutki nieuprawnionego dostępu, tym mniej rozsądne jest opieranie bezpieczeństwa na szerokich grupach typu „wszyscy pracownicy”.
Historia dokumentu ma pozwolić odtworzyć incydent, a nie tylko pokazać ostatnią wersję
Historia wersji to nie to samo co ślad audytowy.
Historia wersji odpowiada zwykle na pytania: jaka była poprzednia treść dokumentu, kto zapisał nową wersję i kiedy nastąpiła zmiana. Analiza incydentu wymaga więcej. Trzeba połączyć informacje z DMS, systemu tożsamości, urządzeń końcowych, API, aplikacji integracyjnych, a czasem także zapory sieciowej czy systemu SIEM.
Przykład: o 02:14 konto dyrektora finansowego pobiera 430 dokumentów z repozytorium umów. Sama historia wersji niczego nie pokaże, bo żaden dokument nie został zmieniony. Dopiero log pobrań pozwala zobaczyć skalę operacji. Potem trzeba ustalić, czy konto logowało się z typowego urządzenia, czy wystąpiło nietypowe uwierzytelnienie, czy operacje wykonał użytkownik przez interfejs WWW, czy aplikacja korzystająca z API.
Dobrze przygotowane środowisko powinno umożliwić ułożenie osi czasu podobnej do tej:
- 02:11:34 — logowanie użytkownika,
- 02:12:02 — dostęp do biblioteki „Umowy”,
- 02:13:48 — pierwszy eksport,
- 02:14:03–02:19:51 — seria pobrań,
- 02:20:17 — próba zmiany uprawnień,
- 02:21:05 — alert bezpieczeństwa,
- 02:22:10 — blokada sesji.
Taka chronologia ma wartość tylko wtedy, gdy zegary poszczególnych systemów są zsynchronizowane. Jeżeli DMS zapisuje 02:14, system tożsamości 03:14, a firewall 02:17 z powodu błędnej strefy czasowej albo rozjechanego zegara, analiza zaczyna przypominać układanie puzzli z kilku pudełek.
Dlatego trzeba ustalić jeden sposób interpretacji czasu — w praktyce często przechowywanie zdarzeń w UTC i poprawne prezentowanie ich w lokalnej strefie czasowej — oraz zapewnić synchronizację zegarów.
Drugi problem to retencja. W Microsoft Purview Audit (Standard) typowy okres przechowywania objętych nim danych audytowych wynosi 180 dni. Audit Premium pozwala dla odpowiednio licencjonowanych użytkowników na dłuższą retencję, w tym domyślnie rok dla określonych obciążeń Microsoft 365, a przy dodatkowych warunkach licencyjnych możliwa jest konfiguracja retencji sięgającej 10 lat. To pokazuje praktyczną pułapkę: informacja może być rejestrowana poprawnie, ale w chwili dochodzenia już jej nie będzie.
Dlatego przed ustaleniem polityki retencji trzeba odpowiedzieć na trzy pytania:
Po jakim czasie możemy realnie odkryć incydent?
Jeżeli analiza, zgłoszenie klienta lub audyt potrafią ujawnić problem po ośmiu miesiącach, sześciomiesięczna historia będzie za krótka.
Ile danych generujemy?
Szczegółowe logowanie setek tysięcy operacji dziennie zwiększa koszty przechowywania i analizy.
Które zdarzenia mają największą wartość dowodową?
Pobrania, eksporty, zmiany uprawnień, operacje administratorów i dostęp przez API zwykle zasługują na większą uwagę niż tysiące technicznych odczytów generowanych przez podgląd czy indeksowanie.
Sam DMS również nie powinien być jedynym miejscem przechowywania informacji o własnych zdarzeniach bezpieczeństwa. Jeżeli napastnik zdobędzie uprawnienia administracyjne i będzie mógł skasować historię razem z dokumentami, wartość takiego mechanizmu gwałtownie spada. Przy systemach o istotnym ryzyku sens ma centralne gromadzenie logów, ograniczenie możliwości ich modyfikacji oraz przekazywanie najważniejszych zdarzeń do systemu monitorowania lub SIEM.
Nie trzeba od razu budować rozbudowanego SOC. Najpierw powinny działać alerty dotyczące zdarzeń, które rzeczywiście mogą oznaczać problem, np. masowego pobierania dokumentów, nietypowego eksportu, zmiany uprawnień administracyjnych, działania nieużywanego wcześniej konta serwisowego czy dostępu do dużej liczby poufnych plików w krótkim czasie.
Najbardziej praktyczny test zgodności nie polega więc na zaznaczeniu w ankiecie pola „system posiada logi”. Trzeba przeprowadzić próbę odtworzenia incydentu. Wybierz jeden dokument, wykonaj kontrolowane pobranie, zmianę uprawnień i zmianę treści, a następnie poproś osobę odpowiedzialną za bezpieczeństwo o odtworzenie: kto, co, kiedy i w jaki sposób zrobił. Jeżeli odpowiedź wymaga tygodnia korespondencji z dostawcą DMS albo ręcznego składania informacji z niezsynchronizowanych plików tekstowych, system nie daje jeszcze wystarczającej rozliczalności.
FAQ
Czy NIS2/KSC wymaga zakupu systemu DMS?
Nie. Przepisy wymagają odpowiednich środków technicznych, operacyjnych i organizacyjnych oraz zarządzania ryzykiem. DMS może być jednym z narzędzi realizujących te zadania, ale ustawa nie nakazuje kupowania konkretnej klasy oprogramowania.
Czy firma musi rejestrować każde otwarcie dokumentu?
Nie ma uniwersalnego przepisu KSC nakazującego wszystkim podmiotom zapis każdego otwarcia każdego dokumentu. Zakres rejestrowania powinien wynikać z ryzyka, charakteru systemu, rodzaju informacji oraz potrzeb związanych z wykrywaniem i odtwarzaniem incydentów.
Czy wpis w logu „dokument otwarty” dowodzi, że pracownik przeczytał plik?
Nie. Zdarzenie dostępu może być wygenerowane przez podgląd, synchronizację, prefetch, indeksowanie, integrację, API albo inny proces techniczny. Log potwierdza określone zdarzenie systemowe, a nie stan świadomości użytkownika.
Co sprawdzić w DMS jako pierwsze przed audytem KSC?
Nie zaczynaj od katalogu funkcji producenta. Weź jeden testowy dokument i sprawdź, czy potrafisz odtworzyć jego dostęp, pobranie, eksport, zmianę treści, zmianę metadanych, zmianę uprawnień oraz operacje przez API i konto serwisowe. Następnie sprawdź tożsamość użytkowników, retencję logów, synchronizację czasu i możliwość eksportu zdarzeń do centralnego systemu. Jeśli któregoś z tych elementów nie da się dziś ustalić, właśnie od tej luki należy zacząć — przed zakupem kolejnego narzędzia.
