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

Главный принцип проектирования политик: давать ровно столько доступа, сколько нужно, и ни байтом больше.

Принцип наименьших привилегий (least privilege) — каждый субъект получает минимально необходимый для своей задачи набор прав, что ограничивает ущерб при компрометации.

Vault даёт точный инструмент разграничения, но сам по себе он не делает систему безопасной — всё зависит от того, как вы пишете политики. Широкая политика сводит на нет смысл внедрения: украденный токен с правами secret/* вскрывает всё хранилище.

Узкие политики по назначению

Правильный подход — отдельная политика на каждое приложение и роль, привязанная строго к нужным путям:

# billing-app может читать ТОЛЬКО свои секреты
path "secret/data/billing/*" {
  capabilities = ["read"]
}

# и получать динамические креды ТОЛЬКО к своей БД
path "database/creds/billing-ro" {
  capabilities = ["read"]
}

Приложение billing физически не может прочитать секреты приложения orders — даже если его токен украдут, ущерб ограничен зоной billing.

Разделяй чтение и запись

Приложениям в рантайме почти никогда не нужна запись секретов — только чтение. Запись оставляют отдельным административным/CI-политикам.

Изоляция по средам

Разделяйте dev/staging/prod не только путями, но и тем, кто к ним допущен. Токен dev-приложения не должен иметь даже теоретической дороги к secret/data/prod/*. Хорошо помогает явный deny на чужие среды в общих политиках.

Как работает под капотом: глубокая защита

Least privilege — это про радиус поражения. Vault уже шифрует, аудирует и ротирует, но если все токены всемогущи, одна утечка обнуляет эти меры. Узкие политики превращают компрометацию одного сервиса в локальный инцидент, а не катастрофу. Связка с динамическими секретами усиливает эффект: даже прочитанные креды живут недолго и привязаны к конкретной роли.

Проверка прав токена

Перед выкаткой стоит убедиться, что токен может ровно то, что должен:

# какие capabilities у токена на конкретный путь
vault token capabilities <токен> secret/data/billing/db

read

Частые ошибки

• Одна «общая» политика на все сервисы — компрометация любого вскрывает всё.
• Давать приложению write «на всякий случай» — оно может перезаписать или удалить секреты.
• Копировать admin-политику новым ролям — права расползаются по принципу «и так сойдёт».
• Не пересматривать политики — со временем накапливаются лишние пути.

Итог

• Least privilege ограничивает радиус поражения при компрометации токена.
• Пишите узкие политики на приложение/роль/среду и разделяйте чтение и запись.
• Проверяйте права через token capabilities и регулярно пересматривайте политики.