Dostęp firmy zewnętrznej do systemów - jak zrobić to bezpiecznie

Producent poprawia aplikację, firma wdrożeniowa przenosi dane, outsourcing utrzymuje serwery, a osobny wykonawca zajmuje się siecią i backupem. Każdy potrzebuje dostępu, ale niekoniecznie do tych samych zasobów. W firmie z jednym administratorem łatwo zakończyć rozmowę zdaniem: „damy serwisowi VPN i konto administratora”. Właśnie wtedy warto doprecyzować, co to konto ma umożliwiać.

Materiał dotyczy przede wszystkim małych i średnich organizacji, do około 200 pracowników korzystających z komputerów. Proponowany model powinien działać także przy jednej lub dwóch osobach w IT i ograniczonym budżecie. Firma zewnętrzna jest potrzebnym partnerem utrzymania. Jej dostęp ma odpowiadać pracy, umowie i ryzyku.

Spis treści

Dostęp firmy zewnętrznej to część architektury bezpieczeństwa

Nie jest to dodatek „na później”. Obejmuje drogę połączenia, konta, uprawnienia, urządzenie serwisanta oraz możliwość ustalenia przebiegu prac. Samo uruchomienie narzędzia zdalnego nie zamyka tematu.

Dostawca aplikacji może potrzebować jej konsoli, firma utrzymująca sieć dostępu do urządzeń, a operator backupu narzędzi do wykonywania i odtwarzania kopii. Sprowadzenie tych ról do jednego wspólnego dostępu utrudnia późniejsze ograniczenie uprawnień. NIST opisuje bezpieczeństwo zdalnego dostępu jako ochronę wszystkich jego elementów, także urządzeń końcowych. Szyfrowany tunel nie naprawia zainfekowanego laptopa.

Co dokładnie wynika z umowy

Punktem wyjścia jest zakres usług: co wykonawca utrzymuje, w jakich godzinach i z jakim czasem reakcji. Umowa i uzgodniony sposób pracy powinny określać odpowiedzialność za dostępność, zgłaszanie prac, zatwierdzanie zmian i ich rozliczanie. Osoba po stronie klienta musi wiedzieć, co może zatwierdzić i kto ją zastępuje.

  • Jakie systemy i czynności obejmuje usługa?
  • Czy wsparcie jest dostępne w godzinach pracy, czy przez całą dobę?
  • Kto zatwierdza pracę planową, a jak wygląda reakcja na awarię?
  • Jak wykonawca zgłasza rozpoczęcie, wynik i nieplanowane zmiany?
  • Kto po obu stronach odpowiada za konta i aktualność listy osób?

Serwis 24/7 z krótkim czasem reakcji może uzasadniać stały dostęp. Nie oznacza automatycznie pełnego VPN do całej sieci, konta Administratora Domeny, możliwości usuwania backupu ani administracji hypervisorem. Nie uzasadnia też pominięcia MFA i logowania działań. Umowa może uzasadniać dostęp, ale nie zastępuje projektu bezpieczeństwa.

Jeżeli klient wymaga nocnej reakcji, a każde połączenie musi zatwierdzić nieobecny administrator, model jest niespójny. Rozwiązaniem może być wcześniej zatwierdzony zakres działań awaryjnych i ich późniejszy przegląd. Ten problem rozwija materiał Systemy mają działać cały czas - ale kto ma się nimi zająć po godzinach?

Kto naprawdę potrzebuje dostępu

„Firma serwisowa ma dostęp” nie wskazuje osoby, która z niego korzysta. Klient potrzebuje aktualnej listy uprawnionych osób albo uzgodnionego sposobu jednoznacznego ustalenia operatora konkretnej sesji. Przy zmianowym serwisie ma to równie duże znaczenie jak przy jednym stałym techniku.

Zasady powinny określać, czy wykonawca może sam dodawać pracowników, w jakich granicach i jak klient to sprawdza. Potrzebne są także osoby odpowiedzialne za zgłoszenie zmiany pracownika, zatwierdzenie nowego konta i odebranie poprzedniego dostępu. Sama nazwa firmy w loginie nie zapewnia tej informacji.

Konto imienne czy wspólne

Preferowanym rozwiązaniem jest konto imienne przypisane do jednej osoby, bez przekazywania go kolegom. Ułatwia powiązanie logowania z pracownikiem, odebranie dostępu jednej osobie i analizę incydentu. Nazwa konta nadal nie jest dowodem, kto fizycznie wykonał każdą czynność, zwłaszcza po przejęciu poświadczeń lub pozostawieniu otwartej sesji.

Starsze urządzenie może mieć tylko wspólne konto serwisowe. W takim przypadku ograniczamy jego użycie, kontrolujemy wydawanie hasła i zapisujemy użytkownika oraz czas pracy. Pomocne jest powiązanie imiennej sesji zdalnej z sesją na urządzeniu. Jeżeli kilka osób pracuje jednocześnie wspólnym kontem, sam przedział godzin może nie wystarczyć do rozróżnienia ich działań.

Dostęp stały czy czasowy

Dostęp czasowy pasuje do sporadycznego wdrożenia lub naprawy. Można ustalić początek i koniec dostępu, a przedłużenie powiązać z dalszym zakresem prac. Dostęp okresowy może obejmować uzgodnione okna serwisowe. Stały dostęp jest uzasadniony przy stałej administracji, krótkiej reakcji i odpowiedzialności wynikającej z umowy.

Stały dostęp nie musi oznaczać stałych najwyższych uprawnień. Kontroli podlegają konta, zakres zasobów, MFA, logi, źródło połączenia tam, gdzie da się je wiarygodnie ograniczyć, oraz sposób odebrania dostępu. Okresowy przegląd pozwala potwierdzić, czy założenia nadal obowiązują. Wyłączanie po każdej czynności dostępu potrzebnego do utrzymania 24/7 może utrudnić realizację uzgodnionej usługi.

VPN nie oznacza automatycznie bezpiecznego dostępu

