Глава 6. Привилегированный доступ

В Главе 5 мы построили фундамент: единый IdP, фишинго-устойчивая MFA, Conditional Access. Но даже идеальная аутентификация не решает проблему привилегий, которые живут вечно. Администратор получает полный доступ к production в день найма — и этот доступ остаётся через месяцы после перевода в другой отдел. В этой главе — как от постоянных привилегий перейти к динамическому, ограниченному по времени доступу.

Зачем: постоянные привилегии — главная мишень

NIST SP 800-207 (Section 2, Tenet 6) формулирует: «Вся аутентификация и авторизация ресурсов являются динамическими и строго применяются перед предоставлением доступа». Доступ определяется динамической политикой, включающей наблюдаемое состояние идентичности, приложения и запрашивающего актива, а также поведенческие и средовые атрибуты.

Источник: NIST SP 800-207, Section 2

Три проблемы постоянных привилегий:

1. Standing access = неограниченное окно атаки. Если учётная запись с правами db_owner скомпрометирована, злоумышленник получает доступ к данным немедленно. Если бы привилегии выдавались на 1 час по запросу — окно атаки сокращалось бы на порядки.

2. Секреты, живущие в коде. Строки подключения к базам, API-ключи, сертификаты — захардкожены в .env файлах, CI/CD переменных, Kubernetes Secrets. По данным GitGuardian State of Secrets Sprawl 2024, в публичных GitHub-репозиториях за 2023 год обнаружено 12.8 млн новых секретов.

Источник: GitGuardian State of Secrets Sprawl 2024

3. Нет governance. Привилегии назначаются, но не пересматриваются. CISA ZTMM v2.0 в столпе Identity выделяет Access Management как отдельную функцию — с критериями минимальных привилегий и непрерывной валидации доступа к ресурсам.

Источник: CISA ZTMM v2.0

Управление привилегированным доступом (PAM)

PAM (Privileged Access Management) — класс решений для контроля доступа к критическим системам: серверам, базам данных, сетевому оборудованию, облачным консолям. В архитектуре NIST 800-207 PAM выступает как источник данных для Механизма политик (PE) и как точка управления учётными данными.

Три подхода к PAM

Подход	Представители	Модель	Ключевая идея
Vault-based (традиционный)	CyberArk	Хранилище паролей + ротация + запись сессий	Секреты хранятся централизованно, выдаются через checkout
Certificate-based (modern)	Teleport	Краткосрочные сертификаты вместо паролей	Нет постоянных учётных данных — только сертификат на сессию
Session-based	HashiCorp Boundary	Авторизация сессий + инъекция учётных данных	Пользователь никогда не видит пароль к целевой системе

CyberArk

CyberArk — наиболее зрелая enterprise PAM-платформа. Два варианта развёртывания:

Privilege Cloud (SaaS) — платформа Identity Security Platform Shared Services с управляемой инфраструктурой
PAM Self-Hosted — полный контроль, для регулируемых отраслей и air-gapped сред

Ключевые компоненты: Digital Vault (хранилище), CPM (Central Policy Manager — ротация паролей), PSM (Privileged Session Manager — запись сессий), PTA (Privileged Threat Analytics — детекция аномалий).

CyberArk Secure Infrastructure Access (SIA), ранее Dynamic Privileged Access — SaaS-решение для JIT-доступа без VPN к Windows, Linux, базам данных, Kubernetes. Zero Standing Privileges (ZSP): учётные данные не существуют до момента запроса, доступ автоматически отзывается по окончании сессии.

Источники: CyberArk Privilege Cloud, CyberArk SIA

Teleport

Teleport (v18.2, Sep 2025) — identity-aware access proxy с сертификатной аутентификацией. Вместо паролей — краткосрочные X.509 и SSH-сертификаты, выданные встроенным CA.

Поддерживаемые протоколы: SSH, RDP, HTTPS, Kubernetes API, PostgreSQL, MySQL, MongoDB, и с версии 18.1 — Model Context Protocol (MCP) для AI-агентов.

Zero Trust свойства Teleport:

Нет постоянных credentials — только сертификаты с коротким TTL
Per-session MFA — MFA при каждом подключении к базе данных (с v18.0)
RBAC — роли привязаны к identity из IdP
Session recording — полная запись SSH, K8s, DB, RDP сессий
Access Requests — JIT-workflow с одобрением через Slack, PagerDuty, или встроенный UI

Источники: Teleport Architecture, Teleport Protocols

