Глава 24. Новые горизонты
В Главе 23 мы разобрали, как внедрять Zero Trust в существующую инфраструктуру: legacy-приложения, Active Directory, устаревшие протоколы. Но Zero Trust — не статичный фреймворк. Три технологических тренда фундаментально меняют ландшафт: AI-агенты создают новый класс небиологических идентичностей (NHI), постквантовая криптография (PQC) готовит замену RSA и ECDSA, а конфиденциальные вычисления защищают данные даже от администратора инфраструктуры. Параллельно IoT/OT-устройства — миллиарды ограниченных узлов — остаются одним из самых сложных объектов для Zero Trust.
Эта глава — не прогноз, а карта конкретных технологий, стандартов и конфигураций, доступных на момент написания (февраль 2026). Каждая секция помечена уровнем зрелости: GA (production-ready), Preview (можно тестировать), Draft (стандарт в разработке).
24.1. AI-агенты и идентичность
Проблема: NHI на стероидах
В Главе 7 мы описали небиологические идентичности: сервисные аккаунты, API-ключи, CI/CD-токены. AI-агенты — качественно иной класс NHI:
- Автономность: агент принимает решения без участия человека — выбирает инструменты, формирует запросы, обрабатывает ответы
- Недетерминированность: один и тот же агент может вести себя по-разному при каждом вызове
- Делегирование: агент действует от имени пользователя, но с собственной логикой принятия решений
- Цепочки вызовов: агент A вызывает агент B, который вызывает агент C — кто несёт ответственность?
По данным Entro Security (H1 2025), NHI выросли на 44% год к году, соотношение NHI к людям достигло 144:1, а 97% NHI имеют избыточные привилегии. С ростом AI-агентов эти цифры будут только увеличиваться.
Источники: Entro Security NHI Report H1 2025, WEF: Non-human identities: Agentic AI's new frontier
OWASP Top 10 для LLM: ключевые риски
OWASP Top 10 for LLM Applications (2025) выделяет 10 рисков, три из которых напрямую связаны с идентичностью и авторизацией:
| # | Риск | Связь с Zero Trust |
|---|---|---|
| LLM01 | Prompt Injection | Атакующий может обойти контроль доступа через инъекцию |
| LLM02 | Sensitive Information Disclosure | Утечка секретов, API-ключей, PII через вывод LLM |
| LLM06 | Excessive Agency | Агент получает больше привилегий, чем необходимо |
| LLM07 | System Prompt Leakage | Секреты в системных промптах вместо proper auth |
LLM06 (Excessive Agency) — главный риск 2025-2026 года. Агенту предоставляется доступ к инструментам с широкими правами, и он выполняет действия за пределами задуманного. Митигация: минимальные привилегии на уровне каждого инструмента, human-in-the-loop для критичных действий.
Источник: OWASP Top 10 for LLM Applications 2025
Протоколы: MCP и A2A
Два протокола определяют, как агенты взаимодействуют с инструментами (MCP) и друг с другом (A2A):
Model Context Protocol (MCP):
| Версия спецификации | Дата | Ключевые изменения |
|---|---|---|
2024-11-05 | Ноя 2024 | Первый релиз, JSON-RPC 2.0, нет стандартизированной аутентификации |
2025-03-26 | Мар 2025 | OAuth 2.1, Streamable HTTP (замена SSE) |
2025-06-18 | Июн 2025 | MCP-серверы = OAuth Resource Servers, RFC 8707 Resource Indicators |
2025-11-25 | Ноя 2025 | Tasks (асинхронные операции), инкрементальные scope |
MCP создан Anthropic (ноя 2024), передан в Agentic AI Foundation (AAIF) при Linux Foundation 9 декабря 2025. Platinum-участники: AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft, OpenAI.
Источники: MCP Specification 2025-11-25, One Year of MCP
Безопасность MCP основана на принципах Zero Trust:
- Инкрементальные scope — разрешения предоставляются только когда workflow их требует (а не заранее)
- Resource Indicators (RFC 8707) — токен привязан к конкретному MCP-серверу, предотвращая token mis-redemption
- Инструменты = произвольный код — спецификация требует явного согласия пользователя перед вызовом любого инструмента
Agent2Agent Protocol (A2A):
Google анонсировал A2A 9 апреля 2025 на Cloud Next. Протокол позволяет агентам обнаруживать друг друга через Agent Card (JSON), управлять задачами и обмениваться контекстом. Безопасность: короткоживущие OAuth/OIDC-токены; в v0.3 (июл 2025) добавлено поле signatures в Agent Card для верификации. A2A Project передан в Linux Foundation 23 июня 2025; позднее включён в AAIF (декабрь 2025). 50+ партнёров при запуске, Apache 2.0.
Источники: Google A2A Announcement, A2A v0.3 Update
Три модели аутентификации агентов
| # | Модель | Механизм | Стандарт/Протокол | Применение |
|---|---|---|---|---|
| 1 | Agent-as-Workload | Агент = рабочая нагрузка, X.509-SVID, mTLS | SPIFFE/SPIRE | Внутренние доверенные агенты |
| 2 | Delegated User Access | Агент действует от имени пользователя | OAuth 2.0 OBO (requested_actor + actor_token) | Агенты, выполняющие задачи пользователя |
| 3 | Hybrid | SVID как client credential для OAuth | draft-ietf-oauth-spiffe-client-auth-00 | Кросс-платформенные сценарии |
IETF-активность (на момент написания):
| Draft | Название | Статус |
|---|---|---|
draft-ietf-oauth-spiffe-client-auth-00 | OAuth SPIFFE Client Authentication | WG adopted, Standards Track |
draft-oauth-ai-agents-on-behalf-of-user-02 | OAuth 2.0 On-Behalf-Of for AI Agents | Informational |
draft-abbey-scim-agent-extension-00 | SCIM Agents and Agentic Applications | Standards Track |
draft-goswami-agentic-jwt-00 | Secure Intent Protocol: Agentic JWT | Individual |
draft-aap-oauth-profile-00 | Agent Authorization Profile for OAuth 2.0 | Individual |
Авторы draft-ietf-oauth-spiffe-client-auth: A. Schwenkschuster, P. Kasselman, S. Rose (NIST) — участие NIST подчёркивает серьёзность направления.
Источники: IETF Datatracker, HashiCorp: SPIFFE Securing Agentic AI
Microsoft Entra Agent ID
Microsoft представил Entra Agent ID (анонс май 2025, расширение на Ignite ноя 2025, Public Preview) — первая попытка вендора формализовать идентичность AI-агентов:
- Каждый агент получает уникальный Agent ID в Entra
- Agent Registry — централизованный реестр всех агентов в организации
- Lifecycle management: регистрация, governance, защита
- Conditional Access политики применяются к агентам
- OAuth flows: Authorization Code + On-Behalf-Of (OBO)
Источник: Microsoft Entra Agent ID
NIST NCCoE: следующий шаг
В феврале 2026 NIST NCCoE опубликовал concept paper «Accelerating the Adoption of Software and AI Agent Identity and Authorization». Комментарии принимаются до 2 апреля 2026. Это может стать основой для NIST SP 1800-xx Practice Guide по идентичности AI-агентов.
Источник: NIST NCCoE Concept Paper
Статус зрелости: Draft/Preview. Ни один IETF-драфт не стал RFC. Entra Agent ID в Public Preview. MCP OAuth — GA (spec 2025-11-25). Планируйте архитектуру, но будьте готовы к изменениям.
24.2. Постквантовая криптография
Угроза: «собирай сейчас, расшифруй потом»
Квантовый компьютер, способный выполнить алгоритм Шора, сломает RSA, ECDSA и ECDH — основу TLS, SSH, VPN и цифровых подписей. Точная дата появления такого компьютера неизвестна, но атака «harvest now, decrypt later» (HNDL) актуальна уже сейчас: зашифрованный трафик перехватывается и сохраняется для будущей расшифровки.
NSM-10 (National Security Memorandum, 4 мая 2022) установил дедлайн 2035 для полного перехода национальных систем безопасности США на квантово-устойчивую криптографию.
Источник: White House NSM-10
NIST PQC стандарты
13 августа 2024 NIST опубликовал три финальных стандарта:
| Стандарт | Алгоритм | Тип | Основа |
|---|---|---|---|
| FIPS 203 | ML-KEM | Key Encapsulation | CRYSTALS-Kyber (решётки) |
| FIPS 204 | ML-DSA | Digital Signature | CRYSTALS-Dilithium (решётки) |
| FIPS 205 | SLH-DSA | Digital Signature | SPHINCS+ (хэши) |
ML-KEM (FIPS 203) — замена ECDH для обмена ключами:
| Набор параметров | Уровень | Публичный ключ | Шифротекст | Общий секрет |
|---|---|---|---|---|
| ML-KEM-512 | ~AES-128 | 800 B | 768 B | 256 бит |
| ML-KEM-768 | ~AES-192 | 1 184 B | 1 088 B | 256 бит |
| ML-KEM-1024 | ~AES-256 | 1 568 B | 1 568 B | 256 бит |
ML-DSA (FIPS 204) — замена ECDSA/RSA для подписей:
| Набор параметров | Уровень | Публичный ключ | Подпись |
|---|---|---|---|
| ML-DSA-44 | Level 2 | 1 312 B | 2 420 B |
| ML-DSA-65 | Level 3 | 1 952 B | 3 309 B |
| ML-DSA-87 | Level 5 | 2 592 B | 4 627 B |
SLH-DSA (FIPS 205) — консервативная альтернатива на основе хэшей (12 вариантов, подписи 7.8–49.9 KB).
Дополнительные алгоритмы:
- FIPS 206 (FN-DSA) — на основе FALCON. Компактные подписи (~666 B). Статус: «basically written» (NIST, фев 2025), IPD ожидается в 2026
- HQC — выбран 11 марта 2025 как запасной KEM на основе кодов коррекции ошибок (не решётки). Стандарт ожидается в 2027
Источники: FIPS 203, FIPS 204, FIPS 205, NIST HQC Selection
CNSA 2.0: таймлайн миграции
NSA опубликовала CNSA 2.0 (Commercial National Security Algorithm Suite, сен 2022, обновление FAQ дек 2024) — обязательный набор алгоритмов для систем национальной безопасности:
| Дедлайн | Категория | Требование |
|---|---|---|
| 2025 | Web/Cloud | Поддержка и предпочтение CNSA 2.0 |
| 2026 | Сетевое оборудование (VPN, роутеры) | Поддержка CNSA 2.0 |
| 2027 | ОС, все новые закупки | Только CNSA 2.0 |
| 2030 | Весь софт/прошивки | Исключительно CNSA 2.0 |
| 2033 | Нишевые устройства | Исключительно CNSA 2.0 |
| 2035 | Все NSS | Полная квантовая устойчивость |
Важно: CNSA 2.0 разрешает только ML-KEM-1024 (не 512/768) и только single-tree LMS/XMSS (не multi-tree).
Источник: NSA CNSA 2.0
Гибридный TLS: ML-KEM + X25519
На переходном этапе используется гибридный обмен ключами — ML-KEM комбинируется с X25519 (классическая ECDH). Оба алгоритма должны быть сломаны для компрометации:
IETF draft: draft-ietf-tls-ecdhe-mlkem-03 (ноя 2025)
Именованные группы: X25519MLKEM768, SecP256r1MLKEM768, SecP384r1MLKEM1024
Размер Client Key Share: ~1 216 B (1 184 ML-KEM + 32 X25519)
Статус: Internet-Draft (не RFC)Поддержка в браузерах:
- Chrome 131+ (ноя 2024): X25519MLKEM768 по умолчанию
- Firefox 132+ (desktop): X25519MLKEM768 по умолчанию
Реальное принятие (Cloudflare, 2025): PQ-трафик вырос с 29% (январь) до 52% (декабрь).
Источники: Cloudflare PQ 2025, Chrome ML-KEM
PQC в облаках
| Возможность | AWS | GCP | Azure |
|---|---|---|---|
| PQ-TLS (ML-KEM) | GA: KMS, ACM, Secrets Manager, S3, ALB/NLB (2025) | Preview: Cloud KMS (окт 2025) | GA: Windows CNG (ноя 2024) |
| Цифровые подписи | — | Preview: ML-DSA, SLH-DSA в Cloud KMS (фев 2025) | GA: ML-DSA в Windows CNG |
| Библиотеки | s2n-tls + AWS-LC (FIPS 140-3) | Tink + BoringCrypto | SymCrypt-OpenSSL v1.9.0 |
| Overhead TLS | ~1 600 B / handshake, ~80-150 мкс | — | — |
Источники: AWS ML-KEM Blog, GCP KEM Preview, Microsoft PQC GA
CISA: что делать сейчас
CISA рекомендует поэтапный подход (на основе EO 14306, июн 2025):
- Инвентаризация криптографии — какие алгоритмы используются и где
- Приоритизация — данные с длительным сроком конфиденциальности (PII, государственные секреты) — мигрировать первыми
- Закупки — приобретать только PQC-совместимые продукты в категориях, где они доступны (облака, браузеры, endpoint encryption)
- Тестирование — включить PQ-TLS в тестовых средах, измерить overhead
Источник: CISA PQC Product Categories
Статус зрелости: GA — стандарты FIPS 203/204/205 финальны; GA — PQ-TLS в браузерах и AWS; Preview — GCP/Azure KMS. Draft — IETF TLS hybrid, CNSA 2.0 дедлайны обязательны для NSS.
24.3. Конфиденциальные вычисления
Защита данных в обработке
Zero Trust защищает данные в покое (encryption at rest) и в передаче (TLS/mTLS). Но есть третье состояние — данные в обработке (data in use). Если атакующий получает root-доступ к серверу, он видит данные в памяти в открытом виде. Конфиденциальные вычисления (Confidential Computing) закрывают этот gap через аппаратные доверенные среды выполнения (TEE).
Определение CCC (Confidential Computing Consortium, Linux Foundation, основан окт 2019): «Конфиденциальные вычисления — защита данных в обработке путём выполнения в аппаратно-обеспеченной, аттестированной доверенной среде выполнения». Три свойства: конфиденциальность данных, целостность данных, целостность кода.
Источник: Confidential Computing Consortium
Аппаратные TEE
| Технология | Вендор | Уровень изоляции | Облака | Статус |
|---|---|---|---|---|
| Intel TDX | Intel | VM (Trust Domain) | GCP (GA), Azure (отдельные серии/регионы) | GA на Xeon 4th/5th Gen |
| AMD SEV-SNP | AMD | VM (encrypted memory) | AWS, Azure, GCP (отдельные серии VM) | GA на EPYC 7003+ |
| ARM CCA | ARM | Realm (Armv9-A RME) | — | Не в production |
| Nitro Enclaves | AWS | Process (Nitro Hypervisor) | AWS (GA, все регионы) | GA |
| NVIDIA H100 TEE | NVIDIA | GPU memory | Azure NCC H100 v5 (GA) | GA (single-GPU: CUDA 12.4; multi-GPU: CUDA 12.8) |
Intel TDX создаёт изолированные Trust Domains — виртуальные машины с зашифрованной памятью, недоступной даже гипервизору. TDX 2.0 добавляет TEE-IO для защиты I/O-устройств.
AMD SEV-SNP (Secure Encrypted Virtualization — Secure Nested Paging) шифрует память VM и защищает от replay-атак гипервизора. Поддерживается на EPYC Milan (7003), Genoa (9004), Turin (9005).
NVIDIA H100 — первый GPU с TEE. Все данные и CUDA-ядра шифруются при передаче через PCIe. Overhead: <5% для большинства LLM-запросов. Blackwell (B200) добавляет NVLink-шифрование для multi-GPU.
Источники: Intel TDX, AMD SEV, NVIDIA CC GA
Удалённая аттестация: RATS
Как убедиться, что TEE подлинный, а не эмуляция? Удалённая аттестация — протокол, в котором TEE предоставляет криптографическое доказательство своего состояния.
IETF RATS (Remote ATtestation procedureS):
| RFC | Название | Дата | Назначение |
|---|---|---|---|
| RFC 9334 | RATS Architecture | Янв 2023 | Архитектура: Attester → Verifier → Relying Party |
| RFC 9711 | Entity Attestation Token (EAT) | Апр 2025 | Формат токена аттестации |
| RFC 9782 | EAT Media Types | Май 2025 | MIME-типы для RESTful API |
Две модели из RFC 9334:
- Passport model: TEE получает аттестационный токен от Verifier и предъявляет его Relying Party
- Background-check model: Relying Party пересылает evidence от TEE в Verifier для проверки
Облачные сервисы
Azure Confidential Computing:
- DCasv5/ECasv5 (AMD SEV-SNP) и DCesv5/ECesv5 (Intel TDX) — GA
- Microsoft Azure Attestation (MAA) — сервис удалённой аттестации через vTPM evidence
- NCC H100 v5 — AMD SEV-SNP + NVIDIA H100 GPU TEE (GA, сен 2024)
- Confidential AKS nodes, Confidential Containers на ACI
GCP Confidential Computing:
- Confidential VMs: AMD SEV (N2D), Intel TDX (C3) — GA
- Confidential GKE Nodes — GA
- Confidential Space — multi-party computation с OIDC-аттестацией
- Intel Trust Authority — сторонняя аттестация, убирает GCP из цепочки доверия
AWS:
- Nitro Enclaves — полная изоляция (нет storage, нет networking, нет shell), только vsock к parent instance
- SEV-SNP на M6a/C6a/R6a — GA
- PCR-измерения Nitro: PCR0 (образ), PCR1 (ядро), PCR2 (приложение) → KMS condition key
Источники: Azure CC, GCP CC, AWS Nitro Enclaves
Конфиденциальные контейнеры
Kata Containers (OpenInfra Foundation, v3.5.0) создают лёгкие VM для изоляции каждого pod. Confidential Containers (CoCo) — проект CNCF Sandbox, интегрированный с Kata — добавляет hardware-based TEE к контейнерам: attestation agent, guest image pull, confidential data hub.
NVIDIA использует стек Kata + CoCo для «trusted AI anywhere» — on-prem, private cloud, public cloud, edge.
Источники: CNCF CoCo, Kata 3.5.0
Статус зрелости: GA — AMD SEV-SNP и Intel TDX доступны в основных облаках (отдельные серии VM/регионы); GA — Nitro Enclaves; GA — NVIDIA H100 TEE (single-GPU). Preview — Confidential Containers. Draft — ARM CCA (нет production-silicon).
24.4. IoT/OT и Zero Trust
Проблема: миллиарды устройств без TPM
IoT/OT-устройства — от промышленных контроллеров (PLC) до датчиков температуры — представляют уникальный вызов для Zero Trust:
Ограниченные ресурсы. RFC 7228 классифицирует устройства: Class 0 (<10 KiB RAM, <100 KiB Flash) не могут выполнять TLS. Class 1 (~10 KiB/~100 KiB) могут с ограничениями. Class 2 (~50 KiB/~250 KiB) близки к обычным узлам.
Нет агентов. На PLC нельзя установить EDR или SPIRE-агент.
Длительный жизненный цикл. Промышленное оборудование работает 15-20 лет; обновления firmware редки или невозможны.
Физический доступ. Устройства в поле, на производстве, в удалённых локациях — физическая безопасность ограничена.
Источник: RFC 7228
Стандарты и фреймворки
| Стандарт | Организация | Фокус |
|---|---|---|
| NIST SP 800-213 | NIST | IoT Device Cybersecurity Guidance для федеральных систем |
| NIST IR 8425 | NIST | Профиль IoT-безопасности для потребительских устройств (сен 2022) |
| IEC 62443 | IEC | Industrial Automation and Control Systems Security — 14 документов |
| NIST SP 800-82 Rev 3 | NIST | OT Security Guide |
| CISA ZTMM v2 | CISA | Devices pillar: от ручного инвентаря до real-time compliance |
IEC 62443 — основной стандарт промышленной кибербезопасности. Определяет Security Levels (SL 1-4) и зоны/каналы — предшественник микросегментации для OT.
U.S. Cyber Trust Mark — добровольная программа маркировки IoT (FCC, запуск янв 2025). Устройства проходят сертификацию по NIST IR 8425. На момент написания программа переживает организационные сложности: UL Solutions вышла из роли Lead Administrator (дек 2025) после расследования FCC.
Источники: NIST SP 800-213, IEC 62443, NIST IR 8425
Паттерны Zero Trust для IoT/OT
Паттерн 1: IoT Gateway / Proxy
Для Class 0-1 устройств — gateway выступает PEP:
Gateway аутентифицирует устройство (по MAC, сертификату или pre-shared key), терминирует протокол (CoAP/MQTT) и формирует mTLS-запрос к backend с SVID, полученным от SPIRE.
Паттерн 2: Микросегментация OT-сетей
Zscaler предлагает агентless сегментацию для OT/IoT: устройства изолируются без установки агентов или перенастройки VLAN. Siemens представил SINEC Secure Connect (it-sa 2025) — первую ZT-платформу для OT-сетей: overlay-сети без VPN, Machine-to-Machine/Cloud/Datacenter подключение.
Паттерн 3: Device Identity и Onboarding
FIDO Device Onboard (FDO) — протокол автоматической регистрации IoT-устройств (FIDO Alliance). Устройство содержит Device Initialize (DI) credential с завода → при первом подключении выполняет Transfer Ownership Protocol → получает credentials для рабочей среды. Заменяет ручную настройку.
Облачные платформы:
| Платформа | Идентичность устройства | Протоколы | Примечание |
|---|---|---|---|
| AWS IoT Core | X.509 сертификат, custom auth | MQTT, HTTPS, MQTT over WSS | Just-in-Time Provisioning по CA |
| Azure IoT Hub | X.509 или SAS-token, DPS | MQTT, AMQP, HTTPS | Device Provisioning Service (DPS) — zero-touch |
| GCP | — | — | IoT Core закрыт 16 авг 2023. Партнёрские решения (Clearblade) |
Источники: AWS IoT Core, Azure IoT Hub, FIDO FDO
Атаки на IoT/OT: масштаб
По данным Zscaler ThreatLabz, атаки на OT/IoT выросли на 400% год к году (2024-2025). Категории:
- Botnets (Mirai, Mozi) — компрометация через default credentials
- Ransomware на OT (Colonial Pipeline, 2021 — Глава 1)
- Supply chain через firmware (XZ Utils, 2024 — Глава 13)
Статус зрелости: GA — AWS IoT Core, Azure IoT Hub; GA — IEC 62443 (зрелый стандарт). Preview — SINEC Secure Connect, Zscaler OT segmentation. Draft — US Cyber Trust Mark (программа в пересмотре).
24.5. Lab: проверка PQC-совместимости TLS
Практика: проверяем, поддерживает ли ваш сервер гибридный PQ-TLS.
Предварительные требования
- OpenSSL 3.x с oqs-provider или AWS CLI v2
- curl 8.x с поддержкой PQ (опционально)
Шаг 1: проверка PQ-поддержки сервера
# Проверяем, какие именованные группы поддерживает сервер
# Используем openssl с oqs-provider
openssl s_client -connect kms.us-east-1.amazonaws.com:443 \
-groups X25519MLKEM768 \
-brief 2>&1 | grep -E "Protocol|Cipher|Group"Ожидаемый вывод для AWS KMS:
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Peer groups: X25519MLKEM768Шаг 2: сравнение handshake с PQ и без
# Классический TLS (X25519)
time openssl s_client -connect kms.us-east-1.amazonaws.com:443 \
-groups X25519 -brief < /dev/null 2>&1
# Гибридный PQ-TLS (X25519MLKEM768)
time openssl s_client -connect kms.us-east-1.amazonaws.com:443 \
-groups X25519MLKEM768 -brief < /dev/null 2>&1Разница: ~80-150 мкс дополнительно для ML-KEM, ~1 600 байт на handshake.
Шаг 3: AWS CLI с PQ-TLS
# AWS CLI v2 поддерживает PQ-TLS для KMS
export AWS_KMS_PQ_TLS_ENABLED=true
# Проверяем, что используется PQ-TLS
aws kms generate-random --number-of-bytes 32 \
--debug 2>&1 | grep -i "post-quantum\|mlkem\|kyber"Шаг 4: аудит криптографии в инфраструктуре
# Сканирование endpoint'ов на PQ-совместимость
# Используем nmap с ssl-enum-ciphers
nmap --script ssl-enum-ciphers -p 443 your-service.example.com
# Или testssl.sh для подробного анализа
# https://github.com/drwetter/testssl.sh
./testssl.sh --pq your-service.example.com:443Результат Lab: вы проверили PQ-TLS совместимость endpoint'а, сравнили overhead и настроили AWS CLI для PQ-TLS. Следующий шаг — инвентаризация всех TLS-endpoint'ов и приоритизация миграции по рекомендациям CISA.
Связь с другими главами
| Тема | Глава | Связь |
|---|---|---|
| NHI и SPIFFE/SPIRE | Гл. 7 | Фундамент workload identity для агентов |
| TPM и аттестация устройств | Гл. 8 | Аппаратный корень доверия → TEE аттестация |
| EDR и osquery | Гл. 9 | Continuous assessment для IoT через Fleet |
| Микросегментация | Гл. 10 | Cilium/Calico для K8s, IEC 62443 для OT |
| mTLS и service mesh | Гл. 12 | mTLS → PQC-mTLS миграция |
| Supply chain security | Гл. 13 | SBOM для IoT firmware, Sigstore → PQC подписи |
| CI/CD OIDC federation | Гл. 15 | Agent CI/CD → OIDC → облачные ресурсы |
| Legacy/IoT контекст | Гл. 23 | Proxy patterns для legacy IoT/OT |
| SPIRE federation | Гл. 22 | Cross-cloud identity для агентов |
| Эталонная архитектура | Гл. 25 | Crypto-agility в ADR |
Итоги
- AI-агенты — новый класс NHI. Три модели аутентификации: SPIFFE (agent-as-workload), OAuth OBO (delegated), гибрид (SPIFFE+OAuth). MCP spec
2025-11-25реализует ZT-принципы: инкрементальные scope, Resource Indicators, явное согласие. Ни один IETF-драфт не стал RFC — стандарты формируются - PQC — FIPS 203/204/205 финальны (авг 2024). Гибридный TLS (X25519MLKEM768) уже в Chrome/Firefox и AWS. 52% трафика Cloudflare использует PQ. CNSA 2.0 обязывает NSS мигрировать к 2035. Начинайте с инвентаризации криптографии и включения PQ-TLS в тестовых средах
- Конфиденциальные вычисления — AMD SEV-SNP и Intel TDX GA во всех облаках. NVIDIA H100 — первый GPU с TEE. RFC 9334/9711 стандартизируют удалённую аттестацию. Применяйте для обработки чувствительных данных и multi-party computation
- IoT/OT — gateway pattern для Class 0-1, микросегментация для OT. IEC 62443 = промышленный стандарт. AWS IoT Core / Azure IoT Hub обеспечивают X.509-based identity. GCP IoT Core закрыт (авг 2023) — используйте партнёрские решения
- Все четыре направления движутся от draft к production. Стройте архитектуру с учётом криптографической гибкости (crypto-agility) — возможности быстро переключить алгоритмы, не переписывая приложения