إعداد نشر تطبيقات الثقة الصفرية

يوفر نشر التطبيقات نقطة وصول عبر مجموعة وكلاء ويمرر الطلبات إلى أهداف مهيأة. يجب إعداد المجموعة والخدمة المنشورة والتطبيق المستهدف وقيود الوصول والتحقق منها منفصلة. لا يثبت إنشاء الخدمة اتصال الوكلاء أو تحليل DNS أو توفر الشهادة أو إمكانية الوصول للهدف.

التحضير

• استخدم حساب مسؤول أعلى يملك صلاحيات الثقة الصفرية اللازمة. قد تختلف صلاحيات العرض والإنشاء والتعديل والحذف.
• أكد مع مسؤولي الشبكة والتطبيق نطاق الوصول ونشر الوكيل وبروتوكول الهدف ومنفذه والشهادات والأشخاص أو الشبكات المسموح بها. ابدأ بتطبيق اختبار ونطاق مضبوط واحصل على موافقة التغيير المطلوبة.
• جهز عقدا أو موارد شبكة حسب الهدف. لتقييد عقد خدمة HTTP خاصة، أنشئ أو اختر مجموعة في التحكم بالوصول وافتح تفاصيلها واستخدم «Add Endpoints» لإضافة عقد الاختبار المصرح بها. راجع المراجع الأخرى قبل تعديل مجموعة موجودة.
• راجع السياسات والمسارات وجدار الهدف ومسار العودة اللازم. للمجموعات ومصادقة الخدمة وسياسات الشبكة أدوار مختلفة؛ حفظ أحدها لا يثبت اختبار الوصول من الطرف إلى الطرف.

إنشاء مجموعة وكلاء

1. افتح مجموعات الوكلاء ضمن نشر تطبيقات الثقة الصفرية واختر «Create Proxy Cluster».
2. أدخل الاسم والنطاق العام واحفظ. يجب مطابقة النطاق العام لإعداد نشر الوكيل؛ أكد تخطيط النطاق وDNS والشهادات مع المسؤولين.
3. تعامل مع رمز المجموعة حسب الصفحة. يعرض الرمز مرة واحدة فقط عند الإنشاء. انقله بأمان للمخولين بالنشر، ولا تضعه في مستندات أو محادثات أو تذاكر عادية.
4. انشر مثيلات الوكيل وفق الإجراء المعتمد ثم راجع المثيلات المتصلة والقدرات. عند انتظار تقرير مثيل متصل لا تفترض توفر الخدمة الخاصة أو المنافذ المخصصة. إنشاء المجموعة لا يجعل المثيل متصلا.

إنشاء خدمة النشر والأهداف

1. افتح الخدمات المنشورة واختر «Create Published Service». اختر المجموعة وأدخل الاسم ونطاق النشر ووضع الوكيل HTTP أو TCP أو UDP أو TLS، وتحقق من النطاق حسب متطلبات النشر.
2. في الأوضاع غير HTTP اختر طريقة تخصيص المنفذ وراجع منفذ الاستماع. يعتمد المنفذ المخصص على قدرات المجموعة المبلّغ عنها؛ افحص الجدار وتعارض المنافذ.
3. أضف هدفا بنوع «Endpoint» أو «Network Resource» أو «Proxy Host Direct». عند اختيار جهاز أو مورد اختر الكائن المقابل أيضا؛ إذا تعذر استخدامه فافحص حالته ومراجعه.
4. أدخل العنوان وراجعه مقابل بروتوكول الخلفية ومنفذها. يستخدم HTTP عنوان http:// أو https:// ومسارا عند الحاجة؛ تطلب الأوضاع الأخرى المضيف والمنفذ. عند الإشارة إلى جهاز أو مورد محدد، راجع الكائن والهدف المعروض ولا تعامل اسم المضيف المثال كترخيص مستقل.
5. أضف أهدافا أخرى عند الحاجة وراجع الكائن والعنوان والمنفذ والخدمة لكل منها. أمثلة الصفحة للتنسيق ولا تضمن الوصول. في خدمة HTTP، يجب أن يبدأ مسار كل هدف بـ / وألا يتكرر داخل الخدمة؛ ويمكن استخدام المسار الافتراضي / مرة واحدة فقط. قبل إضافة عدة أهداف، خطط لمسارات مختلفة مثل /reports و/sales، وتحقق من إعادة التوجيه لكل مسار. إذا فشل الحفظ فتحقق من تكرار /.