HashiCorp Boundary

Boundary — session authorization proxy, который отделяет процесс аутентификации от доступа к целевым системам.

Архитектура: Controller (аутентификация, авторизация, конфигурация) → Worker (проксирование сессий) → Target (целевая система).

Ключевая инновация — два режима работы с учётными данными:

Режим	Как работает	Кто видит пароль
Credential Brokering	Boundary получает credentials из Vault и возвращает пользователю	Пользователь
Credential Injection	Boundary получает credentials и передаёт Worker'у, который устанавливает сессию	Никто

Credential injection — наиболее безопасный подход: пользователь подключается к целевой системе, никогда не видя пароля. Доступен в HCP Boundary и Boundary Enterprise.

Источник: Boundary Credential Management

HashiCorp Vault: секреты как сервис

HashiCorp Vault (v1.21, Oct 2025) — центральная платформа управления секретами. В контексте Zero Trust Vault играет роль менеджера учётных данных (NIST 800-207, Figure 2) и источника данных для Механизма политик (PE).

Источник: Vault Release Notes

Почему динамические секреты

Статические секреты (пароли в .env, API-ключи в переменных окружения) — антипаттерн Zero Trust:

Живут бессрочно → неограниченное окно атаки
Общие на команду → невозможно аудировать, кто использовал
Ротация — ручной процесс → откладывается бесконечно

Vault генерирует динамические секреты: учётные данные, которые не существуют до момента запроса и автоматически уничтожаются по истечении TTL. Каждый запрос — уникальные credentials, привязанные к lease.

Ключевые secrets engines

Engine	Назначение	Как работает
Database	Динамические credentials для БД	`CREATE ROLE` при запросе, `DROP ROLE` при истечении TTL
PKI	Встроенный CA, динамические X.509 сертификаты	Генерирует сертификаты с коротким TTL для mTLS
Transit	Encryption as a Service	Шифрует/дешифрует данные, не храня их. Key rotation без простоя
SSH	Подписанные SSH-сертификаты	Vault CA подписывает публичный ключ пользователя
KV v2	Key-Value хранилище с версионированием	Версии, soft-delete, audit trail

Источник: Vault Secrets Engines

Transit Engine: шифрование как сервис

Transit engine решает проблему «шифрование в приложении»: приложению не нужен доступ к ключам шифрования — оно отправляет данные в Vault API, получает ciphertext.

bash

# Создание ключа шифрования
vault write -f transit/keys/payments

# Шифрование (plaintext → base64 → Vault)
vault write transit/encrypt/payments \
    plaintext=$(echo -n "4111-1111-1111-1111" | base64)
# → ciphertext = vault:v1:AbCdEfGh...

# Ротация ключа (старый ciphertext расшифровывается, новый создаётся с v2)
vault write -f transit/keys/payments/rotate

# Rewrap: перешифровать без раскрытия plaintext
vault write transit/rewrap/payments \
    ciphertext="vault:v1:AbCdEfGh..."
# → vault:v2:XyZaBcDe...

Формат ciphertext vault:v1:... содержит номер версии ключа. При ротации новые данные шифруются ключом v2, но Vault продолжает расшифровывать данные с v1. Rewrap API позволяет перешифровать ciphertext новым ключом без раскрытия plaintext.

Источник: Vault Transit Engine

Методы аутентификации в Vault

Vault поддерживает identity-based аутентификацию, что критично для Zero Trust:

Метод	Для кого	Как аутентифицирует
AppRole	CI/CD, автоматизация	`role_id` (статический) + `secret_id` (динамический, с TTL и usage limits)
Kubernetes	Pods	ServiceAccount token → TokenReview API
JWT/OIDC	Пользователи	Токен от IdP (Okta, Entra ID, Keycloak)
AWS IAM	EC2, Lambda, ECS	Подписанный запрос `sts:GetCallerIdentity`

Каждый метод устраняет статические credentials: Kubernetes auth использует существующий ServiceAccount token, AWS IAM — облачную идентичность, OIDC — токен от корпоративного IdP.

Источник: Vault Auth Methods

Vault в Kubernetes: три способа интеграции

Метод	Механизм	Auth-методы	Потребление ресурсов
Agent Injector	Sidecar-контейнер в каждом Pod	Все auto-auth методы	Высокое (per-pod)
CSI Provider	Volume mount	Ограниченно	Среднее
Secrets Operator (VSO)	CRD → Kubernetes Secret	Kubernetes	Низкое (per-cluster)

