Глава 11. SASE и подключение

В Главе 10 мы рассмотрели микросегментацию — контроль east-west трафика между рабочими нагрузками. Эта глава посвящена north-south трафику: как пользователи подключаются к приложениям. VPN десятилетиями был стандартным ответом, но архитектура Zero Trust предлагает другой подход — Zero Trust Network Access (ZTNA), где доступ предоставляется к конкретному приложению, а не к целой сети.

Зачем заменять VPN

Архитектурные ограничения VPN

VPN создаёт зашифрованный туннель между устройством пользователя и корпоративной сети. После подключения пользователь получает IP-адрес внутренней сети и доступ ко всем ресурсам в разрешённых подсетях. Это модель неявного доверия по факту подключения.

Характеристика	VPN	ZTNA
Область доступа	Сетевой уровень (подсеть/VLAN)	Уровень приложения (per-app)
Модель доверия	Неявное после аутентификации	Непрерывная проверка каждого запроса
Архитектура	Централизованный концентратор	Облачная, распределённая
Латеральное перемещение	Возможно	Предотвращено by design
Видимость приложений	Все приложения видны в сети	Невидимы для неавторизованных
Масштабирование	Ограничено аппаратной ёмкостью	Облачная эластичность
Проверка устройства	Обычно не проверяется	Проверяется при каждой сессии

VPN как вектор атак

VPN-устройства — привлекательная цель для атакующих:

Colonial Pipeline (май 2021): DarkSide использовал устаревшую учётную запись VPN без MFA. Пароль был обнаружен в утечке. Результат — остановка крупнейшего нефтепровода США (5 500 миль), выплата $4,4M выкупа. CEO Джозеф Блаунт подтвердил перед Сенатом: вектор атаки — legacy VPN профиль.

Источник: Cybersecurity Dive — Colonial CEO Testimony

Pulse Secure CVE-2021-22893 (апрель 2021): Критическая RCE-уязвимость (CVSS 10.0) в Pulse Connect Secure. Китайские APT-группы скомпрометировали оборонные предприятия и правительственные организации США. Mandiant обнаружил 16 семейств вредоносного ПО, разработанных специально для Pulse Secure VPN.

Источник: CISA Alert AA21-110A

Fortinet FortiOS (2018-2025): Серия критических уязвимостей в SSL VPN — CVE-2018-13379, CVE-2022-42475 (использована Volt Typhoon против критической инфраструктуры), CVE-2023-27997, CVE-2024-21762. Fortinet в апреле 2025 года сообщил о случаях, когда атакующие сохраняли доступ даже после установки патчей.

Источник: CISA Fortinet Advisory, April 2025

ZTNA: приложение, а не сеть

ZTNA предоставляет доступ на уровне приложения. Пользователь подключается к конкретному сервису, а не к сети. Приложения невидимы для неавторизованных — нет IP-адреса для сканирования (принцип «dark cloud»).

NIST SP 800-207 описывает этот подход в Section 3.1.3: ZTA Using Network Infrastructure and Software Defined Perimeters. PA (Администратор политик) действует как сетевой контроллер, настраивая соединения на основе решений PE (Механизма политик). В Главе 3 мы подробно рассмотрели CSA SDP v2.0 и его 6 моделей развёртывания.

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

SASE и SSE: конвергенция сети и безопасности

SASE (Secure Access Service Edge) — термин, введённый аналитиками Gartner (Neil MacDonald, Joe Skorupa, Lawrence Orans) в отчёте «The Future of Network Security Is in the Cloud» (30 августа 2019). SASE объединяет сетевые и security-функции в единый облачный сервис:

Фреймворк	Компоненты	Категория
SASE	SD-WAN + ZTNA + CASB + SWG + FWaaS	Сетевая часть (SD-WAN) + Security (SSE)
SSE	ZTNA + CASB + SWG	Только security-компоненты (без SD-WAN)

В 2021 году Gartner выделил SSE (Security Service Edge) — security-часть SASE без SD-WAN.

Это признание того, что многие организации готовы принять security-компоненты, не заменяя при этом WAN-инфраструктуру.

Gartner Magic Quadrant for SSE (20 мая 2025): лидеры — Zscaler, Palo Alto Networks, Netskope.

Источник: Gartner IT Glossary — SASE, Gartner IT Glossary — SSE

