Zarządzanie tożsamością w chmurze rozstrzyga się na granicy współdzielonej odpowiedzialności: dostawca utrzymuje mechanizm uwierzytelniania i autoryzacji, a organizacja odpowiada za to, komu nadaje uprawnienia i kto to zatwierdza. Ten artykuł porządkuje tę granicę, rodzaje polityk oraz nazwane role, które muszą istnieć po stronie zespołu.
Na skróty
Czego dowiesz się z artykułu:
- Gdzie kończy się odpowiedzialność dostawcy chmury za dostęp do Twoich danych
- Czym różnią się polityki oparte na tożsamości od polityk opartych na zasobie
- Dlaczego zasada najmniejszych uprawnień jest procesem, a nie ustawieniem
- Które role w zespole muszą być rozdzielone, żeby przegląd dostępów cokolwiek znaczył
Dla kogo jest ten artykuł:
- Administratorzy środowisk chmurowych i osoby nadające uprawnienia
- Liderzy zespołów rozwijających usługi w chmurze publicznej
- Osoby odpowiadające za zgodność i audyt dostępów w organizacji
Czas czytania: 7 minut
Gdzie kończy się odpowiedzialność dostawcy
Model współdzielonej odpowiedzialności opisany w aws.amazon.com rozdziela bezpieczeństwo chmury od bezpieczeństwa w chmurze: dostawca odpowiada za infrastrukturę, na której działa usługa, a klient za konfigurację tej usługi, za dane i za zarządzanie tożsamościami oraz dostępem. Granica jest wyraźniejsza, niż bywa odbierana — i dokładnie po stronie klienta leży to, co w incydentach zawodzi najczęściej.
Praktyczny test tej granicy jest prosty: jeśli ustawienie da się zmienić w konsoli, jest Twoje. Dostawca nie wie, czy konto usługowe powinno czytać ten zasobnik, bo to wynika z celu biznesowego, a nie z architektury usługi. Nie wie też, czy osoba, która odeszła w zeszłym miesiącu, nadal ma dostęp — ten fakt zna wyłącznie Twój proces kadrowy.
Stąd wniosek organizacyjny, nie techniczny: migracja do chmury nie zmniejsza pracy związanej z tożsamością, a przenosi ją z konfiguracji urządzeń na proces nadawania i odbierania uprawnień. Zespół, który nie zbudował tego procesu przed migracją, zbuduje go po pierwszym audycie.
Rodzaje polityk i o czym każda rozstrzyga
Dokumentacja cloud.google.com o zarządzaniu tożsamością i dostępem opisuje model przyznawania ról na zasobach w hierarchii: uprawnienia są grupowane w role, role przypisywane są podmiotom na określonym poziomie hierarchii, a przypisanie jest dziedziczone w dół. To rozróżnienie jest ważniejsze, niż wygląda, bo większość nadmiarowych uprawnień w chmurze powstaje z dziedziczenia, a nie z jawnej decyzji.
Drugi podział dotyczy miejsca, w którym polityka żyje. Polityka oparta na tożsamości jest dołączona do użytkownika, grupy albo konta usługowego i mówi, co ten podmiot może robić. Polityka oparta na zasobie jest dołączona do samego zasobu i mówi, kto może z nim pracować — także spoza Twojej organizacji. Pierwsza odpowiada na pytanie „co wolno tej osobie”, druga na pytanie „kto ma dostęp do tego zasobnika”, i to drugie pytanie jest tym, które zadaje audytor.
Zasada najmniejszych uprawnień wchodzi tu jako proces, nie jako ustawienie. Przewodnik learn.microsoft.com o dobrych praktykach dla ról katalogu tożsamości formułuje to w nazwanych krokach: przypisuj najmniej uprzywilejowaną rolę wystarczającą do zadania, włączaj uprawnienia uprzywilejowane na czas wykonywania zadania mechanizmem Privileged Identity Management, ogranicz liczbę trwałych przypisań roli administratora globalnego i wymagaj uwierzytelniania wieloskładnikowego dla kont administracyjnych. Każdy z tych kroków jest sprawdzalny zapytaniem do katalogu, więc nadaje się na kryterium przeglądu.
Role w zespole: kto nadaje, kto zatwierdza, kto przegląda
Rozdzielenie obowiązków jest tu całą treścią. Jeśli ta sama osoba nadaje uprawnienie i zatwierdza jego nadanie, przegląd dostępów jest formalnością — i taki właśnie przegląd zamyka się w organizacjach zielono przez lata.
Rozkład, który działa, ma nazwane funkcje. Właściciel zasobu rozstrzyga, kto potrzebuje dostępu i w jakim celu, bo to on odpowiada za dane. Administrator tożsamości wykonuje nadanie i utrzymuje spójność katalogu, ale sam nie decyduje o zakresie. Osoba zatwierdzająca jest po stronie biznesu i poświadcza cel, a nie technikę. Inspektor ochrony danych wchodzi tam, gdzie dostęp dotyczy danych osobowych i rozstrzyga o podstawie przetwarzania. W zespołach utrzymujących usługi dochodzi inżynier dyżurny z dostępem podnoszonym na czas incydentu — i ten dostęp musi mieć własny, krótszy termin ważności niż stałe przypisanie.
Konta usługowe zasługują na osobną uwagę, bo nie mają właściciela z definicji. Konto usługowe bez przypisanej osoby odpowiedzialnej przetrwa każdy przegląd, bo nikt nie potwierdzi, że przestało być potrzebne. Wpis w rejestrze musi nazywać właściciela, system, który z konta korzysta, i warunek, po którym konto da się wyłączyć.
Uwierzytelnianie i to, czego nie nadrobi polityka
Polityki rozstrzygają o autoryzacji, czyli o tym, co wolno już uwierzytelnionemu podmiotowi. Jeśli uwierzytelnianie da się obejść, autoryzacja nie ma znaczenia — dlatego ten krok stoi przed poprzednimi, choć w projektach bywa dokładany na końcu.
Dokument csrc.nist.gov SP 800-63B-4 porządkuje to po stronie standardu: definiuje poziomy pewności uwierzytelnienia, dzieli uwierzytelniacze na kategorie i stawia wymagania dla uwierzytelniania wieloskładnikowego oraz dla zarządzania uwierzytelniaczami w ich cyklu życia. Dla zespołu oznacza to konkret: wybór składnika nie jest kwestią wygody, a kwestią poziomu, który chcecie osiągnąć dla danego dostępu.
Czego nie nadrobi żadna polityka: dostępu nadanego poza procesem, klucza dostępu zapisanego w repozytorium i konta współdzielonego przez zespół. Ostatnie jest najgorsze, bo niszczy rozliczalność w całym łańcuchu — wpis w dzienniku wskazuje konto, a nie człowieka, więc po incydencie nie da się ustalić, kto wykonał operację.
Czytaj także
- Zarządzanie tożsamością i dostępem — jak efektywnie zarządzać uprawnieniami — proces nadawania i odbierania uprawnień w organizacji
- Zero Trust — architektura bezpieczeństwa bez zaufanej sieci — model, w którym tożsamość zastępuje granicę sieciową
- Bezpieczeństwo aplikacji low-code w organizacji — checklista wdrożenia — te same uprawnienia widziane od strony aplikacji budowanej poza IT
Rozwijaj kompetencje
Temat rozwijają szkolenia Zarządzanie tożsamością i dostępem (IAM) oraz Zero Trust Security — SASE, mikrosegmentacja i identity management. Pierwsze porządkuje proces i narzędzia zarządzania dostępem, drugie pokazuje, jak tożsamość przejmuje rolę granicy bezpieczeństwa. Skontaktuj się z nami, żeby dopasować zakres do architektury Waszego środowiska.
Najczęściej zadawane pytania (FAQ)
Czy dostawca chmury odpowiada za to, komu dałem dostęp do danych?
Nie. Model współdzielonej odpowiedzialności przypisuje dostawcy bezpieczeństwo infrastruktury, a klientowi konfigurację usług, dane i zarządzanie dostępem. Nadanie uprawnienia, jego zakres i moment odebrania są po stronie klienta — także wtedy, gdy uprawnienie nadało się przez dziedziczenie w hierarchii zasobów, a nie jawną decyzją.
Jak wdrożyć zasadę najmniejszych uprawnień bez blokowania pracy zespołu?
Zaczynając od uprawnień uprzywilejowanych, nie od wszystkich. Stałe przypisania ról administracyjnych zamieniasz na podnoszone na czas zadania, a dopiero potem schodzisz do uprawnień zwykłych, opierając się na faktycznym użyciu. Odwrotna kolejność — zacieśnianie wszystkiego naraz — kończy się falą zgłoszeń i wycofaniem całej zmiany.
Co zrobić z kontami usługowymi, których nikt nie pamięta?
Przypisać każdemu właściciela i warunek wyłączenia, a te bez właściciela najpierw odciąć od uprawnień uprzywilejowanych, nie usuwać od razu. Usunięcie konta, z którego korzysta nieudokumentowana integracja, jest awarią; odebranie mu uprawnień ponad potrzebne jest testem, który tę integrację ujawni bez zatrzymania usługi.
Czy przegląd dostępów musi być okresowy?
Okresowy przegląd jest minimum wymaganym przez audyt, ale sam w sobie opisuje stan sprzed kilku tygodni. Przeglądy użyteczne wyzwala zdarzenie: zmiana roli pracownika, odejście z organizacji, dodanie nowego zasobu z danymi osobowymi, zakończenie projektu. Kalendarz jest siatką bezpieczeństwa dla zdarzeń, których proces nie wychwycił.