الخلاصة

  • تنص RFC 9670 على نموذج مشترك للـ Principal وShareNotification والمشاركة، لكنها تترك إدارة الهويات ومعنى الحقوق التفصيلي لكل نطاق ونوع بيانات.
  • لا يكفي نجاح تعديل shareWith؛ يجب إثبات هوية الجهة، وقراءة myRights من جانب المستلم، وسياسة الإشعار، والعملية الفعلية، وحدود الإلغاء والنسخ المحتفظ بها.

ابتعد الموظف عن حاسوبه وهو مفتوح لدقائق. أضاف شخص آخر Principal يسيطر عليه إلى shareWith في مورد حساس. أعاد الخادم نتيجة /set ناجحة وانتقلت state. انتهى الوصول المادي القصير، لكن حق القراءة استمر بعده.

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

المشكلة هنا ليست أن البروتوكول قبل صيغة خاطئة. المشكلة أن حقيقة صحيحة في control plane ــ حفظ خريطة مشاركة ــ أُعطيت معنى «قرار مقصود وآمن» لم تثبته.

Principal ليس مجرد اسم في قائمة

يمكن أن يمثل Principal فرداً أو مجموعة أو موقعاً أو مورداً مثل غرفة أو جهاز. وقد يرتبط بصفر أو أكثر من Accounts. تضيف قدرات RFC 9670 روابط إلى Principal المستخدم الحالي وإلى Principal المالك للـ Account.

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

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

أما مالك الـ Account فحقوقه ضمنية ولا يوضع في shareWith. غيابه عن الخريطة ليس غياباً عن السلطة.

التعيين والحق الحالي والتنفيذ ثلاث طبقات

يجب أن يعرّف كل نوع بيانات قابل للمشاركة ثلاث خصائص: shareWith وmyRights وisSubscribed.

تربط shareWith معرّفات Principals بخرائط حقوق. تعرض myRights ما يملكه المستخدم الحالي على الكائن. وتعبّر isSubscribed عن رغبة المستخدم في إدراج المورد في تجربته اليومية.

لا تحدد RFC 9670 ما الذي يمكن مشاركته ولا درجة تفاصيل الحقوق. نوع البيانات نفسه يعرّف المفاتيح ودلالتها. لذلك لا يجوز اختزال حق قراءة أو تعديل أو إدارة في علم موحد باسم «access».

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

هذه الفروق مهمة في التحقيق: «لم يظهر» لا يساوي «مُنع»، و«ظهر الحق» لا يساوي «نجحت العملية».

state تمنع محو قرار منافس

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

يوفر RFC 8620 الوسيط ifInState. يقبل الخادم التغيير فقط إذا ظل نوع البيانات في state التي اعتمد عليها العميل؛ وإلا يعيد stateMismatch. وتفصل استجابة /set بين updated وnotUpdated وتعيد oldState وnewState.

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

نجاح state لا يحوّل الاختراق العابر إلى قرار شرعي. إنه يثبت فقط أن الكتابة لم تصطدم بتغيير معروف آخر.

الإشعار قابل للتجميع والحذف

ينشئ الخادم ShareNotification لتسجيل تغيّر حقوق مستخدم على كائن. يتضمن الكائن الحقوق القديمة والجديدة، ونوع الكائن وAccount وID والوقت وchangedBy. وقد يكون principalId للجهة المغيّرة null.

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

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

الإلغاء يمنع طلبات جديدة ولا يمحو الماضي

عند اكتشاف المشاركة الضارة، يجب حذف Principal باستخدام شرط state، وقراءة shareWith وmyRights مجدداً، وتجربة طلب جديد بصفته. عند رفضه يمكن القول إن السلطة الحية في الخدمة أُغلقت ابتداءً من generation وزمن محددين.

لا يثبت ذلك اختفاء ملف صُدّر أو نسخة خُزنت أثناء سريان الحق. RFC 9670 لا تنظم محو النسخ غير المتصلة. يجب فصل «منع عمليات جديدة» عن «استرجاع البيانات» في تقارير الحادث.

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

سلسلة الثقة تبدأ من هوية Principal، ثم ملكية الكائن، ثم mutation مشروطة، وقراءة ثنائية، وسياسة إشعار، وعملية تشغيل، وإلغاء محدود النطاق. لا يجوز لأي خطوة أن تستعير نتيجة التالية.

المصادر