Dostęp just-in-time a dostęp stały: na czym polega różnica?

Czym jest dostęp stały

Dostęp stały to domyślny sposób działania uprawnień. Konto dostaje zestaw praw, które zostają przy nim, dopóki ktoś świadomie ich nie usunie. Uprawnienie utrzymuje się mimo kolejnych logowań, mimo miesięcy nieaktywności i mimo zmian w tym, czym dana osoba faktycznie zajmuje się na co dzień.

Kilka typowych przykładów:

• Inżynier zostaje dodany do grupy administratorów, żeby mógł obsłużyć incydent produkcyjny, i zostaje w tej grupie długo po zamknięciu incydentu.
• Konto serwisowe powstaje z szerokimi prawami „na wszelki wypadek" na czas migracji i nigdy nie zostaje przycięte.
• Pracownik zmienia zespół, zachowuje cały stary dostęp i dostaje nowy na dokładkę, więc uprawnienia narastają z czasem. Ten dryf bywa nazywany access creep albo privilege creep.

Cechą definiującą jest to, że uprawnienie jest domyślnie włączone, a wyłączane tylko wyjątkowo. Nikt nie musi nic robić, żeby dostęp pozostał aktywny. On po prostu jest.

Czym jest dostęp just-in-time

Dostęp just-in-time odwraca ten domyślny stan. Uprawnienie jest domyślnie wyłączone, a włączane tylko wyjątkowo, na ograniczony czas.

W praktyce przepływ JIT wygląda tak:

• Osoba prosi o podwyższony dostęp do konkretnego systemu, zwykle podając powód.
• Prośba jest sprawdzana, automatycznie względem polityki albo przez osobę zatwierdzającą.
• Po zatwierdzeniu uprawnienie jest nadawane na ustalony czas, na przykład godzinę albo jedną zmianę roboczą.
• Gdy czas mija, uprawnienie jest usuwane automatycznie. Bez zadania porządkowego, bez kwartalnego przeglądu, który miałby to wyłapać.

Ta sama osoba może poprosić ponownie następnym razem, gdy będzie tego potrzebować. Różnica jest taka, że między tymi prośbami konto w ogóle nie ma tego uprawnienia. Nie ma nic stałego, co atakujący mógłby na nim znaleźć.

Dokładniejsze omówienie tego, jak JIT jest wnioskowany, zatwierdzany, ograniczany zakresem i logowany, znajdziesz w powiązanym przewodniku „Dostęp just-in-time".

Dlaczego stałe uprzywilejowanie samo w sobie jest problemem

Kusi, żeby uznać stałe uprawnienie za nieszkodliwe, dopóki osoba, która je ma, jest godna zaufania. Problem w tym, że uprawnienie nie należy wyłącznie do tej osoby. Należy do każdego, kto kontroluje dane konto.

Kiedy atakujący przejmuje konto, przez skradzione hasło, wyłudzoną sesję, malware albo wykorzystane ponownie hasło, nie dostaje osoby. Dostaje uprawnienia konta. Każde prawo, które to konto ma, jest dla niego natychmiast dostępne, bez żadnego dodatkowego kroku. Jeśli te prawa są stałe, atakujący dziedziczy je w momencie przejęcia konta i zachowuje je tak długo, jak długo utrzymuje nad nim kontrolę.

Dlatego stałe uprzywilejowanie jest ryzykiem niezależnym od tego, jak dochodzi do naruszenia. Naruszenie decyduje o tym, czy konto zostaje przejęte; dostęp stały decyduje o tym, ile szkód to przejęcie może wyrządzić. Przejęte konto bez wysokowartościowych uprawnień na stałe to mniejszy problem niż przejęte konto, które od razu sięga do produkcji, płatności albo danych klientów.

Stałe uprzywilejowanie ma też tendencję do cichego narastania. Uprawnienia są dodawane, kiedy są potrzebne, a rzadko usuwane, kiedy przestają być potrzebne, więc zbiór stale dostępnych praw z czasem rośnie. Im dłużej uprawnienie stoi nieużywane, tym większa szansa, że nikt nie pamięta, po co powstało i czy wciąż jest zasadne, co czyni je zarówno ekspozycją bezpieczeństwa, jak i problemem audytowym.

Co dostęp just-in-time zmienia, a czego nie zmienia

