Kế hoạch ứng phó sự cố

Hiệu lực: 2 tháng 6, 2026

Kế hoạch ứng phó sự cố này ("Kế hoạch") định nghĩa cách STANDOUT Inc. ("chúng tôi") phát hiện, ứng phó, khôi phục và học hỏi từ các sự cố bảo mật, gián đoạn dịch vụ và vi phạm dữ liệu ảnh hưởng đến dịch vụ VATES ("Dịch vụ"). Kế hoạch tham chiếu NIST SP 800-61 Rev.2 và ISO/IEC 27035, và được xây dựng trên nguyên tắc thiết kế rằng các thiết bị giám sát tự động là tuyến đầu của việc phát hiện.

1. Mục đích và Phạm vi

Các mục tiêu của Kế hoạch này là:

• Phát hiện kịp thời các sự kiện có thể ảnh hưởng đến tính khả dụng, bảo mật, hoặc toàn vẹn của Dịch vụ.
• Định nghĩa các thủ tục ngăn chặn và khôi phục nhằm giảm thiểu tác động.
• Tuân thủ các nghĩa vụ thông báo tới các Khách hàng bị ảnh hưởng và các cơ quan quản lý.
• Cho phép cải thiện liên tục chất lượng vận hành qua phân tích hậu sự cố có cấu trúc.

Kế hoạch này áp dụng cho môi trường sản xuất của Dịch vụ (EC2, Cloudflare, và các nhà cung cấp SaaS liên quan), đường truyền từ Dịch vụ tới các nhà cung cấp AI thượng nguồn, và mọi kho lưu trữ chứa dữ liệu Khách hàng.

2. Định nghĩa sự cố và Phân loại mức độ nghiêm trọng

2.1 Định nghĩa một sự cố

Cho mục đích của Kế hoạch này, một sự cố là bất kỳ sự kiện nào khớp với một hoặc nhiều điều sau:

• Nghi ngờ truy cập trái phép, xâm phạm thông tin đăng nhập, hoặc xâm nhập hệ thống.
• Tiết lộ, thay đổi, hoặc mất mát trái phép dữ liệu Khách hàng, bao gồm dữ liệu cá nhân.
• Ngừng hoạt động hoặc suy giảm hiệu năng đáng kể ảnh hưởng đến chức năng cốt lõi của Dịch vụ.
• Các mối đe dọa bảo mật bao gồm nhiễm malware, ransomware, hoặc tấn công chuỗi cung ứng.
• Lỗi vận hành, cấu hình sai, hoặc lỗi phần mềm dẫn đến tác động quy mô lớn.

2.2 Phân loại mức độ nghiêm trọng

Mỗi sự cố được phân loại tại thời điểm phát hiện vào một trong các mức độ nghiêm trọng sau:

• P1 (Critical): Ngừng hoạt động toàn bộ Dịch vụ, hoặc vi phạm dữ liệu được xác nhận liên quan đến dữ liệu cá nhân. Yêu cầu ứng phó ngay lập tức.
• P2 (High): Suy giảm đáng kể chức năng cốt lõi, không khả dụng đối với các Khách hàng cụ thể, hoặc các bất thường về xác thực. Yêu cầu ứng phó ban đầu trong vòng một giờ.
• P3 (Medium): Suy giảm chức năng một phần hoặc suy giảm hiệu năng với các giải pháp thay thế có sẵn. Ứng phó trong giờ làm việc là chấp nhận được.
• P4 (Low): Các sự kiện với tác động hạn chế tới người dùng, sai lệch toàn vẹn log nhỏ, hoặc giảm dự phòng của các thiết bị giám sát. Được xử lý trong chu kỳ rà soát định kỳ tiếp theo.

3. Cơ cấu ứng phó

3.1 Bên chịu trách nhiệm

Bên chịu trách nhiệm cho Kế hoạch này là Takuya Aoki, Managing Director của STANDOUT Inc. và người đứng đầu phát triển VATES. Mọi thẩm quyền ra quyết định và thẩm quyền thông báo ra bên ngoài trong một sự cố được tập trung vào bên chịu trách nhiệm.

3.2 Các thiết bị phát hiện tự động

Dịch vụ vận hành một tư thế giám sát liên tục hoàn toàn tự động gồm các thiết bị sau. Chúng chạy độc lập với bên chịu trách nhiệm và kích hoạt thông báo ngay lập tức khi các điều kiện ngưỡng được đáp ứng.