Agent Injector — Kubernetes Mutation Webhook, который перехватывает создание Pod'ов и инжектирует Vault Agent sidecar на основе аннотаций:

yaml

apiVersion: v1
kind: Pod
metadata:
  annotations:
    vault.hashicorp.com/agent-inject: "true"
    vault.hashicorp.com/role: "my-app"
    vault.hashicorp.com/agent-inject-secret-db-creds: "database/creds/readonly"
spec:
  serviceAccountName: my-app-sa
  containers:
    - name: app
      image: my-app:latest
      # Секреты доступны в /vault/secrets/db-creds

Vault Secrets Operator (VSO) — более новый подход: один оператор на кластер вместо sidecar на каждый pod. Синхронизирует Vault секреты в нативные Kubernetes Secrets через CRD.

Источник: Vault Kubernetes Integrations

Just-in-Time (JIT) доступ

JIT-доступ — реализация принципа минимальных привилегий во времени: привилегии выдаются только когда нужны, на минимальный срок, с обязательным обоснованием и (опционально) одобрением.

Модель JIT vs Standing Privileges

Облачные реализации JIT

Microsoft Entra PIM (Privileged Identity Management)

PIM — встроенный JIT-механизм в Entra ID. Два типа назначений:

Eligible — пользователь может активировать роль, но не имеет её по умолчанию
Active — роль назначена постоянно (антипаттерн для привилегированных ролей)

При активации eligible-роли: обоснование → (опционально) одобрение → time-bound access (до 24 часов) → автоматический отзыв. Весь процесс логируется для аудита.

Источник: Microsoft Entra PIM

AWS Temporary Elevated Access Management (TEAM)

TEAM — open-source решение от AWS для JIT-доступа в мультиаккаунтной среде AWS IAM Identity Center. Архитектура: React SPA на AWS Amplify + Amazon Cognito (аутентификация) + DynamoDB (хранение запросов) + Lambda (обработка и отзыв) + CloudTrail Lake (аудит).

Пользователь запрашивает временные привилегии через веб-интерфейс, доступный из портала IAM Identity Center. Группы IAM Identity Center определяют: кто может запрашивать (eligibility), кто одобряет (approval), с каким scope (аккаунт + permission set).

Источник: AWS TEAM, AWS Security Blog: TEAM

GCP Privileged Access Manager (PAM)

GCP PAM — встроенный сервис для JIT-доступа. Администратор создаёт entitlement: набор principals, которые могут запросить grant — временное назначение IAM-ролей с максимальной продолжительностью, опциональным одобрением и обязательным обоснованием. Доступ автоматически отзывается по истечении grant.

Источник: GCP PAM Overview

Identity Governance & Administration (IGA)

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

Joiner-Mover-Leaver

Событие	Действие	Без IGA	С IGA
Joiner	Новый сотрудник	Ручное создание аккаунтов в каждой системе	Автоматический provisioning по роли/отделу
Mover	Перевод в другой отдел	Старые права остаются + добавляются новые	Автоматический пересмотр: удаление старых, назначение новых
Leaver	Увольнение	Забытые аккаунты живут месяцами	Автоматическая деактивация во всех системах

Access Reviews (пересмотр доступа)

Access Reviews — регулярная проверка: «Нужен ли этот доступ до сих пор?» Без них права только накапливаются (privilege creep).

Microsoft Entra Access Reviews позволяют проверять:

Членство в группах (security, M365)
Назначения ролей (Entra ID roles, Azure resource roles)
Access packages (entitlement management)
Enterprise applications

Рецензент (менеджер, owner ресурса, или сам пользователь) утверждает или отзывает доступ. ML-рекомендации (user-to-group affiliation) помогают принимать решения. Кампании можно запускать периодически: еженедельно, ежемесячно, ежеквартально, ежегодно.

Источник: Entra Access Reviews

Okta Identity Governance включает: Access Requests (запросы доступа с workflow), Access Certifications (кампании пересмотра с контекстом: частота входа, дата последнего использования ресурса), Entitlement Management и Separation of Duties. С 2025 года — preconfigured campaigns и делегирование governance-активности другим пользователям.

Источник: Okta Identity Governance

Segregation of Duties (SoD)

Разделение обязанностей — контроль, запрещающий одному субъекту иметь конфликтующие права. Два типа:

Preventive SoD — блокирует конфликтующее назначение в момент запроса. Пример: пользователь, который может создавать вендоров в платёжной системе, не должен иметь право оплачивать их.
Detective SoD — обнаруживает конфликты, возникшие со временем (при Mover-событиях), и запускает пересмотр.

Источник: SailPoint: Segregation of Duties

IGA и Zero Trust

IGA обеспечивает непрерывную валидацию прав доступа — требование CISA ZTMM для уровней Advanced и Optimal. Без IGA организация застревает на уровне Traditional/Initial, где привилегии назначаются вручную и не пересматриваются.

Lab: Vault с динамическими credentials для PostgreSQL

В этой лабораторной работе мы настроим HashiCorp Vault для генерации временных учётных данных PostgreSQL. Каждый запрос создаёт уникальный логин/пароль с ограниченным TTL — это практическая реализация принципа минимальных привилегий.

Предварительные требования

Docker и Docker Compose
curl и jq
Vault CLI (install guide)

Шаг 1: Запуск инфраструктуры

Создайте docker-compose.yml:

yaml

# code/ch06-privileged-access/docker-compose.yml
services:
  postgres:
    image: postgres:16
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: postgres
      POSTGRES_DB: myapp
    ports:
      - "5432:5432"
    networks:
      - vault-net

  vault:
    image: hashicorp/vault:1.21
    cap_add:
      - IPC_LOCK
    environment:
      VAULT_DEV_ROOT_TOKEN_ID: root
      VAULT_DEV_LISTEN_ADDRESS: "0.0.0.0:8200"
    ports:
      - "8200:8200"
    networks:
      - vault-net

networks:
  vault-net:

bash

docker compose up -d
export VAULT_ADDR='http://127.0.0.1:8200'
export VAULT_TOKEN='root'
vault status

Важно: dev-режим Vault — только для лабораторных. В production: TLS, auto-unseal через KMS, Raft storage, vault operator init для Shamir-ключей.

Шаг 2: Включение Database Secrets Engine

bash

vault secrets enable database

Шаг 3: Настройка подключения к PostgreSQL

bash

vault write database/config/myapp-db \
    plugin_name="postgresql-database-plugin" \
    allowed_roles="readonly" \
    connection_url="postgresql://{{username}}:{{password}}@postgres:5432/myapp?sslmode=disable" \
    username="postgres" \
    password="postgres"

Обратите внимание: и — шаблоны Vault, которые подставляются при подключении. Адрес postgres — hostname Docker-контейнера (Vault обращается к PostgreSQL по Docker-сети, а не через localhost).

Шаг 4: Создание роли с динамическими credentials

bash

vault write database/roles/readonly \
    db_name="myapp-db" \
    creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' \
        VALID UNTIL '{{expiration}}'; \
        GRANT SELECT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";" \
    default_ttl="1h" \
    max_ttl="24h"

Параметры:

creation_statements — SQL, выполняемый при создании credentials. , , — placeholders Vault.
default_ttl="1h" — credentials живут 1 час по умолчанию
max_ttl="24h" — максимальное продление lease

Шаг 5: Получение временных credentials

bash

vault read database/creds/readonly

Пример ответа:

Key                Value
---                -----
lease_id           database/creds/readonly/abcdef-1234-5678
lease_duration     1h
lease_renewable    true
password           A1a-aBcDeFgHiJkL
username           v-root-readonly-aBcDeFgH-1234567890

Каждый вызов vault read генерирует уникальные credentials. Они привязаны к lease: через 1 час Vault выполнит DROP ROLE и credentials перестанут работать.

Шаг 6: Проверка доступа и жизненного цикла

bash

# Подключение с динамическими credentials (из хост-машины)
PGPASSWORD="A1a-aBcDeFgHiJkL" psql -h localhost -U v-root-readonly-aBcDeFgH-1234567890 -d myapp

# Просмотр информации о lease
vault lease lookup database/creds/readonly/abcdef-1234-5678

# Продление lease (до max_ttl)
vault lease renew database/creds/readonly/abcdef-1234-5678

# Отзыв credentials (немедленно)
vault lease revoke database/creds/readonly/abcdef-1234-5678
# → PostgreSQL role DROPнута, подключение с этими credentials невозможно

Шаг 7: Наблюдение за ротацией (опционально)

bash

# Список всех активных PostgreSQL-ролей, созданных Vault
docker compose exec postgres psql -U postgres -c \
    "SELECT rolname, rolvaliduntil FROM pg_roles WHERE rolname LIKE 'v-%';"

