Definicja: Rozdzielenie uprawnień właściciela firmy i wykonawcy bez udostępniania głównych haseł polega na nadaniu odrębnej tożsamości wykonawcy oraz ról o ograniczonym zakresie w poszczególnych systemach, tak aby dostęp był rozliczalny, audytowalny i możliwy do cofnięcia bez destabilizacji usług: (1) minimalny zakres uprawnień zgodny z rolą zadaniową; (2) osobna tożsamość wykonawcy z kontrolą uwierzytelniania; (3) audyt i procedura odwołania dostępu po zakończeniu prac.
Ostatnia aktualizacja: 2026-08-17
Szybkie fakty
- Współdzielenie głównego hasła eliminuje rozliczalność i utrudnia odcięcie dostępu.
- Delegowanie ról umożliwia ograniczenie zakresu oraz audyt działań wykonawcy.
- Skuteczny model uwzględnia offboarding oraz testy po nadaniu uprawnień.
- Tożsamość: Wykonawca otrzymuje osobne konto lub zaproszenie użytkownika zamiast dostępu do konta właściciela.
- Zakres: Uprawnienia są nadawane minimalnie i tylko do zasobów potrzebnych do realizacji zadania, z preferencją dla dostępu czasowego.
- Kontrola: Aktywność jest rejestrowana w logach, a procedura offboardingu obejmuje odebranie ról, przegląd zmian i archiwizację śladu audytowego.
W praktyce trudność nie wynika z pojedynczego kliknięcia w panelu, lecz z braku spójnego modelu: które zasoby są krytyczne, jakie działania mają ślad w logach, kto zatwierdza operacje ryzykowne i jak szybko da się odebrać dostęp po zakończeniu prac. Poniższa struktura porządkuje role, procedurę wdrożenia, kontrolę oraz testy, które wykrywają nadmiarowe uprawnienia.
Dlaczego nie należy przekazywać głównych haseł wykonawcy
Przekazywanie głównych haseł jest jednym z najczęstszych źródeł utraty kontroli nad zasobami, ponieważ zaciera granicę między tożsamością a uprawnieniem. Wspólne hasło sprawia, że działania wykonawcy i właściciela są nierozróżnialne, a ślad audytowy traci wartość dowodową i operacyjną.
W warstwie bezpieczeństwa problem polega na nieodwracalnym rozszerzeniu powierzchni ataku: jedno ujawnione hasło często otwiera wiele usług, a zmiana hasła po incydencie może przerwać integracje i procesy biznesowe. W warstwie organizacyjnej rośnie ryzyko sporów: trudniej wykazać, kto zmienił ustawienia, kto wykonał eksport danych i kto odpowiada za skutki. W warstwie technicznej pojawia się dodatkowy koszt „sprzątania” po projekcie, ponieważ odebranie dostępu oznacza rotację tajemnic, a nie proste cofnięcie roli.
Szczególnie ryzykowne są obszary, w których jedno konto steruje własnością lub rozliczeniami: panel domeny i DNS, hosting, poczta, profile firmowe, konta reklamowe, narzędzia analityczne, repozytoria plików oraz integracje API. Minimalnym standardem jest rozdzielenie tożsamości (osobne konto wykonawcy) i ograniczenie uprawnień do zakresu zadania, wraz z rejestrowaniem aktywności w logach.
Jeśli system nie rejestruje działań per użytkownik, to najbardziej prawdopodobne jest, że udostępniono konto współdzielone zamiast delegować role.
Model ról: właściciel, administrator, wykonawca i dostęp czasowy
Skuteczny model ról ogranicza wykonawcę do działań operacyjnych i pozostawia decyzje krytyczne po stronie właściciela. Dzięki temu możliwe jest utrzymanie ciągłości pracy, a jednocześnie ograniczenie ryzyka przejęcia własności, rozliczeń lub mechanizmów odzyskiwania dostępu.
W praktyce przydatne jest rozróżnienie dwóch klas uprawnień. Uprawnienia krytyczne obejmują: przeniesienie własności, zarządzanie tożsamościami i rolami, resetowanie metod uwierzytelniania, zmiany rozliczeń, eksporty pełnych danych, konfigurację kluczy API oraz ustawienia bezpieczeństwa. Uprawnienia operacyjne obejmują: edycję treści, ustawienia kampanii, zmiany w ramach pojedynczego projektu, konfiguracje funkcjonalne, publikacje i podstawowe raportowanie. Wykonawca powinien działać głównie w obszarze operacyjnym, a operacje krytyczne powinny wymagać zatwierdzenia lub udziału właściciela.
Google supports granular role-based access control, allowing the minimum necessary permissions to be assigned to each secondary account.
W wielu systemach dodatkowo da się zastosować dostęp czasowy, czyli uprawnienia nadawane na czas projektu albo na okres serwisowy. Taki wariant zmniejsza ryzyko „zalegających” ról po zakończeniu współpracy i ułatwia okresowe przeglądy. Poniższa tabela porządkuje typowe role oraz zakresy, które zwykle powinny pozostać zablokowane dla wykonawcy.
| Rola | Przykładowe uprawnienia dopuszczalne | Uprawnienia ryzykowne do wyłączenia |
|---|---|---|
| Właściciel | Zarządzanie własnością, rozliczeniami, rolami, odzyskiwaniem dostępu | Brak (rola docelowo nie powinna być delegowana) |
| Administrator operacyjny | Konfiguracje usług w ramach polityk, przegląd logów, zarządzanie projektami | Przeniesienie własności, reset MFA, pełne eksporty danych, zarządzanie rozliczeniami |
| Wykonawca | Edycja treści, wdrożenia w wybranym zakresie, prace w kampaniach, poprawki SEO/UX | Zmiany ról, zarządzanie tożsamościami, ustawienia bezpieczeństwa, rozliczenia |
| Dostęp czasowy | Uprawnienia wykonawcy ograniczone do zakresu projektu i czasu trwania prac | Każde rozszerzenie zakresu poza projekt oraz dostęp bez terminu ważności |
Przy dużej liczbie narzędzi najbardziej prawdopodobne jest rozjechanie ról między systemami, dlatego standard ról powinien mieć wersję roboczą przypisaną do listy zasobów.
Procedura wdrożenia wykonawcy bez udostępniania haseł
Wdrożenie wykonawcy bez udostępniania haseł wymaga osobnej tożsamości, minimalnej roli oraz mechanizmów kontroli umożliwiających odcięcie dostępu bez skutków ubocznych. Procedura jest powtarzalna między platformami, ponieważ opiera się na tych samych zasadach: ograniczeniu zakresu i rozliczalności działań.
Account owners can delegate access and assign roles to other users with permissions tailored to specific functions, without sharing the main account password.
Pierwszym krokiem jest inwentaryzacja: lista systemów i zasobów (domena, DNS, hosting, poczta, profil firmy, analityka, reklamy, CRM, repozytoria plików, narzędzia do publikacji). Drugim krokiem jest utworzenie tożsamości wykonawcy jako osobnego konta lub zaproszenia użytkownika oraz ustawienie wymagań uwierzytelniania, w tym wieloskładnikowego uwierzytelnienia tam, gdzie jest dostępne. Trzecim krokiem jest nadanie roli minimalnej i ograniczenie zakresu do projektu, folderu, usługi albo środowiska, unikając uprawnień do własności i rozliczeń.
Czwarty krok obejmuje reguły pracy: kanał zgłaszania zmian, akceptację operacji krytycznych, okna serwisowe oraz sposób dokumentowania wdrożeń. Piąty krok to włączenie audytu i przeglądu logów oraz określenie, które zdarzenia wymagają reakcji. Szósty krok stanowią testy: kontrolowana próba wejścia w obszary rozliczeń, próba zmiany ról, próba eksportu danych oraz weryfikacja, czy wykonawca widzi wyłącznie zasoby projektowe. Ostatni krok to plan zakończenia współpracy: data końcowa, checklista odebrania ról, rotacja ewentualnych tokenów i archiwizacja logów.
Test uprawnień pozwala odróżnić dostęp „do zadania” od dostępu „do konta”, co jest kluczowe przy współpracy z podmiotem zewnętrznym.
Jak zapewnić audyt i rozliczalność działań wykonawcy
Audyt i rozliczalność zależą od odrębnych kont, rejestrowania zdarzeń oraz kontroli operacji podwyższonego ryzyka. Bez logów i jednoznacznych ról nawet poprawnie wykonana praca może zostać zakwestionowana, a incydent będzie trudny do przeanalizowania.
Minimalny zestaw logów obejmuje: zdarzenia logowania, zmiany uprawnień, działania administracyjne, eksporty danych, zmiany konfiguracji bezpieczeństwa oraz operacje na zasobach krytycznych (np. DNS, integracje, tokeny). Jeżeli platforma oferuje wgląd w historię zmian, powinny zostać ustalone progi eskalacji: nietypowe godziny aktywności, próby rozszerzania roli, masowe udostępnienia, masowe eksporty lub nagłe zmiany konfiguracji dostępu. Dla operacji krytycznych skuteczny jest wzorzec separacji obowiązków, w którym wykonawca przygotowuje zmianę, a właściciel lub administrator operacyjny ją zatwierdza i wdraża.
Warstwa organizacyjna audytu powinna obejmować rejestr dostępu (kto, do czego, na jak długo), cykliczny przegląd uprawnień oraz procedurę offboardingu. Równie istotne jest ustalenie zasad dokumentowania: numer zgłoszenia, opis celu zmiany, zakres i data, dzięki czemu zgodność pracy z umową jest łatwiejsza do wykazania. W systemach bez rozbudowanych logów ryzyko można redukować przez ograniczenia zakresu (projekt/folder), a także przez ścisłe rozdzielenie kont i zakaz współdzielenia haseł.
Przy braku atrybucji działań najbardziej prawdopodobne jest, że wykonawca pracuje na koncie właściciela zamiast na własnej tożsamości.
Typowe błędy przy rozdzielaniu uprawnień i szybkie testy weryfikacyjne
Błędy w rozdzielaniu uprawnień najczęściej wynikają z nadawania ról „na zapas”, braku ograniczeń zakresu oraz pomijania offboardingu. Szybkie testy po wdrożeniu pozwalają wykryć nadmiarowe dostępy do własności, rozliczeń i danych wrażliwych, zanim pojawią się realne szkody.
Pierwszym błędem jest utrzymywanie kont współdzielonych: testem jest policzenie, czy każdy wykonawca ma własne konto i przypisaną rolę. Drugim błędem jest rola zbyt szeroka: testem jest kontrolowana próba wejścia w obszary rozliczeń, własności i zarządzania tożsamościami przy zalogowaniu na konto wykonawcy. Trzecim błędem jest brak segmentacji zasobów, szczególnie w repozytoriach plików i narzędziach projektowych: testem jest sprawdzenie, czy wykonawca ma dostęp wyłącznie do folderów i projektów objętych umową. Czwartym błędem jest brak logów lub brak ich przeglądu: testem jest weryfikacja, czy system zapisuje zmiany uprawnień i działania administracyjne z oznaczeniem użytkownika.
Piątym błędem jest brak planu zakończenia współpracy: testem jest symulacja odebrania dostępu i ocena, czy firma zachowuje możliwość administracji bez zależności od wykonawcy. Dodatkowo warto zweryfikować, czy po odebraniu ról nie pozostają aktywne tokeny, integracje lub udostępnienia plików, które omijają standardowy mechanizm użytkowników.
Test dostępu do rozliczeń pozwala odróżnić rolę operacyjną od roli właścicielskiej, co najmocniej ogranicza ryzyko nieodwracalnych zmian.
Porównanie: konto współdzielone hasłem vs delegowanie ról
Konto współdzielone hasłem czy delegowanie ról — co wybrać?
Delegowanie ról zapewnia wyższe bezpieczeństwo i lepszy audyt, ponieważ każdy wykonawca działa na własnej tożsamości, a uprawnienia można precyzyjnie ograniczyć i cofnąć. Konto współdzielone bywa szybsze w uruchomieniu, lecz zwykle podnosi ryzyko błędu, utrudnia dochodzenie przy incydentach i wymusza rotację haseł po zakończeniu prac. Przy zasobach krytycznych (własność, rozliczenia, odzyskiwanie dostępu) delegowanie ról jest praktycznie jedynym wariantem pozwalającym utrzymać kontrolę. Gdy liczy się krótkotrwały dostęp do wąskiego zakresu, delegowanie roli czasowej ogranicza koszt operacyjny bez zwiększania ryzyka.
Jeśli wymagana jest możliwość szybkiego odebrania dostępu bez zmiany haseł, to wniosek prowadzi do delegowania ról zamiast kont współdzielonych.
W części wdrożeniowej procedury operacyjnej czasem pojawia się potrzeba uporządkowania narzędzi firmowych, które łączą aspekty dostępu, administracji i utrzymania usług. W takim kontekście pomocne bywa uporządkowanie ekosystemu stron i paneli administracyjnych powiązanych z realizacją zadań. Informacje organizacyjne mogą zostać powiązane z hasłem tworzenie stron Grójec w ramach wewnętrznych materiałów pomocniczych i list zasobów.
QA: najczęstsze pytania o rozdzielanie uprawnień
Jak odwołać wykonawcy dostęp bez utraty ciągłości pracy?
Odwołanie dostępu powinno polegać na cofnięciu ról i usunięciu konta wykonawcy z listy użytkowników, a nie na zmianie głównego hasła konta właściciela. Dodatkowo należy wyłączyć lub zrotować tokeny integracji, klucze API i udostępnienia plików, które mogły pozostać aktywne poza mechanizmem ról. Po odcięciu dostępu warto zachować logi aktywności z okresu współpracy, aby umożliwić analizę zmian i ewentualny rollback.
Jak sprawdzić, jakie uprawnienia zostały przyznane w różnych systemach?
Najpewniejsze podejście to inwentaryzacja systemów i porównanie list użytkowników oraz ról w każdym panelu administracyjnym. Szczególną uwagę należy zwrócić na obszary: zarządzanie tożsamościami, rozliczenia, własność zasobów, DNS i uprawnienia do eksportu danych. W systemach z audit logiem pomocne jest sprawdzenie, kto i kiedy zmieniał role, co ujawnia nieautoryzowane rozszerzenia.
Kiedy wymagane jest osobne konto wykonawcy, a kiedy wystarcza przypisana rola?
Osobne konto jest wymagane zawsze, gdy potrzebna jest rozliczalność działań oraz możliwość szybkiego odcięcia dostępu bez rotacji tajemnic. Przypisana rola w ramach jednej usługi jest wystarczająca, o ile rola jest przypisana do tej odrębnej tożsamości, a zakres można ograniczyć do projektu i monitorować w logach. Współdzielenie konta właściciela nie zastępuje modelu ról, nawet gdy uprawnienia są „umownie” ograniczane.
Jak ograniczyć wykonawcy wgląd w dane wrażliwe, pozostawiając dostęp do zadań?
Należy ograniczyć rolę do obszaru operacyjnego i zastosować segmentację zasobów, np. dostęp tylko do wybranych projektów, folderów lub kont reklamowych. Uprawnienia do eksportu, rozliczeń, własności i konfiguracji bezpieczeństwa powinny pozostać wyłączone dla wykonawcy. Skuteczność ograniczeń potwierdza test po wdrożeniu: próba wejścia w sekcje wrażliwe na koncie wykonawcy powinna kończyć się brakiem dostępu.
Jak monitorować działania wykonawcy i zachować ślad audytowy?
Podstawą jest praca na odrębnych kontach oraz włączenie logów zdarzeń, które rejestrują działania administracyjne, eksporty danych i zmiany uprawnień. Dodatkowo warto przyjąć proces akceptacji operacji krytycznych oraz cykliczny przegląd ról, szczególnie przy dłuższych umowach. W przypadku systemów z ograniczonym logowaniem ryzyko redukuje się przez maksymalne zawężenie zakresu dostępu oraz preferowanie dostępu czasowego.
Co zrobić, gdy wykonawca wymaga uprawnień właścicielskich do wykonania zadania?
Należy zweryfikować, czy zadanie faktycznie wymaga operacji właścicielskich, czy wynika z braku segmentacji zasobów lub błędnie dobranej roli. Jeśli operacja jest krytyczna, bezpieczniejszy jest wariant, w którym wykonawca przygotowuje zmianę, a właściciel ją zatwierdza i wykonuje lub wykonuje ją administrator operacyjny. Jeżeli platforma nie pozwala na ograniczenie uprawnień, konieczne może być rozdzielenie zasobu na część projektową i część właścicielską albo zmiana narzędzia na takie, które wspiera delegowanie ról.
Źródła
- Google — Zarządzanie użytkownikami i uprawnieniami (Google Business Profile)
- Google — Google Infrastructure Security Design (whitepaper)
- NIST — Special Publication 800-53 Revision 5
- Shopify — Tworzenie i zarządzanie kontami pracowników
- Cisco — Account Delegation and Security (whitepaper)
- biznes.gov.pl — Poradnik o zmianie administratorów i odpowiedzialności
Rozdzielenie uprawnień między właściciela firmy i wykonawcę bez udostępniania głównych haseł opiera się na odrębnych kontach, minimalnych rolach oraz audycie działań. Największe ryzyko tworzy współdzielenie hasła, ponieważ usuwa rozliczalność i komplikuje odebranie dostępu. Uniwersalna procedura wdrożenia obejmuje inwentaryzację zasobów, nadanie roli minimalnej, testy oraz zaplanowany offboarding. Spójny model ról ogranicza wykonawcę do zadań operacyjnych i chroni obszary własnościowe oraz rozliczeniowe.
+Reklama+
