Phala и Intel TDX: аттестация сборщика Telegram

TgWitness / Документация · Развертывание и восстановление

Развертывание с высоким уровнем надежности добавляет независимые проверки среды сбора данных к проверке архива. Рецензент запрашивает записи о развертывании и доступе, хранящиеся у поставщика облачных услуг и Cloudflare, а развертывание с использованием Intel TDX добавляет аппаратную аттестацию среды сборщика данных.

Обычное использование локальной среды и Docker остаётся без изменений. Ничто здесь не запускается, пока вы не выполните развёртывание с помощью python -m tgwitness.cloud, а сборщик считывает данные с хоста только тогда, когда развертывание устанавливает TGWITNESS_ASSURANCE.

Схема в текстовом формате

1. Оператор → Сервер, брандмауэр без правил входящего трафика (API провайдера)
2. Оператор → Туннель и DNS (API Cloudflare)
3. Сервер, брандмауэр без правил входящего трафика → Туннель и DNS (только исходящие сообщения)
4. Сервер, брандмауэр без правил входящего трафика → Ключ подписи, созданный на сервере
5. Verifier, токены только для чтения → Журнал провайдера и брандмауэр
6. Verifier, токены только для чтения → Адрес туннельного коннектора и входной трафик
7. Verifier, токены только для чтения → Подписанное заявление /api/assurance
8. Verifier, токены только для чтения → Архив доказательств в формате ZIP

На этой странице

• Что может проверить верификатор
• Провайдеры
• Конфиденциальная виртуальная машина на Phala Cloud (Intel TDX)
• Перед началом работы
• Из панели
• Быстрый туннель без домена
• Развертывание
• Отладка развертывания и блокировка
• Удалить развертывание
• Любой сервер (самосертифицированный)
• Проверить
• Отчет о передаче доказательств
• Cloudflare в качестве внешнего свидетеля
• Чтение результатов развертывания

Что может проверить верификатор#

Коллектор записывает состояние SSH, сеансы, историю входа в систему и информацию о загрузке в подписанные записи process-start и host.state. На обычной виртуальной машине это локальные инвентарные записи, которые эксперт сравнивает с независимыми записями провайдера. Приведенное ниже развертывание Intel TDX дополнительно проверяет измерения, основанные на аппаратных средствах.

Провайдеры#

Используйте отдельный проект, команду, аккаунт или субаккаунт для каждого дела: тогда у верификатора будет доступ только для чтения, и он увидит только эту развертку. Учетные данные считываются из --provider-token-file или из указанной выше переменной, но ни в коем случае не из командной строки. Для AWS в файле указывается ACCESS_KEY_ID SECRET_ACCESS_KEY [SESSION_TOKEN]; регион — --location.

В каждом отчёте указывается, какую информацию не могут отобразить записи каждого провайдера. Короче говоря: Hetzner регистрирует запросы консоли; консоль восстановления DigitalOcean, Lish/Glish от Linode и веб- консоль Vultr не регистрируются как таковые, поэтому доступ root блокируется при первой загрузке, и для входа в консоль требуется сброс пароля или изменение параметров загрузки, которые регистрируются. Vultr возвращает адрес консоли при нажатии любой клавиши, позволяющей прочитать данные инстанса; ни в записи, ни в отчёте он не сохраняется.

Конфиденциальная виртуальная машина на Phala Cloud (Intel TDX)#

При этом --provider phala коллектор работает в конфиденциальной виртуальной машине Intel TDX на Phala Cloud, управляемой dstack. Хост и сотрудники Phala не могут читать её память, а процессор подписывает подтверждение того, что именно загрузила машина. Верификатор не доверяет Phala на слово: tgwitness.tdx самостоятельно проверяет каждое подтверждение, вплоть до закрепленного корневого центра сертификации Intel SGX, по спискам отзывов Intel и подписанным Intel данным о платформе, и отклоняет машины, которые могут быть отлажены или перенесены.

The OS image (about 180 MB, of which 21 MB are kept) is downloaded once from Dstack-TEE/meta-dstack into dstack-images beside the record; --tdx-image FOLDER uses another folder or an unpacked image, --tdx-image none skips the comparison. The measurement follows dstack-mr and the qemu-acpi crate of Dstack-TEE/dstack. Private measurement regressions compare QEMU's own ACPI output and a retained Phala Cloud quote; live qualification also needs the published image. --tdx-measurements still compares MRTD and RTMR0-2 given as JSON instead.

