Phala / Intel TDX · استقرار با تضمین بالا

TgWitness / مستندسازی · راه‌اندازی و بازیابی

استقرار با تضمین بالا، بررسی‌های مستقل محیط جمع‌آوری را به تأیید بایگانی اضافه می‌کند. بازبین، سوابق استقرار و دسترسی را که توسط ارائه‌دهنده ابری و کلودفلر نگهداری می‌شوند، استعلام می‌کند و استقرار Intel TDX، گواهی سخت‌افزاری محیط گردآورنده را اضافه می‌کند.

استفادهٔ معمولی محلی و Docker بدون تغییر است. هیچ چیزی در اینجا اجرا نمی‌شود مگر اینکه با python -m tgwitness.cloud، و کالکتور تنها زمانی میزبان خود را می‌خواند که استقرار تنظیم کند. TGWITNESS_ASSURANCE.

نمودار به صورت متن

1. اپراتور → سرور، فایروال بدون قواعد ورودی (API ارائه‌دهنده)
2. اپراتور → تونل و DNS (API کلودفلر)
3. سرور، فایروال بدون قواعد ورودی → تونل و DNS (فقط خروجی)
4. سرور، فایروال بدون قواعد ورودی → کلید امضا روی سرور ایجاد شده است
5. تأییدکننده، توکن‌های فقط-خواندنی → لاگ ارائه‌دهنده و فایروال
6. تأییدکننده، توکن‌های فقط-خواندنی → آدرس کانکتور تونل و ورودی
7. تأییدکننده، توکن‌های فقط-خواندنی → بیانیه تضمین امضا شده /api/
8. تأییدکننده، توکن‌های فقط-خواندنی → فایل فشرده شواهد

در این صفحه

• آنچه یک اعتبارسنج می‌تواند بررسی کند
• ارائه‌دهندگان
• ماشین مجازی محرمانه در Phala Cloud (Intel TDX)
• قبل از شروع
• از پنل
• تونل سریع بدون دامنه
• راه‌اندازی
• عیب‌یابی استقرار و قفل
• حذف یک استقرار
• هر سرور (خودگواهی‌شده)
• تأیید کنید
• گزارش تحویل مدرک
• کلودفلر به‌عنوان شاهد بیرونی
• خواندن نتیجه استقرار

آنچه یک راستی‌آزما می‌تواند بررسی کند#

جمع‌آورنده وضعیت SSH، جلسات، تاریخچه ورود و اطلاعات بوت را در رکوردهای امضا شدهٔ شروع-فرآیند و host.state ثبت می‌کند. در یک ماشین مجازی معمولی، این‌ها رکوردهای موجودی محلی هستند که بازبین آن‌ها را با رکوردهای مستقل ارائه‌دهنده مقایسه می‌کند. استقرار Intel TDX در زیر، به‌طور اضافی اندازه‌گیری‌های پشتیبانی‌شده توسط سخت‌افزار را تأیید می‌کند.

ارائه‌دهندگان#

برای هر پرونده از یک پروژه، تیم، حساب یا زیرحساب اختصاصی استفاده کنید: دسترسی فقط-خواندن اعتبارسنج سپس فقط این استقرار را نشان می‌دهد. اعتبارنامه‌ها از --provider-token-file یا متغیر بالا، هرگز از خط فرمان. برای AWS، فایل حاوی ACCESS_KEY_ID SECRET_ACCESS_KEY [SESSION_TOKEN]؛ منطقه است --location.

آنچه سوابق هر ارائه‌دهنده نمی‌تواند نشان دهد، در هر گزارش چاپ می‌شود. به طور خلاصه: هتزنر درخواست‌های کنسول را ثبت می‌کند؛ کنسول بازیابی DigitalOcean، Lish/Glish در Linode و کنسول وب Vultr به این صورت ثبت نمی‌شوند، بنابراین روت در اولین بوت قفل می‌شود و ورود به کنسول نیاز به ریست کردن رمز عبور یا تغییر بوت دارد، که این موارد ثبت می‌شوند. Vultr آدرس کنسول را به هر کلیدی که بتواند نمونه را بخواند، بازمی‌گرداند؛ نه رکورد و نه گزارش آن را ذخیره می‌کنند.

ماشین مجازی محرمانه روی Phala Cloud (Intel TDX)#

