Umowa powierzenia i podprocesorzy
Dostępny jest wzór umowy powierzenia przetwarzania danych oraz lista dostawców, którzy mogą uczestniczyć w świadczeniu usługi.
Zero-trust architecture
Architektura bezpieczeństwa
Bezpieczeństwo opisujemy przez konkretne mechanizmy, dokumenty i odpowiedzialności: od logowania, przez dostęp do danych, po ślad audytowy.
Pakiet bezpieczeństwa
Dokumenty dla kupującego dostępne na zapytanie
Przy rozmowie wdrożeniowej udostępniamy lub omawiamy materiały potrzebne do oceny ryzyka dostawcy. Nie publikujemy publicznie parametrów operacyjnych bez potwierdzenia zakresu usługi.
Hosting, kopie i odtwarzanie
Model hostingu, kopii zapasowych, przywracania usługi i dopuszczalnego zakresu utraty danych po awarii potwierdzamy dla konkretnego wdrożenia.
Procedura incydentu
Opisujemy kanał zgłoszenia, sposób kwalifikacji incydentu, role po stronie Brillnet i klienta oraz oczekiwany przebieg komunikacji.
Status systemu zarządzania
System zarządzania według ISO 27001 jest wdrożony. Certyfikacja nie jest obecnie planowana, a część dokumentów systemowych może być udostępniona klientom na zapytanie.
Tożsamość i dostęp
Uwierzytelnianie i autoryzacja bez domyślnego zaufania
Zewnętrzne uwierzytelnianie
Użytkownicy logują się przez zewnętrznego dostawcę tożsamości. Aplikacja nie przechowuje lokalnie haseł, a role wynikają z ustalonej odpowiedzialności w organizacji.
Role z delegacjami czasowymi
Dostęp można ograniczyć do konkretnego obszaru pracy i nadać go tylko na określony czas. Po wygaśnięciu delegacji uprawnienia wracają do poprzedniego zakresu.
Silnik uprawnień
Przed wykonaniem ważnej akcji system sprawdza, kto działa, na jakim obiekcie i w jakim celu. Brak jasnej podstawy dostępu powinien blokować wykonanie akcji.
Zatwierdzanie w modelu czterech oczu
Akcje o podwyższonym ryzyku mogą wymagać zatwierdzenia drugiej osoby. Decyzja, uzasadnienie i czas zatwierdzenia pozostają widoczne w historii procesu.
Ochrona danych
Szyfrowanie, klasyfikacja i suwerenność danych
Klasyfikacja danych
Dane są oznaczane według wrażliwości, na przykład jako publiczne, wewnętrzne, poufne albo osobowe. Pola wrażliwe mogą być ukrywane w interfejsie i w odpowiedziach systemu.
Klucze szyfrowania zarządzane przez klienta
Zakres zarządzania kluczami szyfrowania jest ustalany przy wdrożeniu. W modelu wymagającym większej kontroli klient może zarządzać własnymi kluczami albo uzgodnić osobny model obsługi kluczy.
Minimalne uprawnienia bazy danych
Dostęp techniczny do bazy danych jest ograniczany do zakresu potrzebnego danej części systemu. Testy przed wydaniem sprawdzają, czy nie pojawił się zbyt szeroki dostęp.
Bramka akceptacji eksportów
Eksport danych poufnych i osobowych może wymagać dodatkowej akceptacji. Jeżeli wymagane zgody nie są spełnione, eksport jest blokowany i zapisany w historii.
Ślad audytowy
Ślad audytowy z weryfikacją kryptograficzną
Dziennik zdarzeń z weryfikacją integralności
Dziennik zdarzeń zapisuje ważne akcje w kolejności, którą można później sprawdzić pod kątem integralności. Naruszenie ciągłości zapisu powinno uruchomić alert bezpieczeństwa.
Pakiet dowodowy z weryfikacją kryptograficzną
Pakiet dowodowy zawiera listę elementów, zakres danych i historię operacji. Dzięki temu audytor może sprawdzić, co zostało pokazane i z jakiego okresu pochodzi.
Izolacja danych organizacji
Dane organizacji są oddzielane od danych innych klientów oraz ograniczane przez polityki dostępu. Zakres izolacji jest potwierdzany w modelu wdrożenia.
Rejestr dostępu do dowodów i eksportów
Każde pobranie pakietu dowodowego, eksportu lub raportu pozostawia ślad: kto, kiedy, jaki zakres danych i w jakim celu.
Infrastruktura i wydania
Kontrole bezpieczeństwa przed udostępnieniem zmian
Bramka bezpieczeństwa
Przed wydaniem sprawdzane są zależności, znane podatności i podstawowe ryzyka bezpieczeństwa. Zmiany z wysokim ryzykiem nie powinny trafiać do wydania bez decyzji osoby odpowiedzialnej.
Kontrola używanych bibliotek
Lista bibliotek i ich wersji jest utrzymywana w sposób powtarzalny. Znane niebezpieczne wersje powinny być blokowane albo kierowane do szybkiej aktualizacji.
Bezpieczne logowanie błędów
Logi błędów powinny usuwać dane osobowe, tokeny dostępu i inne informacje wrażliwe. Celem jest diagnoza problemu bez ujawniania danych klienta.
Kontrola procesu logowania
Proces logowania jest monitorowany, ponieważ wpływa na dostęp do dowodów i odpowiedzialność użytkowników. Problemy z logowaniem są traktowane jako ryzyko operacyjne.
Ścieżka aktualizacji bezpieczeństwa
Istotne podatności mają przypisanego właściciela, status naprawy i decyzję o priorytecie. Dzięki temu aktualizacje bezpieczeństwa nie giną w zwykłej kolejce prac.
Bezpieczeństwo — FAQ
Standardowo zakładamy hosting danych w Unii Europejskiej. Dokładna lokalizacja, retencja i wymagania infrastrukturalne są potwierdzane w umowie wdrożeniowej.
Tak, jeżeli zostanie to uzgodnione w zakresie wdrożenia. Wtedy opisujemy, kto zarządza kluczami szyfrowania, jak wygląda ich wymiana i kto odpowiada za dostęp do nich.
Izolacja danych między organizacjami jest częścią testów przed wydaniem. Zakres kopii zapasowych, przywracania i odtworzenia po awarii potwierdzamy w ustaleniach wdrożeniowych.
Dziennik zdarzeń zapisuje ważne operacje w sposób pozwalający sprawdzić ciągłość historii. Naruszenie integralności zapisu powinno uruchomić alert i analizę bezpieczeństwa.
Pulsar GRC
Gotowy, żeby uporządkować ryzyka i zgodność?
Porozmawiajmy o procesie, który dziś wymaga najwięcej ręcznej pracy: wymagania, kontrole, dowody, CAPA, audyty i raportowanie.
Kontakt: [email protected]
