Статья Управление жизненным циклом Non-Human Identities: автоматизация provisioning, ротации и отзыва через policy-as-code

28,65 миллиона захардкоженных секретов в публичных GitHub-репозиториях за 2025 год - плюс 34% год к году, по данным GitGuardian State of Secrets Sprawl. AI-related credentials выросли на 81% и стали самой быстрорастущей категорией утечек. При этом CSA фиксирует: только 15% организаций уверены, что способны предотвратить атаку через non-human identities. Остальные 85% - нет.

Последние полтора года я занимаюсь редизайном NHI lifecycle в нескольких командах - от стартапов с парой сотен сервисных аккаунтов до enterprise с десятками тысяч. И вот что я понял: инструменты для автоматизации provisioning, ротации и отзыва машинных идентификаторов существуют давно. Проблема не техническая. Проблема - в отсутствии операционного процесса, который связывает эти инструменты в единый управляемый цикл. Дальше - конкретный стек и пайплайн для каждой фазы.

Атакующая цепочка через NHI: почему стандартный IAM не закрывает машинные идентификаторы​

Стандартный IAM построен вокруг human identity lifecycle: HR-система создаёт запись, IGA провижинит аккаунты, менеджер проводит access review, при увольнении аккаунты деактивируются. Для NHI этот цикл ломается на каждом этапе. Не потому что инструменты плохие - потому что NHI не привязаны к организационным событиям.

Сервисный аккаунт создаётся разработчиком через gcloud iam service-accounts create, а не HR-системой. Владелец - автор pull request, который уволился два года назад. Access review не проводится, потому что никто не знает, какой workload использует этот SA и что сломается при изменении. При завершении проекта аккаунт остаётся - никто не рискнёт отключить. По данным Entro Security, популяция NHI выросла на 44% между 2024 и 2025 годами, а соотношение NHI к human identities в cloud-native средах достигает 144:1. Сто сорок четыре машинных аккаунта на одного живого человека.

Цифры по инцидентам подтверждают масштаб: по данным IBM 2024, утечки с участием скомпрометированных credentials обходятся в среднем в $4,81 млн. Согласно Verizon DBIR 2024, украденные учётные данные задействованы в 80% data breaches. Утечки с участием скомпрометированных credentials (включая NHI) обнаруживаются и локализуются в среднем за 292 дня - почти 10 месяцев, за которые атакующий успевает выстроить полную persistence-инфраструктуру. Вспомните Capital One: SSRF через misconfigured WAF -> credentials overprivileged IAM-роли EC2 через Instance Metadata Service -> доступ к данным более 100 миллионов клиентов. Один сервисный аккаунт с лишними правами.

Как выглядит kill chain через скомпрометированный NHI​

Атакующий, получивший доступ к скомпрометированному NHI, действует по конкретной цепочке, которая маппится на MITRE ATT&CK:

Initial Access - Cloud Accounts (T1078.004). Утёкший долгоживущий API-ключ из публичного репозитория, CI/CD-лога или захардкоженный в Docker-образе - входная точка. Ничего не нужно ломать: ключ легитимный.

Credential Access - обращение к Cloud Instance Metadata API (T1552.005) для получения временных credentials привязанных IAM-ролей. Параллельно - попытка доступа к Cloud Secrets Management Stores (T1555.006): если у скомпрометированного аккаунта есть secretmanager.versions.access в GCP или secretsmanager:GetSecretValue в AWS, Vault и Secrets Manager становятся источником дополнительных credentials. Steal Application Access Token (T1528) - перехват OAuth-токенов из кэша или переменных окружения - расширяет набор доступных идентификаторов.

Persistence и Privilege Escalation - добавление новых credentials к существующим SA: Additional Cloud Credentials (T1098.001). Или назначение дополнительных ролей: Additional Cloud Roles (T1098.003). Атакующий создаёт запасные входы, которые переживут ротацию исходного ключа. Вот почему одной ротации недостаточно.

Lateral Movement - с украденным Application Access Token (T1550.001) атакующий перемещается между сервисами. OAuth-токен одного микросервиса открывает доступ к API соседних, если scope выдан с запасом. А он почти всегда выдан с запасом.

Defense Evasion - модификация tenant-политик: Domain or Tenant Policy Modification (T1484) - отключение audit logging или ослабление conditional access rules.

На каждом этапе атакующий действует от имени легитимного NHI. Нет аномального входа пользователя, нет нетипичного IP - только машинный трафик, неотличимый от нормального. Поведенческий baseline для NHI определяется через NIST CSF v2.0 DE.AE-01 (Adverse Event Analysis), но большинство организаций такой baseline для machine identities попросту не строят. И это - корень проблемы.