Вы увидите, что каждый запрос vault read database/creds/readonly создал отдельную роль с уникальным именем и VALID UNTIL, соответствующим TTL lease.

Шаг 8: Очистка

bash

docker compose down -v

Что дальше

Шаг	Уровень CISA	Что настроить
Заменить dev-mode на Raft storage + auto-unseal	Initial → Advanced	`vault operator init`, KMS auto-unseal
Добавить Kubernetes auth + Agent Injector	Advanced	`auth/kubernetes`, Pod annotations
Transit Engine для шифрования PII	Advanced	`transit/keys/`, rewrap API
Vault Secrets Operator (VSO)	Advanced → Optimal	CRD-based secrets sync

Ключевые выводы

Standing privileges — антипаттерн Zero Trust. NIST 800-207 (Tenet 6) требует динамических решений о доступе. Постоянные привилегии = постоянная поверхность атаки.
PAM эволюционирует: от хранилищ к identity-aware proxy. CyberArk хранит и ротирует пароли. Teleport заменяет их краткосрочными сертификатами. Boundary инжектирует credentials, которые пользователь никогда не видит.
Динамические секреты Vault сокращают окно атаки с «бесконечно» до TTL lease (минуты-часы). Каждый запрос — уникальные credentials с audit trail.
JIT-доступ — реализация least privilege во времени. Azure PIM (eligible assignments), AWS TEAM (open-source для IAM Identity Center), GCP PAM (entitlements + grants) — облачные реализации одного паттерна.
IGA замыкает цикл: Joiner-Mover-Leaver автоматизация, Access Reviews для предотвращения privilege creep, SoD для разделения конфликтующих прав.

В Главе 7 мы перейдём от человеческих идентичностей к машинным: SPIFFE/SPIRE, Workload Identity Federation, и проблема NHI (Non-Human Identity).

Глава 6. Привилегированный доступ ​

Зачем: постоянные привилегии — главная мишень ​

Управление привилегированным доступом (PAM) ​

Три подхода к PAM ​

CyberArk ​

Teleport ​

HashiCorp Boundary ​

HashiCorp Vault: секреты как сервис ​

Почему динамические секреты ​

Ключевые secrets engines ​

Transit Engine: шифрование как сервис ​

Методы аутентификации в Vault ​

Vault в Kubernetes: три способа интеграции ​

Just-in-Time (JIT) доступ ​

Модель JIT vs Standing Privileges ​

Облачные реализации JIT ​

Identity Governance & Administration (IGA) ​

Joiner-Mover-Leaver ​

Access Reviews (пересмотр доступа) ​

Segregation of Duties (SoD) ​

IGA и Zero Trust ​

Lab: Vault с динамическими credentials для PostgreSQL ​

Предварительные требования ​

Шаг 1: Запуск инфраструктуры ​

Шаг 2: Включение Database Secrets Engine ​

Шаг 3: Настройка подключения к PostgreSQL ​

Шаг 4: Создание роли с динамическими credentials ​

Шаг 5: Получение временных credentials ​

Шаг 6: Проверка доступа и жизненного цикла ​

Шаг 7: Наблюдение за ротацией (опционально) ​

Шаг 8: Очистка ​

Что дальше ​

Ключевые выводы ​

Глава 6. Привилегированный доступ

Зачем: постоянные привилегии — главная мишень

Управление привилегированным доступом (PAM)

Три подхода к PAM

CyberArk

Teleport

HashiCorp Boundary

HashiCorp Vault: секреты как сервис

Почему динамические секреты

Ключевые secrets engines

Transit Engine: шифрование как сервис

Методы аутентификации в Vault

Vault в Kubernetes: три способа интеграции

Just-in-Time (JIT) доступ

Модель JIT vs Standing Privileges

Облачные реализации JIT

Identity Governance & Administration (IGA)

Joiner-Mover-Leaver

Access Reviews (пересмотр доступа)

Segregation of Duties (SoD)

IGA и Zero Trust

Lab: Vault с динамическими credentials для PostgreSQL

Предварительные требования

Шаг 1: Запуск инфраструктуры

Шаг 2: Включение Database Secrets Engine

Шаг 3: Настройка подключения к PostgreSQL

Шаг 4: Создание роли с динамическими credentials

Шаг 5: Получение временных credentials

Шаг 6: Проверка доступа и жизненного цикла

Шаг 7: Наблюдение за ротацией (опционально)

Шаг 8: Очистка

Что дальше

Ключевые выводы