ZT Zero TrustФИЗИЧЕСКИЙ МАКЕТ · V7 QR-коды
T-Media · Zero Trust · навигация по макету

Zero Trust, который можно потрогать

Физический макет 900 × 600 мм показывает целевую модель безопасности не как набор продуктов, а как систему принятия решений о доступе и систему недопущения небезопасных состояний. Отсканируйте QR-код рядом с любой зоной макета — и вы на нужной странице.

Смотреть карту зон Все QR-коды для печати
Общий вид собранного макета Zero Trust Decision Fabric
Zero Trust Decision Fabric · ревизия V7 · вид спереди6 платформ 300×300 · 44 съёмных модуля · 18 фигур
900×600мм — размер макета в сборе
2фабрики: Decision + Security Engineering
10функциональных зон на макете
44съёмных модуля на штифтах
64маршрута связей между зонами
~8дней непрерывной печати PLA
Навигация

Карта зон макета

Десять зон на плите 900 × 600 мм. Каждая плитка — ссылка на раздел с объяснением. Расположение соответствует физическому макету: слева субъекты, в центре Decision Fabric, справа сервисы и данные, сверху конвейер Security Engineering.

Зоны 09 и 10 раскрываются в одном разделе «Данные и Hound». Полный чертёж с размерами — в инструкции PDF.

Философия модели

Две фабрики — два вопроса

Вся архитектура сводится к двум вопросам. Ответ на первый даёт Decision Fabric, на второй — Security Engineering Fabric. Цель — не добавлять защиту поверх небезопасной архитектуры, а убирать сами классы атак и плохие состояния.

Decision Fabric

Кто и что имеет право сделать?

Решает, кто, с какого устройства, в какой сессии, с какими атрибутами и к какому конкретному сервису получает доступ. Персональный маршрут до разрешённого сервиса — вместо «доступа в сеть вообще».

Conditional AccessIAM / IDMPolicy & RiskABAC-логика
Security Engineering Fabric

Что имеет право существовать?

Не позволяет небезопасному коду, артефактам, образам, конфигурациям и legacy бесконтрольно попадать в runtime и оставаться там. Жёсткие gates на каждом этапе жизненного цикла.

Spirit + DiameterSAST · секреты · зависимостиСканеры · реестрыReject / Eradicate
Зелёная труба на макете

Канонический путь доступа

В нормальной модели существует один принципиальный путь — от субъекта к конкретному сервису и его данным. Решение принимается относительно конкретного сервиса, а доступ идёт через управляемую точку входа.

SUBJECTсубъект
→
CONTEXTконтекст
→
PERSONAL ACCESST-Connect
→
DECISIONfabric
→
AUTHORIZEDдоступ
→
LBaaSворота
→
SERVICEсервис
→
DATAданные
✕  Такого нормального пути в модели нет:
SUBJECT
→
NETWORK
→
DB
и
SUBJECT
→
DATA

Субъект не ходит напрямую в СУБД или DLH — к данным обращаются только сервисы. Категории данных (ПДн, Confidential, Restricted) — атрибуты в политике, а не отдельный периметр.

Зона 02 · слева на макете

Субъекты: identity есть не только у человека

Пять классов субъектов инициируют доступ. У каждого — собственная identity, собственный контекст и собственные ограничения. Подрядчик, сервис и AI-агент — такие же полноценные субъекты, как сотрудник.

Employees / T-Team

Сотрудники

FIDO2 / Passwordless, identity пользователя, TPM-backed device identity, compliance и поведенческая история.

Contractors

Подрядчики

Атрибут contractor=true участвует в политике напрямую: «Подрядчикам нельзя доступ к ПДн» — одно правило вместо сотен ручных ACL.

Administrators

Администраторы

Привилегированные пользователи: roles, permissions, session risk, отдельные требования к устройству и способу аутентификации.

Service Identity

Сервисы

Собственная identity для back-to-back взаимодействия: разрешённые вызываемые сервисы, допустимые endpoints, runtime-контекст.

AI Agents

AI-агенты

Отдельный субъект: от чьего имени действует, какие имеет capabilities, к каким сервисам и данным допущен, что считается аномалией.

