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