تصميم بحث عالمي مراعي للأذونات بدون تسريبات بيانات

لماذا يمكن أن يسرّب البحث العالمي البيانات

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

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

يبدو البحث "للقراءة فقط"، لذا تقلل الفرق من شأنه. لكنه يمكن أن يفشي بيانات عبر عناوين النتائج والمعاينات والاقتراحات والأعداد التجميعية (مثل "العملاء (5)"), وحتى عبر فروق في الزمن (سريع لبعض المصطلحات وبطيء لغيرها).

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

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

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

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

ما الذي تفهرسه وما الذي يجب حمايته

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

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

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

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

قواعد مستوى السجل تقرر الرؤية صفًا بصف. مثال: يمكن لوكيل الدعم رؤية التذاكر الموكّلة لفريقه، بينما يمكن للمدير رؤية كل التذاكر في منطقته. قاعدة شائعة أخرى هي ملكية المستأجر: في تطبيق متعدد المستأجرين، يمكن للمستخدم رؤية السجلات حيث customer_id = their_customer_id.

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

ماذا يعني "مسموح أن يرى" عمليًا

"مسموح" نادرًا ما يكون مجرد تبديل نعم/لا واحد. عادةً يجمع بين الملكية (أنشأته أنا، موكّل إليّ)، العضوية (فريقي، قسمي، دوري)، النطاق (منطقتي، وحدة الأعمال، المشروع)، حالة السجل (منشور، غير مؤرشف)، وحالات خاصة (عملاء VIP، حظائر قانونية، وسوم مقيدة).

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

قرّر ما الآمن عرضه في معاينة النتيجة

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

الإفتراض الآمن هو عرض حقول قليلة وغير حساسة حتى يتأكد الوصول: اسم عرض أو عنوان (أحيانًا مخفف)، معرف قصير (مثل رقم الطلب)، حالة عالية المستوى (مفتوح، مدفوع، مُشحون)، تاريخ (إنشاء أو تحديث)، ووسم كيان عام (Ticket, Invoice).

مثال ملموس: إذا بحث أحدهم "Acme merger" ووجود تذكرة مقيدة، إعادة "Ticket: Acme merger draft - Legal" تُعد تسريبًا. نتيجة أكثر أمانًا هي "Ticket: Restricted" بدون مقتطف، أو عدم إظهار نتيجة على الإطلاق، حسب سياستك.

وضع هذه التعريفات بشكل صحيح يسهل القرارات لاحقًا: ما الذي تفهرسه، كيف تقوم بالفلترة، وما الذي تقبل الكشف عنه.

المتطلبات الأساسية لبحث آمن وسريع

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

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

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

بحث عالمي آمن يحتاج أربعة أشياء:

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

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

ثلاثة أنماط تصميم شائعة (ومتى تستخدم كلًا منها)

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

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

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

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

المنهج ب: تخزين سمات الأذونات في الفهرس والفلترة هناك. تضمّن حقولًا مثل tenant_id, team_id, owner_id, أعلام الدور، أو project_id في كل وثيقة مفهرسة. كل استعلام يضيف فلاتر تطابق نطاق المستخدم الحالي.

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

المنهج ج: هجين. فلترة خشنة في الفهرس، وفحص نهائي في قاعدة البيانات. تفلتر في الفهرس باستخدام سمات مستقرة وعريضة (tenant, workspace, customer)، ثم تعيد فحص الأذونات على مجموعة صغيرة من معرّفات المرشحين في قاعدة البيانات الأساسية قبل إرجاع أي شيء.

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

اختيار النمط

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

خطوة بخطوة: صمّم فهرسًا يحترم قواعد الوصول

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

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

ثم قرّر إشارات الأذونات التي يمكنك فلترتها بسرعة. هذه سمات تمنع الوصول ويمكن تخزينها على كل وثيقة مفهرسة، مثل tenant_id, org_unit_id, وvisibility_level. الهدف أن يطبق كل استعلام فلاتر قبل إرجاع النتائج، بما في ذلك الإكمال التلقائي.

تتضمن سير عمل عملي:

