Administrator DMS, który potrafi zmienić konfigurację systemu, nie musi automatycznie czytać umów zarządu, dokumentacji pracowniczej, ofert przetargowych czy akt postępowań prawnych. To dwie różne kompetencje. Prawo do administrowania platformą nie powinno oznaczać biznesowego prawa do treści dokumentów.
Problem zaczyna się wtedy, gdy organizacja tworzy jedno konto „admin”, daje mu pełne prawa „na wszelki wypadek” i zostawia taki dostęp przez lata. Taki model jest wygodny dla IT, ale bardzo słaby z punktu widzenia bezpieczeństwa. Przejęcie jednego konta może wtedy otworzyć dostęp do całego repozytorium, a późniejsze ustalenie, kto faktycznie przeglądał dokumenty, staje się trudne albo niemożliwe.
Nie oznacza to jednak, że da się po prostu zagwarantować: „administrator techniczny nigdy nie może odczytać dokumentu”. Jeżeli jedna osoba kontroluje aplikację, bazę danych, storage, kopie zapasowe i klucze szyfrujące albo może samodzielnie nadać sobie takie prawa, pozostaje wobec niej techniczne zaufanie. Sensowna architektura polega więc nie na składaniu absolutnych obietnic, lecz na ograniczaniu tego zaufania, rozdzielaniu kompetencji i pozostawianiu śladów każdej operacji uprzywilejowanej.
Administrator platformy to nie właściciel dokumentów
Pierwsza zmiana powinna nastąpić w modelu ról. W wielu firmach administrator DMS jest jednocześnie administratorem użytkowników, repozytoriów, konfiguracji, bezpieczeństwa i treści. To za szeroki zakres.
Praktyczny podział wygląda inaczej:
- administrator platformy utrzymuje usługę, konfigurację, integracje, aktualizacje i dostępność;
- administrator tożsamości i uprawnień zarządza kontami i rolami;
- właściciel repozytorium lub obszaru biznesowego decyduje, kto może czytać dokumenty działu;
- administrator bezpieczeństwa lub audytor kontroluje logi i zdarzenia;
- operator backupu wykonuje kopie i odtworzenia, ale nie powinien automatycznie uzyskiwać prawa do przeglądania zawartości;
- konta aplikacyjne i serwisowe dostają tylko uprawnienia potrzebne konkretnemu procesowi.
To rozdzielenie ma znaczenie również w popularnych usługach chmurowych. W SharePoint Online rola SharePoint Administrator nie daje automatycznie dostępu do treści wszystkich witryn i OneDrive’ów. Administrator może jednak nadać sobie dostęp do wybranej witryny. To dobrze pokazuje różnicę między brakiem stałego prawa odczytu a brakiem technicznej możliwości uzyskania dostępu.
Załóżmy, że dział prawny przechowuje w DMS dokumentację transakcji M&A. Administrator systemu musi móc zwiększyć limit przestrzeni, naprawić workflow i sprawdzić konfigurację integracji. Nie potrzebuje do tego prawa „odczytaj wszystkie pliki”.
Jeżeli pojawia się awaria dotycząca konkretnego dokumentu, administrator może dostać czasowy dostęp do jednej przestrzeni lub jednego zestawu danych. Właściciel obszaru prawnego zatwierdza operację, a po jej zakończeniu uprawnienie znika.
RBAC, czyli Role-Based Access Control, nadaje prawa na podstawie roli. Przykładowo „administrator DMS” może zarządzać konfiguracją, a „HR Manager” odczytywać akta pracownicze.
ABAC, czyli Attribute-Based Access Control, pozwala uwzględnić dodatkowe warunki: dział, klasyfikację dokumentu, lokalizację użytkownika, urządzenie, poziom poufności czy etap procesu. Jest bardziej elastyczny, ale także trudniejszy w utrzymaniu.
RBAC ma sens, gdy organizacja ma stabilne i czytelne role. ABAC przydaje się tam, gdzie dostęp zależy od wielu warunków. Nie warto natomiast budować kilkuset mikro-ról tylko po to, żeby odwzorować każdy możliwy wyjątek. Po kilku miesiącach nikt nie będzie wiedział, dlaczego użytkownik ma pięć podobnych ról.
Najważniejsze kryterium jest prostsze: czy administrator potrzebuje danej informacji do wykonania swojej pracy, czy jedynie technicznej możliwości zarządzania systemem? Jeżeli wystarcza zarządzanie platformą, nie należy dodawać prawa odczytu treści.
Trzeba przy tym uważać na „ukryte” ścieżki dostępu. Model zagrożeń powinien obejmować nie tylko interfejs DMS, ale również:
- storage obiektowy lub udział plikowy;
- bazę danych;
- wyszukiwarkę i indeks pełnotekstowy;
- cache;
- system OCR;
- eksporty;
- API;
- kopie zapasowe;
- środowiska testowe zawierające kopię produkcji;
- klucze szyfrujące;
- konta serwisowe i integracyjne;
- procedurę restore.
Jeżeli dokument jest zablokowany w aplikacji, ale administrator bazy może wykonać zapytanie bezpośrednio do tabeli zawierającej jego treść, kontrola na poziomie DMS jest tylko częściowa.
Podobnie z backupem. Operator, który może skopiować backup do własnego środowiska, odtworzyć bazę oraz uzyskać klucz szyfrujący, może ominąć kontrolę aplikacji. Backup i restore należy więc traktować jako uprzywilejowane operacje, a nie neutralną czynność techniczną.
Stałe konto administratora zastąp dostępem na żądanie
Największym błędem nie jest samo istnienie wysokich uprawnień. Problemem jest ich stała dostępność.
Administrator, który przez 24 godziny na dobę może wejść do każdego obszaru, pozostaje wartościowym celem dla phishingu, kradzieży tokenów sesyjnych czy przejęcia urządzenia. Model Just-in-Time zmienia sytuację: użytkownik na co dzień nie posiada aktywnych uprawnień uprzywilejowanych, lecz uruchamia je dopiero wtedy, gdy wykonuje konkretną operację.
Dobry proces JIT powinien zawierać co najmniej:
- imienne konto administratora zamiast wspólnego „admin”;
- wskazanie potrzebnej roli;
- określenie zasobu lub repozytorium;
- podanie uzasadnienia;
- określenie czasu dostępu;
- MFA przy aktywacji;
- niezależną akceptację dla najbardziej wrażliwych operacji;
- automatyczne wygaśnięcie;
- powiadomienie o uruchomieniu roli;
- zapis operacji w audycie;
- okresowy review listy osób uprawnionych do aktywacji.
Nie każdy dostęp musi przechodzić przez wieloetapową akceptację. Jeżeli administrator restartuje usługę indeksowania i nie otrzymuje dostępu do poufnych danych, wymaganie zgody dyrektora bezpieczeństwa za każdym razem może tylko blokować pracę.
Inaczej wygląda sytuacja, kiedy ktoś chce aktywować prawo umożliwiające przejęcie administracji nad repozytorium zarządu lub dostęp do kluczy kryptograficznych. Tutaj zasada czterech oczu jest uzasadniona: osoba wnioskująca nie powinna samodzielnie zatwierdzać własnego podniesienia uprawnień.
W Microsoft Entra Privileged Identity Management można konfigurować między innymi MFA, uzasadnienie, akceptację oraz maksymalny czas aktywacji. Dla ról Microsoft Entra zakres konfiguracji maksymalnej aktywacji wynosi od 1 do 24 godzin. Narzędzie pozwala również stosować role kwalifikowane, które użytkownik aktywuje dopiero na czas pracy.
To dobry mechanizm, ale nie jest bezkosztowym dodatkiem do każdego środowiska Microsoft 365. Według dokumentacji obowiązującej w październiku 2026 r. pełne użycie PIM wymaga Microsoft Entra ID P2 albo Microsoft Entra ID Governance dla odpowiednich użytkowników. Trzeba więc sprawdzić faktyczny plan licencyjny, a nie zakładać, że obecność Entra ID automatycznie daje wszystkie funkcje PIM.
Jeszcze ważniejsze: PIM nie naprawia złej architektury DMS. Jeżeli aktywacja roli Global Administratora umożliwia administratorowi samodzielne nadanie sobie innych praw, organizacja nadal musi zdecydować, kto może aktywować właśnie tę rolę, kto to zatwierdza i co dzieje się później.
W praktyce dobrym punktem wyjścia dla typowych interwencji jest dostęp na 1–4 godziny, nie cały dzień roboczy. Dłuższy czas ma sens przy migracji, dużym maintenance window lub zaplanowanym wdrożeniu. Nie należy jednak zamieniać JIT w fikcję poprzez automatyczne przyznawanie ośmiogodzinnej roli administratora każdego ranka.
Osobny przypadek to break-glass, czyli dostęp awaryjny.
Awaria o 2:00 w nocy nie może czekać czterech godzin na akceptację osoby, która nie odbiera telefonu. Dlatego organizacja potrzebuje ścieżki awaryjnej, ale dostęp awaryjny nie powinien działać jak boczne wejście bez monitoringu.
Dobra procedura break-glass obejmuje:
- jednoznacznie oznaczone konto lub mechanizm awaryjny;
- silne uwierzytelnienie;
- ograniczenie liczby osób posiadających możliwość użycia;
- natychmiastowy alarm po aktywacji;
- obowiązkowe uzasadnienie;
- zapis operacji;
- możliwie krótki czas aktywnego dostępu;
- obowiązkowy przegląd po zdarzeniu.
Nie należy projektować awaryjnego procesu tak restrykcyjnie, że w czasie rzeczywistego incydentu nikt nie może odzyskać działania systemu. Bezpieczeństwo, które uniemożliwia przywrócenie DMS po awarii, samo staje się ryzykiem.
Log powinien pokazać nie tylko logowanie, ale dostęp do poufnego dokumentu
Samo zapisanie informacji „administrator zalogował się o 11:42” niewiele mówi. Jeśli sześć minut później wyeksportowano 120 plików z repozytorium HR, system powinien pozwolić połączyć te zdarzenia.
Dla dokumentów oznaczonych jako poufne warto rejestrować co najmniej:
- kto wykonał operację;
- z jakiego konta i typu sesji;
- kiedy;
- jaki dokument lub zbiór dokumentów został objęty operacją;
- czy było to wyświetlenie, pobranie, eksport, zmiana uprawnień czy usunięcie;
- jaką rolę administrator miał w tym momencie;
- czy rola była stała, czy aktywowana czasowo;
- numer zgłoszenia lub uzasadnienie dostępu;
- kto zatwierdził podniesienie uprawnień;
- z jakiego urządzenia lub źródła wykonano operację, o ile system dostarcza takie dane;
- rezultat operacji.
W środowisku Microsoft 365 konkretne operacje na SharePoint i OneDrive mogą trafiać do dziennika Microsoft Purview Audit. Rejestrowane są między innymi zdarzenia związane z dostępem do plików i udostępnianiem. Trzeba jednak sprawdzić dokumentację konkretnego zdarzenia i usługi — samo stwierdzenie, że „mamy audyt Microsoft 365”, nie gwarantuje zapisania każdej operacji istotnej dla danego DMS.
Istotny jest także czas przechowywania. Audit Standard przechowuje obecnie dane audytowe standardowo przez 180 dni. W Audit Premium część zdarzeń Microsoft Entra, Exchange, OneDrive i SharePoint może być domyślnie przechowywana przez rok dla odpowiednio licencjonowanych użytkowników. Dłuższa retencja, w tym rozwiązania sięgające 10 lat, wymaga odpowiednich dodatków i polityk.
To nie jest detal. Jeżeli organizacja wykrywa problem po dziewięciu miesiącach, sześciomiesięczny dziennik nie odpowie już na pytanie, kto otworzył dokument.
Dlatego dla szczególnie ważnych systemów sensowne jest wysyłanie logów poza sam DMS — do SIEM, niezależnego repozytorium audytowego albo pamięci objętej polityką niezmienności. Administrator aplikacji nie powinien móc po cichu wyczyścić zarówno dokumentu, jak i jedynego śladu po jego odczycie.
Microsoft udostępnia między innymi Office 365 Management Activity API do pobierania zdarzeń dotyczących działań użytkowników i administratorów. Azure Storage oferuje z kolei mechanizmy immutable storage/WORM, w których obiekty objęte właściwą polityką nie mogą być dowolnie zmieniane lub kasowane w okresie retencji. To przykłady klocków, z których można zbudować niezależniejszą ścieżkę audytową. Nie każdy DMS ma jednak analogiczne API i nie każdy system pozwala rejestrować odczyt pojedynczego dokumentu.
Następny poziom separacji dotyczy kluczy szyfrujących.
Dobrze skonfigurowany system może oddzielić administrację infrastrukturą od używania kluczy. Azure Key Vault rozróżnia między innymi control plane — zarządzanie samym zasobem — i data plane, czyli operacje na kluczach, sekretach i certyfikatach. Pozwala to przyznać administratorowi prawo do części czynności technicznych bez automatycznego prawa używania wszystkich sekretów.
Nie można jednak na tej podstawie napisać, że administrator „na pewno nie odczyta danych”. Microsoft wprost zwraca uwagę, że użytkownik mający odpowiednio szerokie uprawnienia do warstwy zarządzania może w określonych konfiguracjach nadać sobie dostęp do data plane. Dlatego administrator subskrypcji, administrator ról i administrator kluczy również muszą zostać objęci modelem uprzywilejowanego dostępu.
Dla najbardziej wrażliwych informacji można pójść dalej i rozdzielić klucze pomiędzy różne domeny zaufania. Przykładem jest Microsoft Purview Double Key Encryption, gdzie do odszyfrowania chronionej treści wymagane są dwa klucze, a jeden pozostaje pod kontrolą organizacji. Taki model jest przeznaczony do specjalnych przypadków bardzo wrażliwych danych, a nie do całego firmowego DMS. Zwiększa kontrolę, ale również koszt operacyjny, wymagania infrastrukturalne i ryzyko problemów z dostępnością.
Nie warto więc zaczynać projektu od najbardziej skomplikowanej kryptografii. Najpierw usuwa się stałe nadmiarowe prawa, później porządkuje role i JIT, następnie audyt, a dopiero potem ocenia, czy niezależne klucze rzeczywiście rozwiązują istotne ryzyko.
Przykład z praktyki: administrator otrzymuje zgłoszenie, że prezes nie może otworzyć zaszyfrowanego dokumentu. W słabym modelu admin ma stały dostęp do całej przestrzeni zarządu i sam testuje dokument na swoim koncie. W lepszym modelu najpierw diagnozuje konfigurację bez dostępu do treści. Jeżeli to nie wystarcza, aktywuje czasową rolę dla konkretnego repozytorium. Wniosek zawiera numer zgłoszenia, dostęp zatwierdza inna osoba, MFA jest wymagane, a po dwóch godzinach rola wygasa. Odczyt i eksport zostają zapisane poza samą aplikacją.
To samo powinno dotyczyć eksportu. „Może czytać” i „może wynieść 40 GB dokumentów” to nie jest ten sam poziom ryzyka. DMS powinien, jeśli technicznie jest to możliwe, rozdzielać podgląd, pobieranie, masowy eksport i administrację prawami.
Jeżeli platforma nie umożliwia takiej granulacji, trzeba to potraktować jako ograniczenie produktu, a nie próbować opisać konfigurację jako bardziej bezpieczną, niż jest naprawdę. W takiej sytuacji można ograniczać ryzyko przez JIT, monitoring, segmentację administracji, MFA, kontrolę urządzeń i niezależne logowanie, ale technicznej cechy systemu nie da się zastąpić polityką organizacyjną.
FAQ
Czy administrator DMS powinien mieć stały dostęp do wszystkich dokumentów?
Nie. Stałe prawo odczytu powinno istnieć tylko wtedy, gdy rzeczywiście wynika z obowiązków danej osoby. Zarządzanie konfiguracją DMS samo w sobie nie uzasadnia dostępu do dokumentów HR, prawnych czy zarządu.
Czy da się zagwarantować, że administrator techniczny nigdy nie odczyta dokumentów?
Nie zawsze. Jeżeli jedna osoba kontroluje aplikację, bazę, storage, backup oraz klucze albo może samodzielnie nadać sobie takie prawa, pozostaje techniczna możliwość dostępu. Celem jest rozdzielenie kompetencji, ograniczenie stałych uprawnień oraz uczynienie każdego nadzwyczajnego dostępu widocznym i rozliczalnym.
Jak długo administrator powinien dostawać podwyższone uprawnienia?
Tylko na czas potrzebny do konkretnego zadania. Dla zwykłych interwencji technicznych rozsądnym punktem startowym jest 1–4 godziny. Migracje i zaplanowane prace mogą wymagać dłuższego okna. Ważniejsze od arbitralnego limitu jest automatyczne wygaśnięcie uprawnień po zakończeniu operacji.
Co sprawdzić najpierw w istniejącym DMS?
Najpierw wyeksportuj listę wszystkich kont mających stałe uprawnienia administracyjne i odpowiedz przy każdym z nich na trzy pytania: czy konto jest imienne, czy pozwala czytać dokumenty oraz czy właściciel biznesowy nadal akceptuje taki zakres. Następnie sprawdź administratorów storage, bazy, backupu i kluczy — audyt samej aplikacji nie wystarczy. Pierwszym błędem do usunięcia są wspólne i stale aktywne konta typu „admin” z pełnym dostępem. Dopiero po ich rozdzieleniu ma sens wdrażanie JIT, dodatkowych workflow akceptacji czy bardziej zaawansowanej architektury kluczy.
