Jak nie przesadzić z uprawnieniami? - Najmniejszy Wymagany Dostęp w SAP

W świecie systemów ERP, takich jak SAP, kwestia uprawnień użytkowników jest kluczowa - nie tylko dla bezpieczeństwa, ale też dla sprawności działania całej organizacji. A jednak w praktyce często spotyka się sytuacje, w których użytkownicy mają dostęp do znacznie szerszego zestawu funkcji, niż realnie potrzebują. Czasem „na wszelki wypadek”, czasem „bo tak było szybciej”, a czasem po prostu nikt nie zadał sobie trudu, by to sprawdzić. Tymczasem istnieje zasada, która powinna być fundamentem każdej polityki zarządzania dostępami: Zasada Najmniejszego Wymaganego Dostępu (Least Privilege Principle, LPP). W skrócie - użytkownik powinien mieć dokładnie tyle uprawnień, ile potrzebuje do wykonywania swoich obowiązków. Ani mniej, ani więcej. Badanie przeprowadzone wśród 225 organizacji ujawniło, że 85% uprawnień nie było wykorzystywanych przez ostatnie 90 dni, a co trzeci użytkownik miał dostęp do systemów, z których nie korzystał wcale. Te dane nie pozostawiają złudzeń - nadmiarowe dostępy to realny i powszechny problem. Większość użytkowników ma zdecydowanie za szerokie uprawnienia, co nie tylko zwiększa powierzchnię ataku, ale i stanowi ryzyko audytowe.  

Dlaczego to naprawdę ma znaczenie?

Zasada LPP to nie tylko zdrowy rozsądek - to jeden z filarów bezpieczeństwa informacji i zgodności z regulacjami. Zbyt szerokie uprawnienia mogą skutkować:

• nadużyciami finansowymi lub manipulacją danymi,
• przypadkowymi błędami, które zakłócają procesy lub powodują utratę danych,
• naruszeniem zasady rozdziału obowiązków (SoD),
• niezgodnością z przepisami, takimi jak RODO czy SOX,
• trudniejszymi audytami i większym polem do cyberataków.

 

Historie z życia, czyli jak to wygląda w praktyce.

Przyjrzyjmy się kilku przykładom niestosowania zasady Najmniejszego Wymaganego Dostępu: Przykład 1: Pracownik księgowości z pełnym dostępem do cyklu fakturowania Osoba w dziale finansowym miała dostęp do wszystkich transakcji w cyklu fakturowania: od wprowadzania faktur przychodzących (MIRO), przez księgowanie dokumentów (FB60), aż po zatwierdzanie płatności (F110). Ryzyko: Pracownik mógł samodzielnie przeprowadzić cały proces - od stworzenia dokumentu po realizację przelewu. Taki dostęp łamie zasadę rozdziału obowiązków i znacząco utrudnia późniejsze ustalenie, kto był odpowiedzialny za co. Rozwiązanie: Ograniczyć dostęp do jednej roli - np. tylko MIRO lub tylko FB60 - i przypisać zatwierdzanie płatności innemu użytkownikowi. Warto wdrożyć workflow i jasno zdefiniować właścicieli poszczególnych etapów procesu. Przykład 2: Pracownik w dziale zakupów z dostępem do warunków sprzedaży Pracownik działu zakupów miał nie tylko dostęp do zamówień (ME21N, ME22N), ale też do warunków cenowych sprzedaży (VK11). Problem w tym, że te dane nie były mu potrzebne, a ich edycja mogła mieć strategiczne konsekwencje. Ryzyko: Nieautoryzowana zmiana polityki cenowej - przypadkowa lub celowa. Rozwiązanie: Wyraźne rozdzielenie ról zakupowych i sprzedażowych oraz ograniczenie dostępu do danych tylko w ramach odpowiednich jednostek. Przykład 3: Pracownik po zmianie stanowiska Po przejściu z magazynu do działu kontrolingu, pracownik zachował stare uprawnienia i otrzymał nowe. Efekt? Jednoczesny dostęp do dokumentów magazynowych i danych kosztowych. Ryzyko: Nadmiarowy dostęp do procesów spoza obecnych obowiązków, potencjalne konflikty SoD. Rozwiązanie: Każda zmiana stanowiska powinna wiązać się z pełnym przeglądem uprawnień - nie tylko dodaniem nowych ról, ale również odebraniem zbędnych. Te przykłady pokazują, jak łatwo w praktyce dochodzi do nadania zbyt szerokich uprawnień - często w wyniku pośpiechu, braku przeglądu lub nieprzemyślanego łączenia ról. Każdy z opisanych przypadków uświadamia, że nawet pozornie drobne zaniedbania mogą prowadzić do poważnych ryzyk, które można łatwo wyeliminować, stosując zasadę LPP.

Jak działać zgodnie z zasadą LPP?

Stosowanie zasady Najmniejszego Wymaganego Dostępu wymaga nie tylko świadomości ryzyk, ale też konkretnych działań organizacyjnych i technicznych - najlepiej wdrażanych systematycznie i z myślą o długofalowym bezpieczeństwie. Oto kilka sugestii:

• Twórz role biznesowe dopasowane do faktycznego zakresu obowiązków - bez zbędnych transakcji.
• Ustalaj pola organizacyjne i ograniczaj zakres danych (np. do konkretnej spółki lub magazynu).
• Stosuj przemyślane procesy zatwierdzania i przeglądu uprawnień - zwłaszcza przy zmianie ról lub stanowisk.
• Weryfikuj konflikty SoD przed przyznaniem dostępu.
• Recertyfikuj uprawnienia regularnie, np. co 6 lub 12 miesięcy.
• Wspieraj się narzędziami SAP, takimi jak GRC Access Control, SUIM, ST03N czy logi transakcji.

A jeśli chcesz naprawdę uporządkować temat dostępów, warto sięgnąć po dedykowane rozwiązania, takie jak smartGRC  (https://smartgrc.pl/). Dzięki nim można m.in.:

• prowadzić cykliczne przeglądy okresowe uprawnień,
• wdrożyć workflow do nadawania i zatwierdzania dostępów,
• zarządzać bazą ryzyk SoD, co zdecydowanie ułatwia kontrolę i poprawia bezpieczeństwo systemu.

 

LPP a wygoda pracy użytkownika

Często spotykanym mitem jest przekonanie, że ograniczanie uprawnień pogarsza komfort pracy. W rzeczywistości jest dokładnie odwrotnie. Dobrze zaprojektowane role - zgodne z zakresem obowiązków i oczyszczone z nadmiarowych transakcji - sprawiają, że użytkownicy:

• szybciej odnajdują potrzebne funkcje,
• nie są przytłoczeni zbędnymi opcjami w interfejsie,
• rzadziej popełniają błędy wynikające z przypadkowego kliknięcia „nie tego, co trzeba”.

Zasada Najmniejszego Wymaganego Dostępu poprawia więc nie tylko bezpieczeństwo, ale też użyteczność systemu SAP. To czystszy, bardziej przejrzysty interfejs - a więc lepsze doświadczenie dla użytkownika końcowego.  

LPP a regulacje i standardy bezpieczeństwa

Warto też pamiętać, że zasada Najmniejszego Wymaganego Dostępu nie jest jedynie dobrą praktyką - to jeden z formalnych wymogów wielu międzynarodowych standardów i regulacji dotyczących bezpieczeństwa informacji i ochrony danych. Oto kilka przykładów:

• ISO/IEC 27001 - wymaga kontrolowania dostępu do zasobów na zasadzie potrzeby biznesowej.
• NIST SP 800-53 - wskazuje zasadę least privilege jako podstawowy mechanizm ochrony systemów informatycznych.
• RODO/GDPR - nakłada obowiązek ograniczenia dostępu do danych osobowych tylko do osób, które go rzeczywiście potrzebują (zasada minimalizacji).
• SOX (Sarbanes-Oxley Act) - wymaga kontroli dostępu w kontekście integralności sprawozdań finansowych.

Przestrzeganie zasady LPP pomaga zatem nie tylko zminimalizować ryzyka operacyjne, ale również utrzymać zgodność z obowiązującymi przepisami i normami, co może mieć kluczowe znaczenie w trakcie audytów i kontroli zewnętrznych.  

Co zyskujesz, stosując LPP?

Wdrażanie zasady Najmniejszego Wymaganego Dostępu to nie tylko zgodność z przepisami i bezpieczeństwo. To także szereg konkretnych korzyści:

• Mniej problemów przy audytach - dzięki lepszej kontroli nad dostępami.
• Szybsze i bardziej przejrzyste kontrole - uporządkowane role to mniej wyjątków do tłumaczenia.
• Niższe koszty zarządzania dostępami - mniej ról do utrzymania, mniej zgłoszeń do IT.
• Większa przejrzystość odpowiedzialności - wiadomo, kto za co odpowiada.
• Mniej błędów użytkowników - bo mają dostęp tylko do tego, co naprawdę potrzebne.
• „Czystszy” system SAP - bez przerośniętych ról i historycznych uprawnień.

 

Na koniec - zdrowy rozsądek jako standard

Zasada Najmniejszego Wymaganego Dostępu to nie przesadna ostrożność, ale profesjonalne podejście do bezpieczeństwa w SAP. Chroni nie tylko dane i procesy, ale też reputację organizacji. Dlatego warto poświęcić chwilę, by zastanowić się: czy ten dostęp jest naprawdę potrzebny? Jeśli nie - to właśnie idealny moment, żeby go ograniczyć. Źródła:

1. Cloud Security Alliance. (2024). Mastering Least Privilege: Cutting Unused Access Without Cutting Corners. Pobrano z https://cloudsecurityalliance.org/blog/2024/05/30/mastering-least-privilege-cutting-unused-access
2. (b.d.). What is Least Privilege? Pobrano z https://www.cyberark.com/what-is/least-privilege/
3. Edwards, M. (2025). Annex A.5.3: Segregation of Duties. online. Pobrano z https://www.isms.online/iso-27001/annex-a/5-3-segregation-of-duties-2022/
4. National Institute of Standards and Technology (NIST). (b.d.). Least privilege. Pobrano z https://csrc.nist.gov/glossary/term/least_privilege
5. (2024). Secure SAP with Effective Access Governance. Pobrano z https://www.safepaas.com/articles/secure-sap-with-effective-access-governance/
6. (2025). Access certification: An ultimate guide. Zluri. Pobrano z https://www.zluri.com/blog/access-certification
7. (2024). Oficjalna strona produktu smartGRC. Pobrano z https://smartgrc.pl/