Zasada najmniejszych uprawnień – wyjaśnienie

Zasada najmniejszych uprawnień wydaje się oczywista, gdy się ją powie na głos: przyznaj kontu, procesowi lub użytkownikowi tylko dostęp, którego potrzebuje do wykonania swojej pracy, nic więcej. Luka między powiedzeniem tego a rzeczywistym uruchamianiem systemów w ten sposób to miejsce, gdzie większość naruszeń zmienia się z drobnego incydentu w pełne przejęcie domeny.

Co to faktycznie oznacza

Zasada najmniejszych uprawnień (PoLP) mówi, że każdy podmiot w systemie — użytkownik, konto usługi, aplikacja, kontener — powinien działać z minimalnym zestawem uprawnień wymaganym do ukończenia swojej funkcji. Nie uprawnień, które są wygodne. Nie uprawnień, które ktoś przyznał trzy lata temu i zapomniał odwołać. Minimalnym.

Dotyczy to każdej warstwy: uprawnień systemu plików, ról bazy danych, zakresów API, polityk IAM w chmurze, reguł zapory, dostępu sudo. Proces serwera WWW czytający pliki statyczne nie potrzebuje dostępu do zapisu do /etc. Skrypt raportowania, który uruchamia tylko zapytania SELECT, nie potrzebuje roli bazy danych z prawami DROP TABLE. Stażystka z marketingu nie powinna mieć uprawnień administratora domeny, bo było łatwiej niż ustalenie odpowiedniej grupy.

Dlaczego ma znaczenie większe, niż wydaje się

Kiedy atakujący przejmie konto lub proces, dziedziczy wszystko, co to konto potrafi robić. Jeśli laptop phishowanego pracownika ma dostęp tylko do udziałów plików istotnych dla jego zespołu, promień wybuchu tego phishingu jest ograniczony. Jeśli to samo konto ma prawa administratora domeny, ponieważ IT ustawiło go w ten sposób kiedyś do rozwiązywania problemów i nigdy tego nie wycofało, atakujący teraz posiada sieć.

To jest logika stojąca za większością raportów forensycznych po naruszeniu: początkowy dostęp miał niską wartość, ale ruchy boczne przez nadmiernie uprzywilejowane konta zamieniły go w ransomware w całym środowisku. Nadmiarowe uprawnienia nie powodują początkowego przejęcia, ale prawie zawsze to, co czyni przejęcie kosztownym.

Gdzie pojawia się to w praktyce

Cloud IAM. AWS, Azure i GCP domyślnie zachowują się permisywnie, jeśli nie będziesz ostrożny — polityka IAM z "Action": "*" i "Resource": "*" przejdzie walidację i będzie działać, aż do momentu, gdy wyciekły klucz dostępu da atakującemu pełną kontrolę nad kontem. Zamiast tego ograniczaj polityki do określonych działań i ARN zasobów zamiast sięgać po znaki wieloznaczne.

Konta usług. To często najgorsi przestępcy, ponieważ nikt ich nie przegląda w taki sposób, jak przegląda konta ludzkie. Pipeline CI/CD, który wdraża do jednego wiadra S3, nie powinien przechowywać poświadczeń, które mogą czytać każde wiadro na koncie.

Role bazy danych. Oddziel role raportowania tylko do odczytu od ról aplikacji, które potrzebują INSERT/UPDATE, i oddziel je od roli DBA, która może zmieniać schemat. Zarówno PostgreSQL, jak i MySQL obsługują szczegółowe instrukcje GRANT — używaj ich zamiast dawać każdemu połączeniu aplikacji odpowiednik roota.

Sudo i dostęp administratora lokalnego. Podniesienie uprawnień just-in-time (żądaj dostępu, uzyskaj go na ograniczony czas, stracił automatycznie) zawsze bije stałe prawa administratora. Narzędzia takie jak sudo z czasowo ograniczonymi regułami lub rozwiązania PAM w środowiskach korporacyjnych istnieją właśnie do tego celu.

Napięcie z