18 października 2026

Masz zewnętrznego informatyka? Odpowiedzialność i tak zostaje u Ciebie

Sieć przychodni, kilkanaście placówek, własny dział IT to jedna osoba od komputerów i drukarek. Serwery z systemem rejestracji pacjentów i dokumentacją utrzymuje firma zewnętrzna, od lat ta sama, nikt nie ma do niej zastrzeżeń. Kiedy przy KSC padło pytanie, jak firma zarządza podatnościami, odpowiedź była prosta: mamy firmę, która się tym zajmuje.

Potem ktoś zapytał, skąd wiadomo, że się zajmuje. Zapadła cisza. Nie dlatego, że dostawca coś zaniedbał. Po prostu nikt po stronie przychodni nigdy tego nie sprawdzał, bo nie wiedział, jak.

W trzecim odcinku cyklu o KSC sprawdzam, jak nadzorować firmę, której powierzyłeś utrzymanie serwerów.

Uwaga porządkowa: nie jestem prawnikiem i to nie jest porada prawna.

Co mówi przepis

Dyrektywa NIS2, wdrażana znowelizowaną ustawą o krajowym systemie cyberbezpieczeństwa, w art. 20 ust. 1 kładzie nadzór nad środkami zarządzania ryzykiem na organy zarządzające. Art. 21 ust. 2 lit. d wymienia wśród tych środków bezpieczeństwo łańcucha dostaw, w tym relacji z bezpośrednimi dostawcami i usługodawcami. Art. 21 ust. 3 dopowiada, że trzeba przy tym brać pod uwagę jakość praktyk cyberbezpieczeństwa dostawców. Lit. f dodaje ocenę skuteczności środków.

Oficjalne FAQ do ustawy o KSC potwierdza, że zadania można powierzyć innym, ale nie zwalnia to kierownika podmiotu z odpowiedzialności. Pisałem o tym szerzej w tekście o outsourcingu. Tutaj zajmuję się jedną praktyczną konsekwencją: skoro odpowiedzialność zostaje u Ciebie, musisz zapewnić skuteczny nadzór nad zleconą pracą. Techniczne sprawdzanie możesz powierzyć kompetentnej osobie, ale ktoś po Twojej stronie musi wiedzieć, co i jak jest sprawdzane.

Gdzie jest luka

W większości takich relacji jedyne źródło informacji o stanie serwerów to sam dostawca. On skanuje, on łata, on pisze raport, jeśli w ogóle go pisze. Klient dostaje to, co dostawca uzna za ważne, w formie, jaką dostawca wybrał.

To nie jest zarzut wobec dostawców. Większość robi rzetelną robotę. Problem jest w konstrukcji: kiedy ten sam podmiot wykonuje pracę i jako jedyny ją ocenia, klient nie ma czym tej oceny porównać. Przy audycie zdanie "dostawca nas zapewnił" nie jest dowodem nadzoru.

Są też trzy rzeczy, które w praktyce giną najczęściej.

Decyzje o ryzyku zapadają po stronie dostawcy. Administrator uznaje, że aktualizacji nie da się zrobić przed końcem kwartału, bo system rejestracji jej nie wspiera. Decyzja może być rozsądna, ale jej skutki ponosi przychodnia, a zlecenie obsługi nie zdejmuje odpowiedzialności z jej kierownika. Ktoś po stronie przychodni powinien ją zatwierdzić, wiedząc, co zatwierdza.

Historia zostaje u dostawcy. Jeśli kiedyś zmienicie firmę, rejestr działań z ostatnich lat może odejść razem z nią, a audytor zapyta właśnie o te lata.

Raport mówi to, co dostawca chce powiedzieć. Nie musi to być nieuczciwość. Wystarczy, że raport opisuje wykonaną pracę ("zainstalowano 140 aktualizacji"), a nie stan ("ile podatności jest po terminie").

Jak to zamknąć bez psucia współpracy

Ustal w umowie, co ma być w raporcie. Nie liczba wykonanych czynności, tylko wskaźniki stanu: odsetek podatności usuniętych w terminie, lista pozycji po terminie, czas usunięcia, lista serwerów objętych i nieobjętych skanem, data ostatniego skanu każdego z nich. Do tego terminy usuwania, które obowiązują dostawcę, zapisane w umowie albo w Waszej polityce. Opisałem te wskaźniki w poprzednim odcinku.

Decyzje o ryzyku zatwierdza ktoś u Ciebie. Dostawca może zaproponować odroczenie aktualizacji, z uzasadnieniem i datą przeglądu. Zatwierdza osoba po Twojej stronie, która za to odpowiada. Zapisz tę zasadę w umowie.

Dane mają być Twoje. Dostęp do historii skanów i decyzji w trakcie umowy oraz ich przekazanie po jej zakończeniu. Najprościej, jeśli dane od początku leżą w miejscu, do którego masz dostęp niezależnie od dostawcy.