Облачные ZTNA-решения

AWS Verified Access

AWS Verified Access (GA: 28 апреля 2023) — управляемый сервис, обеспечивающий Zero Trust доступ к приложениям в AWS без VPN. Каждый запрос оценивается по политикам, учитывающим идентичность пользователя и состояние устройства.

Источник: AWS Verified Access GA

Архитектура:

Четыре уровня компонентов:

Instance — контейнер верхнего уровня, оценивает запросы. 1 identity + N device trust providers
Trust Providers — identity (OIDC или IAM Identity Center) и device (CrowdStrike, Jamf, JumpCloud)
Groups — коллекции endpoints с общей Cedar-политикой
Endpoints — конкретные приложения: ALB, NLB, ENI, Network CIDR, Amazon RDS

Cedar — язык политик:

hcl

// Разрешить доступ пользователям из домена с доверенным устройством
permit(principal, action, resource)
when {
    context.idc.user.email.address.contains("@example.com")
    && context.crowdstrike.assessment.overall > 50
};

Cedar — декларативный язык от AWS (open source), используемый также в Amazon Verified Permissions. Политики содержат permit или forbid с условиями в when {}. Default deny — все запросы запрещены, если нет разрешающей политики.

Источник: AWS — Verified Access Policy Structure, Cedar Policy Language

Эволюция протокольной поддержки:

Дата	Возможность
Апрель 2023	GA: HTTP/HTTPS only
Декабрь 2024	Non-HTTP preview (TCP, SSH, RDP)
Февраль 2025	Non-HTTP GA — TCP/SSH/RDP
Март 2025	FedRAMP High (GovCloud) + Moderate (US East/West)

Ограничения: UDP не поддерживается, 1 identity trust provider на instance.

NIST SP 1800-35 (E4B5): Verified Access включён как PE/PA/PEP в Enterprise Build 5 «SDP and Microsegmentation». VPC Lattice используется для east-west трафика.

Источник: NIST SP 1800-35, E4B5

GCP Identity-Aware Proxy (IAP)

GCP IAP — управляемый обратный прокси, реализующий модель BeyondCorp. IAP проверяет идентичность и контекст каждого запроса перед передачей к приложению.

Поток запроса:

Пользователь отправляет HTTPS-запрос к защищённому ресурсу
IAP обнаруживает, что ресурс защищён, и перенаправляет к Google Sign-In (или внешнему IdP через Workforce Identity Federation)
После аутентификации IAP проверяет IAM-роль roles/iap.httpsResourceAccessor
При авторизации запрос передаётся backend-у с подписанным JWT (X-Goog-Iap-Jwt-Assertion, алгоритм ES256)
Backend верифицирует JWT по публичным ключам https://www.gstatic.com/iap/verify/public_key

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

Поддерживаемые ресурсы:

App Engine (standard/flexible)
Compute Engine (через Application Load Balancer)
GKE (через BackendConfig или Gateway API для кластеров 1.24+)
Cloud Run (прямая интеграция с --iap флагом, GA)
On-premises приложения (через IAP On-Prem Connector)

IAP для GKE (BackendConfig):

yaml

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: iap-config
spec:
  iap:
    enabled: true
    oauthclientCredentials:
      secretName: my-iap-secret

Источник: Enabling IAP for GKE

TCP forwarding — доступ к SSH/RDP без публичных IP:

bash

# SSH через IAP tunnel
gcloud compute ssh INSTANCE_NAME \
  --tunnel-through-iap --zone=ZONE

# RDP: создать туннель, подключить RDP-клиент к localhost
gcloud compute start-iap-tunnel INSTANCE_NAME 3389 \
  --local-host-port=localhost:3390 --zone=ZONE

Источник: IAP TCP Forwarding

Access Context Manager — context-aware политики:

yaml

# Access Level: корпоративные устройства из офисной сети
- ipSubnetworks:
    - 203.0.113.0/25
  devicePolicy:
    allowedEncryptionStatuses:
      - ENCRYPTED
    osConstraints:
      - osType: DESKTOP_WINDOWS
        minimumVersion: 10.0.1809
      - osType: DESKTOP_MAC

Источник: Access Context Manager