Каждый запуск коллектора, зафиксированный в журнале, сопровождается таким подтверждением, поэтому verify --evidence проверяет каждый запуск и образ ОС, с которого он был загружен. Ревизии приложений Phala и операции CVM служат в качестве журнала поставщика: изменение конфигурации Docker Compose после развертывания приводит к отклонению отчета, а перезапуски фиксируются для последующего анализа.

В панели выберите «Конфиденциальная виртуальная машина · Phala Cloud» в разделе «Дополнительно» → «Сервер 24/7» и вставьте ключ API Phala Cloud; быстрый туннель работает так же, как на Hetzner. Из командной строки:

python -m tgwitness.cloud deploy --provider phala --name case-1 --server-type tdx.small \
    --ref v0.8.0 --repository https://github.com/phishdestroy/TgWitness --quick-tunnel \
    --provider-token-file phala-key.txt
python -m tgwitness.cloud verify --record deployments/case-1/deployment.json \
    --provider-token-file phala-key.txt --cloud-init deployments/case-1/docker-compose.yaml \
    --source CHECKOUT_OF_COMMIT --fingerprint COLLECTOR_FINGERPRINT --report certificate.md
python -m tgwitness.cloud check-report --report certificate.pdf --verifier-fingerprint VERIFIER_KEY

--tdx-collateral считывает сертификаты и списки отзывов Intel из файла, а не загружает их с сайта Intel. Шлюз DNS здесь недоступен: у Phala нет провайдерского брандмауэра для исходящего трафика.

Сертификат аттестации#

При развёртывании Phala verify --report certificate.md также записывает сертификат: автономный файл certificate.html и файл формата A4 certificate.pdf, содержащий заключение, цепочку доверия от корневого сертификата Intel до ключа сборщика, сравнение с обычными серверами и серверами повышенной надёжности, результаты измерений рядом со значениями, рассчитанными на основе опубликованного образа, информацию о том, кто ручается за каждую часть, цепочку сертификатов Intel, все проверки, журнал поставщика, а также инструкции по повторению проверки. Отчёт в формате JSON остаётся авторитетным документом; страницы отображают его содержимое.

Отчёт заверяется цифровой печатью; данные заверения находятся в certificate.seal.json и соседних файлах .tsq/.tsr:

--timestamp URL (повторяемый) выбирает другие центры сертификации, --timestamp none — ни один, --sign-with none оставляет печать неподписанной. check-report проверяет хеш отчёта, подпись верификатора, каждую временную метку относительно доверенного корня и её квалифицированный статус, а также подпись PDF-файла. Юридическая сила квалифицированной временной метки за пределами ЕС, а также отчёта в целом, определяется судом или органом власти, получающим данный документ; печать подтверждает момент создания отчёта и отсутствие в нём изменений.

Аттестация не может исключить наличие уязвимости в модуле TDX или микрокоде Intel, а также физический доступ к шине памяти. Тот, кто контролирует приложение в аккаунте Phala, может развернуть другой компоуз; он отображается как новая ревизия с новым хешем компоуза. Хост контролирует источник времени машины и сеть.

Развёртывание, проверка с --evidence, перезапуски, сравнение образа ОС, заверение сертификата и удаление проверены непосредственно на Phala Cloud; см. прогон от 4 ноября 2026 года.

Прежде чем начать#

1. Зона Cloudflare, её ID учётной записи и токен API с правами Cloudflare Tunnel Edit, Zone Read и DNS Edit, указанные с помощью --cloudflare-token-file или CLOUDFLARE_API_TOKEN. Для верификатора: права Cloudflare Tunnel Read, DNS Read и, для журнала аудита, Account Settings Read. Без домена для быстрого туннеля ничего из этого не требуется.
2. Учетные данные провайдера с правом записи в выделенный проект; lock использует то же самое:
   • Hetzner: токен API с правами на чтение и запись;
   • DigitalOcean: личный токен доступа с правом записи;
   • Linode: личный токен доступа с linodes, firewall и events областями доступа «чтение/запись»;
   • Vultr: ключ API выделенного аккаунта или суб-аккаунта;
   • AWS: разрешены учетные данные IAM ec2:DescribeVpcs, ec2:DescribeImages, ec2:CreateSecurityGroup, ec2:AuthorizeSecurityGroupIngress, ec2:RunInstances, ec2:CreateTags, ec2:DescribeInstances, ec2:DescribeSecurityGroupRules и ec2:RevokeSecurityGroupIngress.