با --provider phala جمع‌کننده در یک ماشین مجازی محرمانه Intel TDX روی Phala Cloud، که توسط dstack مدیریت می‌شود، اجرا می‌شود. میزبان و کارکنان Phala نمی‌توانند حافظه آن را بخوانند و پردازنده، گواهی‌ای از آنچه ماشین بوت کرده است، امضا می‌کند. اعتبارسنج صرفاً به حرف Phala اکتفا نمی‌کند: tgwitness.tdx خودش هر گواهی را، تا ریشه CA Intel SGX پین‌شده، با فهرست‌های لغو اعتبار و داده‌های پلتفرم امضا شده اینتل بررسی می‌کند، و ماشین‌هایی را که قابل اشکال‌زدایی یا مهاجرت هستند، رد می‌کند.

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 که پس از استقرار تغییر کرده باشد، گزارش خطا می‌دهد و راه‌اندازی‌های مجدد برای بازبینی فهرست می‌شوند.

در پنل، در بخش Extras → Server 24/7 گزینه «ماشین مجازی محرمانه · Phala Cloud» را انتخاب کرده و یک کلید 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 به جای دانلود گواهی‌نامه‌ها و فهرست‌های لغو اعتبار اینتل از خود اینتل، آن‌ها را از یک فایل می‌خواند. Gateway DNS در اینجا در دسترس نیست: Phala فاقد فایروال ارائه‌دهنده برای ترافیک خروجی است.

گواهی اعتبارسنجی#

برای استقرار Phala، verify --report certificate.md همچنین گواهی را می‌نویسد: a certificate.html خودکفا و یک A4 certificate.pdf با نتیجه، زنجیره اعتماد از ریشه اینتل تا کلید گردآورنده، مقایسه‌ای با سرورهای معمولی و با تضمین بالا، اندازه‌گیری‌ها در کنار مقادیر محاسبه شده از تصویر منتشر شده، چه کسی برای هر بخش ضمانت می‌کند، زنجیره گواهی اینتل، هر بررسی، گزارش ارائه‌دهنده، و نحوه تکرار تأیید اعتبار. گزارش JSON سند معتبر باقی می‌ماند؛ صفحات آن را نمایش می‌دهند.

این گزارش با امضاها و مهرهای زمانی به‌صورت دیجیتال در فایل‌های certificate.seal.json و .tsq/.tsr کنار آن مهر و موم شده است:

--timestamp URL (تکرارپذیر) مراجع دیگر را انتخاب می‌کند، --timestamp none هیچ‌کدام را، و --sign-with none مهر را بدون امضا رها می‌کند. check-report هش گزارش، امضای راستی‌آزما، هر نشانگر زمانی را به یک ریشه مورد اعتماد و وضعیت معتبر آن، و امضای PDF را بررسی می‌کند. اعتبار قانونی یک مهر زمانی معتبر خارج از اتحادیه اروپا، و کل گزارش، بر عهده دادگاه یا مرجعی است که آن را دریافت می‌کند؛ این مهر نشان می‌دهد که گزارش چه زمانی وجود داشته و تغییر نکرده است.

یک گواهی‌نامه نمی‌تواند یک نقص در ماژول TDX یا میکروکد اینتل، یا دسترسی فیزیکی به گذرگاه حافظه را رد کند. هر کسی که کنترل برنامه در حساب فالا را در دست دارد می‌تواند یک کامپوز دیگر را مستقر کند؛ این کامپوز به عنوان یک بازنگری جدید با هش کامپوز جدید ظاهر می‌شود. میزبان منبع زمان و شبکه ماشین را کنترل می‌کند.

عملیات استقرار، تأیید با --evidence، راه‌اندازی مجدد، مقایسه تصویر سیستم‌عامل، گواهی مهر و موم دیجیتال با امضاها و مهرهای زمانی و نابودسازی روی خود Phala Cloud اجرا شده‌اند؛ به اجرای در تاریخ ۴ نوامبر ۲۰۲۶ و مراجعه کنید.

قبل از شروع#