VPN zabezpiecza kanał komunikacji. Nie określa automatycznie, do czego użytkownik ma dostęp, jakie ma uprawnienia, kiedy może pracować ani co może zmieniać. Dodatkowo samo logowanie VPN zwykle nie opisze zmian wykonanych wewnątrz aplikacji.

Zbyt szeroki model: VPN => pełna sieć => serwery => backup => hypervisor => urządzenia sieciowe.

Model ograniczony do zadania: VPN => konkretny segment lub host => konkretna usługa.

ACL, czyli listy kontroli dostępu, i reguły firewall mogą ograniczyć dozwolone kierunki oraz porty. Segmentacja oddziela obszary sieci, ale skuteczność podziału zależy również od reguł ruchu między nimi. Na przykład dokumentacja pfSense opisuje reguły dla ruchu IPsec niezależnie od samego zestawienia tunelu. Szczegóły konfiguracji zależą od produktu i trybu VPN.

Lista dozwolonych źródłowych adresów IP może pomóc przy stałych adresach wykonawcy. Nie identyfikuje osoby i nie zastępuje MFA. Jump host, nazywany też bastionem, może skupić dostęp do systemów administracyjnych. Ma sens, jeśli organizacja potrafi go zabezpieczyć i utrzymywać. Nie jest obowiązkowym zakupem każdej małej firmy. Często najpierw wystarczy poprawić konta i reguły na istniejącym firewallu.

Narzędzia zdalnego wsparcia - dostęp wtedy, gdy jest potrzebny

Producent aplikacji lub firma serwisowa może poprawnie świadczyć pomoc przez TeamViewer, AnyDesk albo podobne narzędzie. Problemem jest brak kontroli nad tym, kiedy i na których urządzeniach narzędzie może umożliwić połączenie. Domyślnie ograniczamy zdalny dostęp. Stały dostęp jest wyjątkiem wymagającym konkretnego uzasadnienia.

Przy sporadycznym wsparciu zdalny dostęp powinien być domyślnie wyłączony i uruchamiany tylko dla konkretnego urządzenia oraz na czas potrzebny do wykonania prac. Stała możliwość zdalnego dostępu powinna być rozwiązaniem świadomie uzasadnionym, a nie ustawieniem domyślnym wynikającym z wygody użytkowników lub serwisu.

Nie zaczynamy od pytania: dlaczego mielibyśmy ograniczać zdalny dostęp? Zaczynamy od pytania: dlaczego ten dostęp ma być dostępny cały czas?

Dostęp uruchamiamy dla konkretnej stacji, konkretnego zgłoszenia, na określony czas i tylko w zakresie potrzebnym do wykonania prac. Po zakończeniu administrator powinien potwierdzić zamknięcie sesji i ponownie ograniczyć lub wyłączyć dostęp.

Preferowany model dla sporadycznej pomocy: zgłoszenie => wskazana stacja => czasowe zezwolenie => sesja serwisowa => zakończenie prac => wyłączenie dostępu.

Czas dostępu wynika z prac, nie z arbitralnej liczby minut. Jeśli potrzeba więcej czasu, przedłużenie powinno być świadome i powiązane ze zgłoszeniem. Administrator organizacji kontroluje możliwość zdalnego połączenia. Użytkownik może zgłosić problem i zatwierdzić sesję w uzgodnionym modelu, ale nie powinien samodzielnie tworzyć stałej ścieżki dostępu.

Wsparcie interaktywne

Użytkownik lub administrator zgłasza problem, uruchamia narzędzie, przekazuje uprawnionemu serwisowi wymagany kod lub identyfikator i zatwierdza połączenie. Po pracy zamyka sesję. Dokładny przebieg zależy od rozwiązania. AnyDesk opisuje dostęp interaktywny jako ręczne przyjęcie lub odrzucenie żądania. Sam identyfikator urządzenia nie jest tym samym co zgoda na przejęcie kontroli.

Jeżeli infrastruktura pozwala na precyzyjne sterowanie, administrator powinien zastosować odpowiednio regułę dla konkretnego hosta, ograniczony segment, określone porty lub usługi, czasowe reguły firewall albo centralnie zarządzanego agenta. Przykładem jest czasowe zezwolenie na komunikację narzędzia tylko z jednej stacji objętej zgłoszeniem. Wybór mechanizmu zależy od produktu i architektury.

Chodzi o regułę lub konfigurację umożliwiającą komunikację narzędzia zdalnego wsparcia, niekoniecznie o port przychodzący. Dokumentacja TeamViewer opisuje połączenia wychodzące. Sama dostępność komunikacji nie oznacza jeszcze, że każdy może się połączyć: znaczenie mają również uwierzytelnianie, zgoda użytkownika i polityki dostępu. Nie każdy produkt działa identycznie.

Samo zamknięcie okna programu nie musi zatrzymać usługi działającej w tle ani wyłączyć dostępu nienadzorowanego. Dlatego zakończenie prac wymaga sprawdzenia, czy czasowa możliwość połączenia rzeczywiście została usunięta lub ograniczona.

Kiedy stały dostęp jest uzasadnionym wyjątkiem

Stała dostępność może wynikać z umowy, SLA określającego uzgodniony poziom usługi, wymaganej dostępności, stałego utrzymania systemu, krótkiego czasu reakcji lub konkretnego wymagania technicznego. Uzasadnienie powinno wskazywać urządzenia, uprawnione osoby i potrzebny zakres. Wygoda użytkownika lub serwisanta nie jest wystarczającym powodem.

W dostępie nienadzorowanym agent działa stale i po skonfigurowaniu odpowiedniego uwierzytelniania umożliwia połączenie bez aktywnego udziału użytkownika. Może to być właściwy model dla stale utrzymywanego serwera. Nie jest jednak automatycznym ustawieniem dla wszystkich stacji. Dokumentacja AnyDesk opisuje ten tryb oraz 2FA. Wyjątek nadal wymaga kontroli kont, zakresu, logów i możliwości odebrania dostępu.

