Про Zero Trust написано много, и почти всё – про принципы. Гораздо полезнее посмотреть, во что эти принципы превращаются в реальной эксплуатации: какие решения принимаются, от чего приходится отказаться и что ломается, если сделать наполовину.
Ниже – устройство инфраструктуры, в которой работает моя команда. Это не витрина: клиенту мы отдаём ровно ту же схему, потому что защищать чужой периметр по правилам, которые не применяешь к себе, нечестно.
Серверы: разносим не машины, а аккаунты
Базово всё разворачивается в Hetzner, но принципиально здесь другое. Прокси-серверы, основные и резервные живут на разных аккаунтах с разными способами оплаты.
Про этот риск обычно забывают. Резервирование строят на уровне машин и дата-центров, а единой точкой отказа остаётся учётная запись у провайдера: блокировка по спорному платежу, ошибка антифрода, претензия по абузе – и вся инфраструктура, включая бэкапы, недоступна одновременно. Разные аккаунты и разные платёжные инструменты убирают именно этот сценарий, а не абстрактную «отказоустойчивость».
Привязки к площадке при этом нет: работаем с облаками (AWS, Google Cloud, Microsoft Azure), с любыми поставщиками физических серверов и с виртуализацией на VMware ESXi, Proxmox VE или QEMU/KVM. Как это выглядит на конкретном кластере, я разбирал в статье про Proxmox как код. Выбор площадки – вопрос задачи и юрисдикции, а не привычки.
Секреты: OpenBao и аппаратные ключи
Секреты хранятся в OpenBao, а мастер-ключ не лежит на сервере целиком: он разделён на доли, и доли хранятся в аппаратных ключах. Разница с «паролями в зашифрованном файле» принципиальная: украденный диск бесполезен сам по себе, а поднять хранилище заново нельзя, пока держатели долей не соберутся физически.
Дальше действует правило, которое и делает Zero Trust рабочим, а не декларативным: все секреты выдаются временно и ротируются после выполнения задачи. Не существует инженера с постоянным доступом «на всякий случай». Украденный доступ полезен ровно до конца задачи, ради которой его выдали.
Рабочие места инженеров
- Аппаратные ключи у всех. YubiKey – не рекомендация для желающих, а условие доступа. Фишинг перестаёт работать как класс атаки: перехваченный пароль без физического ключа бесполезен.
- Только зашифрованные MacBook или Linux. Windows на рабочих местах не используется – это осознанное сужение поверхности атаки, а не спор о вкусах.
- Apache Guacamole для доступа к административным интерфейсам: сессия идёт через шлюз, а не напрямую с ноутбука инженера, и остаётся в журнале.
Никто не работает с данными руками
Прямого доступа к данным нет ни у кого. Любое изменение проходит через пайплайн Ansible и только после выполнения резервной копии.
Это даёт три вещи сразу. Изменение воспроизводимо: его можно прочитать, проверить и повторить. Оно обратимо: бэкап снят до, а не «наверное, был вчера». И оно не зависит от состояния конкретного человека в конкретный вечер – самая частая причина аварий в эксплуатации не злоумышленник, а усталый администратор с правами root.
Где Zero Trust ломается на практике
Модель почти никогда не разваливается целиком. Она разваливается по одному исключению за раз, и все исключения выглядят разумно в момент, когда их делают.
- «Выдай постоянный доступ, я устал каждый раз запрашивать». Одна такая учётка обнуляет весь смысл временных секретов: злоумышленнику достаточно найти именно её.
- Секрет, отправленный в переписку. Он мгновенно оказывается вне хранилища, вне ротации и вне журналов – и живёт там годами.
- Бэкап на том же аккаунте. Классика: резервирование есть, но оно погибает вместе с основным контуром от одного административного действия провайдера.
- Исключение «только для этого сервера». Инфраструктура состоит из исключений примерно через полгода после первого.
Поэтому Zero Trust – в первую очередь дисциплина, а не набор продуктов. Купить его нельзя: можно купить хранилище секретов и аппаратные ключи, но если рядом живёт постоянная учётка «для удобства», защищённость определяется именно ею, а не остальной схемой.
Как эта дисциплина собирается в законченный контур – периметр, устройства сотрудников, SIEM, шифрование и отработка инцидентов – описано на странице проекта по информационной безопасности.
Что мы сознательно не делаем
Мы не занимаемся первой линией техподдержки. Не потому, что это ниже достоинства, а потому что это другая профессия с другой экономикой и другим ритмом. Наша зона – экспертиза и core-инфраструктура: проектирование, безопасность, эксплуатация критичного контура.
Из того же принципа честности: часть собственных разработок мы не продаём как коробку. Пока продукт не прошёл достаточного пробега на своих задачах, продавать его – значит перекладывать эксперимент на клиента.
Частые вопросы
Зачем разносить серверы по разным аккаунтам? Учётная запись у провайдера – такая же единая точка отказа, как одна стойка: блокировка делает недоступной всю инфраструктуру вместе с бэкапами.
Чем это лучше зашифрованного хранилища? Мастер-ключ не хранится на сервере целиком: он разделён на доли в аппаратных ключах, поэтому украденный диск бесполезен.
Почему изменения только через пайплайн? Они воспроизводимы, обратимы и не зависят от состояния конкретного человека вечером в пятницу.
Zero Trust требует менять инфраструктуру? Нет, модель описывает порядок выдачи доступа, а не оборудование, и одинаково ложится на облака, bare-metal и виртуализацию.
Нужна консультация?
Если вы выстраиваете защищённый контур и хотите понять, где в нём остались единые точки отказа, запишитесь на бесплатную 15-минутную консультацию. Разберём вашу схему и покажем слабые места.
