Zero Trust — это не определённый набор продуктов и не фиксированный список правил. Это подход, который говорит, где и в какой момент принимается решение о том, кто и куда получает доступ. Классическая схема принимала это решение на границе сети: попал внутрь периметра — считаешься доверенным. Zero Trust требует решать заново по каждому запросу, выдавать минимум прав и на одну сессию, учитывая состояние устройства и контекст.
NIST SP 800-207 раскладывает архитектуру на три роли: точка принятия решения (policy engine и policy administrator), точка применения решения (policy enforcement point) рядом с ресурсом и источники данных, на которые они опираются. В январе 2026 года NSA выпустил серию Zero Trust Implementation Guidelines — вводную часть, фазу обследования и две фазы внедрения; на первый план там вынесена криптографически проверяемая идентичность устройства, а не адрес и не имя хоста.
Отсюда получается рабочий вопрос к любому слою инфраструктуры: где принимается решение, где оно применяется — и что происходит между ними, когда пропадает связь. Ниже — четыре слоя Linux-инфраструктуры: что отвечает каждый и где его ответ заканчивается.
Слой 1. Сеть и доступ к ресурсу
Микросегментация и брокеры доступа (ZTNA, identity-aware proxy) убирают из схемы главное допущение периметра. Подключение к сервису идёт не по маршруту «я в офисной сети», а по решению брокера, который знает пользователя, его устройство и запрошенный ресурс. На Linux этот слой собирают из агентов оверлейной сети, eBPF-политик между подами, прокси перед административными интерфейсами.
Что закрывается: боковое перемещение внутри сети и доступ к сервисам по одному факту сетевой связности.
Предел слоя: брокер доводит инженера до хоста и на этом заканчивается. Что происходит после установления сессии — какой учётной записью человек вошёл, какие права получил — вне его компетенции. За безупречно настроенным ZTNA-контуром обычно обнаруживается сервисная учётная запись с паролем, который знает вся смена.
Слой 2. Взаимодействие сервисов
Здесь Zero Trust дошёл до зрелости. Взаимный TLS даёт обеим сторонам проверяемую идентичность, SPIFFE и SPIRE описывают, как выдавать её самим сервисам автоматически и на короткий срок, а сервис-меш применяет политику по каждому вызову. Сертификат живёт часы, ротация идёт без участия человека, отзыв сводится к тому, чтобы не выдать следующий.
Что закрывается: доверие между процессами перестаёт опираться на сетевые адреса.
Предел слоя: модель описывает сервисы, а не людей. Инженер, который подключается к машине руками, в неё не попадает — у него нет ни такой идентичности, ни агента, который выпишет ему сертификат за миллисекунду. Разрыв между «сервисы аутентифицируются криптографией» и «люди аутентифицируются паролем» проходит ровно по этой границе.
Слой 3. Вход человека на хост
Здесь решений больше всего — три семейства:
SSH-центр сертификации. Вместо раздачи открытых ключей по хостам центр подписывает короткоживущие сертификаты: инженер получает сертификат на несколько часов, хост проверяет подпись локально. Отзыв — по истечении срока, без обхода парка. Слабое место: сертификат выдаётся при обращении к центру, поэтому центр должен быть доступен в момент начала работы.
Бастионы и системы привилегированного доступа. Сессия идёт через посредника, который пишет запись экрана, ведёт журнал команд и выдаёт пароль на время. Даёт восстановимую картину работ и контроль над тем, кто и когда подключался. Слабое место: на самом хосте по-прежнему стоит пароль — просто теперь он лежит в хранилище, а не в голове инженера. Локальный вход с клавиатуры бастион не видит вовсе.
Каталог. LDAP, Active Directory, FreeIPA плюс SSSD дают персональные учётные записи, единый отзыв и групповые политики. По духу Zero Trust это шаг вперёд: доступ привязан к человеку, а не к общей учётной записи. Слабое место: вход зависит от связи с контроллером домена. Если учётной записи нет в кэше, без связи с каталогом войти не получится. А та, что в кэше есть, продолжит пускать даже после блокировки в каталоге.
Общий знаменатель всех трёх: решение принимается в центре, применяется на устройстве, а между ними — сеть.
Слой 4. Права внутри операционной системы
Zero Trust не заканчивается на входе: принцип наименьших привилегий требует, чтобы вошедший получил ровно то, что нужно для работы. Linux даёт для этого штатный набор — группы и права файловой системы, sudoers, мандатное разграничение (SELinux, AppArmor, PARSEC в Astra Linux), пространства имён и capabilities, подсистема аудита.
Что закрывается: привилегии перестают быть двоичными «обычный пользователь или root».
Предел слоя: конфигурация статична. Она была правильной в день настройки, а через год на устройствах живёт то, что накопилось, — временно выданная группа, забытое правило sudoers, учётная запись подрядчика, который давно не работает. Zero Trust предполагает постоянную переоценку, а здесь переоценка чаще всего означает человека с ноутбуком и командой getent.
Что получается в сумме
| Принцип Zero Trust | Чем закрывается на Linux | Что остаётся открытым |
|---|---|---|
| Решение по каждому запросу | Брокер доступа, сервис-меш | Локальный вход в ОС решением не охвачен |
| Проверяемая идентичность | mTLS и SPIFFE для сервисов, каталог для людей | Идентичность человека проверяет центр, а не устройство |
| Доступ на сессию, короткий срок | Короткоживущие SSH-сертификаты, ротация в меше | Требует связи с центром в момент выдачи |
| Наименьшие привилегии | sudoers, мандатное разграничение, capabilities | Настройка дрейфует, сверки с эталоном нет |
| Непрерывная проверка | Телеметрия, состояние устройства | На устройстве без связи телеметрию некому читать |
Правый столбец складывается в один пробел. Решение о доступе живёт в центре, применение — на устройстве, и вся конструкция держится на канале между ними. Пока канал есть, схема работает. Когда его нет — а он отсутствует у выносных узлов, промышленных стендов, банкоматов, оборудования в удалённых филиалах, — остаётся выбирать между двумя плохими вариантами: пустить по кэшу и потерять отзыв или не пустить и остановить обслуживание.
Решение внутри удостоверения
Выход из этой развилки в том, чтобы перестать передавать решение по сети в момент входа. Оно принимается заранее, при выдаче, и записывается в само удостоверение: кто человек, какая роль ему открыта, на каких устройствах она действует и до какого числа. Удостоверение подписано, лежит на аппаратном токене у инженера и предъявляется устройству напрямую.
Точка принятия решения не исчезает, а разделяется во времени: политика формулируется в центре при выдаче, проверка выполняется на устройстве в момент входа — по подписи, сроку, области действия и списку отзыва. Связь нужна для управления парком, а не для того, чтобы открыть дверь.
Так устроен Tessera Access. Инженер вставляет токен и вводит PIN, устройство отправляет случайный вызов и проверяет подпись закрытым ключом — пароля в схеме нет вовсе, поэтому нечего подсматривать, выманивать и перебирать. Роль, привязка к устройству или группе и срок действия лежат в удостоверении; делегирование от одного держателя другому может только сузить права, но не расширить. Прекращение доступа опирается на короткий срок и список отзыва — отзывается конкретное удостоверение, без смены паролей на парке. Каждый вход, выход и работа с ролью пишутся в журнал на самом устройстве, а журнал выдач ведётся со сцеплением записей, так что правка истории задним числом видна.
Четвёртый слой — права после входа — закрывает Census: ролевые учётные записи, группы, sudoers и systemd-лимиты описываются подписанной декларацией, а инструмент показывает расхождение фактического состояния устройства с ней и приводит устройство к декларации. Наименьшие привилегии перестают быть разовой настройкой и становятся проверяемым состоянием, которого и требует непрерывная переоценка.
Российский контур
Российской инфраструктуре четвёртый слой достаётся частично готовым. В Astra Linux мандатное разграничение — штатный механизм: мандатный контроль целостности ограничивает даже процессы с root-правами, а замкнутая программная среда допускает запуск только подписанных программ.
Требования регуляторов ложатся на карту выше без натяжки: процесс 1 ГОСТ Р 57580.1 требует того же, что и Zero Trust, только другими словами — идентификации и многофакторной аутентификации персонала, регистрации входов с привязкой к человеку, прекращения доступа по сроку, эталона прав и сверки с ним фактических. Средство защиты поддерживает реализацию этих мер, а соответствие показывает организация; подробный разбор — в статье про ГОСТ Р 57580 на банкоматах.
С чего начинать
Порядок слоёв стоит выбирать по тому, где у вас сегодня доверие выдаётся без проверки. Если машины постоянно на связи с центром, отдача выше на первых двух слоях: брокер доступа и идентичность сервисов дают быстрый эффект. Если парк распределён и связь непостоянная, начинать надо снизу — с того, как человек входит в устройство и какие права там находит, потому что верхние слои на таком парке работают не всегда.
Любой слой стоит проверять одним и тем же вопросом: что делает эта схема, когда канал до центра пропал. Ответ «пустит по кэшу» и ответ «не пустит никого» одинаково означают, что решение о доступе так и осталось за пределами устройства.
Если у вас распределённый Linux-парк и вы примеряете к нему Zero Trust — напишите нам: разберём вашу схему по слоям и покажем вход по токену на стенде.