Проектирование и внедрение 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 c 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:

Каждый этап добавляет защиту, не блокируя работу бизнеса. Попытка сделать всё сразу в продакшене неизбежно заканчивается инцидентом доступности.

Стоимость рассчитывается индивидуально после аудита текущей архитектуры и определения приоритетных рисков. Масштаб работ зависит от размера инфраструктуры и зрелости текущих практик безопасности. Получите консультацию — оценим ваш проект.