Chrome Enterprise Premium (ранее BeyondCorp Enterprise, переименован в апреле 2024, $6/user/month) добавляет к бесплатному IAP: DLP в браузере, URL-фильтрацию, защиту от фишинга, Certificate-Based Access (mTLS).

Источник: Chrome Enterprise Premium Pricing

Azure: Microsoft Entra Private Access

Microsoft Global Secure Access (GA: 11 июля 2024) — SSE-решение Microsoft, объединяющее:

Компонент	Функция
Entra Internet Access	Secure Web Gateway (SWG) — фильтрация веб-трафика
Entra Private Access	ZTNA — замена VPN, per-app доступ к внутренним ресурсам
Internet Access for Microsoft Services	Оптимизированный доступ к Microsoft 365 (включён в Entra ID P1/P2)

Источник: What is Global Secure Access

Ключевое отличие от конкурентов: TCP и UDP. В отличие от AWS Verified Access (только TCP) и IAP (HTTP/HTTPS + TCP tunneling), Entra Private Access поддерживает TCP и UDP — включая SSH, RDP, SMB, SQL, VoIP и другие корпоративные протоколы.

Два режима доступа:

Quick Access — широкий доступ, заменяющий VPN. До 500 application segments (FQDN, IP, CIDR). Быстрый старт.
Per-app Enterprise Applications — гранулярный контроль. Каждое приложение получает собственную Conditional Access политику (MFA, compliance, risk level).

Миграция: Quick Access → Application Discovery → per-app Enterprise apps → отключение Quick Access.

Интеграция с Conditional Access:

Universal Conditional Access расширяет CA на сетевой трафик
Compliant Network Check — блокирует доступ не через Global Secure Access (защита от кражи токенов)
Оценка: идентичность + устройство + risk level + сеть

Global Secure Access Client:

Поддерживаемые платформы: Windows, macOS (GA с июля 2025), iOS, Android
Использует LWF (Lightweight Filter) driver — не VPN-туннель, может сосуществовать с VPN
Ограничения: IPv6 не поддерживается, multi-session (RDP/VDI) не поддерживается

Стоимость: Entra Private Access — $5/user/month (требует Entra ID P1). Microsoft Entra Suite — $12/user/month (включает Private Access + Internet Access + ID Governance + ID Protection + Verified ID).

Источник: Microsoft Entra Pricing, Private Access Deployment Guide

Cloudflare Access

Cloudflare Access — ZTNA-решение на базе глобальной сети Cloudflare. Ключевое преимущество — бесплатный тарифный план для команд до 50 пользователей и простота развёртывания.

Архитектура:

cloudflared tunnel — лёгкий daemon, устанавливающий исходящий туннель от инфраструктуры к сети Cloudflare. Никаких входящих портов, никаких публичных IP.

До 1 000 туннелей и 1 000 IP-маршрутов на аккаунт
25 реплик (load balancers) на туннель
Поддерживает HTTP, SSH (браузерный терминал + short-lived сертификаты), VNC, произвольные TCP-порты

Identity providers: OIDC, SAML, GitHub, Google, Microsoft, Okta, OneLogin и другие.

Защита запросов:

Cf-Access-Jwt-Assertion — подписанный JWT в заголовке каждого запроса
Публичный ключ для верификации: https://<team>.cloudflareaccess.com/cdn-cgi/access/certs
Backend обязан верифицировать JWT — заголовок Cf-Access-Authenticated-User-Email можно подделать, если IAP обойдён

Device posture: WARP-клиент, проверка серийного номера, шифрования диска, версии ОС.

Источник: Cloudflare Access, Cloudflare Tunnel Docs, ZTNA Access Policies

Сравнение ZTNA-решений

Критерий	AWS Verified Access	GCP IAP	Azure Private Access	Cloudflare Access
GA	Апрель 2023	2019	Июль 2024	2018
Протоколы	HTTP/HTTPS, TCP (с 02/2025)	HTTP/HTTPS, TCP tunnel	TCP + UDP	HTTP, SSH, TCP
Язык политик	Cedar	IAM + Access Context Manager	Conditional Access	Dashboard rules
Device trust	CrowdStrike, Jamf, JumpCloud	Endpoint Verification, BeyondCorp Alliance	Intune Compliance	WARP client
Идентичность	IAM Identity Center, OIDC	Google Sign-In, Workforce IdF	Entra ID	15+ IdP (OIDC/SAML)
Клиент	Браузер (+ расширение для device trust)	Браузер (+ Endpoint Verification)	Global Secure Access Client	Браузер (+ WARP для private net)
NIST 1800-35	Да (E4B5)	Нет	Нет	Нет
Бесплатный тариф	Нет	IAP бесплатен (Chrome EP: $6/user)	Нет ($5/user + Entra P1)	До 50 пользователей
Стоимость	~$197/мес на HTTP-приложение	$0 (IAP) / $6/user (Chrome EP)	$5/user/мес + Entra ID P1	От $7/user/мес (Teams)