حد الأمان في Proxy Host Direct: توضح الصفحة أن مضيف الوكيل يصل إلى الهدف مباشرة دون توجيه الثقة الصفرية أو التحكم بالوصول أو عزل الشبكة المحلية؛ لا يجوز أن يكون الهدف عنوان loopback أو link-local أو multicast. قيّم منفصلا نطاق وصول الوكيل والجدار وحماية الهدف ولا تفترض أن ضوابط الشبكة تلك ما زالت تقيد هذا المسار. عندما يكون الهدف اسم مضيف، لا يعني نجاح الحفظ أن كل عنوان يحلّه الوكيل فعليًا مسموح للاتصال. قد يُرفض الاتصال إذا أعطى التحليل عنوانًا مقيّدًا مثل عنوان الإرجاع المحلي أو الرابط المحلي أو الإرسال المتعدد. تحقق من تحليل الاسم وإمكانية الوصول إلى الهدف من بيئة مضيف الوكيل، وأعد الاختبار بعد تغيير DNS؛ لا تحاول تجاوز القيود بتغيير الاسم.

طريقة وصول خدمة HTTP

تقدم صفحة مصادقة HTTP أساليب مختلفة؛ حدد الجمهور ومتطلبات الأمن قبل الاختيار:

1. Zero Trust Network Only: تحقق من وجود مثيلات متصلة وتفعيل وضع الوكيل الخاص ودعم الخدمة الخاصة. فعّل الخيار واختر مجموعة وصول مجهزة واحدة على الأقل. تقول الصفحة إن الوصول يقتصر على العقد المتصلة والمطابقة للمجموعة؛ اختبر العقد المطابقة وغير المطابقة.
2. غير الوضع الخاص: اختر «No Authentication» أو PIN أو «Password». عند الإنشاء أو التحويل إلى PIN أو كلمة مرور أدخل بيانات الاعتماد؛ يتكون PIN من ستة أرقام. اضبط مدة الجلسة وفق متطلبات المؤسسة واحفظ وانقل الأسرار بأمان. قبل اختيار عدم المصادقة قيّم التعرض والمخاطر ولا تفترض اشتراط مصادقة المستخدم تلقائيا.
3. اختيار مجموعة الخدمة الخاصة ومصادقة PIN أو كلمة المرور للخدمة غير الخاصة طريقتان مختلفتان. بعد التبديل تحقق من الخيارات والمسموح لهم والوصول الفعلي. لا تعرض أوضاع غير HTTP صفحة المصادقة هذه؛ لا تفترض توفير الحماية نفسها تلقائيا.

عند اختيار مصادقة PIN أو كلمة المرور أو التبديل إليها، تضبط الصفحة مدة جلسة الدخول على 86400 ثانية (24 ساعة). النطاق المقبول من 60 إلى 604800 ثانية (دقيقة إلى 7 أيام). هذه قيمة أولية عند التبديل وليست بالضرورة إعداد خدمة موجودة حاليًا. اضبطها واحفظها وفق متطلبات المؤسسة، وأعد التحقق من بيانات الاعتماد والمدة بعد تغيير طريقة المصادقة.

إعداد القيود والتحقق

