سحب صلاحية موظف أثناء عمله: اختبار سباق الطلبات والجلسات في المتصفح متعدد الحسابات

صلاحية حُذفت لكن الجلسة ما زالت تعمل

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

ارسم حدود السلطة الفعلية

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

حدد معنى الإلغاء الفوري

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

اختبر السباق بين القرار والطلب

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

ما مصير الطلب الجاري بالفعل؟

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

إصدارات السياسة تمنع الاعتماد على ذاكرة قديمة

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

قنوات WebSocket تحتاج تحققًا مستمرًا

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

المهام المجدولة ليست مستخدمًا حاضرًا

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

لا تخلط الإلغاء بتسجيل الخروج

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

سجل تدقيق يمكن تفسيره

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

جدول قبول متعدد المسارات

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

الأخطاء التي تظهر في التطبيقات متعددة الحسابات

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

كيف تنفذ تجربة آمنة؟

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

ما الذي تقوله المراجع الرسمية؟

يعرض معيار NIST SP 800-53 ضوابط لإدارة الحسابات وإنفاذ الوصول وأقل امتياز، ويذكر الإدارة الديناميكية للامتيازات ضمن مناقشة إدارة الحسابات. المرجع: https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final . لا يفرض ذلك وحده زمن إلغاء موحدًا على كل منتج؛ يجب اختيار سياسة ملائمة للمخاطر وتوثيقها. ولشرح توزيع الأدوار في المتصفح متعدد الحسابات، اقرأ دليل إيجي تاج: https://egytag.com/ar/articles/إدارة-صلاحيات-الفريق-داخل-متصفح-متعدد-الحسابات . أما الاختبار هنا فيركز على السباق بين التغيير والطلب والتنفيذ، وهو جانب مختلف عن اختيار الدور الابتدائي.

خطة استجابة عند فشل الاختبار

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