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

Canonical page: https://phishdestroy.github.io/TgWitness/th/docs/reference/high-assurance/

เซิร์ฟเวอร์ที่ได้รับการรักษาความปลอดภัยอย่างแน่นหนาและทำงานตลอด 24/7 บน Hetzner หรือ Phala Cloud, Gateway DNS และขั้นตอนการตรวจสอบที่ฝ่ายที่สามสามารถทำซ้ำได้

[Project context and measured scale](https://phishdestroy.github.io/TgWitness/docs/reference/overview/)

[Documentation index](https://phishdestroy.github.io/TgWitness/th/llms.txt)

Translation coverage: this edition includes material from the English original.

เซิร์ฟเวอร์ที่ได้รับการรักษาความปลอดภัยอย่างแน่นหนาและทำงานตลอด 24/7 บน Hetzner หรือ Phala Cloud, Gateway DNS และขั้นตอนการตรวจสอบที่ฝ่ายที่สามสามารถทำซ้ำได้

[TgWitness](https://github.com/phishdestroy/TgWitness/blob/main/README.md) / [เอกสารประกอบ](https://github.com/phishdestroy/TgWitness/blob/main/docs/README.md) · [การติดตั้งและกู้คืน](https://phishdestroy.github.io/TgWitness/th/docs/reference/deployment/)

![การติดตั้งและกู้คืน](https://phishdestroy.github.io/TgWitness/assets/chapter-operate.svg)

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

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

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

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

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 ของหลักฐาน

**บนหน้านี้**

- [สิ่งที่ผู้ตรวจสอบสามารถตรวจสอบได้](https://phishdestroy.github.io/TgWitness/th/docs/reference/high-assurance/#what-a-verifier-can-check)
- [ผู้ให้บริการ](https://phishdestroy.github.io/TgWitness/th/docs/reference/high-assurance/#providers)
- [VM ลับบน Phala Cloud (Intel TDX)](https://phishdestroy.github.io/TgWitness/th/docs/reference/high-assurance/#confidential-vm-on-phala-cloud-intel-tdx)
- [ก่อนที่จะเริ่ม](https://phishdestroy.github.io/TgWitness/th/docs/reference/high-assurance/#before-you-start)
- [จากแผงควบคุม](https://phishdestroy.github.io/TgWitness/th/docs/reference/high-assurance/#from-the-panel)
- [สร้างอุโมงค์อย่างรวดเร็วโดยไม่ต้องใช้โดเมน](https://phishdestroy.github.io/TgWitness/th/docs/reference/high-assurance/#quick-tunnel-without-a-domain)
- [ปรับใช้](https://phishdestroy.github.io/TgWitness/th/docs/reference/high-assurance/#deploy)
- [การแก้ไขข้อผิดพลาดในการปรับใช้และล็อก](https://phishdestroy.github.io/TgWitness/th/docs/reference/high-assurance/#debug-deployment-and-lock)
- [ลบการติดตั้ง](https://phishdestroy.github.io/TgWitness/th/docs/reference/high-assurance/#remove-a-deployment)
- [เซิร์ฟเวอร์ใดก็ได้ (ที่ผ่านการรับรองด้วยตนเอง)](https://phishdestroy.github.io/TgWitness/th/docs/reference/high-assurance/#any-server-self-attested)
- [ตรวจสอบ](https://phishdestroy.github.io/TgWitness/th/docs/reference/high-assurance/#verify)
- [รายงานการส่งมอบหลักฐาน](https://phishdestroy.github.io/TgWitness/th/docs/reference/high-assurance/#report-for-evidence-handover)
- [Cloudflare ในฐานะผู้สังเกตการณ์จากภายนอก](https://phishdestroy.github.io/TgWitness/th/docs/reference/high-assurance/#cloudflare-as-an-outside-witness)
- [การอ่านผลการปรับใช้](https://phishdestroy.github.io/TgWitness/th/docs/reference/high-assurance/#reading-the-deployment-result)

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

| คำกล่าวอ้าง | วิธีตรวจสอบ | ดูแลโดย |
| --- | --- | --- |
| เซิร์ฟเวอร์นี้ถูกสร้างขึ้นผ่าน API ของผู้ให้บริการ ณ เวลาที่ทราบ | วัตถุเซิร์ฟเวอร์และการสร้างมันในบันทึกของผู้ให้บริการเอง | ผู้ให้บริการ |
| ไม่มีใครใช้เส้นทางเข้าถึงของผู้ให้บริการ | บันทึกคำขอคอนโซล, การกู้คืน, การรีเซ็ตรหัสผ่าน, การสร้างใหม่, ISO, ภาพ, และการสำรองข้อมูล | ผู้ให้บริการ |
| ไม่มีอะไรสามารถเชื่อมต่อกับมันได้ | ไฟร์วอลล์ของผู้ให้บริการไม่มีกฎการรับข้อมูลเข้า; SSH ถูกซ่อนตั้งแต่การบูตครั้งแรก | ผู้ให้บริการ (ไฟร์วอลล์), โฮสต์ (SSH) |
| สามารถเข้าถึงแผงควบคุมนี้ได้เฉพาะผ่านทางอุโมงค์เท่านั้น | ทางเข้า Tunnel ส่งข้อมูลไปยังแผงควบคุมเท่านั้น; คอนเน็กเตอร์ทำงานจากที่อยู่ของเซิร์ฟเวอร์ | Cloudflare |
| ซอฟต์แวร์นี้ทำงาน | ค่าแฮชของต้นไม้แหล่งที่มาที่ลงนามโดยผู้เก็บข้อมูลจะเท่ากับค่าเช็คเอาต์ของคอมมิตที่ได้รับการปรับใช้ | Collector, ตรวจสอบกับ Git |
| กุญแจการลงนามได้ถูกสร้างขึ้นบนเซิร์ฟเวอร์นั้น | กุญแจจะลงนามในข้อความที่ระบุ ID เซิร์ฟเวอร์ของผู้ให้บริการและค่าแฮชของ cloud-init ที่ได้รับ | Collector, ตรวจสอบกับผู้ให้บริการ |
| บันทึกนี้เกี่ยวข้องกับกุญแจและเซิร์ฟเวอร์ดังกล่าว | ทุกกระบวนการที่เริ่มต้นในหลักฐาน ZIP จะนำค่าการวัดของโฮสต์สำหรับเซิร์ฟเวอร์นั้นมาด้วย | หลักฐานZIP |

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

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

| `--provider` | ข้อมูลรับรอง | สิทธิ์การเข้าถึงแบบอ่านเท่านั้นของ Verifier | บันทึกของผู้ให้บริการสำหรับผู้ตรวจสอบ | เก็บไว้เพื่อ |
| --- | --- | --- | --- | --- |
| `hetzner` | `HCLOUD_TOKEN` | อ่านโทเค็นของโครงการเดียวกัน | การดำเนินการของเซิร์ฟเวอร์และไฟร์วอลล์ | ในขณะที่ทรัพยากรยังมีอยู่ |
| `digitalocean` | `DIGITALOCEAN_TOKEN` | โทเค็นการเข้าถึงส่วนตัวแบบอ่านอย่างเดียว | การดำเนินการของ Droplet | ในขณะที่ Droplet ยังอยู่ |
| `linode` | `LINODE_TOKEN` | `linodes`, `firewall`, `events` ขอบเขตการอ่านเท่านั้น | เหตุการณ์ของบัญชี, เวอร์ชันกฎไฟร์วอลล์ | 90 วัน |
| `vultr` | `VULTR_API_KEY` | ผู้ใช้ที่มีสิทธิ์อ่านและ `activity_logs` สิทธิ์ | บันทึกกิจกรรมบัญชี (วิธี, เส้นทาง, ผู้ดำเนินการ) | 30 วัน หรือนานกว่านั้นหากสมัครใช้บริการบันทึกการตรวจสอบ |
| `aws` | `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY` | `ec2:DescribeInstances`, `ec2:DescribeSecurityGroups`, `cloudtrail:LookupEvents` | ประวัติเหตุการณ์ CloudTrail | 90 วัน |
| `phala` | `PHALA_CLOUD_API_KEY` | กุญแจ API ของพื้นที่ทำงานเดียวกัน | การปรับปรุงแอปพลิเคชันและการดำเนินการ CVM: การเปลี่ยนแปลงการกำหนดค่าและสภาพแวดล้อมของ Docker Compose, การเริ่มต้นใหม่, การอัปเกรดระบบปฏิบัติการ | แม้ว่าแอปพลิเคชันนี้จะมีอยู่ |
| `generic` | ไม่มี | ไม่มี | ไม่มี: **รับรองด้วยตนเอง** | – |

ใช้โครงการ ทีม บัญชี หรือบัญชีลูกที่เฉพาะสำหรับแต่ละกรณี: สิทธิ์การเข้าถึงแบบอ่านอย่างเดียวของผู้ตรวจสอบ จะแสดงเฉพาะการปรับใช้ครั้งนี้เท่านั้น ข้อมูลรับรองจะถูกอ่านจาก `--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](https://phala.com/) ซึ่งได้รับการจัดการโดย dstack ผู้โฮสต์และทีมงานของ Phala ไม่สามารถอ่าน หน่วยความจำของมันได้ และตัวประมวลผลจะลงนามในใบรับรองเกี่ยวกับสิ่งที่เครื่องได้บูตขึ้น ตัวตรวจสอบไม่ เชื่อคำกล่าวของ Phala โดยตรง: `tgwitness.tdx` ตรวจสอบใบรับรองทุกใบด้วยตนเอง ไปจนถึง Intel SGX Root CA ที่ถูกตรึงไว้ โดยเปรียบเทียบกับรายชื่อการเพิกถอนของ Intel และข้อมูลแพลตฟอร์มที่ Intel ลงนาม และปฏิเสธ เครื่องที่สามารถถูกดีบักหรือย้ายได้

| รายงานรายการ | สิ่งที่แสดง |
| --- | --- |
| `tdx_binding` | การรับรองนี้รวมถึงคำแถลงที่ลงนามของผู้เก็บข้อมูลและค่าสุ่มของคำขอนี้ |
| `tdx_quote` | Intel รับรองการยืนยันนี้; การยืนยันจะผ่านได้เฉพาะเมื่อ Intel ประเมินว่าแพลตฟอร์มนั้นเป็นเวอร์ชันล่าสุด |
| `tdx_compose_hash` | RTMR3 ซึ่งถูกเล่นซ้ำจากบันทึกเหตุการณ์ dstack วัดผลการสร้างข้อความในแอปที่ผู้เก็บข้อมูลรายงาน |
| `tdx_compose` | โค้ดที่เขียนขึ้นนั้นตรงกันทุกไบต์กับโค้ดที่สร้างขึ้นจาก commit ที่ถูก deploy: ไฟล์ต้นฉบับถูกตรึงด้วย hash, ภาพทั้งสองถูกตรึงด้วย digest, ไม่มีโค้ดอื่นใด |
| `tdx_identity` | การรับรองความถูกต้องมาจากแอปพลิเคชันและอินสแตนซ์ที่ได้รับการปรับใช้ พร้อมด้วยกุญแจจาก KMS ของ Phala และดิสก์ที่เข้ารหัส |
| `tdx_os` | MRTD และ RTMR0-2 มีค่าเท่ากับค่าที่ตัวตรวจสอบคำนวณจากภาพระบบปฏิบัติการ dstack ที่ Dstack-TEE เผยแพร่ ซึ่งพบได้จากแฮชภาพระบบปฏิบัติการที่ CVM รายงาน และจากตาราง ACPI ที่ QEMU สร้างขึ้นสำหรับรูปแบบของ VM: เฟิร์มแวร์, เคอร์เนล, initrd, บรรทัดคำสั่งพร้อมแฮชระบบไฟล์รูท, หน่วยความจำ, vCPU และอุปกรณ์ ภาพระบบปฏิบัติการสำหรับการพัฒนาจะล้มเหลว |

The OS image (about 180 MB, of which 21 MB are kept) is downloaded once from [Dstack-TEE/meta-dstack](https://github.com/Dstack-TEE/meta-dstack/releases) 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` ที่อยู่ข้างๆ:

| Seal | สิ่งที่เพิ่มเข้ามา |
| --- | --- |
| ตราประทับเวลาอิเล็กทรอนิกส์ที่ได้รับการรับรอง, `http://tsa.belgium.be/connect` | เวลาประทับตาม RFC 3161 บนไบต์ที่แม่นยำของ `certificate.json` จากผู้ให้บริการบริการความเชื่อถือที่ได้รับการรับรองของรัฐบาลกลางเบลเยียม (FPS Policy and Support, BOSA) หน่วยงานนี้ถูกระบุเป็นบริการประทับเวลาที่ได้รับการรับรอง (qualified time-stamping service) ในสถานะที่ได้รับการอนุมัติ (status granted) บนรายชื่อที่เชื่อถือได้ของสหภาพยุโรป (EU trusted list) ของเบลเยียม; ราก (Belgium Root CA6) และรายการในรายชื่อดังกล่าว (ตามรายชื่อที่ออกเมื่อวันที่ 20 ตุลาคม 2026) ถูกตรึงไว้ใน `tgwitness/tsa_roots.py`. ตามข้อ 41 ของกฎระเบียบ (EU) No 910/2014 การประทับเวลาดังกล่าวถือว่ามีความถูกต้องทั้งในด้านวันที่และเวลา รวมถึงความสมบูรณ์ของข้อมูลในทุกประเทศสมาชิกสหภาพยุโรป |
| เวลาประทับตาม RFC 3161, FreeTSA | เวลาประทับครั้งที่สอง ซึ่งไม่เกี่ยวข้องกัน |
| ลายเซ็นของ Verifier | Ed25519 บนข้อความที่ระบุ SHA-256 ของรายงานและทุกเวลาประทับ พร้อมด้วยกุญแจของผู้ตรวจสอบเอง (`--sign-with FOLDER`, ค่าเริ่มต้น `~/.tgwitness/verifier`); PDF มีลายเซ็นจากกุญแจเดียวกัน |

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

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

การปรับใช้ การตรวจสอบด้วย `--evidence` การรีสตาร์ท การเปรียบเทียบภาพระบบปฏิบัติการ ใบรับรองที่ได้รับการปิดผนึกดิจิทัลด้วยลายเซ็นและตราประทับเวลา และ การทำลาย ได้ดำเนินการบน Phala Cloud เอง; ดู [การดำเนินการเมื่อวันที่ 4 พฤศจิกายน 2026](https://phishdestroy.github.io/TgWitness/th/docs/reference/verification/#live-phala-cloud-deployment--4-november-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 แบบรวดเร็ว](https://phishdestroy.github.io/TgWitness/th/docs/reference/high-assurance/#quick-tunnel-without-a-domain)ไม่จำเป็นต้องใช้สิ่งใดในนี้
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` ตามที่รายงาน จากนั้น แสดงที่อยู่ โทเค็นของแผงควบคุม และลายนิ้วมือของกุญแจลงนาม หากไม่มีโดเมน เซิร์ฟเวอร์จะได้รับ [อุโมงค์ชั่วคราว](https://phishdestroy.github.io/TgWitness/th/docs/reference/high-assurance/#quick-tunnel-without-a-domain) ; การเลือก **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://developers.cloudflare.com/tunnel/get-started/quick-tunnels/) ไปยังแผงควบคุม: ที่อยู่แบบสุ่ม `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` | ID, ค่าแฮช, การเรียก API (วิธี, เส้นทาง, สถานะ) และข้อความที่ลงนามครั้งแรก | ใช่, ด้วยตัวตรวจสอบ |
| `cloud-init.redacted.yaml` | คำสั่ง cloud-init ที่ถูกต้อง โดยแทนที่ข้อมูลลับสองรายการด้วย `REDACTED` | ใช่ |
| `panel-token.txt` | โทเค็นของแผง | ไม่ |

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

ลงชื่อเข้าใช้ Telegram ที่ `https://case.example.org` ด้วยโทเค็นของแผงควบคุม ตามที่ระบุใน [คู่มือบัญชี](https://phishdestroy.github.io/TgWitness/th/docs/reference/accounts/) การดำเนินการบนแผงควบคุมจะถูกบันทึกไว้ในบันทึกที่ลงนามแล้ว; การดำเนินการเหล่านี้ไม่ใช่ เซสชัน SSH [ผู้เป็นพยานสามารถตรวจสอบ](https://phishdestroy.github.io/TgWitness/th/docs/reference/witness/) `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](https://phishdestroy.github.io/TgWitness/th/docs/reference/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 เซิร์ฟเวอร์ก็ยังคงทำงานได้ และสองใน สิ่งเหล่านี้สามารถใช้งานได้ในวันนี้:

| อะไร | สิ่งที่แสดง | ในTgWitness |
| --- | --- | --- |
| Quick tunnel หรือ tunnel ของโดเมนของคุณ | สามารถเข้าถึงแผงนี้ได้เฉพาะผ่านทางอุโมงค์เท่านั้น | ตัวช่วยตั้งค่าเซิร์ฟเวอร์ ดูด้านบน |
| drand relay `drand.cloudflare.com` | บันทึกหลังรอบ drand จะใหม่กว่าบันทึกนี้: บันทึกนี้ถูกเขียนขึ้นตามลำดับเหตุการณ์ที่เกิดขึ้น | โหมดหลักฐาน, **ผู้เป็นพยานเพิ่มเติม**, ไม่มีบัญชี ([รูปแบบ](https://phishdestroy.github.io/TgWitness/th/docs/reference/evidence/#optional-records-in-evidence-mode-drand-and-telegram-devices)) |
| การแจ้งเตือนสถานะความเสถียรของ Tunnel | เมื่ออุโมงค์ถูกตัดการเชื่อมต่อ โดยทางอีเมลหรือ webhook จาก Cloudflare | ตั้งค่าในแดชบอร์ด Cloudflare |
| Gateway DNS (`--gateway-dns`, หรือ **Cloudflare Gateway DNS** ในตัวช่วยสร้าง) | ทุกชื่อที่เซิร์ฟเวอร์ค้นหา ซึ่ง Cloudflare ตอบกลับผ่าน TLS; ไฟร์วอลล์ของ Hetzner ไม่อนุญาตให้ DNS เข้าถึงสิ่งอื่นใด; และว่านโยบาย Gateway สามารถเขียนคำตอบใหม่ได้หรือไม่ | Hetzner, แพ็กเกจ Zero Trust ฟรี, ไม่ต้องการโดเมน; `verify` ตรวจสอบไฟร์วอลล์ ตำแหน่ง การบันทึกข้อมูล นโยบาย การสอบถามของเซิร์ฟเวอร์ และบันทึกการตรวจสอบ; โหมดหลักฐานจะคัดลอกบันทึกเข้าสู่สมุดบันทึก |
| เกตเวย์ที่ติดตั้ง Cloudflare One client บนเซิร์ฟเวอร์ ซึ่งเป็นไฟร์วอลล์ขาออกที่อนุญาตเฉพาะ Cloudflare เท่านั้น | ทุกการเชื่อมต่อที่เซิร์ฟเวอร์สร้างขึ้น ไม่ใช่แค่ DNS เท่านั้น | ยังไม่ได้สร้าง |
| เข้าถึงหน้าแผงควบคุม | ใครได้เข้าสู่ระบบในแผงควบคุม และเมื่อใด | ยังไม่ได้สร้าง: ต้องใช้โดเมนของคุณเอง |
| การบันทึกคำสั่ง SSH | ทุกคำสั่งในเซสชันการดีบัก | ยังไม่ได้สร้าง |

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 เก็บเวอร์ชันของกฎไว้ [บันทึกการตรวจสอบความ](https://phishdestroy.github.io/TgWitness/th/docs/reference/verification/)ถูกต้องแสดงรายการการปรับใช้ที่ผ่านการทดสอบและการตรวจสอบที่ยังคงใช้งานอยู่ [ส่วนขอบเขตการตรวจสอบ](https://phishdestroy.github.io/TgWitness/th/docs/reference/evidence/#verification-scope)จะเชื่อมโยงการตรวจสอบสภาพแวดล้อมเหล่านี้ กับการเก็บรวบรวมข้อมูลจากคลังข้อมูลและการตรวจสอบความสมบูรณ์