اختبار Entra Application Proxy: وين تنتهي حماية السحابة وتبدأ ثقة التطبيق الداخلي والموصل؟

التطبيق صار خلف إنترَا ويطلب تسجيل دخول، فهل انتهى اختبار المصادقة والتفويض؟ لا زالت عندك رحلة فيها خدمة نشر وموصل وخادم داخلي وجلسة تطبيق وقرار على كل عملية. الحماية عند أول البوابة مهمة، لكنها ما تجيب عن كل سؤال داخل التطبيق.

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

اختبار التطبيق يبدأ من خريطة الرحلة

ابدأ بالعنوان الخارجي الذي يستخدمه موظف اللاب، والتطبيق المؤسسي الذي يحكم النشر، ومجموعة الموصلات، والعنوان الداخلي، وطريقة تسجيل الدخول الموحد عند الخادم. هذه العناصر تحدد من يستقبل الطلب ومن يثبت الهوية ومن يفوض العملية.

Application Proxy
Private Network Connector
Backend Application

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

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

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

المصادقة المسبقة والتفويض داخل التطبيق مرحلتان

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

Preauthentication
Application Authorization

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

وبالعكس، رفض الحساب قبل وصوله للخادم يثبت حد البوابة في تلك الحالة، لكنه ما يختبر تفويض التطبيق للحسابات التي تعبرها. تحتاج مسارًا مصرحًا به بهوية معروفة يجيب عن السؤال الداخلي. فصل المرحلتين يجعل النتيجة دقيقة ويمنع الاكتفاء بتسجيل دخول ناجح أو شاشة رفض واحدة.

طريقة النشر تحدد أي حماية تتوقعها

اقرأ طريقة المصادقة المسبقة الفعلية للتطبيق، ولا تعتمد على أن اسم الخدمة يحمل إنترَا. تصميم يمرر الطلب ليعتمد على مصادقة التطبيق يختلف عن تصميم يفرض تحققًا سحابيًا قبله. التوقع الأمني لازم يطابق الإعداد المستعمل، وليس ميزة متاحة في المنتج.

Passthrough
Microsoft Entra Preauthentication

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

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

الموصل جسر يحتاج حدود شبكة وإدارة واضحة

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

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

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

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

إذا كانت الهوية تأتي في Headers، من يحق له إرسالها؟

بعض التطبيقات الداخلية تفهم الهوية من رؤوس تضيفها طبقة وسيطة موثوقة بعد تحقق المستخدم. في هذا التصميم، مصدر الرأس جزء من حد الثقة، وليس قيمة المستخدم فقط. التطبيق يحتاج أن يقبل هذه المعلومة من المسار المعتمد وفق ضوابط نشره.

Header-based SSO
HTTP Headers

راجع إعداد تعيين السمات والتحويلات مع مالك التطبيق، ثم قيود الوصول إلى الخادم الذي يعتمد تلك الرؤوس. وجود دعم أصلي لهذه الطريقة أو تكامل بديل لا يجعل كل تطبيق يطبق نفس الضوابط من نفسه. افحص التصميم الحالي والوثيقة التي تخصه.

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

الملاحظة الجيدة تشرح مَن يثبت الهوية ومَن ينقلها ومَن يثق بها. عبارة «يستخدم هيدر» وحدها ما تعني ثغرة؛ هذا نمط له حدود يجب أن تتحقق، مثل أي تكامل هوية آخر.

تعيين السمة يحتاج أن يطابق هوية التطبيق

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

في المثال، حساب التدريب في الدليل له معرف ثابت، بينما التطبيق يحتفظ باسم دخول قديم. اطلب من المالك شرح قواعد المطابقة والتغير عند نقل الموظف أو تغيير اسمه. لا تختبر ذلك بتعديل هوية موظف حقيقي؛ يجهز المسؤول حسابين وبيانات خاصة باللاب.

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

لا تسمِ كل اختلاف اسم انتحالًا. قد يكون هناك تحويل مشروع يوثق النظام، أو سجل قديم أو حساب تطبيق مختلف. تحتاج ربطًا بين المعرفات والعملية، لا صورة اسم عرض. وهذه القراءة تساعد أيضًا في منع توصية تغير حقلًا يعتمد عليه تطبيق آخر دون دراسة.

تفويض Kerberos يحتاج مراجعة الغرض والنطاق

تطبيق يستخدم مصادقة ويندوز المتكاملة قد يعتمد على تفويض مقيد ينفذه الموصل ضمن تسجيل الدخول الموحد. هنا تدخل علاقة بين هوية المستخدم وخدمة داخلية وحساب أو جهاز مسؤول عن التفويض. لا تفترض أن وجود هذا المسار يمنح قدرة عامة على كل خدمات الدليل.