1. عرّف قواعد الرؤية لكل كيان (تذاكر، عملاء، فواتير) بلغة بسيطة.
2. أنشئ مخطط مستند بحث بموجّه record_id بالإضافة إلى حقول بحثية آمنة فقط.
3. أضف حقول أذونات قابلة للفلترة (tenant_id, org_unit_id, visibility_level) لكل مستند.
4. تعامل مع الاستثناءات بمنح صريحة: خزّن قائمة سماح (معرّفات المستخدمين) أو معرّفات المجموعات للعناصر المشتركة.

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

الحفاظ على تزامن الفهرس دون مفاجآت

تجربة بحث آمنة تعتمد على أمر ممل واحد يُؤدى جيدًا: يجب أن يعكس الفهرس الواقع. إذا تم إنشاء سجل أو تغييره أو حذفه أو تغيّر أذوناته، يجب أن تتبع نتائج البحث بسرعة وبشكل متوقع.

مواكبة الإنشاء والتحديث والحذف

عامل الفهرسة كجزء من دورة حياة البيانات. نموذج ذهني مفيد: في كل مرة يتغير مصدر الحقيقة، تصدر حدثًا ويتفاعل الفهرس مع هذا الحدث.

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

تغييرات الأذونات هي تغييرات فهرس

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

اجعل تغييرات الأذونات أحداثًا من الدرجة الأولى. إذا كان بحثك يعتمد على فلاتر tenant أو team، تأكد أن الوثائق المفهرسة تتضمن الحقول اللازمة لفرض ذلك (tenant_id, team_id, owner_id, allowed_role_ids). عند تغيّر تلك الحقول، أعد الفهرسة.

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

التخطيط للاتساق المحتمل

حتى مع أحداث جيدة، سيكون هناك نافذة يتأخر فيها البحث عن الحقيقة. قرّر ماذا يجب أن يرى المستخدمون في الثواني القليلة بعد التغيير.

قاعدتان تساعدان:

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

أضف مسارًا آمنًا احتياطيًا عندما يكون الفهرس غير متزامن

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

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

أخطاء شائعة تسبب تسريبات بيانات

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

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

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

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

مصائد التسريب التي يجب فحصها مبكرًا:

• الإكمال التلقائي والبحث الأخير مفلتران بنفس قواعد البحث الكامل.
• أعداد الفئات والإجماليات محسوبة بعد تطبيق الأذونات.
• مفاتيح الكاش تتضمن tenant ID وتوقيعًا للأذونات (الدور، الفريق، معرّف المستخدم).
• السجلات والتحليلات لا تخزن الاستعلامات الخام أو مقتطفات النتائج للبيانات المقيدة.

أخيرًا، احذر من الفلاتر الواسعة جدًا. "الفلترة حسب المستأجر فقط" هي خطأ متعدد المستأجرين الكلاسيكي، لكنه يحدث داخل مستأجر واحد أيضًا: الفلترة حسب "القسم" عندما يكون الوصول على مستوى السجل. مثال: وكيل دعم يبحث "refund" ويحصل على نتائج عبر كل العملاء في المستأجر، بما في ذلك حسابات VIP المقصود رؤيتها فقط لفريق أصغر. الحل بسيط من حيث المبدأ: فرض قواعد على مستوى الصف في كل مسار استعلام (بحث، إكمال تلقائي، فئات، تصديرات)، ليس فقط في عرض السجل.

تفاصيل الخصوصية والأمان التي ينسى الناس

تركز كثير من التصاميم على "من يمكن رؤية ماذا"، لكن التسريبات تحدث أيضًا عبر الحواف: حالات الفراغ، الزمن، وتلميحات صغيرة في الواجهة. يجب أن يكون البحث المراعِي للأذونات آمنًا حتى عندما لا يُرجع شيئًا.

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

التطابقات الجزئية الحساسة

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

مجموعة قواعد عملية:

• اشترط التطابق الدقيق للحقل عالي المخاطر (البريد الإلكتروني، الهاتف، المعرفات).
• تجنّب إظهار مقتطفات مميّزة تكشف نصًا مخفيًا.
• فكّر في تعطيل الإكمال التلقائي للحقل الحساس تمامًا.

إذا كان إظهار حرف واحد يساعد شخصًا في تخمين بيانات، اعتبره حساسًا.

ضوابط مكافحة الإساءة التي لا تخلق مخاطر جديدة

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

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

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

مثال: فريق دعم يبحث التذاكر عبر العملاء

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

