IAM & least privilege
Тема дорожной карты · DevOps Engineer
Identity and Access Management (IAM) — это система политик, ролей и кред, которая определяет, кто что может делать в вашей инфраструктуре. Принцип наименьших привилегий (least privilege) гласит: выдавайте ровно те права, которые нужны нагрузке, и не больше — используя короткоживущие креды, скоупленные токены и identity-aware прокси вместо долгоживущих статических ключей. В облаках именно IAM — разница между «утёкший токен сольёт один бакет» и «утёкший токен сожжёт весь аккаунт».
Как это работает
IAM & least privilege для платформенных инженеров покрывает hardening ОС, сегментацию сетей, IAM, secrets management и защиту supply chain. Linux hardening — это CIS benchmarks (отключить ненужные сервисы, ограничить SSH, включить auditd). IAM следует least privilege: каждый пайплайн получает свой service account только с нужными ему правами. Секреты живут в Vault, AWS Secrets Manager или Yandex Lockbox — никогда в Git, никогда в env-переменных, видимых через printenv. Supply chain: подписывайте артефакты (Cosign, Sigstore), генерируйте SBOM (Syft), сканируйте на CVE (Trivy, Grype), используйте build-пайплайны с SLSA-уровнями.
Когда применять
Применяйте IAM & least privilege с первого дня — security debt накапливается быстрее, чем feature debt. Минимум до публичного запуска: TLS везде (Let's Encrypt или Caddy), нет дефолтных паролей, IAM-роли на workload, секреты в vault, контейнерные images сканируются в CI, авто-патчи ОС включены. Для российских платформ, обрабатывающих персональные данные, 152-ФЗ требует задокументированные access controls, audit trails и incident response — Роскомнадзор проверяет бумаги не меньше технологии. Pen-тест ежегодно с момента появления выручки.
Типичные ошибки
Ловушки security: секреты в .env.example, закоммиченные в Git; долгоживущие AWS access keys вместо short-lived role assumption; "починим потом" исключения в CI-сканировании, остающиеся навсегда; нет политики ротации любого credential; IAM-политики, скопированные из блог-постов без понимания (Action: "*" не значит "все мои сервисы"); нет incident response playbook (при ransomware будете импровизировать плохо); нет patching policy (CVE-2014-0160 Heartbleed жил в продакшене месяцами у многих компаний).