JIT zmienia jedną konkretną rzecz: jak długo wysokowartościowe uprawnienie jest dostępne. Zamiast być dostępne bez przerwy, jest dostępne tylko w nadanych oknach czasowych. To skraca okres, w którym przejęte konto może korzystać z tego uprawnienia, z „zawsze" do „rzadkich chwil, gdy dostęp jest aktywny".

To operacyjna forma zasady least privilege. NIST definiuje least privilege jako ograniczenie dostępu podmiotu do minimum niezbędnego do wykonania przypisanych zadań (CNSSI 4009-2015; NIST SP 800-53 Rev. 5). O least privilege zwykle mówi się w kategoriach zakresu, czyli tego, ile rzeczy obejmuje dane uprawnienie. JIT dodaje wymiar czasu: minimum nie tylko w zakresie, ale i w czasie trwania. NIST SP 800-207, publikacja o architekturze zero trust, mówi o tym samym, traktując dostęp jako coś nadawanego na poziomie sesji, z minimalnymi uprawnieniami potrzebnymi do wykonania zadania, a nie jako stałe przypisanie. Zakresową stronę least privilege omawia powiązany przewodnik o least privilege.

Warto jasno powiedzieć, czego JIT nie robi. Nie uwierzytelnia nikogo za ciebie, więc słabe uwierzytelnianie albo brak drugiego składnika wciąż jest słabym punktem w momencie żądania dostępu. Nie decyduje, na co dana osoba powinna mieć pozwolenie; kontroluje tylko, kiedy już podjęta decyzja o uprawnieniu jest aktywna. I nie usuwa potrzeby ścisłego ograniczania zakresu uprawnień. Nadanie JIT, które jest zbyt szerokie, wciąż jest zbyt szerokie, dopóki jest aktywne. JIT i ograniczanie zakresu w duchu least privilege działają razem, jedno nie zastępuje drugiego.

Zero standing privilege jako stan docelowy

Obok JIT często pojawia się określenie zero standing privilege. Opisuje ono cel: stan, w którym żadne konto nie ma na stałe wysokowartościowych uprawnień. Każde działanie uprzywilejowane wymaga jawnego, ograniczonego czasowo nadania, a między nadaniami do konta nie jest przypięte nic wrażliwego, co mógłby wykorzystać atakujący.

Zero standing privilege to cel podróży; dostęp just-in-time to droga, którą się do niego dochodzi. Do zera stałego uprzywilejowania dochodzisz, przenosząc uprawnienia z trwałych przypisań do nadań na żądanie, które wygasają. Większość organizacji nie osiąga tego dla każdego uprawnienia i nie musi. Wartość koncentruje się w uprawnieniach o największym blast radius i to tam eliminowanie dostępu stałego ma największe znaczenie.

Konto awaryjne (break-glass): zaplanowany wyjątek na wypadek sytuacji nadzwyczajnych

Usunięcie dostępu stałego rodzi oczywistą obawę: co się dzieje w prawdziwej sytuacji nadzwyczajnej, kiedy sam system zatwierdzania jest niedostępny, albo gdy ktoś potrzebuje dostępu natychmiast i nie ma czasu na zwykłą prośbę? Do tego służy dostęp break-glass.

Break-glass to wcześniej ustalona, celowo wyjątkowa ścieżka do podwyższonego dostępu na prawdziwe sytuacje nadzwyczajne. Nazwa pochodzi od szklanej skrzynki nad alarmem przeciwpożarowym: jest tam, można jej użyć, ale użycie jej jest zdarzeniem, które zwraca uwagę. Dobrze zaprojektowana procedura break-glass ma zwykle kilka cech:

• Jest zarezerwowana na prawdziwe sytuacje nadzwyczajne, a kwalifikujące się sytuacje są zdefiniowane z góry.
• Jej użycie uruchamia natychmiastowy alert, więc dostęp jest widoczny dla innych w momencie, gdy zostaje wzięty, a nie odkrywany później.
• Jest dokładnie logowana, więc istnieje jasny zapis, kto jej użył, kiedy i w jakim celu.
• Każde użycie jest później sprawdzane, żeby potwierdzić, że było uzasadnione.

Break-glass nie służy do utrzymywania dostępu stałego pod inną nazwą. Dane uwierzytelniające za nim stojące są chronione, monitorowane i mają leżeć nieużywane. Konto break-glass, z którego korzysta się rutynowo, po cichu staje się z powrotem dostępem stałym, co niweczy cały sens. Chodzi o kontrolowaną furtkę awaryjną, żeby usunięcie codziennego stałego uprzywilejowania nie zostawiło cię bez wyjścia, gdy coś naprawdę się posypie.

