Принцип наименьших привилегий

Материал проходит ревью.

НовичокФундамент ~34 мин

Границы темы

Scope: как ограничить полномочия пользователя, сервиса, процесса и оператора ровно теми действиями, ресурсами, условиями и временем, которые нужны для задачи.

Не рассматриваем: синтаксис конкретного IAM и подробное сравнение RBAC/ABAC. Сначала нужна переносимая модель, иначе сложный policy-язык лишь точнее выразит неверное решение.

Что нужно знать заранее

Нужно уметь назвать сценарий угрозы и его blast radius. Статья «Эшелонированная защита» показывает, почему ограничение последствий остаётся важным после обхода prevention.

Результаты обучения

После статьи читатель сможет:

1. описать привилегию как решение над субъектом, действием, ресурсом и контекстом;
2. разделить обычные и административные полномочия;
3. ограничить сервисную identity по данным и инфраструктуре;
4. спроектировать временную выдачу и отзыв;
5. проверить policy негативными тестами и аудитом использования.

Основная модель

Принцип наименьших привилегий требует выдавать субъекту только полномочия, необходимые для назначенной задачи. В NIST SP 800-53 это control AC-6; его enhancements отдельно рассматривают непривилегированный доступ для обычных функций, privileged accounts, ограничение privileged commands и периодический review.

Диаграмма

Рабочая формула:

привилегия = subject × action × resource × context × time

Если хотя бы одна координата заменена на *, blast radius растёт и требует явного обоснования.

Основные термины

Термин	Определение	Пример
Subject	Identity, от имени которой выполняется действие	Пользователь, worker, CI job
Privilege	Разрешённая возможность выполнить действие	orders:refund
Scope	Граница ресурсов и операций	Только tenant 42
Privileged function	Действие, способное менять security-critical состояние	Выдать роль, прочитать secret
Separation of duties	Разделение критичного процесса между субъектами	Один создаёт refund, другой подтверждает
Just-in-time access	Доступ, выдаваемый на короткое время под задачу	30 минут диагностики production
Privilege creep	Накопление больше не нужных прав	Старая роль после смены команды
Blast radius	Максимальный масштаб ущерба при ошибке или компрометации	Все tenants вместо одного

End-to-end сценарий: worker возвратов

Worker читает задания на refund и вызывает платёжного провайдера.

Диаграмма

Не существует одной роли «refund service». Здесь минимум четыре независимых набора прав:

Identity	Нужные права	Не нужны
Runtime worker	Consume refunds, читать нужные поля заказа, вызвать refund	Создавать пользователей, менять schema, читать все secrets
Deployment job	Обновить image и config deployment	Выполнять refund и читать customer data
On-call	Читать metrics/logs; временно получить диагностический доступ	Постоянный DB owner
Reconciliation job	Читать provider settlement и сравнивать суммы	Изменять payout account

Компрометация runtime worker не должна автоматически давать deployment или административные полномочия.

Что происходит под капотом

Решение least privilege проходит через несколько enforcement points:

Диаграмма

Каждый слой ограничивает отдельное измерение:

• queue policy — источник работы;
• application policy — business action и tenant;
• database grants/query — набор данных;
• provider credential — внешние операции;
• audit — обнаружение использования вне ожидаемого паттерна.

Минимальный воспроизводимый пример

Составьте policy-карточку вместо широкой роли refund-admin:

subject: service:refund-worker
task: process approved refund jobs
permissions:
  - action: queue.consume
    resource: queue/refunds-approved
  - action: order.read
    resource: tenant/${job.tenant_id}/order/${job.order_id}
    fields: [id, payment_id, refundable_amount, status]
  - action: payment.refund
    resource: merchant/main
constraints:
  max_amount: ${job.approved_amount}
  source: refunds-approved
  credential_ttl: 15m
denied:
  - order.list_all
  - payment.change_payout_account
  - database.schema_write
evidence:
  - policy_decision_log
  - provider_operation_id
owner: payments-team
review: 2026-10-31

Ожидаемый результат

Из карточки видно, зачем существует каждое разрешение, где его scope, какие действия явно запрещены, когда пересматривать доступ и каким evidence подтверждается использование.

Негативные проверки

1. Worker пытается refund другого tenant — deny.
2. Сумма превышает approved amount — deny.
3. Задание пришло не из approved queue — deny.
4. Credential истёк — deny и bounded retry, а не бессрочный token.
5. Worker пытается изменить payout account — deny и security signal.

Позитивный happy path не доказывает least privilege: нужны попытки выйти за каждую границу policy.

Временный административный доступ

Постоянный admin удобен, но превращает редкую операцию в постоянный риск.

Диаграмма