Centralne zarządzanie może pomóc utrzymywać jednolite ustawienia i wskazać uprawnionych operatorów. Zakres zależy od wersji i licencji. Dokumentacja wsparcia TeamViewer opisuje polityki ustawień i MFA. MFA konta w usłudze i zabezpieczenie połączenia do urządzenia mogą być osobnymi mechanizmami. Trzeba sprawdzić wszystkie używane ścieżki i odzyskiwanie dostępu. CISA zaleca przegląd narzędzi zdalnego dostępu i ograniczanie ich użycia, niezależnie od marki.

Samodzielne uruchomienie pomocy przez użytkownika może być dopuszczalne, ale organizacja nadal powinna umieć ustalić:

  • Czego dotyczyło zgłoszenie
  • Kto udzielał wsparcia i na jakiej stacji
  • Kiedy rozpoczęto i zakończono sesję
  • Czy wykonywano działania wymagające podwyższonych uprawnień

W małej firmie wystarczy często prosty rejestr prac serwisowych, powiązany z logami i osobą wykonującą pracę. Użytkownik nie powinien samodzielnie tworzyć stałych wyjątków bezpieczeństwa ani przyznawać serwisowi praw większych niż potrzebne do zgłoszenia.

Czy administrator organizacji potrafi wskazać wszystkie komputery, na których firma zewnętrzna może obecnie uruchomić zdalną sesję?

Jeżeli odpowiedź nie jest znana, warto przejrzeć zainstalowane agenty zdalnego dostępu, konta serwisowe, stałe reguły firewall, zapisane wyjątki i mechanizmy dostępu nienadzorowanego. Przegląd powinien odróżnić uzasadnione stałe utrzymanie od dostępu pozostawionego po dawnym zgłoszeniu.

Ograniczenie dostępu do konkretnych zasobów

„Dostęp do aplikacji” powinien oznaczać konkretne hosty, usługi, segmenty i narzędzia. Serwis jednej aplikacji nie daje automatycznego powodu do przeglądania udziałów plikowych, konsoli backupu czy innych serwerów znajdujących się obok.

Przed nadaniem uprawnień wykonawca powinien wskazać potrzebne połączenia i role. Klient weryfikuje zarówno to, że można wykonać uzgodnione prace, jak i to, że niedozwolone zasoby pozostają niedostępne. Prawa w aplikacji są osobną warstwą od reguł sieciowych. Także narzędzia zdalnego wsparcia łączące się przez usługę pośredniczącą wymagają kontroli kont, zakresu i sesji.

Firma zewnętrzna a konto Administratora Domeny

Konto Administratora Domeny jest potrzebne tylko wtedy, gdy wymaga tego rzeczywisty zakres prac. Wygoda, zwyczaj producenta albo ogólne stwierdzenie „aplikacja nie działa” nie wyjaśniają, dlaczego serwisant potrzebuje tak szerokich praw. Microsoft opisuje delegowanie administracji Active Directory z zakresem mniejszym niż najwyższe uprawnienia.

Jeżeli producent deklaruje taki wymóg, punktem odniesienia jest dokumentacja właściwej wersji i dokładna czynność. Można rozważyć konto czasowe lub czasowe nadanie roli, odnotować okres użycia i odebrać prawa, gdy przestaną być potrzebne. Konto o najwyższych uprawnieniach wymaga zaufanego stanowiska. Nie powinno służyć do poczty, przeglądania internetu ani zwykłej obsługi stacji użytkowników.

Dostęp do hypervisora

Administracja hypervisorem może pozwolić wpływać na wiele maszyn, ich dyski i konfigurację. Firma serwisująca jedną aplikację nie potrzebuje przez to automatycznie dostępu do warstwy wirtualizacji. Gdy dostęp jest uzasadniony, powinien mieć wskazanego użytkownika, zakres, logowanie, sposób odebrania i MFA w obsługiwanych metodach logowania.

Role i granice uprawnień zależą od produktu. Przykładowo Proxmox dokumentuje uprawnienia do konkretnych obiektów i metody uwierzytelniania. Nie zakładamy, że MFA konsoli WWW obejmuje również SSH lub token API. Szersze omówienie granic zaufania zawiera materiał Konto administratora nie jest zwykłym kontem - jak ograniczać uprawnienia i nie stracić kontroli.

Dostęp do backupu

Czy firma serwisująca system produkcyjny powinna automatycznie móc usuwać jego kopie zapasowe? Odpowiedź zależy od roli. Operator backupu potrzebuje innych możliwości niż producent aplikacji, a firma administrująca całą infrastrukturą może mieć szerszą odpowiedzialność. Każdy z tych zakresów wymaga uzasadnienia.

Warto rozdzielić wykonywanie kopii, odtwarzanie i usuwanie, o ile produkt pozwala. Prawo do odtwarzania też jest istotne: może umożliwiać odczyt danych. Veeam zaleca oddzielanie infrastruktury backupowej i opisuje warianty dla różnej skali środowiska. Nie oznacza to obowiązku budowania osobnej domeny w każdej małej firmie.

Backup powinien zachowywać niezależność od środowiska, które ma odtwarzać. Osobna nazwa konta nie wystarczy, jeśli administrator produkcji kontroluje również jego hasło, hosta i repozytorium. Znaczenie mają także kopie odłączone lub odporne na modyfikację oraz test odtworzenia. Więcej w materiale Kopia zapasowa to nie backup - dopóki nie potrafisz odtworzyć danych.

Dostęp zdalny a dostęp wykonywany w siedzibie

Bezpieczeństwo nie kończy się na VPN. Serwisant może pracować w siedzibie przy serwerze, stacji administracyjnej, urządzeniu sieciowym, systemie dziedzinowym, hypervisorze albo backupie. Obecność w budynku nie zastępuje uzgodnienia zakresu prac i konta.

