الوضع

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

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

النُهج التي لا تصمد تمامًا

هناك أربعة نُهج شائعة، ولكل منها دوره. كما أن لكل منها حدودًا يجب الاعتراف بها بصراحة.

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

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

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

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

ليس أي منها خاطئًا في كل الحالات. لكنها خاطئة كحل عام لمشكلة الوصول المتعدد الأطراف على منصة مشتركة.

النموذج ذو الطبقتين

يقسم نهجنا عملية التفويض إلى طبقتين مستقلتين تشكلان النظام.

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

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

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

لماذا يُعدّ التطبيق على مستوى الحقول من جانب الخادم أمرًا مهمًا

يتم تطبيق قيود الأدوار على الخادم قبل أن تغادر البيانات قاعدة البيانات. وهذا هو الجزء المهم من الناحية العملية:

ينطبق الفلتر على كل مسار استعلام — صفحات التفاصيل، وعروض القوائم، وطلبات واجهة برمجة التطبيقات (API)، وعمليات التصدير الجماعي، ومربعات الخرائط.
يحصل المستخدم الذي يكتب معرّف سجل يعرفه في عنوان URL على خطأ ٤٠٤ Not Found، لأن السجل غير موجود بالفعل بالنسبة له.
لا فائدة من لقطة شاشة مأخوذة من شاشة مستخدم آخر؛ فلن يتم تحميل البيانات عندما يحاول المستخدم المحظور الوصول إليها.
ترث الميزات الجديدة تطبيق القواعد تلقائيًا، لأنها تمر عبر نفس طبقة بيانات الخادم.

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

مثال توضيحي

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

أنشئ دورًا باسم المقاول أ مع قيد واحد:

النموذج: Point
الحقل: owner
المقارنة: =
قيمة التصفية: Contractor B
الأذونات المحظورة: القراءة، التعديل، الإنشاء، الحذف

أضف مستخدمي المقاول أ كأعضاء. قم بإجراء نفس الإجراء بالنسبة لـ المقاول ب. هذه هي التهيئة بأكملها.

تستطيع فرق المقاول «أ» الآن رؤية نقاطها الخاصة والطبقات المشتركة، دون أن تظهر لها أي بيانات تخص المقاول «ب». وإذا فتحوا قائمة بالنقاط، فلن تظهر فيها سجلات المقاول «ب». وإذا قاموا بالتصدير إلى ملف CSV، فسيتم تصفية البيانات. وإذا حاولوا تخمين الرقم التعريفي (ID) لأحد نقاط المقاول «ب» ولصقوه في عنوان URL، فسيحصلون على خطأ ٤٠٤ Not Found. ويواجه المقاول «ب» الوضع المعاكس تمامًا. لا يعرف أي من الطرفين حجم العمل الذي أنجزه الطرف الآخر، أو مكانه، أو متى تم تحديثه.

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

متى يكون وجود مستأجرين منفصلين هو الحل الأمثل

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

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

ملخص

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