3. Кит, который нужно запустить. Тег релиза однократно сопоставляется с соответствующим китом с помощью git ls-remote; сервер всегда получает только 40-символьный коммит.

Из панели#

На вашем компьютере в меню «Дополнительно» → «Сервер 24/7» запускается то же самое deploy для Hetzner в три шага: выберите Европу или США, вставьте токен Hetzner (чтение и запись), затем проверьте тип сервера, месячную стоимость, адрес и версию, которые панель нашла по этому токену. Ничего не создается до вашего подтверждения. Панель отображает каждый шаг в виде deploy по мере их появления, а затем — адрес, токен панели и отпечаток ключа подписи. Без домена сервер получает быстрый туннель ; в разделе «Ваши серверы» → «Найти текущий адрес» он запрашивается заново после перезапуска. Для фиксированного адреса под вашим собственным доменом откройте «Дополнительно» · «Ваш собственный домен » и добавьте токен Cloudflare (подготовленная ссылка выбирает «Зона чтения», «Редактирование DNS» и «Редактирование туннеля Cloudflare»).

Токены передаются с каждым запросом из вкладки браузера на TgWitness на том же компьютере и никуда не записываются; запись развертывания, отредактированный файл cloud-init, токен панели и, для быстрого туннеля, ключ адреса хранятся в deployments/NAME внутри каталога данных. Панель предоставляет доступ к этому только главному администратору по прямому loopback-соединению (127.0.0.1без прокси или заголовков туннеля); панель, доступ к которой осуществляется через сеть, вместо этого отображает команды . По умолчанию версия соответствует тегу релиза запущенной панели, определяемому через API GitHub. Местоположение, тип сервера и цена получаются из API Hetzner: cpx22 если он предлагается, в противном случае — самый дешёвый тип x86 с объёмом памяти не менее 2 ГБ.

Быстрый туннель без домена#

--quick-tunnel заменяет --zone, --cloudflare-account и --panel-host; при этом не используется ни учётная запись Cloudflare, ни токен:

python -m tgwitness.cloud deploy --provider hetzner --name case-2026-11 --server-type cpx22 \
    --ref 0123456789abcdef0123456789abcdef01234567 --quick-tunnel --provider-token-file hetzner.token

На сервере cloudflared открывает быстрый туннель к панели: случайный https://….trycloudflare.com адрес, который меняется при каждой перезапуске cloudflared или сервера. Небольшой сервис на сервере публикует каждый адрес в случайной теме ntfy.sh , подписав его (HMAC-SHA256) ключом, хранящимся только в каталоге развёртки (address-key.txt), и повторяет это каждые три часа, поскольку ntfy.sh хранит сообщения в течение 12. deploy и Find текущий адрес принимают только подписанные сообщения, поэтому поддельное сообщение не сможет направить вас и ваш токен панели на чужой адрес. Тема находится в записи и в опубликованном cloud-init: любой, у кого они есть, может прочитать текущий адрес, который по-прежнему запрашивает токен панели. Сервер не открывает входящий порт ни в том, ни в другом случае.

Верификатор не имеет ключа адреса, и любой, кто читает тему, может публиковать в ней сообщения. Поэтому коллектор также публикует сам адрес, подписанный собственным ключом Ed25519, а verify берет самое новое сообщение, подписанное ключом коллектора в записи развертывания; сообщения упорядочиваются по времени их получения ntfy.sh, а не по времени, указанному в них. Коллектор, созданный до введения данного изменения, ничего не подписывает, и verify затем берет самое новое сообщение и указывает это в проверке statement; поддельное сообщение может только привести к сбою этой проверки, поскольку адрес по-прежнему должен отвечать ключом коллектора.

