Phala / Intel TDX · การปรับใช้ที่มีความมั่นใจสูง

TgWitness / เอกสารประกอบ · การติดตั้งและกู้คืน

การปรับใช้แบบความมั่นใจสูง (High-assurance deployment) เพิ่มการตรวจสอบอิสระต่อสภาพแวดล้อมการเก็บข้อมูลเข้าไปใน การตรวจสอบการเก็บถาวร ผู้ตรวจสอบจะสอบถามบันทึกการปรับใช้และการเข้าถึงที่เก็บไว้โดย ผู้ให้บริการคลาวด์และ Cloudflare และการปรับใช้ Intel TDX จะเพิ่มการรับรองด้วยฮาร์ดแวร์ สำหรับสภาพแวดล้อมของผู้เก็บข้อมูล

การใช้งานในเครื่องท้องถิ่นและ Docker ปกติยังคงไม่เปลี่ยนแปลง ไม่มีอะไรที่นี่จะทำงานได้จนกว่าคุณจะ deploy ด้วย python -m tgwitness.cloud, และตัวเก็บข้อมูลจะอ่านข้อมูลจากโฮสต์เฉพาะเมื่อการปรับใช้ตั้งค่า TGWITNESS_ASSURANCE.

แผนภาพในรูปแบบข้อความ

1. Operator → เซิร์ฟเวอร์, ไฟร์วอลล์ที่ไม่มีกฎการรับข้อมูลเข้า (API ของผู้ให้บริการ)
2. Operator → Tunnel และ DNS (Cloudflare API)
3. เซิร์ฟเวอร์, ไฟร์วอลล์ที่ไม่มีกฎการรับข้อมูลเข้า → Tunnel และ DNS (ส่งออกไปเท่านั้น)
4. เซิร์ฟเวอร์, ไฟร์วอลล์ที่ไม่มีกฎการรับข้อมูลเข้า → กุญแจการลงนามที่สร้างขึ้นบนเซิร์ฟเวอร์
5. Verifier, โทเค็นแบบอ่านอย่างเดียว → บันทึกของผู้ให้บริการและไฟร์วอลล์
6. Verifier, โทเค็นแบบอ่านอย่างเดียว → ที่อยู่ Tunnel Connector และทางเข้า
7. Verifier, โทเค็นแบบอ่านอย่างเดียว → คำแถลง /api/assurance ที่ได้รับการลงนาม
8. Verifier, โทเค็นแบบอ่านอย่างเดียว → ไฟล์ ZIP ของหลักฐาน

บนหน้านี้

• สิ่งที่ผู้ตรวจสอบสามารถตรวจสอบได้
• ผู้ให้บริการ
• VM ลับบน Phala Cloud (Intel TDX)
• ก่อนที่จะเริ่ม
• จากแผงควบคุม
• สร้างอุโมงค์อย่างรวดเร็วโดยไม่ต้องใช้โดเมน
• ปรับใช้
• การแก้ไขข้อผิดพลาดในการปรับใช้และล็อก
• ลบการติดตั้ง
• เซิร์ฟเวอร์ใดก็ได้ (ที่ผ่านการรับรองด้วยตนเอง)
• ตรวจสอบ
• รายงานการส่งมอบหลักฐาน
• Cloudflare ในฐานะผู้สังเกตการณ์จากภายนอก
• การอ่านผลการปรับใช้

สิ่งที่ผู้ตรวจสอบสามารถตรวจสอบได้#

ตัวเก็บข้อมูลบันทึกสถานะ SSH, เซสชัน, ประวัติการเข้าสู่ระบบ และข้อมูลการบูตในบันทึก process-start และ host.state ที่ได้รับการลงนาม บน VM ทั่วไป บันทึกเหล่านี้เป็นบันทึกข้อมูลในเครื่อง ซึ่งผู้ตรวจสอบจะเปรียบเทียบกับบันทึกอิสระของผู้ให้บริการ การ ปรับใช้ Intel TDX ด้านล่างนี้ยังตรวจสอบการวัดผลที่ได้รับการสนับสนุนจากฮาร์ดแวร์เพิ่มเติมด้วย

ผู้ให้บริการ#

