Przejęte konto jest niebezpieczne ze względu na to, co może zrobić po początkowym włamaniu. Jeśli skradzione dane logowania użytkownika zapewniają dostęp do każdego serwera, administrator agencji może zmienić każde środowisko klienta, a konto usługi może usunąć kopie zapasowe, jeden incydent może doprowadzić do awarii całej firmy.
Zasada najmniejszych uprawnień to praktyczny sposób na ograniczenie zasięgu takiego incydentu. Każda tożsamość otrzymuje wyłącznie dostęp wymagany do wykonania bieżącego zadania, na możliwie najkrótszy uzasadniony czas i w najmniejszym możliwym zakresie. Gdy konto zostanie przejęte, atakujący dziedziczy te ograniczenia, zamiast otrzymać swobodną drogę przez całe środowisko.
Najmniejsze uprawnienia nie są pojedynczym ustawieniem. Obejmują kontrolę dostępu, kontrolę dostępu opartą na rolach, silne uwierzytelnianie, projekt sieci, przeglądy uprawnień, monitorowanie i planowanie odtwarzania danych. Wymagają również dyscypliny w odniesieniu do kont, które często są pomijane: tożsamości usług, kluczy API, awaryjnych kont administratorów i danych uwierzytelniających do kopii zapasowych.
Co właściwie ogranicza zasada najmniejszych uprawnień
Dostęp ma kilka wymiarów. Użytkownik może mieć możliwość logowania się do serwera, ale nie odczytywać określonego katalogu. Administrator może zarządzać jednym środowiskiem klienta, ale nie innym. Konto bazy danych może odczytywać wybrane tabele, ale nie zmieniać schematów ani tworzyć nowych użytkowników. Proces tworzenia kopii zapasowej może zapisywać dane potrzebne do odtwarzania, ale nie usuwać istniejących punktów przywracania.
Dlatego przydatna decyzja dotycząca dostępu powinna uwzględniać cztery pytania:
- Kto żąda dostępu: wskazany pracownik, administrator, usługa, API czy konto awaryjne?
- Jaki zasób jest objęty dostępem: serwer, baza danych, system plików, konsola zarządzania czy repozytorium kopii zapasowych?
- Jakie działania są potrzebne: odczyt, zapis, wykonywanie, konfiguracja, tworzenie, usuwanie czy odtwarzanie?
- Kiedy i skąd dostęp powinien być ważny?
Najmniejsze uprawnienia ograniczają niepotrzebne kombinacje tych uprawnień. Nie gwarantują, że konto nie zostanie przejęte, ani nie zastępują instalowania poprawek, ochrony punktów końcowych czy monitorowania sieci. Ich wartość polega na ograniczaniu skutków: atakujący, który zdobędzie jedną tożsamość, powinien napotkać rzeczywiste granice.
Rozdziel role przed przydzieleniem uprawnień
Rozdzielenie ról to jeden z najskuteczniejszych sposobów, aby zapobiec przekształceniu przejętego konta w nieograniczone konto administratora. Mała firma może rozdzielić zwykłą pracę, administrację serwerami, administrację kopiami zapasowymi oraz dostęp do finansów lub danych klientów. Agencja może potrzebować osobnych ról dla własnej infrastruktury i każdego środowiska klienta.
Kontrola dostępu oparta na rolach sprawia, że te granice można stosować w powtarzalny sposób. Zamiast przyznawać uprawnienia bezpośrednio poszczególnym osobom, zdefiniuj role takie jak operator serwera, użytkownik odczytujący bazę danych, inżynier wdrożeń, audytor bezpieczeństwa i operator kopii zapasowych. Przypisz ludzi do potrzebnych im ról, a następnie przeglądaj definicje ról wraz ze zmianami systemów.
Nie traktuj kontroli dostępu opartej na rolach jako powodu do utworzenia jednej, zbyt szerokiej roli o nazwie administrator. Rola powinna odzwierciedlać rzeczywistą funkcję zawodową i ograniczony zakres. Na przykład inżynier wdrożeń może ponownie uruchamiać określoną usługę aplikacji i aktualizować jej katalog wydań, ale nie powinien móc tworzyć użytkowników systemu operacyjnego ani usuwać kopii zapasowych bazy danych.
Utrzymuj oddzielne tożsamości administratorów
Osoby administrujące serwerami powinny zwykle mieć standardowe konto do poczty e-mail, przeglądania internetu i rutynowej pracy oraz oddzielną uprzywilejowaną tożsamość do administracji. Zmniejsza to ryzyko, że atak phishingowy na konto używane na co dzień natychmiast ujawni uprawnienia administratora.
Tożsamości administracyjne powinny być imienne, możliwe do przypisania konkretnej osobie i indywidualnie chronione. Wspólne dane uwierzytelniające administratora odbierają możliwość rozliczania działań i utrudniają cofnięcie dostępu. Jeśli to samo hasło zna kilka osób, jego zmiana podczas incydentu staje się uciążliwa, a dzienniki nie pokazują wiarygodnie, kto wykonał daną czynność.
Gdy wspólne konto awaryjne jest nieuniknione, przechowuj je pod kontrolą w odpowiednim sejfie danych uwierzytelniających, wymagaj udokumentowanego pobrania, rejestruj użycie i zmieniaj dane uwierzytelniające po uzyskaniu dostępu. Powinno być wyjątkiem na potrzeby odtwarzania działania, a nie standardowym sposobem administrowania serwerami przez zespół.
Stosuj dostęp just-in-time do uprzywilejowanych zadań
Stałe uprawnienia tworzą stałą okazję dla atakującego. Dostęp just-in-time ogranicza to ryzyko, przyznając podwyższone uprawnienia wyłącznie wtedy, gdy wymaga tego zadanie. Zatwierdzenie może być ręczne lub automatyczne, ale powinno określać system docelowy, żądaną rolę, powód i czas trwania.
Inżynier wsparcia może otrzymać dostęp do jednego serwera produkcyjnego na 45 minut, aby zbadać awarię usługi. Po upływie tego czasu uprawnienie powinno zniknąć bez konieczności pamiętania o jego odebraniu. W przypadku wrażliwych działań wymagaj, aby druga osoba zatwierdziła dostęp lub samą zmianę.
Dostęp ograniczony czasowo jest szczególnie przydatny dla agencji. Deweloper może potrzebować tymczasowego dostępu do serwera klienta podczas wdrożenia, a zewnętrzny specjalista — jednorazowego dostępu diagnostycznego. Żaden z nich nie powinien bezterminowo zachowywać szerokiego dostępu do wszystkich środowisk klientów.
Dostęp awaryjny powinien podlegać tej samej zasadzie, nawet gdy liczy się szybkość. Utrzymuj niewielką liczbę kont awaryjnych o ściśle określonym zakresie, z silnym uwierzytelnianiem i niezależnymi metodami odzyskiwania. Generuj alert za każdym razem, gdy jedno z nich zostanie użyte, rejestruj powód i — w miarę możliwości — wykonywane polecenia, a następnie natychmiast przeanalizuj zdarzenie. Proces awaryjny, który nigdy nie był testowany, nie jest procesem niezawodnym, dlatego testuj go bez stałego udostępniania danych uwierzytelniających.
Dopasuj uwierzytelnianie do zasady najmniejszych uprawnień
Hasło jedynie potwierdza, że ktoś zna sekret. Nie ogranicza tego, co dana tożsamość może zrobić po zalogowaniu. Najmniejsze uprawnienia i uwierzytelnianie rozwiązują różne problemy: MFA pomaga zapobiec nieautoryzowanemu dostępowi, natomiast kontrola dostępu ogranicza szkody, jeśli dostęp zostanie uzyskany.
Stosuj MFA dla administratorów, VPN, chmury, kopii zapasowych i innych kont o dużym wpływie. Tam, gdzie środowisko na to pozwala, preferuj metody odporne na phishing i nie traktuj SMS-ów jako jedynej ochrony krytycznej administracji. Wymuszaj odrębne zasady uwierzytelniania dla uprzywilejowanych tożsamości, zamiast pozwalać im dziedziczyć najsłabsze zasady stosowane wobec zwykłych użytkowników.
Cofanie danych uwierzytelniających musi być szybkie i przećwiczone. Prowadź ewidencję użytkowników, kluczy SSH, tokenów API, certyfikatów, danych uwierzytelniających usług i integracji zewnętrznych. Gdy istnieje podejrzenie przejęcia konta:
- Wyłącz lub zawieś tożsamość i unieważnij aktywne sesje.
- Usuń jej członkostwo w grupach, klucze, tokeny i delegowane uprawnienia.
- W stosownych przypadkach zablokuj znane adresy źródłowe lub urządzenia, nie zakładając, że to wystarczy.
- Zmień sekrety, które konto mogło odczytać, wykorzystać lub ujawnić.
- Przejrzyj dzienniki pod kątem aktywności przed cofnięciem dostępu i po nim.
Nie polegaj wyłącznie na zmianie hasła. Atakujący mógł już utworzyć inne konto, skopiować token API, dodać klucz SSH lub uzyskać trwały dostęp za pośrednictwem zaplanowanego zadania.
Ograniczaj konta usług i dostęp do API
Kontom usług często przyznaje się nadmierne uprawnienia, ponieważ działają bez obecności człowieka. To częsty punkt awarii: aplikacja musi odczytywać jedną bazę danych, ale jej konto może administrować każdą bazą na serwerze. Token wdrożeniowy musi publikować jedną aplikację, ale może modyfikować system operacyjny.
Twórz osobne tożsamości usług dla poszczególnych aplikacji i środowisk. Dane uwierzytelniające produkcji, środowiska testowego i programistycznego nie powinny być wymienne. Każdej tożsamości przyznaj wyłącznie uprawnienia wymagane do jej działania i zabroń logowania interaktywnego kontom, które powinny służyć wyłącznie do uruchamiania usług.
W przypadku API ograniczaj tokeny według operacji, punktu końcowego, środowiska, sieci źródłowej i czasu wygaśnięcia. Przechowuj sekrety poza kodem aplikacji i zmieniaj je zgodnie z ustalonym harmonogramem lub po zmianie personelu. Monitoruj nietypowy wolumen, pochodzenie geograficzne, nieudane żądania i próby użycia API poza jego przeznaczeniem.
Nie zakładaj, że konto usługi jest bezpieczne tylko dlatego, że żaden człowiek nie zna jego hasła. Złośliwe oprogramowanie działające na serwerze aplikacji może być w stanie użyć jego danych uwierzytelniających, a podatna aplikacja może pozwolić atakującemu działać za pośrednictwem tożsamości usługi. Uprawnienia konta muszą więc być na tyle wąskie, aby ograniczyć tę drogę ataku.
Stosuj najmniejsze uprawnienia na serwerach, w systemach plików i bazach danych
Stosuj zasady sudo zamiast nieograniczonego dostępu root
W systemach Linux używaj indywidualnych kont i starannie zdefiniowanych reguł sudo, zamiast przyznawać każdemu administratorowi nieograniczony dostęp root. Osoba, która musi jedynie ponownie uruchomić usługę, nie powinna automatycznie otrzymywać uprawnień do edycji plików uwierzytelniania, instalowania pakietów czy usuwania dzienników.
Określaj dozwolone polecenia, a tam, gdzie to praktyczne, także dozwolone argumenty i hosty docelowe. Zachowaj ostrożność w przypadku poleceń uruchamiających edytory, powłoki lub skrypty, ponieważ pozornie wąska reguła może pośrednio prowadzić do pełnego dostępu root. Przeglądaj zasady sudo jako kod lub konfigurację, testuj je i usuwaj tymczasowe reguły po zakończeniu zadania.
Kontroluj uprawnienia systemu plików
Rozdziel kod aplikacji, konfigurację, przesyłane treści, dzienniki i kopie zapasowe. Proces sieciowy może potrzebować zapisu do katalogu przesyłania plików, ale nie powinien móc modyfikować wykonywalnego kodu ani odczytywać prywatnych plików konfiguracyjnych zawierających dane uwierzytelniające. Procesy baz danych nie powinny mieć ogólnego dostępu do niezwiązanych z nimi katalogów domowych użytkowników.
W stosownych przypadkach używaj własności, grup, list kontroli dostępu i izolacji usług. Zwracaj uwagę na uprawnienia dziedziczone: nowy katalog lub konto może przypadkowo otrzymać dostęp za pośrednictwem szerokiej grupy nadrzędnej. Testuj uprawnienia z użyciem rzeczywistej tożsamości usługi, a nie tylko konta administratora, które może zobaczyć wszystko.
Ograniczaj uprawnienia baz danych
Użytkowników baz danych należy rozdzielać według aplikacji i funkcji. Konto raportowe może potrzebować dostępu SELECT do określonych widoków, a konto aplikacji — odczytu i aktualizacji wybranych tabel, ale nie zmiany schematu, tworzenia użytkowników ani usuwania danych. Administracyjny dostęp do bazy powinien być zarezerwowany dla niewielkiej grupy i realizowany za pomocą imiennych tożsamości.
Jeśli architektura aplikacji na to pozwala, rozdziel dane uwierzytelniające do odczytu i zapisu. Ograniczaj połączenia z bazą według hosta lub segmentu sieci, szyfruj połączenia i rejestruj operacje administracyjne. Jeśli aplikacja internetowa zostanie przejęta, wąskie uprawnienia bazy danych mogą uniemożliwić atakującemu przekształcenie przyczółka w aplikacji w nieograniczone niszczenie danych.
Stosuj segmentację sieci jako kolejną granicę uprawnień
Uprawnienia tożsamości nie wystarczą, jeśli każdy serwer może swobodnie łączyć się z każdym innym. Segmentuj sieci i definiuj jawne reguły ruchu między urządzeniami użytkowników, serwerami aplikacji, bazami danych, interfejsami zarządzania i systemami kopii zapasowych.
Serwer frontendowy może potrzebować dostępu do portu aplikacji, a aplikacja — do portu bazy danych. Żaden z nich nie musi mieć dostępu SSH do każdej maszyny. Interfejsy zarządzania powinny być osiągalne wyłącznie zatwierdzonymi ścieżkami administracyjnymi, takimi jak kontrolowany VPN lub sieć zarządzania. Repozytoria kopii zapasowych nie powinny być szeroko dostępne z obciążeń produkcyjnych.
Segmentacja ogranicza możliwość poruszania się atakującego po sieci po przejęciu konta lub serwera. Ułatwia również wykrywanie nietypowej aktywności: próba połączenia serwera WWW z interfejsem zarządzania lub stacji roboczej z repozytorium kopii zapasowych powinna uruchomić dochodzenie.
Chroń kopie zapasowe przed przejętymi kontami produkcyjnymi
Kopia zapasowa dostępna za pośrednictwem tego samego konta lub serwera, który chroni, może zostać zniszczona podczas ataku. Oprogramowanie ransomware często próbuje znaleźć oprogramowanie do tworzenia kopii, repozytoria i dane uwierzytelniające, zanim zaszyfruje dane produkcyjne. Odtwarzanie zależy od oddzielenia dostępu do kopii zapasowych od administracji produkcją.
Używaj dedykowanej tożsamości kopii zapasowych o możliwie najmniejszych uprawnieniach. Konto produkcyjne nie powinno móc usuwać, zmieniać ani skracać okresu przechowywania danych kopii zapasowych. Jeśli projekt na to pozwala, administracja kopiami powinna korzystać z oddzielnej ścieżki zarządzania, oddzielnych danych uwierzytelniających i MFA. Dostęp do odtwarzania również powinien być kontrolowany: osoby obsługujące produkcję nie potrzebują automatycznie uprawnień do usuwania historii kopii zapasowych.
W przypadku serwerów kontrolowanych przez klienta firma Safenix zapewnia zewnętrzną kopię zapasową szyfrowaną kluczem, którego Safenix nigdy nie posiada, przechowywaną w Niemczech i niezmienną przez cały okres retencji. Taki podział ma znaczenie, gdy przejęte konto serwera może uszkodzić środowisko produkcyjne. Więcej informacji znajdziesz tutaj: jak Safenix chroni szyfrowane kopie zapasowe i kontroluje, kto może je odczytywać.
Safenix chroni serwery biznesowe kontrolowane przez klientów. Nie zapewnia planu tworzenia kopii zapasowych dla stron działających na hostingu współdzielonym, gdzie klient nie kontroluje serwera bazowego. To rozróżnienie jest ważne przy ocenie, czy projekt kopii zapasowych rzeczywiście może odizolować dane potrzebne do odtworzenia od danych uwierzytelniających produkcji.
Przeglądaj dostęp stale, a nie tylko raz w roku z przyzwyczajenia
Uprawnienia się kumulują. Pracownicy zmieniają role, agencje kończą projekty, kontraktorzy odchodzą, a tymczasowy dostęp diagnostyczny staje się stały. Nieaktywne konta są szczególnie atrakcyjne dla atakujących, ponieważ mogą nadal mieć przydatne uprawnienia, ale poświęca się im niewiele uwagi.
Prowadź ewidencję dostępu obejmującą:
- Imienne konta użytkowników i administratorów
- Grupy, role i delegowane uprawnienia
- Klucze SSH, tokeny API, certyfikaty i sekrety aplikacji
- Konta usług i zaplanowane zadania
- Zewnętrzne agencje, kontraktorów i dostawców wsparcia
- Tożsamości awaryjne i break-glass
- Konta kopii zapasowych, monitoringu i zarządzania infrastrukturą
Przeglądaj dostęp po dołączeniu pracownika, zmianie jego roli lub odejściu, po zakończeniu projektu oraz po dużych zmianach infrastruktury. Zaplanowany przegląd może odbywać się co miesiąc w przypadku dostępu uprzywilejowanego i co kwartał w przypadku szerszego dostępu, przy częstotliwości dostosowanej do ryzyka. Poproś właściciela zasobu o potwierdzenie nie tylko tego, że konto należy do właściwej osoby, lecz także że każde uprawnienie jest nadal konieczne.
Agencje powinny unikać dziedziczonych uprawnień między środowiskami klientów. Technik obsługujący Klienta A nie powinien otrzymywać roli, która automatycznie zapewnia dostęp do Klientów B, C i D. W miarę możliwości używaj oddzielnych dzierżaw, kont, grup, kluczy lub zakresów zarządzania. Jeśli centralne narzędzia utrudniają separację, traktuj to jako ryzyko projektowe, zamiast uznawać szeroki dostęp za nieunikniony.
Monitoruj użycie uprawnień i zachowuj dowody
Najmniejsze uprawnienia działają najlepiej, gdy można obserwować sposób ich wykorzystywania. Rejestruj uwierzytelnianie, podnoszenie uprawnień, zmiany ról, nowe klucze, tworzenie tokenów, zmiany uprawnień, administrację bazami danych i działania dotyczące kopii zapasowych. Zapisuj tożsamość, cel, czas, źródło, rezultat oraz — w stosownych przypadkach — zgłoszenie lub zatwierdzenie powiązane z działaniem.
Przesyłaj ważne dzienniki poza administrowane systemy, aby atakujący nie mógł po cichu zmienić dowodów. Chroń dostęp do dzienników za pomocą oddzielnych uprawnień i określ okres przechowywania wspierający dochodzenie oraz potrzeby prawne lub regulacyjne. Zsynchronizowany czas na serwerach znacznie ułatwia korelację zdarzeń.
Monitorowanie powinno koncentrować się na istotnych sygnałach, a nie generować alerty, z którymi nikt nie jest w stanie sobie poradzić. Przykłady obejmują:
- Nadanie zwykłemu użytkownikowi roli administratora
- Użycie konta awaryjnego poza zadeklarowanym incydentem
- Interaktywne logowanie za pomocą konta usługi
- Użycie tokenu z nieznanej sieci lub o nietypowej porze
- Duże zmiany uprawnień w wielu środowiskach klientów
- Próby uzyskania dostępu do danych kopii zapasowych, ich usunięcia lub zmiany
Po uruchomieniu alertu zachowaj odpowiednie dzienniki, historię poleceń, rejestry uwierzytelniania i stan systemu przed wprowadzeniem zmian, które mogłyby zniszczyć dowody. Jednocześnie nie opóźniaj ograniczania incydentu w oczekiwaniu na idealne zebranie materiału do analizy kryminalistycznej. Zapisz, co zmieniono, przez kogo i kiedy, a w przypadku poważnych zdarzeń współpracuj z wykwalifikowanym zespołem reagowania na incydenty.
Typowe luki, które należy wyeliminować
Wiele programów opartych na najmniejszych uprawnieniach zawodzi z powodu skrótów operacyjnych, a nie technicznej niemożności. Zwróć uwagę na następujące schematy:
- Wspólne dane uwierzytelniające administratora: uniemożliwiają wiarygodne przypisanie działań, utrudniają odbieranie dostępu i sprawiają, że szybkie unieważnienie staje się uciążliwe.
- Stały dostęp agencji: dostawca może potrzebować okazjonalnego dostępu do jednego serwera, a nie stałego dostępu do każdego środowiska klienta.
- Nieaktywne konta: stare konta pracowników, kontraktorów i testowe mogą zachować cenne uprawnienia długo po zakończeniu ich przeznaczenia.
- Dziedziczone uprawnienia: szerokie grupy i zagnieżdżone role mogą po cichu zapewniać dostęp do klientów, serwerów lub magazynów danych.
- Jedno konto do każdej funkcji: połączenie uprawnień wdrożeniowych, bazodanowych, systemowych i dotyczących kopii zapasowych tworzy jeden cel o bardzo dużym wpływie.
- Tymczasowe wyjątki, które nigdy nie wygasają: awaryjne reguły sudo, otwarcia zapory i tokeny API potrzebują właścicieli oraz automatycznych dat zakończenia.
- Zarządzanie kopiami zapasowymi z produkcji: jeśli ten sam administrator może zmieniać zarówno systemy działające, jak i dane potrzebne do odtworzenia, atakujący również może uzyskać taką możliwość.
W ramach dalszych analiz zapoznaj się z praktycznymi wskazówkami dotyczącymi zasady najmniejszych uprawnień i przejętych kont, a następnie odnieś te pomysły do systemów i obowiązków, które rzeczywiście funkcjonują w Twojej firmie.
Praktyczne priorytety dla małych firm i agencji
Małe zespoły nie potrzebują rozbudowanej platformy tożsamości, aby osiągnąć znaczącą poprawę. Zacznij od spisania krytycznych systemów i tożsamości, które mogą nimi administrować, modyfikować je lub je usuwać. Usuń wspólne dane uwierzytelniające, wyłącz nieaktywne konta i wymagaj MFA przy dostępie uprzywilejowanym.
Następnie rozdziel uprawnienia produkcyjne, administracyjne i dotyczące kopii zapasowych. Utwórz imienne konta administratorów, ogranicz tożsamości usług, zawęź uprawnienia użytkowników baz danych i ogranicz ścieżki sieciowe między serwerami. Dodaj proces zatwierdzania i wygaszania dostępu zewnętrznego, nawet jeśli początkowo będzie opierał się tylko na zgłoszeniu i przypomnieniu w kalendarzu.
Na koniec przetestuj reakcję. Czy możesz szybko odebrać pracownikowi dostęp? Czy możesz usunąć członka agencji bez wpływu na innych klientów? Czy potrafisz ustalić, które konto zmieniło regułę zapory? Czy możesz odtworzyć dane, jeśli administrator produkcji zostanie przejęty? Jeśli odpowiedź jest niejasna, luka nie dotyczy wyłącznie kontroli dostępu — jest również problemem odporności.
Najmniejsze uprawnienia mogą powodować niewielkie utrudnienia przy nietypowych zadaniach. To utrudnienie jest przydatne, gdy powstrzymuje zwykłe konta przed wykonywaniem destrukcyjnych działań. Projektuj rozsądne role, zapewniaj szybkie podnoszenie uprawnień just-in-time i utrzymuj kontrolowany dostęp awaryjny. Celem nie jest blokowanie legalnych operacji. Chodzi o to, aby jedna skradziona tożsamość nie stała się uprawnieniem do przejęcia kontroli nad firmą.