Przed rozpoczęciem warto potwierdzić tożsamość i zlecenie, wskazać stanowisko oraz ustalić, jakie urządzenia i nośniki można podłączyć. Preferowane jest osobne konto. Udostępnienie otwartej sesji codziennego administratora miesza działania dwóch osób. Gdy ograniczenia systemu wymuszają użycie istniejącego konta, potrzebne są zgoda, zapis czasu i powiązanie sesji z konkretnym serwisantem. Nadzór dopasowujemy do ryzyka. Nie musi oznaczać obserwowania każdej czynności przez cały dzień.

Serwisant pracuje na miejscu - kto wykonał działania

Log może pokazać: konto administratora => logowanie => zmiana konfiguracji. Nadal pozostaje pytanie, kto siedział przy komputerze. Jeśli hasło zna administrator, serwisant i jego zastępca, sam login nie rozstrzyga sprawy.

  • Kto przyjechał i z jakiej firmy?
  • W jakim celu i na podstawie którego zlecenia?
  • Kiedy rozpoczął i zakończył pracę?
  • Z jakiego konta i stanowiska korzystał?
  • Jaki zakres prac wykonał i co zmienił?

W małej firmie wystarczy często jeden wpis w rejestrze powiązany z potwierdzeniem wykonawcy. Jeżeli osoby zmieniają się przy stanowisku, warto odnotować przekazanie sesji albo rozpocząć nową sesję imienną. Potwierdzenie „serwis był dziś u nas” jest za mało dokładne, by wyjaśnić zmianę wykonaną o konkretnej godzinie.

Log techniczny a rozliczalność osoby

Log techniczny pokazuje aktywność konta. Rejestr organizacyjny powinien pozwolić ustalić, kto w tym czasie rzeczywiście wykonywał pracę. Konto imienne, nieudostępniane innym, dobrze wspiera rozliczalność. Problem narasta przy kontach wspólnych, tymczasowych, przekazanych serwisantowi i przy pracy kilku osób na jednej sesji.

Do odtworzenia przebiegu potrzebne są spójne znaczniki czasu, identyfikator konta lub sesji i odpowiedni zakres zdarzeń. Dziennik logowań nie musi rejestrować każdej zmiany konfiguracji. Zakres audytu trzeba sprawdzić w używanym systemie, a logi przechowywać tak, by nie znikały przed analizą i nie mogły być swobodnie usuwane przez osobę, której pracę mają dokumentować.

Nie potrzeba od razu dużego centrum monitorowania. Ważniejsze są działające logi, uzgodniona retencja i osoba, która potrafi je odczytać. CISA opisuje logowanie dla małych i średnich firm. Praktyczne rozwinięcie: Mamy logi. I co z tego? Jak zbudować monitoring, który naprawdę działa.

Rejestr prac serwisowych

Rejestr prac może być chronionym arkuszem, dokumentem lub uporządkowanymi zgłoszeniami. System ticketowy jest wygodny przy większej liczbie zleceń, ale nie jest warunkiem rozpoczęcia ewidencji. Jeden wpis powinien obejmować:

  • Datę oraz godzinę rozpoczęcia i zakończenia
  • Imię i nazwisko wykonującego prace oraz nazwę firmy
  • System i zakres zlecenia
  • Użyte konto oraz identyfikator sesji, jeśli jest dostępny
  • Osobę po stronie klienta zatwierdzającą pracę
  • Wynik prac i wykonane zmiany
  • Napotkane problemy i dalsze działania

Przy stałym utrzymaniu rejestr może odnosić się do wcześniej uzgodnionej kategorii czynności, bez osobnej zgody na każde rutynowe sprawdzenie. Zmiany wykraczające poza zakres wymagają odrębnego uzgodnienia. W rejestrze nie zapisujemy haseł. Dostęp do niego i możliwość zmiany wpisów powinny być kontrolowane. Prosty rejestr rzeczywiście uzupełniany jest lepszy niż rozbudowany system, którego nikt nie używa.

MFA i klucze sprzętowe dla firmy zewnętrznej

Konto zewnętrznego administratora jest dobrym kandydatem do MFA. Przy stałej administracji silne uwierzytelnianie może być wymaganiem współpracy. Mechanizm trzeba dopasować do VPN, konsoli i pozostałych dróg dostępu, a nie tylko do jednego ekranu logowania. CISA zaleca MFA także małym firmom.

FIDO2 może zapewniać uwierzytelnianie odporne na phishing dzięki powiązaniu z właściwą usługą. Klucz sprzętowy jest sensowną opcją dla kilku kont administracyjnych, jeżeli usługa go obsługuje. YubiKey jest jednym z przykładów, nie jedynym rozwiązaniem. Właściwości zależą od protokołu i konfiguracji, nie samego podłączenia urządzenia USB. Dokumentacja Yubico opisuje działanie FIDO.

Certyfikat jest powiązany z kluczem publicznym, a uwierzytelnianie wymaga dostępu do odpowiadającego mu klucza prywatnego. Ten klucz trzeba chronić. Sam certyfikat nie oznacza automatycznie MFA. Wdrożenie wymaga obsługi wydawania, odnawiania i unieważniania zgodnie z produktem. Podstawy opisuje Microsoft w dokumentacji certyfikatów.

Przed wymuszeniem MFA strony uzgadniają rejestrację zapasu, utratę urządzenia, odejście pracownika i odzyskanie dostępu. Zapasowy klucz rejestruje się wcześniej w obsługiwanych usługach. Wspólny telefon z zatwierdzaniem dowolnych próśb może osłabić identyfikację osoby. Silne logowanie nie chroni automatycznie już przejętej sesji.

Dostęp awaryjny

Awaria może wystąpić wtedy, gdy normalny VPN, katalog albo usługa uwierzytelniania nie działa. Ścieżka awaryjna powinna być możliwie niezależna od zależności, które ma pomóc odtworzyć. Może wymagać lokalnego dostępu, innej metody logowania lub wcześniej przygotowanego konta. Konkretne rozwiązanie zależy od systemu i modelu wsparcia.

