W instytucji publicznej bezpieczeństwo nie jest techniczną funkcją schowaną w serwerowni. To warunek, od którego zależy, czy obywatel zaufa cyfrowej usłudze, czy urzędnik może działać bez obawy o własną odpowiedzialność i czy audyt nie zatrzyma kolejnego projektu. Bezpieczeństwo w sektorze publicznym to dziś realna podstawa zaufania, a nie formalność na końcu wdrożenia.
Z naszego doświadczenia najtrudniejsze nie jest kupienie narzędzia, lecz zebranie w jedną spójną całość tożsamości, dostępów, logów, zgód i obowiązków z RODO, a potem utrzymanie przez lata. Nawet jeśli nie masz własnego zespołu bezpieczeństwa, my tę kompetencję wnosimy. Podpieramy ją doświadczeniem w prowadzeniu systemów i infrastruktury dla administracji oraz w pracy przy systemach bezpieczeństwa, gdzie kontrola dostępu, rozliczalność i poufność danych są wymogiem, a nie dodatkiem.
Dlaczego bezpieczeństwo w instytucji publicznej to podstawa zaufania?
Instytucja przetwarza dane, których obywatel nie może przenieść gdzie indziej: numer PESEL, dane o zdrowiu czy majątku. Nie ma relacji handlowej, z której da się zrezygnować, więc poprzeczka odpowiedzialności stoi wyżej niż w firmie. Dlatego patrzymy na bezpieczeństwo jak na cechę całego systemu: liczy się, kto i na jakiej podstawie dostał dostęp, czy każda operacja zostawia ślad i czy w razie incydentu da się odtworzyć jej przebieg. Gdy to jest poukładane, instytucja udowodni, że panuje nad danymi, a tego zaufania nie odbuduje się łatwo po jednym wycieku.
Jak zarządzać tożsamością i dostępem (IAM) w instytucji?
Fundamentem jest zarządzanie tożsamością i dostępem (IAM), czyli jasna odpowiedź, kto jest kim w systemie i co mu wolno. Gdy pracownicy się zmieniają, przechodzą między wydziałami i obsługują wiele systemów naraz, bez tego porządku dostępy szybko wymykają się spod kontroli.
Projektujemy warstwę IAM wokół kilku mechanizmów, które realnie ograniczają ryzyko:
- role i uprawnienia oparte o funkcję (RBAC), a nie przypisywane ręcznie pojedynczym osobom,
- zasadę najmniejszych uprawnień (least-privilege), czyli dokładnie tyle dostępu, ile wymaga zadanie, i nic ponadto,
- uwierzytelnianie wieloskładnikowe (MFA) oraz logowanie przez centralne źródło tożsamości (SSO, federacja), żeby nie mnożyć osobnych haseł,
- automatyczne odbieranie dostępu przy zmianie stanowiska lub odejściu pracownika, spięte z systemem kadrowym.
Dzięki temu dostęp wynika z roli, a nie z historii zatrudnienia. Kluczowa jest zasada najmniejszych uprawnień: domyślnie brak dostępu, a każde rozszerzenie to świadoma decyzja z właścicielem i terminem ważności. Przejęte konto nie otwiera wtedy napastnikowi całego systemu, a jedynie wycinek przypisany do tej roli.
Jak zbudować audit trail i polityki retencji danych?
Rozliczalność zaczyna się od audit trail, czyli niezaprzeczalnego zapisu tego, kto, kiedy i co zrobił z danymi. W sektorze publicznym to nie wygoda, lecz dowód w razie kontroli, skargi obywatela albo postępowania. Budujemy więc logowanie tak, aby obejmowało odczyt i modyfikację danych wrażliwych, zmiany uprawnień i operacje administracyjne, a same logi były chronione przed edycją.
Z audytem nierozłącznie idą polityki retencji. Dane trzymane „na wszelki wypadek” bez końca to i ryzyko, i niezgodność z zasadą ograniczenia przechowywania. Ustalamy więc, jak długo żyje każda kategoria danych i logów, kiedy są archiwizowane, a kiedy trwale usuwane, i automatyzujemy te cykle, by zgodność nie zależała od tego, czy ktoś pamięta o czyszczeniu.
Jak zarządzać zgodami i danymi osobowymi zgodnie z RODO?
RODO w administracji ma swoją specyfikę: najczęściej podstawą przetwarzania jest przepis prawa lub zadanie publiczne, a nie zgoda. Tam jednak, gdzie zgody są potrzebne, muszą być zbierane świadomie, wersjonowane i możliwe do wycofania, a system musi pokazać, na jakiej podstawie i w jakim celu przetwarza dany rekord. Skupiamy się tu na mechanizmach, które realizują prawa obywatela i obowiązki administratora:
- rejestr czynności przetwarzania powiązany z realnymi funkcjami systemu, a nie prowadzony obok w arkuszu,
- obsługę praw osoby (dostęp, sprostowanie, usunięcie, przenoszenie) dostępną proceduralnie i technicznie,
- minimalizację i pseudonimizację tam, gdzie pełne dane nie są potrzebne do zadania,
- powiązanie zgód z celami, aby cofnięcie zgody faktycznie zatrzymywało dane przetwarzanie.
Dzięki temu zgodność z RODO wynika z działania systemu, a nie z dokumentacji po fakcie.
Po co instytucji regularne przeglądy ochrony danych?
Bezpieczeństwo nie jest stanem, który się osiąga i odhacza. Zmienia się prawo, ludzie, integracje i zagrożenia, więc układ szczelny rok temu dziś może mieć luki. Dlatego traktujemy przeglądy ochrony danych jako stały rytm, a nie reakcję na kontrolę: cyklicznie weryfikujemy nadane uprawnienia, analizujemy logi pod kątem nietypowych wzorców, sprawdzamy aktualność polityk retencji i testujemy procedury reakcji na incydent. Taki przegląd wychwytuje dryf, zanim zrobi się z niego incydent.
Jak podejść do zgodności z wymogami (KRI, NIS2)?
Instytucje poruszają się w gęstej siatce wymogów. Krajowe Ramy Interoperacyjności (KRI) narzucają standardy m.in. bezpieczeństwa informacji i dostępności systemów, a dyrektywa NIS2 podnosi poprzeczkę w zarządzaniu ryzykiem, zgłaszaniu incydentów i odpowiedzialności kierownictwa.
Nie traktujemy ich jako osobnych list kontrolnych. Większość sprowadza się do tych samych fundamentów: kontroli dostępu, rozliczalności, zarządzania ryzykiem i zdolności reakcji na incydent. Jeśli te podstawy są solidne, zgodność z kolejnym aktem to głównie udokumentowanie tego, co już działa, a nie przebudowa systemu. Doradzamy tu ogólnie i wspieramy wdrożenie techniczne, a interpretację prawną zostawiamy prawnikom instytucji.
Jakie kompetencje bezpieczeństwa dostarczamy do instytucji?
Tu jest sedno naszego modelu: nawet bez własnego działu bezpieczeństwa dostarczamy ludzi i kompetencje, którzy to robią. Obsadzamy konkretne role, dopasowane do etapu projektu i luk po Twojej stronie:
- inżynierów IAM i tożsamości, którzy projektują role, SSO, MFA i integrację ze źródłem kadrowym,
- architektów bezpieczeństwa, którzy spinają uwierzytelnianie, szyfrowanie, logowanie i retencję w spójny model,
- programistów znających wymogi sektora publicznego, piszących kod z myślą o audytowalności i ochronie danych,
- wsparcie w obszarze zgodności, tłumaczące wymogi KRI czy NIS2 na konkretne funkcje i konfiguracje.
Nie wyceniamy „bezpieczeństwa w ogóle”, tylko kompetencje, których naprawdę potrzebujesz.
Jak robimy to w RITS?
Robimy to jako partner nearshore z Polski, który rozumie realia administracji i wymóg rozliczalności:
- weryfikujemy kompetencje przed startem, a skład dobieramy pod specyfikę instytucji, a nie „na zapas”,
- opieramy się na doświadczeniu w prowadzeniu systemów i infrastruktury dla sektora publicznego oraz w projektach, gdzie bezpieczeństwo i kontrola dostępu były rdzeniem rozwiązania,
- wpinamy się w istniejące procedury i narzędzia instytucji, zamiast narzucać własny świat od zera, i pracujemy w zbliżonej strefie czasowej, więc przeglądy i reakcja na incydent idą bez opóźnień.
Najczęściej realizujemy to jako dedykowane oprogramowanie budowane przez nasz zespół, a tam, gdzie trzeba szybko uzupełnić konkretną kompetencję, w modelu wzmocnienia zespołu.
Od czego zacząć porządkowanie bezpieczeństwa i zgodności?
Zacznij od uczciwej odpowiedzi na dwa pytania: kto ma dziś dostęp do danych i na jakiej podstawie oraz czy jesteś w stanie odtworzyć, co się z nimi działo. Jeśli któraś odpowiedź brzmi „nie do końca”, to tam leży największe ryzyko i tam zaczynamy: od IAM i audit trail, a dopiero potem domykamy retencję, zgody i zgodność. Różnice między modelami współpracy opisaliśmy w artykule o modelach współpracy IT.
Chcesz uporządkować bezpieczeństwo i zgodność w swojej instytucji? Porozmawiajmy, dobierzemy kompetencje i podejście pod Twoje systemy i wymogi.