Ограничения: быстрый туннель не привязан к учётной записи Cloudflare, поэтому verify отмечает проверки туннеля, коннектора и DNS как недоступные; лучший возможный результат — incomplete. На Phala Cloud проверка проходит: коннектор работает внутри конфигурации Docker Compose, включённой в измерения. Записи провайдера, брандмауэр, подписанное заявление, измерения хоста и сравнение установщиков проверяются как обычно. Для побайтового сравнения с эталонным установщиком нужен развёрнутый коммит с поддержкой --quick-tunnel; при проверке версии 0.7.0 собирается установщик для домена и обнаруживаются различия. Cloudflare не гарантирует доступность быстрых туннелей, ограничивает очередь 200 запросами и не передаёт Server-Sent Events. Поэтому обновления панели в реальном времени (после 0.7.0) могут не проходить через такой туннель, и страницу придётся перезагружать; эта часть ещё не проверялась. Для постоянной работы используйте собственный домен.

Развертывание#

Сначала просмотрите всё, что будет отправлено. plan не отправляет запросов ни провайдеру, ни Cloudflare:

python -m tgwitness.cloud plan --provider hetzner --name case-2026-11 --server-type cpx22 \
    --ref 0123456789abcdef0123456789abcdef01234567 --zone example.org \
    --cloudflare-account CLOUDFLARE_ACCOUNT_ID --panel-host case.example.org

Затем выполните развертывание с теми же параметрами и учетными данными:

python -m tgwitness.cloud deploy --provider hetzner --name case-2026-11 --server-type cpx22 \
    --ref 0123456789abcdef0123456789abcdef01234567 --zone example.org \
    --cloudflare-account CLOUDFLARE_ACCOUNT_ID --panel-host case.example.org \
    --witness-host case-witness.example.org \
    --provider-token-file hetzner.token --cloudflare-token-file cloudflare.token

Типы серверов для начала: cpx22 (Hetzner), s-1vcpu-2gb (DigitalOcean), g6-standard-1 (Linode), vc2-1c-2gb (Vultr), t3.small (AWS). --location и --image по умолчанию для каждого провайдера — Ubuntu 24.04 в европейском регионе.