Dostęp awaryjny nie oznacza automatycznie konta bez MFA. Przykładowo Microsoft dla Entra ID opisuje silne, niezależne metody awaryjne. Tych ustawień nie przenosi się bez analizy do każdego innego produktu.

Procedura wskazuje uprawnione osoby, sposób uzyskania poświadczeń, zapis użycia i późniejszy przegląd. Powinna działać również przy nieobecności głównego administratora. Test obejmuje rzeczywiste uzyskanie dostępu, nie tylko sprawdzenie, czy istnieje dokument. Po użyciu odtwarzamy przebieg prac i zabezpieczamy ponownie ujawnione poświadczenia.

Odebranie dostępu po zakończeniu prac

Po jednorazowej naprawie można wyłączyć konto, odebrać czasową rolę, usunąć dostęp VPN, unieważnić certyfikat albo wyrejestrować klucz. Wykonujemy działania odpowiadające rzeczywistej metodzie dostępu. Wyłączenie jednego konta nie musi zakończyć wszystkich aktywnych sesji i usunąć niezależnych tokenów.

Przy dostępie okresowym sprawdzamy koniec uzgodnionego okna. Przy stałej umowie pozostaje zakres potrzebny do dalszego utrzymania, a odbierane są uprawnienia nadmiarowe lub nadane tylko na czas zmiany. Nie wyłączamy automatycznie działającego dostępu serwisu 24/7 po każdej czynności. Decyzja wynika z dalszej potrzeby i odpowiedzialności, nie z samego zamknięcia zgłoszenia.

Zmiana pracownika po stronie wykonawcy

Pracownik wykonawcy może odejść, choć umowa z jego firmą nadal obowiązuje. Klient nie dowie się o tym z samego faktu, że konto przestało być używane. Umowa lub procedura powinna wskazywać, kto zgłasza zmianę, w jakim czasie, kto odbiera dostęp i kto zatwierdza następcę.

Nowa osoba otrzymuje własny dostęp. Poprzednie konto, role, klucze i sesje wymagają przeglądu. Gdy odchodzący pracownik znał wspólne hasła, samo wyłączenie jego loginu nie wystarczy. Potrzebna może być zmiana tych haseł, z uwzględnieniem zależności usług. Klient powinien otrzymać potwierdzenie wykonania, a nie tylko obietnicę, że zajmie się tym wykonawca.

Zmiana firmy serwisowej

Zmiana firmy serwisowej to więcej niż nowy numer telefonu. Przekazanie musi zapewniać ciągłość działania i kontrolę klienta nad dostępem. Zanim poprzednia firma zakończy obsługę, powinno być jasne, kto przejmuje administrację i jak odzyskać ją w razie problemu.

  • VPN, konta centralne i lokalne oraz aktywne sesje
  • Certyfikaty, klucze sprzętowe, tokeny i znane wykonawcy hasła
  • Hypervisor, backup i urządzenia sieciowe
  • Narzędzia zdalnego dostępu oraz konsole zarządzane przez wykonawcę
  • Dokumentacja, rejestry prac i dostęp awaryjny

Nie wystarczy zmienić jednego hasła. Trzeba usunąć niepotrzebne ścieżki, potwierdzić przekazanie konfiguracji i sprawdzić działanie nowego dostępu. Rotację poświadczeń używanych przez usługi planujemy i testujemy, aby nie zatrzymać zadań. Moment odcięcia poprzedniego wykonawcy powinien wynikać z uzgodnionego przekazania, a w przypadku incydentu z potrzeb jego obsługi.

Podwykonawcy

Podwykonawca może być potrzebny do specjalistycznego zadania. Klient powinien wiedzieć, czy model współpracy na to pozwala i kto faktycznie pracuje. Odpowiedzialność za zgłoszenie osoby, zakres i odebranie dostępu nie może zniknąć między dwiema firmami.

Preferowane jest osobne konto lub inny wiarygodny sposób przypisania sesji do człowieka. Podwykonawca nie powinien po prostu otrzymać hasła pracownika głównego wykonawcy. Rejestr wskazuje osobę, firmę, zlecenie i zatwierdzony czas. Kwestie dopuszczenia podwykonawców zależą od umowy i odpowiedzialności stron. Tu chodzi o praktyczną kontrolę dostępu.

Jak przechowywać hasła

Sposób przechowywania poświadczeń dobieramy do częstotliwości użycia, krytyczności, liczby osób, potrzeb audytu i odzyskania oraz ryzyka awarii systemów elektronicznych. Hasło używane codziennie przez kilka uprawnionych osób wymaga innego sposobu przechowywania niż dane logowania do konta awaryjnego, po które sięga się sporadycznie.

Manager haseł nie jest bezpieczny tylko dlatego, że jest cyfrowy. Papier nie jest niebezpieczny tylko dlatego, że jest analogowy. Pytania są podobne: kto uzyska dostęp, czy zostanie to odnotowane, czy dane dostępowe są aktualne i czy będą dostępne wtedy, gdy są potrzebne.

Manager haseł

Manager haseł może generować silne, unikalne hasła i ograniczyć zapisywanie ich w plikach lub wiadomościach. W rozwiązaniu zespołowym może zapewnić centralne zarządzanie, kontrolowane współdzielenie, historię i odebranie dostępu. Zakres funkcji, w tym audyt i odzyskiwanie, zależy od produktu oraz planu usługi.

Odebranie dostępu do sejfu haseł nie usuwa kopii danych logowania, które użytkownik już poznał lub wyeksportował. Gdy trzeba faktycznie odciąć tę osobę od systemu, może być konieczna zmiana hasła w systemie docelowym. Zmiana wpisu w managerze nie zawsze automatycznie zmienia hasło konta.

Manager staje się krytycznym systemem. Wymaga ochrony konta głównego, MFA tam, gdzie jest obsługiwane, aktualizacji, ograniczenia uprawnień i sprawdzonego odzyskiwania. Poradnik NCSC pomaga ocenić manager haseł. Decyzja powinna uwzględniać także dostęp podczas awarii, a nie tylko wygodę codziennego logowania.

