طرح واکنش به حادثه

تاریخ اجرا: 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)، مدیرعامل STANDOUT Inc. و رئیس توسعه VATES است. همه اختیارات تصمیم‌گیری و اختیار اطلاع‌رسانی بیرونی طی یک حادثه در طرف پاسخگو متمرکز است.

3.2 ابزارهای کشف خودکار

سرویس یک وضعیت پایش پیوسته کاملاً خودکار متشکل از ابزارهای زیر را اجرا می‌کند. آن‌ها مستقل از طرف پاسخگو اجرا می‌شوند و به‌محض برآورده شدن شرایط آستانه، اطلاع‌رسانی فوری را فعال می‌کنند.

• Cloudflare Health Check: مبدأ تولید را از چندین نقطه دید جغرافیایی با بازه‌های 60 ثانیه‌ای کاوش می‌کند.
• HetrixTools: نقاط پایانی تولید را از چندین نقطه دید جهانی از خلال مسیری مستقل از Cloudflare پایش می‌کند.
• Sentry: استثناهای برنامه را در زمان واقعی می‌گیرد و به طرف پاسخگو اطلاع می‌دهد.
• Cloudflare WAF (Managed Rules + OWASP Core Ruleset): الگوهای حمله شناخته‌شده را در حالت Block مسدود می‌کند.
• Cloudflare DDoS Protection: حملات DDoS را در لایه شبکه، لایه SSL/TLS، و لایه HTTP به‌طور پیوسته و خودکار مهار می‌کند.
• Anomaly Detection Batch (systemd timer): لاگ‌های ممیزی را هر پنج دقیقه اسکن می‌کند و سه دسته را کشف می‌کند: نرخ درخواست بالا، نرخ رد مجوز بالا، و تلاش‌های brute-force.
• Rate Limiting: محدودسازی نرخ درخواست per-tenant روی نقاط پایانی استفاده و محدودسازی نرخ مبتنی بر IP روی نقاط پایانی احراز هویت، که ترافیک مازاد را به‌طور خودکار رد می‌کند.
• Configurable Security Alerts: مشتریان می‌توانند انتخاب کنند که کدام رویدادهای عملیاتی (موجودی کم، ورود از مکان جدید، دسترسی مسدودشده، شکست‌های مکرر ورود) اطلاع‌رسانی ایمیلی را فعال کنند، با آستانه‌های حساسیت به‌ازای هر رویداد.
• Audit Log Infrastructure: هر فراخوانی API را در یک لاگ ممیزی مقاوم در برابر دستکاری با زنجیره هش (SHA-256، توالی per-tenant) ثبت می‌کند و ورودی‌ها را برای راستی‌آزمایی مستقل تجمیع می‌کند.
• Status Dashboard (9 health pills): ممیزی، ناهنجاری، GeoIP، پشتیبان، دسته حذف، پوشش کاتالوگ، انحراف تطبیق، killswitch، و سلامت سرویس را روی یک صفحه واحد بصری‌سازی می‌کند.
• Automated Backup: عکس‌های فوری SQLite را با GPG AES-256 رمزنگاری می‌کند و 30 نسل روزانه را نگه می‌دارد.

3.3 واگذاری واکنش خط مقدم به خودکارسازی

مراحل کشف و تریاژ توسط ابزارهای خودکار بالا به‌عنوان خط مقدم انجام می‌شوند. طرف پاسخگو تنها با دریافت اطلاع‌رسانی‌های فراتر از آستانه مداخله می‌کند. این طراحی تضمین می‌کند که پوشش کشف 24/7 بدون وابستگی به مکان یا در دسترس بودن طرف پاسخگو به‌طور فیزیکی مستقر شود.

4. فرایند واکنش

4.1 کشف

هنگامی که یک یا چند مورد از ابزارهای خودکار توصیف‌شده در بخش 3.2 یک ناهنجاری را کشف کنند، به طرف پاسخگو بلافاصله از طریق Sentry، ایمیل، و هشدارهای داشبورد اطلاع داده می‌شود. گزارش‌های مشتری در [email protected] دریافت و در همان جریان تیکت می‌شوند.

4.2 تریاژ

با دریافت یک اطلاع‌رسانی، طرف پاسخگو شدت را با بررسی موارد زیر تأیید می‌کند:

• دامنه تأثیر (همه مشتریان / مشتری خاص / instance منفرد).
• اینکه آیا داده شخصی، بیانات اعتماد احراز هویت، یا اطلاعات صورتحساب متأثر شده‌اند.
• دخالت عوامل خارجی (قطعی ارائه‌دهنده هوش مصنوعی بالادست، قطعی Cloudflare، قطعی AWS).
• همبستگی با الگوهای حمله شناخته‌شده (لاگ‌های WAF، نتایج کشف ناهنجاری، هشدارهای GeoIP).

4.3 مهار

بسته به شدت، یک یا چند مورد از تدابیر مهار زیر اعمال می‌شوند:

• تعلیق instanceهای متأثر از طریق state machine برای جداسازی فوری.
• افزودن آدرس‌های IP مبدأ به یک deny list (به‌ازای هر مشتری یا سراسری).
• ابطال انبوه نشست‌ها بر اساس JWT jti.
• فعال‌سازی killswitch (توقف کامل ترافیک، تدبیر آخرین چاره).
• فعال‌سازی Cloudflare «Under Attack Mode» در برابر حملات 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 روش اطلاع‌رسانی

اطلاع‌رسانی‌ها عمدتاً از طریق ایمیل به نشانی ثبت‌شده مشتری تحویل می‌شوند، و حسب نیاز با بنرهایی درون کنسول مدیریت تکمیل می‌شوند.

6. چرخه پس‌ازمرگ و یادگیری

پس از یک حادثه P1 یا P2، طرف پاسخگو یک پس‌ازمرگ (Post-Mortem) انجام می‌دهد و موارد زیر را مستند می‌کند. سند به‌طور داخلی نگه داشته و با درخواست به مشتریان و ممیزان افشا می‌شود.

• خط زمانی رویدادها از کشف تا بازیابی.
• تحلیل ریشه (عوامل فنی و عملیاتی).
• دامنه کمّی‌شده تأثیر.
• ارزیابی فرایند واکنش.
• تدابیر پیشگیرانه و مهلت‌های هدف.

پس‌ازمرگ‌ها به‌صورت پس‌ازمرگ‌های بدون سرزنش (Blameless Post-Mortems) انجام می‌شوند، با تمرکز بر بهبود ساختاری به‌جای پاسخگویی فردی.

7. نگهداری و بازبینی طرح

7.1 بازبینی دوره‌ای

این طرح حداقل سالانه، و نیز پس از هر حادثه مهم، در پی تغییرات اساسی در معماری سرویس، و در پی اصلاحات قوانین و مقررات قابل‌اجرا، بازبینی می‌شود.

7.2 سابقه بازبینی

سابقه بازبینی این طرح به‌طور داخلی نگه داشته و با درخواست به مشتریان و ممیزان افشا می‌شود.

8. تماس

برای گزارش یک حادثه یا طرح پرسش‌ها درباره این طرح:

STANDOUT Inc.
ایمیل: [email protected]

آخرین به‌روزرسانی: 2 ژوئن 2026