zabezpieczenie
dostęp uprzywilejowany
Nadzór nad kontami, które mogą zmieniać systemy, czytać wszystko albo wyłączać zabezpieczenia. Przepisy oczekują silnego logowania, osobnych kont administracyjnych i regularnego przeglądu tego, kto ma te prawa.
- co chroni
- kilka kont, które mogą zmieniać systemy, czytać wszystko albo wyłączać zabezpieczenia
- kto za to odpowiada
- szef IT
- zacznij od
- wyeksportuj listę ról administracyjnych i przypisz właściciela każdej
czym jest
Dostęp uprzywilejowany to konta, które mogą zmieniać systemy, czytać wszystko albo wyłączać zabezpieczenia: administratorzy domeny i serwerów, właściciele konsol chmurowych, administratorzy baz danych i każdy, kto obsługuje dostawcę tożsamości. Jest ich niewielu, a napastnik, który przejmie jedno, nie potrzebuje drugiego.
Przepisy oczekują od nich trzech prostych rzeczy. Silnego logowania, osobnego konta do administrowania i przeglądu w zaplanowanych odstępach, kto ma te prawa. NIS2 i DORA podają zasadę. Rozporządzenie wykonawcze dla wymienionych dostawców usług cyfrowych rozpisuje kroki i jest rozsądnym punktem odniesienia dla pozostałych.
Zacznij od listy. Policz role administracyjne u dostawcy tożsamości i w pięciu najważniejszych systemach, przypisz każdemu nazwisku właściciela i powód, a resztę usuń. Narzędzia, które trzymają hasła w sejfie, nadają prawa na czas albo nagrywają sesje, należą do tego obszaru. Czy potrzebujesz któregoś, zależy od tego, jak długa jest lista po porządkach.
podstawa NIS2 art. 21(2)(i); IR 2024/2690 załącznik 11.3.2, 11.3.3 jako punkt odniesienia. Kategorie narzędzi to praktyka.
jak używa się roli administracyjnej i jak się ją odbiera
- 1zwykłe kontopoczta i przeglądanie stron, bez praw administratora
- 2prośba o rolęna zadanie i okno czasowe, ze wskazaną osobą zatwierdzającą
- 3silne logowanieosobne konto administracyjne z drugim składnikiem
- 4działanie i zapissesja lub log zmian pokazuje, co zrobiono
- 5koniec prawodebrane, gdy zadanie się kończy lub okno się zamyka
lista osób z rolami jest eksportowana i przeglądana w ustalonym rytmie
podstawa praktyka robocza. Żaden tekst prawny tego nie ustala.
przykład
Wyobraź sobie firmę z 200 osobami i kontami administracyjnymi rozsianymi po dostawcy tożsamości, serwerach i konsoli chmurowej.
Administratorzy czytają pocztę i przeglądają strony tym samym kontem, na którym mają swoje prawa. Jedno hasło do bazy zna kilka osób. Wykonawca z dawnego projektu nadal ma rolę i nikt nie umie powiedzieć dlaczego.
Każdy administrator ma osobne konto administracyjne, używane tylko do administrowania i chronione drugim składnikiem. Przy każdym nazwisku na liście ról stoi właściciel i powód. Prawa są nadawane na zadanie i odbierane, gdy się kończy, a wspólne hasło leży w sejfie z zapisem każdego użycia.
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. | Prowadź listę każdego konta z uprawnieniami administratora, z wskazanym właścicielem każdego, i zatwierdź politykę, która nimi rządzi. |
| IR 2024/2690 | IR 2024/2690 załącznik 11.3.2(a) | Wymienieni dostawcy usług cyfrowych: silne uwierzytelnianie, takie jak MFA, dla kont uprzywilejowanych. | Wymuś drugi składnik dla każdej roli administracyjnej i miej raport, kto jest zarejestrowany. |
| IR 2024/2690 | IR 2024/2690 załącznik 11.3.2(b) | Wymienieni dostawcy usług cyfrowych: konta używane wyłącznie do administrowania systemami. | Daj każdemu administratorowi osobne konto administracyjne, którego nie używa do poczty ani przeglądania stron. |
| IR 2024/2690 | IR 2024/2690 załącznik 11.3.3 | Wymienieni dostawcy usług cyfrowych: przegląd praw uprzywilejowanych w zaplanowanych odstępach i udokumentowanie wyniku. | Wybierz odstęp, przeglądaj według niego listę administratorów i zachowaj podpisany zapis. |
| DORA | DORA art. 9(4)(c) | Ograniczenie dostępu fizycznego i logicznego do tego, czego potrzebują zatwierdzone funkcje. | Przyznawaj najwęższą rolę, która wystarcza do zadania, i odbieraj prawa, gdy zadanie się kończy. |
| RODO | RODO art. 32(1)(b) | Stała poufność systemów przetwarzania, dobrana do ryzyka. | Traktuj administratorów systemów z danymi osobowymi jako konta o najwyższym ryzyku. |
podstawa NIS2 art. 21(2)(i); IR 2024/2690 załącznik 11.3.2(a), 11.3.2(b), 11.3.3 jako punkt odniesienia; DORA art. 9(4)(c); RODO art. 32(1)(b). To, co zabezpieczenie ma robić, jest praktyką.
na co patrzeć przy wyborze
- Czy da się prowadzić osobne konto administracyjne dla każdej osoby i pokazać, do którego zwykłego konta należy?
- Czy prawa można nadać na zadanie i okno czasowe, a potem odebrać automatycznie?
- Czy wymusza drugi składnik, najlepiej taki, którego nie da się oszukać fałszywą stroną, zanim użyje się roli administracyjnej?
- Tam, gdzie nie da się uniknąć kont współdzielonych lub wbudowanych, czy hasło można trzymać w sejfie i zmieniać po każdym użyciu?
- Czy zapisuje, co administrator robił w sesji, i kto może ten zapis czytać?
- Czy jednym raportem pokażesz każdego, kto ma rolę administracyjną w głównych systemach?
- Czy obejmuje konsole chmurowe i samego dostawcę tożsamości, czy tylko serwery?
- Jaki jest udokumentowany sposób wejścia, gdy narzędzie nie działa?
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 każdą rolę administracyjną u dostawcy tożsamości i w pięciu najważniejszych systemach. Przypisz każdemu nazwisku właściciela i powód, a resztę usuń.
- solidnie
Daj każdemu administratorowi osobne konto z drugim składnikiem, przeglądaj listę według ustalonego rytmu i zachowuj podpisany wynik.
- mocno
Nadawaj prawa na zadanie i okno czasowe, trzymaj nieuniknione wspólne hasła w sejfie, nagrywaj sesje administratorów i testuj drogę wejścia na wypadek awarii narzędzia.
podstawa praktyka robocza. Żaden tekst prawny tego nie ustala.
gdzie się psuje
prawa administratora na zwykłym koncie
Administrator, który czyta pocztę i przegląda strony tym samym kontem, daje wiadomości phishingowej klucze. Rozdziel te dwie role.
lista, której nikt nie umie wytłumaczyć
Prawa dodane na potrzeby projektu i nigdy nieodebrane się kumulują. Jeśli nie umiesz powiedzieć, dlaczego nazwisko jest na liście, nie powinno go tam być.
współdzielone hasła administracyjne
Hasło znane kilku osobom nie pokaże, kto co zrobił. Tam, gdzie jest nieuniknione, trzymaj je w sejfie i zapisuj każde użycie.
zapomniane konta wbudowane i serwisowe
Przegląd ludzi pomija konta, które do nikogo nie należą, jak konta serwisowe i dostęp dostawców. Zachowują prawa latami, jeśli nikt ich nie ma na swojej liście.
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 |
|---|---|---|
| eksport z datą: osoby z rolami administracyjnymi w głównych systemach | szef IT | co kwartał |
| lista administratorów porównana ze zwykłymi kontami, pokazująca, że są osobne | szef IT | co kwartał |
| raport rejestracji drugiego składnika dla ról administracyjnych | szef IT | co kwartał |
| podpisany przegląd praw uprzywilejowanych z usunięciami | szef IT | co kwartał (Twój wybór) |
| próbka logu zmian ról administracyjnych | szef IT | co roku |
podstawa practice. Częstotliwości to Twój wybór; rozporządzenie wykonawcze mówi o zaplanowanych odstępach.
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
Wyeksportuj dziś listę ról administracyjnych i zaznacz każde nazwisko, którego nie umiesz wytłumaczyć.