SEC — Security Architecture & Threat Model —
|
|
| Version |
1.0 |
| Date |
YYYY-MM-DD |
| Author |
(skill sa-2-architecture) |
| Status |
🟡 Draft |
| Approved by |
Security: — · Tech Lead: — |
| Source |
SAD_… v1.0 · DAT_… v1.0 · RBAC_… của BA · chính sách bảo mật … |
| Scope |
|
| Confidence |
🟡 |
Change Log
| Version |
Date |
Người sửa |
Thay đổi |
ADR |
| 1.0 |
|
|
Bản đầu |
— |
🔴 Security có quyền phủ quyết AG2. Tài liệu này phải được làm cùng người của
Security, không phải trình cho họ xem lúc cuối. Phát hiện muộn nhất và đau nhất luôn đến từ đây.
1. Ranh giới tin cậy
Nơi dữ liệu đi từ vùng ít tin cậy sang vùng tin cậy hơn. Mỗi ranh giới phải có kiểm tra đầu vào.
| # |
Ranh giới |
Từ vùng |
Sang vùng |
Kiểm tra gì tại đây |
CMP chịu trách nhiệm |
| 1 |
Internet → hệ thống |
không tin cậy |
|
xác thực, giới hạn tốc độ, kích thước payload, kiểm tra định dạng |
|
| 2 |
Service → CSDL |
|
|
|
|
2. Xác thực
|
Quyết định |
ADR |
| Cơ chế |
session / JWT / OAuth2 + OIDC / mTLS |
|
| Nơi giữ trạng thái |
server-side / stateless token |
|
| Thời hạn access token |
|
|
| Refresh token |
có/không · thời hạn · xoay vòng không |
|
| Cách thu hồi ngay lập tức |
(bắt buộc trả lời — token stateless thu hồi bằng gì) |
|
| Đa yếu tố (MFA) |
với vai trò nào |
|
| Nơi ký/xác minh chữ ký |
khoá ở đâu, xoay bao lâu một lần |
|
🔴 JWT stateless không thu hồi được ngay trừ khi có danh sách chặn. Nhân viên nghỉ việc
lúc 9h mà token còn hiệu lực tới 10h là rủi ro thật — quyết định ở đây, không để dev tự xử lý.
3. Phân quyền
|
Quyết định |
ADR |
| Mô hình |
RBAC / ABAC / kết hợp |
|
| Chỗ ra quyết định |
gateway / từng service / thư viện chung |
|
| Nguồn sự thật của vai trò |
|
|
| Ràng buộc dữ liệu (row-level) |
có/không · cơ chế |
|
🔴 Phân quyền ở gateway không đủ khi có ràng buộc dữ liệu. "Chỉ xem cửa hàng mình phụ
trách" là điều kiện trên dữ liệu — gateway không biết. Phải quyết ở service, và phải nhất quán.
3.1 Map RBAC của bộ BA xuống quyền kỹ thuật
ROLE-nn (BA) |
Vai trò kỹ thuật |
Quyền trên IF-nnn |
Ràng buộc dữ liệu |
Ai gán vai trò này |
ROLE-01 |
|
IF-001 đọc |
🔶 chỉ cửa hàng phụ trách |
|
Mỗi ROLE-nn trong RBAC của BA phải có đúng một dòng ở đây. Thiếu ⇒ chặn AG2.
3.2 Phân tách nhiệm vụ (SoD)
Cho các hành động phê duyệt / chốt sổ / chuyển tiền.
| Hành động |
Người thực hiện không được đồng thời là |
Cơ chế cưỡng chế |
4. Threat model — STRIDE
Làm cho mỗi luồng nhạy cảm: đăng nhập, thanh toán, dữ liệu cá nhân, thao tác quản trị, xuất dữ liệu.
4.1 Luồng: <tên>
| ID |
Loại (STRIDE) |
Mối đe doạ |
Thành phần bị nhắm |
Mức |
Biện pháp |
Cách kiểm chứng biện pháp có hiệu lực |
FIT/QAS |
THR-01 |
Spoofing |
|
|
🔴 |
|
pentest / kiểm thử tự động / review thủ công định kỳ |
|
THR-02 |
Tampering |
|
|
|
|
|
|
THR-03 |
Repudiation |
|
|
|
audit log ghi … |
|
|
THR-04 |
Information disclosure |
|
|
|
|
|
|
THR-05 |
Denial of service |
|
|
|
giới hạn tốc độ … |
|
|
THR-06 |
Elevation of privilege |
|
|
|
|
|
|
🔴 Cột "cách kiểm chứng" không được để trống. Biện pháp không kiểm chứng được là biện pháp
tồn tại trên giấy — đúng theo quy tắc D8.
4.2 Mối đe doạ đã chấp nhận
THR |
Vì sao chấp nhận |
Ai ký · ngày |
Dấu hiệu cảnh báo |
Kế hoạch nếu xảy ra |
5. Bảo vệ dữ liệu
|
Quyết định |
| Mã hoá in-transit |
TLS … · nội bộ có mã hoá không |
| Mã hoá at-rest |
cấp nào (đĩa / CSDL / trường) · khoá quản lý ở đâu |
| Trường nào mã hoá ở mức trường |
(tham chiếu DAT §5) |
| Che dữ liệu khi hiển thị / khi log |
quy tắc cụ thể |
| Dữ liệu ở môi trường non-prod |
ẩn danh hoá / dữ liệu sinh / cấm dùng dữ liệu thật |
🔴 Dữ liệu production trên môi trường dev là vi phạm phổ biến nhất và dễ tránh nhất. Chốt
rõ ở đây và cưỡng chế bằng FIT.
6. Quản lý secret
|
Quyết định |
| Nơi lưu |
|
| Cách ứng dụng lấy |
|
| Xoay khoá: tần suất, tự động hay thủ công |
|
| Cấm tuyệt đối |
secret trong mã nguồn, trong biến môi trường ghi vào log, trong ảnh container |
| Cách phát hiện rò rỉ |
quét mã nguồn: … · FIT-nn |
7. Audit log
| Hành động phải ghi |
Ghi những trường gì |
Ai đọc được |
Giữ bao lâu |
Chống sửa bằng cách nào |
| Đăng nhập / thất bại |
|
|
|
|
| Thay đổi quyền |
|
|
|
|
| Truy cập dữ liệu nhạy cảm |
|
|
|
|
| Phê duyệt / chốt sổ |
|
|
|
|
🔴 Audit log mà người bị audit sửa được thì không phải audit log. Ghi rõ cơ chế chống sửa
(append-only, tài khoản riêng, hệ thống tách biệt).
8. Tuân thủ
| Yêu cầu |
Nguồn |
Cách đáp ứng |
Bằng chứng cho kiểm toán |
Ai xác nhận |
|
GDPR / PCI-DSS / K-ISMS / nội bộ |
|
|
|
9. Phụ thuộc & chuỗi cung ứng
|
Quyết định |
| Quét lỗ hổng thư viện |
công cụ · tần suất · ngưỡng chặn build |
| Quét ảnh container |
|
| Chính sách vá lỗ hổng nghiêm trọng |
trong bao lâu |
| Ai duyệt thư viện mới |
|
10. Giả định & Ngoài phạm vi
Giả định:
| ID |
Giả định |
Cách xác minh |
Nếu sai |
Ngoài phạm vi:
- (ví dụ: không chống được kẻ tấn công có quyền quản trị hạ tầng — rủi ro này do quy trình
nhân sự và kiểm soát truy cập cloud xử lý, không do kiến trúc ứng dụng)
11. Open Questions
| ID |
Câu hỏi |
Hỏi ai |
Từ ngày |
Chặn gì |
Hệ quả nếu trả lời ngược |