Provisioning сервисных аккаунтов и policy-as-code: NHI governance с первой строки кода​

IaC-first: Terraform-модули с обязательными metadata​

Первое правило: ни один production NHI не создаётся вручную через cloud console. Каждый сервисный аккаунт, каждая IAM-роль, каждый OAuth-клиент описывается в Terraform или Pulumi и проходит code review. Это enforcement point, без которого audit trail по provisioning не существует.

Обязательные поля при создании NHI:

• Owner - конкретный инженер (email), не team alias и не devops@company.com
• TTL - дата истечения или условие деcommissioning ("удалить при архивации репозитория X")
• Purpose - одна строка: зачем этот NHI существует
• Environment - prod / staging / dev
• Consumer - какой workload, pipeline или agent потребляет этот NHI

resource "google_service_account" "deploy_sa" {
  account_id   = "deploy-${var.service_name}"
  display_name = "Deploy pipeline – ${var.service_name}"
  description  = "owner:${var.owner_email} ttl:${var.ttl_date}"
}

resource "google_project_iam_member" "deploy_binding" {
  project = var.project_id
  role    = "roles/clouddeploy.releaser"
  member  = "serviceAccount:${google_service_account.deploy_sa.email}"
}

Роль roles/clouddeploy.releaser вместо roles/editor - минимальный набор permissions. В GCP рекомендую включить Organization Policy iam.disableServiceAccountKeyCreation, чтобы JSON-ключи к SA не создавались вообще. Вместо ключей - Workload Identity Federation: CI/CD-система аутентифицируется через OIDC-провайдер, токен живёт час, ничего не хранится на диске.

Аналогичные паттерны по облакам: в AWS - IAM Role + OIDC-провайдер вместо IAM User с Access Key. IRSA или EKS Pod Identity (рекомендуется с 2023) для EKS. В Azure - Managed Identity вместо Service Principal с client secret, Workload Identity Federation для AKS. Kubernetes STIG от DISA рекомендует projected service account tokens вместо статичных secrets в volumes и Pod Security Standards для ограничения привилегий workloads.

Policy-as-code gate: OPA и Sentinel в CI/CD​

IaC - необходимое, но недостаточное условие. Код пишут люди, и roles/owner назначается "чтобы точно работало и не тратить время на подбор минимальных permissions". Знакомо? Policy-as-code действует как автоматический guardrail: OPA/Gatekeeper в Kubernetes, HashiCorp Sentinel в Terraform Enterprise, или OPA Conftest для pre-commit валидации Terraform plan.

deny[msg] {
  rc := input.resource_changes[_]
  rc.type == "google_service_account"
  desc := object.get(rc.change.after, "description", "")
  not contains(desc, "owner:")
  msg := "SA must include owner: in description"
}

deny[msg] {
  rc := input.resource_changes[_]
  rc.type == "google_project_iam_member"
  endswith(rc.change.after.role, "/owner")
  msg := sprintf("Primitive role %v blocked for NHI", [rc.change.after.role])
}

Пайплайн: terraform plan -out=plan.json -> terraform show -json plan.json -> conftest test plan.json. При нарушении - PR блокируется. Override - только через approval двух security-инженеров с записью в audit log.

Набор политик для production NHI, который закрывает типовые ошибки:

• Запрет primitive roles (roles/owner, roles/editor, roles/viewer) для service accounts
• Обязательные labels: owner, ttl, env, consumer-workload
• Ограничение IAM-биндингов на один SA (не более 3 ролей; если нужно больше - пересмотреть архитектуру)
• Запрет биндинга к allUsers или allAuthenticatedUsers
• Запрет resource google_service_account_key - если ключ нужен, используется отдельный exception workflow

Этот подход реализует контроли NIST SP 800-53 AC-1 (Access Control Policy) и IA-1 (Identification and Authentication Policy): политики документированы в коде, применяются автоматически, аудируемы и версионируемы через git history. Никакой "политики в Confluence, которую никто не читал".

Автоматизация ротации секретов: от Vault до Workload Identity Federation​

📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме

Зарегистрироваться или Войти

Длительность grace period определяется архитектурой: если workload использует Vault agent с auto-auth и template rendering - достаточно часа. Если секрет читается из environment variable при старте контейнера - нужен restart, grace period увеличивается до 24-48 часов. Если ротация не завершилась успешно - pipeline откатывает, восстанавливает старый ключ и создаёт инцидент. Без автоматического отката - не запускать.

Trade-off: подходы к управлению секретами NHI​

