تتعلق مخاطر تسريب DNS عندما يتمكن الكود المشغّل في صندوق الرمل من حل أسماء نطاقات يتحكم فيها المهاجم أو استخدام DNS كقناة بيانات صادرة، لذلك يجب على الفرق تقييم سياسة DNS، والتسجيل، ومسارات جلب الحزم، وأدلة الحوادث قبل الوثوق بصندوق رمل وكيل ذكاء اصطناعي في سير عمل حساسة.
لماذا تعتبر DNS مهمة في نماذج التهديد لصندوق الرمل
صُممت صناديق الرمل لوكلاء الذكاء الاصطناعي لتحقيق استقلالية مفيدة. قد يقوم وكيل برمجي بتشغيل اختبارات، وتثبيت حزم، واستدعاء واجهات برمجة تطبيقات، وتشغيل متصفح، وفحص ملفات، وإنتاج مخرجات دون موافقة بشرية على كل أمر. هذه المرونة هي بالضبط السبب في أن سلوك الشبكة يحتاج إلى مراجعته الخاصة، بشكل منفصل عن عزل وحدة المعالجة المركزية والذاكرة ونظام الملفات والعمليات.
غالبًا ما تحصل DNS على اهتمام أقل من HTTP الصادر لأنها تبدو كبنية تحتية للربط البيني. تحتاج التطبيقات إلى تحليل الأسماء للوصول إلى واجهات برمجة التطبيقات والسجلات وصفحات الويب ونقاط النهاية للتحديث. لكن DNS لا يزال اتصالاً صادرًا. صندوق الرمل الذي يمكنه حل أسماء نطاقات عشوائية يمكنه الكشف عن معلومات من خلال أسماء الاستعلامات، أو الاتصال ببنية تحتية يتحكم فيها المهاجم، أو إنشاء نقطة عمياء إذا لم يتم تسجيل حركة DNS بنفس العناية التي تُعطى لطلبات الويب.
هذه ليست فئة نظرية اخترعت لوكلاء الذكاء الاصطناعي. توثق MITRE ATT&CK DNS كبروتوكول طبقة تطبيق يمكن للخصوم استخدامه للاتصال بأوامر التحكم، وتوثق بشكل منفصل تسريب البيانات عبر بروتوكولات بديلة عندما تغادر البيانات عبر قناة ليست بروتوكول التطبيق الرئيسي. بالنسبة لمقيّمي صناديق الرمل، الدرس واضح: لا تعامل DNS على أنها غير ضارة لمجرد أنها ليست طلب HTTP POST.
بالنسبة لوكلاء الذكاء الاصطناعي، عادة ما يأتي الخطر من سلسلة من الأذونات الصغيرة بدلاً من خطأ واحد واضح:
| قدرة صندوق الرمل | لماذا تسمح الفرق بها | سؤال متعلق بـ DNS |
|---|---|---|
| تثبيت الحزم | السماح للوكلاء بتثبيت التبعيات المفقودة | ما هي السجلات ومسارات الحل المسموح بها؟ |
| الوصول إلى الويب | السماح لوكلاء المتصفح بجمع سياق عام | هل يمكن للكود حل أي نطاق أم نطاقات معتمدة فقط؟ |
| استدعاءات واجهات برمجة التطبيقات | السماح للوكلاء بالتكامل مع تطبيقات الخلفية | هل النطاقات الداخلية ونقاط نهاية البيانات الوصفية محظورة؟ |
| أدوات البناء | السماح لوكلاء البرمجة بتشغيل اختبارات واقعية | هل يمكن لبرامج ما بعد التثبيت تشغيل عمليات بحث غير متوقعة؟ |
| جلسات طويلة الأمد | السماح للوكلاء بمواصلة المهام متعددة الخطوات | هل يتم الاحتفاظ بسجلات DNS عبر دورة حياة الجلسة الكاملة؟ |
الهدف ليس حظر كل استدعاء شبكة. العديد من مهام الوكيل تحتاج وصولاً شبكياً خاضعاً للتحكم. الهدف هو معرفة المسارات الموجودة، والمسارات المحظورة، وما هي الأدلة التي ستحصل عليها إذا تصرفت مهمة بشكل غير متوقع.
أين يظهر تحليل DNS في سير عمل الوكيل
غالباً ما تسأل مراجعات الأمان عما إذا كان صندوق الرمل لديه وصول إلى الإنترنت. هذا السؤال واسع جداً. تبدأ مراجعة أفضل بتحديد كل مكان قد يؤدي فيه الكود أو الأدوات أو مديري الحزم أو المتصفحات إلى تحليل الأسماء.
تشمل مسارات DNS الشائعة:
- طلبات الكود المباشرة من Python وJavaScript ونصوص shell وSDKs ومجموعات الاختبار.
- أتمتة المتصفح التي تحمّل الصفحات والموارد الفرعية والخطوط والصور ونصوص التحليلات وعمليات إعادة التوجيه.
- مديري الحزم مثل npm وpip وuv وpnpm وapt وcargo أو مثبتات الإضافات الخاصة بلغة معينة.
- أدوات البناء التي تجلب الملفات الثنائية والقوالب وبرامج تشغيل المتصفح وملفات النماذج وتركيبات الاختبار.
- أدوات الوكيل التي تستدعي واجهات برمجة تطبيقات طرف ثالث أو نقاط نهاية webhook.
- وظائف الخلفية التي تستمر في العمل بعد عودة خطوة الوكيل المرئية.
يجب أن يشمل هذا التحديد كل من حركة المرور المقصودة والعرضية. قد يطلب المطور فقط من الوكيل تشغيل اختبار وحدة، لكن أمر الاختبار قد يقوم بتثبيت حزمة، وقد يقوم مدير الحزم بحل نطاق السجل، وقد يتصل برنامج دورة الحياة بمضيف منفصل. قد تكون مهمة المتصفح مقتصرة على موقع عام واحد، بينما تحل الموارد المضمنة العديد من النطاقات الإضافية.
بالنسبة لمزود صندوق الرمل، فإن أقوى إجابة ليست فقط “الوصول إلى الشبكة متاح” أو “الوصول إلى الشبكة معزول”. الإجابة المفيدة تشرح مسار الحل:
- هل يستخدم DNS صندوق الرمل محللاً خاضعاً لتحكم المزود، أم محللاً خاضعاً لتحكم العميل، أم محلل VPC، أم محللاً عاماً؟
- هل يمكن للعميل تقييد النطاقات أو نطاقات عناوين IP أو المنافذ أو البروتوكولات؟
- هل يتم تسجيل طلبات DNS لكل صندوق رمل، لكل جلسة، لكل أمر، أم فقط على مستوى الشبكة الإجمالي؟
- هل يتم تسجيل عمليات البحث المرفوضة، أم فقط عمليات البحث المسموح بها؟
- هل يمكن للعملاء فصل DNS لجلب الحزم عن DNS لوقت التشغيل؟
إذا كانت هذه التفاصيل غير متوفرة، تعامل معها كعناصر تقييم مفتوحة، وليس كدليل على أن صندوق الرمل غير آمن. يعتمد الخطر العملي على حساسية سير العمل، والأسرار المتاحة داخل صندوق الرمل، وسياسة الخروج، وجودة الأدلة الجنائية.
كيفية تقييم سياسة الخروج
سياسة الخروج هي سطح التحكم الذي يقرر ما إذا كانت DNS ستصبح ربطاً روتينياً أم مسار هروب غير مراجع. يجب أن تجيب سياسة ناضجة على ثلاثة أسئلة: ما هو مسموح، لماذا هو مسموح، وكيف تتم الموافقة على الاستثناءات.
ابدأ بالموقف الافتراضي. لا ينبغي أن يرث صندوق الرمل المستخدم لرمز وكيل ذكاء اصطناعي غير موثوق نفس الوصول الشبكي الواسع مثل كمبيوتر المطور المحمول. إذا كان الافتراضي هو الخروج المفتوح، اسأل عما إذا كان المنتج يدعم تضييق هذا الوصول لأعباء العمل عالية المخاطر. إذا كان الافتراضي هو الخروج المقيد، اسأل كيف يمكن للمطورين تمكين النطاقات الدقيقة اللازمة للمهمة.
ثم افصل سياسة DNS عن سياسة HTTP. بعض الأنظمة تفرض قوائم السماح HTTP لكنها تترك تحليل الأسماء واسعاً. يمكن أن يخلق ذلك عدم تطابق: قد يفشل طلب إلى مضيف غير معتمد في طبقة HTTP، لكن استعلام DNS لا يزال يغادر البيئة وقد لا يزال يحمل بيانات وصفية في الاسم المستفسر عنه. التصميم الأكثر صرامة يقيم محاولات الحل والاتصال معاً.
بالنسبة لمراجعات الأمان، استخدم مصفوفة سياسة مثل هذه:
| مجال التقييم | ماذا تسأل | أدلة أقوى |
|---|---|---|
| الخروج الافتراضي | هل الوصول إلى الشبكة الصادرة مفتوح أم مرفوض أم محدد النطاق حسب القالب؟ | سياسة افتراضية مكتوبة بالإضافة إلى نتيجة اختبار على مستوى صندوق الرمل |
| مسار محلل DNS | أي محلل يتعامل مع DNS صندوق الرمل؟ | رسم تخطيطي للهندسة أو دليل على التكوين |
| قوائم السماح للنطاقات | هل يمكن للفرق السماح فقط بالسجلات وواجهات برمجة التطبيقات المعتمدة؟ | مثال التكوين ومثال سجل الرفض |
| كتل IP والشبكات الخاصة | هل النطاقات الداخلية وخدمات البيانات الوصفية محظورة افتراضياً؟ | قواعد الرفض الموثقة وأدلة الاختبار |
| ضوابط البروتوكول | هل يتم التحكم في DNS وHTTP وHTTPS والمآخذ الأولية بشكل منفصل؟ | نموذج السياسة، وليس فقط الصياغة التسويقية |
| سير عمل الاستثناء | من يمكنه إضافة نطاقات أو تخفيف السياسة؟ | موافقة قائمة على الدور وسجل تدقيق |
بالنسبة لمعظم الفرق، الهدف العملي الأول ليس بيئة خروج صفرية مثالية. إنه ملف تعريف خروج أدنى موثق: سجلات حزم معتمدة، نطاقات واجهات برمجة تطبيقات معتمدة، لا وصول إلى الشبكات الداخلية ما لم يتم توجيهه صراحةً، وسجلات لكل من المحاولات المسموح بها والمرفوضة.
جلب الحزم وDNS الناتج عن التبعيات
تثبيت الحزم هي إحدى أسهل الطرق للتقليل من تقدير خروج صندوق الرمل. غالباً ما يفشل الكود الذي يولده الوكيل بسبب التبعيات المفقودة، وأسرع تجربة للمطور هي السماح للوكيل بتثبيت ما يحتاجه. هذه الراحة تخلق مشكلة ثانية في سلسلة التوريد: أسماء الحزم، وعمليات إعادة التوجيه في السجل، وبرامج التثبيت، والتنزيلات الثنائية يمكن أن تؤدي إلى نشاط DNS وشبكة لم يذكرها الطلب الأصلي أبداً.
تشير إرشادات تطبيق LLM من OWASP إلى المخاطر المتعلقة بالاستقلالية المفرطة والتعرض لسلسلة التوريد. في صناديق الرمل للوكلاء، تلتقي هذه المخاطر في تثبيت الحزم. قد يُسمح للنموذج باختيار الأوامر. قد يستدعي الأمر مدير حزم. قد يجلب مدير الحزم كوداً من سجل. قد يقوم الكود الذي تم جلبه بتشغيل خطافات التثبيت. كل خطوة قد تخلق عمليات بحث DNS واتصالات صادرة.
يجب أن يركز التقييم الدفاعي على الحوكمة، وليس على آليات الاستغلال:
- يفضل استخدام ملفات التبعيات المثبتة للمهام المتكررة للوكيل.
- استخدم سجلات معتمدة أو مخابئ سحب للمنظومات البيئية الشائعة.
- سجل اسم الحزمة والإصدار وعنوان URL للسجل والنطاقات التي تم حلها وهاشات القطع الأثرية حيثما كان ذلك عملياً.
- افصل إذن تثبيت الحزمة عن وصول الإنترنت العام لوقت التشغيل.
- اطلب الموافقة قبل تثبيت الحزم خارج قائمة السماح لمساحات العمل الحساسة.
- ضع في اعتبارك قوالب صندوق رمل مبنية مسبقاً للمكدسات الشائعة حتى لا يحتاج الوكلاء إلى وصول شبكي واسع خلال كل تشغيل.
الفرق المهم هو أن “جلب الحزمة” ليس تحكماً واحداً. إنه يشمل تحليل DNS، والمصادقة على السجل، وتنزيل القطع الأثرية، وتنفيذ الكود في وقت التثبيت، وسلوك التخزين المؤقت. مراجعة جيدة لصندوق الرمل تسأل عن المسار بأكمله.
افتراضات الأسرار وكشف البيانات
تسريب DNS مهم فقط إذا كان هناك شيء ذو معنى لتسريبه. هذا يجعل وضع الأسرار ونطاق البيانات جزءاً من مراجعة DNS.
يجب معاملة صناديق الرمل لوكلاء الذكاء الاصطناعي مثل عمال البناء غير الموثوقين ما لم يثبت العكس. لا تضع بيانات اعتماد إنتاج طويلة الأمد، أو رموز سحابية واسعة، أو بيانات العملاء، أو كود مصدر داخلي في صندوق الرمل فقط لأن صندوق الرمل معزول عن المضيف. العزل يقلل من نصف قطر الانفجار، لكنه لا يجعل كل أمر آمناً.
استخدم هذه الافتراضات عند تصميم سير عمل عالي المخاطر:
- أي ملف يمكن قراءته بواسطة الكود المنفذ من قبل الوكيل يمكن تضمينه في السجلات أو المخرجات أو طلبات الشبكة أو رسائل الخطأ.
- أي متغير بيئة مرئي لعملية يمكن نسخه بواسطة تلك العملية.
- أي قناة صادرة مسموح بها لصندوق الرمل تستحق نفس مراجعة فقدان البيانات، بما في ذلك DNS.
- أي تعليمات محقونة بالطلب في سير عمل المتصفح أو المستند قد تحاول التأثير على استخدام الأداة.
- أي جلسة طويلة الأمد تزيد من قيمة سجلات دورة الحياة وانتهاء صلاحية الرمز.
تشمل الضوابط العملية بيانات اعتماد قصيرة الأمد، ومفاتيح واجهة برمجة تطبيقات بأقل الامتيازات، وحسابات خدمة محددة النطاق، وأسرار لكل مهمة، وسجلات منقحة، وفصل صريح بين مهام البحث عن البيانات العامة ومهام تنفيذ الكود الحساس.
السجلات ومسارات التدقيق وأدلة الحوادث
ضوابط DNS مفيدة فقط إذا كان يمكن للفرق التحقق منها. عندما تكون مهمة صندوق الرمل مشبوهة، تحتاج فرق الأمان إلى أدلة بسرعة: ما الذي تم تشغيله، وما الذي تم حله، وما الذي اتصل، وما هي الملفات التي تغيرت، وما هي المخرجات التي تم إرجاعها.
على الأقل، اسأل عما إذا كانت المنصة يمكنها إعادة بناء هذه الأحداث لجلسة صندوق رمل معينة:
- وقت إنشاء صندوق الرمل، القالب، تكوين الموارد، والمالك.
- الأوامر التي نفذها الوكيل أو المستخدم.
- الملفات التي تمت قراءتها أو كتابتها أو تحميلها أو تنزيلها عندما يعرض المنتج عمليات الملفات.
- تثبيتات الحزم وعمليات جلب السجل.
- استعلامات DNS، بما في ذلك الطابع الزمني والاسم المستفسر عنه والنتيجة ومعرف صندوق الرمل/الجلسة.
- محاولات الاتصال الصادرة، بما في ذلك المضيف الوجهة وعنوان IP والمنفذ والبروتوكول ونتيجة السماح/الرفض والحجم حيثما كان متاحاً.
- استدعاءات الأدوات وأحداث التنقل في المتصفح والعمليات الخلفية.
- أحداث حقن الأسرار دون كشف قيم الأسرار في السجلات.
- أحداث إنهاء الجلسة والإيقاف المؤقت والاستئناف واللقطة والتنظيف.
لا تطلب فقط سجلات حركة المرور الناجحة. غالباً ما تكون الأحداث المرفوضة أكثر فائدة لتقييم ما إذا كانت السياسة تعمل. إذا حاول صندوق الرمل حل نطاق غير معتمد وقامت السياسة بحظره، فإن عملية البحث المرفوضة هذه هي الدليل الذي يفصل بين تحكم فعال وفشل صامت.
الاحتفاظ أيضاً مهم. نافذة سجل مدتها سبعة أيام قد تكون كافية لتصحيح الأخطاء لكنها ضعيفة للاستجابة للحوادث. يجب على الفرق ذات أعباء العمل الخاضعة للتنظيم أو الحساسة للعملاء مواءمة الاحتفاظ بتليمترية صندوق الرمل مع سياسة تسجيل الأمان الأوسع.
ملاحظات تقييم صندوق رمل وكيل Novita
صُمم صندوق رمل وكيل Novita لسير عمل وكيل الذكاء الاصطناعي التي تحتاج تنفيذ كود معزول، وأتمتة متصفح، ومهام من نوع استخدام الكمبيوتر، وجلسات طويلة الأمد، وأعباء عمل التقييم أو التعلم التعزيزي. نظرة عامة على صندوق رمل وكيل Novita هي نقطة البداية الصحيحة لسلوك المنتج الحالي، ويصف صفحة منتج صندوق رمل الوكيل الملاءمة الأوسع للمنصة.
عند تقييم Novita أو أي مزود صندوق رمل آخر لأعباء العمل الحساسة لـ DNS، افصل بين نوعين من العبارات:
- ملاءمة المنتج: ما إذا كان صندوق الرمل يدعم سير عمل الوكيل الذي تحتاجه، مثل تنفيذ الكود أو أتمتة المتصفح أو المهام طويلة الأمد.
- دليل الضوابط الأمنية: ما إذا كانت ضوابط DNS الدقيقة، والخروج، وجلب الحزم، والأسرار، والسجلات تلبي سياستك الداخلية.
هذا الفصل يمنع الادعاء المفرط. يمكن أن يكون صندوق الرمل ملائماً بقوة لتنفيذ الوكيل ولا يزال يتطلب مراجعة عميل محددة لسياسة DNS، ومسار المحلل، وقوائم السماح، والاحتفاظ بالتدقيق، وسير عمل الحوادث. يجب على فرق الأمان طلب الوثائق الحالية أو تأكيد المنتج لتلك التفاصيل الضابطة قبل الموافقة على أعباء العمل الحساسة.
بالنسبة للفرق التي تستخدم بالفعل نماذج Novita AI، فإن ملاءمة المنصة هي أنه يمكن تقييم واجهات برمجة تطبيقات النموذج والبنية التحتية لتنفيذ الوكيل معاً. يمكن أن يقلل ذلك من الانتشار التشغيلي، لكنه لا يلغي الحاجة إلى نموذج تهديد. تعامل مع صندوق الرمل كبيئة تنفيذ خاضعة للتحكم، وحدد الوصول الشبكي الذي تحتاجه كل فئة وكيل، وتحقق من أن أدلة التحكم تطابق خطر البيانات الموضوعة بداخله.
قائمة مراجعة الأمان
استخدم قائمة المراجعة هذه قبل الموافقة على أعباء عمل صندوق رمل وكيل الذكاء الاصطناعي التي قد تمس كوداً حساساً أو بيانات اعتماد أو بيانات عميل أو أنظمة داخلية.
| سؤال المراجعة | لماذا هو مهم |
|---|---|
| ما الذي يمكن لصندوق الرمل حله افتراضياً؟ | يمكن أن تكون DNS إشارة صادرة حتى عندما يكون HTTP محظوراً. |
| هل يمكن تقييد DNS حسب النطاق أو القالب أو مساحة العمل أو سياسة VPC؟ | أعباء العمل الحساسة تحتاج افتراضيات أضيق من مهام البحث العامة. |
| هل يتم تسجيل استعلامات DNS لكل جلسة صندوق رمل؟ | الاستجابة للحوادث تحتاج إلى إسناد، وليس فقط مقاييس المحلل الإجمالية. |
| هل يتم تسجيل محاولات DNS والاتصال المرفوضة؟ | الأحداث المرفوضة تثبت أن السياسة حظرت سلوكاً غير متوقع. |
| هل سجلات الحزم مدرجة في قائمة السماح أو موكلة؟ | يمكن لمديري الحزم تشغيل DNS وتنزيلات تعتمد على التبعيات. |
| هل يمكن فصل تثبيتات الحزمة عن وصول الشبكة لوقت التشغيل؟ | خطر وقت البناء ووقت التشغيل مختلفان. |
| هل نطاقات IP الداخلية ونقاط نهاية البيانات الوصفية محظورة؟ | لا ينبغي للوكلاء اكتشاف أو الاتصال بمستويات التحكم في البنية التحتية عن طريق الصدفة. |
| كيف يتم حقن الأسرار وتحديد نطاقها وتدويرها وتنقيحها؟ | مراجعة DNS غير مكتملة إذا كانت الأسرار طويلة الأمد متاحة للكود في صندوق الرمل. |
| هل الموارد الفرعية للمتصفح مرئية في السجلات؟ | وكلاء المتصفح قد يحلون نطاقات أكثر من عنوان URL الأعلى. |
| ما هي الأدلة المتاحة بعد الإيقاف المؤقت أو الاستئناف أو اللقطة أو التنظيف؟ | الجلسات الطويلة تحتاج تليمترية واعية بدورة الحياة. |
| من يمكنه تخفيف سياسة الخروج؟ | يجب أن تكون تغييرات الاستثناء قابلة للتدقيق. |
| كيف يتم الحفاظ على الجلسات المشبوهة؟ | لا ينبغي للتنظيف أن يمحو الدليل الوحيد المفيد للحادث. |
إذا كانت عدة إجابات غير معروفة، أبقِ عبء العمل خارج صندوق الرمل حتى يتمكن المزود أو فريق المنصة الداخلي من توثيق مسار التحكم. إذا كان عبء العمل يتعامل فقط مع البيانات العامة ولا يستخدم أي أسرار، فقد تكون نفس الفجوات مقبولة خلال النمذجة الأولية، لكن يجب تتبعها قبل الاستخدام الإنتاجي.
الخلاصة
بالنسبة لصناديق الرمل الإنتاجية للوكلاء، راجع DNS كجزء من الخروج، وليس كحاشية. الإعداد الدفاعي الأدنى هو سياسة خروج محددة النطاق، وحوكمة صريحة لجلب الحزم، وأسرار قصيرة الأمد، وسجلات لجلسات DNS والاتصالات، وسير عمل حوادث مُختبر لحفظ الأدلة.
استخدم وصولاً شبكياً أوسع للنماذج الأولية منخفضة المخاطر فقط عندما تكون البيانات غير حساسة وليس لدى الوكيل أسرار ذات معنى. بالنسبة لقواعد البيانات الحساسة أو بيانات العملاء أو واجهات برمجة التطبيقات الداخلية أو سير العمل الخاضع للتنظيم، اطلب ملف تعريف خروج أدنى وأدلة حالية من المزود قبل منح الوكلاء تنفيذاً مستقلاً.
الأسئلة الشائعة
هل تسريب DNS ذو صلة إذا كان صندوق الرمل يحظر HTTP؟
نعم. ضوابط HTTP وضوابط DNS طبقات مختلفة. قد يحظر صندوق الرمل طلبات الويب الصادرة مع الاستمرار في السماح باستعلامات DNS. يجب على فرق الأمان التحقق من كل من سياسة الحل وسياسة الاتصال.
هل يجب ألا تحتوي صناديق الرمل لوكلاء الذكاء الاصطناعي على وصول إلى الإنترنت؟
ليس دائماً. العديد من مهام الوكيل المفيدة تحتاج سجلات الحزم والوثائق العامة وواجهات برمجة التطبيقات أو الوصول إلى المتصفح. الهدف الأكثر أماناً هو خروج أدنى وقابل للتفسير: اسمح بما تحتاجه المهمة، ارفض ما لا تحتاجه، وسجل النشاط المسموح به والمرفوض.
هل تثبيتات الحزم هي نفس الوصول الشبكي العام؟
لا. تستحق تثبيتات الحزم سياسة منفصلة لأنها تتضمن سجلات وحل التبعيات وتنزيل القطع الأثرية وأحياناً برامج وقت التثبيت. قد يسمح الفريق بعمليات جلب الحزم من خلال ذاكرة تخزين مؤقتة معتمدة مع رفض الخروج التعسفي لوقت التشغيل.
ما هي السجلات الأكثر أهمية لخطر DNS؟
السجلات الأكثر فائدة هي تلك التي تربط استعلام DNS بصندوق رمل وأمر ووقت ومستخدم أو سير عمل وكيل وقرار سياسة محددين. سجلات البحث المرفوضة مهمة بشكل خاص لأنها تظهر ما إذا كان التحكم قد عمل بالفعل.
هل يمكن لمزود صندوق الرمل ضمان عدم تسريب البيانات؟
كن حذراً مع الضمانات المطلقة. يمكن للمزود تقديم العزل وضوابط الشبكة والتسجيل وخيارات التكوين، لكن الخطر النهائي يعتمد على تصميم سير العمل والأسرار ووضع البيانات وسياسة الخروج والمراقبة التشغيلية.