Gdzie pasuje który model

Żaden z modeli nie jest właściwy wszędzie. Sensowne podejście to dopasowanie modelu do ryzyka.

Dostęp stały jest uzasadniony przy pracy niskiego ryzyka i wysokiej częstotliwości, gdzie koszt ciągłego ponownego nadawania byłby wysoki, a blast radius uprawnienia mały. Dostęp handlowca do własnych rekordów w CRM, dostęp pracownika do dysku współdzielonego, z którego zespół korzysta cały dzień, zwykła poczta i kalendarz: sprawianie, że wygasają co godzinę, tworzyłoby tarcie przy niewielkim zysku dla bezpieczeństwa.

Dostęp just-in-time sprawdza się przy uprawnieniach uprzywilejowanych, wrażliwych albo rzadko używanych. Administracja systemami produkcyjnymi, dostęp do danych klientów albo danych finansowych, zmiany w infrastrukturze chmurowej, narzędzia bezpieczeństwa i wszelkie stałe prawa kont serwisowych albo kontraktorów to naturalni kandydaci. To dokładnie te uprawnienia, przy których przejęcie robi najwięcej szkód, i dokładnie te, z których korzysta się okazjonalnie, a nie stale, więc model na żądanie pasuje do faktycznego wzorca użycia.

Praktyczny sposób podjęcia decyzji to zadanie dwóch pytań o dane uprawnienie: jak źle będzie, jeśli zostanie nadużyte, i jak często jest faktycznie używane? Uprawnienia o wysokim wpływie, używane okazjonalnie, to najmocniejszy argument za JIT. Uprawnienia o niskim wpływie, używane stale, to najsłabszy argument, i zwykle w porządku jest zostawić je jako stałe, z normalnym monitoringiem. Większość realnych środowisk kończy jako mieszanka, z JIT stosowanym selektywnie, a nie wszędzie.

Tabela porównawcza

• Stan domyślny · Dostęp stały: Uprawnienie włączone, usuwane wyjątkowo · Dostęp just-in-time: Uprawnienie wyłączone, nadawane wyjątkowo
• Dostępność · Dostęp stały: Ciągła, na stałe do momentu odwołania · Dostęp just-in-time: Ograniczona do ustalonego okna czasowego
• Nadawanie · Dostęp stały: Raz, a potem trwa dalej · Dostęp just-in-time: Na każdą prośbę, za każdym razem, gdy jest potrzebne
• Usuwanie · Dostęp stały: Ręczne albo w ramach okresowego przeglądu · Dostęp just-in-time: Automatyczne po zakończeniu okna
• Ekspozycja przy przejęciu konta · Dostęp stały: Cały zestaw uprawnień dostępny natychmiast · Dostęp just-in-time: Tylko to, co aktywne w ramach bieżącego nadania
• Relacja do least privilege · Dostęp stały: Często dryfuje ponad to, co potrzebne · Dostęp just-in-time: Wymusza minimalny zakres i minimalny czas trwania
• Obraz audytowy · Dostęp stały: Statyczny, nieużywane prawa się kumulują · Dostęp just-in-time: Każde nadanie to zalogowane zdarzenie ze znacznikiem czasu
• Najlepiej pasuje do · Dostęp stały: Codziennego dostępu niskiego ryzyka i wysokiej częstotliwości · Dostęp just-in-time: Dostępu uprzywilejowanego, wrażliwego albo okazjonalnego
• Obsługa sytuacji nadzwyczajnych · Dostęp stały: I tak zawsze dostępna · Dostęp just-in-time: Obsługiwana osobną ścieżką break-glass

Źródła

• NIST CSRC Glossary, least privilege (definition from CNSSI 4009-2015, NIST SP 800-53 Rev. 5, NIST SP 800-171r3) · https://csrc.nist.gov/glossary/term/least_privilege (definicja least privilege używana w całym tekście)
• NIST SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations · https://doi.org/10.6028/NIST.SP.800-53r5 (least privilege jako mechanizm kontrolny i zasada projektowa)
• NIST SP 800-207, Zero Trust Architecture · https://csrc.nist.gov/pubs/sp/800/207/final (dostęp nadawany na poziomie sesji, z minimalnymi uprawnieniami potrzebnymi do zadania, zamiast jako stałe przypisanie)