- لماذا تحتاج صناديق حماية وكلاء الذكاء الاصطناعي إلى تسجيل تدقيق مختلف
- سجلات تنفيذ الأوامر والعمليات
- أحداث الوصول إلى نظام الملفات
- استدعاءات الشبكة الصادرة وتسجيل التدفق الصادر
- أحداث تثبيت الحزم
- استدعاءات الأدوات والنتائج
- أحداث دورة حياة الجلسة
- أحداث حدود الموارد
- تنسيقات السجلات المهيكلة مقابل غير المهيكلة
- سلامة السجلات ودليل العبث
- سياسات الاحتفاظ بسجل التدقيق لصناديق حماية وكلاء الذكاء الاصطناعي
- إظهار السجلات للاستجابة للحوادث
- ماذا تسأل مزود صندوق الحماية الخاص بك
- الخاتمة
- الأسئلة الشائعة
- مقالات مقترحة
يجب أن تلتقط سجلات التدقيق لصناديق حماية وكلاء الذكاء الاصطناعي تنفيذ الأوامر والعمليات، وقراءة وكتابة الملفات، واستدعاءات الشبكة الصادرة ووجهات التدفق الصادر، وأحداث تثبيت الحزم، واستدعاءات الأدوات، وملخصات المدخلات والمخرجات للنموذج على مستوى الجلسة، وأحداث الوصول إلى حدود الموارد، وأحداث دورة حياة الجلسة. بدون هذه التغطية، لا يستطيع فريق الأمان إعادة بناء ما فعله الوكيل، أو تتبع اختراق، أو تلبية متطلبات مراجعة ما بعد الحادث. الثغرات في أي من هذه الفئات تترك نقاطًا عمياء يصعب أو يستحيل سدها بأثر رجعي.
لماذا تحتاج صناديق حماية وكلاء الذكاء الاصطناعي إلى تسجيل تدقيق مختلف
تفترض سجلات تدقيق الخوادم التقليدية أن إجراءً ما تم تشغيله بواسطة إنسان أو عملية تطبيق حتمية. وكلاء الذكاء الاصطناعي يكسرون هذا الافتراض. يمكن لموجه واحد أن يتسبب في قيام جلسة بتثبيت حزم، وكتابة ملفات، وتشغيل أوامر شل، واستدعاء واجهات برمجة تطبيقات خارجية، وإنشاء عمليات فرعية — كل ذلك في ثوانٍ، دون موافقة بشرية على الخطوات الفردية.
هذا يغير ما يجب أن تجيب عليه سجل التدقيق. بالنسبة للخادم التقليدي، السؤال عادة هو “هل قام مستخدم مخول بتغيير هذا الملف؟” بالنسبة لصندوق حماية الوكيل، الأسئلة هي:
- ما الذي قرر النموذج تنفيذه، وبأي ترتيب؟
- ما هي أوامر الشل التي تم تشغيلها، وكأي عملية؟
- هل وصل الوكيل إلى ملفات لم يكن من المتوقع أن يلمسها؟
- ما الذي غادر صندوق الحماية عبر الشبكة، وأين ذهب؟
- هل أدى تثبيت حزمة إلى إدخال تعليمات برمجية غير متوقعة؟
- ماذا كان الوكيل يفعل عندما وصل إلى حد الموارد أو تم إنهاؤه؟
نظام السجلات الذي يمكنه الإجابة على هذه الأسئلة يمنح فرق الأمان قدرة إعادة البناء التي يحتاجونها. نظام السجلات الذي لا يستطيع ذلك يترك الاستجابة للحوادث في حالة تخمين.
سجلات تنفيذ الأوامر والعمليات
تنفيذ العمليات هو الفئة الأعلى أولوية. كل أمر يشغله الوكيل — مباشرة أو من خلال عملية فرعية من شل — يجب أن ينتج إدخال سجل يتضمن: اسم العملية وقائمة الوسائط الكاملة، العملية الأب ومعرف العملية (PID)، المستخدم ومعرف المستخدم الفعّال (UID)، دليل العمل، الطابع الزمني بدقة أقل من الثانية، ورمز الخروج.
بدون قائمة الوسائط، تكون الأوامر مثل python أو curl أو bash عديمة المعنى تقريبًا في تتبع ما بعد الحادث. بدون UID، لا يمكنك معرفة ما إذا كان الوكيل يعمل بصلاحيات مرتفعة. بدون سلسلة PID الأب، لا يمكنك إعادة بناء العمليات الفرعية المتداخلة أو فهم كيفية استدعاء الأمر.
يمكن لأنظمة تدقيق لينكس مثل auditd مع قواعد استدعاء النظام المناسبة (execve، execveat) التقاط هذا على مستوى النواة داخل جهاز ضيف صغير (microVM). يمكن لصناديق الحماية القائمة على الحاويات استخدام التتبع القائم على eBPF أو تسجيل seccomp كبديل، على الرغم من أن لكل نهج تغطية ومقايضات أداء مختلفة. الشرط الرئيسي من منظور فريق الأمان هو أن يتم إنشاء السجل أسفل طبقة التطبيق — لا يمكن الوثوق في عملية وكيل تتحكم في تسجيلها الخاص للإبلاغ عن سلوكها بدقة.
أحداث الوصول إلى نظام الملفات
يجب أن تسجل تغطية تدقيق نظام الملفات عمليات القراءة والكتابة والحذف وإعادة التسمية والتركيب. لكل حدث، يجب أن يتضمن السجل: نوع العملية، المسار الكامل، العملية ومعرف العملية المسؤولة، UID، والطابع الزمني.
من الناحية العملية، يمكن أن يؤدي تسجيل كل قراءة ملف في صندوق حماية مشغول إلى حجم كبير. غالبًا ما تقوم فرق الأمان بتضييق ذلك إلى المسارات الحساسة — على سبيل المثال، أي مسار تحت /etc، /root، مساحة عمل الوكيل، مواقع ملفات بيانات الاعتماد، والأسرار المثبتة. الكتابة والحذف لهما أولوية أعلى من القراءة بالنسبة لمعظم نماذج التهديد، لكن قراءة ملفات بيانات الاعتماد أو التكوين تستحق التسجيل بغض النظر.
تعتبر أحداث نظام الملفات مفيدة بشكل خاص لتحديد محاولات تسريب البيانات (قراءات كبيرة تليها استدعاءات شبكة صادرة)، وتغييرات التكوين غير المتوقعة (كتابات لملفات لا ينبغي للوكيل لمسها)، وسلوك التنظيف (عمليات حذف يتم تنفيذها في نهاية الجلسة، والتي قد تشير إلى محاولة إخفاء النشاط).
استدعاءات الشبكة الصادرة وتسجيل التدفق الصادر
تسجيل التدفق الصادر هو أحد المجالات الأكثر شيوعًا التي لم يتم تحديدها بشكل كافٍ في نشر صناديق حماية الوكيل. العديد من صناديق الحماية تسجل أنه تمت محاولة اتصال شبكة؛ القليل منها يسجل أين ذهب، وما البروتوكول المستخدم، وما إذا كان ناجحًا.
يجب أن تتضمن إدخالات سجل التدفق الصادر الكاملة: عنوان IP الوجهة والمنفذ، اسم النطاق الذي تم حله (استعلام DNS والإجابة)، البروتوكول (TCP، UDP، HTTP، إلخ)، البايتات المنقولة في كل اتجاه، العملية التي فتحت الاتصال، UID، والطابع الزمني.
تسجيل استعلامات DNS مهم بشكل منفصل. الوكيل الذي يستعلم عن نطاق غير متوقع — حتى لو تم حظر الاتصال لاحقًا — هو إشارة تستحق التسجيل. يمكن لـ DNS عبر HTTPS تجاوز تسجيل الاستعلام ما لم يفرض صندوق الحماية سياسة الشبكة على مستوى يعترضه.
يجب على صناديق الحماية التي توفر ضوابط تدفق صادر قائمة على القائمة المسموح بها تسجيل كل من محاولات الاتصال المسموح بها والمحظورة. ارتفاع حجم المحاولات المحظورة إلى وجهات غير متوقعة هو بحد ذاته إشارة أمنية مهمة.
أحداث تثبيت الحزم
تثبيت الحزم هو هدف تدقيق عالي القيمة لأنه يغير بيئة التشغيل بطرق تستمر طوال مدة الجلسة وربما تؤثر على العمليات اللاحقة. يجب أن يلتقط كل حدث تثبيت: مدير الحزم المستدعى (pip، npm، apt، cargo، إلخ)، اسم الحزمة، الإصدار المطلوب، الإصدار الذي تم حله، عنوان URL المصدر أو السجل، تجزئة الحزمة أو المجموع الاختباري، العملية و UID، والطابع الزمني.
عنوان URL المصدر مهم. الحزمة المثبتة من سجل خاص، أو عنوان URL مباشر، أو مرآة غير عادية لها ملف تعريف مخاطر مختلف عن تلك المثبتة من السجل العام الافتراضي. التجزئة مهمة للتحقق بعد الحادث — إذا تم العثور لاحقًا على أن حزمة ما ضارة، فأنت تريد معرفة ما إذا كان هذا الإصدار بالضبط قد تم تثبيته في جلسة معينة.
صناديق الحماية التي تمنع تثبيت الحزم تمامًا تقضي على فئة المخاطر هذه ولكنها أيضًا تقيد بشكل كبير ما يمكن للوكلاء فعله. تحتاج معظم عمليات النشر الإنتاجية إلى مسار وسيط: تسجيل كل شيء، السماح بالتثبيت من قائمة مصادر معتمدة، ووضع علامة أو حظر التثبيت من مصادر غير معروفة.
استدعاءات الأدوات والنتائج
عادةً ما يعمل وكلاء الذكاء الاصطناعي من خلال آلية استدعاء أداة حيث يطلب النموذج إجراءً مسمى — تشغيل كود، قراءة ملف، استدعاء API، بحث في الويب — وتقوم طبقة التنسيق بتنفيذه. هذه الاستدعاءات للأدوات تقع فوق مستوى نظام التشغيل وهي أحداث على مستوى التطبيق، لكن من المهم تسجيلها لأنها تمثل نية النموذج بدلاً من مجرد العواقب على مستوى النظام.
يجب أن تلتقط سجلات استدعاء الأداة: اسم الأداة، ملخص لمعلمات الإدخال (وليس المحتوى الكامل إذا كان سيتضمن أسرارًا أو معلومات تعريف شخصية للمستخدم)، ملخص لحالة النتيجة (نجاح، خطأ، مهلة)، معرف الجلسة، والطابع الزمني.
تسجيل الإدخال والإخراج الكاملين لكل استدعاء أداة مفيد لتصحيح الأخطاء ولكنه يخلق مخاطر تتعلق بالخصوصية وتسرب الأسرار. النهج العملي هو تسجيل أسماء الأدوات والحالات دون قيد أو شرط، تسجيل ملخصات الإدخال/الإخراج بمستوى تفصيل قابل للتكوين، وتوفير طريقة لاسترداد التفاصيل الكاملة لجلسات محددة أثناء التحقيق مع ضوابط الوصول المناسبة.
الهدف هو إشارة كافية لإعادة بناء تسلسل إجراءات الوكيل دون إنشاء مخزن سجلات يصبح بحد ذاته هدفًا عالي القيمة.
أحداث دورة حياة الجلسة
أحداث دورة حياة الجلسة ترسخ جميع إدخالات السجل الأخرى. معرف الجلسة الذي يظهر في كل نوع حدث يجعل من الممكن ربط السجلات عبر الفئات والإجابة على “ماذا حدث في هذا التشغيل المحدد؟”
أحداث دورة الحياة للتسجيل:
| الحدث | الحقول الرئيسية |
|---|---|
| إنشاء الجلسة | معرف الجلسة، معرف المستخدم/المستأجر، اسم القالب أو الصورة، تكوين الموارد، الطابع الزمني |
| بدء الجلسة | معرف الجلسة، معرف المضيف، حدود الموارد المخصصة، الطابع الزمني |
| إيقاف الجلسة مؤقتًا | معرف الجلسة، السبب (استدعاء API، مهلة، إيقاف تلقائي)، الطابع الزمني |
| استئناف الجلسة | معرف الجلسة، الجهة المستأنفة، الطابع الزمني |
| إنهاء الجلسة | معرف الجلسة، سبب الإنهاء (عادي، مهلة، نفاد الذاكرة OOM، استدعاء API، انتهاك سياسة)، حالة الخروج، الطابع الزمني |
| تنظيف الجلسة | معرف الجلسة، حالة نظام الملفات عند التنظيف (محفوظ، محذوف، حفظ لقطة)، الطابع الزمني |
سبب الإنهاء مفيد بشكل خاص بعد الحادث. الجلسة التي تم إنهاؤها بسبب انتهاك سياسة، أو قتل بسبب OOM، أو إشارة غير متوقعة بدلاً من خروج نظيف تستحق الفحص الدقيق. الجلسات التي تم إيقافها مؤقتًا ثم استئنافها تستحق الفحص لاستمرارية الحالة — هل تغير أي شيء في البيئة بين الإيقاف المؤقت والاستئناف؟
أحداث حدود الموارد
أحداث حدود الموارد تلتقط اللحظات التي وصلت فيها الجلسة إلى سقف تم تكوينه واتخذ النظام إجراءً. تشير هذه الأحداث إما إلى سلوك تحميل عادي مرتفع أو شيء أكثر إثارة للقلق — عملية جامحة، أو طفرة حسابية غير متوقعة، أو محاولة متعمدة لاستنزاف الموارد.
يجب أن تتضمن إدخالات السجل لأحداث حدود الموارد: نوع الحد (تقييد وحدة المعالجة المركزية CPU، نفاد الذاكرة OOM، حصة القرص، حد معدل الشبكة، مهلة)، القيمة المقاسة في وقت الحدث، الحد المكون، الإجراء المتخذ (تقييد، قتل، تحذير)، العملية أو الجلسة المتأثرة، والطابع الزمني.
عمليات القتل بسبب OOM تستحق الفحص بشكل خاص لأنها قد تشير إلى أن الوكيل كان يحاول إجراء عملية حسابية كبيرة لم تكن متوقعة، أو حزمة تم تحميلها ببيانات كبيرة بشكل غير متوقع، أو تسرب ذاكرة. أحداث تقييد وحدة المعالجة المركزية في جلسة من المفترض أن تقوم فقط باستدعاءات LLM خفيفة قد تشير إلى أن شيئًا آخر يعمل داخل صندوق الحماية.
تنسيقات السجلات المهيكلة مقابل غير المهيكلة
السجلات غير المهيكلة — أسطر نصية حرة مثل 2026-06-29 10:04:00 INFO: process python started — قابلة للقراءة ولكن يصعب الاستعلام عنها أو تجميعها أو دمجها مع SIEM أو خط تنبيه. لأغراض التدقيق، تتطلب تحليلاً ينكسر عندما يتغير تنسيق السجل.
السجلات المهيكلة — عادةً JSON أو تنسيق مخطط شائع مثل CEF أو OCSF — تسمح بفهرسة كل حقل والاستعلام عنه والتنبيه عليه مباشرة. حدث execve مهيكل يتضمن {"ts": "2026-06-29T10:04:00.123Z", "event": "process.exec", "session_id": "...", "pid": 1234, "ppid": 1, "uid": 0, "cmd": "curl", "args": ["-s", "https://..."], "exit_code": 0} يمكن الاستعلام عنه فورًا بواسطة أي من حقوله.
بالنسبة لفرق الأمان التي تقوم بتقييم مزود صندوق حماية، الأسئلة الرئيسية هي:
- هل السجلات مهيكلة أم غير مهيكلة؟
- ما المخطط أو التنسيق المستخدم، وهل هو موثق؟
- هل يمكن بث السجلات في الوقت الفعلي إلى SIEM خارجي أو نظام تجميع سجلات؟
- ما هو زمن الوصول بين الحدث وتوفره في تدفق السجل؟
البث في الوقت الفعلي أو شبه الفعلي مهم لحالات استخدام الكشف. السجل المتاح فقط بعد ساعات من انتهاء الجلسة مفيد لإعادة بناء الحادث ولكن ليس للتنبيه المباشر.
سلامة السجلات ودليل العبث
سجل التدقيق الذي يمكن للوكيل تعديله ليس سجل تدقيق. هذا هو شرط دليل العبث: يجب إنشاء السجل وتخزينه بطريقة لا تستطيع عملية الوكيل تغيير أو حذف أو قمع إدخالاتها الخاصة.
على مستوى التنفيذ، هذا يعني عادةً:
- إنشاء السجل على مستوى النواة (نظام التدقيق، eBPF) بدلاً من التسجيل على مستوى التطبيق داخل صندوق الحماية
- شحن السجل إلى وجهة خارجية لا تستطيع عملية صندوق الحماية الوصول إليها
- تخزين سجل للكتابة مرة واحدة أو للإلحاق فقط بدون واجهة برمجة تطبيقات للحذف يمكن الوصول إليها من شبكة صندوق الحماية
- إدخالات السجل موقعة أو ذات مجموع اختباري عند الإنشاء بحيث يمكن اكتشاف العبث أو الاقتطاع بعد ذلك
بالنسبة لمزودي صناديق الحماية المدارة، السؤال ذو الصلة هو ما إذا كانت عملية الوكيل لديها أي مسار لتعديل تسليم السجل. إذا تمت كتابة السجلات إلى ملف داخل صندوق الحماية ثم شحنها، فقد تتمكن عملية وكيل ذات صلاحيات كافية من التدخل في الشحن. إذا تم إنشاء السجلات على مستوى برنامج المراقبة (hypervisor) أو المضيف وشحنها خارج النطاق، فلن يكون للوكيل أي وصول.
سلسلة الحضانة لبيانات السجل — المهمة بشكل خاص للامتثال أو المراجعة القانونية — تتطلب أن يكون مسار جمع السجل وضوابط الوصول للتخزين وأي تحويلات يتم تطبيقها على الأحداث الأولية موثقة وقابلة للتدقيق بأنفسها.
سياسات الاحتفاظ بسجل التدقيق لصناديق حماية وكلاء الذكاء الاصطناعي
تعتمد متطلبات الاحتفاظ بسجلات تدقيق صندوق حماية وكيل الذكاء الاصطناعي على البيئة التنظيمية، وملف مخاطر أعباء العمل، والجدول الزمني للاستجابة للحوادث الذي يحتاجه فريق الأمان لدعمه.
نقاط بداية عملية لفرق الأمان لتقييمها:
| حالة الاستخدام | الحد الأدنى المقترح للاحتفاظ |
|---|---|
| التحقيق النشط في الحوادث | ساخن/قابل للاستعلام لمدة 90 يومًا على الأقل |
| الطب الشرعي بعد الحادث | متوفر في التخزين البارد لمدة 12–24 شهرًا |
| مراجعة الامتثال (SOC 2، ISO 27001) | حسب متطلبات الإطار المعمول به |
| الحجز القانوني | حتى الإفراج الصريح |
بالنسبة لأعباء عمل وكيل الذكاء الاصطناعي، 90 يومًا من التخزين الساخن هو خط أساس ذو مغزى لأن أنماط الاختراق في الوكلاء المستقلين قد لا يتم اكتشافها فورًا — الوكيل الذي قام بتسريب بيانات خلال جلسة قبل ثلاثة أسابيع قد لا يتم التعرف عليه حتى يتم ملاحظة شذوذ في مرحلة لاحقة.
الحجم هو عامل تكلفة حقيقي. يمكن لصندوق حماية يشغل آلاف الجلسات يوميًا مع تسجيل كامل لـ execve والشبكة أن يولد كمية كبيرة من البيانات. التخزين المتدرج — ساخن للبيانات الحديثة، دافئ للمدى المتوسط، بارد للأرشفة — هو نهج شائع. الضغط والتصفية على مستوى الحقل (تسجيل أنواع الأحداث عالية الأولوية فقط بكامل الدقة) جديران بالاعتبار أيضًا، مع المفاضلة أن السجلات المصفاة قد تفوت أنواع الأحداث غير المتوقعة.
إظهار السجلات للاستجابة للحوادث
جمع السجلات ضروري لكنه غير كافٍ. السجلات التي تبقى في حاوية لا يستعلم عنها أحد لا تقدم أي حماية. بالنسبة لفرق الأمان، المتطلب التشغيلي هو القدرة على الإجابة على أسئلة محددة بسرعة:
- ماذا فعلت الجلسة X بين الوقت T1 و T2؟
- ما الجلسات التي وصلت إلى المسار P؟
- ما الجلسات التي أجرت اتصالات صادرة إلى النطاق D؟
- ما الجلسات التي قامت بتثبيت الحزمة V؟
- ما الجلسات التي تم إنهاؤها بالسبب R؟
يتطلب هذا واجهة استعلام — إما تكامل SIEM، أو منصة تحليلات سجلات، أو API يوفره المزود — حيث يتم فهرسة معرف الجلسة ونوع الحدث ونطاق الطابع الزمني والمسار والنطاق والحقول الرئيسية الأخرى وجعلها قابلة للبحث.
التنبيه على أنماط محددة هو الطبقة الثانية. الإشارات عالية الأولوية لصناديق حماية وكلاء الذكاء الاصطناعي تشمل: تنفيذ أوامر معروفة بأنها خطيرة (curl | bash، wget -O - | sh، base64 -d | sh)، اتصالات صادرة إلى نطاقات غير متوقعة أو مسجلة حديثًا، تثبيت حزم من عناوين URL غير مسجلة، أحداث كتابة إلى مسارات ملفات بيانات الاعتماد، جلسات تنتهي بانتهاك سياسة أو قتل OOM، وأي حدث يحدث تحت UID 0 عندما لا ينبغي للوكيل أن يعمل كجذر.
قواعد الكشف المعدة مسبقًا والمعايرة لأنماط سلوك صندوق حماية الوكيل تقلل من الوقت حتى أول تنبيه للنشاط الجديد. يجب أن تسأل فرق الأمان التي تقوم بتقييم مزودي صناديق الحماية عما إذا كان المزود يوفر قواعد الكشف، وتوثيق مخطط السجل، وتكاملات SIEM نموذجية، أم أن بناء هذه الطبقة متروك بالكامل للعميل.
ماذا تسأل مزود صندوق الحماية الخاص بك
عند تقييم صندوق حماية وكيل ذكاء اصطناعي لتغطية سجل التدقيق، هذه هي الأسئلة الملموسة التي تستحق طرحها على المزود:
- ما فئات الأحداث التي يتم تسجيلها افتراضيًا، وما الذي يتطلب تكوينًا؟
- هل يتم إنشاء السجلات على مستوى النواة/برنامج المراقبة، أم داخل عملية صندوق الحماية؟
- ما تنسيق السجل المهيكل المستخدم، وهل المخطط موثق علنًا؟
- هل يمكن بث السجلات في الوقت الفعلي إلى وجهة خارجية؟
- ما هي سياسة الاحتفاظ بالبيانات، وهل يمكن تمديدها؟
- هل لدى عملية صندوق الحماية أي مسار لتعديل أو قمع إدخالات السجل الخاصة بها؟
- هل إدخالات السجل موقعة أو مقاومة للعبث بأي شكل آخر؟
- هل هناك واجهة برمجة تطبيقات للاستعلام أو تكامل SIEM متاح؟
- هل هناك قواعد كشف مبنية مسبقًا أو قوالب تنبيه لأنماط تهديد صندوق الحماية الشائعة؟
لا يكتمل أي نشر لصندوق حماية من حيث التسجيل افتراضيًا. الثغرات بين ما يجمعه المزود وما يحتاجه فريق الأمان لإعادة بناء حادث شائعة. تحديد تلك الثغرات قبل النشر، وليس بعد وقوع حادث، هو المكسب العملي من هذا النوع من التقييم.
يوفر صندوق حماية وكيل Novita أحداث دورة حياة الجلسة وسجلات التنفيذ ومقاييس الموارد التي يمكن الوصول إليها من خلال API الخاص به. يجب على فرق الأمان التي تقوم بتقييم صندوق حماية وكيل Novita التحقق من تغطية السجل الحالية وخيارات التصدير وتكوين الاحتفاظ في وثائق المنتج قبل اتخاذ قرارات الهندسة المعمارية.
الخاتمة
تسجيل التدقيق لصناديق حماية وكلاء الذكاء الاصطناعي ليس ميزة يمكنك إضافتها بعد وقوع حادث. فئات الأحداث الهامة — تنفيذ العمليات، الوصول إلى نظام الملفات، حركة المرور الصادرة، تثبيت الحزم، استدعاءات الأدوات، دورة حياة الجلسة، وحدود الموارد — يجب أن تكون في النطاق قبل أن يدخل عبء العمل إلى مرحلة الإنتاج، ويجب أن يكون مسار جمع السجل خارج نطاق وصول الوكيل.
القائمة العملية لفرق الأمان واضحة ومباشرة: حدد فئات الأحداث التي يلتقطها مزود صندوق الحماية الخاص بك افتراضيًا، وتأكد من إنشاء السجلات على مستوى النواة أو برنامج المراقبة بدلاً من داخل عملية الوكيل، وتحقق من توفر المخرجات المهيكلة لتكامل SIEM، وحدد سياسات الاحتفاظ قبل أن تحتاجها للتحقيق.
الثغرات في أي من هذه المجالات هي ثغرات في قدرتك على الإجابة على “ماذا فعل هذا الوكيل؟” — وبالنسبة للوكلاء المستقلين الذين يعملون على نطاق واسع، فإن هذا السؤال سيحتاج في النهاية إلى إجابة.
الأسئلة الشائعة
ما الأحداث التي يجب أن تلتقطها سجلات تدقيق صندوق حماية وكيل الذكاء الاصطناعي؟
كحد أدنى: تنفيذ الأوامر والعمليات (مع قوائم الوسائط الكاملة)، قراءة/كتابة/حذف نظام الملفات، اتصالات الشبكة الصادرة واستعلامات DNS، أحداث تثبيت الحزم مع عناوين URL المصدر والتجزئات، استدعاءات الأدوات وحالة النتيجة، أحداث دورة حياة الجلسة (إنشاء، إيقاف مؤقت، استئناف، إنهاء، تنظيف)، وأحداث حدود الموارد (تقييد CPU، قتل OOM، مهلة). يؤدي فقدان أي من هذه الفئات إلى ترك نقاط عمياء لا يمكن إعادة بنائها بعد وقوع الحادث.
لماذا لا يمكنني الاعتماد على التسجيل على مستوى التطبيق داخل صندوق الحماية؟
عملية الوكيل التي تتحكم في التسجيل الخاص بها يمكنها قمع أو تعديل إدخالات حول سلوكها — عن قصد أو من خلال خطأ. الجمع على مستوى النواة (عبر auditd أو eBPF أو أدوات برنامج المراقبة) ينشئ إدخالات سجل أسفل طبقة التطبيق، حيث لا يتمتع الوكيل بحق الوصول للكتابة. هذا هو شرط دليل العبث: يجب إنشاء السجل في مكان لا يمكن للوكيل الوصول إليه.
كم من الوقت يجب الاحتفاظ بسجلات تدقيق صندوق حماية وكيل الذكاء الاصطناعي؟
خط أساس عملي: 90 يومًا في تخزين ساخن قابل للاستعلام للتحقيق النشط، 12-24 شهرًا في تخزين بارد للطب الشرعي بعد الحادث. أطر الامتثال مثل SOC 2 و ISO 27001 لها متطلباتها الخاصة التي قد تحل محل هذه الخطوط الأساسية. بالنسبة للحجز القانوني، يجب أن يستمر الاحتفاظ حتى يتم الإفراج عنه صراحةً من قبل المستشار القانوني.
ما الفرق بين سجلات التدقيق المهيكلة وغير المهيكلة؟
السجلات غير المهيكلة هي أسطر نصية حرة تتطلب تحليلاً للاستعلام. السجلات المهيكلة تستخدم مخططًا ثابتًا (JSON، CEF، OCSF) حيث يتم فهرسة كل حقل والاستعلام عنه مباشرة. لعمليات الأمان، السجلات المهيكلة أسهل بكثير في التكامل مع منصات SIEM، وكتابة قواعد الكشف لها، والاستعلام عنها أثناء الاستجابة للحوادث.
هل يمكن لوكيل الذكاء الاصطناعي العبث بسجلات التدقيق الخاصة به؟
يعتمد ذلك على مكان إنشاء السجلات وتخزينها. إذا تمت كتابة السجلات إلى ملف داخل صندوق الحماية وشحنها خارجيًا، فقد تتداخل عملية وكيل ذات صلاحيات كافية مع خط أنابيب الشحن. إذا تم إنشاء السجلات على مستوى برنامج المراقبة أو المضيف وكتابتها مباشرة إلى وجهة خارجية لا تستطيع شبكة صندوق الحماية الوصول إليها، فلن يكون لدى الوكيل أي مسار لتعديلها. تحقق دائمًا من بنية جمع السجل، وليس فقط تنسيق السجل.
ما الذي يجب أن أبحث عنه في توثيق سجل تدقيق مزود صندوق الحماية؟
تأكد من: فئات الأحداث التي يتم تسجيلها افتراضيًا مقابل تلك التي تتطلب تكوينًا؛ ما إذا كانت السجلات يتم إنشاؤها على مستوى النواة/برنامج المراقبة أم داخل عملية صندوق الحماية؛ ما هو التنسيق المهيكل والمخطط المستخدم؛ ما إذا كان البث في الوقت الفعلي إلى الأنظمة الخارجية مدعومًا؛ ما هي سياسة الاحتفاظ الافتراضية وهل يمكن تمديدها؛ وما إذا كانت قواعد الكشف المبنية مسبقًا أو تكاملات SIEM متاحة.