ใช้โครงการ ทีม บัญชี หรือบัญชีลูกที่เฉพาะสำหรับแต่ละกรณี: สิทธิ์การเข้าถึงแบบอ่านอย่างเดียวของผู้ตรวจสอบ จะแสดงเฉพาะการปรับใช้ครั้งนี้เท่านั้น ข้อมูลรับรองจะถูกอ่านจาก --provider-token-file หรือตัวแปรข้างต้นเท่านั้น ไม่เคยจากบรรทัดคำสั่ง สำหรับ AWS ไฟล์ เก็บ ACCESS_KEY_ID SECRET_ACCESS_KEY [SESSION_TOKEN]; ภูมิภาคคือ --location.

ข้อมูลที่บันทึกของผู้ให้บริการแต่ละรายไม่สามารถแสดงได้ จะถูกพิมพ์ไว้ในทุกรายงาน สรุปสั้นๆ: Hetzner บันทึกคำขอคอนโซล; ส่วน Recovery Console ของ DigitalOcean, Lish/Glish ของ Linode และ web console ของ Vultr ไม่ถูกบันทึกในลักษณะดังกล่าว ดังนั้นสิทธิ์ root จะถูกล็อกตั้งแต่การบูตครั้งแรก และการเข้าสู่ระบบคอนโซล จำเป็นต้องรีเซ็ตรหัสผ่านหรือเปลี่ยนวิธีการบูต ซึ่งทั้งสองกรณีนี้ถูกบันทึกไว้ Vultr ส่งคืนที่อยู่คอนโซล ให้กับคีย์ใดก็ตามที่สามารถอ่านอินสแตนซ์ได้; ทั้งบันทึกและรายงานไม่เก็บข้อมูลนี้ไว้

เครื่องเสมือนลับ (Confidential VM) บน Phala Cloud (Intel TDX)#

โดย --provider phala ตัวเก็บข้อมูลทำงานในเครื่องเสมือนลับ Intel TDX บน Phala Cloud ซึ่งได้รับการจัดการโดย dstack ผู้โฮสต์และทีมงานของ Phala ไม่สามารถอ่าน หน่วยความจำของมันได้ และตัวประมวลผลจะลงนามในใบรับรองเกี่ยวกับสิ่งที่เครื่องได้บูตขึ้น ตัวตรวจสอบไม่ เชื่อคำกล่าวของ Phala โดยตรง: tgwitness.tdx ตรวจสอบใบรับรองทุกใบด้วยตนเอง ไปจนถึง Intel SGX Root CA ที่ถูกตรึงไว้ โดยเปรียบเทียบกับรายชื่อการเพิกถอนของ 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 หลังจากการปรับใช้ล้มเหลว จะทำให้รายงานไม่ผ่าน และการเริ่มต้นใหม่จะถูกแสดงรายการเพื่อตรวจสอบ

ในแผงควบคุม ให้เลือก Confidential virtual machine · Phala Cloud ภายใต้ Extras → Server 24/7 และวาง Phala Cloud API key ลงไป; การสร้างอุโมงค์แบบรวดเร็วทำงานได้เหมือนบน 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 Gateway DNS ไม่สามารถใช้งานได้ที่นี่: Phala ไม่มีไฟร์วอลล์ของผู้ให้บริการ สำหรับทราฟฟิกขาออก

ใบรับรองการยืนยัน#

สำหรับการปรับใช้ Phala verify --report certificate.md ยังเขียนใบรับรองด้วย: ใบรับรอง certificate.html แบบอิสระ และ certificate.pdf แบบ A4 พร้อมผลการตรวจสอบ, ห่วงโซ่ความเชื่อถือ จากรากของ Intel ไปยังกุญแจผู้รวบรวม, การเปรียบเทียบกับเซิร์ฟเวอร์ทั่วไปและเซิร์ฟเวอร์ที่มีความมั่นใจสูง, ผลการวัดค่าข้างเคียงกับค่าที่คำนวณจากภาพที่เผยแพร่, ผู้รับรองสำหรับแต่ละ ส่วน, ห่วงโซ่ใบรับรองของ Intel, การตรวจสอบทุกขั้นตอน, บันทึกของผู้ให้บริการ, และวิธีทำซ้ำ การตรวจสอบ. รายงาน JSON ยังคงเป็นบันทึกที่มีอำนาจสูงสุด; หน้าเว็บแสดงผลจากรายงานดังกล่าว

