خطة الاستجابة للحوادث

تسري اعتبارًا من: 2 يونيو 2026

تحدّد خطة الاستجابة للحوادث هذه («الخطة») كيف تكشف STANDOUT Inc. («نحن») الحوادث الأمنية وانقطاعات الخدمة وخروقات البيانات التي تؤثّر على خدمة VATES («الخدمة»)، وكيف تستجيب لها وتتعافى منها وتتعلّم منها. وتستند الخطة إلى NIST SP 800-61 Rev.2 وISO/IEC 27035، وهي مبنيّة على مبدأ التصميم القائل بأن أدوات المراقبة المؤتمتة تشكّل الخطّ الأمامي للكشف.

1. الغرض والنطاق

أهداف هذه الخطة هي:

• الكشف في الوقت المناسب عن الأحداث التي قد تؤثّر على توافر الخدمة أو سرّيتها أو سلامتها.
• تحديد إجراءات الاحتواء والتعافي التي تقلّل من التأثير.
• الامتثال لالتزامات الإشعار تجاه العملاء المتأثّرين والسلطات التنظيمية.
• تمكين التحسين المستمرّ لجودة التشغيل من خلال تحليل منظَّم لما بعد الحادث.

تنطبق هذه الخطة على بيئة الإنتاج للخدمة (EC2، وCloudflare، ومزوّدي SaaS المرتبطين)، ومسار الاتصال من الخدمة إلى مزوّدي الذكاء الاصطناعي الأساسيين، وجميع وسائط التخزين التي تحتفظ ببيانات العملاء.

2. تعريف الحادث وتصنيف الخطورة

2.1 تعريف الحادث

لأغراض هذه الخطة، الحادث هو أي حدث يطابق واحدًا أو أكثر مما يلي:

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

2.2 تصنيف الخطورة

يُصنَّف كل حادث وقت الكشف إلى أحد مستويات الخطورة التالية:

• P1 (حرج): انقطاع كامل للخدمة، أو خرق بيانات مؤكَّد يشمل بيانات شخصية. يتطلّب استجابة فورية.
• P2 (عالٍ): ضعف كبير في الوظيفة الأساسية، أو عدم توافر لعملاء محدّدين، أو حالات شاذّة في المصادقة. يلزم استجابة أوّلية خلال ساعة واحدة.
• P3 (متوسّط): ضعف وظيفي جزئي أو تدهور في الأداء مع توافر حلول بديلة. الاستجابة خلال ساعات العمل مقبولة.
• P4 (منخفض): أحداث ذات تأثير محدود على المستخدم، أو انحراف طفيف في سلامة السجلّ، أو انخفاض في تكرار أدوات المراقبة. تُعالَج في دورة المراجعة المجدولة التالية.

3. هيكل الاستجابة

3.1 الطرف المسؤول

الطرف المسؤول عن هذه الخطة هو Takuya Aoki، المدير التنفيذي (Managing Director) لـ STANDOUT Inc. ورئيس تطوير VATES. وتتركّز جميع صلاحيات اتخاذ القرار وصلاحية الإشعار الخارجي أثناء الحادث في الطرف المسؤول.

3.2 أدوات الكشف المؤتمتة

تشغّل الخدمة وضعية مراقبة مستمرّة مؤتمتة بالكامل تتكوّن من الأدوات التالية. وهي تعمل بشكل مستقل عن الطرف المسؤول وتُطلق إشعارًا فوريًا بمجرّد استيفاء شروط العتبة.

• Cloudflare Health Check: يفحص مصدر الإنتاج من نقاط مراقبة جغرافية متعدّدة بفواصل 60 ثانية.
• HetrixTools: يراقب نقاط نهاية الإنتاج من نقاط مراقبة عالمية متعدّدة عبر مسار مستقل عن Cloudflare.
• Sentry: يلتقط استثناءات التطبيق في الوقت الفعلي ويُشعر الطرف المسؤول.
• Cloudflare WAF (Managed Rules + OWASP Core Ruleset): يحظر أنماط الهجوم المعروفة في وضع الحظر (Block mode).
• Cloudflare DDoS Protection: يخفّف هجمات DDoS باستمرار وتلقائيًا على مستوى الشبكة، ومستوى SSL/TLS، ومستوى HTTP.
• دفعة كشف الشذوذ (systemd timer): تفحص سجلّات التدقيق كل خمس دقائق وتكشف ثلاث فئات: معدّل طلبات مرتفع، ومعدّل رفض تصريح مرتفع، ومحاولات القوة الغاشمة (brute-force).
• تحديد المعدّل (Rate Limiting): تحديد معدّل الطلبات لكل مستأجِر على نقاط نهاية الاستخدام، وتحديد معدّل قائم على IP على نقاط نهاية المصادقة، مع رفض الحركة الزائدة تلقائيًا.
• تنبيهات أمان قابلة للتهيئة: يمكن للعملاء اختيار الأحداث التشغيلية (انخفاض الرصيد، وتسجيل الدخول من موقع جديد، والوصول المحظور، وتكرار إخفاقات تسجيل الدخول) التي تُطلق إشعارات بريد إلكتروني، مع عتبات حساسية لكل حدث.
• بنية سجلّ التدقيق التحتية: تسجّل كل استدعاء API في سجلّ تدقيق مقاوم للعبث بسلسلة هاش (SHA-256، تسلسل لكل مستأجِر) وتوحّد الإدخالات للتحقّق المستقل.
• لوحة الحالة (9 مؤشّرات صحّة): تصوّر التدقيق، وكشف الشذوذ، وGeoIP، والنسخ الاحتياطي، ودفعة الحذف، وتغطية الكتالوج، وانحراف التسوية، وkillswitch، وصحة الخدمة على شاشة واحدة.
• النسخ الاحتياطي المؤتمت: يشفّر لقطات SQLite بـ GPG AES-256 ويحتفظ بـ 30 جيلًا يوميًا.

