Google SecOps يؤتمت القضية كاملة، لكن المعاينة تستثني بعض السجلات
سجّلت Google في 6 سبتمبر 2026 دعم Case playbooks في Google SecOps بمرحلة المعاينة. ووفق ملاحظات إصدار Google Cloud، تستطيع فرق مركز العمليات الأمنية تشغيل Playbook أو تنفيذ إجراء يدوي على حاوية القضية كاملة بدل تكرار التنفيذ لكل تنبيه، بما يوحّد مهام الاستجابة ويحد من العمليات الزائدة.
عمليًا، يبدأ الاستخدام في 6 سبتمبر 2026 بإنشاء Playbook واختيار Case كنطاق له، ثم تخصيصه للأعمال المشتركة بين تنبيهات القضية. غير أن الميزة ما زالت Preview وليست إصدارًا عامًا؛ وهي لا تستخرج البيانات إلا من التنبيهات المفتوحة، كما تُستثنى سجلات تنفيذها من Legacy Monitoring وصادرات SOAR القديمة.
متى يستحق الإجراء الانتقال إلى نطاق Case؟
المرشح المناسب هو الإجراء الذي يجب أن يحدث مرة واحدة للحادث كله، لا مرة لكل تنبيه. يشمل ذلك فتح تذكرة تتبع واحدة في نظام ITSM، أو إرسال إشعار موحد إلى الفريق، أو إثراء عنوان IP مشترك بين تنبيهات متعددة. أما القرار الذي يعتمد على خصائص تنبيه بعينه، فيظل نطاق Alert أو منطق يحافظ على سياق كل تنبيه أنسب له.
تظهر هنا ملاحظة زمنية مهمة: كانت مراجعة مجتمع Google SecOps المنشورة في 13 يوليو قد وصفت Case playbooks بالفعل بأنها ميزة Pre-GA، وشرحت نطاق Case ومعالجة التنبيهات المفتوحة وإزالة تكرار الكيانات. لذلك يمثل 6 سبتمبر تاريخ إدراج الدعم في ملاحظات الإصدار الرسمية، وليس دليلًا على أن أول ظهور موثق للمعاينة حدث في ذلك اليوم.
قبل النقل، يفيد فصل الأتمتة الحالية إلى أعمال تخص القضية مجتمعة وأخرى تتطلب سياق تنبيه منفرد. لا يكفي أن تكون الخطوة متكررة؛ يجب أيضًا أن تنتج النتيجة نفسها عند تطبيقها على مجموعة التنبيهات، وألا يؤدي جمع المدخلات إلى إخفاء خاصية يحتاج إليها النظام الخارجي.
إنشاء Case playbook وتحديد وقت تشغيله
عند إنشاء Playbook جديد، اختر Case من خيارات Scope بدل Alert، وهو الخيار الافتراضي. يتغير منشئ الأتمتة عندئذ ليعرض مشغلات الإدخال والتفاعل الملائمة للقضية، ويمكن كذلك إرفاق Playbook بقضية منشأة يدويًا أو تشغيل إجراء قياسي مباشرة على مستوى Case من واجهة القضية.
- حدّد نتيجة واحدة مشتركة، مثل إنشاء تذكرة خارجية أو إثراء الكيانات المجمعة.
- أنشئ Playbook باسم فريد واختر Case في إعداد النطاق؛ فلا يجوز أن يتطابق اسمه مع اسم Alert playbook موجود.
- اختر مشغل الإدخال: جميع القضايا الجديدة، أو شرطًا مخصصًا، أو وسمًا محددًا عند الإدخال.
- أضف الإجراءات والكتل، وراجع قدرة كل خطوة على استقبال مصفوفة التنبيهات والكيانات بدل كائن تنبيه واحد.
- شغّل حالة اختبار تضم تنبيهات وكيانات ممثلة للبيئة، ثم افحص النتيجة داخل القضية وفي التكامل الخارجي.
تسمح Reaction triggers بتشغيل الأتمتة بعد الإدخال عند تغير المسؤول عن القضية أو حقل مخصص أو الأولوية أو المرحلة، وكذلك عند إضافة وسم أو تعليق. هذه المشغلات مفيدة للأعمال المرتبطة بدورة التحقيق، لكن تكرار تغير الحقل نفسه قد يكرر التذكرة أو الإشعار ما لم يتضمن التصميم شرطًا يمنع إعادة التنفيذ غير المقصودة.
كيف تعمل إزالة تكرار الكيانات؟
يجمع Case playbook كيانات التنبيهات في قائمة واحدة، ويكون خيار Deduplicate entities مفعّلًا افتراضيًا لكل إجراء. يبحث النظام عن الكيانات الفريدة باستخدام المعرّف والنوع، ويرسل المجموعة الفريدة إلى الأداة الخارجية، ثم ينسخ التفاصيل العائدة إلى النسخ المطابقة داخل القضية. النتيجة أن عنوان IP المتكرر يمكن إثراؤه مرة واحدة بدل استهلاك طلب منفصل لكل ظهور.
يمكن تعطيل الخيار عندما تحمل كل نسخة من الكيان خصائص مرتبطة بتنبيه محدد ويجب معالجتها منفردة. لكن هذا المفتاح يؤثر في الكيانات التي تعالجها الإجراءات فقط؛ فالعناصر النائبة مثل [Entity.Identifier] تظل تُحل إلى قائمة الكيانات المتميزة حتى عند تعطيله.
يوجد داخل حلقات الكيانات خيار مستقل باسم Deduplicate loop entities، وهو مفعّل افتراضيًا أيضًا. مع تشغيل Lock scope to iteration ترى الإجراءات الداخلية الكيان الجاري وحده، ثم تطبق النتيجة على نسخه المطابقة؛ أما عند تعطيل القفل فتظل مصفوفة كيانات القضية كاملة متاحة داخل الحلقة. لهذا ينبغي اختبار الحلقات وظيفيًا، لأن شكل المخطط وحده لا يكشف البيانات التي ستراها كل خطوة.
السجلات المستثناة وحدود البيانات والتكاملات
تجمع وثيقة Case playbooks الرسمية القيود الحاسمة: التنفيذ يعالج البيانات المستخرجة من التنبيهات ذات الحالة Open فقط، وتُستثنى عمليات Case playbooks من لوحات Legacy Monitoring ومن SOAR Data Exports القديمة، بما فيها Managed BigQuery وBring Your Own BigQuery. كما تتطلب الوظائف الكاملة حدًا أدنى من إصدارات التكاملات، منها GoogleChronicle 84 وJira 58 وMISP 40 وServiceNow 67، وقد لا تعمل بعض الخصائص كما هو متوقع مع الإصدارات الأقدم.
هذا هو المقصود بـ«بعض السجلات» في العنوان: Google SecOps لا يحذف سجلات القضية أو التنبيهات، بل لا يدرج سجلات تنفيذ Case playbooks في وجهات مراقبة وتصدير قديمة بعينها. وقد ينجح التشغيل داخل القضية بينما لا يظهر في لوحة قديمة، ما يصنع فجوة رصد إذا كانت مؤشرات الفريق تعتمد على تلك الوجهة وحدها.
تدعم الإجراءات القياسية في Content Hub العمل على مستوى القضية، لكن الإجراءات المخصصة ونصوص Python تحتاج إلى المرور صراحة على مصفوفة التنبيهات كاملة حتى لا تُسقط تفاصيل الكيانات. كما أن ظهور تنبيه مغلق داخل واجهة القضية لا يعني دخول بياناته في التنفيذ؛ إذ يقتصر الاستخراج على التنبيهات المفتوحة وقت التشغيل.
ما الذي يجب إثباته قبل الاعتماد التشغيلي؟
ينبغي أن يحاكي الاختبار اختلافات القضية الفعلية، لا مجرد حالة ذات تنبيه واحد. الهدف هو التحقق من نطاق البيانات، وسلوك إزالة التكرار، والنتيجة في النظام الخارجي، وإمكان رصد التنفيذ بعد غيابه عن الأدوات القديمة.
- استخدم قضية تحتوي كيانًا متكررًا في أكثر من تنبيه، وقارن النتائج مع تفعيل إزالة التكرار وتعطيلها.
- أضف تنبيهًا مغلقًا، وتأكد من أن الإجراء لا يعتمد على بيانات لن تدخل في الاستخراج.
- راجع إصدار كل تكامل مشارك مقابل الحد الأدنى الذي حددته Google، ثم افحص الطلب والنتيجة في النظام الخارجي.
- حدّد مكانًا بديلًا لمتابعة التنفيذ والأخطاء إذا كانت اللوحات أو الصادرات الحالية من المسارات القديمة المستثناة.
- اختبر Reaction triggers مع تغيرات متكررة في القضية للتأكد من عدم إنشاء تذاكر أو إشعارات مكررة.
الحالة المؤكدة بعد إدراج 6 سبتمبر هي بقاء Case playbooks ضمن Preview وشروط Pre-GA، مع احتمال عدم ظهورها في بعض البيئات قبل تمكين ميزات المعاينة أو تدخل المسؤول. وهي توحّد الأتمتة على مستوى القضية، لكن جاهزيتها الإنتاجية تعتمد على اختبار التنبيهات المغلقة، وإصدارات التكاملات، ومسار الرصد الذي سيحل محل الأدوات القديمة المستثناة.
اقرأ أيضًا:
اشترك في نشرتنا الإخبارية
احصل على أحدث أخبار الويب 3 والذكاء الاصطناعي والعملات المشفرة مباشرة في بريدك.