Подход	Когда использовать	Ограничения
Vault Dynamic Secrets	Базы данных, cloud IAM, PKI в гибридных и multi-cloud средах	HA-кластер (минимум 3 ноды для Raft quorum, 5 нод для production HA; каждая ~8-16 ГБ RAM для small deployment по HashiCorp Vault Reference Architecture, Integrated Storage (Raft) - рекомендованный backend), настройка secrets engine на каждый бэкенд, ощутимая операционная нагрузка
Cloud-native (AWS Secrets Manager, GCP Secret Manager)	Single-cloud, managed services	Vendor lock-in, cross-cloud ротация не поддерживается нативно
cert-manager + SPIFFE/SPIRE	K8s workload identity, mTLS	Только K8s-совместимые workloads, не покрывает API-ключи к внешним сервисам
Workload Identity Federation (OIDC)	CI/CD -> Cloud provider	Требует OIDC-совместимый IdP, не все legacy-сервисы поддерживают federation
Ручная ротация + calendar reminder	Не использовать. Серьёзно, не надо	Забывается, не масштабируется, audit trail отсутствует

Выбор зависит от инфраструктуры: если всё в одном облаке - cloud-native менеджер секретов проще и дешевле. Multi-cloud или гибрид - Vault как единая control plane. Только Kubernetes - cert-manager + SPIRE покрывают mTLS-слой, но для API-ключей к SaaS-сервисам всё равно понадобится Vault или cloud-native store.

CIEM non-human identities: обнаружение и устранение избыточных привилегий​

CIEM (Cloud Infrastructure Entitlement Management) закрывает разрыв между "какие разрешения выданы NHI" и "какие NHI реально использует". Privilege creep у машинных аккаунтов агрессивнее, чем у пользователей: access review проводится реже, ответственного owner часто нет, а при создании разрешения выдаются "с запасом".

Характерная картина, которую я вижу раз за разом: service account для CI/CD-деплоя получил roles/editor при создании, и за 18 месяцев из нескольких тысяч доступных permissions задействовал 12. Двенадцать. Оставшиеся тысячи - чистый attack surface. CIEM-решения (Wiz, Tenable Cloud Security / бывший Ermetic, Prisma Cloud, CrowdStrike Falcon Cloud Security) анализируют CloudTrail, GCP Cloud Audit Logs, Azure Activity Logs и строят per-identity карту effective permissions vs actual usage, отсортированную по risk score.

От CIEM-алерта до right-sizing: практический сценарий​

1. CIEM обнаруживает: SA deploy-pipeline-payments имеет roles/editor, за 90 дней использовал 12 конкретных permissions
2. CIEM генерирует рекомендацию: custom role с перечнем этих 12 permissions
3. DevSecOps-инженер создаёт PR с custom role definition в Terraform
4. OPA-политика валидирует: custom role не содержит wildcard permissions, labels на месте
5. terraform apply переключает SA на custom role
6. Мониторинг 7 дней через Cloud Audit Logs: если workload не генерирует 403 Forbidden - старый roles/editor binding удаляется
7. Запись в access certification log: SA right-sized, дата, инженер, обоснование

Этот процесс - ядро continuous access certification для NHI. Он соответствует NIST CSF v2.0 PR.AA-01 (управление identities и credentials авторизованных сервисов) и ID.AM-01 (инвентаризация и управление активами).

Масштаб, при котором ручной анализ невозможен: аудит одной Fortune 500 финансовой организации обнаружил более 4,2 миллиона non-human identities при ~50 000 человеческих аккаунтов, согласно данным CSA. При таких объёмах CIEM - не удобство, а необходимость. Для компании с 200-500 NHI в одном облаке - можно начать с самописного скрипта, который парсит CloudTrail и сравнивает granted vs used permissions. При тысячах NHI в multi-cloud - без CIEM-продукта не обойтись.

Отзыв привилегий машинных идентификаторов: brownout-протокол и экстренный revoke​

Decommissioning - фаза, где гибнет большинство NHI-программ. Причина банальна: страх сломать прод. "Этот SA не использовался 6 месяцев, но вдруг он нужен для годовой отчётности?" - и аккаунт остаётся. По данным OWASP Non-Human Identities Top 10, improper offboarding стабильно входит в критические риски.

Brownout-протокол решает эту дилемму через управляемое отключение вместо гадания на кофейной гуще:

1. Обнаружение неактивности: NHI не аутентифицировался более 30 дней (prod) или 14 дней (dev/staging)
2. Disable (карантин): аккаунт отключается, но не удаляется. gcloud iam service-accounts disable в GCP, aws iam update-access-key --status Inactive в AWS. Credentials инвалидируются, но сам объект сохраняется
3. Наблюдение (24-48 часов): мониторинг failed authentication attempts от workloads, которые пытаются использовать отключённый NHI
4. Решение: нет попыток аутентификации за период наблюдения - permanent delete. Были попытки - аккаунт восстанавливается, но немедленно назначается owner для access review с дедлайном