Зона на макете

Физическая метафора

Миниатюрные люди за рабочими местами, роботы-андроиды для AI-агентов и отдельные фигуры для service identities. Стол подрядчика — съёмный модуль.

Зона 03 · T-Connect

Personal Network Access

T-Connect — не Decision Fabric, а управляемый способ доставить субъекта до точки принятия решения и дальше — до конкретного сервиса. Вместе с Desktop as a Service он заменяет классический VPN.

Старая модель

VPN открывает сеть

USER
→
VPN
→
NETWORK

Много потенциально достижимых ресурсов. Получив сеть, субъект получает пространство для движения.

Целевая модель

Персональный маршрут

USER + IDENTITY + DEVICE
→
PERSONAL ACCESS
→
DECISION
→
SERVICE

Сетевой доступ превращается из широкого пространства в персональный маршрут до разрешённого сервиса.

Зона 04 · фиолетовые каналы

Контекст: три независимых риска

Контекст — не отдельная зона, а текущее состояние самого субъекта. Decision Fabric получает несколько независимых профилей; каждый со своим риском. Корректный пользователь на корректном устройстве может оказаться в скомпрометированной сессии.

Identity Risk

Кто это и как подтверждён

  • FIDO2 / Passwordless
  • Identity telemetry
  • UEBA-история поведения

Passwordless — источник сильного identity assurance: исчезают credential stuffing, spraying и phishing паролей.

Device Risk

Состояние устройства

  • TPM-backed identity
  • Diameter Agent
  • Compliance / posture
  • UEBA

Compliance — не разовая проверка при входе, а постоянное состояние в runtime.

Session Risk

Риск текущей сессии

  • Время и сетевой контекст
  • Характер операций
  • Смена устройства / окружения
  • Признаки session hijacking
Privileges

Полномочия — набор фильтров

Не одна RBAC-роль, а комбинация: roles, permissions, attributes, organization, contractor- и administrator-флаги, ownership и другие свойства субъекта и цели.

Data Context

Данные тоже имеют контекст

Discovery, classification и categorization выполняются постоянно: где данные, какой категории, какой сервис с ними работает. Data Risk подаётся в решение наравне с остальными профилями.

Зона 05 · центральный механизм

Decision Fabric — центр модели

Крупнейший модуль макета. Сюда сходятся все контекстные каналы: identity, device, session, полномочия, запрошенный сервис и endpoint, data context и сигналы UEBA. Внутри — Conditional Access, IAM/IDM, policy evaluation и risk evaluation. ABAC здесь не внешний блок, а часть общей логики.

Что входит в решение

Identity Profile + Risk Device Profile + Risk Session Risk Privileges / Attributes Requested Service / Endpoint Data Context + Risk UEBA Signals

Целевая гранулярность решения: Subject → Service → Endpoint → Data Category.

Возможные вердикты

ALLOWпропустить
DENYотказать
RESTRICTограничить
STEP-UPусилить auth
LIMITурезать scope
OBSERVEнаблюдать

Смысловые политики вместо ручных ACL: Contractor → ПДн → DENY.

Зона 06 · ворота

Authorized Access и LBaaS

После положительного решения запрос движется дальше только через управляемую точку входа. LBaaS — физические «ворота» перед service landscape на макете: зелёная труба проходит сквозь них к конкретному зданию-сервису.

DECISION
→
AUTHORIZED ACCESS
→
LBaaS
→
SERVICE
Панорама макета: ворота LBaaS и здания сервисов
Панорама: слева направо — Decision Fabric, ворота LBaaS, здания сервисов.
Зона 07 · здания сервисов

Сервисы, реестры и микросегментация

Доступ выдаётся не в сеть, а к конкретному сервису. Между зданиями на макете — физически существующие маршруты и отсутствующие пути: то, что не соединено, недостижимо.

Web App

Web

Отдельная service identity и собственные endpoints.

API

API

Явно разрешённые вызовы и межсервисная аутентификация.

Analytics

Analytics

Работа с данными DB2 и DLH через собственный scope.

ML

ML Service

Вычислительные нагрузки с собственным security-контекстом.

Service Registry

Реестр сервисов

