تدقيق الوصول إلى السجلات قبل نشر وكيل الذكاء الاصطناعي
دليل عملي لما قبل النشر يدقّق ما يستطيع مستخدم وكيل Agentforce رؤيته فعليًا — على مستوى الكائن والسجل — كي لا يكشف بيانات لا ينبغي له كشفها.
أأمن لحظة لاكتشاف أن وكيل الذكاء الاصطناعي لديك قادر على قراءة كل سجل رواتب في المؤسسة هي قبل نشره — لا حين يطلب منه مستخدم ذلك. وبما أن وكيل Agentforce يرث صلاحية وصول المستخدم الذي يعمل باسمه، فإن تشغيله هو في الحقيقة قرار بكشف كل ما يستطيع ذلك المستخدم رؤيته، حواريًا وبسرعة الآلة. هذا الدليل يدقّق ذلك الوصول أولًا.
لماذا يهمّ هذا التدقيق للوكلاء أكثر مما يهمّ للبشر
نادرًا ما يصطدم الإنسان بكامل مدى صلاحياته — فهو يفتح السجلات التي يعمل عليها ويتجاهل الباقي. أما الوكيل فلا. اطرح عليه سؤالًا فيسترجع كل ما هو في متناوله ويربطه ويلخّصه. الوكيل لا ينشئ أي وصول جديد؛ بل يكشف الوصول الموجود أصلًا — بما في ذلك الوصول الذي نسيه الجميع.
إذن فالتدقيق لا يدور حول الذكاء الاصطناعي. إنه يدور حول الإجابة عن سؤال قديم بإلحاح جديد: ما الذي يستطيع هذا المستخدم رؤيته فعليًا؟
الخطوة 1 — حدِّد بدقة هوية التشغيل الخاصة بالوكيل
حدِّد بالضبط أي مستخدم (أو أي إعداد مستخدم) يعمل الوكيل باسمه. كل ما يستطيع الوكيل قراءته تحدده أذونات تلك الهوية ومشاركاتها. وإن كان يعيد استخدام ملف تعريف بشري واسع الصلاحيات، فتلك هي الملاحظة الأولى بالفعل — راجع الخطوة 5.
الخطوة 2 — دقّق الوصول على مستوى الكائن
بالنسبة إلى تلك الهوية، راجِع أذونات الكائن من ملف تعريفها ومجموعات الأذونات الخاصة بها:
- CRUD — أي الكائنات يمكنها قراءته / إنشاؤه / تحريره / حذفه؟
- أمن الحقول (Field-level security) — أي الحقول الحساسة مرئية؟
- View All / Modify All — أيٌّ من هذه على كائن (أو “View All Data”) يتجاوز نموذج المشاركة بالكامل، وهو أعلى ما يجب البحث عنه أولوية.
الوصول على مستوى الكائن هو البوابة؛ فإن لم يكن للوكيل أي مسوّغ تجاري لقراءة كائن ما، فعالِج ذلك هنا قبل القلق بشأن السجلات.
الخطوة 3 — دقّق الوصول على مستوى السجل
بالنسبة إلى الكائنات التي يستطيع قراءتها، حدِّد أي السجلات يراها، عبر كل آلية مشاركة:
- الإعدادات الافتراضية على مستوى المؤسسة (OWD) — هل خط الأساس خاص أم عام؟ إعداد OWD العام يعني أن الوكيل يرى كل سجل من ذلك الكائن.
- التسلسل الهرمي للأدوار — هل تقع الهوية عاليًا في التسلسل الهرمي، فترث كل من هم دونها؟
- قواعد المشاركة — أي القواعد القائمة على الملكية والقائمة على المعايير تشملها؟
- المشاركات اليدوية — أي منح فردية لمرة واحدة؟
- المشاركة الضمنية — الوصول إلى الحسابات الذي يجلب معه السجلات الفرعية، وهي الطبقة التي تنساها عمليات التدقيق.
المخرَج الذي تريده: ها هي المجموعة الفعلية للسجلات التي يستطيع هذا الوكيل قراءتها، والآلية وراء كل منها.
الخطوة 4 — تصيّد الوصول المفرط في السعة والمتقادم
وبالصورة الكاملة بين يديك، ابحث عن المنح التي لا ينبغي أن تكون موجودة:
- إعداد OWD بـ Public Read ينبغي أن يكون خاصًا.
- قواعد مشاركة قائمة على المعايير تطابق أكثر بكثير مما هو مقصود.
- مجموعات أذونات تُركت فيها صلاحية “View All” من مشروع سابق.
- مشاركات يدوية كان يُقصد بها أن تكون مؤقتة.
كل واحدة من هذه أمرٌ كان الوكيل سيكشفه لولا ذلك. نقِّها.
الخطوة 5 — امنح الوكيل أقل قدر من الامتيازات
لا تُعِد استخدام ملف تعريف بشري واسع الصلاحيات. وفّر هوية مخصصة بأقل قدر من الامتيازات محصورة في مهمة الوكيل، وضع فوقها سياسات قائمة على السمات للقواعد الدقيقة. ينبغي أن يحظى الوكيل بالحد الأدنى من الوصول المطلوب — ولا شيء يرثه بالصدفة.
الخطوة 6 — أعِد التدقيق عند كل تغيير
الوصول الفعلي يتغيّر مع الوقت: قاعدة مشاركة جديدة، أو نقل دور، أو تعديل في مجموعة أذونات، فيتسع نطاق وصول الوكيل بهدوء. أعِد تشغيل التدقيق بعد أي تغيير في المشاركة، وعلى وتيرة منتظمة بصرف النظر عن ذلك. “محصور بشكل صحيح عند الإطلاق” لا يعني “محصور بشكل صحيح اليوم.”
تحويل تدقيق يستغرق أيامًا إلى سؤال
الخطوات من 2 إلى 6 هي الجزء الصعب: إعادة بناء الوصول الفعلي الحقيقي لمستخدم ما عبر CRUD وأمن الحقول وست آليات مشاركة — ثم إبقاؤه محدَّثًا. يدويًا، يعني ذلك أيامًا من العمل ويسهل الوقوع في الخطأ فيه.
AgentForceAccess مصمم لهذا الغرض تحديدًا. اسأل، بالإنجليزية البسيطة، عمّا يستطيع المستخدم الذي يعمل الوكيل باسمه رؤيته فعليًا، فيتتبّع كل منحة — إذن كائن، أو قاعدة مشاركة، أو مشاركة يدوية أو ضمنية — ويذكر الآلية وراءها. إنه يحوّل “نظن أن الوكيل محصور بشكل صحيح” إلى “نعلم أنه كذلك”، قبل أن تنشره وبعد كل تغيير.
الأسئلة الأكثر تكراراً
لماذا ندقّق الوصول قبل نشر الوكيل من الأساس؟
لأن الوكيل سيكشف كل ما يستطيع مستخدمه الذي يعمل باسمه الوصول إليه، فوريًا وعند الطلب. معظم المؤسسات لديها مشاركة أكثر انفتاحًا مما يتذكره أحد، لذا يكشف التدقيق الوصول الكامن الذي كان الوكيل سيعرضه لولا ذلك — قبل أن يفعل.
ماذا ينبغي أن يغطّي التدقيق فعليًا؟
طبقتين. على مستوى الكائن: صلاحيات CRUD لدى المستخدم الذي يعمل الوكيل باسمه وأمن الحقول من ملف تعريفه ومجموعات الأذونات الخاصة به. على مستوى السجل: أي سجلات محددة يستطيع رؤيتها عبر الإعدادات الافتراضية على مستوى المؤسسة، والتسلسل الهرمي للأدوار، وقواعد المشاركة، والمشاركات اليدوية، والمشاركة الضمنية.
هل ينبغي أن يستخدم الوكيل حساب موظف حقيقي؟
لا. وفّر هوية مخصصة بأقل قدر من الامتيازات محصورة في مهمة الوكيل، بدلًا من إعادة استخدام ملف تعريف بشري واسع الصلاحيات. ينبغي أن يحظى الوكيل بالحد الأدنى من الوصول الذي يحتاجه ولا شيء يرثه بالصدفة.
كم مرة ينبغي أن نعيد التدقيق؟
بعد أي تغيير في الإعدادات الافتراضية على مستوى المؤسسة، أو قواعد المشاركة، أو التسلسل الهرمي للأدوار، أو ملفات التعريف، أو مجموعات الأذونات — وعلى وتيرة منتظمة بصرف النظر عن ذلك. الوصول الفعلي يتغيّر مع الوقت، ونطاق وصول الوكيل يتغيّر معه.
شاهده على مؤسستك أنت
يشرح AgentForceAccess بلغة واضحة وبسيطة لماذا يستطيع أي مستخدم رؤية أي سجل أو ملف — عبر كل آلية مشاركة في Salesforce.
اطلب وصولاً مبكراً