Miej własną listę dostępów wydanych dostawcy. Konta administratora, klucze SSH, VPN, panel hostingu, kopie zapasowe: kto po Twojej stronie ma tę listę i czy potrafi te dostępy zamknąć bez pomocy dostawcy? Jeśli jedyną osobą, która umie odebrać dostęp dostawcy, jest sam dostawca, to masz zaufanie, a nie nadzór. Nie chodzi o odbieranie czegokolwiek dziś. Chodzi o to, żeby w dniu zmiany firmy albo incydentu po jej stronie nie zaczynać od pytania, gdzie są hasła. To pytanie podsunął mi pod pierwszym odcinkiem administrator z firmy, która utrzymuje serwery klientom. Sam przyznał, że dla dostawcy bywa niewygodne, ale po nim obie strony wiedzą, na czym stoją.

Raport ma trafiać do Ciebie wprost z danych. Najmocniejsza forma nadzoru to taka, w której wskaźniki liczą się z wyników skanu, a nie są przepisywane przez kogoś do tabelki. Wtedy obie strony patrzą na te same liczby i nikt nie musi nikomu wierzyć na słowo. Taki raport sprawdza część pracy dostawcy, tę widoczną w skanie. Nie zastępuje oceny jego praktyk ani dowodów wykonania innych obowiązków, a Ty dalej sprawdzasz, czy skan obejmuje wszystkie serwery i czy jest aktualny.

Raz na kwartał jedna rozmowa o liczbach. Nie o tym, ile zrobiono, tylko o tym, co jest po terminie i dlaczego. Jeśli przyczyną jest brak okien serwisowych albo stara aplikacja, to jest sprawa do Twojej decyzji, nie do pretensji wobec dostawcy.

Takie zasady pomagają też dostawcy. Raport liczony z danych pokazuje jego pracę lepiej niż tabelka, a to, co stoi z powodu Waszych decyzji, widać czarno na białym.

Gdzie pomaga Secvalis, a gdzie nie

Konto w Secvalis może należeć do Twojej firmy, a dostawca dostaje w nim dostęp z rolą techniczną. Jeden użytkownik może należeć do wielu kont, z osobną rolą w każdym, więc firma obsługująca kilku klientów pracuje u każdego w jego koncie. Dla tej roli możesz zawęzić dostęp do maszyn wybranych projektów. Do konta zaprasza właściciel albo administrator, a usunąć z niego użytkownika może tylko właściciel. Dostawca z rolą techniczną sam nikogo nie zaprosi ani nie usunie. Po usunięciu dostęp wygasa przy najbliższym odświeżeniu sesji, a nie w tej samej sekundzie. Dotyczy to samego Secvalis: listy dostępów do serwerów tu nie ma i trzeba ją prowadzić osobno.

Ustawienia wysyłki raportu zarządczego, w tym odbiorców, zmienia tylko właściciel lub administrator konta. Rola techniczna może je odczytać, ale nie zmienić. Raport może przychodzić do Ciebie cyklicznie, a jego wskaźniki liczą się z wyników skanów: podatność jest uznana za usuniętą, kiedy zniknie z kolejnego pełnego skanu, a nie kiedy ktoś kliknie "naprawione". Średni czas usunięcia pomija przy tym między innymi pozycje zastane w chwili rozpoczęcia pomiaru.

Akceptacja ryzyka wymaga uzasadnienia, właściciela ryzyka, daty przeglądu i informacji o zabezpieczeniach. Rola techniczna może złożyć wniosek, a zatwierdza go właściciel albo administrator konta. Dziennik audytowy zapisuje takie decyzje i można go wyeksportować. Jeśli chcesz dać wgląd audytorowi, ma do tego osobną rolę, tylko do odczytu.

Secvalis nie zastąpi umowy z dostawcą, oceny dostawcy ani całego obszaru bezpieczeństwa łańcucha dostaw. Nie sprawdzi, czy dostawca dobrze chroni własne systemy i dostępy do Twoich. Obejmuje serwery Linux i obrazy uruchomionych na nich kontenerów, więc jeśli dostawca utrzymuje też stacje z Windows albo sieć, ta część musi mieć własny raport. Jeśli nadasz dostawcy rolę administratora, będzie mógł zmienić ustawienia raportu, więc rozważ, komu jaką rolę dajesz.

Jak to wygląda w praktyce, możesz sprawdzić w publicznym demo: raport zarządczy, rejestr decyzji o ryzyku i dziennik audytowy fikcyjnej firmy, bez rejestracji.

W następnym odcinku przechodzę na stronę administratora: co zrobić, kiedy na liście jest 800 pozycji, a ludzi jeden etat.

Źródła

Jeden mail w tygodniu z nowo opublikowanymi podatnościami, o których warto wiedzieć. Bez zakładania konta.

Digest dotyczy ogólnie nowych podatności, nie Twoich serwerów. Jeśli chcesz wiedzieć, które z nich faktycznie działają w Twojej infrastrukturze, tym zajmuje się Secvalis : skanuje Twoje maszyny i zgłasza wyłącznie to, co ich dotyczy.