Kerberos Constrained Delegation
KCD
SPN

في المراجعة، اطلب من المسؤول إعداد الخدمة المقصودة ومطابقة اسمها وهويتها ونطاق التفويض المعتمد. راجع أن العلاقة تبرر ما يحتاجه التطبيق المنشور، وأن حساب إدارة الموصل مناسب لوظيفته. قراءة الإعداد والسجلات قد تكفي لفحص التصميم دون طلب تذكرة باسم شخص آخر.

إذا فشلت العملية، افصل المصادقة عند البوابة عن خطوة التفويض وعن قبول التطبيق. خطأ واحد في النهاية قد يكون من ربط الهوية أو الخدمة أو إعداد الخادم، لا دليلًا على أن كل تفويض آمن أو غير آمن. لا تنفذ أوامر تهيئة جديدة على الدليل داخل اختبار قراءة؛ يملك الفريق المختص تغييرات هذا المسار.

ولمن يتدرب على الدليل النشط، هذه زاوية تربط السحابة بالخدمة الداخلية بطريقة مهنية: تعرف من يستطيع ماذا ولأي خدمة، وتحدد الأدلة التي تثبت ذلك قبل أي اختبار أثر.

مسار URL جزء من الحد، وليس زخرفة في العنوان

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

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

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

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

الجلسة الداخلية تحتاج اختبارها الخاص

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

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

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

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

اجمع الدليل من الطرف الذي اتخذ القرار

نجاح سجل إنترَا يخص المرحلة السحابية. وسجل الموصل يفسر الربط والطلب الداخلي بحسب المتاح. وسجل التطبيق يوضح هوية الجلسة وقرار المورد. اجمع منها ما يحتاجه السيناريو فقط، واربطها بوقت الطلب ومعرفه والهوية التدريبية.

لو ظهر رفض، لا تكتفِ برمز حالة واحد في المتصفح. قد يكون صادرًا من طبقة وسيطة أو من التطبيق، ولكل واحد معنى مختلف. اطلب من المسؤول جزء السجل الذي يفسر الحدث، ثم قارنه بالحالة المرجعية التي كانت تعمل.

في التقرير، ارسم الرحلة بالكلمات أو جدول العلاقات: طرف يثبت الهوية، وآخر يمررها، وثالث يفوض العملية. هذا يجعل الملاحظة واضحة للهوية والشبكة والتطبيق معًا. لا يحتاج مرفقًا ضخمًا يحتوي كل عناوين الخوادم أو رموز المصادقة.

ولو لم تتوفر سجلات أحد الأطراف، قل أين توقف التحقق. عبارة «الطلب وصل للموصل» تحتاج دليلًا من ذلك الطرف أو من العملية، بينما ظهور الصفحة قد لا يعزل كل خطوة. وصف الثقة في الأدلة أفضل من إضافة تفاصيل تتوقع أنها حدثت لكن لم ترصدها.

من الفجوة إلى توصية يقدر كل فريق ينفذها

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

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

قسّم المعالجة بحسب المالك: الهوية تضبط التعيين والسياسات، والشبكة تضبط حد الخادم، والتطبيق يضبط تفسير الهوية والتفويض، وفريق المنصة يراجع الموصل. مو كل نتيجة تحتاج تغييرًا في الأربع جهات، لكن كل نتيجة تحتاج أن تعرف من يملك سببها.

بعد المعالجة، أعد نفس عملية اللاب والحالة المشروعة. ما يكفي أن الصفحة صارت تطلب دخولًا؛ نريد أن المورد المقصود يقبل الشخص المناسب ويرفض الحالة خارج التوقع، وأن الرحلة التي راجعتها ما تغيرت دون توثيق.

مصادر رسمية وما تكمل به المنهجية

توجد طرق تسجيل دخول موحد متعددة، فراجع الوثيقة التي تخص الطريقة الموجودة في بيئتك. خطة المقارنة هنا مثال تعليمي، وليست وصفًا لثغرة ثابتة في بروكسي التطبيقات.

Application Proxy overview
https://learn.microsoft.com/en-us/entra/identity/app-proxy/overview-what-is-app-proxy

Security considerations
https://learn.microsoft.com/en-us/entra/identity/app-proxy/application-proxy-security

Native header-based SSO
https://learn.microsoft.com/en-us/entra/identity/app-proxy/application-proxy-configure-single-sign-on-with-headers

KCD for SSO
https://learn.microsoft.com/en-us/entra/identity/app-proxy/how-to-configure-sso-with-kcd

ولقراءة السياسة السحابية التي قد تحكم أول مرحلة، ارجع لهذا الشرح:
https://courses.cyberpts.com/community/153/akhtbar-conditional-access-fy-entra-lysh-aldkhwl-ynjh-walsyash-tqwl-failure-afhm

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