Konta i dostępy w oprogramowaniu firmowym: role, uwierzytelnianie i rozliczanie miejsc

Konta i dostępy w firmowym oprogramowaniu — od ERP do SaaS

Konto w firmowym oprogramowaniu to nie tylko login i hasło, ale brama do danych i procesów. Dopóki ktoś ma aktywne konto z odpowiednimi uprawnieniami, może czytać, zmieniać i eksportować informacje, na których opiera się działalność firmy. W systemach ERP praca odbywa się na jednej bazie, co — jak opisuje Comarch — sprawia, że dane wprowadzone w jednym obszarze, np. w handlu, są natychmiast widoczne dla innych użytkowników: zarządzającego produkcją, księgowości czy magazynu. Błędnie nadany dostęp ma więc skutki natychmiastowe i obejmuje całą organizację.

Warto rozróżnić trzy pojęcia, które w praktyce bywają mylone. Konto to tożsamość konkretnej osoby w systemie: identyfikator, dane logowania, status aktywny lub nieaktywny. Rola to przypisany do konta zestaw uprawnień — widoki, formularze, akcje i obszary danych, do których użytkownik ma wgląd. Licencja lub miejsce to jednostka rozliczeniowa wobec dostawcy: jedno płatne stanowisko, którego przypisanie do konta decyduje o koszcie. Porządek wymaga zarządzania wszystkimi trzema warstwami naraz, bo samo posiadanie konta nie mówi, co dana osoba może zrobić ani ile firma za to płaci.

Kontekst techniczny zależy od modelu usługi. W publikacjach o bezpieczeństwie chmury wyróżnia się IaaS (infrastruktura jako usługa, czyli zapewnianie sprzętu), PaaS (platforma jako usługa) oraz SaaS (oprogramowanie jako usługa, czyli dostęp do gotowych aplikacji). Z perspektywy kont i dostępów największe znaczenie ma SaaS: użytkownik nie administruje serwerem, a mimo to odpowiada za konfigurację kont, udostępnianie danych i rozliczanie miejsc w aplikacji dostawcy. Każdy z tych modeli powinien zostać uwzględniony w analizie ryzyka organizacji.

Odpowiedzialność za dostępy pozostaje po stronie firmy niezależnie od tego, kto hostuje oprogramowanie. Administrator danych odpowiada za bezpieczeństwo także wtedy, gdy korzysta z usług zewnętrznego dostawcy. RODO nakłada obowiązek zawarcia umowy precyzującej przedmiot, charakter, cel i czas przetwarzania danych oraz regularnego testowania skuteczności wdrożonych środków technicznych i zdolności szybkiego przywrócenia dostępności danych w razie incydentu.

Role i uprawnienia: kto naprawdę potrzebuje dostępu

W większości systemów klasy ERP i w aplikacjach SaaS można wyróżnić kilka podstawowych typów ról. Administrator zarządza kontami, rolami i konfiguracją systemu, ale niekoniecznie musi mieć dostęp do wszystkich danych merytorycznych. Użytkownik końcowy pracuje na dokumentach i danych w swoim obszarze — sprzedaży, księgowości, magazynie, kadrach czy produkcji. Konsultant lub zewnętrzny dział IT odpowiada za rozbudowę i utrzymanie systemu. Programista ingeruje w najbardziej techniczne warstwy rozwiązania. Rozdzielenie tych ról to pierwszy krok do kontroli nad tym, kto co widzi i co może zmienić.

Dobrym przykładem praktycznego podziału jest sposób opisania architektury systemu ERP w materiałach Vendo.ERP. Użytkownicy systemu mogą dostosowywać wygląd i funkcje do własnych potrzeb — zmieniać wygląd list, zakładek czy formularzy, co jest powiązane z posiadanymi uprawnieniami. Konsultanci lub zewnętrzny dział IT zajmują się rozbudową systemu: dodatkowymi wtyczkami, tworzeniem własnych pól, zmianą uprawnień i ustawianiem wydruków. Część zadań zastrzeżona jest wyłącznie dla programistów dostawcy. Taki układ pokazuje, że uprawnienia nie są jedną flagą „dostęp do ERP”, lecz zbiorem warstw o różnym zakresie odpowiedzialności.

Podstawową zasadą ich nadawania jest minimalny dostęp: użytkownik powinien otrzymać dokładnie te uprawnienia, które są niezbędne do wykonywania jego zadań, i nie więcej. W praktyce oznacza to kilka pytań przy każdym wniosku: do jakich danych ma trafić dana osoba, jakie operacje ma wykonywać (odczyt, edycja, zatwierdzanie, eksport, usuwanie) oraz czy dana czynność nie powinna być rozdzielona pomiędzy dwie osoby. Szczególnie ostrożnie warto podchodzić do uprawnień do eksportu danych, masowej edycji oraz zatwierdzania dokumentów finansowych.