--repository принимает коммит из другого репозитория Git по протоколу https без указания учетных данных в URL (по умолчанию https://github.com/phishdestroy/TgWitness.git). deploy также принимает --out для другого каталога развертывания (по умолчанию deployments/NAME; каталог, в котором уже находится развертывание, отклоняется) и --wait, количество минут ожидания подписанного отчета сборщика: от 1 до 240, по умолчанию 20 или 60 для generic.

Команда:

1. создаёт туннель Cloudflare, входящий трафик которого перенаправляет имя хоста панели на саму панель и, если указано, имя хоста свидетеля на /api/witness/head и /api/assurance только;
2. создаёт проксированные записи CNAME для этих имён хостов, отклоняя имена, которые уже существуют;
3. создаёт брандмауэр провайдера без правил входящего трафика и сервер за ним без SSH-ключа, без резервных копий, без консольного агента и с cloud-init, который маскирует SSH, блокирует root, устанавливает cloudflared, загружает именно этот коммит, проверяет его и запускает TgWitness в качестве защищённого сервиса systemd;
4. ожидает подписанного заявления сборщика и проверяет, указаны ли в нём этот сервер и хэш данного файла cloud-init.

deployments/case-2026-11/ затем содержит:

Корневой пароль провайдера, токен туннеля и токен панели никогда не записываются deployment.json. Опубликуйте отпечаток коллектора, указанный в конце, через канал, которым вы не управляете в одиночку, например, через канал свидетеля или в сообщении получателю.

Войдите в Telegram по адресу https://case.example.org с помощью токена панели, как описано в руководстве по работе с аккаунтами. Действия панели записываются в подписанный журнал; они не являются SSH-сессиями. Свидетель может опрашивать https://case-witness.example.org.

SSH отсутствует: если начальная инициализация завершится сбоем, коллектор никогда не ответит. Удалите сервер и разверните его заново или воспользуйтесь отладочным развертыванием, чтобы найти причину.

Секреты в пользовательских данных#

Cloud-init хранит два секрета: токен панели и токен туннеля Cloudflare. Ключ подписи среди них нет; он создаётся на сервере. Hetzner, DigitalOcean и Linode не возвращают пользовательские данные через свои API. Vultr возвращает их любому ключу, который может читать инстанс, а EC2 — через DescribeInstanceAttribute. Для AWS предоставляйте верификатору только три действия из таблицы, ни в коем случае ec2:Describe*. Для Vultr следует предположить, что ключ верификатора может читать оба токена. Токен туннеля позволяет кому-либо запустить второй коннектор: verify сообщает о любом коннекторе, не находящемся на сервере, и заявления коллектора нельзя подделать таким образом, поскольку каждый из них подписывает новый челлендж. При использовании --quick-tunnel вторым секретом является ключ адреса: кто бы ни прочитал его, может опубликовать ложный адрес, который панель примет.

В публичном заявлении сборщика не указываются адрес сервера и источники логинов; оба эти элемента остаются в подписанном журнале.

Отладка развертывания и блокировка#

--debug-ssh-key KEY --debug-ssh-from 198.51.100.4 поддерживает SSH для одного ключа с одного адреса или небольшой сети, максимум /24 для IPv4 или /48 для IPv6. KEY уже зарегистрирован у провайдера: имя или ID SSH-ключа в проекте Hetzner, ID или отпечаток SSH-ключа в команде DigitalOcean, имя пользователя Linode, SSH-ключи которого добавлены в профиль root, ID SSH-ключа в учётной записи Vultr или имя пары ключей EC2 в регионе. Эти параметры не применяются к generic. Такое развертывание регистрируется как debug и никогда не отмечается как «высокого уровня безопасности». По завершении выполните sudo tgwitness-lock в качестве последней команды последнего сеанса SSH, а затем:

python -m tgwitness.cloud lock --record deployments/case-2026-11/deployment.json --provider-token-file hetzner.token

Брандмауэр теряет все правила входящего трафика. Затем в отчётах отображается, когда SSH был разрешён, а когда был закрыт; это окно остаётся видимым.

Удалить развёртку#

destroy Удаляет сервер и его брандмауэр, найденные по метке развертывания, так что развертывание, завершившееся сбоем на полпути, также удаляется, а затем — записи DNS, указывающие на его туннель, и сам туннель. Журнал сервера и ключ подписи удаляются вместе с ним: сначала экспортируйте доказательства. Запись сохраняется, помеченная removed, с указанием вызовов API, связанных с удалением.

python -m tgwitness.cloud destroy --record deployments/case-2026-11/deployment.json --confirm case-2026-11 \
    --provider-token-file hetzner.token --cloudflare-token-file cloudflare.token

Удаление через API реализовано для Hetzner. Для других провайдеров destroy процесс останавливается перед удалением и указывает метку для удаления в консоли провайдера. Ручно установленный сервер (generic) теряет только свои записи туннеля и DNS. Для быстрого развертывания туннеля не требуется токен Cloudflare: его туннель заканчивается на сервере, а его сообщения удаляются из ntfy.sh в течение 12 часов.

Любой сервер (с самоподписью)#

--provider generic предназначено для сервера, приобретённого или установленного вручную. deploy создаёт туннель и DNS, записывает install.sh (частный) и install.redacted.sh (для публикации), а затем ожидает. Скопируйте install.sh на свежеустановленный сервер Ubuntu 24.04 и запустите его там:

sudo bash install.sh

Он фиксирует состояние хоста в том виде, в каком он был (логины, аккаунты, authorized_keys, сокеты прослушивания, сервисы, запланированные задания, пакеты), устанавливает коммит, включает брандмауэр хоста, удаляет себя, маскирует SSH и завершает сессию. Отчёт по такому серверу в лучшем случае является САМОУДОСТОВЕРЕННЫМ: тот, кто запустил установщик, имел права root до этого, и у проверяющего нет доступа к записям провайдера. Это всё же лучше, чем необъяснимый сервер: инвентарь, хэш установщика и каждый последующий вход в систему подписаны.

Проверить#

Верификатору потребуются deployment.jsonопубликованный установщик, учетные данные только для чтения и, в идеале, выгрузку коммита и доказательство ZIP:

git clone -c core.autocrlf=false https://github.com/phishdestroy/TgWitness.git checkout
git -C checkout checkout 0123456789abcdef0123456789abcdef01234567
python -m tgwitness.cloud verify --record deployment.json \
    --provider-token-file read-only.token --cloudflare-token-file cloudflare-read.token \
    --fingerprint COLLECTOR_FINGERPRINT --cloud-init cloud-init.redacted.yaml \
    --source checkout --evidence tgwitness-evidence.zip --report report.md

В момент проверки верификатор запрашивает все данные у провайдера и Cloudflare; запись предоставляет только идентификаторы, по которым необходимо запросить информацию. Код завершения равен 0 для PASS, 1 для FAIL и 2 для REVIEW, INCOMPLETE или SELF-ATTESTED. --fingerprint должно поступать из независимого канала; без него ключ сравнивается только с записью оператора. python verify.py по-прежнему проверяет само доказательство ZIP, как описано в разделе «Доказательства».

Действия провайдера классифицируются: создание и запуск в течение 30 минут после создания проходят успешно; консоль, восстановление, сброс пароля, пересборка, ISO, образы, снимки, резервные копии, Systems Manager, подключение к экземпляру EC2 и открытие портов брандмауэра завершаются сбоем; действия, связанные с питанием, и всё неожиданное помечаются для проверки. Неизвестное действие никогда не проходит незаметно.

Отчёт о передаче доказательств#

--report report.md создаёт отчёт в формате Markdown и report.json рядом с ним:

1. результат, отпечаток ключа коллектора, развёртывание, провайдер, фиксация, сервер, брандмауэр, туннель;
2. каждая проверка с указанием её статуса и источника (API провайдера, API Cloudflare, отчёт сборщика, журнал доказательств);
3. журнал провайдера с оценкой каждого действия и, если провайдер это фиксирует, с указанием исполнителя;
4. конечные точки Cloudflare, хранящие соединения туннеля, конфигурацию и журнал аудита;
5. подписанное заявление сборщика;
6. что подтверждает отчёт, а что нет;
7. команды для воспроизведения результата, а также SHA-256 каждого предоставленного файла.

Передайте отчет, report.json, deployment.json, опубликованный установщик и доказательства ZIP. Подготовьте отчет заранее: журналы провайдеров хранятся в течение ограниченного времени.

Cloudflare в качестве внешнего свидетеля#

Здесь всё необязательно. Без учётной записи Cloudflare сервер всё равно работает, и два из них работают уже сегодня:

Logpush, который позволяет хранить собственную копию Cloudflare в R2, является функцией Enterprise: на бесплатном тарифном плане Cloudflare отвечает logpush is not enabled for this account. Журнал шлюза хранится там 24 часа, поэтому в режиме «доказательства» он копируется в подписанный журнал (журнал Cloudflare Gateway, содержащий DNS-запросы данного сервера, — токен только для чтения с правом «Account Analytics Read»).

Без плана «Zero Trust» у аккаунта есть одно DNS-местоположение. Когда Cloudflare отклоняет другое, сервер использует существующее, и его запросы различаются по адресу; для этого фильтра также требуется «Zero Trust PII Read», и destroy оставляет общее местоположение. Один запрос журнала охватывает не более трёх часов, поэтому копия и verify чтение данных за день в трехчасовых интервалах.

Gateway DNS отвечает за системный резолвер. Запросы DNS через HTTPS по порту 443 к другому резолверу, а также соединения с адресами, по которым поиск не проводится (например, с дата-центрами Telegram), не фиксируются в его журнале.

Cloudflare не имеет доступа к шифрованным данным Telegram, другим устройствам, привязанным к аккаунту Telegram (список устройств в режиме «evidence mode» фиксирует их со стороны Telegram) или гипервизору провайдера.

Как читать результат проверки среды#

В случае обычной виртуальной машины провайдер контролирует инфраструктуру хоста, а локальные ресурсы проверяются наряду с записями провайдера. В случае Intel TDX верификатор дополнительно проверяет характеристики оборудования, привязку коллектора, компоновку и показатели ОС. Ознакомьтесь с отдельными результатами, чтобы увидеть, какие проверки прошли успешно, а какие были недоступны.

Исторические данные о брандмауэре зависят от провайдера; Linode сохраняет версии правил. Запись валидация содержит список протестированных развертываний и оставшихся активных проверок, а область верификации связывает эти проверки среды с получением архива и проверкой его целостности.