รายงานนี้ได้รับการปิดผนึกด้วยลายเซ็นและตราประทับเวลาแบบดิจิทัล ในไฟล์ certificate.seal.json และไฟล์ .tsq/.tsr ที่อยู่ข้างๆ:

--timestamp URL (สามารถทำซ้ำได้) เลือกหน่วยงานอื่น ๆ, --timestamp none ไม่เลือกหน่วยงานใด, --sign-with none ไม่ลงลายเซ็นบนตราประทับ check-report ตรวจสอบค่าแฮชของรายงาน, ลายเซ็นของผู้ตรวจสอบ, แต่ละเวลาประทับกับรากที่เชื่อถือได้และสถานะที่ได้รับการรับรองของมัน, รวมถึงลายเซ็นของ PDF น้ำหนักทางกฎหมาย ของตราประทับเวลาที่ได้รับการรับรองนอกสหภาพยุโรป และของรายงานโดยรวม ขึ้นอยู่กับศาล หรือหน่วยงานที่รับรายงานนั้น; ตราประทับแสดงว่าเมื่อใดรายงานนั้นมีอยู่ และว่ารายงานนั้นยังไม่ถูกเปลี่ยนแปลง

การรับรองนี้ไม่สามารถตัดความเป็นไปได้ของข้อบกพร่องในโมดูล TDX หรือไมโครโค้ดของ Intel หรือการเข้าถึงทางกายภาพ ไปยังบัสหน่วยความจำได้ ผู้ใดก็ตามที่ควบคุมแอปพลิเคชันในบัญชีของ Phala สามารถปรับใช้ compose อีกตัวได้; มันจะปรากฏเป็นเวอร์ชันใหม่ที่มีค่าแฮชของ compose ใหม่ ผู้โฮสต์ควบคุมแหล่งที่มาของเวลา และเครือข่ายของเครื่อง

การปรับใช้ การตรวจสอบด้วย --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 หากไม่มีโดเมน การสร้าง Tunnel แบบรวดเร็วไม่จำเป็นต้องใช้สิ่งใดในนี้
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. การ commit ที่จะรัน แท็กการปล่อยเวอร์ชันจะถูกแปลงเป็น commit ที่เกี่ยวข้องเพียงครั้งเดียวด้วย git ls-remote; เซิร์ฟเวอร์จะรับเฉพาะ commit ที่มีความยาว 40 ตัวอักษรเท่านั้น

จากแผงควบคุม#

บนคอมพิวเตอร์ของคุณเอง, Extras → Server 24/7 จะทำงานในลักษณะเดียวกัน deploy สำหรับ Hetzner ในสาม ขั้นตอน: เลือกยุโรปหรือสหรัฐอเมริกา, วางโทเค็น Hetzner (อ่าน & เขียน), แล้วตรวจสอบ ประเภทเซิร์ฟเวอร์, ราคาต่อเดือน, ที่อยู่ และเวอร์ชันที่แผงควบคุมพบด้วยโทเค็นนั้น ไม่มี อะไรถูกสร้างขึ้นก่อนที่คุณจะยืนยัน แผงควบคุมจะแสดงแต่ละขั้นตอนพร้อม deploy ตามที่รายงาน จากนั้น แสดงที่อยู่ โทเค็นของแผงควบคุม และลายนิ้วมือของกุญแจลงนาม หากไม่มีโดเมน เซิร์ฟเวอร์จะได้รับ อุโมงค์ชั่วคราว ; การเลือก Your servers → Find the current address จะค้นหาที่อยู่ใหม่อีกครั้งหลังการรีสตาร์ท สำหรับที่อยู่คงที่ภายใต้โดเมนของคุณเอง ให้เปิด Optional · your own domain และเพิ่มโทเค็น Cloudflare (ลิงก์ที่เตรียมไว้จะเลือก Zone Read, DNS Edit และ Cloudflare Tunnel Edit)