Konfiguracja widoków i funkcji zależnie od roli to nie tylko kwestia bezpieczeństwa, ale i ergonomii. Rolę można zbudować tak, aby użytkownik widział wyłącznie potrzebne menu, formularze i pola, a zbędne akcje były dla niego niewidoczne lub nieaktywne. Ograniczenia warto nakładać na poziomie operacji, a nie tylko wyglądu — ukrycie przycisku nie jest zabezpieczeniem, jeśli czynność można wykonać inną ścieżką. Warto też unikać kont współdzielonych i „kont tymczasowych”, które zostają w systemie na stałe, oraz traktować konto administratora jako wyjątek używany świadomie i tylko wtedy, gdy jest naprawdę potrzebne.

Uwierzytelnianie: hasło to za mało

Uwierzytelnianie dwuskładnikowe (2FA) wzmacnia bezpieczeństwo konta, wymagając dwóch form weryfikacji tożsamości. Jak opisuje Microsoft, pomaga zapobiegać nieautoryzowanemu dostępowi, zmniejsza ryzyko naruszeń i wspiera zgodność między systemami i użytkownikami. Do popularnych metod drugiego składnika Microsoft zalicza powiadomienia push w aplikacji mobilnej z zatwierdzeniem, kody SMS, dane biometryczne oraz fizyczne klucze bezpieczeństwa. Sama długość i złożoność hasła nie wystarcza, gdy to samo hasło zostanie użyte gdzie indziej lub padnie ofiarą phishingu.

Rozwiązania MFA oferują szeroki wachlarz metod i to administrator decyduje, które z nich są dostępne dla użytkowników. W opisie produktu Rublon MFA wymieniane są między innymi: aplikacja mobilna generująca nowy mobilny kod dostępu co 30 sekund (również w trybie offline), oparta na algorytmie haseł jednorazowych zależnych od czasu (TOTP); powiadomienie mobilne (push) zatwierdzane jednym dotknięciem; jednorazowe kody wysyłane SMS-em, niewymagające smartfona ani połączenia z internetem; link e-mail, który nie wymaga instalacji dodatkowego oprogramowania ani sprzętu; kod QR skanowany telefonem z aplikacją uwierzytelniającą; klucze YubiKey OTP oraz rozwiązanie zgodne ze standardem FIDO2, pozwalające logować się przez dotknięcie fizycznego klucza bezpieczeństwa FIDO2/U2F lub użycie klucza dostępu FIDO2 passkey.

Osobnym, praktycznym elementem są kody pomijania (bypass code). Administratorzy mogą generować kody o ograniczonej liczbie użyć i ograniczonym czasie ważności, które przydają się w sytuacjach, gdy użytkownik zgubił swoje urządzenie. Bez takiego mechanizmu codziennym obejściem polityki bezpieczeństwa staje się telefoniczne „wyłączanie 2FA” dla każdego, kto zgubi telefon — a to właśnie wtedy powstaje największe ryzyko.

Dobór metod warto podporządkować odporności na phishing i przejęcie konta. Metody oparte na fizycznym kluczu lub kluczu dostępu są znacznie trudniejsze do przechwycenia przez fałszywą stronę logowania niż kody, które użytkownik przepisuje z wiadomości SMS lub z komunikatu aplikacji — dlatego w systemach o wysokiej stawce (finanse, kadry, administracja) warto rozważać właśnie je. Niezależnie od wybranej metody kluczowe jest konsekwentne wymuszanie drugiego składnika dla wszystkich kont z dostępem do danych, a nie tylko dla wybranych użytkowników.

Wagę tego zagadnienia pokazuje praktyka organu nadzorczego. W decyzji UODO z maja 2024 roku (DKN.5112.35.2021), dotyczącej incydentu w środowisku chmurowym, złamanie zabezpieczeń platformy chmurowej wskazano jako potencjalny wektor ataku, a w uzasadnieniu podkreślono, że użytkownicy systemu stosowali słabe hasła oraz że wystąpiła błędna konfiguracja domeny.

Metody uwierzytelniania dwuskładnikowego (2FA)

Priorytetowe metody 2FA według odporności na phishing

Dostępy w chmurze: pliki, udostępnianie i odzyskiwanie

