zasada najmniejszych uprawnień

Zasada najmniejszych uprawnień to reguła nadawania każdemu użytkownikowi, procesowi i usłudze tylko tych uprawnień, które są niezbędne do wykonania zadania, i tylko na czas jego trwania. NIST definiuje ją jako zasadę bezpieczeństwa, według której system ogranicza uprawnienia użytkowników i działających w ich imieniu procesów do minimum potrzebnego do wykonania powierzonych zadań ^[1]. Zasada dotyczy ludzi, kont serwisowych, kluczy API, baz danych i plików. Jest jednym z fundamentów modelu Zero Trust. W publikacji SP 800-53 Rev. 5 NIST ujmuje ją od strony architektury: każdy podmiot dostaje minimum zasobów systemowych i autoryzacji potrzebnych do pełnienia swojej funkcji ^[1].

Jak działa

Zasada odwraca domyślne podejście. Zamiast odbierać zbędne prawa, zaczyna się od zera i dodaje tylko potrzebne. OWASP ujmuje to jako przydzielanie użytkownikom minimalnych uprawnień koniecznych do wykonania pracy ^[4]. Zaleca też, by aplikacja domyślnie odmawiała dostępu ^[4]. Każde nadane uprawnienie powinno mieć uzasadnienie.

OWASP podkreśla, że zasada obowiązuje w dwóch wymiarach: poziomym i pionowym ^[4]. W poziomie osoby o różnych funkcjach potrzebują dostępu do różnych zasobów. W pionie różnica dotyczy zakresu uprawnień na kolejnych szczeblach.

Cykl stosowania zasady pokazuje schemat poniżej.

RYS. 1Utrzymanie najmniejszych uprawnień

MITRE w opisie słabości CWE-250 zaleca podnosić uprawnienia jak najpóźniej i porzucać je jak najwcześniej ^[2]. Kod wymagający wyższych uprawnień warto wydzielić i scentralizować, a dane wejściowe do niego sprawdzać szczególnie starannie ^[2]. Na tej idei opiera się dostęp just-in-time.

Zastosowania

Zasada ma zastosowanie na każdej warstwie systemu. Tabela zestawia typowe przykłady.

CERT Polska podaje przykład podziału: osobie od monitoringu wystarczy odczyt statusu i logów, operatorowi helpdesku prawo do odblokowania konta, a administratorowi aplikacji dostęp do jednej usługi ^[3]. Administrator jednego systemu nie powinien mieć dostępu do administracji innymi ^[3]. Typowy podział obejmuje trzy funkcje: operatora z dostępem tylko do odczytu, administratora zmieniającego konfigurację w wyznaczonym obszarze i audytora z wglądem w logi oraz historię zmian ^[3]. W systemach Windows tę samą ideę realizują delegacja uprawnień, Just Enough Administration i mechanizmy dostępu czasowego ^[3]. Organizacyjnym narzędziem zasady jest zarządzanie dostępem uprzywilejowanym (PAM), a technicznym model ról, taki jak RBAC.

W WordPressie

WordPress ma sześć predefiniowanych ról, od superadministratora po subskrybenta, a każda kolejna ma mniej uprawnień ^[5]. Subskrybent ma tylko uprawnienie read ^[5]. Typowe naruszenie zasady to nadawanie roli administratora osobom, które tylko piszą teksty. Wystarczy im rola autora albo współpracownika. Opis ról zawiera hasło role i uprawnienia użytkowników.

Na szczególną uwagę zasługuje uprawnienie unfiltered_html. Pozwala publikować HTML, a nawet JavaScript, a dokumentacja ostrzega, że nadanie go niezaufanym użytkownikom może skończyć się publikacją złośliwego kodu ^[5].

Zasada dotyczy też warstwy serwera. Podręcznik utwardzania WordPressa podaje, że użytkownik bazy danych MySQL potrzebuje tylko praw odczytu i zapisu: SELECT, INSERT, UPDATE i DELETE ^[6]. Prawa do struktury i administracji, takie jak DROP, ALTER i GRANT, można odebrać ^[6]. Podręcznik zastrzega, że aktualizacje wtyczek i głównych wersji WordPressa mogą wymagać zmian w schemacie bazy ^[6]. Pliki powinny należeć do konta użytkownika i być zapisywalne przez to konto ^[6]; zob. uprawnienia plików.

-- konto aplikacji WordPress tylko z prawami do danych
GRANT SELECT, INSERT, UPDATE, DELETE ON wp_example.* TO 'wp_app'@'localhost';

Tę samą logikę stosuje się do haseł aplikacji i kluczy integracji. Integracja, która tylko publikuje wpisy, powinna działać na koncie z rolą autora, a nie administratora.

Zagrożenia i skutki

MITRE opisuje CWE-250 jako wykonywanie operacji na poziomie uprawnień wyższym niż wymagane, co tworzy nowe słabości albo wzmacnia skutki innych ^[2]. Atakujący, który przejmie taki proces, uzyskuje dostęp do wszystkiego, na co pozwalają podwyższone uprawnienia: może wykonywać kod, wyłączać usługi i czytać zastrzeżone dane ^[2]. CERT Polska ujmuje to krótko: przydzielanie pełnych uprawnień „na wszelki wypadek” powiększa skutki każdej pomyłki i każdego przejętego konta ^[3].

Na stronie WordPress nadmiar uprawnień zamienia drobny błąd w poważny incydent. Przejęcie konta autora daje dostęp do wpisów. Przejęcie konta administratora daje dostęp do instalacji wtyczek i edytora plików, a przez nie do serwera. Zasada ogranicza też lateral movement i skutki eskalacji uprawnień.

Dobre praktyki

• Każdy administrator ma indywidualne konto, a konto do codziennej pracy jest oddzielone od administracyjnego ^[3].
• Kod działa z najniższymi uprawnieniami potrzebnymi do zadania, najlepiej na wydzielonych kontach o jednym przeznaczeniu ^[2].
• Tokeny dostępu są ograniczone do konkretnego serwera zasobów oraz konkretnych zasobów i akcji ^[7].
• Uprawnienia są sprawdzane przy każdym żądaniu ^[4]; w kodzie wtyczek służy do tego weryfikacja uprawnień.
• Lista kont z wysokimi rolami jest regularnie przeglądana, a nieużywane konta są usuwane.

Zasada nie zastępuje innych zabezpieczeń. Zmniejsza powierzchnię ataku i ogranicza szkody, gdy inne zabezpieczenia zawiodą.