🔐
Безпека та захист даних · Модуль 4 з 4

Принципи Zero Trust для AI

Застосуйте Zero Trust до AI-розгортань: never trust, always verify, limit blast radius.

35 хвМодуль 4/4
Прогрес треку100%

Принципи Zero Trust для AI

Zero Trust — це не buzzword. Для AI-систем він критичний: модель не повинна мати привілеїв, яких їй не потрібно зараз, а кожен запит має бути верифікований. Цей модуль показує, як застосувати 5 базових принципів Zero Trust до agentic AI та RAG-систем — щоб blast radius будь-якого compromise залишався мінімальним.

Що ви опануєте

  • 5 принципів Zero Trust у application до AI
  • Least-privilege для AI-агентів (з реальними прикладами)
  • Just-in-time access vs long-lived credentials
  • Human-in-the-loop checkpoints

Концепція 1: Least-privilege для AI-агентів

Модель або agent отримує тільки мінімум дозволів, потрібний для визначеної задачі. Не "доступ до всього", не "повний read", не "повний write".

Приклад агента для email-чорнетки:

ПравоРаніше (поганий дизайн)Zero Trust
Read inboxУсі emails, включно з archivedОстанні 7 днів, тільки unread
Send emailБудь-яким адресатамТільки до contacts user'а
ModifyМожна deleteТільки create draft
CalendarRead + writeТільки read

Без таких розмежувань, compromise агента = compromise усього inbox'у.

ℹ️Інверсія мислення

Не питайте: "які доступи я можу безпечно дати?". Питайте: "які мінімальні доступи дозволять виконати задачу?". Різниця у безпеці — на порядок.

Концепція 2: Just-in-time access

Видавайте ефемерні access-токени замість довготривалих credentials. Час життя — хвилини, не місяці.

Поганий патерн:

  • API-key для AI-сервісу зберігається у vault, перевіряється раз на квартал.
  • Якщо key витік — атакувальник має доступ до наступного quarterly rotation.

Zero Trust патерн:

  • Agent запрошує short-lived token (≤ 15 хв) при запуску задачі.
  • Token не stored — генерується на runtime.
  • Якщо token витік — corruption window ≤ 15 хв.

Технології:

  • OAuth 2.0 з token expiry.
  • AWS STS (Security Token Service).
  • Azure managed identities з token rotation.

Концепція 3: Network segmentation

AI, що працює з sensitive data, — в ізольованих сегментах зі строгим egress-контролем.

СегментЩо тамEgress
Public AIChatGPT, public APIsInternet OK
Internal AICopilot M365 internal dataТільки до vendor IPs
Sensitive AIRAG на client dataТільки до approved internal endpoints
Regulated AIHealthcare/financial AIAir-gapped, no internet

Чому це важливо: якщо attacker compromise'нув Sensitive AI segment, вони не можуть просто exfiltrate'ити дані до зовнішнього attacker.com — egress блокується.

Концепція 4: Human-in-the-loop gates

Дії agent'ів з high-stakes наслідками — тільки з явним підтвердженням людини. Це не slow down, це safety gate.

Типові high-stakes дії:

ДіяЧому потрібен human gate
Платежі / refunds > $XНезворотні фінансові наслідки
Delete операції на production dataНезворотна втрата
Email до external partyReputational/legal exposure
Modify production configOutage ризик
Sensitive data exportDLP violation potential

UX-патерн: agent готує дію, показує preview, людина клікає "approve" перед execution. Тут немає компромісу — це обов'язкове для agentic AI.

⚠️Найгірша помилка

"Це сповільнить agent." Так, сповільнить — на 30 секунд. Якщо agent виконує irreversible operation без human approval, вам потрібна не швидкість, а нова посада CAIO.

Концепція 5: Immutable audit logs

AI-дії генерують tamper-proof логи. Без можливості "поправити заднім числом". Це фундамент для розслідування інцидентів і compliance evidence.

Технічні вимоги:

  • Write-once storage — S3 Object Lock, Azure Immutable Storage, Google Cloud Storage retention policies.
  • Cryptographic chain — кожен log entry містить hash попереднього (blockchain-style).
  • External vendor archive — копія логів у third-party service (можливо immutable cloud).
  • Retention period — мінімум 12 місяців, для regulated industries — 7 років.

Що логувати для кожного AI-action:

  • Timestamp + user identity.
  • Full prompt + completion (або hash, якщо PII).
  • Tools used + parameters.
  • Approval gates passed (хто, коли).
  • Outcome — success/failure/error.

Чекліст: впровадження Zero Trust для AI

  • Аудит поточних AI-agents — які permissions реально потрібні
  • Обмежити permissions до least-privilege для кожного agent
  • Перейти від long-lived credentials до just-in-time tokens
  • Сегментувати network — sensitive AI у власних сегментах
  • Додати human-in-the-loop gates для high-stakes дій
  • Налаштувати immutable audit logging з cryptographic chain

Глибше у джерелах

Підсумок

Zero Trust для AI — це не "ще одна архітектура". Це фундамент, без якого будь-який інший контроль обходиться через одну хибну довіру. Least privilege + just-in-time access + segmentation + human gates + immutable logs — це 5 принципів, що захищають вас від 95% реальних attack scenarios.

Наступний трек: Технічна AI-грамотність — як насправді працюють LLM та RAG, без потреби бути ML-інженером.

Завершили читання? Позначте модуль як пройдений.