Принцип найменшої привілеї, Пояснено

Принцип найменшої привілеї звучить очевидно, коли його озвучиш: дай акаунту, процесу або користувачеві тільки той доступ, який йому потрібен для його роботи, нічого більше. Різниця між тим, щоб це сказати, та тим, щоб насправді так запустити свої системи, це саме те місце, де більшість бреш перетворюються з невеликого інциденту на повний компроміс домену.

Що це насправді означає

Принцип найменшої привілеї (PoLP) каже, що кожен суб'єкт в системі — користувач, сервісний акаунт, програма, контейнер — повинен працювати з мінімальним набором дозволів, необхідних для виконання його функції. Не дозволи, які зручні. Не дозволи, що хтось дав три роки тому й забув відозвати. Мінімальний набір.

Це стосується кожного рівня: дозволи файлової системи, ролі баз даних, API scopes, cloud IAM політики, правила firewall, доступ через sudo. Процес web server, який читає статичні файли, не потребує прав на запис в /etc. Скрипт звіту, який запускає тільки SELECT запити, не потребує ролі бази даних з правами DROP TABLE. Стажер з маркетингу не потребує domain admin прав тільки тому, що це було простіше, ніж з'ясовувати правильну групу.

Чому це важливіше, ніж звучить

Коли зловмисник компрометує акаунт або процес, він успадковує все, що цей акаунт може робити. Якщо ноутбук фішованого працівника має доступ тільки до файлових ресурсів, релевантних його команді, радіус вибуху цієї фішинг-атаки обмежено. Якщо цей самий акаунт має права domain admin тому, що IT налаштував його таким чином один раз для усунення неполадок і ніколи не скасував, зловмисник тепер контролює всю мережу.

Це логіка, яка стоїть за більшістю звітів про форензику після брешей: перший доступ був низької цінності, але бічний рух через надмірно дозволені акаунти перетворив його в ransomware по всьому середовищу. Надлишкова привілей не викликає першопочатковий компроміс, але це майже завжди те, що робить компроміс дорогим.

Де це з'являється на практиці

Cloud IAM. AWS, Azure, GCP — всі за замовчуванням мають дозвільну поведінку, якщо ти не будеш обережний — IAM політика з "Action": "*" та "Resource": "*" пройде валідацію і працюватиме добре, до того моменту, коли витік ключа доступу дасть зловмисникові повний контроль над акаунтом. Обмежи політики конкретними діями та resource ARNs замість використання wildcards.

Сервісні акаунти. Це часто найгірші порушники, тому що ніхто їх не перевіряє так, як перевіряють людські акаунти. Конвеєр CI/CD, який розгортається в один S3 bucket, не повинен мати облікові дані, що можуть читати кожен bucket в акаунті.

Ролі баз даних. Розділи ролі, які тільки читають звіти, від ролей додатків, що потребують INSERT/UPDATE, і розділи їх від DBA ролі, що може змінювати схему. PostgreSQL та MySQL обидва підтримують детальні GRANT вирази — використовуй їх замість того, щоб давати кожному з'єднанню додатку еквівалент root.

Sudo та локальний адмін. Just-in-time підвищення (запрос доступу, отримай його на обмежене вікно, втрати його автоматично) переважає постійні права адміністратора щоразу. Інструменти як sudo з часово обмеженими правилами, або PAM рішення в корпоративних середовищах, існують саме для цього.

Напруження з