โทเค็นจะเดินทางไปพร้อมกับแต่ละคำขอจากแท็บเบราว์เซอร์ไปยัง TgWitness บนคอมพิวเตอร์เดียวกัน และไม่ถูกบันทึกไว้ที่ใดทั้งสิ้น; บันทึกการติดตั้ง, cloud-init ที่ถูกลบข้อมูลส่วนตัว, โทเค็นแผงควบคุม และ สำหรับอุโมงค์ชั่วคราว, กุญแจที่อยู่ จะถูกเก็บไว้ใน deployments/NAME ภายในไดเรกทอรีข้อมูล แผงควบคุมจะให้บริการนี้เฉพาะผู้ดูแลระบบหลักผ่านการเชื่อมต่อ loopback โดยตรง (127.0.0.1, ไม่มีส่วนหัวพร็อกซีหรือทูนเนล); ส่วนควบคุมที่เข้าถึงผ่านเครือข่ายจะแสดงคำสั่ง แทน ส่วนเวอร์ชันจะตั้งค่าเริ่มต้นเป็นแท็กการปล่อยของส่วนควบคุมที่กำลังทำงาน ซึ่งถูกแก้ไขผ่าน API ของ GitHub ส่วนตำแหน่ง ประเภทเซิร์ฟเวอร์ และราคา มาจาก API ของ Hetzner: cpx22 หากมี ให้บริการ มิฉะนั้นจะใช้ประเภท x86 ที่ถูกที่สุดที่มีหน่วยความจำอย่างน้อย 2 GB

สร้างอุโมงค์อย่างรวดเร็วโดยไม่ต้องใช้โดเมน#

--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 ที่ถูกวัด); บันทึกของผู้ให้บริการ, ไฟร์วอลล์, คำแถลงที่ลงนาม, การวัดโฮสต์ และการเปรียบเทียบตัวติดตั้ง ถูกตรวจสอบตามปกติ การเปรียบเทียบไบต์กับตัวติดตั้งอ้างอิงต้องการ commit ที่ถูกปรับใช้ ซึ่งรู้จัก --quick-tunnel อยู่แล้ว; การเช็คเอาต์เวอร์ชัน 0.7.0 จะสร้างตัวติดตั้งโดเมนและรายงาน ความแตกต่าง Cloudflare ไม่รับประกันเวลาทำงานของ Quick Tunnels, อนุญาตให้มีการร้องขอ 200 ครั้ง ที่กำลังดำเนินการอยู่ และไม่ส่ง Server-Sent Events ดังนั้นการอัปเดตแบบเรียลไทม์ของแผงควบคุม (เวอร์ชันหลัง 0.7.0) อาจไม่ส่งผ่าน Quick Tunnels และจำเป็นต้องรีโหลดหน้า; ส่วนนี้ยังไม่ได้ทดสอบ สำหรับกรณี ที่จำเป็นต้องใช้งานต่อเนื่อง ให้ใช้โดเมนของคุณเอง

ปรับใช้#

