# Phala / Intel TDX · نشر عالي الأمان

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

خادم مغلق يعمل على مدار الساعة طوال أيام الأسبوع على Hetzner أو Phala Cloud، وبوابة DNS، وعمليات التحقق التي يمكن لطرف ثالث تكرارها.

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

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

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

خادم مغلق يعمل على مدار الساعة طوال أيام الأسبوع على Hetzner أو Phala Cloud، وبوابة 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/ar/docs/reference/deployment/)

![النشر والاستعادة](https://phishdestroy.github.io/TgWitness/assets/chapter-operate.svg)

يضيف النشر عالي الضمان فحوصات مستقلة لبيئة التجميع إلى التحقق من الأرشيف. يقوم المراجع بالاستعلام عن سجلات النشر والوصول التي يحتفظ بها مزود الخدمة السحابية وCloudflare، كما يضيف نشر Intel TDX شهادة الأجهزة لبيئة أداة التجميع.

لا يتغير الاستخدام العادي المحلي واستخدام Docker. لا يعمل أي شيء هنا ما لم تقم بالنشر باستخدام `python -m tgwitness.cloud`، ولا يقرأ المجمع مضيفه إلا عندما يحدد النشر `TGWITNESS_ASSURANCE`.

مخطط تدفق · المشغل → خادم، وجدار حماية بدون قواعد دخول (واجهة برمجة تطبيقات المزود); المشغل → النفق وDNS (واجهة برمجة تطبيقات Cloudflare); خادم، وجدار حماية بدون قواعد دخول → النفق وDNS (للإرسال فقط); خادم، وجدار حماية بدون قواعد دخول → مفتاح التوقيع الذي تم إنشاؤه على الخادم; Verifier، الرموز المميزة للقراءة فقط → سجل المزود وجدار الحماية; Verifier، الرموز المميزة للقراءة فقط → عنوان موصل النفق ومدخل البيانات; Verifier، الرموز المميزة للقراءة فقط → بيان /api/assurance الموقّع; Verifier، الرموز المميزة للقراءة فقط → ملف ZIP للأدلة · المشغل · Verifier، الرموز المميزةللقراءة فقط · خادم، وجدار حماية بدونقواعد دخول · سجل المزود وجدار الحماية · عنوان موصل النفق ومدخلالبيانات · بيان /api/assuranceالموقّع · ملف ZIP للأدلة · النفق وDNS · مفتاح التوقيع الذي تمإنشاؤه على الخادم · واجهة برمجة تطبيقات المزود · واجهة برمجة تطبيقات · Cloudflare · للإرسال فقط

**الرسم التخطيطي كنص**

1. المشغل → خادم، وجدار حماية بدون قواعد دخول (واجهة برمجة تطبيقات المزود)
2. المشغل → النفق وDNS (واجهة برمجة تطبيقات Cloudflare)
3. خادم، وجدار حماية بدون قواعد دخول → النفق وDNS (للإرسال فقط)
4. خادم، وجدار حماية بدون قواعد دخول → مفتاح التوقيع الذي تم إنشاؤه على الخادم
5. Verifier، الرموز المميزة للقراءة فقط → سجل المزود وجدار الحماية
6. Verifier، الرموز المميزة للقراءة فقط → عنوان موصل النفق ومدخل البيانات
7. Verifier، الرموز المميزة للقراءة فقط → بيان /api/assurance الموقّع
8. Verifier، الرموز المميزة للقراءة فقط → ملف ZIP للأدلة

**في هذه الصفحة**

- [ما يمكن للمحقق التحقق منه](https://phishdestroy.github.io/TgWitness/ar/docs/reference/high-assurance/#what-a-verifier-can-check)
- [المزودون](https://phishdestroy.github.io/TgWitness/ar/docs/reference/high-assurance/#providers)
- [آلة افتراضية سرية على Phala Cloud (Intel TDX)](https://phishdestroy.github.io/TgWitness/ar/docs/reference/high-assurance/#confidential-vm-on-phala-cloud-intel-tdx)
- [قبل البدء](https://phishdestroy.github.io/TgWitness/ar/docs/reference/high-assurance/#before-you-start)
- [من اللوحة](https://phishdestroy.github.io/TgWitness/ar/docs/reference/high-assurance/#from-the-panel)
- [نفق سريع بدون نطاق](https://phishdestroy.github.io/TgWitness/ar/docs/reference/high-assurance/#quick-tunnel-without-a-domain)
- [النشر](https://phishdestroy.github.io/TgWitness/ar/docs/reference/high-assurance/#deploy)
- [تصحيح أخطاء النشر والتأمين](https://phishdestroy.github.io/TgWitness/ar/docs/reference/high-assurance/#debug-deployment-and-lock)
- [إزالة عملية النشر](https://phishdestroy.github.io/TgWitness/ar/docs/reference/high-assurance/#remove-a-deployment)
- [أي خادم (مُصدق ذاتيًا)](https://phishdestroy.github.io/TgWitness/ar/docs/reference/high-assurance/#any-server-self-attested)
- [التحقق](https://phishdestroy.github.io/TgWitness/ar/docs/reference/high-assurance/#verify)
- [تقرير عن تسليم الأدلة](https://phishdestroy.github.io/TgWitness/ar/docs/reference/high-assurance/#report-for-evidence-handover)
- [Cloudflare كشاهد خارجي](https://phishdestroy.github.io/TgWitness/ar/docs/reference/high-assurance/#cloudflare-as-an-outside-witness)
- [قراءة نتيجة النشر](https://phishdestroy.github.io/TgWitness/ar/docs/reference/high-assurance/#reading-the-deployment-result)

## ما يمكن للمحقق التحقق منه

| الادعاء | كيف يتم التحقق من ذلك | يتم الاحتفاظ بها بواسطة |
| --- | --- | --- |
| تم إنشاء الخادم عبر واجهة برمجة تطبيقات (API) المزود في وقت معروف | كائن الخادم وإنشاؤه في سجل المزود الخاص | المزود |
| لم يستخدم أحد مسارات الوصول الخاصة بالمزود | سجل طلبات وحدة التحكم، والإنقاذ، وإعادة تعيين كلمة المرور، وإعادة البناء، وملفات ISO، والصور، والنسخ الاحتياطية | المزود |
| لا يمكن لأي شيء الاتصال بها | لا يحتوي جدار الحماية الخاص بالمزود على أي قواعد للاتصالات الواردة؛ ويتم إخفاء SSH منذ التشغيل الأول | المزود (جدار الحماية)، المضيف (SSH) |
| لا يمكن الوصول إلى اللوحة إلا عبر النفق | يتم توجيه مدخل النفق إلى اللوحة وحدها؛ ويعمل الموصل من عنوان الخادم | Cloudflare |
| هذا البرنامج بالذات يعمل | تتطابق قيمة التجزئة الموقعة لشجرة المصدر الخاصة بـ«الجامع» مع نسخة من الالتزام الذي تم نشره | Collector، تمت مقارنته مع Git |
| تم إنشاء مفتاح التوقيع على ذلك الخادم | يقوم المفتاح بتوقيع بيان يحدد معرّف خادم المزود وهاش ملف cloud-init الذي تلقّاه | Collector، تمت مقارنته مع المزود |
| تنتمي اليومية إلى ذلك المفتاح والخادم | كل عملية تبدأ في الدليل ZIP تحمل قياس المضيف لذلك الخادم | الأدلة ZIP |

يقوم المجمع بتسجيل حالة SSH والجلسات وسجل تسجيل الدخول ومعلومات التشغيل في سجلات موقعة لـ process-start و`host.state`. على جهاز افتراضي عادي، تُعد هذه سجلات جرد محلية يقارنها المراجع بالسجلات المستقلة الخاصة بالمزود. كما أن نشر 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، ووحدة التحكم على الويب الخاصة بـ Vultr فلا يتم تسجيلها على هذا النحو، لذا يتم قفل حساب الجذر (root) عند أول عملية تشغيل، ويحتاج تسجيل الدخول إلى وحدة التحكم إلى إعادة تعيين كلمة المرور أو تغيير طريقة التشغيل، وهما أمران يتم تسجيلهما. تقوم Vultr بإرجاع عنوان وحدة التحكم إلى أي مفتاح يمكنه قراءة المثيل؛ ولا يتم تخزينه لا في السجل ولا في التقرير.

## آلة افتراضية سرية على 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` | هذا النص هو، بايتًا بايتًا، نفس النص الذي يبنيه كود الالتزام الذي تم نشره: ملفات المصدر مثبتة بواسطة التجزئة، والصورتان بواسطة الملخص، ولا يوجد أي كود آخر |
| `tdx_identity` | يأتي التوثيق من التطبيق والمثيل الذي تم نشره، باستخدام مفاتيح من نظام إدارة المفاتيح (KMS) الخاص بـ Phala وقرص مشفر |
| `tdx_os` | تساوي قيمتي MRTD و RTMR0-2 القيم التي يحسبها المدقق من صورة نظام التشغيل dstack التي تنشرها Dstack-TEE، والتي يتم العثور عليها من خلال تجزئة صورة نظام التشغيل التي يبلغ عنها CVM، ومن جداول ACPI التي يبنيها QEMU لشكل الآلة الافتراضية: البرنامج الثابت، النواة، initrd، سطر الأوامر مع تجزئة نظام الملفات الجذر، الذاكرة، المعالجات الافتراضية (vCPUs) والأجهزة. تفشل صورة التطوير |

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 بعد فشل النشر يؤدي إلى رفض التقرير، ويتم إدراج عمليات إعادة التشغيل للمراجعة.

في اللوحة، اختر **«آلة افتراضية سرية · Phala Cloud»** ضمن **«إضافات»** → **«خادم 24/7»** والصق مفتاح واجهة برمجة تطبيقات 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. خدمة Gateway DNS غير متوفرة هنا: لا يمتلك Phala جدار حماية من مزود الخدمة للحركة الصادرة.

### شهادة التصديق

بالنسبة لنشر Phala، يقوم `verify --report certificate.md` أيضًا بكتابة الشهادة: ملف `certificate.html` مستقل وملف A4 `certificate.pdf` يتضمنان النتيجة النهائية، وسلسلة الثقة من الجذر الخاص بـ Intel إلى مفتاح المجمع، ومقارنة مع الخوادم العادية والخوادم عالية الضمان، والقياسات بجانب القيم المحسوبة من الصورة المنشورة، ومن يضمن كل جزء، وسلسلة شهادات Intel، وكل فحص، وسجل المزود، وكيفية تكرار التحقق. يظل تقرير JSON هو السجل المرجعي؛ بينما تعرضه الصفحات.

التقرير مختوم رقميًا بالتوقيعات والطوابع الزمنية، في ملف `certificate.seal.json` والملفات `.tsq`/`.tsr` الموجودة بجانبه:

| الختم | ما الذي تضيفه |
| --- | --- |
| طابع زمني إلكتروني معتمد، `http://tsa.belgium.be/connect` | طابع زمني وفقًا لمعيار RFC 3161 على البايتات الدقيقة لـ `certificate.json` من مزود خدمة الثقة المؤهل التابع للحكومة الفيدرالية البلجيكية (FPS Policy and Support، BOSA). وتُدرج هذه الوحدة كخدمة ختم زمني معتمدة، بحالة «ممنوحة»، في القائمة الموثوقة للاتحاد الأوروبي الخاصة ببلجيكا؛ ويتم تثبيت الجذر (Belgium Root CA6) وإدخالات القائمة، اعتبارًا من القائمة الصادرة في 20 أكتوبر 2026، في `tgwitness/tsa_roots.py`. وبموجب المادة 41 من اللائحة (الاتحاد الأوروبي) رقم 910/2014، يُفترض أن هذا الختم الزمني دقيق من حيث التاريخ والوقت ومن حيث سلامة البيانات في كل دولة عضو في الاتحاد الأوروبي |
| الطابع الزمني RFC 3161، FreeTSA | طابع زمني ثانٍ مستقل |
| توقيع أداة التحقق | يتم تطبيق خوارزمية Ed25519 على عبارة تحدد قيمة SHA-256 للتقرير وكل طابع زمني، باستخدام المفتاح الخاص بالمدقق (`--sign-with FOLDER`، الافتراضي `~/.tgwitness/verifier`)؛ ويحمل ملف PDF توقيعًا بنفس المفتاح |

يختار `--timestamp URL` (قابل للتكرار) سلطات أخرى، بينما لا يختار `--timestamp none` أي سلطة، ويترك `--sign-with
none` الختم دون توقيع. أما `check-report` فيتحقق من تجزئة التقرير، وتوقيع المدقق، وكل طابع زمني إلى جذر موثوق به وحالته المؤهلة، وتوقيع ملف PDF. الأهمية القانونية للطابع الزمني المؤهل خارج الاتحاد الأوروبي، وللتقرير ككل، تعود إلى المحكمة أو السلطة التي تستلمه؛ ويُظهر الختم تاريخ وجود التقرير وأنه لم يتغير.

لا يمكن للتصديق أن يستبعد وجود عيب في وحدة TDX أو الميكروكود الخاص بشركة Intel، أو الوصول المادي إلى ناقل الذاكرة. يمكن لأي شخص يتحكم في التطبيق في حساب Phala نشر تكوين آخر؛ ويظهر هذا التكوين كنسخة معدلة جديدة مع هاش تكوين جديد. يتحكم المضيف في مصدر الوقت للجهاز والشبكة.

تم تنفيذ عمليات النشر، والتحقق باستخدام `--evidence`، وإعادة التشغيل، ومقارنة صورة نظام التشغيل، والشهادة المختومة رقميًا بالتوقيعات والطوابع الزمنية، و التدمير على Phala Cloud نفسها؛ انظر [، عملية التشغيل في 4 نوفمبر 2026،](https://phishdestroy.github.io/TgWitness/ar/docs/reference/verification/#live-phala-cloud-deployment--4-november-2026).

## قبل أن تبدأ

1. منطقة Cloudflare، ومعرف حسابها، ورمز API مع **تحرير Cloudflare Tunnel** و **قراءة المنطقة** و**تحرير DNS**، مع إرفاقها بـ `--cloudflare-token-file` أو `CLOUDFLARE_API_TOKEN`. بالنسبة للمُحقق: **قراءة Cloudflare Tunnel** و**قراءة DNS**، وبالنسبة لسجل التدقيق، **إعدادات الحساب - قراءة**. بدون نطاق، لا يحتاج [نفق سريع](https://phishdestroy.github.io/TgWitness/ar/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. التزام التشغيل. يتم تحويل علامة الإصدار مرة واحدة إلى التزامها باستخدام `git ls-remote`؛ ولا يتلقى الخادم سوى الالتزام المكون من 40 حرفًا.

## من اللوحة

على جهاز الكمبيوتر الخاص بك، تعمل **«Extras → Server 24/7»** بنفس الطريقة `deploy` بالنسبة لـ Hetzner في ثلاث خطوات: اختر أوروبا أو الولايات المتحدة، والصق رمز Hetzner (قراءة وكتابة)، ثم راجع نوع الخادم، والسعر الشهري، والعنوان، والإصدار الذي عثرت عليه اللوحة باستخدام هذا الرمز. لا يتم إنشاء أي شيء قبل تأكيدك. تعرض اللوحة كل خطوة كما `deploy` يتم الإبلاغ عنها، ثم العنوان، ورمز لوحة التحكم وبصمة مفتاح التوقيع. بدون نطاق، يحصل الخادم على [نفق سريع](https://phishdestroy.github.io/TgWitness/ar/docs/reference/high-assurance/#quick-tunnel-without-a-domain) ؛ **خوادمك → «البحث عن العنوان الحالي** » يبحث عنه مرة أخرى بعد إعادة التشغيل. للحصول على عنوان ثابت تحت نطاقك الخاص، افتح **«اختياري · نطاقك الخاص** » وأضف رمز Cloudflare (الرابط المُعد مسبقًا يحدد «قراءة المنطقة» و«تحرير DNS» و«تحرير نفق Cloudflare»).

تنتقل الرموز مع كل طلب من علامة تبويب المتصفح إلى TgWitness على نفس الكمبيوتر ولا يتم تسجيلها في أي مكان؛ حيث يتم الاحتفاظ بسجل النشر، وملف cloud-init المحجوب، ورمز اللوحة، و مفتاح العنوان (لإنشاء نفق سريع) داخل `deployments/NAME` داخل دليل البيانات. لا توفر اللوحة هذه الميزة إلا للمسؤول الرئيسي عبر اتصال لوبباك مباشر (`127.0.0.1`، بدون رؤوس بروكسي أو نفق)؛ أما اللوحة التي يتم الوصول إليها عبر الشبكة فتعرض الأوامر بدلاً من ذلك. يكون الإصدار افتراضيًا هو علامة الإصدار الخاصة باللوحة قيد التشغيل، والتي يتم تحديدها من خلال واجهة برمجة تطبيقات GitHub. أما الموقع ونوع الخادم والسعر فتأتي من واجهة برمجة تطبيقات 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
```

على الخادم، تفتح خدمة Cloudflare [نفقًا سريعًا](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 the current address**» لا تقبلان سوى المنشورات الموقعة، لذا لا يمكن لمنشور مزور إرسالك أنت ورمز لوحة التحكم الخاص بك إلى عنوان شخص آخر. الموضوع موجود في السجل و في cloud-init المنشور: يمكن لأي شخص يمتلكهما قراءة العنوان الحالي، الذي لا يزال يطلب رمز لوحة التحكم. لا يحتفظ الخادم بأي منفذ وارد في كلتا الحالتين.

لا يمتلك المُحقق مفتاح عنوان، ويمكن لأي شخص يقرأ الموضوع النشر فيه. لذا يقوم المُجمّع أيضًا بنشر العنوان نفسه، موقّعًا بمفتاح Ed25519 الخاص به، ويأخذ `verify` أحدث منشور موقّع بمفتاح المُجمّع في سجل النشر؛ ويتم ترتيب المنشورات حسب الوقت الذي استلمتها فيه ntfy.sh ، وليس حسب الوقت الذي تدعيه. لا يوقع المجمع الذي يعود إلى ما قبل هذا التغيير على أي شيء، و يأخذ `verify` بعد ذلك أحدث منشور ويذكر ذلك في فحص `statement`؛ ولا يمكن للمنشور المزور إلا أن يتسبب في فشل هذا الفحص، حيث يجب أن يرد العنوان بمفتاح المجمع.

ما يكلفه ذلك: لا يحتفظ أي حساب Cloudflare بسجلات لنفق سريع، لذا يُبلغ `verify` أن النفق والموصل وفحص DNS غير متاحين، وتكون النتيجة في أفضل الأحوال `incomplete` (عندما 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، ويقفل حساب الجذر، ويقوم بتثبيت `cloudflared`، ويجلب الالتزام بالضبط، ويتحقق منه، ويبدأ تشغيل TgWitness كخدمة systemd معززة؛
4. ينتظر البيان الموقّع من المجمع ويتحقق من أنه يذكر اسم هذا الخادم و التجزئة الخاصة بـ cloud-init هذا.

`deployments/case-2026-11/` ثم تحتوي على:

| ملف | المحتويات | مشاركة؟ |
| --- | --- | --- |
| `deployment.json` | المعرفات، والتجزئات، وطلبات واجهة برمجة التطبيقات (الطريقة، المسار، الحالة)، والبيان الأول الموقّع | نعم، باستخدام أداة التحقق |
| `cloud-init.redacted.yaml` | تم استبدال الأمر الدقيق لـ cloud-init مع سرّيه بـ `REDACTED` | نعم |
| `panel-token.txt` | رمز اللوحة | لا |

لا يتم أبدًا كتابة كلمة مرور الجذر الخاصة بالمزود، ورمز النفق، ورمز اللوحة `deployment.json`. انشر بصمة المجمع المطبوعة في النهاية عبر قناة لا تتحكم فيها بمفردك، على سبيل المثال قناة الشهود أو رسالة إلى المستلم.

قم بتسجيل الدخول إلى Telegram على `https://case.example.org` باستخدام رمز اللوحة، كما هو موضح في [دليل الحساب](https://phishdestroy.github.io/TgWitness/ar/docs/reference/accounts/). يتم تسجيل إجراءات اللوحة في السجل الموقّع؛ وهي ليست جلسات SSH. يمكن [للشاهد](https://phishdestroy.github.io/TgWitness/ar/docs/reference/witness/) إجراء استطلاع `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` مسجلة بالفعل لدى المزود: اسم أو معرّف مفتاح 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 في غضون 12 ساعة.

## أي خادم (مُصدق ذاتيًا)

`--provider generic` هذا مخصص لخادم تم شراؤه أو تثبيته يدويًّا. `deploy` يُنشئ النفق وDNS، ويكتب `install.sh` (خاص) و `install.redacted.sh` (للنشر)، وينتظر. انسخ `install.sh` إلى خادم Ubuntu 24.04 تم تثبيته حديثًا وقم بتشغيله هناك:

```
sudo bash install.sh
```

وهي تسجل المضيف كما كان (عمليات تسجيل الدخول، والحسابات، `authorized_keys`، ومنافذ الاستماع، والخدمات، والمهام المجدولة، والحزم)، ويقوم بتثبيت الالتزام، وتفعيل جدار الحماية الخاص بالمضيف، وحذف نفسه، وإخفاء SSH، وإنهاء الجلسة. ويكون التقرير الخاص بمثل هذا الخادم في أحسن الأحوال **«مُثبت ذاتيًا**»: أي أن من قام بتشغيل المثبت كان يمتلك صلاحيات الجذر قبله، ولا يتوفر أي سجل من المزود للمحقق. ومع ذلك، فهو أفضل من خادم غير موثق: حيث يتم توقيع قائمة الجرد، وتجزئة المثبت، وكل عملية تسجيل دخول لاحقة.

## التحقق

يحتاج المُحقق إلى `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 من قبل المُحقق في تلك اللحظة؛ ولا يوفر السجل سوى المعرّفات المطلوب الاستفسار عنها. رمز الخروج هو 0 لـ **«PASS**»، و1 لـ **«FAIL**»، و2 لـ **«REVIEW**» أو **«INCOMPLETE**» أو **«SELF-ATTESTED**». `--fingerprint` يجب أن يأتي من قناة مستقلة؛ وبدونها تتم مقارنة المفتاح بسجل المشغل فقط. `python verify.py` لا يزال يتحقق من الدليل ZIP، كما هو موضح في [قسم «الدليل](https://phishdestroy.github.io/TgWitness/ar/docs/reference/evidence/)».

يتم تصنيف إجراءات المزود على النحو التالي: يتم قبول إجراءات الإنشاء والتشغيل في غضون 30 دقيقة من الإنشاء؛ أما إجراءات وحدة التحكم، والإنقاذ، وإعادة تعيين كلمة المرور، وإعادة البناء، وملفات ISO، والصور، واللقطات، والنسخ الاحتياطية، و«مدير الأنظمة»، و«EC2 Instance Connect»، وفتح ثغرات في جدار الحماية، فتُرفض؛ أما إجراءات الطاقة وأي إجراءات غير متوقعة فيتم وضع علامة عليها للمراجعة. ولا تمر أي إجراء غير معروف مرور الكرام أبدًا.

## تقرير لتسليم الأدلة

`--report report.md` يكتب تقرير Markdown و `report.json` بجانبه:

1. النتيجة، بصمة مفتاح المجمع، النشر، المزود، الالتزام، الخادم، جدار الحماية، النفق؛
2. كل فحص مع حالته ومصدره (واجهة برمجة تطبيقات المزود، واجهة برمجة تطبيقات Cloudflare، بيان المجمع، سجل الأدلة)؛
3. سجل المزود الذي يتضمن تقييم كل إجراء، وكذلك الفاعل، في الحالات التي يسجله فيها المزود؛
4. نقاط نهاية Cloudflare التي تحتفظ باتصالات النفق وتكوينه وسجل التدقيق؛
5. بيان المجمع الموقّع؛
6. ما يثبته التقرير وما لا يثبته؛
7. الأوامر اللازمة لتكرار العملية، وSHA-256 لكل ملف تم تزويدها به.

قم بتسليم التقرير، `report.json`, `deployment.json`والمثبت المنشور و الأدلة ZIP. قم بإعداد التقرير في وقت مبكر: حيث يتم الاحتفاظ بسجلات مزود الخدمة لفترات محدودة.

## Cloudflare كشاهد خارجي

كل شيء هنا اختياري. حتى بدون حساب Cloudflare، يظل الخادم يعمل، وهناك اثنان من هذه الخوادم يعملان اليوم:

| ماذا | ما يعرضه | في TgWitness |
| --- | --- | --- |
| نفق سريع أو نفق خاص بنطاقك | لا يمكن الوصول إلى اللوحة إلا عبر النفق | معالج الخادم، انظر أعلاه |
| ترحيل drand `drand.cloudflare.com` | السجلات التي تلي جولة drand أحدث منها: فقد كُتبت اليومية بشكل متتابع | وضع الأدلة، **المزيد من الشهود**، بدون حساب ([تنسيق](https://phishdestroy.github.io/TgWitness/ar/docs/reference/evidence/#optional-records-in-evidence-mode-drand-and-telegram-devices)) |
| إشعارات حالة النفق | عند تعطل النفق، عبر البريد الإلكتروني أو webhook من Cloudflare | قم بتعيينها في لوحة تحكم Cloudflare |
| Gateway DNS (`--gateway-dns`، أو **Cloudflare Gateway DNS** في المعالج) | كل اسم بحث عنه الخادم، تم الرد عليه بواسطة Cloudflare عبر بروتوكول TLS؛ ولا يسمح جدار الحماية من Hetzner لنظام DNS بالوصول إلى أي شيء آخر؛ وما إذا كان بإمكان سياسة البوابة إعادة كتابة الإجابات | Hetzner، خطة Zero Trust مجانية، بدون نطاق؛ `verify` يتحقق من جدار الحماية والموقع والتسجيل والسياسات واستعلامات الخادم وسجل التدقيق؛ ويقوم «وضع الأدلة» بنسخ السجل إلى «اليومية» |
| بوابة مع عميل Cloudflare One على الخادم، وهو جدار حماية للاتصالات الصادرة لا يسمح إلا بـ Cloudflare | كل اتصال أجراه الخادم، وليس فقط DNS | لم يتم إنشاؤها بعد |
| الوصول أمام اللوحة | من قام بتسجيل الدخول إلى اللوحة ومتى | لم يتم إنشاؤها بعد: تحتاج إلى نطاق خاص بك |
| تسجيل أوامر SSH | كل أمر في جلسة تصحيح الأخطاء | لم يتم إنشاؤها بعد |

تعد Logpush، التي تحتفظ بنسخة Cloudflare الخاصة في R2، ميزة مخصصة للمؤسسات: في الخطة المجانية ، تستجيب Cloudflare `logpush is not enabled for this account`. يستمر سجل بوابة Cloudflare لمدة 24 ساعة هناك، لذا يقوم «وضع الأدلة» بنسخه إلى السجل الموقّع (**سجل بوابة Cloudflare لـ استعلامات DNS لهذا الخادم،** وهو رمز للقراءة فقط مع «قراءة تحليلات الحساب»).

بدون خطة «Zero Trust»، يكون للحساب موقع DNS واحد. وعندما ترفض Cloudflare موقعًا آخر، يشارك الخادم الموقع الحالي ويتم تمييز استفساراته عن طريق عنوانه؛ ويحتاج هذا المرشح إلى «Zero Trust PII Read» أيضًا، و `destroy` يترك موقعًا مشتركًا. يمتد استعلام السجل الواحد لمدة ثلاث ساعات كحد أقصى، لذا تتم قراءة النسخة و `verify` قراءة اليوم في نوافذ مدتها ثلاث ساعات.

يغطي بوابة DNS محلل النظام. ولا يظهر في سجلها بروتوكول DNS عبر HTTPS على المنفذ 443 المتجه إلى محلل آخر، ولا الاتصالات الموجهة إلى عناوين لم يتم البحث عنها في أي مكان (مثل مراكز بيانات Telegram، على سبيل المثال).

لا يمكن لـ Cloudflare الاطلاع على محتوى تشفير Telegram، أو الأجهزة الأخرى المرتبطة بحساب Telegram (قائمة الأجهزة في «وضع الأدلة» تسجلها من جانب Telegram) أو برنامج Hypervisor الخاص بالمزود.

## قراءة نتيجة النشر

بالنسبة للآلة الافتراضية العادية، يتحكم المزود في البنية التحتية للمضيف، ويتم فحص المخزون المحلي إلى جانب سجلات المزود. بالنسبة لـ Intel TDX، يقوم المُحقق أيضًا بفحص مواصفات الأجهزة، وربط المجمع، وعمليات التكوين، وقياسات نظام التشغيل. اقرأ النتائج الفردية لمعرفة الفحوصات التي تم اجتيازها أو التي لم تكن متاحة.

تعتمد تفاصيل جدار الحماية التاريخية على المزود؛ حيث تحتفظ Linode بإصدارات القواعد. يسرد [سجل التحقق](https://phishdestroy.github.io/TgWitness/ar/docs/reference/verification/) عمليات النشر التي تم اختبارها وعمليات الفحص الحية المتبقية، ويربط [نطاق التحقق](https://phishdestroy.github.io/TgWitness/ar/docs/reference/evidence/#verification-scope) بين عمليات فحص البيئة هذه واكتساب الأرشيف وسلامته.