Owner, purpose, runtime, dependencies, identity, environment, security context — всё, что нужно решению о доступе.

Endpoint Registry

Реестр endpoints

Каждый endpoint — свой data scope, permissions и risk context: /profile/read и /admin — это разные права.

HBF · eBPF

Микросегментация

Каждая допустимая связь явная: Service A → B разрешён, A → C — нет. Компрометация одного сервиса не даёт свободного lateral movement.

Inter-service Auth

Network reachability — недостаточно

Даже при разрешённом маршруте Service B обязан понимать, какой именно сервис к нему обращается. Service-to-service взаимодействие тоже основано на identity — так же, как доступ субъектов.

Зоны 09–10 · справа на макете

Данные: DB, DLH и Hound

Данные не являются отдельным периметром. Они лежат в разных системах, а над ними постоянно идёт discovery и классификация. Категории — цветные вставки внутри хранилищ на макете: атрибут данных, а не зона.

DB 1

Операционное хранилище

Цилиндрическая ёмкость. Обслуживает транзакционные сервисы; субъект не имеет прямого пути к нему.

DB 2

Хранилище Analytics

Второй цилиндр. Аналитическая нагрузка — через сервис Analytics с собственным data scope.

DLH

Lakehouse

Модульный комплекс из трёх ярусов контейнеров — съёмная сборка. Аналитические данные и категории внутри.

Hound

Робот-исследователь данных

Исследует СУБД и DLH, автоматически категоризирует содержимое и постоянно обновляет знание о данных. Data Context возвращается в Decision Fabric и security plane: неизвестное содержимое хранилищ превращается в известный контекст.

Категории данных

ПДн · Confidential · Restricted

Категория — атрибут, который политика учитывает наравне с субъектом и сервисом. Data Risk — самостоятельный вход решения наряду с Identity, Device и Session.

Зона 08 · голубые каналы

UEBA — аналитический комбайн

UEBA — не ворота доступа. Он собирает телеметрию со всей среды и возвращает обновлённый риск туда, где принимаются решения. Постоянный feedback loop: каждое решение рождает активность, активность рождает телеметрию, телеметрия — новый риск для следующего решения.

DECISION→ ACTIVITY→ TELEMETRY→ UEBA→ NEW RISK→ NEXT DECISION

Что собирает

  • Identity events
  • Device telemetry
  • Session activity
  • Service и network телеметрия
  • Data activity и access decisions

Куда возвращает риск

  • Identity Risk
  • Device Risk
  • Session Risk
  • Service Risk
  • Decision Fabric

Зачем

Ловит злоупотребление внутри легитимного доступа: identity настоящая, устройство compliant, доступ разрешён — но поведение аномальное. Именно здесь UEBA меняет следующее решение.

Зона 01 · верхний конвейер

Security Engineering Fabric

Вторая фабрика отвечает на вопрос «должен ли этот объект вообще появиться и существовать в нашей инфраструктуре?». Это производственный конвейер с жёсткими gates на каждом этапе — шире классического ASPM. На макете: лампочка идеи → рабочая станция кода → манипулятор CI/CD → реестр артефактов → арка автодеплоя → runtime.

ИДЕЯНачало жизненного цикла
КОДРазработка и проверка исходниковSAST · секреты · policy
CI / CDСборка, тесты, контрольЗависимости · provenance
АРТЕФАКТЫРеестр проверенных версийBase images · scanning
АВТОДЕПЛОЙДопуск и доставка в runtimeDeploy policy
RUNTIMEKubernetes · постоянный контрольInventory · rescanning
Spirit + Diameter

Наши инструменты фабрики

Блок Spirit + Diameter и другие security-механизмы обеспечивают проверки жизненного цикла и непрерывную оценку устройств в runtime.

Реестры и сканеры

Что существует и в каком состоянии

Service / Endpoint / Infrastructure Registry, network- и vulnerability-сканеры, конфигурационные и Kubernetes/runtime-сканеры, инвентаризации — всё стекается в фабрику и даёт актуальную картину среды.

Контейнер отбраковки на макете

Плохие состояния не защищают — их устраняют

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

REJECT
→
ISOLATE
→
REPLACE / MIGRATE
→
ERADICATE