Хорошая процедура отвечает на вопросы:

• какая задача требует elevation;
• кто подтверждает и не подтверждает сам себе;
• какие команды и ресурсы доступны;
• как долго живёт credential;
• где сохраняется audit без секретов;
• как происходит досрочный revoke;
• что проверяется после завершения.

Trade-offs

Решение	Выигрыш	Цена или риск
Мелкие permissions	Малый blast radius	Больше policy и review
Отдельные service identities	Изоляция компонентов	Lifecycle credentials и observability
Just-in-time access	Меньше постоянных admin rights	Зависимость от approval-системы при инциденте
Field-level access	Меньше раскрытых данных	Сложнее запросы и schema evolution
Separation of duties	Защита от ошибки и злоупотребления	Задержка критичных операций

Цель — минимально достаточный доступ, а не математический минимум любой ценой. Слишком хрупкая policy провоцирует ручные bypass и общие credentials.

Failure modes и типичные ошибки

1. Роль равна должности. support слишком широка; нужны конкретные actions и resource scope.
2. Runtime использует owner credential. Ошибка приложения получает права schema migration и обхода row policies.
3. Доступ «на всякий случай». Необоснованные права почти никогда не удаляются.
4. Только UI restrictions. Скрытая кнопка не ограничивает API.
5. Нет отрицательных тестов. Команда проверяет разрешённое, но не границы deny.
6. Нет expiry и review. Временная задача создаёт постоянную привилегию.
7. Один secret у всех replicas и сред. Компрометация одной точки расширяет blast radius.
8. Audit содержит credential. Наблюдаемость сама раскрывает привилегию.

Практическое задание

Задача: выберите service identity своего backend и проведите privilege review.

Запишите:

1. одну конкретную задачу;
2. необходимые actions и resources;
3. права, не использованные за выбранный период;
4. runtime, deployment и operator identities;
5. пять негативных tests;
6. expiry/review/revoke процесс;
7. максимальный blast radius текущей и предлагаемой policy.

Критерии готовности: каждое allow связано с задачей; широкие wildcard имеют owner и обоснование; удаление прав проверено в staging или безопасном canary.

Подсказка

Начните с реальной telemetry использования прав. Отсутствие события не всегда доказывает ненужность доступа: учтите редкие recovery-сценарии и проверьте runbook.

Проверка знаний

ИНТЕРАКТИВНАЯ ПРОВЕРКА

Проверка знаний

0 / 4

01Worker только отправляет письма по сообщениям очереди. Какой доступ минимален?

Consume одной очереди и send через email providerПолный доступ к production DB на случай отладкиCluster-admin, потому что worker работает в Kubernetes

02Какие ограничения являются частью least privilege?

Разрешённые действияКонкретные ресурсы и tenantСрок и условия доступаПостоянный доступ после первой выдачи

03Сильная многофакторная аутентификация делает широкие права безопасными.

ВерноНеверно

04Восстановите жизненный цикл привилегии.

1. Истечь или отозваться
2. Обосновать задачу и минимальный scope
3. Записать использование и проверить аномалии
4. Выдать на ограниченный срок

Проверено: 0 из 4

Самопроверка

1. Почему MFA не заменяет least privilege?
2. Чем task scope отличается от роли?
3. Какие права следует разделить между runtime и deployment?
4. Как доказать, что удаление privilege безопасно?

Ответы и критерии

1. MFA защищает вход, но не уменьшает полномочия уже аутентифицированного субъекта.
2. Роль группирует права, а task scope объясняет конкретное действие, ресурс, условия и время; одна роль часто скрывает избыточность.
3. Runtime получает только бизнес-операции; deployment — изменение версии/config без доступа к пользовательским операциям и данным сверх необходимости.
4. По usage evidence, negative/positive tests, canary и готовому rollback; одного предположения владельца недостаточно.

Краткое резюме

• Least privilege ограничивает subject, action, resource, context и time.
• Пользовательские, runtime, deployment и operator identities требуют разных прав.
• Временный доступ должен иметь approval, TTL, audit и revoke.
• Проверять нужно не только allow, но и каждую границу deny.
• Минимизация blast radius остаётся полезной после обхода authentication.

Следующие шаги

Статья «Идентификация» объясняет, как система создаёт и поддерживает identity, которой затем назначаются минимальные привилегии.

Источники

• NIST SP 800-53 Rev. 5, Release 5.2.0 — control AC-6 и связанные требования к privileged access, accounts и review.
• NIST SP 800-53A Rev. 5 — assessment objectives и evidence для проверки least privilege controls.
• OWASP Authorization Cheat Sheet — least privilege, deny by default, проверка каждого запроса и тестирование authorization logic.