1. یک زون Cloudflare، شناسه حساب آن و یک توکن API با قابلیت‌های Cloudflare Tunnel Edit، Zone Read و DNS Edit، که با --cloudflare-token-file یا CLOUDFLARE_API_TOKENبرای اعتبارسنج: خواندن تونل کلودفلر، خواندن DNS و، برای سوابق حسابرسی، خواندن تنظیمات حساب. بدون دامنه، یک تونل سریع به هیچ‌کدام از این موارد نیاز ندارد.
2. اطلاعات اعتبار ارائه‌دهنده با دسترسی نوشتن به یک پروژه اختصاصی؛ lock از همان استفاده می‌کند:
   • Hetzner: توکن API با مجوز خواندن و نوشتن؛
   • DigitalOcean: توکن دسترسی شخصی با دسترسی نوشتن؛
   • Linode: توکن دسترسی شخصی با linodes, firewall و events دامنه‌های خواندن/نوشتن؛
   • ولتر: کلید 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; سرور تنها commit ۴۰ کاراکتری را دریافت می‌کند.

از پنل#

روی کامپیوتر خود، مسیر Extras → Server 24/7 همان را اجرا می‌کند deploy برای Hetzner در سه مرحله: اروپا یا ایالات متحده را انتخاب کنید، یک توکن Hetzner (خواندن و نوشتن) را الصاق کنید، سپس نوع سرور، قیمت ماهانه، آدرس و نسخه‌ای را که پنل با آن توکن پیدا کرده است بررسی کنید. هیچ چیزی قبل از تأیید شما ایجاد نمی‌شود. پنل هر مرحله را به صورت deploy گزارش می‌کند، سپس آدرس، توکن پنل و اثر انگشت کلید امضا را نشان می‌دهد. بدون دامنه، سرور یک تونل سریع دریافت می‌کند؛ سرورها ← آدرس فعلی را پس از راه‌اندازی مجدد دوباره بررسی می‌کند. برای یک آدرس ثابت تحت دامنه خود، گزینه‌های اختیاری · دامنه خود را باز کرده و یک توکن کلودفلر اضافه کنید (لینک آماده‌شده، گزینه‌های «خواندن منطقه»، «ویرایش DNS» و «ویرایش تونل کلودفلر» را انتخاب می‌کند).

توکن‌ها با هر درخواست از زبانه مرورگر به TgWitness در همان کامپیوتر جابجا می‌شوند و در هیچ‌کجا ذخیره نمی‌شوند؛ رکورد استقرار، cloud-init حذف‌شده، توکن پنل و، برای یک تونل سریع، کلید آدرس در نگهداری می‌شوند deployments/NAME داخل دایرکتوری داده. پنل این قابلیت را فقط به مدیر اصلی در یک اتصال لوپ‌بک مستقیم ارائه می‌دهد (127.0.0.1، بدون هیچ هدر پروکسی یا تونل)؛ پنلی که از طریق شبکه به آن دسترسی پیدا می‌شود، به جای آن دستورات را نمایش می‌دهد. نسخه به طور پیش‌فرض بر روی تگ انتشار پنل در حال اجرا تنظیم می‌شود که از طریق API گیت‌هاب حل شده است. مکان، نوع سرور و قیمت از API هتزنر دریافت می‌شوند: cpx22 جایی که ارائه می‌شود، در غیر این صورت ارزان‌ترین نوع x86 با حداقل ۲ گیگابایت حافظه.

تونل سریع بدون دامنه#

--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 پست‌ها را به مدت ۱۲ ساعت نگه می‌دارد. deploy و Find the current address فقط پست‌های امضا شده را می‌پذیرد، بنابراین یک پست جعل‌شده نمی‌تواند شما و توکن پنل‌تان را به آدرس شخص دیگری ارسال کند. این موضوع در رکورد و cloud-init منتشر شده وجود دارد: هر کسی که آن‌ها را داشته باشد می‌تواند آدرس فعلی را بخواند، که همچنان برای توکن پنل درخواست می‌کند. سرور به هر حال هیچ پورت ورودی‌ای را باز نگه نمی‌دارد.

یک راستی‌آزما کلید آدرس ندارد و هر کسی که موضوع را بخواند می‌تواند در آن پست بگذارد. بنابراین گردآورنده همچنین خودِ آدرس را، امضا شده با کلید Ed25519 خود، پست می‌کند و verify جدیدترین پستی را که با کلید گردآورنده در رکورد استقرار امضا شده است، برمی‌دارد؛ پست‌ها بر اساس زمانی که ntfy.sh آن‌ها را دریافت کرده است مرتب می‌شوند، نه زمانی که ادعا می‌کنند. یک گردآورنده از قبل از این تغییر، هیچ چیزی را امضا نمی‌کند، و سپس verify جدیدترین پست را انتخاب کرده و در بررسی statement این موضوع را اعلام می‌کند؛ یک پست جعل‌شده تنها می‌تواند باعث شکست آن بررسی شود، زیرا آدرس همچنان باید با کلید گردآورنده پاسخ دهد.