Что попадает в отбраковку

bad codeleaked secretsvulnerable artifactsbad docker imagesobsolete componentsunsupported runtimeslegacy

Legacy — backlog на уничтожение

Legacy — не постоянная архитектурная зона, а временное плохое состояние: isolate → contain → migrate/replace → delete. Пока legacy существует, микросегментация ограничивает blast radius. Цель — не научиться идеально его защищать, а перестать его иметь.

Эффект модели

Классы атак, которые просто исчезают

Модель не «борется» с этими атаками — она убирает сами классы. Каждый механизм на макете закрывает целый класс угроз, а не отдельный вектор.

Passwordless

Атаки на пароли

Полный FIDO2 без password fallback убирает reusable password: исчезают credential stuffing, password reuse, spraying, phishing и кража паролей как способ входа.

Personal Access

Широкий сетевой доступ

«Пользователь получил сеть» заменяется на «пользователь получил маршрут к конкретному сервису». Нечего перебирать — достижимо только разрешённое.

HBF · eBPF

Lateral movement

Явные межсервисные связи убирают автоматический переход от foothold к свободному движению по инфраструктуре.

IAM + Attributes

Избыточные права

Conditional Access, атрибуты и data context позволяют выражать смысловые политики: Contractor → ПДн → DENY. Без сотен ручных ACL.

Hound

Неизвестные данные

Непрерывная классификация превращает неизвестное содержимое хранилищ в известный Data Context — чувствительное больше не «спрятано само в себе».

UEBA

Злоупотребление легитимным

Работает там, где identity настоящая и доступ разрешён, но поведение стало аномальным — обновляет риск до следующего решения.

Security Engineering

Уязвимое и устаревшее ПО

Фабрика не позволяет части проблем дойти до production, а то, что уже внутри и не соответствует целевой модели, отправляется по цепочке isolate → migrate → delete.

Производство

Как макет устроен физически

Шесть печатных платформ 300×300 мм собираются в плиту 900×600 мм. Съёмные модули фиксируются штифтами на проверенных посадочных местах — композицию можно собирать, разбирать и транспортировать. Материал: PLA, принтер Creality K2 Plus.

Разнесённый вид: съёмные модули над своими посадочными местами
Разнесённый вид: 44 съёмных модуля над проверенными местами установки.

6 платформ

300 × 300 мм каждая, соединяются штифтами Ø4,4 мм. Дальний ряд A1–A2–A3, ближний B1–B2–B3.

44 модуля

От арок микросегментации и стоек до трёхъярусного DLH. Каждый садится на собственные штифты.

18 фигур

Люди, подрядчики, AI-агенты, комбайн UEBA, робот Hound, сканер compliance и центр Decision Fabric.

~8 дней печати

3,91 кг PLA, 15 заданий, расчёт Creality Print: 187 часов нарезки + смены заданий.

📄Инструкция печати и сборкиPDF · очередь заданий, посадочные точки всех 44 модулей, проверка посадки 🏷Таблички для макетаPDF · 44 карточки 60×24 мм к подставкам ⬛QR-коды зонСтраница генерации: введите адрес сайта и распечатайте коды к зонам
План зон макета 900×600 мм с координатами
План размещения зон с посадочными координатами всех модулей.
Что читать без объяснений

Макет говорит сам

Четырнадцать тезисов, которые считываются с макета даже без подписей.

  1. Identity существует не только у человека
  2. AI-агент — самостоятельный субъект
  3. Доступ выдаётся не в сеть, а к конкретному сервису
  4. Каждое решение зависит от текущего контекста
  5. Identity, Device и Session имеют независимый риск
  6. Conditional Access и IAM/IDM живут внутри Decision Fabric
  7. Сервисы не могут свободно общаться друг с другом
  8. Пользователь не ходит напрямую к данным
  9. Категория данных — атрибут, а не периметр
  10. Классификация данных происходит постоянно
  11. UEBA непрерывно обновляет risk context
  12. Security Engineering блокирует плохое ещё в lifecycle
  13. Плохие состояния устраняют, а не защищают вечно
  14. Legacy — backlog на уничтожение, а не архитектурная зона
↑