Papier, koperta i sejf

Dla rzadko używanego hasła awaryjnego rozsądnym rozwiązaniem może być papier w zamkniętej kopercie przechowywanej w sejfie. Warunkiem jest kontrola dostępu i utrzymanie aktualności. Koperta na dnie szuflady, dostępna dla każdego, nie jest tym samym modelem.

  • Wskazane osoby uprawnione do pobrania koperty i zapewnione zastępstwo
  • Ewidencja pobrania oraz odnotowanie otwarcia i powodu użycia
  • Ochrona sejfu przed nieuprawnionym dostępem i zagrożeniami fizycznymi
  • Zmiana hasła po użyciu według przygotowanej procedury i wymiana zapisu
  • Okresowy test aktualności oraz dostępności przy awarii

Wady są konkretne: papier można skopiować, nie ma automatycznej historii, aktualizacja jest ręczna, a nieaktualne hasło zawiedzie w najgorszym momencie. Zamknięta koperta pomaga zauważyć otwarcie, lecz nie dowodzi, że nikt nie poznał treści. Sejf też może być niedostępny poza godzinami pracy. Ochronę fizyczną trzeba połączyć z organizacją dostępu.

Hasła awaryjne i dostęp offline

System odzyskania nie powinien być całkowicie zależny od systemu, który właśnie odtwarzamy. Jeśli manager wymaga tej samej domeny, SSO, sieci lub serwera, awaria może jednocześnie odebrać administrację i dostęp do hasła potrzebnego do naprawy.

Jeden z możliwych modeli: codzienne hasła => manager. Hasło awaryjne => manager + niezależna kopia offline. Nie jest to jedyny wariant. Możliwe są również niezależne konta i zapasowe metody uwierzytelniania zgodne z produktem.

Kopia offline powinna obejmować tylko potrzebny zakres i pozostawać aktualna. Dla zaszyfrowanej kopii trzeba zapewnić niezależny dostęp do klucza odszyfrowania. W przypadku zapisu na papierze potrzebny jest fizyczny dostęp do sejfu. Samo hasło nie pomoże, jeśli nadal brakuje wymaganego drugiego składnika, sprawnego urządzenia albo drogi połączenia. Test powinien uwzględniać te zależności, także poza zwykłymi godzinami pracy.

Minimalny model dla małej firmy

Mała firma nie potrzebuje skomplikowanego PAM, czyli systemu zarządzania dostępem uprzywilejowanym, żeby poprawić bezpieczeństwo. Sensowny punkt startu obejmuje:

  • Imienne konto stałego administratora zewnętrznego
  • MFA dobrane do używanych metod dostępu
  • VPN ograniczony do potrzebnych zasobów, bez automatycznego dostępu do całej sieci
  • Konto Administratora Domeny tylko do uzasadnionych zadań
  • Oddzielnie określony i kontrolowany dostęp do backupu
  • Oddzielnie określony i kontrolowany dostęp do hypervisora
  • Rejestrowanie logowań i istotnych zmian
  • Prosty rejestr prac serwisowych
  • Procedurę zmiany osoby po stronie wykonawcy
  • Procedurę zakończenia i odebrania dostępu
  • Manager haseł dopasowany do codziennej administracji
  • Niezależny, przetestowany dostęp awaryjny

Oddzielenie dostępu oznacza rzeczywistą kontrolę praw i poświadczeń tam, gdzie wymaga tego granica zaufania, a nie tylko dodatkową nazwę konta. Zakres wdrażamy etapami z wykonawcą i testujemy. Rozwiązanie, którego nikt nie potrafi utrzymać lub użyć poza godzinami, nie spełnia swojej roli.

Najczęstsze błędy

  • „Firma serwisowa ma VPN, więc jest bezpiecznie.” VPN jest właściwym elementem ochrony kanału, ale problemem pozostaje zbyt szeroki ruch. Proste rozwiązanie: wskazane zasoby, reguły firewall i kontrola uprawnień
  • „Serwisant dostaje Administratora Domeny, bo tak jest szybciej.” Takie prawa mogą być potrzebne do konkretnej pracy. Wygoda nie uzasadnia pozostawienia ich do wszystkiego. Potwierdź wymaganie i ogranicz zakres oraz czas
  • „Przyjechał technik, więc daliśmy mu konto administratora.” Ograniczenia starszego systemu mogą wymusić istniejące konto. Bez zapisu nie wiadomo jednak, kto pracował. Preferuj konto imienne, a wyjątek powiąż z osobą i sesją
  • „Logi pokażą, kto coś zrobił.” Mogą dobrze wspierać rozliczalność imiennego konta. Przy wspólnym loginie brakuje związku z człowiekiem. Uzupełnij je rejestrem prac
  • „Firma ma dostęp od lat, więc nie ma sensu go ruszać.” Wieloletnia umowa może uzasadniać stały dostęp. Nie gwarantuje aktualności osób i zakresu. Wprowadź krótki, regularny przegląd
  • „Pracownik zmienił się po stronie wykonawcy, ale konto zostało.” Konto techniczne może pozostać potrzebne, lecz były pracownik nie powinien zachować dostępu. Odbierz jego metody logowania i zmień znane mu wspólne dane uwierzytelniające, jeśli jest to potrzebne
  • „Backup i hypervisor są dostępne z tego samego konta.” Szersza administracja może wynikać z umowy, ale wspólne poświadczenia zwiększają skutki przejęcia. Oddziel granice zaufania i uzasadnij każdą rolę
  • „Hasło awaryjne jest w managerze, który działa tylko po zalogowaniu do domeny.” To wygodne do codziennej pracy, lecz zawodzi przy awarii domeny. Przygotuj niezależną ścieżkę i przetestuj ją
  • „Papier jest niebezpieczny, bo nie jest cyfrowy.” Niekontrolowana kartka jest problemem. Zabezpieczony zapis danych konta awaryjnego może być uzasadniony. Oceń dostęp, aktualność i ewidencję zamiast samego nośnika
  • „Każdy użytkownik może uruchomić zdalny serwis, więc zostawiliśmy dostęp na stałe.” Wygoda użytkownika nie jest wystarczającym powodem do utrzymywania stałej ścieżki zdalnego dostępu. Przy sporadycznej pomocy dostęp powinien być domyślnie wyłączony i uruchamiany na czas konkretnego zgłoszenia. Stały dostęp wymaga uzasadnienia modelem wsparcia i kontroli administratora.