W firmowych kontach chmurowych dostęp do plików wymaga własnych zasad, wykraczających poza samo logowanie. Warto zdecydować, kto może tworzyć nowe przestrzenie i foldery, komu wolno udostępniać pliki na zewnątrz organizacji, a kiedy udostępnienie wymaga zatwierdzenia. Dobrą praktyką jest nadawanie dostępów grupowych zamiast indywidualnych — łatwiej je potem przeglądać i odbierać — oraz stosowanie linków z ograniczonym czasem ważności i ograniczeniem do konkretnych odbiorców. Należy też regularnie przeglądać listę osób spoza firmy, które mają dostęp do materiałów wewnętrznych.

Drugim filarem jest walka z phishingiem w codziennej pracy zespołu. Skuteczne podejście opiera się na prostych nawykach: sprawdzaniu adresu nadawcy i domeny, ostrożności wobec nieoczekiwanych załączników i linków, niepodawaniu danych logowania w formularzach, do których prowadzi wiadomość, oraz jasnej ścieżce zgłaszania podejrzanych maili do działu IT lub bezpieczeństwa. Ważne, aby zespół wiedział, że zgłoszenie fałszywej wiadomości jest zachowaniem pożądanym, a nie „przeszkadzaniem”. W opracowaniach o bezpieczeństwie kont chmurowych walka z mailami phishingowymi i przywracanie usuniętych wiadomości wymieniane są obok zarządzania dostępem do plików jako elementy tej samej polityki.

Trzeci element to umiejętność odwrócenia skutków błędu lub ataku. Usunięcie wiadomości czy pliku przez użytkownika — czasem w wyniku celowego działania osoby, która przejęła konto — nie powinno być nieodwracalne. Warto znać i mieć opisaną procedurę korzystania z kosza i panelu administratora do przywracania usuniętych wiadomości oraz ustalić, jak długo przechowywane są kopie. Właściwie skonfigurowane mechanizmy odzyskiwania są częścią tego samego wymogu, który RODO wiąże z art. 32: zdolności szybkiego przywrócenia dostępności danych osobowych w przypadku incydentu, obok regularnego testowania skuteczności wdrożonych środków technicznych.

Nie mniej istotna jest relacja z dostawcą usługi chmurowej. Przed powierzeniem danych warto zweryfikować podmiot przetwarzający pod kątem gwarancji wdrożenia odpowiednich środków technicznych i organizacyjnych — wieloletnia współpraca nie jest bowiem, jak wskazał UODO, sama w sobie gwarantem bezpiecznego świadczenia usług. W sprawie zakończonej karą 4,9 mln złotych dla Fortum Marketing oraz 250 tys. złotych dla podmiotu przetwarzającego (DKN.5130.2215.2020) w decyzji UODO wyróżniono między innymi brak weryfikacji podmiotu przetwarzającego właśnie w tym zakresie.

Kary za naruszenia RODO mogą sięgać 20 mln euro albo 4 proc. rocznego obrotu, a w praktyce organ nadzorczy wymierza także kary niższe, lecz dotkliwe dla mniejszych podmiotów. W opisie najczęstszych błędów przedsiębiorców zwraca się uwagę, że małe firmy często nie mają procedur kontroli dostępu ani świadomości, że udostępnienie danych osobowych bez zapewnienia bezpieczeństwa jest poważnym naruszeniem.

Sprawdzian bezpieczeństwa dostępu do kont chmurowych

Ryzyko i kary za naruszenia RODO w Polsce

Rozliczanie miejsc: jak role i statusy kont przekładają się na koszty

W modelu SaaS i w wielu wdrożeniach ERP koszt jest funkcją liczby kont z określonym typem dostępu, a nie liczby osób zatrudnionych w firmie. Dlatego podstawą kontroli kosztów jest aktualny rejestr kont. Powinien on zawierać co najmniej: identyfikator użytkownika, imię i nazwisko oraz dział, przypisaną rolę, typ licencji lub miejsca, datę utworzenia konta, datę ostatniego logowania oraz status (aktywne, zawieszone, do usunięcia). Utrzymywany na bieżąco rejestr pozwala odpowiadać na pytanie „za co faktycznie płacimy” bez każdorazowego przeszukiwania konsoli administratora.

Kolejnym krokiem jest mapowanie ról na typy licencji. Nie każda osoba potrzebująca wglądu w dane wymaga pełnego, edycyjnego miejsca w systemie. Część dostawców oferuje tańsze warianty licencji o ograniczonym zakresie funkcji lub dostępy tylko do odczytu — warto sprawdzić w cenniku i umowie, jakie opcje są dostępne, zamiast domyślnie przydzielać wszystkim najszerszy pakiet. Zasada jest prosta: uprawnienia i koszt powinny wynikać z rzeczywistej roli, a nie z przyzwyczajenia.

