Проектування та впровадження Zero Trust архітектури під ключ

Проектування та впровадження Zero Trust архітектури під ключ

Периметр-безпека померла: VPN не захищає від скомпрометованого ноутбука співробітника, а в хмарі немає «внутрішньої» мережі. Zero Trust — єдиний підхід, який працює для гібридної інфраструктури. Ми проектуємо та впроваджуємо Zero Trust архітектуру під ключ: від аудиту поточних ризиків до повного переходу на модель «ніколи не довіряй, завжди перевіряй». Досвід наших інженерів — понад 10 років у хмарній безпеці та Kubernetes. Ми впровадили Zero Trust для компаній з інфраструктурою від 50 до 5000 серверів. Гарантуємо, що після нашої роботи будь-яка атака на мережу буде зупинена на перших же етапах. Зв'яжіться з нами, щоб оцінити ваш проєкт.

Чому периметр-безпека не працює?

Класична модель безпеки будувалася на периметрі: зовні — недовірена мережа, всередині — все довірене. VPN давав доступ «всередину», і далі все було відкрито. Проблема розкрилася з приходом SaaS, віддаленої роботи та хмар: поняття «всередині» перестало існувати. Скомпрометований ноутбук співробітника опиняється «всередині» та отримує доступ до всього.

Zero Trust прибирає неявну довіру за мережевим розташуванням. Кожен запит аутентифікується та авторизується — незалежно від того, звідки він прийшов.

Слой 1: Identity-centric доступ

Фундамент Zero Trust — ідентифікація кожного суб'єкта: користувача, сервісу, пристрою.

Користувачі: MFA обов'язковий для всіх, включаючи внутрішні системи. OIDC через корпоративний IdP (Okta, Azure AD, Google Workspace) для всіх застосунків. SSO не для зручності — для централізованого контролю. Вимкнути користувача в IdP = негайно втратити доступ до всіх систем.

Сервіси: mTLS між усіма сервісами, SPIFFE/SPIRE для ідентифікації workload. Kubernetes ServiceAccount tokens з expirationSeconds: 3600 замість long-lived токенів.

Пристрої: корпоративні пристрої з перевіркою стану (MDM enrollment, disk encryption, OS версія). Доступ до чутливих ресурсів тільки з managed devices. Реалізується через device posture check в Tailscale, Cloudflare Access або Google BeyondCorp.

Слой 2: Мережева сегментація через micro-segmentation

Плоска мережа — ворог Zero Trust. Навіть якщо зловмисник потрапив на один хост, lateral movement має бути заблокований.

В Kubernetes — NetworkPolicy для кожного namespace:

---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-api-to-db
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: api
      ports:
        - protocol: TCP
          port: 5432

Default-deny-all + явні дозволи для кожної пари сервісів. Cilium або Calico з підтримкою L7-правил дозволяють дозволяти не просто «порт 80», а конкретні HTTP-методи та шляхи.

В хмарі: Security Groups з мінімальними правилами, AWS PrivateLink для міжсервісної взаємодії без публічної мережі, VPC Endpoints для AWS-сервісів.

Як мікросегментація зупиняє атаки?

Мікросегментація дробить мережу на ізольовані сегменти, кожен зі своїми правилами доступу. Навіть якщо зловмисник захопив под, він не зможе переміститися до бази даних, тому що NetworkPolicy дозволяє трафік тільки від API. За даними NIST, мікросегментація знижує час виявлення вторгнень на 70% порівняно з плоскою мережею.

Слой 3: Application-layer controls

Мережа пропускає трафік — це ще не означає, що доступ дозволено. Кожен застосунок реалізує власну авторизацію:

Service mesh authorization. Istio AuthorizationPolicy на рівні кожного сервісу — які identity можуть робити які запити. Не просто «frontend може звертатися до api», а «frontend може GET /api/products але не DELETE /api/products».

Open Policy Agent (OPA) / Rego. Централізований policy engine для складної логіки авторизації. OPA може застосовуватися як Admission Controller в Kubernetes, як middleware в застосунках, як sidecar.

# policy/authz.rego
package authz

default allow = false

allow {
  input.method == "GET"
  input.path[0] == "api"
  input.user.roles[_] == "read-only"
}

allow {
  input.user.roles[_] == "admin"
}

Слой 4: Data access controls та least privilege

Доступ до даних на рівні рядків і колонок. PostgreSQL Row Level Security:

ALTER TABLE orders ENABLE ROW LEVEL SECURITY;
CREATE POLICY orders_tenant_isolation ON orders USING (tenant_id = current_setting('app.tenant_id')::uuid);

IAM політики на AWS з condition за тегами ресурсів, а не wildcard ARN. S3 bucket policy із забороною на доступ без VPC Endpoint.

Слой 5: Visibility — логи, метрики, алерти

Zero Trust без видимості — це замок з невидимими воротами. Потрібен audit trail кожного доступу:

• CloudTrail для AWS API calls
• Vault audit log для кожного запиту секретів
• Kubernetes audit log для API server операцій
• Application-level access logs з user identity

Аномальна поведінка: користувач запросив 1000 секретів за 5 хвилин, сервіс почав звертатися до нових ендпоінтів, pod зробив egress-запит на зовнішній IP. Все це має генерувати alert через SIEM або правила в AWS GuardDuty / Falco.

Що входить в роботу

Ми надаємо повний цикл впровадження: аудит поточної архітектури, проектування цільової моделі, налаштування IdP та MFA, deployment NetworkPolicies, налаштування mTLS через service mesh, інтеграція SIEM та навчання команди. Кожен етап документується, ви отримуєте схему мережі, політики доступу та runbook для експлуатації.

Ітеративний шлях впровадження

Zero Trust не впроваджується за спринт. Типовий roadmap:

Кожен етап додає захист, не блокуючи роботу бізнесу. Спроба зробити все одразу в продакшені неминуче закінчується інцидентом доступності.

Вартість розраховується індивідуально після аудиту поточної архітектури та визначення пріоритетних ризиків. Масштаб робіт залежить від розміру інфраструктури та зрілості поточних практик безпеки. Отримайте консультацію — оцінимо ваш проєкт.