В мире DevOps давно привыкли автоматизировать всё. Мы автоматически собираем контейнеры, автоматически разворачиваем Kubernetes, автоматически обновляем серверы, автоматически масштабируем кластеры. Но почти никогда не задаём один простой вопрос. Можно ли вообще доверять машине, которая сейчас выполняет наш код?
На первый взгляд вопрос кажется странным. Если сервер отвечает по SSH, Kubernetes считает его Ready, Prometheus собирает метрики, а Terraform успешно применил изменения, значит всё в порядке. Не обязательно.
Именно поэтому всё больше внимания получает технология Remote Attestation, удалённое подтверждение того, что система действительно находится в доверенном состоянии.
Работает, но не значит безопасно.
Представьте обычный production. Есть Kubernetes-кластер. В нём работают десятки сервисов. Каждый день проходят деплои. CI/CD зелёный. Мониторинг показывает нормальные показатели.
Но в какой-то момент один из узлов оказывается скомпрометирован. Например, изменён системный бинарник, загружен посторонний модуль ядра, отключены политики безопасности, изменены системные библиотеки, подменён контейнерный runtime.
Все сервисы продолжают работать. Пользователи ничего не замечают. Даже мониторинг не показывает проблем. Но доверять такому серверу уже нельзя.
Проверять нужно не только приложение.
Сегодня DevOps отлично умеет проверять приложения. Мы проверяем unit-тесты, интеграционные тесты, контейнеры, зависимости, CVE, качество кода. Но редко проверяем саму платформу, на которой всё это работает.
Получается странная ситуация. Мы можем доказать, что Docker-образ безопасен. Но не можем доказать, что сам хост не был изменён после запуска.
Что такое Remote Attestation?
Идея очень простая. Сервер не говорит: поверьте мне. Он говорит: вот доказательства моего состояния.
Причём доказательства должны быть свежими, криптографически защищёнными, невозможными для подделки и пригодными для автоматической проверки. Если доказательства соответствуют ожидаемому состоянию, системе можно доверять. Если нет, её следует считать потенциально скомпрометированной.
Доверие должно строиться слоями.
Современная инфраструктура давно перестала быть одним сервером. Сегодня существует несколько уровней доверия: оборудование, прошивка, BIOS или UEFI, загрузчик, ядро, операционная система, контейнерный runtime, Kubernetes, приложение.
Если один нижний слой нарушен, все верхние автоматически становятся подозрительными. Именно поэтому современные системы говорят о Layered Attestation, многоуровневой аттестации. Каждый уровень подтверждает корректность следующего. Получается своеобразная цепочка доверия.
Это похоже на цепочку поставок программного обеспечения.
После появления атак на цепочки поставок стало очевидно: недостаточно проверить только конечный контейнер. Нужно понимать, кто его собрал, из каких зависимостей, каким компилятором, на каком runner, каким ключом подписан артефакт.
Теперь похожая идея применяется и к инфраструктуре. Недостаточно знать, что приложение работает. Важно понимать, на чём именно оно работает.
Представьте Kubernetes будущего.
Допустим, новый worker пытается присоединиться к кластеру. Сегодня обычно происходит следующее: kubelet получает сертификат, узел появляется в Kubernetes, scheduler начинает размещать Pod.
Но представьте другую последовательность. Перед регистрацией узел должен доказать, что используется утверждённая версия ядра, что Secure Boot включён, что загрузчик не изменён, что контейнерный runtime соответствует эталону, что политики безопасности активны. Если хотя бы одна проверка не проходит, узел просто не допускается в кластер.
Это уже не фантастика. Именно в эту сторону развивается защищённая инфраструктура.
Почему это особенно важно для облаков?
В облачной среде серверы появляются и исчезают постоянно. Автомасштабирование может создать десятки новых виртуальных машин за несколько минут.
Возникает вопрос: как убедиться, что каждая из них действительно соответствует требованиям безопасности? Ручная проверка невозможна.
Здесь и появляется аттестация. Каждая новая машина автоматически предоставляет криптографически подтверждённую информацию о своём состоянии, а управляющая система принимает решение, допустить её к работе или нет.
DevOps постепенно переходит от автоматизации к доказательствам.
Раньше было достаточно сказать: pipeline успешно завершился. Теперь этого мало.
Возникают новые вопросы. Можно ли доказать, что контейнер не изменялся после сборки? Что образ подписан доверенным ключом? Что кластер соответствует политикам безопасности? Что сервер загружен именно с ожидаемой конфигурацией? Что инфраструктура действительно находится в известном состоянии?
Во многих организациях именно такие доказательства становятся обязательной частью процессов безопасности.
И здесь снова появляется формальная верификация.
Научная работа интересна тем, что авторы предлагают не просто автоматизировать аттестацию, а формально доказать корректность самой системы проверки. Это важное различие.
Обычно мы доверяем инструменту, потому что он давно используется. Здесь предлагается другой подход. Протокол проверки описывается математически. Конфигурация системы генерируется автоматически. Затем доказывается, что механизм проверки работает именно так, как задумано.
Получается цепочка доверия не только к серверу, но и к самому процессу проверки.
Почему это важно для DevOps?
За последние годы профессия сильно изменилась. Сначала мы автоматизировали развёртывание. Потом тестирование. Затем безопасность. Теперь начинается новый этап.
Инженеру уже недостаточно сказать: я развернул инфраструктуру. Всё чаще придётся отвечать на другой вопрос: можете ли вы доказать, что этой инфраструктуре можно доверять? И это принципиально иной уровень зрелости.
Remote Attestation — это не ещё один инструмент безопасности и не замена антивирусу. Это переход к инфраструктуре, где доверие перестаёт строиться на предположениях и начинает основываться на проверяемых фактах.
Для DevOps это означает важный сдвиг. В ближайшие годы успешный инженер будет не только автоматизировать развёртывание и эксплуатацию, но и строить системы, способные доказывать свою целостность.
Когда-то главным вопросом было: запущен ли сервер? Потом: правильно ли он настроен? Следующий вопрос уже звучит иначе: способен ли сервер криптографически доказать, что ему можно доверять?
Именно этот подход постепенно становится фундаментом современных платформ, облачной безопасности и архитектур Zero Trust.
Автор: Коробов Алексей
© Коробов А.Е., 2026