دليل تقوية الأمان

تغطي هذه الصفحة إعدادات ZTXBAS المهمة للنشر الإنتاجي. وتقوية أمان Linux عمومًا (إعدادات kernel sysctl وSSH وfail2ban وأساس جدار حماية المضيف) خارج نطاقها؛ وتغطيها معايير CIS ودليل تقوية Ubuntu Server بصورة أفضل.

إذا كنت لا تزال في مرحلة التجربة، فابدأ باختبار docker run في دليل البدء. تفترض هذه الصفحة أنك تستعد لتشغيل ZTXBAS في مكان يمكن للمستخدمين الحقيقيين الوصول إليه.

1. نموذج التهديد

صُمم ZTXBAS لمقاومة:

• التصيد. يضمن ربط الأصل وإظهاره على الهاتف عدم إمكان إعادة تشغيل مصادقة تمت الموافقة عليها لدى أصل مختلف.
• إعادة التشغيل على الشبكة. تُوقّع جميع طلبات API باستخدام HMAC-SHA256 مع طابع زمني محدود التفاوت وقيمة Nonce. وتحمي TLS قناة الاتصال الخارجية.
• انتحال التطبيق المعتمد (RP). يمتلك كل تطبيق سر HMAC خاصًا به؛ فيقتصر أثر تسرب السر على التطبيق المعني.
• سرقة رموز الموافقة. رموز JWT قصيرة العمر وموقعة بـES256 ومرتبطة بـsub وaud (معرّف التطبيق) وorigin.

لا يحمي ZTXBAS من:

• اختراق مضيف المسؤول: فكل من يملك ملف تعريف ارتباط جلسة الإدارة أو كلمة مرور المسؤول يستطيع إنشاء التطبيقات وتدوير الأسرار. تعامل مع الوصول إلى اللوحة كصلاحيات root.
• تطبيق RP خبيث: قد يستطيع الطرف المعتمد الذي يكذب بشأن أصله التصيد لمستخدميه هو فقط، لكنه يستطيع ذلك.
• هاتف مسجل وغير مقفل في يد مهاجم. يحمي توثيق الجهاز من العبث، لكنه لا يحمي من تسليم مستخدم شرعي جهازًا غير مقفل.
• أي شيء أسفل الحاوية: نواة المضيف أو برنامج الأجهزة الافتراضية أو الوصول المادي إلى القرص الحاوي لملف SQLite.

2. تحقق من صورة الحاوية قبل تشغيلها

يُوقّع كل إصدار باستخدام cosign. تحقق قبل جلبه إلى الإنتاج:

# Get the public key once (pin both URLs; either is fine).
curl -sO https://corezt.com/ztxbas/cosign.pub

# Verify the tag you're about to run.
cosign verify --key cosign.pub ghcr.io/corezt/ztxbas:1.0.0

ثم ثبّت النشر على بصمة digest بدل الوسم tag:

docker pull ghcr.io/corezt/ztxbas:1.0.0
docker inspect --format='{{index .RepoDigests 0}}' ghcr.io/corezt/ztxbas:1.0.0
# ghcr.io/corezt/ztxbas@sha256:...

البصمات غير قابلة للتغيير بخلاف الوسوم. فإذا اختُرقت بنية توزيع الصور، قد يُعاد توجيه الوسم إلى صورة أخرى، لكن بصمتها لا تتغير.

تدوير المفتاح. عند تدوير مفتاح التوقيع، يُنشر المفتاح الجديد إلى جانب القديم لدورة إصدار كاملة حتى يتمكن المتكاملون من الانتقال. تُنشر الإعلانات في صفحة الإصدارات وSECURITY.md. ومن المخطط دعم التوقيع دون مفاتيح ثابتة عبر OIDC عند تفعيل GitHub Actions؛ وحتى ذلك الوقت يجري توقيع cosign من محطة مدير الإصدارات.

3. إعدادات تشغيل الحاوية

يأتي ملف docker-compose.yml القياسي بالإعدادات التالية؛ وإذا نقلتها إلى نظام تنسيق آخر فأبقها كما هي.

cap_drop: [ALL]
security_opt:
  - no-new-privileges:true
read_only: true
tmpfs:
  - /tmp:size=16m
user: "10001:10001"       # non-root in the image

أهمية كل إعداد:

• cap_drop: ALL — يعمل ZTXBAS خادم HTTP وUDP في مساحة المستخدم ولا يحتاج إلى قدرات إضافية. وإذا فشل ربط منفذ، فقد يكون منفذًا مميزًا أقل من 1024؛ استخدم منافذ 8443/8080/9443 المخصصة أو اربط المنفذ على المضيف عبر وكيل عكسي بدل منح CAP_NET_BIND_SERVICE.
• no-new-privileges — يمنع ملفات setuid داخل الصورة من تصعيد الامتيازات. لا توجد هذه الملفات حاليًا، لكن قد تضيفها اعتماديات مستقبلية.
• read_only: true مع tmpfs لـ/tmp — لا تكتب الحاوية إلا إلى /var/lib/ztxbas (وحدة تخزين البيانات) و/tmp (الملفات المؤقتة). ويحد نظام ملفات الجذر للقراءة فقط من فئات كثيرة من أساليب الاستمرارية الخبيثة.
• مستخدم غير root — تعمل الصورة بمعرّفي مستخدم ومجموعة 10001. يُنشأ مجلد البيانات بصلاحيات 0700 عند التشغيل الأول؛ لا تنفذ chown -R إلى root «لحل خطأ صلاحيات». فذلك الخطأ يعني أن وحدة التخزين أُنشئت بواسطة مستخدم آخر وتحتاج إصلاحًا على مستوى المضيف.

يُستحسن إضافة حدود موارد إلى تلك الضوابط:

deploy:
  resources:
    limits:
      memory: 512M
      pids: 200

يمكن لمثيل واحد التعامل مع مئات التحديات المتزامنة دون بلوغ هذا الحد عادةً؛ الغرض منه احتواء الحالات الخارجة عن السيطرة، لا تقدير حجم الحمل المطلوب.

4. كشف منافذ الشبكة

يستمع ZTXBAS على ثلاثة منافذ، ولكل منها متطلبات كشف مختلفة جدًا.

المنفذ	البروتوكول	المحتوى	الكشف العام
8443/tcp	HTTPS	واجهة API للتطبيقات المعتمدة موقعة بـHMAC	عام مع إنهاء TLS
8080/tcp	HTTP(S)	لوحة الإدارة	لا تُكشف أبدًا مباشرة للإنترنت
9443/udp	AES-GCM	نقل تطبيق الهاتف	عام مع نشر مباشر

يحمل منفذ UDP المحمول تشفيره الخاص (غلاف AES-256-GCM مع إثبات ECDSA مرتبط بالجهاز؛ انظر SECURITY.md). ولا يوضع وراء وكيل عكسي، لأن وكلاء HTTP القياسيين لا يمررون إطار هذا البروتوكول. انشره مباشرة على المضيف وافتح UDP/9443 في جدار الحماية.

وصفة ufw بسيطة على المضيف:

ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp comment 'ssh'
ufw allow 443/tcp comment 'caddy → ZTXBAS 8443'
ufw allow 9443/udp comment 'ZTXBAS mobile transport'
# 8080 is NOT opened — see section 6.
ufw enable

5. TLS

يدعم ZTXBAS ثلاثة أشكال من TLS. اختر واحدًا.

الموصى به: وكيل عكسي ينهي TLS (Caddy). يتولى Caddy بروتوكول ACME تلقائيًا، لذا لا يظهر تجديد الشهادات للمستخدم. يضبط ملف docker-compose.caddy.yml الإضافي ذلك. يقدم ZTXBAS HTTP عاديًا على جانب loopback، ويتولى Caddy TLS على الجانب العام.