Czy dostęp firmy zewnętrznej jest dobrze zorganizowany?

  • Czy wiemy, kto po stronie wykonawcy ma dostęp?
  • Czy konta są imienne?
  • Czy zakres dostępu odpowiada umowie?
  • Czy VPN daje dostęp tylko tam, gdzie trzeba?
  • Czy konto ma MFA?
  • Czy firma potrzebuje Administratora Domeny?
  • Czy ma dostęp do backupu?
  • Czy ma dostęp do hypervisora?
  • Czy zakres tych dostępów jest uzasadniony?
  • Czy prace wykonywane w siedzibie są odnotowywane?
  • Czy wiadomo, kto fizycznie wykonywał zmianę?
  • Czy użyte konto można powiązać z konkretną osobą?
  • Czy działa rejestr prac serwisowych?
  • Czy logi są przechowywane?
  • Czy wiemy, kto zatwierdza prace?
  • Czy dostęp po zakończeniu prac jest wyłączany, jeśli nie jest dalej potrzebny?
  • Czy zmiana pracownika firmy zewnętrznej uruchamia odebranie dostępu?
  • Czy zmiana wykonawcy uruchamia pełny przegląd dostępów?
  • Czy podwykonawcy są uwzględnieni?
  • Czy hasła są przechowywane w kontrolowany sposób?
  • Czy manager haseł ma bezpieczny mechanizm odzyskania?
  • Czy istnieje niezależny dostęp awaryjny?
  • Czy hasło awaryjne da się uzyskać podczas awarii domeny lub sieci?
  • Czy wiemy, na których urządzeniach działa oprogramowanie zdalnego wsparcia?
  • Czy dostęp nienadzorowany jest włączony tylko tam, gdzie jest rzeczywiście potrzebny?
  • Czy stałe reguły urządzenia brzegowego związane ze zdalnym wsparciem są nadal potrzebne?
  • Czy dla sporadycznego serwisu można uruchamiać dostęp tylko na czas zgłoszenia?
  • Czy można wskazać osobę z firmy zewnętrznej, która wykonywała konkretną sesję?
  • Czy po zakończeniu umowy usuwane są agenty, konta i reguły umożliwiające zdalny dostęp?

Pytania praktyczne

Kliknij pytanie, aby rozwinąć odpowiedź.

+ Czy firma zewnętrzna może mieć stały VPN?

Tak, jeśli uzasadniają to umowa i sposób utrzymania. Stałe połączenie nie powinno automatycznie otwierać całej sieci. Potrzebne są określone konta, zakres, MFA, logi i możliwość odebrania dostępu.

+ Czy firma serwisowa powinna mieć Administratora Domeny?

Tylko do prac wymagających tych uprawnień. Wymóg producenta warto potwierdzić w dokumentacji i odnieść do konkretnej czynności. Do pozostałych zadań lepsza jest delegowana rola.

+ Czy dostęp zewnętrzny zawsze powinien być czasowy?

Nie. Sporadyczne prace przemawiają za dostępem czasowym, a stałe utrzymanie i krótka reakcja mogą uzasadniać dostęp stały. Zakres i kontrola muszą odpowiadać odpowiedzialności.

+ Czy konto wspólne jest zawsze niedopuszczalne?

Niektóre systemy nie oferują kont imiennych. Wtedy ograniczamy użycie, kontrolujemy wydawanie hasła i wiążemy pracę z osobą, czasem oraz zleceniem. To kompromis, który trzeba świadomie utrzymywać.

+ Czy VPN wystarczy do zabezpieczenia dostępu?

Nie. Chroni kanał, lecz potrzebne są jeszcze reguły dostępu do zasobów, właściwe uprawnienia, bezpieczne urządzenie i logowanie. MFA VPN nie oznacza MFA każdej konsoli.

+ Czy firma serwisująca aplikację powinna mieć dostęp do hypervisora?

Nie automatycznie. Najpierw trzeba wskazać zadanie, którego nie da się wykonać na poziomie aplikacji lub systemu gościa. Jeśli dostęp jest potrzebny, ograniczamy rolę do obsługiwanego zakresu.

+ Czy powinna mieć dostęp do backupu?

Tylko w zakresie wynikającym z roli. Zlecenie odtworzenia danych nie musi wymagać prawa do usuwania kopii. Operator backupu może potrzebować szerszego dostępu niż serwis aplikacji.

+ Czy serwisant pracujący w siedzibie powinien mieć osobne konto?

To preferowane rozwiązanie, jeśli system je obsługuje. Wizyta na miejscu nie usuwa potrzeby określenia uprawnień i osoby wykonującej pracę.

+ Co zrobić, jeśli serwisant musi użyć istniejącego konta administracyjnego?

Potwierdzić konieczność, zatwierdzić zakres i odnotować osobę, konto, stanowisko oraz początek i koniec pracy. Po zakończeniu zamknąć sesję i ocenić potrzebę zmiany udostępnionego hasła.

+ Czy log systemowy wystarczy do ustalenia, kto wykonywał prace?

Konto imienne i chroniona sesja mogą dobrze wspierać identyfikację. Przy kontach wspólnych lub przekazanych innej osobie potrzebny jest dodatkowy zapis organizacyjny. Sam login nie rozstrzyga, kto siedział przy komputerze.

+ Jak prowadzić prosty rejestr prac serwisowych?

W chronionym arkuszu, dokumencie lub zgłoszeniu. Zapis obejmuje osobę i firmę, czas, system, konto, zakres, zatwierdzającego, wynik, zmiany i problemy. Nie wpisujemy do niego haseł.