ดูทุกสิ่งที่จะถูกส่งไปก่อน 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 รับ commit จาก repositori Git https อื่น โดยไม่ใช้ข้อมูลรับรองใน URL (ค่าเริ่มต้น https://github.com/phishdestroy/TgWitness.git). deploy ยังรับได้ --out สำหรับไดเรกทอรีการปรับใช้อื่น (ค่าเริ่มต้น deployments/NAME; จะปฏิเสธไดเรกทอรีที่มี การปรับใช้อยู่แล้ว) และ --wait, จำนวนนาทีที่ต้องรอเพื่อรับคำแถลงที่ลงนามจากผู้รวบรวม: 1 ถึง 240, ค่าเริ่มต้น 20, หรือ 60 สำหรับ generic.

คำสั่ง:

1. สร้าง Cloudflare tunnel ที่การเข้า (ingress) จะส่งชื่อโฮสต์ของ panel ไปยัง panel และ หากมีชื่อโฮสต์ของ witness จะส่งไปยัง /api/witness/head และ /api/assurance เท่านั้น;
2. สร้างบันทึก CNAME ผ่านพร็อกซีสำหรับชื่อโฮสต์เหล่านั้น โดยปฏิเสธชื่อที่มีอยู่แล้ว;
3. สร้างไฟร์วอลล์ผู้ให้บริการโดยไม่มีกฎการรับเข้า และเซิร์ฟเวอร์ที่อยู่เบื้องหลังโดยไม่มีกุญแจ SSH, ไม่มีการสำรองข้อมูล, ไม่มีตัวแทนคอนโซล, และ cloud-init ที่ซ่อน SSH, ล็อกสิทธิ์ root, ติดตั้ง cloudflared, ดึง commit ที่ต้องการมาอย่างแม่นยำ ตรวจสอบ และเริ่มTgWitness เป็น บริการ systemd ที่ได้รับการเสริมความปลอดภัย;
4. รอรับคำแถลงที่ลงนามจากผู้เก็บข้อมูล และตรวจสอบว่าคำแถลงนั้นระบุชื่อเซิร์ฟเวอร์นี้และ ค่าแฮชของ cloud-init นี้

deployments/case-2026-11/ จากนั้นจะประกอบด้วย:

รหัสผ่านรูทของผู้ให้บริการ โทเค็นอุโมงค์ และโทเค็นแผงควบคุม จะไม่ถูกบันทึกไว้ deployment.json. โปรดเผยแพร่ลายนิ้วมือของตัวเก็บข้อมูล (collector fingerprint) ที่พิมพ์ไว้ที่ส่วนท้าย ผ่านช่อง ที่คุณไม่ได้ควบคุมเพียงคนเดียว เช่น ช่องผู้เป็นพยาน (witness channel) หรือข้อความที่ส่งถึงผู้รับ

ลงชื่อเข้าใช้ Telegram ที่ https://case.example.org ด้วยโทเค็นของแผงควบคุม ตามที่ระบุใน คู่มือบัญชี การดำเนินการบนแผงควบคุมจะถูกบันทึกไว้ในบันทึกที่ลงนามแล้ว; การดำเนินการเหล่านี้ไม่ใช่ เซสชัน SSH ผู้เป็นพยานสามารถตรวจสอบ https://case-witness.example.org.

ไม่มี SSH: หากขั้นตอน bootstrap ล้มเหลว ตัวเก็บข้อมูลจะไม่ตอบสนองเลย ให้ลบเซิร์ฟเวอร์และ ติดตั้งใหม่ หรือใช้การติดตั้งแบบดีบักเพื่อหาสาเหตุ

ข้อมูลลับในข้อมูลผู้ใช้#

cloud-init เก็บข้อมูลลับสองอย่าง: โทเค็นของ panel และโทเค็นของ Cloudflare tunnel. กุญแจการลงนามไม่ได้อยู่ในนั้น; มันถูกสร้างขึ้นบนเซิร์ฟเวอร์ 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 records ที่ชี้ไปยัง ทูนเนล และทูนเนลเอง บันทึกของเซิร์ฟเวอร์และกุญแจการลงนามถูกลบไปด้วย: ส่งออก หลักฐานก่อน บันทึกจะยังคงอยู่ โดยถูกทำเครื่องหมาย 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, ซ็อกเก็ตรับฟัง, บริการ, งานที่กำหนดเวลา, แพ็กเกจ), ติดตั้งการ commit, เปิดใช้งานไฟร์วอลล์ของโฮสต์, ลบ ตัวเอง, ปิดบัง SSH และสิ้นสุดเซสชัน รายงานสำหรับเซิร์ฟเวอร์ประเภทนี้ดีที่สุดคือ SELF-ATTESTED: ผู้ที่รันตัวติดตั้งต้องมีสิทธิ์ root ก่อนหน้านั้น และไม่มีบันทึกจากผู้ให้บริการ ให้ผู้ตรวจสอบใช้ แต่ยังคงดีกว่าเซิร์ฟเวอร์ที่ไม่มีคำอธิบาย: รายการสินทรัพย์, แฮชของตัวติดตั้ง และการเข้าสู่ระบบทุกครั้งหลังจากนั้นล้วนได้รับการลงนาม

ตรวจสอบ#

ผู้ตรวจสอบจำเป็นต้องมี 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 ทั้งหมดในขณะนั้น; บันทึก จะส่งเพียง ID ที่ต้องการตรวจสอบเท่านั้น รหัสออก (exit code) คือ 0 สำหรับ PASS, 1 สำหรับ FAIL และ 2 สำหรับ REVIEW, INCOMPLETE หรือ SELF-ATTESTED. --fingerprint ควรมาจากช่องสัญญาณอิสระ หากไม่มีข้อมูลนี้ กุญแจจะถูกเปรียบเทียบกับบันทึกของผู้ให้บริการเท่านั้น python verify.py ยังคงตรวจสอบหลักฐานZIPด้วยตัวเอง เช่นเดียวกับในส่วน Evidence