Szczególną uwagę należy poświęcić kontom, które przestały być używane. Konto byłego pracownika lub osoby, która zmieniła stanowisko i przestała korzystać z danego systemu, generuje koszt i ryzyko jednocześnie. Warto ustalić jasne reguły dezaktywacji: kto może zawiesić konto, kto je ostatecznie usuwa i po jakim czasie od zakończenia współpracy. Konta testowe, szkoleniowe i „na wszelki wypadek” powinny mieć określony termin ważności i być automatycznie przeglądane.

Zamawianie nowych miejsc warto scentralizować. Jeden właściciel procesu — na przykład osoba odpowiedzialna za systemy biznesowe — powinien być punktem przyjmowania wniosków i weryfikować, czy potrzebę da się zrealizować istniejącym dostępem, czy naprawdę konieczny jest nowy płatny seat. Pozwala to uniknąć dwóch typowych problemów: kupowania miejsc, których nikt nie używa, oraz pracy na kontach współdzielonych, które zacierają odpowiedzialność i utrudniają audyt.

Ta sama lista używana do kontroli kosztów służy do przeglądu uprawnień: widać na niej, kto ma dostęp do czego, kto logował się ostatnio i gdzie nagromadziły się zbędne przywileje. Regularne uzgadnianie rejestru kont z fakturami od dostawcy chroni więc jednocześnie budżet i dane.

Cykl życia konta i przegląd uprawnień

Najprostszym sposobem uporządkowania dostępów jest opisanie całego cyklu życia konta jako powtarzalnej procedury, obejmującej trzy momenty: nadanie dostępu, jego zmianę i odebranie. Wniosek o nowe konto powinien zawierać uzasadnienie biznesowe, wskazanie wymaganych funkcji i obszarów danych oraz zatwierdzenie przez przełożonego. Realizuje go administrator, tworząc konto i przypisując istniejącą rolę — a jeśli żadna nie pasuje, tworząc nową rolę świadomie i dokumentując, co obejmuje. Nowy użytkownik powinien zostać zapoznany z zasadami bezpieczeństwa, w tym z wymogiem drugiego składnika logowania.

Zmiana uprawnień jest równie ważna jak ich nadanie. Awans, przeniesienie między działami czy czasowe zastępstwo to typowe sytuacje, w których stare uprawnienia zostają „na zapas”, a nowe dokładają się na wierzch. Dobrą praktyką jest wtedy przegląd całego zestawu uprawnień, a nie tylko dodanie kolejnych: rola powinna zostać dobrana od nowa do aktualnych zadań. Warto również ustalać z góry, czy dostęp ma charakter czasowy, i wyznaczać datę jego wygaśnięcia.

Odbieranie dostępu powinno mieć formę listy kontrolnej, wykonywanej możliwie szybko. W praktyce obejmuje ona dezaktywację konta w każdej aplikacji, odebranie dostępu do współdzielonych zasobów chmurowych, przekazanie lub zabezpieczenie dokumentów i skrzynki pocztowej, zwrot sprzętu oraz zmianę haseł lub kluczy, do których miała dostęp odchodząca osoba. Konto powinno być dezaktywowane, a następnie — po ustalonym okresie potrzebnym np. na przekazanie spraw — usunięte lub pozostawione w formie archiwalnej bez możliwości logowania.

Uzupełnieniem cyklu jest regularny przegląd uprawnień. Polega on na porównaniu rzeczywistych dostępów z aktualnym rejestrem i weryfikacji, czy każdy użytkownik nadal potrzebuje przypisanej roli. Najlepiej, gdy przeglądu dokonują właściciele poszczególnych obszarów lub systemów, potwierdzając lub korygując listy swoich użytkowników — administrator techniczny rzadko bowiem wie, kto faktycznie czego potrzebuje w pracy. Wyniki przeglądu powinny kończyć się konkretnymi decyzjami: pozostawić, ograniczyć, odebrać.

Ostatnim elementem jest gotowość na incydent. Gdy pojawia się podejrzenie przejęcia konta, kluczowe jest szybkie działanie: zablokowanie konta i sesji, wymuszenie zmiany poświadczeń, sprawdzenie, do jakich zasobów uzyskano dostęp i czy doszło do eksportu danych, a także ocena, czy zdarzenie wymaga zgłoszenia naruszenia ochrony danych do organu nadzorczego. Warto mieć tę procedurę zapisaną i przetestowaną zawczasu — tak samo jak mechanizmy przywracania usuniętych danych, których wymaga skuteczne zarządzanie bezpieczeństwem kont w firmie.