هزینه‌اش چیست: هیچ حساب Cloudflare رکورد تونل سریع را نگه نمی‌دارد، بنابراین verify تونل، کانکتور و بررسی DNS را به عنوان در دسترس نبودن گزارش می‌کند و نتیجه در بهترین حالت incomplete (روی Phala در عوض، بررسی Cloud با موفقیت انجام می‌شود: کانکتور در داخل پیکربندی اندازه‌گیری‌شده Docker Compose اجرا می‌شود؛ سوابق ارائه‌دهنده، فایروال، بیانیه امضا‌شده، اندازه‌گیری‌های میزبان و مقایسه نصب‌کننده طبق معمول بررسی می‌شوند. مقایسه بایت با نصب‌کننده مرجع به یک commit مستقر نیاز دارد که از قبل --quick-tunnel را بشناسد؛ یک checkout نسخه 0.7.0، نصب‌کننده دامنه را می‌سازد و تفاوت را گزارش می‌کند. کلودفلر به تونل‌های سریع هیچ تضمینی برای زمان بهره‌برداری (uptime) نمی‌دهد، اجازه می‌دهد ۲۰۰ درخواست در حال انجام (in-flight) داشته باشد و رویدادهای ارسال‌شده توسط سرور (Server-Sent Events) را منتقل نمی‌کند، بنابراین ممکن است به‌روزرسانی‌های زنده پنل (نسخه‌های بعد از 0.7.0) از طریق آن نرسند و نیاز به بارگذاری مجدد نما (view) باشد؛ این بخش آزمایش نشده است. برای موردی که باید پایدار بماند، از دامنه خود استفاده کنید.

راه‌اندازی#

ابتدا به همه چیزهایی که ارسال خواهند شد نگاه کنید. 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 (ولتر)، t3.small (AWS). --location و --image پیش‌فرض برای هر ارائه‌دهنده، اوبونتو ۲۴.۰۴ در یک منطقه اروپایی.

--repository تغییرات را از یک مخزن Git دیگر با HTTPS دریافت می‌کند، بدون اعتبارنامه‌ها در URL (پیش‌فرض https://github.com/phishdestroy/TgWitness.git). deploy همچنین می‌پذیرد --out برای یک دایرکتوری استقرار دیگر (پیش‌فرض deployments/NAME؛ دایرکتوری که در حال حاضر یک استقرار در آن وجود دارد، رد می‌شود) و --wait، زمان انتظار برای بیانیه امضا شده جمع‌آوری‌کننده: ۱ تا ۲۴۰، پیش‌فرض ۲۰، یا ۶۰ برای generic.

دستور:

1. یک تونل Cloudflare ایجاد می‌کند که ورودی آن نام میزبان پنل را به پنل و، در صورت ارائه، نام میزبان شاهد را به /api/witness/head و /api/assurance تنها؛
2. برای آن نام‌های میزبان، رکوردهای CNAME پروکسی‌شده ایجاد می‌کند و از ثبت نام‌هایی که از قبل وجود دارند، خودداری می‌کند؛
3. یک فایروال ارائه‌دهنده بدون قواعد ورودی و یک سرور پشت آن بدون کلید SSH، بدون پشتیبان، بدون عامل کنسول، و cloud-init که SSH را مخفی می‌کند، روت را قفل می‌کند، نصب می‌کند cloudflared، دقیقاً همان commit را دریافت می‌کند، آن را بررسی می‌کند و TgWitness را به عنوان یک سرویس systemd سخت‌شده راه‌اندازی می‌کند؛
4. منتظر بیانیهٔ امضا‌شدهٔ کلکسیونر می‌ماند و بررسی می‌کند که آیا این بیانیه، این سرور و هَش این cloud-init را نام می‌برد.

deployments/case-2026-11/ سپس شامل است:

رمز عبور ریشهٔ ارائه‌دهنده، توکن تونل و توکن پنل هرگز در deployment.json. اثر انگشت کلکتیوری را که در انتها ثبت شده است، تنها از طریق کانالی که کنترل آن در دست شما نیست، مانند یک کانال شاهدی یا یک پیام به گیرنده، منتشر کنید.

در تلگرام وارد شوید در https://case.example.org با توکن پنل، همان‌طور که در راهنمای حساب کاربری آمده است. اقدامات پنل در دفترچه یادداشت امضا شده ثبت می‌شوند؛ آن‌ها جلسات SSH نیستند. یک شاهد می‌تواند درخواست وضعیت بدهد https://case-witness.example.org.

SSH وجود ندارد: اگر بوت‌استرپ شکست بخورد، کالکتور هرگز پاسخ نمی‌دهد. سرور را حذف کرده و دوباره مستقر کنید، یا از استقرار عیب‌یابی (debug deployment) برای یافتن علت استفاده کنید.

رازها در داده‌های کاربر#

cloud-init دو رمز را در خود حمل می‌کند: توکن پنل و توکن تونل کلودفلر. کلید امضا در میان آن‌ها نیست؛ این کلید روی سرور ایجاد می‌شود. 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 از قبل با ارائه‌دهنده ثبت شده است: نام یا شناسه یک کلید SSH در پروژه Hetzner، شناسه یا اثر انگشت یک کلید SSH در تیم DigitalOcean، نام کاربری Linode که کلیدهای SSH پروفایل آن به ریشه اضافه شده‌اند، شناسه یک کلید 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 منقضی می‌شوند.

هر سرور (خودگواهی‌شده)#

--provider generic برای سروری است که خریداری شده یا به‌صورت دستی نصب شده باشد. deploy تونل و DNS را ایجاد می‌کند، می‌نویسد install.sh (خصوصی) و install.redacted.sh (برای انتشار)، و منتظر می‌ماند. کپی install.sh آن را در یک سرور تازه نصب‌شده اوبونتو ۲۴.۰۴ کپی کرده و در آنجا اجرا کنید:

sudo bash install.sh

این ابزار میزبان را همان‌گونه که بود ثبت می‌کند (ورودی‌ها، حساب‌ها، authorized_keys، سوکت‌های شنود، خدمات، کارهای زمان‌بندی‌شده، بسته‌ها)، commit را نصب می‌کند، فایروال میزبان را فعال می‌کند، خود را حذف می‌کند، SSH را مخفی می‌سازد و جلسه را پایان می‌دهد. گزارش چنین سروری در بهترین حالت خودگواهی‌شده (SELF-ATTESTED) است: هر کسی که نصب‌کننده را اجرا کرده قبلاً دسترسی روت داشته و هیچ رکورد ارائه‌دهنده‌ای برای راستی‌آزمایی‌کننده در دسترس نیست. این هنوز بهتر از یک سرور بدون توضیح است: موجودی، هش نصب‌کننده و هر ورود بعدی امضا شده‌اند.

تأیید#

تأییدکننده نیاز دارد deployment.json، نصب‌کننده منتشر شده، اعتبارنامه‌های فقط-خواندنی و، به‌طور ایده‌آل، یک خروجی از commit و یک مدرک 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 در آن لحظه توسط اعتبارسنج درخواست می‌شود؛ رکورد فقط شناسه‌هایی را که باید پرسیده شوند، فراهم می‌کند. کد خروج برای PASS برابر 0، برای FAIL برابر 1 و برای REVIEW، INCOMPLETE یا SELF-ATTESTED برابر 2 است. --fingerprint باید از یک کانال مستقل بیاید؛ بدون آن، کلید فقط با رکورد اپراتور مقایسه می‌شود. python verify.py هنوز خودِ ZIP، همانند بخش Evidence، شواهد را تأیید می‌کند.

اقدامات ارائه‌دهنده طبقه‌بندی می‌شوند: ایجاد و شروع در ۳۰ دقیقه پس از ایجاد، عبور؛ کنسول، بازیابی، بازنشانی رمز عبور، بازسازی، ISO، تصاویر، اسنپ‌شات‌ها، پشتیبان‌ها، مدیر سیستم، اتصال نمونه EC2 و باز کردن فایروال ناموفق هستند؛ اقدامات مربوط به برق و هر چیزی که غیرمنتظره است برای بازبینی علامت‌گذاری می‌شوند. یک اقدام ناشناخته هرگز بی‌سروصدا رد نمی‌شود.

گزارش تحویل مدرک#

--report report.md گزارش مارک‌داون را می‌نویسد و report.json در کنار آن:

1. نتیجه، اثر انگشت کلید گردآورنده، استقرار، ارائه‌دهنده، کامیت، سرور، فایروال، تونل؛
2. هر بررسی به همراه وضعیت و منبع آن (API ارائه‌دهنده، API کلودفلر، بیانیه گردآورنده، مجله شواهد)؛
3. لاگ ارائه‌دهنده با ارزیابی هر اقدام و، در مواردی که ارائه‌دهنده آن را ثبت می‌کند، عامل؛
4. نقطه‌های پایانی کلودفلر که اتصالات، پیکربندی و گزارش‌های حسابرسی تونل را در خود نگه می‌دارند؛
5. بیانیهٔ امضا‌شدهٔ گردآورنده؛
6. آنچه گزارش اثبات می‌کند و آنچه اثبات نمی‌کند؛
7. دستورالعمل‌هایی برای بازتولید آن و SHA-256 هر فایلی که به آن داده شده است.

گزارش را تحویل دهید، report.json, deployment.json، نصاب منتشرشده و مدرک ZIP را تحویل دهید. گزارش را زود تهیه کنید: لاگ‌های ارائه‌دهنده برای دوره‌های محدودی نگهداری می‌شوند.

کلودفلر به‌عنوان شاهد بیرونی#

همه چیز در اینجا اختیاری است. بدون حساب Cloudflare، سرور همچنان اجرا می‌شود و دو مورد از این موارد امروز کار می‌کنند:

Logpush که نسخهٔ اختصاصی Cloudflare را در R2 نگه می‌دارد، یک ویژگی سازمانی است: در طرح رایگان، Cloudflare پاسخ می‌دهد logpush is not enabled for this account. لاگ گیت‌وی آن در آنجا ۲۴ ساعت دوام می‌آورد، بنابراین حالت شواهد آن را در دفترچه یادداشت امضا شده کپی می‌کند (لاگ گیت‌وی کلودفلر از پرس‌وجوهای DNS این سرور، یک توکن فقط-خواندنی با دسترسی به تحلیل حساب).

بدون یک طرح اعتماد صفر، یک حساب یک مکان DNS دارد. هنگامی که Cloudflare مکان دیگری را رد می‌کند، سرور مکان موجود را به اشتراک می‌گذارد و پرس‌وجوهای آن بر اساس آدرسشان از هم متمایز می‌شوند؛ آن فیلتر نیاز به دسترسی خواندن PII اعتماد صفر نیز دارد، و destroy یک مکان مشترک را ترک می‌کند. یک پرس‌وجوی لاگ حداکثر سه ساعت را در بر می‌گیرد، بنابراین کپی و verify خواندن روز در بازه‌های ساعتی سه ساعته انجام می‌شود.

DNS گیت‌وی، حل‌کننده سیستم را پوشش می‌دهد. DNS بر روی HTTPS در پورت ۴۴۳ به یک حل‌کننده دیگر، و اتصالات به آدرسی که در هیچ‌جا یافت نمی‌شود (برای مثال، مراکز داده تلگرام)، در لاگ آن ثبت نمی‌شوند.

کلودفلر نمی‌تواند محتوای داخل رمزگذاری تلگرام، سایر دستگاه‌های متصل به حساب تلگرام (فهرست دستگاه‌های حالت مدرک، آن‌ها را از سمت تلگرام ثبت می‌کند) یا هایپروایزر ارائه‌دهنده را مشاهده کند.

خواندن نتیجه استقرار#

برای یک ماشین مجازی معمولی، ارائه‌دهنده زیرساخت میزبان را کنترل می‌کند و موجودی محلی در کنار سوابق ارائه‌دهنده بررسی می‌شود. برای Intel TDX، راستی‌آزما علاوه بر این، استناد سخت‌افزاری، پیوند گردآورنده، ترکیب و اندازه‌گیری‌های سیستم‌عامل را بررسی می‌کند. نتایج فردی را بخوانید تا ببینید کدام بررسی‌ها با موفقیت انجام شده‌اند یا در دسترس نبوده‌اند.

جزئیات فایروال تاریخی به ارائه‌دهنده بستگی دارد؛ لینود نسخه‌های قوانین را حفظ می‌کند. سوابق اعتبارسنجی، استقرارهای آزمایش‌شده و بررسی‌های زنده باقیمانده را فهرست می‌کند، و دامنه تأیید، این بررسی‌های محیطی را به دریافت و یکپارچگی آرشیو متصل می‌سازد.