TLS مباشرة على المنفذ. اضبط ZTXBAS_TLS_CERT وZTXBAS_TLS_KEY على مسارات PEM المركبة. يقرأ ZTXBAS الملفين مرة واحدة عند التشغيل؛ لا يوجد ACME مدمج ولا إعادة تحميل فورية. ويجب أن تقترن أداة تجديد الشهادات التي تكتب ملفات جديدة (مثل certbot خارجي أو وكيل Let's Encrypt) بإعادة تشغيل الحاوية عند تغير الملفات. ويعني ذلك عمليًا تنفيذ docker restart ZTXBAS ليلًا بحسب جدول التجديد؛ ما يسبب انقطاعًا لبضع ثوانٍ.

موازن حمل سحابي ينهي TLS. يشبه نموذج Caddy لكن موازن الحمل يملك الشهادة. تأكد من إضافة رؤوس X-Forwarded-For و-Proto، واقرأ القسم 7 حول الوكلاء الموثوقين.

اسمح بـTLS 1.2 أو أحدث فقط، وفضّل TLS 1.3. وكلاهما إعداد افتراضي في Caddy؛ أما إذا أنهيت TLS عند موازن حمل فعطّل صراحةً جميع الإصدارات الأقدم من 1.2.

6. إتاحة لوحة الإدارة بأمان

تمثل لوحة الإدارة على المنفذ 8080 أكثر الأسطح حساسية في مثيل ZTXBAS. توجد ثلاثة مسارات مدعومة بترتيب تنازلي للأمان:

أ. Loopback مع نفق SSH (الأكثر أمانًا). اترك ZTXBAS_CONSOLE_LISTEN_ADDR على القيمة الافتراضية (127.0.0.1:8080). وصل إليها من حاسوبك عبر:

ssh -L 8080:127.0.0.1:8080 ztxbas.example.com
# then open http://127.0.0.1:8080 in your browser

لا يلزم تغيير تهيئة ZTXBAS. وتصبح اللوحة غير قابلة للوصول من الإنترنت بتصميمها. وهذا هو الافتراضي والموصى به.

ب. وكيل عكسي مع مصادقة أساسية وقائمة IP مسموحة. انشر اللوحة تحت اسم مثل console.ztxbas.example.com خلف Caddy، مع مصادقة أساسية أمامها وقائمة IP مسموحة لمكتبك أو نطاق VPN. راجع deploy/docker/Caddyfile.example. يصلح ذلك للفرق، لكن لا تستخدم المصادقة الأساسية وحدها حاجزًا وحيدًا.

ج. mTLS عند الوكيل العكسي. للنشر عالي الأهمية، ضع أمام اللوحة Caddy أو nginx يشترط شهادة عميل، مع قائمة IP مسموحة إضافية.

آلية الأمان عند بدء التشغيل. يرفض ZTXBAS البدء إذا رُبط ZTXBAS_CONSOLE_LISTEN_ADDR بعنوان غير loopback دون TLS. لا تتجاوز ذلك باستخدام ZTXBAS_ALLOW_INSECURE_CONSOLE=1 إلا إذا:

• كان عنوان الربط داخل الحاوية loopback لكن تعيين منافذ Docker يوصله بعنوان خاص أو loopback فقط على المضيف (كما في الوصفات القياسية)، أو
• كان التشغيل خلف وكيل عكسي ينهي TLS بنفسه، وتحققت من أن الوكيل يزيل رؤوس Authorization وملفات الارتباط الواردة من المسارات غير المصادَق عليها.

لا تضبط ZTXBAS_ALLOW_INSECURE_CONSOLE=1 أبدًا لحاوية يُنشر منفذ لوحتها على 0.0.0.0 دون وكيل أمامها.

7. نظافة إعدادات الوكيل العكسي

إذا كان ZTXBAS خلف Caddy أو nginx أو موازن حمل، فحدد له الوكلاء الموثوقين لنقل عناوين العملاء:

ZTXBAS_TRUSTED_PROXIES=10.0.0.0/8,172.16.0.0/12

الآثار:

• تعمل حدود معدل محاولات دخول المسؤول بحسب IP الحقيقي للعميل، لا عنوان الوكيل.
• تعكس عناوين المصدر في سجلات التدقيق المتصل الحقيقي.
• دون هذا الإعداد، يتجاهل ZTXBAS رأس X-Forwarded-For؛ فقد يسمح قبول رأس مزوّر من طرف غير موثوق بانتحال IP للعميل.

عند الوكيل، أزل كل رؤوس X-Forwarded-* الواردة قبل إضافة رؤوسك. وإلا يستطيع عميل إنترنت الكذب بشأن X-Forwarded-For وتمريره الوكيل. في Caddy:

reverse_proxy ztxbas:8443 {
    header_up -X-Forwarded-For
    header_up X-Forwarded-For {remote_host}
    header_up X-Forwarded-Proto {scheme}
}

8. SMTP

يرفض ZTXBAS البدء دون ضبط SMTP، لأن رسائل التسجيل تمنح المستخدمين رمز QR لربط الأجهزة. وكان الفشل الصامت هنا نمط خطأ موثقًا في الخادم القديم المكتوب بـC.

مطلوب عند بدء التشغيل:

• ZTXBAS_SMTP_HOST وZTXBAS_SMTP_PORT.
• ZTXBAS_SMTP_USER وZTXBAS_SMTP_PASS.
• ZTXBAS_SMTP_FROM.

توصيات:

• استخدم نطاق إرسال مخصصًا (auth.example.com أو noreply-ztxbas.example.com) مع إعداد SPF وDKIM وDMARC. فرسائل التسجيل إلى المستخدمين الجدد من أكثر الرسائل التي تصفيها مزوّدات البريد بدقة.
• فضّل مرحّل رسائل معاملات (Postmark أو SES أو Mailgun أو Postfix داخلي مع DKIM) بدل خدمة بريد استهلاكية مشتركة.
• اختبر المسار كاملًا بعد كل تغيير: أعد إرسال رسالة تسجيل من اللوحة إلى عنوان تجريبي تستطيع متابعة وصولها إلى الصندوق الوارد أو الرسائل المزعجة أو سجل البريد.
• مرّر بيانات اعتماد SMTP عبر أسرار Docker/Kubernetes، لا متغيرات بيئة مكشوفة في ملف compose قد يصل إلى git.

9. الأسرار على القرص

يكتب ZTXBAS ثلاثة ملفات حساسة داخل وحدة تخزين البيانات:

الملف	الغرض	الصلاحيات
ztxbas.db (مع -wal و-shm)	SQLite للتطبيقات والمستخدمين والأصول والتدقيق	0600
jwt-signing.key	مفتاح ES256 الخاص لتوقيع JWT	0600
breakglass.txt (عند التشغيل الأول فقط)	كلمة مرور مسؤول لمرة واحدة	0600 ثم يُحذف

قواعد:

• لا توسّع الصلاحيات عبر chmod للتحايل على مشكلة. إذا لم تتمكن الحاوية من قراءة مجلد بياناتها، فغالبًا أن وحدة التخزين أنشأها مستخدم آخر (انظر القسم 3).
• انسخ مجلد البيانات كله احتياطيًا كوحدة واحدة. يجب إبقاء مفتاح توقيع JWT وحالة SQLite متزامنين؛ فاستعادة أحدهما دون الآخر قد تجعل رموز JWT القائمة غير قابلة للتحقق أو قابلة للتزوير بسهولة.
• كلمة مرور breakglass تُكتب عند التشغيل الأول فقط، وتستخدم مرة واحدة وتنتهي مع أول دخول إداري ناجح. بدّلها فور الدخول ولا تعاملها ككلمة مرور دائمة.

تظهر أسرار HMAC الخاصة بالتطبيقات (المسلّمة إلى RPs) مرة واحدة عند إنشاء التطبيق ولا تعرض لاحقًا. وينبغي أن يحفظها RP في مدير أسراره وألا يودعها في المستودع البرمجي. دوّرها بواسطة:

docker exec ztxbas ztxbas app rotate <app-id>

التدوير حاليًا ذري؛ فيمر RP بنافذة وجيزة يجب خلالها نشر السر الجديد قبل أن يتوقف القديم عن العمل. ويقع التدوير بسرّين مع فترة سماح قابلة للضبط ضمن خارطة الإصدار v1.1.

10. الاستمرارية والنسخ الاحتياطية

يحتفظ SQLite بنمط WAL بكل شيء: التطبيقات والأصول والمستخدمين وسجلات التدقيق وحساب المسؤول ومخزن الجلسات. والنسخ الاحتياطي إجراء على نظام الملفات.

نموذجان مدعومان:

نسخ احتياطي أثناء التشغيل باستخدام sqlite3 .backup. يعمل على قاعدة البيانات الحية دون إيقاف الحاوية:

docker exec ztxbas sqlite3 /var/lib/ztxbas/ztxbas.db \
    ".backup /var/lib/ztxbas/backup.db"

docker cp ztxbas:/var/lib/ztxbas/backup.db ./ztxbas-$(date +%F).db
# Also grab the JWT signing key — see section 9.
docker cp ztxbas:/var/lib/ztxbas/jwt-signing.key ./jwt-$(date +%F).key

شفّر الملفات المخزنة (باستخدام age أو gpg أو أداة النسخ الاحتياطي). مفتاح JWT مفتاح خاص P-256؛ فتعامل معه كمفتاح مضيف SSH.

لقطة دون اتصال. أوقف الحاوية، واحزم وحدة التخزين ثم أعد التشغيل:

docker stop ztxbas
docker run --rm -v ztxbas-data:/data -v $PWD:/backup alpine \
    tar czf /backup/ztxbas-$(date +%F).tgz -C /data .
docker start ztxbas

هذا أبسط، لكنه يسبب بضع ثوانٍ من التوقف لكل نسخة احتياطية.

اختبر الاستعادة كل ثلاثة أشهر على الأقل. فالنسخ الاحتياطي غير المُختبر نية وليس قدرة تعافٍ مؤكدة. شغّل الحزمة في حاوية اختبارية وتأكد من فتح لوحة التحكم وعرض التطبيق والتحقق من JWT جديد بالمفتاح المستعاد.

11. التسجيل والمراقبة

يكتب ZTXBAS JSON منظّمًا إلى المخرج القياسي stdout، ويمكن لـjournald وdocker logs وLoki وناقلات SIEM قراءته مباشرةً.

مثال على سطر سجل:

{"time":"2026-01-15T10:04:11.812Z","level":"WARN","msg":"hmac.verify.fail",
 "app_id":"app_a1b2c3d4e5","reason":"timestamp_skew","skew_sec":312}

حقول أو أحداث يستحسن التنبيه عليها:

• hmac.verify.fail بمعدل مرتفع لـapp_id واحد ← احتمال تفاوت الساعة أو تسرب سر وتدويره.
• admin.login.fail بمعدل مرتفع من IP واحد ← محاولة تخمين كلمات المرور على اللوحة.
• challenge.expired بمعدل مرتفع ← تدهور وصول إشعارات الهاتف أو تعذر وصول الهواتف إلى 9443/udp.
• smtp.send.fail بأي معدل ← عدم وصول رسائل التسجيل للمستخدمين بصورة صامتة.

يعيد GET /health حالة حياة الخدمة وإصدارها. وهو لا يفحص عمدًا الخدمات اللاحقة (SMTP أو ztxlib)، لأن فحصًا يفشل أثناء عطل جزئي قد يخرج مثيلات سليمة من الخدمة. استخدم تنبيهات السجلات المنظمة للأعطال اللاحقة.

12. تحديد معدل الطلبات

الإعدادات الافتراضية مناسبة لنشر بمثيل واحد:

• المسارات العامة: حد لكل تطبيق مع سماح بدفعات مؤقتة. إن إنشاء مئة تحدٍ في الثانية من تطبيق واحد يدل على استخدام غير صحيح أو هجوم، وفي الحالتين يفيد خفض المعدل.
• المسارات الإدارية: حد أضيق لكل IP عميل. وتُقيّد محاولات الدخول بقوة كذلك لكل اسم مسؤول.

يمكن زيادة حد المسارات العامة للتطبيقات عالية الحجم، وربما لا ينبغي خفض حد الإدارة. يُضبط كلاهما عبر متغيرات البيئة الموثقة في deploy/README.md.

إذا وضعت WAF أمام ZTXBAS (مثل Cloudflare أو AWS WAF)، فإنها تصبح طبقة إضافية لضبط الحركة؛ وتظل حدود ZTXBAS المدمجة دفاعًا داخليًا لا أساسيًا.

13. الترقيات

1. اقرأ ملاحظات الإصدار. عمليات الترحيل تُضاف دون تعديل السابقة، لذا تدعم الترقيات؛ لكن الرجوع إلى إصدار أقدم غير مدعوم لأن عملية ترحيل حديثة قد تضيف أعمدة لا يعرفها الإصدار السابق.
2. تحقق من وسم الإصدار الجديد بـcosign باستخدام cosign.pub الموثوق نفسه.
3. نفّذ docker pull لبصمة الصورة الجديدة، ثم انسخ وحدة تخزين البيانات احتياطيًا (القسم 10).
4. شغّل docker compose up -d؛ فتستخدم الحاوية الجديدة وحدة التخزين وتشغّل أي عمليات ترحيل جديدة عند البدء.
5. راقب السجلات لبدء نظيف واستجابة جديدة من /health تحتوي حقل version الجديد.

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

14. الاستجابة للحوادث

تسرب سر HMAC لتطبيق.

docker exec ztxbas ztxbas app rotate <app-id>

انشر السر الجديد في تهيئة RP. تظل التحديات الجارية التي أُنشئت بالسر القديم صالحة، لأنها مرتبطة بمعرّف التحدي والأصل لا بسر HMAC لدى RP، لكن أي طلب API جديد بالسر القديم يفشل مباشرةً.

تسرب مفتاح توقيع JWT. يوجد المفتاح في jwt-signing.key داخل وحدة البيانات. والتدوير يدوي ومسبب للانقطاع في v1:

docker stop ztxbas
docker exec -u root ztxbas rm /var/lib/ztxbas/jwt-signing.key   # or delete via the host mount
docker start ztxbas

ينشأ مفتاح جديد عند التشغيل ويُنشر عبر /.well-known/jwks.json تحت kid جديد. تصبح كل رموز JWT الصادرة بالمفتاح القديم غير قابلة للتحقق؛ فنقطة JWKS لا تنشر إلا المفتاح المحمّل حاليًا، لذا قد ترى تطبيقات RP التي جلبت JWT خلال الدقائق الخمس الأخيرة إخفاقات تحقق أثناء النقل. افترض اختراق جميع الجلسات الصالحة حاليًا وسجّل خروج المستخدمين لدى RP.

تقع آلية تدوير JWKS متعددة المفاتيح مع فترة تداخل آمنة ضمن خطة v1.1.

تسرب كلمة مرور breakglass. هي لمرة واحدة وتنتهي عند أول تسجيل دخول. وإذا تسربت قبل استخدامها، فإن docker exec ztxbas ztxbas admin reset-password --user admin يولد كلمة جديدة ويلغي كل الجلسات القائمة.

اشتباه اختراق جلسة مسؤول. من اللوحة: Account → Sessions → Revoke all other sessions. ثم دوّر كلمة مرور المسؤول. وتحتفظ سجلات التدقيق بمعرّفات الجلسات وعناوين IP المصدرية.

اشتباه اختراق جهاز محمول (إبلاغ عن فقدان الهاتف).

# From the RP side, using an SDK — or from the console under Users.
curl -X DELETE https://ztxbas.example.com/v1/users/<user-id> ...

يُلغى تسجيل المستخدم بصورة ذرية، وتصبح مفاتيح جهازه غير مفيدة فورًا مقابل ZTXBAS. أعد تسجيله بجهاز جديد ضمن إجراء استرداد الحساب الخاص بك.

15. النشر في بيئات معزولة تمامًا

تعمل المكونات جميعها. فلا اتصال إجباري بالخارج أو خادم تراخيص أو قياس عن بُعد أو تحديثات مفروضة. التغييرات المطلوبة:

• توزيع الصورة. انسخ ghcr.io/corezt/ztxbas إلى سجل حاويات داخلي؛ تحقق من cosign عند إدخالها ثم أعد وسمها داخليًا.
• TLS. لن يعمل ACME التلقائي؛ استخدم سلطة شهادات داخلية وملفات PEM ثابتة (ZTXBAS_TLS_CERT/_KEY، القسم 5).
• SMTP. استخدم مرحّل Postfix أو Exchange داخليًا.
• الوقت. وجّه Chrony إلى خادم NTP الداخلي. تفاوت الطابع الزمني لـHMAC محدود؛ وقد تؤدي ساعة خاطئة إلى فشل تدفق RP مبكرًا وبصورة صامتة.
• توزيع SDK. يمكن جلب حزمة Go عبر GOPROXY؛ بينما تحتاج حزم Node وPython إلى مرآة داخلية أو تضمين الاعتماديات لدى RPs خلف العزل.

16. ما الذي لا يفعله ZTXBAS عمدًا؟

إذا احتجت إحدى القدرات التالية، فإن ZTXGate هو منصة الوصول الأوسع؛ ويمكن استخدام تطبيق الهاتف نفسه، بينما تُدمج قدرة ZTXBAS المرخّصة داخل ZTXGate بدل نشر خادم ZTXBAS منفصل:

• SSO أو SAML أو OIDC للمسؤولين.
• أدوار RBAC للمسؤولين تتجاوز حسابًا واحدًا.
• توفير مستخدمين عبر SCIM.
• إثبات حالة MDM بوصفه عاملًا.
• تصدير SIEM بأكثر من نقل سجلات stdout.
• عزل متعدد المستأجرين.
• وصول أوسع للشبكة تحكمه السياسات عبر مسار ZTXGate المعتمد على العميل، بما فيه خدمات غير الويب مثل SSH وRDP، إضافة إلى HTTP/HTTPS دون عميل لتطبيقات الويب المدعومة.

محاولة إضافة هذه الوظائف إلى ZTXBAS تخرجه عن تصميم «عملية واحدة، وظيفة واحدة» وتفضي إلى صيانة نسخة متفرعة قديمة بلا نهاية. انتقل بدلًا من ذلك إلى ZTXGate؛ فتطبيق الهاتف الذي يستخدمه مستخدموك مناسب بالفعل.