Что такое Zero Trust Network Access (ZTNA)?
ZTNA — это модель безопасности, основанная на предположении, что никакое устройство или пользователь не являются доверенными по умолчанию, независимо от их местоположения (внутри или вне домашней сети). Каждый запрос на доступ к ресурсам должен пройти строгую аутентификацию и авторизацию. Основная идея заключается в предоставлении доступа с наименьшими привилегиями (least privilege access), позволяя пользователям получать доступ только к тем ресурсам, которые им необходимы для выполнения работы. Этот подход помогает снизить риски утечек данных и повышает общую защищенность инфраструктуры.
Таким образом, каждый запрос проходит проверки:
- Аутентификация → кто ты?
- Авторизация → к чему именно можешь обращаться?
- Шифрование → защита транзитных данных.
Почему классический VPN не подходит?
- Доверие после подключения. Получаем доступ ко всем IP‑ресурсам.
- ACL‑ы на IP‑уровне.
- Отсутствие микросегментации — сервисы внутри LAN «видят» друг друга.
ZTNA решает эти проблемы, закрывая сеть по умолчанию и ограничивая доступ до уровня отдельного сервиса.
Знакомство с OpenZiti
OpenZiti (ZTNA) | Классический VPN | |
---|---|---|
Доступ после подключения | Закрыт. Доступ только к разрешённым сервисам | Открыт ко всей подсети |
Гранулярность | Сервис + Атрибуты | Подсеть / IP + ACL |
Открытые порты для сервисов | Нет (требуется 1 исходящий порт) | Да |
Встраиваемость | SDK Go/C/JS/iOS/Android | Нет |
Авторизация | mTLS + атрибутные политики | Сетевые ACL |
Масштабирование | Роли, шаблоны, авто‑ротация сертификатов | Ручное управление IP‑списками |
OpenZiti — это инструментарий (overlay‑network + PKI + SDK) для построения Zero Trust прямо внутри приложений или туннелем поверх существующей сети (overlay network).
Архитектура OpenZiti
Компонент | Функция | Порты (по умолчанию) |
Controller | PKI, политики, авторизация | 6262/TCP (ctrl), 8440/TCP (mgmt‑API) |
Edge Router | Публичная точка входа / выхода | 3022/TCP (data) |
Fabric Router | Mesh‑маршрутизация внутри overlay | 3022/3023 TCP |
Tunnelers / SDK | Клиенты (desktop, mobile, сервисы) | Исходящее соединение → Edge Router |
Оверлейная сеть OpenZiti обеспечивает безопасное соединение поверх существующей сетевой инфраструктуры, такой как Интернет.Основные компоненты сети OpenZiti:
- OpenZiti Controller. Управляет конфигурацией, аутентификацией и сервисами.
- OpenZiti Router. Действует как маршрутизатор в оверлейной сети, направляя трафик и формируя ячеистую сеть.
- OpenZiti Clients / Tunnelers. Позволяют устройствам подключаться к оверлейной сети. Пример: Ziti Desktop Edge, Ziti Mobile Edge и ziti-edge-tunnel для Linux. Они могут создавать туннели для перенаправления трафика между обычной и оверлейной сетями.
OpenZiti строит оверлейную ячеистую сеть, обеспечивая защиту и изоляцию трафика даже в потенциально скомпрометированных средах. Весь трафик защищен с использованием взаимной аутентификации (mTLS) и сквозного шифрования (ChaCha20-Poly1305), что предотвращает перехват данных на сетевых узлах. Доступ к сети и данным возможен только после обязательной авторизации и аутентификации.
«Идентичности» и регистрация
В OpenZiti всё строится вокруг Identities (cert + key). Есть два способа выпуска:
Метод | Когда используют | Как работает |
OTT (One‑Time Token) | Редкие или ручные регистрации | Генерируем enroll‑token , передаём по безопасному каналу, клиент запускает ziti edge enroll <token> и получает сертификат. |
CA‑Enrollment | Автоматическое масштабное подключение | Внешний CA подписывает CSR, Controller проверяет цепочку и выдаёт сертификат без токена. |
После enroll
клиент получает .json‑файл с PKCS8 ключом и конфигом сети — храните его как пароль!
Практический кейс: моя домашняя лаборатория
Топология
Моя топология выглядит так. В общем-то можно обойтись и без VPS, если у вас белый статический IP. Но я рекомендую использовать VPS как edge роутер.
- Edge Router + Controller подняты на недорогом VPS, 1 Гб RAM вполне достаточно.
- Дома — homelab‑router на Raspberry Pi.
- Смартфоны/ноутбуки — клиенты Ziti Desktop Edge/Ziti Mobile Edge.
Конфиги и политики
Ниже — выдержки из моей сети с комментами.
6.1 Роутеры
{
"name": "edge-router",
"roleAttributes": ["edge-router"],
"isTunnelerEnabled": false,
"enrollment": { "ott": true }
}
Публичный Edge Router на VPS, не туннелирует трафик, только маршрутизирует.
{
"name": "homelab-router",
"roleAttributes": ["homelab-router"],
"isTunnelerEnabled": true,
"enrollment": { "ott": true }
}
Домашний туннелер. Он «привязывает» локальные сервисы к оверлею.
6.2 Идентичности
{
"name": "shady-phone",
"roleAttributes": ["homelab-service"],
"type": "Default"
}
Смартфон получит доступ к сервисам с ролью homelab-service
.
6.3 Intercept и Host‑Config
{
"name": "homelab-intercept-config",
"configTypeId": "g7cIWbcGg",
"data": {
"addresses": [
"192.168.10.0/24",
"*.inside.shady2k.ru"
],
"portRanges": [{ "low": 1, "high": 65535 }],
"protocols": ["tcp", "udp"]
}
}
На клиенте перехватываю любые обращения к LAN‑IP (192.168.10.x) или к домашним DNS‑именам.
{
"name": "homelab-host-config",
"configTypeId": "NH5p4FpGR",
"data": {
"forwardProtocol": true,
"forwardAddress": true,
"forwardPort": true
}
}
На туннелере разрешаю проброс «как есть»: исходный IP⁄порт → сервису.
6.4 Сервис и Политики
{
"name": "homelab-service",
"configs": ["@homelab-intercept-config", "@homelab-host-config"],
"roleAttributes": ["homelab-service"]
}
{
"name": "homelab-dial-policy",
"serviceRoles": ["@homelab-service"],
"identityRoles": ["#vpn-service"],
"type": "Dial"
}
Телефоны «звонят» сервису.
{
"name": "homelab-bind-policy",
"serviceRoles": ["@homelab-service"],
"identityRoles": ["@homelab-router"],
"type": "Bind"
}
Туннелер «вяжет» сервис из LAN к оверлею.
{
"name": "service-router-policy",
"edgeRouterRoles": ["#edge-router", "#homelab-router"],
"serviceRoles": ["@homelab-service"],
"semantic": "AnyOf"
}
Пакет может идти через любой из двух роутеров.
Расширенные сценарии использования
Сценарий | Что защищаем | Как выглядит | Польза |
Серверы клиентов без открытия портов | 1 EdgeRouter в ЦОД, 1 Tunnel на сервере заказчика | MSP подключается к RDP/SSH конкретного хоста | Ноль входящих правил на фаерволе клиента |
Домашняя сеть | Home Assistant, IP‑камеры | Tunnel (RPi) ←→ EdgeRouter (VPS) | Безопаснее «сквозных» HTTPS‑портов |
Замена site‑to‑site VPN | Две локации с Ziti Routers | Роли и сервисы вместо IP субсети | Микросегментация inter‑site |
Промышленный IoT | PLC, SCADA | Tunnel в шкафу + Edge в облаке | PKI‑основанное соединение, без NAT punching |
Плюсы и минусы в домашней лаборатории
Плюсы
- Нулевая поверхность атаки — сервисы не «светятся» в Интернете.
- Идентичности — удобнее запоминать роли, а не IP.
- SDK — можно встроить Ziti прямо в микросервисы.
- Ячеистая сеть — автоматический «обход» падений одного узла.
- Открытый исходный код — все компоненты сети вы устанавливаете и контролируете сами.
Минусы
- Кривая обучения круче, чем у прочих решений.
- Большинство GUI‑функций ещё в работе (CLI — мастер).
- Документация местами не очень четкая и требует длительного осмысления.
- Все нужно делать самому.
Заключение
OpenZiti переносит Zero Trust туда, где раньше правили L2/L3‑VPN. Немного усилий на понимание архитектуры — и взамен:
- Видимая снаружи инфраструктура сведена к одному порту, который открыт только на edge роутере, в домашней лаборатории порты открывать не нужно.
- Детальный контроль доступа.
- Резервирование каналов за счет дублирования роутеров.
- Простота настройки конечных устройств.
В результате моя домашняя лаборатория стала не только безопаснее, но и удобнее: больше не думаю о адресах, пробросах портов и роутинге — OpenZiti всё сделал за меня.
Если вы хотите попробовать, то можно воспользоваться сервисом Twingate, там настройки минимальные, основные функции те же, бесплатного плана вполне достаточно для того, чтобы разобраться в концепции.