การดำเนินการของผู้ให้บริการถูกจัดประเภท: การสร้างและเริ่มต้นภายใน 30 นาทีหลังการสร้างจะผ่าน; คอนโซล, การกู้คืน, การรีเซ็ตรหัสผ่าน, การสร้างใหม่, ISO, ภาพ, สแนปช็อต, การสำรองข้อมูล, Systems Manager, EC2 Instance Connect และการเปิดพอร์ตไฟร์วอลล์จะล้มเหลว; การดำเนินการเกี่ยวกับพลังงานและสิ่งใดก็ตามที่ไม่คาดคิด จะถูกทำเครื่องหมายเพื่อตรวจสอบ การดำเนินการที่ไม่รู้จักจะไม่ผ่านโดยไม่มีข้อเตือนใดๆ

รายงานสำหรับการส่งมอบหลักฐาน#

--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. บันทึก Gateway ของมันจะเก็บไว้ 24 ชั่วโมงที่นั่น ดังนั้น โหมดหลักฐานจะคัดลอกมันเข้าไปในบันทึกที่ลงนาม (บันทึก Gateway ของ Cloudflare เกี่ยวกับ คำขอ DNS ของเซิร์ฟเวอร์นี้ ซึ่งเป็นโทเค็นอ่านอย่างเดียวที่มีสิทธิ์ Account Analytics Read)

หากไม่มีแผน Zero Trust บัญชีจะมีตำแหน่ง DNS เพียงหนึ่งแห่ง เมื่อ Cloudflare ปฏิเสธตำแหน่งอื่น เซิร์ฟเวอร์จะแชร์ตำแหน่งที่มีอยู่ และคำขอจะถูกแยกแยะตามที่อยู่ของมัน; ตัวกรองนั้น ยังต้องการสิทธิ์ Zero Trust PII Read ด้วย และ destroy ทำให้เหลือตำแหน่งที่แชร์ร่วมกัน การค้นหาบันทึกหนึ่งครั้งจะครอบคลุม สูงสุดสามชั่วโมง ดังนั้นการคัดลอกและ verify อ่านข้อมูลของวันนั้นในช่วงเวลาสามชั่วโมง

Gateway DNS ครอบคลุมตัวแก้ปัญหา DNS ของระบบ DNS ผ่าน HTTPS บนพอร์ต 443 ไปยังตัวแก้ปัญหา DNS อื่น และ การเชื่อมต่อไปยังที่อยู่ที่ไม่ถูกค้นหาที่ใด (เช่น ศูนย์ข้อมูลของ Telegram) จะไม่ปรากฏใน บันทึกของมัน

Cloudflare ไม่สามารถเข้าถึงข้อมูลภายในระบบการเข้ารหัสของ Telegram, อุปกรณ์อื่น ๆ ที่ใช้บัญชี Telegram เดียวกัน (รายชื่ออุปกรณ์ในโหมดหลักฐานบันทึกข้อมูลจากด้าน Telegram) หรือไฮเปอร์ไวเซอร์ของผู้ให้บริการ

การอ่านผลการปรับใช้#

สำหรับ VM ทั่วไป ผู้ให้บริการจะควบคุมโครงสร้างพื้นฐานของโฮสต์ และข้อมูลในระบบท้องถิ่น จะถูกตรวจสอบควบคู่กับบันทึกของผู้ให้บริการ สำหรับ Intel TDX ผู้ตรวจสอบจะตรวจสอบเพิ่มเติม ข้อมูลสเปกฮาร์ดแวร์ การผูกมัดของตัวเก็บข้อมูล การจัดองค์ประกอบ และการวัดผลระบบปฏิบัติการ อ่านผลลัพธ์แต่ละรายการ เพื่อดูว่าการตรวจสอบใดผ่านหรือไม่สามารถดำเนินการได้

รายละเอียดไฟร์วอลล์ในอดีตขึ้นอยู่กับผู้ให้บริการ; Linode เก็บเวอร์ชันของกฎไว้ บันทึกการตรวจสอบความถูกต้องแสดงรายการการปรับใช้ที่ผ่านการทดสอบและการตรวจสอบที่ยังคงใช้งานอยู่ ส่วนขอบเขตการตรวจสอบจะเชื่อมโยงการตรวจสอบสภาพแวดล้อมเหล่านี้ กับการเก็บรวบรวมข้อมูลจากคลังข้อมูลและการตรวจสอบความสมบูรณ์