• Cloudflare Health Check: Thăm dò origin sản xuất từ nhiều điểm quan sát địa lý ở khoảng thời gian 60 giây.
• HetrixTools: Giám sát các endpoint sản xuất từ nhiều điểm quan sát toàn cầu qua một đường độc lập với Cloudflare.
• Sentry: Bắt các ngoại lệ ứng dụng theo thời gian thực và thông báo cho bên chịu trách nhiệm.
• Cloudflare WAF (Managed Rules + OWASP Core Ruleset): Chặn các mẫu tấn công đã biết ở chế độ Block.
• Cloudflare DDoS Protection: Liên tục và tự động giảm nhẹ các cuộc tấn công DDoS ở tầng mạng, tầng SSL/TLS, và tầng HTTP.
• Anomaly Detection Batch (systemd timer): Quét nhật ký kiểm toán mỗi năm phút và phát hiện ba loại: tỷ lệ yêu cầu cao, tỷ lệ từ chối cấp quyền cao, và các nỗ lực brute-force.
• Rate Limiting: Giới hạn tốc độ yêu cầu theo từng tenant trên các endpoint sử dụng và giới hạn tốc độ dựa trên IP trên các endpoint xác thực, tự động từ chối lưu lượng vượt mức.
• Configurable Security Alerts: Khách hàng có thể chọn các sự kiện vận hành nào (số dư thấp, đăng nhập từ vị trí mới, truy cập bị chặn, các lần đăng nhập thất bại lặp lại) kích hoạt thông báo email, với các ngưỡng độ nhạy theo từng sự kiện.
• Audit Log Infrastructure: Ghi mọi lần gọi API vào một nhật ký kiểm toán chống giả mạo theo chuỗi băm (SHA-256, số thứ tự theo từng tenant) và hợp nhất các mục để kiểm chứng độc lập.
• Status Dashboard (9 health pills): Trực quan hóa audit, anomaly, GeoIP, backup, deletion batch, catalog coverage, reconciliation drift, killswitch, và service health trên một màn hình duy nhất.
• Automated Backup: Mã hóa các snapshot SQLite bằng GPG AES-256 và giữ lại 30 thế hệ hàng ngày.

3.3 Ủy thác ứng phó tuyến đầu cho tự động hóa

Các giai đoạn phát hiện và phân loại được thực hiện bởi các thiết bị tự động ở trên như tuyến đầu. Bên chịu trách nhiệm chỉ can thiệp khi nhận được các thông báo vượt ngưỡng. Thiết kế này bảo đảm rằng phạm vi phát hiện 24/7 được thiết lập về mặt vật lý mà không phụ thuộc vào vị trí hay sự sẵn sàng của bên chịu trách nhiệm.

4. Quy trình ứng phó

4.1 Phát hiện

Khi bất kỳ một hoặc nhiều thiết bị tự động được mô tả tại Mục 3.2 phát hiện một bất thường, bên chịu trách nhiệm được thông báo ngay lập tức qua Sentry, email, và các cảnh báo dashboard. Các báo cáo của Khách hàng được tiếp nhận tại [email protected] và được lập ticket theo cùng luồng.

4.2 Phân loại

Khi nhận được một thông báo, bên chịu trách nhiệm xác nhận mức độ nghiêm trọng bằng cách xem xét:

• Phạm vi tác động (tất cả Khách hàng / Khách hàng cụ thể / Instance riêng lẻ).
• Liệu dữ liệu cá nhân, thông tin đăng nhập xác thực, hoặc thông tin thanh toán có bị ảnh hưởng hay không.
• Sự liên quan của các yếu tố bên ngoài (sự cố của nhà cung cấp AI thượng nguồn, sự cố Cloudflare, sự cố AWS).
• Sự tương quan với các mẫu tấn công đã biết (WAF logs, kết quả phát hiện bất thường, GeoIP alerts).

4.3 Ngăn chặn

Tùy theo mức độ nghiêm trọng, một hoặc nhiều biện pháp ngăn chặn sau được áp dụng:

• Tạm ngưng các Instance bị ảnh hưởng qua state machine để cô lập ngay lập tức.
• Thêm các địa chỉ IP nguồn vào một deny list (theo từng Khách hàng hoặc toàn cục).
• Thu hồi phiên hàng loạt theo JWT jti.
• Kích hoạt killswitch (dừng toàn bộ lưu lượng, biện pháp cuối cùng).
• Kích hoạt Cloudflare "Under Attack Mode" chống lại các cuộc tấn công L7.

4.4 Khôi phục

Sau khi ngăn chặn, các nguyên nhân gốc được loại bỏ và các bước sau được thực hiện:

• Khôi phục từ bản sao lưu khi cần (các thủ tục được ghi tại docs/RESTORE.md).
• Xoay vòng các thông tin đăng nhập bị ảnh hưởng (API key, JWT secret, khóa mã hóa sao lưu, v.v.).
• Áp dụng các bản vá, sửa cấu hình, và sửa mã lên sản xuất.
• Kiểm chứng trên môi trường staging và sản xuất.
• Tiếp tục quan sát ít nhất 24 giờ qua các thiết bị giám sát.

4.5 Hậu sự cố

Sau khi khôi phục được xác nhận, bên chịu trách nhiệm:

• Ghi lại dòng thời gian, nguyên nhân gốc, phạm vi tác động, và các hành động ứng phó.
• Xác định và tích hợp các biện pháp phòng ngừa vào lộ trình triển khai.
• Nơi áp dụng, thông báo cho các Khách hàng bị ảnh hưởng và các cơ quan quản lý (xem Mục 5).
• Đưa các cải thiện trở lại vào Kế hoạch này và các tài liệu vận hành liên quan.

5. Thông báo cho Khách hàng và Cơ quan quản lý

5.1 Thông báo vi phạm dữ liệu cá nhân

Nếu việc thu thập, mất mát, hoặc tiết lộ trái phép dữ liệu cá nhân được xác nhận, chúng tôi thực hiện thông báo theo:

• EU General Data Protection Regulation (GDPR) Article 33: Thông báo cho cơ quan giám sát trong vòng 72 giờ kể từ khi biết được.
• GDPR Article 34: Nơi xác định có rủi ro cao, thông báo cho các chủ thể dữ liệu bị ảnh hưởng mà không chậm trễ quá mức.
• Đạo luật Bảo vệ Thông tin Cá nhân (Nhật Bản): Báo cáo cho Ủy ban Bảo vệ Thông tin Cá nhân và thông báo cho các chủ thể dữ liệu, theo các nghị định và quy tắc nội các áp dụng.
• Các khu vực pháp lý áp dụng khác: Các thông báo mà luật bảo vệ dữ liệu quốc gia hoặc khu vực áp dụng yêu cầu.

5.2 Thông báo gián đoạn dịch vụ

Đối với các gián đoạn dịch vụ được phân loại là P1 hoặc P2, chúng tôi thông báo cho các Khách hàng bị ảnh hưởng mà không chậm trễ quá mức, bao gồm dòng thời gian khôi phục dự kiến và mọi biện pháp giảm nhẹ tạm thời. Các kênh thông báo là [email protected] và bảng điều khiển quản trị Dịch vụ.

5.3 Phương thức thông báo

Các thông báo được gửi chủ yếu qua email tới địa chỉ đã đăng ký của Khách hàng, được bổ sung khi cần bằng các banner trong bảng điều khiển quản trị.

6. Chu kỳ Hậu kiểm và Học hỏi

Sau một sự cố P1 hoặc P2, bên chịu trách nhiệm thực hiện một Hậu kiểm và ghi lại các mục sau. Tài liệu được giữ lại nội bộ và được tiết lộ cho Khách hàng và kiểm toán viên khi có yêu cầu.

• Dòng thời gian các sự kiện từ phát hiện đến khôi phục.
• Phân tích nguyên nhân gốc (các yếu tố kỹ thuật và vận hành).
• Phạm vi tác động được định lượng.
• Đánh giá quy trình ứng phó.
• Các biện pháp phòng ngừa và thời hạn mục tiêu.

Các cuộc Hậu kiểm được tiến hành như Blameless Post-Mortems, tập trung vào cải thiện cấu trúc hơn là quy trách nhiệm cá nhân.

7. Duy trì và Rà soát Kế hoạch

7.1 Rà soát định kỳ

Kế hoạch này được rà soát ít nhất hàng năm, cũng như sau bất kỳ sự cố đáng kể nào, khi có thay đổi trọng yếu đối với kiến trúc Dịch vụ, và khi có sửa đổi các luật và quy định áp dụng.

7.2 Lịch sử sửa đổi

Lịch sử sửa đổi của Kế hoạch này được duy trì nội bộ và được tiết lộ cho Khách hàng và kiểm toán viên khi có yêu cầu.

8. Liên hệ

Để báo cáo một sự cố hoặc nêu các thắc mắc về Kế hoạch này:

STANDOUT Inc.
Email: [email protected]

Cập nhật lần cuối: 2 tháng 6, 2026