Для экстренного отзыва при подтверждённой компрометации brownout неприменим - нужен немедленный revoke. Автоматизированный playbook:

• Отзыв всех ключей: gcloud iam service-accounts keys list + delete для каждого
• Отзыв всех Vault leases для dynamic secrets: vault lease revoke -prefix database/creds/<role>/ (для KV v2 secrets leases не создаются - отзыв через ротацию значения или vault kv metadata delete)
• Отзыв OAuth refresh tokens через provider API
• Switch на standby workload identity, если архитектура предусматривает hot standby
• Notification в security channel с timeline и blast radius assessment

Согласно NIST SP 800-53 IR-1, процедуры реагирования должны быть задокументированы и протестированы до инцидента. Playbook экстренного отзыва NHI - часть incident response, а не импровизация во время пожара. Если вы тренируете tabletop exercises без сценария "скомпрометирован сервисный аккаунт" - добавьте.

Чеклист: управление жизненным циклом non-human identities​

Нумерованный список для включения в отчёт по аудиту или передачи команде DevOps/Platform:

1. Запустить discovery: перечислить все NHI в cloud IAM, Active Directory, Kubernetes, CI/CD. Для каждого зафиксировать owner, consumer workload, дату создания, дату последней аутентификации
2. Включить Organization Policy iam.disableServiceAccountKeyCreation (GCP) или SCP с deny на iam:CreateAccessKey для всех, кроме break-glass роли (AWS)
3. Все новые NHI создавать только через Terraform/Pulumi-модули с обязательными labels: owner, ttl, env, consumer
4. Развернуть OPA Conftest или Sentinel как mandatory CI/CD check. Минимальный набор политик: запрет primitive roles, обязательные metadata, запрет wildcard permissions, запрет SA key creation
5. Настроить автоматическую ротацию long-lived credentials с периодом не более 90 дней. Новые workloads - только dynamic или short-lived credentials (Vault Dynamic Secrets, Workload Identity Federation)
6. Подключить CIEM к CloudTrail / Audit Logs. Настроить weekly report по NHI с gap более 50% между granted и used permissions
7. Автоматический disable NHI неактивных более 30 дней (prod) / 14 дней (dev/staging) с brownout-протоколом
8. Логирование всех операций с NHI credentials: создание, ротация, использование, отзыв. Хранение не менее 1 года (NIST SP 800-53 AU-1)
9. Квартальный access certification для всех NHI с привилегиями выше read-only. Каждый NHI предъявляется назначенному owner для re-certification
10. Задокументировать и протестировать playbook экстренного отзыва NHI credentials: от обнаружения компрометации до полного revoke - целевое время менее 15 минут

Типичная ошибка при старте NHI governance - начинать с покупки CIEM. Логика кажется разумной: "сначала увидим проблему - потом починим". На практике работает наоборот. CIEM покажет сотни overprivileged service accounts, команда утонет в алертах, не имея ни policy-as-code для enforcement, ни автоматизации для remediation. Через квартал дашборд станет ещё одной проигнорированной вкладкой. Видел это не раз.

Рабочая последовательность другая: сначала golden path для provisioning - Terraform-модуль с OPA-политикой, затем ротация через Vault или cloud-native менеджер, и только после этого CIEM для обнаружения legacy NHI, созданных до внедрения guardrails. CIEM эффективен, когда поток новых проблем остановлен и команда разгребает хвосты, а не когда overprivileged аккаунты продолжают создаваться с прежней скоростью.

По данным CSA, 16% организаций вообще не отслеживают создание AI-related identities. Microsoft Copilot Studio перешагнул отметку в миллион созданных AI-агентов, Gartner прогнозирует agentic AI в 33% корпоративных приложений к 2028 году. AI-агенты - не пассивные holders credentials, а автономные акторы: запрашивают разрешения в runtime, порождают sub-agents и выполняют цепочки действий через десятки систем. Governance frameworks, построенные под статичные сервисные аккаунты, к ним принципиально неприменимы.

Кто сегодня выстроит lifecycle management для "классических" NHI - service accounts, API keys, certificates - получит фундамент для управления следующим поколением. Кто не выстроит - будет разбирать post-mortem, где AI-агент с roles/owner обеспечил lateral movement быстрее, чем SOC-аналитик открыл тикет. На WAPT эту цепочку - от утёкшего ключа до полного захвата облачной инфраструктуры - разбирают на практике в лабораторных условиях.