Lab: Cloudflare Access для внутреннего приложения

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

Аккаунт Cloudflare (бесплатный, до 50 пользователей в Zero Trust)
Docker (для локального тестового приложения)
Домен, делегированный в Cloudflare DNS (или можно использовать .cfargotunnel.com для теста)

Шаг 1: Установка cloudflared

bash

# macOS
brew install cloudflared

# Debian/Ubuntu
curl -L --output cloudflared.deb \
  https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb
sudo dpkg -i cloudflared.deb

# Docker
docker pull cloudflare/cloudflared:latest

Шаг 2: Запуск тестового приложения

bash

# Простое веб-приложение на порту 8080
docker run -d --name demo-app -p 8080:80 nginx:alpine
echo "Hello from Zero Trust" | docker exec -i demo-app sh -c 'cat > /usr/share/nginx/html/index.html'

# Проверка
curl http://localhost:8080
# Hello from Zero Trust

Шаг 3: Авторизация cloudflared

bash

cloudflared tunnel login
# Откроется браузер → выберите домен → токен сохранён в ~/.cloudflared/cert.pem

Шаг 4: Создание туннеля

bash

cloudflared tunnel create demo-tunnel
# Created tunnel demo-tunnel with id <TUNNEL_ID>

Шаг 5: Конфигурация туннеля

Создайте файл ~/.cloudflared/config.yml:

yaml

tunnel: <TUNNEL_ID>
credentials-file: /Users/<you>/.cloudflared/<TUNNEL_ID>.json

ingress:
  - hostname: demo.example.com    # ваш домен
    service: http://localhost:8080
  - service: http_status:404      # catch-all для остальных запросов

Шаг 6: DNS-запись

bash

cloudflared tunnel route dns demo-tunnel demo.example.com
# CNAME demo.example.com → <TUNNEL_ID>.cfargotunnel.com создан

Шаг 7: Настройка Access Policy в Cloudflare Dashboard

Перейдите в Cloudflare Zero Trust → Access → Applications
Нажмите Add an Application → Self-hosted
Укажите:
- Application domain: demo.example.com
- Session duration: 24 часа
Добавьте Policy:
- Name: Allow Company
- Action: Allow
- Include: Emails ending in @example.com (или конкретные email-адреса)
Настройте Identity Provider (например, GitHub, Google, или One-time PIN)
Сохраните

Шаг 8: Запуск туннеля

bash

cloudflared tunnel run demo-tunnel
# INF Starting tunnel
# INF Connection established connIndex=0 ...

Шаг 9: Проверка

Откройте https://demo.example.com в браузере
Cloudflare перенаправит на страницу аутентификации
Выберите Identity Provider и авторизуйтесь
После успешной аутентификации — страница приложения: «Hello from Zero Trust»

Проверьте JWT-заголовок на стороне backend-а:

bash

# Внутри контейнера или при проксировании — запрос содержит:
# Cf-Access-Jwt-Assertion: <signed JWT>
# Cf-Access-Authenticated-User-Email: user@example.com

# Верифицировать JWT по публичному ключу:
# https://<team>.cloudflareaccess.com/cdn-cgi/access/certs

Шаг 10: Запуск как сервис (production)

bash

# Linux (systemd)
sudo cloudflared service install
sudo systemctl start cloudflared

# Docker Compose
# docker-compose.yml:
# services:
#   cloudflared:
#     image: cloudflare/cloudflared:latest
#     command: tunnel run
#     environment:
#       - TUNNEL_TOKEN=<token>
#     restart: unless-stopped

# Kubernetes (DaemonSet или Deployment)
# См. https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/deployment-guides/kubernetes/

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

bash