1. في «Access Control» أدخل «Allowed CIDRs» و«Blocked CIDRs» حسب متطلبات المؤسسة، وراجع مهل الهدف والتمرير والخيارات في الإعدادات المتقدمة. لا تستنتج النتيجة من قائمة واحدة؛ اختبر النشر الفعلي.
2. تحقق من شهادة الخدمة المستهدفة ومتطلبات الاتصال. تعرض الصفحة خيار تجاوز فحص TLS للخلفية لشهادة موقعة ذاتيا يتعذر فحصها في شبكة داخلية مضبوطة. قيّم الأمن قبل التفعيل ولا تجعله إجراء إصلاح افتراضيا.
3. قبل الحفظ راجع المجموعة والنطاق والأهداف والمصادقة والمجموعات وقيود الشبكة. بعد الحفظ تحقق من التفعيل وحالة التشغيل. انتظار الوكيل أو عدم إنشاء النفق أو حالة شهادة لا تعني إتاحة الخدمة.
4. من عميل مخول اختبر DNS والمنفذ والشهادة والمصادقة والتطبيق، ثم اختبر القيود من عميل غير مخول. للوصول الخاص اختبر عقدا مطابقة للمجموعة وأخرى غير مطابقة.
5. راجع سجل الخدمة وسجلات التدقيق لمطابقة الخدمة والوقت. السجلات أدلة للمراحل المسجلة ولا تستبدل اختبارات الوصول والأمان الفعلية.

مثال CIDR: عندما لا تكون قائمة السماح فارغة، يجب أن يطابق عنوان المصدر إدخالًا واحدًا على الأقل؛ وإذا طابق قائمة الحظر أيضًا يُرفض. لا تقيّد قائمة السماح الفارغة المصادر بذاتها، لكن قد تستمر قائمة الحظر والضوابط الأخرى في السريان. مثلًا، عند السماح بـ 10.20.0.0/16 وحظر 10.20.5.0/24 يجتاز 10.20.4.10 فحصي CIDR هذين، ويُرفض 10.20.5.10 لمطابقته الحظر، ويُرفض 10.21.4.10 لخروجه عن نطاق السماح. العناوين أمثلة فقط. قد تؤثر الوكلاء السابقون أو ترجمة عناوين الشبكة في عنوان المصدر الذي يتعرف عليه الوكيل؛ تحقّق منه واختبره في بيئة النشر. لا يضمن اجتياز CIDR تحقق المصادقة أو مجموعة الوصول أو شروط الخدمة المستهدفة.

تفسير عمود المصادقة: في وصول HTTP قد تتأثر حالة النجاح أو الفشل المعروضة بحالة استجابة HTTP؛ فقد تظهر 401 أو 403 كفشل، بينما قد تظهر حالات أخرى، بما فيها أخطاء الخدمة، كنجاح. في السجلات غير المستندة إلى HTTP مثل TCP أو UDP أو TLS، لا يعني عرض الفشل بالضرورة فشل مصادقة مستخدم. قارن طريقة مصادقة الخدمة ورمز الاستجابة ومصدر الوصول وسجلات التطبيق المستهدف ضمن اختبار مضبوط؛ لا تستنتج نجاح المصادقة أو فشلها أو هوية المستخدم من هذا العمود وحده. التسميات المقابلة في الواجهة الإنجليزية هي Authentication وSuccess وFailed.

التغيير ومعالجة المشكلات

• تعذر الحفظ: افحص المجموعة والاسم والنطاق وكائن الهدف وتنسيق العنوان؛ افحص منفذ غير HTTP، ولـ HTTP الخاص افحص المثيل والقدرات ومجموعة واحدة على الأقل وPIN المطلوب.
• أنشئت ولا يمكن الوصول: افحص التفعيل والتشغيل والوكيل وDNS والمنفذ والجدار والشهادة والهدف والمسار منفصلة.
• المصادقة أو الوصول غير متوقع: راجع الوضع الخاص أو المصادقة والمجموعات والشبكات المسموح بها والمحظورة والسياسات الأخرى وحماية الهدف؛ اختبر المسموح والمرفوض.
• التعديل أو التعطيل أو الحذف: راجع المراجع والمستخدمين واعتماد الأعمال، وسجل الإعدادات واتبع التصريح؛ أعد فحص الحالة والقيود والعمل بعد التغيير. تعامل مع الرموز والأسرار عبر قناة آمنة.