3.3 تفويض الاستجابة الأمامية إلى الأتمتة

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

4. عملية الاستجابة

4.1 الكشف

عندما تكشف أداة واحدة أو أكثر من الأدوات المؤتمتة الموضّحة في القسم 3.2 عن حالة شاذّة، يُشعَر الطرف المسؤول فورًا عبر Sentry والبريد الإلكتروني وتنبيهات اللوحة. وتُستلَم تقارير العملاء على [email protected] وتُسجَّل كتذاكر في المسار نفسه.

4.2 الفرز

عند تلقّي إشعار، يؤكّد الطرف المسؤول الخطورة بفحص:

• نطاق التأثير (جميع العملاء / عميل محدّد / instance فردي).
• ما إذا كانت البيانات الشخصية أو بيانات اعتماد المصادقة أو معلومات الفوترة متأثّرة.
• تورّط عوامل خارجية (انقطاعات مزوّد الذكاء الاصطناعي الأساسي، وانقطاعات Cloudflare، وانقطاعات AWS).
• الارتباط بأنماط الهجوم المعروفة (سجلّات WAF، ونتائج كشف الشذوذ، وتنبيهات GeoIP).

4.3 الاحتواء

بحسب الخطورة، يُطبَّق واحد أو أكثر من تدابير الاحتواء التالية:

• تعليق الـ instances المتأثّرة عبر آلة الحالة للعزل الفوري.
• إضافة عناوين IP المصدر إلى قائمة حظر (لكل عميل أو عمومية).
• إبطال جماعي للجلسات حسب JWT jti.
• تفعيل الـ killswitch (إيقاف كامل لحركة المرور، تدبير الملاذ الأخير).
• تفعيل «Under Attack Mode» من Cloudflare ضدّ هجمات L7.

4.4 التعافي

بعد الاحتواء، تُزال الأسباب الجذرية ويُنفَّذ ما يلي:

• الاستعادة من نسخة احتياطية حسب الحاجة (الإجراءات موثّقة في docs/RESTORE.md).
• تدوير بيانات الاعتماد المتأثّرة (مفاتيح API، وأسرار JWT، ومفاتيح تشفير النسخ الاحتياطي، إلخ).
• تطبيق التصحيحات وإصلاحات التهيئة وتصحيحات الكود على الإنتاج.
• التحقّق على بيئتَي الـ staging والإنتاج.
• مواصلة المراقبة لمدة 24 ساعة على الأقل عبر أدوات المراقبة.

4.5 ما بعد الحادث

بعد تأكيد التعافي، يقوم الطرف المسؤول بما يلي:

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

5. إشعار العملاء والجهات التنظيمية

5.1 إشعار خرق البيانات الشخصية

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

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

5.2 إشعار انقطاع الخدمة

بالنسبة لانقطاعات الخدمة المُصنَّفة P1 أو P2، نُشعر العملاء المتأثّرين دون تأخير لا مبرّر له، بما في ذلك الجدول الزمني المتوقّع للتعافي وأي تدابير تخفيف مؤقّتة. وقنوات الإشعار هي [email protected] ووحدة تحكم إدارة الخدمة.

5.3 طريقة الإشعار

تُسلَّم الإشعارات بشكل أساسي عبر البريد الإلكتروني إلى العنوان المسجّل للعميل، مدعومةً عند الحاجة بشرائط (banners) داخل وحدة تحكم الإدارة.

6. دورة ما بعد الحادث والتعلّم

عقب حادث P1 أو P2، يُجري الطرف المسؤول تحليلًا لما بعد الحادث (Post-Mortem) ويوثّق البنود التالية. ويُحتفَظ بالوثيقة داخليًا وتُفصَح للعملاء والمدقّقين عند الطلب.

• الجدول الزمني للأحداث من الكشف إلى التعافي.
• تحليل السبب الجذري (العوامل التقنية والتشغيلية).
• نطاق التأثير مُقدَّرًا كمّيًا.
• تقييم عملية الاستجابة.
• التدابير الوقائية والمواعيد النهائية المستهدفة.

تُجرى تحليلات ما بعد الحادث على شكل Blameless Post-Mortems، تركّز على التحسين الهيكلي بدلًا من المساءلة الفردية.

7. صيانة الخطة ومراجعتها

7.1 المراجعة الدورية

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

7.2 سجلّ المراجعات

يُحتفَظ بسجلّ مراجعات هذه الخطة داخليًا ويُفصَح للعملاء والمدقّقين عند الطلب.

8. التواصل

للإبلاغ عن حادث أو لطرح استفسارات حول هذه الخطة:

STANDOUT Inc.
البريد الإلكتروني: [email protected]

آخر تحديث: 2 يونيو 2026