cloudflared tunnel delete demo-tunnel
docker stop demo-app && docker rm demo-app

Интеграция с архитектурой Zero Trust

Связь	Описание	Глава
Идентичность → ZTNA	ZTNA-решения аутентифицируют пользователей через IdP, настроенный в Главе 5 (OIDC, SAML)	Глава 5
Device trust → политика	AWS Verified Access + CrowdStrike ZTA, Azure CA + Intune compliance, GCP + Endpoint Verification — все используют сигналы от Главы 8	Глава 8
EDR → risk signal	CrowdStrike ZTA score в Cedar-политике, Defender risk level в Conditional Access — EDR сигналы из Главы 9 влияют на доступ	Глава 9
Микросегментация + ZTNA	ZTNA контролирует north-south, микросегментация (Глава 10) — east-west. Вместе — полное покрытие	Глава 10
Service mesh	Для service-to-service трафика используется mTLS через service mesh (Глава 12), а не ZTNA	Глава 12

Итоги

VPN ≠ Zero Trust. VPN предоставляет сетевой доступ и неявное доверие. ZTNA предоставляет доступ к конкретному приложению с непрерывной проверкой
SASE (Gartner, 2019) = SD-WAN + SSE. SSE (Gartner, 2021) = ZTNA + CASB + SWG. Организации могут начать с SSE, не заменяя WAN
AWS Verified Access — Cedar-политики, device trust (CrowdStrike/Jamf/JumpCloud), NIST 1800-35 E4B5. TCP с февраля 2025
GCP IAP — реализация BeyondCorp. Бесплатный IAP + Access Context Manager. TCP forwarding для SSH/RDP. Chrome Enterprise Premium ($6/user) для DLP и mTLS
Azure Private Access — единственный из трёх, поддерживающий TCP+UDP. Глубокая интеграция с Conditional Access. LWF-клиент, не конфликтует с VPN
Cloudflare Access — бесплатно до 50 пользователей. cloudflared tunnel — исходящий туннель без публичных IP. Простейший путь к ZTNA для малых команд
Выбирайте по экосистеме: AWS → Verified Access, GCP → IAP, Azure → Private Access, мультиоблако → Cloudflare Access или Zscaler ZPA

Глава 11. SASE и подключение ​

Зачем заменять VPN ​

Архитектурные ограничения VPN ​

VPN как вектор атак ​

ZTNA: приложение, а не сеть ​

SASE и SSE: конвергенция сети и безопасности ​

Облачные ZTNA-решения ​

AWS Verified Access ​

GCP Identity-Aware Proxy (IAP) ​

Azure: Microsoft Entra Private Access ​

Cloudflare Access ​

Сравнение ZTNA-решений ​

Lab: Cloudflare Access для внутреннего приложения ​

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

Шаг 1: Установка cloudflared ​

Шаг 2: Запуск тестового приложения ​

Шаг 3: Авторизация cloudflared ​

Шаг 4: Создание туннеля ​

Шаг 5: Конфигурация туннеля ​

Шаг 6: DNS-запись ​

Шаг 7: Настройка Access Policy в Cloudflare Dashboard ​

Шаг 8: Запуск туннеля ​

Шаг 9: Проверка ​

Шаг 10: Запуск как сервис (production) ​

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

Интеграция с архитектурой Zero Trust ​

Итоги ​

Глава 11. SASE и подключение

Зачем заменять VPN

Архитектурные ограничения VPN

VPN как вектор атак

ZTNA: приложение, а не сеть

SASE и SSE: конвергенция сети и безопасности

Облачные ZTNA-решения

AWS Verified Access

GCP Identity-Aware Proxy (IAP)

Azure: Microsoft Entra Private Access

Cloudflare Access

Сравнение ZTNA-решений

Lab: Cloudflare Access для внутреннего приложения

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

Шаг 1: Установка cloudflared

Шаг 2: Запуск тестового приложения

Шаг 3: Авторизация cloudflared

Шаг 4: Создание туннеля

Шаг 5: Конфигурация туннеля

Шаг 6: DNS-запись

Шаг 7: Настройка Access Policy в Cloudflare Dashboard

Шаг 8: Запуск туннеля

Шаг 9: Проверка

Шаг 10: Запуск как сервис (production)

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

Интеграция с архитектурой Zero Trust

Итоги