zabezpieczenie
SSO i katalog tożsamości
Jedno miejsce, w którym mieszkają tożsamości i w którym zapada decyzja o wpuszczeniu kogoś. Pozwala wymusić przyjęcia, odejścia i MFA w jednym punkcie, a jednocześnie staje się systemem, którego nie możesz stracić.
- co chroni
- każde logowanie do każdej podłączonej aplikacji, z jednego miejsca
- kto za to odpowiada
- szef IT
- zacznij od
- wypisz aplikacje, które nadal trzymają własne hasła, i najważniejsze podłącz najpierw
czym jest
Katalog to lista tożsamości: każda osoba, jej grupy i prawa, które z nich wynikają. SSO (jednokrotne logowanie) to usługa, która raz decyduje, czy ktoś może wejść, i przekazuje tę decyzję podłączonym aplikacjom. Razem są jednym miejscem, w którym zakłada się przychodzących, wyłącza odchodzących i wymusza drugi składnik.
W tym leży zysk. Jedno wyłączone konto przestaje działać we wszystkich podłączonych aplikacjach, a jedno ustawienie obejmuje wszystkich. Kosztem jest koncentracja. Gdy usługa nie działa, nie działa wszystko za nią, a napastnik, który ją przejmie, trzyma klucze do całości.
Traktuj ją więc jako najlepiej chroniony system, jaki prowadzisz. Ogranicz grono jej administratorów, miej przetestowaną awaryjną drogę wejścia, rób kopie jej konfiguracji i testuj odtwarzanie. Żaden przepis nie wskazuje produktu. Oczekują wyników: jedna osoba na tożsamość, silne logowanie, log zmian i ciągłość.
podstawa NIS2 art. 21(2)(i), 21(2)(j), 21(2)(c); IR 2024/2690 załącznik 11.5.2(b) jako punkt odniesienia. To, co zabezpieczenie ma robić, jest praktyką.
skąd bierze się tożsamość i gdzie jest uznawana
- zdarzenia: przyjęcie, zmiana, odejście
- tożsamości i grupy
- decyzja o logowaniu
- logi logowań i zmian
podstawa praktyka robocza. Żaden tekst prawny tego nie ustala.
przykład
Wyobraź sobie firmę ze 120 osobami, która trzyma konta w poczcie, w narzędziu finansowym i w dwóch aplikacjach biznesowych, każde z własnym hasłem.
Odchodzący zostaje wyłączony w poczcie, a w trzech aplikacjach pozostaje aktywny. Drugi składnik obejmuje pocztę i nic poza nią. Jedno konto awaryjne założono lata temu i nikt nie wie, czy jego hasło jeszcze działa.
Każda osoba istnieje w katalogu raz, zasilanym z systemu HR, a główne aplikacje ufają jednej usłudze logowania, która wymusza drugi składnik. Wyłączenie konta zatrzymuje je wszędzie. Konto awaryjne jest testowane w ustalonym dniu, a jego użycie włącza alarm.
To ilustracja, a nie opis prawdziwego przypadku.
co musi robić dla każdego przepisu
| przepis | gdzie | czego wymaga tekst | co musi robić zabezpieczenie |
|---|---|---|---|
| NIS2 | NIS2 art. 21(2)(i) | Bezpieczeństwo zasobów ludzkich, polityki kontroli dostępu i zarządzanie aktywami. | Trzymaj tożsamość każdego pracownika w jednym katalogu, tak by odchodzącego wyłączyć raz i wszędzie, gdzie ten katalog jest zaufany. |
| NIS2 | NIS2 art. 21(2)(j) | MFA lub uwierzytelnianie ciągłe, w stosownych przypadkach. | Wymuszaj drugi składnik w usłudze logowania, tak by każda podłączona aplikacja go dziedziczyła. |
| NIS2 | NIS2 art. 21(2)(c) | Ciągłość działania, taka jak zarządzanie kopiami zapasowymi i odtwarzanie po awarii, oraz zarządzanie kryzysowe. | Zaplanuj sytuację, w której usługa tożsamości nie działa: kopie, druga ścieżka administratora i przetestowany sposób wejścia. |
| IR 2024/2690 | IR 2024/2690 załącznik 11.5.2(b) | Wymienieni dostawcy usług cyfrowych: powiązanie tożsamości użytkownika z jedną osobą. | Upewnij się, że każde konto odpowiada jednej wskazanej osobie, zgodnie z listą z HR. |
| IR 2024/2690 | IR 2024/2690 załącznik 11.2.2(f) | Wymienieni dostawcy usług cyfrowych: rejestrowanie zarządzania prawami dostępu. | Zapisuj, kto zmienił które prawa, i przechowuj log tak długo, jak postanowisz. |
| DORA | DORA art. 9(4)(d) | Polityki i protokoły silnego uwierzytelniania. | Ustaw zasady logowania raz, w katalogu, i pokaż, że są egzekwowane. |
| RODO | RODO art. 32(1)(b) | Stała poufność systemów przetwarzania, dobrana do ryzyka. | Chroń katalog jako system, który strzeże dostępu do wszystkiego, co zawiera dane osobowe. |
podstawa NIS2 art. 21(2)(i), 21(2)(j), 21(2)(c); IR 2024/2690 załącznik 11.5.2(b), 11.2.2(f) jako punkt odniesienia; DORA art. 9(4)(d); RODO art. 32(1)(b). To, co zabezpieczenie ma robić, jest praktyką.
na co patrzeć przy wyborze
- Które z Twoich aplikacji mogą się z nim połączyć, a które nadal trzymają własne hasła?
- Czy wymusza drugi składnik i ustawione przez Ciebie warunki logowania, takie jak urządzenie, lokalizacja czy ryzyko, dla każdej podłączonej aplikacji?
- Czy możesz wyłączyć jedno konto, by każda podłączona aplikacja przestała je przyjmować, i jak szybko?
- Czy jest zasilany z systemu HR, czy ktoś zakłada konta ręcznie?
- Jak usługa jest odporna na awarię i czy dotrzesz do własnej konsoli administratora, gdy ona padnie?
- Czy jest konto awaryjne (break-glass), trzymane poza zwykłym logowaniem, z alarmem przy użyciu i regularnie testowane?
- Czy możesz wyeksportować listę użytkowników, przynależność do grup i log zmian?
- Czy da się odejść: czy dane można wyeksportować w standardowej formie?
podstawa praktyka robocza. Żaden tekst prawny tego nie ustala.
trzy poziomy, od pierwszego kroku do mocnego
Każdy poziom dodaje coś widocznego. Zatrzymaj się tam, gdzie pozwala na to ryzyko, które akceptujesz.
- start
Wypisz aplikacje, które trzymają własne hasła, podłącz najważniejsze do usługi logowania i porównaj listę użytkowników z listą z HR.
- solidnie
Zasilaj katalog z systemu HR, wymuszaj drugi składnik i warunki logowania centralnie, wycofaj każdą drugą listę kont i miej kopię konfiguracji.
- mocno
Ogranicz grono administratorów katalogu, alarmuj i testuj konto awaryjne (break-glass) według harmonogramu, raz w roku testuj odtworzenie katalogu i sprawdź, czy dane da się wyeksportować w standardowej formie.
podstawa praktyka robocza. Żaden tekst prawny tego nie ustala.
gdzie się psuje
pojedynczy punkt awarii bez planu
Jeśli usługa logowania nie działa, nie działa wszystko, co za nią stoi. Zapisz, jak wchodzisz, przetestuj to i miej kopię konfiguracji.
konto awaryjne, którego nikt nie sprawdził
Konto awaryjne z zagubionym hasłem albo wygasłym składnikiem zawodzi w dniu, w którym jest potrzebne. Testuj je według harmonogramu i alarmuj każde użycie.
dwa katalogi, które się nie zgadzają
Drugie źródło kont, pozostałe po fuzji lub pilotażu, utrzymuje odchodzących jako aktywnych. Znajdź drugą listę i wycofaj ją.
aplikacje poza systemem
System z własnymi lokalnymi hasłami stoi poza każdą regułą, którą egzekwujesz centralnie. Wypisz je i zdecyduj o każdym.
podstawa praktyka robocza. Żaden tekst prawny tego nie ustala.
dowód, który zostawia
| co możesz pokazać | kto jest właścicielem | odświeżanie |
|---|---|---|
| lista aplikacji podłączonych do usługi logowania i tych, które nie są | szef IT | co kwartał |
| eksport użytkowników porównany z listą z HR | szef IT | co kwartał |
| ustawienia wymuszania drugiego składnika i warunków logowania | szef IT | co kwartał |
| procedura konta awaryjnego z datą ostatniego testu | szef IT | co roku |
| test odtworzenia katalogu | szef IT | co roku |
podstawa practice. Częstotliwości to Twój wybór.
sprawdź sam
- Dyrektywa (UE) 2022/2555 (NIS2) (EUR-Lex)
- Rozporządzenie wykonawcze Komisji (UE) 2024/2690 (EUR-Lex)
- Rozporządzenie (UE) 2022/2554 (DORA) (EUR-Lex)
- Rozporządzenie (UE) 2016/679 (RODO) (EUR-Lex)
twój następny krok
Wypisz aplikacje, które nadal trzymają własne hasła, i zdecyduj, którą podłączyć najpierw.