مايا تكتب "Alic" لأن المتصل قال أن اسمه Alice. يظهر الإكمال التلقائي عددًا من الاقتراحات. تنقر على "Alice Nguyen - Ticket: Password reset." قبل فتح أي شيء، يعيد التطبيق فحص الوصول لذلك السجل. إذا كانت التذكرة لا تزال مخصّصة لفريقها ودورها يسمح بذلك، تصل إلى التذكرة.

ما تراه مايا في كل خطوة:

• صندوق البحث: تظهر الاقتراحات بسرعة، ولكن فقط للسجلات التي يمكنها الوصول إليها الآن.
• قائمة النتائج: موضوع التذكرة، اسم العميل، وقت آخر تحديث. لا توجد نُسخ "ليس لديك وصول".
• تفاصيل التذكرة: يتم تحميل العرض الكامل بعد فحص أذونات خادمي ثانية. إذا تغيّر الوصول، يُعرض "التذكرة غير موجودة" (وليس "ممنوع").

قارن ذلك بليو، وكيل جديد في التدريب. دوره يسمح فقط بعرض التذاكر المعلمة "جمهور للدعم" وفحسب لعميل واحد. يكتب لي نفس الاستعلام "Alic." يرى اقتراحات أقل، ولا تُلمح العناصر المفقودة. لا يوجد عدّ "5 نتائج" يكشف عن matches أخرى. الواجهة ببساطة تعرض ما يمكنه فتحه.

لاحقًا، يقوم مدير بإعادة تخصيص "Alice Nguyen - Password reset" من فريق مايا إلى فريق تصعيد متخصص. خلال نافذة قصيرة (عادةً ثوانٍ إلى دقائق قليلة، حسب نهج المزامنة)، يتوقف البحث عن إرجاع تلك التذكرة لمايا. إذا كانت صفحة التفاصيل مفتوحة وقامت بتحديثها، يعاد فحص الأذونات وتختفي التذكرة.

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

قائمة مراجعة وخطوات لاحقة للتنفيذ الآمن

البحث العالمي المراعِي للأذونات "مكتمل" فقط عندما تكون الحواف المملة آمنة. تحدث العديد من التسريبات في أماكن تبدو غير ضارة: الإكمال التلقائي، أعداد النتائج، والتصديرات.

فحوصات سريعة للأمان

قبل الإطلاق، مرّ بهذه الفحوصات مع بيانات حقيقية، ليس عينات:

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

خطة اختبار يمكنك تشغيلها

أنشئ مصفوفة أدوار صغيرة (الأدوار × الكيانات) ومجموعة بيانات تتضمن حالات متعمدة صعبة: سجلات مشتركة، وصول تم سحبه مؤخرًا، وأشباه عبر مستأجرين.

اختبر ذلك في ثلاث مراحل: (1) اختبارات مصفوفة الأدوار حيث تتحقق أن السجلات المرفوضة لا تظهر أبدًا في النتائج أو الاقتراحات أو الأعداد أو التصديرات؛ (2) اختبارات "حاول كسرها" حيث تلصق معرفات، وتبحث بالبريد أو الهاتف، وتجرب التطابقات الجزئية التي يجب ألا تُرجع شيئًا؛ (3) اختبارات الزمن والكاش حيث تغير الأذونات وتتأكد أن النتائج تتحدّث بسرعة بدون اقتراحات قديمة.

تشغيليًا، خطط ليوم تبدو فيه نتائج البحث "خطأ". سجّل سياق الاستعلام (المستخدم، الدور، المستأجر) والفلاتر المطبّقة، لكن تجنّب تخزين نصوص الاستعلامات الحساسة أو مقتطفات النتائج. للتصحيح الآمن، أنشئ أداة خاصة بالمسؤول يمكنها شرح سبب تطابق سجل ولماذا سُمح به.

إذا كنت تبني على AppMaster (appmaster.io)، نهج عملي هو الحفاظ على البحث كتدفق جانب خادم: نمذج الكيانات والعلاقات في Data Designer، طبّق قواعد الوصول في Business Processes، وأعد استخدام نفس فحص الأذونات للإكمال التلقائي، قائمة النتائج، والتصديرات بحيث يكون هناك مكان واحد لتصحيحه.