نطاقات فرعية مشتركة ومدخلان: من يرى أي سجلات؟

تتقاسم العيادة A والعيادة B قاعدة شيفرة واحدة ونطاقين فرعيين ومزيجًا من الزوار من المكتب ومن VPN. جرت العادة أن يهيّئ فريق الشبكة المدخلين كلًا على حدة، وهذا مقبول ما دام التطبيق لا يفعل ذلك. الفحوص أدناه مكانها التطبيق، ويجب أن تتصرف بالطريقة نفسها أيًا كان الباب الذي استخدمه الطلب.

أولًا: اسم المضيف لا يسمّي إلا مستأجرًا

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

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

ثانيًا: العضوية تأتي من الجلسة

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

اختبر الحالة السلبية بتعديل معرّف سجل ومعامل مستأجر. إذا أعاد أي من التعديلين بيانات، فالنطاق يُقرأ من الطلب لا من العضوية الموثقة.

نطاق الكوكيز وتسجيل الدخول الموحد يحددان أين يمكن تقديم الحساب. ولا يحددان ما يجوز لذلك الحساب قراءته.

ثالثًا: الشبكة لا تثبت شيئًا عن الشخص

بوابة VPN توثق نفقًا، وقائمة سماح عامة توثق نطاق عناوين. ولا واحدة منهما تحدد هوية شخص. NAT يجمع كثيرًا من المستخدمين في عنوان مصدر واحد، ونطاق المكتب يفعل الشيء نفسه لكل من في المبنى. تعامل مع الاثنين كوقائع نقل، وأبقِ التخويل في التطبيق، أو في تكامل يصرّح بالهوية صراحة ويُراجع على هذا الأساس.

DNS واقعة نقل ثالثة. الجواب الخاص يحتاج مسارًا خاصًا، والواجهة الأمامية العامة تحتاج مسار أصل مدعومًا. ولا واحد منها يحمل إذنًا.

جملة واحدة تُعلّق على الحائط: الشبكة تقرر كيف يصل الطلب، والتطبيق يقرر ما يجوز قراءته.

رابعًا: شغّل المصفوفة على المدخلين

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

curl -s -o /dev/null -w '%{http_code}' -b jar.txt https://clinic-b.example.com/records/42
curl -s -o /dev/null -w '%{http_code}' -b jar.txt https://clinic-a.example.com/records/42

ثم عدّل مدخلًا في قائمة السماح وأعد التشغيل. النتيجة التي تتغير تعني أن ضابطًا شبكيًا يتخذ قرار تخويل.

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