+ Czy MFA ma sens dla firmy zewnętrznej?

Tak, zwłaszcza dla zdalnej administracji. Metoda powinna pasować do obsługiwanych usług, a odzyskanie dostępu musi być uzgodnione i sprawdzone przed awarią.

+ Czy warto używać kluczy sprzętowych?

Mogą być praktyczne nawet dla kilku osób, szczególnie przy natywnym FIDO2. Wymagają zgodności usługi, właściwej rejestracji i zapasu. Marka urządzenia sama nie gwarantuje odporności na phishing.

+ Co zrobić, gdy pracownik firmy serwisowej odchodzi?

Uruchomić uzgodnione zgłoszenie zmiany i odebrać jego konta, role, sesje oraz metody uwierzytelniania. Sprawdzić także wspólne dane uwierzytelniające, które znał. Następca powinien mieć własny dostęp.

+ Co zrobić przy zmianie firmy serwisowej?

Przekazać dokumentację i zapewnić nową administrację, a następnie przejrzeć wszystkie drogi dostępu poprzedniej firmy. Obejmuje to VPN, konta, narzędzia zdalne, klucze, backup, hypervisor i dostęp awaryjny.

+ Czy podwykonawca powinien mieć osobne konto?

Tak, jeśli system to umożliwia. Powinien być rozpoznawalny jako konkretna osoba, z zatwierdzonym zakresem i odpowiedzialnym za odebranie dostępu. Nie powinien po prostu używać loginu innego pracownika.

+ Czy manager haseł jest zawsze najlepszym rozwiązaniem?

Jest zwykle wygodny do codziennej administracji, ale trzeba ocenić ochronę, współdzielenie i odzyskiwanie. Nie powinien być jedynym miejscem dostępu awaryjnego, jeśli zależy od systemu objętego awarią.

+ Czy hasło zapisane na papierze jest złym rozwiązaniem?

Nie z definicji. Znaczenie mają dostęp, aktualność, kontrola użycia i ochrona fizyczna. Kartka przy monitorze i kontrolowany zapis awaryjny w sejfie to różne sytuacje.

+ Czy koperta w sejfie może być sensownym zabezpieczeniem?

Tak, szczególnie do przechowywania rzadko używanych danych logowania do konta awaryjnego. Potrzebne są uprawnione osoby, ewidencja otwarcia, aktualizacja po użyciu i dostęp także podczas awarii. Koperta nie uniemożliwia skopiowania hasła.

+ Jak przechowywać hasła awaryjne?

W sposób niezależny od awarii, którą mają pomóc usunąć. Może to być chroniona kopia offline obok managera, ale trzeba zapewnić aktualność, drugi składnik i drogę dostępu. Wybór potwierdza praktyczny test.

+ Czy TeamViewer lub podobne narzędzie powinno być dostępne cały czas?

Przy sporadycznym wsparciu - nie. Dostęp powinien być uruchamiany dla konkretnego urządzenia i zgłoszenia, a po zakończeniu prac wyłączany lub ponownie ograniczany. Stały dostęp może być uzasadniony, jeśli wynika z umowy, stałego utrzymania systemu lub wymaganego czasu reakcji. Sama wygoda użytkownika lub serwisu nie wystarcza.

+ Czy każdy użytkownik powinien móc samodzielnie uruchomić zdalne wsparcie?

Może to być dopuszczalny model, jeśli organizacja potrafi ustalić, kto i kiedy uzyskał dostęp. Użytkownik nie powinien samodzielnie tworzyć stałych wyjątków bezpieczeństwa ani przyznawać uprawnień większych niż potrzebne.

+ Czy stała reguła firewall dla programu zdalnego wsparcia jest dobrym rozwiązaniem?

To zależy od sposobu działania produktu i modelu wsparcia. Przy sporadycznym serwisie warto rozważyć precyzyjne albo czasowe reguły zamiast szerokiego stałego wyjątku. Kontrola komunikacji uzupełnia uwierzytelnianie i polityki dostępu.

Podsumowanie

Bezpieczny dostęp firmy zewnętrznej nie polega na maksymalnym ograniczeniu wszystkiego. Polega na dopasowaniu dostępu do rzeczywistej pracy, umowy i poziomu ryzyka. Stałe utrzymanie może wymagać stałego dostępu, a zakres szerokiej administracji może być uzasadniony.

Organizacja powinna wtedy wiedzieć, kto korzysta z uprawnień, kiedy, po co, do czego i jak długo. Powinna też umieć odtworzyć ten przebieg z logów i rejestrów.

Log techniczny pokazuje, co zrobiło konto. Organizacja powinna również potrafić ustalić, kto faktycznie wykonywał pracę.

Hasło przechowywane elektronicznie nie jest automatycznie bezpieczniejsze od hasła przechowywanego fizycznie. Bezpieczeństwo zależy od sposobu przechowywania, dostępu, kontroli i możliwości odzyskania.

Autor: Mariusz Smółka

QuestLab.pl - Wałbrzych

Cyberbezpieczeństwo - audyty - bezpieczeństwo informacji - RODO - infrastruktura IT - szkolenia

Ostatni przegląd merytoryczny: 2 października 2026 r.

Materiał przygotowany z wykorzystaniem narzędzi AI wspierających redakcję i analizę. Autorem treści jest Mariusz Smółka i ponosi on odpowiedzialność za jej ostateczny kształt.

Licencja: Creative Commons CC BY-NC-SA 4.0

Materiał możesz udostępniać i modyfikować z podaniem autora - Mariusz Smółka, QuestLab.pl - wyłącznie do celów niekomercyjnych i na tej samej licencji. Wykorzystanie komercyjne wymaga odrębnej zgody autora.

Licencja nie obejmuje logo QuestLab.pl, znaków towarowych ani materiałów osób trzecich wykorzystanych na odrębnych zasadach.

Znalazłeś błąd lub nieścisłość?

Będę wdzięczny za informację. Materiały są przeglądane i aktualizowane.