Tư duy Feynman • Trực quan hình họa • Java / Spring Boot

Chương 21: Threat Modeling & Security Architecture

Mô hình hóa mối đe dọa bài bản: Nhận diện tài sản, phân tích STRIDE, đánh giá rủi ro DREAD, sơ đồ luồng dữ liệu DFD và kiến trúc phòng thủ đa tầng.

#01 Asset Identification & Classification (Nhận diện & Phân loại Tài sản)

💡 BƯỚC 1: ẨN DỤ ĐỜI THƯỜNG (FEYNMAN ANALOGY)
Trước khi lắp camera hay thuê vệ sĩ, bạn phải biết trong nhà mình món đồ nào đáng giá nhất: viên kim cương gia bảo hay chiếc bàn chải đánh răng cũ. Trong phần mềm, số thẻ tín dụng và mật khẩu người dùng là 'kim cương' (Confidential/Tier 1), trong khi logo công ty hay bài viết blog công khai là 'bàn chải' (Public/Tier 3). Bạn không bảo vệ mọi thứ như nhau.
📊 HÌNH HỌA MINH HỌA (VISUAL FLOW): Asset Identification & Classification (Nhận diện & Phân loại Tài sản)
Dữ liệu hệ thống Toàn bộ tài nguyên Phân loại Tier 1 Mật khẩu, Thẻ, Token Phân loại Tier 2 Họ tên, Email PII Phân loại Tier 3 Dữ liệu Web công khai 🛡️ Phân loại tài sản: Xác định tài nguyên trọng yếu để tập trung nguồn lực bảo vệ
🧪 BƯỚC 2: PHÒNG THÍ NGHIỆM TƯƠNG TÁC (SANDBOX)
Mẫu thử nghiệm: ASSET: User Database Credentials (Tier 1 - Secret)ASSET: Public Marketing Banner (Tier 3 - Public)ASSET: Customer Phone Numbers (Tier 2 - PII)
⚠️ Phân loại tài sản: Mật khẩu CSDL thuộc mức độ Bí mật cao nhất!
⚖️ BƯỚC 3: SO SÁNH CODE LỖI VS CODE CHUẨN (JAVA / SPRING BOOT)
❌ Vulnerable Java Code (Không an toàn)
// THIẾU PHÂN LOẠI: Lưu chung dữ liệu mật và công khai vào cùng một bảng không mã hóa
public class CustomerData {
    public String publicBio;
    public String plainCreditCardNumber; // LƯU CHUNG RỦI RO CỰC CAO!
}
✅ Secure Java Code (Chuẩn bảo mật)
// CHUẨN PHÂN LOẠI DỮ LIỆU: Áp dụng Annotation bảo mật và phân tách vùng lưu trữ
public class CustomerProfile {
    private String publicBio; // Tier 3: Public

    @Sensitivity(Level.CONFIDENTIAL) // Tier 1: Restricted PII
    @Convert(converter = AesGcmFieldEncryptor.class)
    private String encryptedSsn;
}
🎯 BƯỚC 4: THỬ TÀI THẤU HIỂU (ACTIVE CHECK)
Mục tiêu quan trọng nhất của việc Nhận diện và Phân loại tài sản là gì?
A. Giúp doanh nghiệp hiểu rõ dữ liệu nào quan trọng nhất để áp dụng các biện pháp bảo vệ tương xứng, tránh lãng phí nguồn lực hoặc bảo vệ thiếu sót.
B. Bán dữ liệu cho bên thứ ba.
C. Tăng kích thước ổ cứng máy chủ.
D. Xóa bớt dữ liệu cũ.
📝 Tóm tắt nhanh bằng lời của bạn (Feynman Notebook): (Tự động lưu vào trình duyệt)

#02 Threat Definition & Identification with STRIDE (Mô hình mối đe dọa STRIDE)

💡 BƯỚC 1: ẨN DỤ ĐỜI THƯỜNG (FEYNMAN ANALOGY)
STRIDE giống như bảng ghi nhớ 6 thói quen xấu của kẻ trộm mà bảo vệ cần đề phòng: Giả mạo thẻ (Spoofing), Cạy sửa ổ khóa (Tampering), Chối tội bảo 'không phải tôi' (Repudiation), Nhìn trộm mật mã két (Information Disclosure), Đặt bom chặn cửa (Denial of Service), và Tự xưng là sếp (Elevation of Privilege).
📊 HÌNH HỌA MINH HỌA (VISUAL FLOW): Threat Definition & Identification with STRIDE (Mô hình mối đe dọa STRIDE)
S - Spoofing Giả mạo danh tính T - Tampering Sửa đổi dữ liệu trái phép R - Repudiation Chối bỏ trách nhiệm I - D - E Lộ thông tin, DoS, Leo thang ⚠️ Mô hình STRIDE của Microsoft: Nhận diện 6 nhóm mối đe dọa cốt lõi
🧪 BƯỚC 2: PHÒNG THÍ NGHIỆM TƯƠNG TÁC (SANDBOX)
Mẫu thử nghiệm: THREAT: Spoofing (Giả mạo người dùng)THREAT: Tampering (Sửa đổi số tiền gửi)THREAT: Repudiation (Chối chuyển tiền)
⚠️ Phân tích mối đe dọa theo mô hình STRIDE!
⚖️ BƯỚC 3: SO SÁNH CODE LỖI VS CODE CHUẨN (JAVA / SPRING BOOT)
❌ Vulnerable Java Code (Không an toàn)
// THIẾT KẾ THIẾU STRIDE: Gửi số tiền và người nhận qua request không chữ ký
// Kẻ gian có thể giả mạo (Spoofing) hoặc sửa đổi tham số (Tampering) trên đường truyền
✅ Secure Java Code (Chuẩn bảo mật)
// THIẾT KẾ ĐÃ ÁP DỤNG BIỆN PHÁP ĐỐI PHÓ STRIDE:
// 1. Spoofing -> Spring Security JWT Authentication
// 2. Tampering -> TLS 1.3 + Request Body HMAC SHA-256
// 3. Repudiation -> Spring Data JPA @Audited lưu vết bất biến
// 4. Information Disclosure -> Mã hóa AES-GCM
// 5. Denial of Service -> Bucket4j Rate Limiting
// 6. Elevation of Privilege -> Spring Method Security @PreAuthorize
🎯 BƯỚC 4: THỬ TÀI THẤU HIỂU (ACTIVE CHECK)
Chữ 'R' trong mô hình phân loại mối đe dọa STRIDE là viết tắt của từ gì?
A. Repudiation (Sự chối bỏ trách nhiệm hành động).
B. Routing.
C. Remote.
D. Random.
📝 Tóm tắt nhanh bằng lời của bạn (Feynman Notebook): (Tự động lưu vào trình duyệt)

#03 Vulnerability Identification (Nhận diện Điểm yếu Bảo mật)

💡 BƯỚC 1: ẨN DỤ ĐỜI THƯỜNG (FEYNMAN ANALOGY)
Điểm yếu (Vulnerability) là khe hở hay vết nứt trên bức tường rào của nhà bạn. Kẻ trộm (Threat) luôn tồn tại ngoài phố, nhưng nếu tường rào nhà bạn vững chắc không có vết nứt (không có Vulnerability), thì kẻ trộm chỉ đứng nhìn chứ không thể nào đột nhập vào được.
📊 HÌNH HỌA MINH HỌA (VISUAL FLOW): Vulnerability Identification (Nhận diện Điểm yếu Bảo mật)
Hệ thống Web Kiểm tra kiến trúc Phát hiện khe hở SQL nối chuỗi, JWT thiếu verify Đánh giá tác động Rò rỉ CSDL toàn hệ thống Gia cố điểm yếu Vá mã nguồn triệt để ⚠️ Lỗ hổng là điểm yếu nội tại của hệ thống cho phép kẻ tấn công khai thác
🧪 BƯỚC 2: PHÒNG THÍ NGHIỆM TƯƠNG TÁC (SANDBOX)
Mẫu thử nghiệm: VULN: Insecure Deserialization in Java ObjectInputStreamVULN: Hardcoded JWT secret keyVULN: Zero known vulnerabilities
⚠️ Điểm yếu giải mã ObjectInputStream cho phép thực thi mã từ xa (RCE)!
⚖️ BƯỚC 3: SO SÁNH CODE LỖI VS CODE CHUẨN (JAVA / SPRING BOOT)
❌ Vulnerable Java Code (Không an toàn)
// ĐIỂM YẾU BẢO MẬT: Dùng Java Native Deserialization không kiểm soát class
ObjectInputStream ois = new ObjectInputStream(clientSocket.getInputStream());
Object obj = ois.readObject(); // RCE VỚI GADGET CHAINS!
✅ Secure Java Code (Chuẩn bảo mật)
// CHUẨN AN TOÀN: Dùng định dạng dữ liệu trung lập (JSON) với ObjectMapper an toàn
ObjectMapper mapper = new ObjectMapper();
mapper.deactivateDefaultTyping(); // Chặn nạp Class tùy tiện
MySafeDto dto = mapper.readValue(jsonStream, MySafeDto.class);
🎯 BƯỚC 4: THỬ TÀI THẤU HIỂU (ACTIVE CHECK)
Mối quan hệ giữa Mối đe dọa (Threat) và Điểm yếu (Vulnerability) là gì?
A. Mối đe dọa là nguy cơ tiềm tàng bên ngoài; Điểm yếu là khiếm khuyết nội tại bên trong cho phép mối đe dọa biến thành hiện thực.
B. Cả hai từ này hoàn toàn đồng nghĩa.
C. Điểm yếu là kẻ trộm, mối đe dọa là cái khóa nhà.
D. Không có liên hệ gì với nhau.
📝 Tóm tắt nhanh bằng lời của bạn (Feynman Notebook): (Tự động lưu vào trình duyệt)

#04 Risk Assessment with DREAD (Đánh giá Rủi ro theo Mô hình DREAD)

💡 BƯỚC 1: ẨN DỤ ĐỜI THƯỜNG (FEYNMAN ANALOGY)
Khi bác sĩ chẩn đoán bệnh, họ chấm điểm mức độ nguy kịch: Bệnh này có lây nhanh không? Có thuốc chữa không? Có làm chết người không? DREAD cho điểm từ 1 đến 10 trên 5 tiêu chí: Mức độ tàn phá (Damage), Khả năng tái lập (Reproducibility), Độ dễ khai thác (Exploitability), Số người ảnh hưởng (Affected users), và Độ dễ phát hiện (Discoverability).
📊 HÌNH HỌA MINH HỌA (VISUAL FLOW): Risk Assessment with DREAD (Đánh giá Rủi ro theo Mô hình DREAD)
Damage (Mức tàn phá) Điểm 10/10 Exploitability (Độ dễ) Điểm 9/10 DREAD Score Tổng điểm: 45/50 (Rất cao) Kế hoạch xử lý Ưu tiên số 1 trong Sprint 🛡️ Công thức DREAD = (D + R + E + A + D) / 5 để định lượng mức độ ưu tiên
🧪 BƯỚC 2: PHÒNG THÍ NGHIỆM TƯƠNG TÁC (SANDBOX)
Mẫu thử nghiệm: DREAD: Damage=10, Reproducibility=10, Exploitability=9, Affected=10, Discoverability=9DREAD: Damage=2, Reproducibility=3, Exploitability=2, Affected=1, Discoverability=2
⚠️ Điểm DREAD trung bình: 9.6/10 (Rủi ro Khẩn cấp - Cần vá ngay lập tức)!
⚖️ BƯỚC 3: SO SÁNH CODE LỖI VS CODE CHUẨN (JAVA / SPRING BOOT)
❌ Vulnerable Java Code (Không an toàn)
// ĐÁNH GIÁ RỦI RO SAI LẦM:
// Coi một lỗ hổng RCE không cần đăng nhập có cùng mức độ ưu tiên
// với một lỗi chính tả hiển thị trên trang Điều khoản sử dụng!
✅ Secure Java Code (Chuẩn bảo mật)
// MA TRẬN RỦI RO DREAD:
// Risk Level = Impact (Mức độ tác động) x Likelihood (Khả năng xảy ra)
// - Critical (Score 40-50): Vá trong vòng 24 giờ
// - High (Score 30-39): Vá trong vòng 7 ngày
// - Medium (Score 20-29): Đưa vào Sprint hiện tại
// - Low (Score 0-19): Đưa vào Backlog
🎯 BƯỚC 4: THỬ TÀI THẤU HIỂU (ACTIVE CHECK)
Yếu tố 'Exploitability' trong mô hình DREAD đo lường điều gì?
A. Mức độ dễ dàng để một kẻ tấn công (dù không có trình độ cao) có thể thực hiện thành công cuộc tấn công.
B. Giá tiền của máy chủ.
C. Số lượng lập trình viên trong công ty.
D. Dung lượng bộ nhớ RAM còn trống.
📝 Tóm tắt nhanh bằng lời của bạn (Feynman Notebook): (Tự động lưu vào trình duyệt)

#05 Attack Surface Mapping (Lập bản đồ Bề mặt Tấn công)

💡 BƯỚC 1: ẨN DỤ ĐỜI THƯỜNG (FEYNMAN ANALOGY)
Bề mặt tấn công giống như toàn bộ số lượng cửa đi, cửa sổ, ống khói, và lỗ thông gió của một tòa nhà mà kẻ trộm có thể chui vào. Càng mở nhiều cửa sổ không cần thiết, người bảo vệ càng khó canh chừng. Thu hẹp bề mặt tấn công chính là xây bịt những cánh cửa thừa, chỉ giữ lại duy nhất 1 cửa chính có bảo vệ canh gác.
📊 HÌNH HỌA MINH HỌA (VISUAL FLOW): Attack Surface Mapping (Lập bản đồ Bề mặt Tấn công)
Hệ thống rộng lớn 100 ports, 500 APIs Attack Surface Audit Rà soát cổng & endpoint Thu hẹp bề mặt Đóng cổng thừa, tắt shadow API Kết quả Bề mặt tấn công tối thiểu 🛡️ Thu hẹp bề mặt tấn công (Attack Surface Reduction): Giảm thiểu số điểm tiếp xúc với Internet
🧪 BƯỚC 2: PHÒNG THÍ NGHIỆM TƯƠNG TÁC (SANDBOX)
Mẫu thử nghiệm: PORTS: 22, 80, 443, 3306, 5432, 8080, 9090 open to 0.0.0.0/0PORTS: 443 only via Cloudflare WAF
⚠️ Mở toang cổng CSDL 5432 và SSH 22 ra toàn mạng Internet!
⚖️ BƯỚC 3: SO SÁNH CODE LỖI VS CODE CHUẨN (JAVA / SPRING BOOT)
❌ Vulnerable Java Code (Không an toàn)
# BỀ MẶT TẤN CÔNG KHỔNG LỒ TRONG DOCKER COMPOSE:
ports:
  - "5432:5432" # Mở thẳng cổng Postgres ra ngoài Internet!
  - "6379:6379" # Mở thẳng cổng Redis không mật khẩu!
  - "8080:8080" # Mở thẳng backend không qua WAF!
✅ Secure Java Code (Chuẩn bảo mật)
# BỀ MẶT TẤN CÔNG TỐI THIỂU (HARDENED):
# Chỉ có Nginx Ingress Controller mở cổng 443 ra ngoài Internet
ports:
  - "443:443"
# PostgreSQL và Redis chỉ kết nối trong mạng nội bộ docker network, không mở port host:
networks:
  backend-tier:
    internal: true # Tuyệt đối không có Internet ingress!
🎯 BƯỚC 4: THỬ TÀI THẤU HIỂU (ACTIVE CHECK)
Hành động nào sau đây giúp thu hẹp bề mặt tấn công của một ứng dụng Spring Boot?
A. Tắt các Actuator endpoints không cần thiết, đóng các cổng debug, và chỉ mở cổng HTTPS thông qua API Gateway.
B. Cài thêm thật nhiều phần mềm giải trí lên máy chủ.
C. Mở toàn bộ cổng mạng từ 1 đến 65535.
D. Chia sẻ mật khẩu root cho mọi thành viên trong dự án.
📝 Tóm tắt nhanh bằng lời của bạn (Feynman Notebook): (Tự động lưu vào trình duyệt)

#06 Trust Boundaries & Security Zones (Ranh giới Tin cậy & Vùng Bảo mật)

💡 BƯỚC 1: ẨN DỤ ĐỜI THƯỜNG (FEYNMAN ANALOGY)
Trong một pháo đài cổ, có 3 lớp thành: Vòng ngoài là nơi dân chúng họp chợ (DMZ công cộng), vòng giữa là nơi đồn trú của binh lính (Application Zone), và trong cùng là pháo đài trung tâm cất giữ quốc bảo (Data Tier). Bất kỳ ai muốn đi từ vòng ngoài vào vòng trong đều phải dừng lại tại các cổng thành để trình giấy thông hành.
📊 HÌNH HỌA MINH HỌA (VISUAL FLOW): Trust Boundaries & Security Zones (Ranh giới Tin cậy & Vùng Bảo mật)
Public Internet Vùng không tin cậy DMZ / WAF Kiểm tra gói tin HTTP App Private Subnet Xử lý Business Logic Database Isolation Vùng bảo vệ cao nhất 🛡️ Kiến trúc 3 lớp (3-Tier): Phân tách vùng mạng an toàn bằng Security Groups & VPC
🧪 BƯỚC 2: PHÒNG THÍ NGHIỆM TƯƠNG TÁC (SANDBOX)
Mẫu thử nghiệm: ARCHITECTURE: Flat Network (All servers in 1 subnet)ARCHITECTURE: 3-Tier VPC with Isolated Subnets
⚠️ Mạng phẳng (Flat Network): Nếu Web Server bị hack, kẻ tấn công vào thẳng Database!
⚖️ BƯỚC 3: SO SÁNH CODE LỖI VS CODE CHUẨN (JAVA / SPRING BOOT)
❌ Vulnerable Java Code (Không an toàn)
// SAI LẦM: Không kiểm tra quyền khi request được chuyển tiếp từ service khác
// Tin tưởng tuyệt đối vì cho rằng nó đến từ IP nội bộ!
✅ Secure Java Code (Chuẩn bảo mật)
// KIẾN TRÚC AN TOÀN VÙNG BẢO MẬT:
// 1. Public Subnet: Chỉ chứa AWS ALB (Application Load Balancer)
// 2. Private App Subnet: Chứa Spring Boot ECS Containers
// 3. Isolated DB Subnet: Chứa RDS Aurora PostgreSQL (không có route ra Internet)
// Security Group DB: Chỉ nhận traffic cổng 5432 từ Security Group của App Container!
🎯 BƯỚC 4: THỬ TÀI THẤU HIỂU (ACTIVE CHECK)
Tại sao kiến trúc mạng phẳng (Flat Network - tất cả server chung một subnet) lại cực kỳ nguy hiểm?
A. Vì khi một máy chủ biên (như máy chủ Web công khai) bị thỏa hiệp, kẻ tấn công có thể dễ dàng di chuyển ngang (Lateral Movement) và tấn công thẳng vào CSDL mà không gặp vật cản.
B. Vì mạng phẳng làm chậm tốc độ gõ phím.
C. Vì mạng phẳng không thể cài đặt hệ điều hành Linux.
D. Vì nó làm tốn dung lượng pin laptop.
📝 Tóm tắt nhanh bằng lời của bạn (Feynman Notebook): (Tự động lưu vào trình duyệt)

#07 Data Flow Diagrams — DFD for Security (Sơ đồ Luồng Dữ liệu Bảo mật)

💡 BƯỚC 1: ẨN DỤ ĐỜI THƯỜNG (FEYNMAN ANALOGY)
Sơ đồ DFD giống như bản đồ hệ thống cấp thoát nước của một tòa nhà chung cư: Các hình chữ nhật là căn hộ (External Entities), các hình tròn là trạm bơm xử lý (Processes), hai vạch ngang là bể chứa nước (Data Stores), và các mũi tên là đường ống dẫn nước (Data Flows). Khi vẽ thêm các đường đứt nét đỏ (Trust Boundaries), bạn sẽ thấy ngay khúc ống nào đang chạy lộ thiên ngoài trời dễ bị kẻ xấu chọc thủng.
📊 HÌNH HỌA MINH HỌA (VISUAL FLOW): Data Flow Diagrams — DFD for Security (Sơ đồ Luồng Dữ liệu Bảo mật)
Entity: Khách hàng Web Browser Process: Đăng nhập Spring Auth Controller Trust Boundary Vượt qua ranh giới mạng Data Store: DB Users Bảng PostgreSQL 🛡️ DFD cấp độ 1: Mô hình hóa các thực thể, tiến trình, kho dữ liệu và ranh giới bảo mật
🧪 BƯỚC 2: PHÒNG THÍ NGHIỆM TƯƠNG TÁC (SANDBOX)
Mẫu thử nghiệm: DFD_ELEMENT: Process -> Data Flow -> StoreDFD_ELEMENT: Direct Entity to Data Store (Bypass Process)
⚠️ Phân tích luồng dữ liệu bảo mật trên sơ đồ DFD!
⚖️ BƯỚC 3: SO SÁNH CODE LỖI VS CODE CHUẨN (JAVA / SPRING BOOT)
❌ Vulnerable Java Code (Không an toàn)
// LỖI KIẾN TRÚC DFD: Để Client kết nối trực tiếp vào Database thông qua Firebase/Direct JDBC
// mà không có tầng Backend Business Logic kiểm soát!
✅ Secure Java Code (Chuẩn bảo mật)
// KIẾN TRÚC DFD ĐÚNG CHUẨN:
// [Client] --(HTTPS POST)--> [Spring Controller] 
//                                   |
//                              (@Valid & Authz)
//                                   v
//                             [Order Service] 
//                                   |
//                             (PreparedStatement)
//                                   v
//                             [(PostgreSQL DB)]
🎯 BƯỚC 4: THỬ TÀI THẤU HIỂU (ACTIVE CHECK)
Quy tắc cơ bản nào sau đây là BẮT BUỘC trong sơ đồ luồng dữ liệu (DFD) bảo mật?
A. Dữ liệu không bao giờ được phép chảy trực tiếp từ Thực thể bên ngoài (External Entity) vào Kho dữ liệu (Data Store) mà phải luôn đi qua một Tiến trình (Process) xử lý.
B. Mọi mũi tên bắt buộc phải có màu đỏ.
C. Kho dữ liệu chỉ được lưu tối đa 10 dòng.
D. Không được dùng sơ đồ cho các ứng dụng viết bằng Java.
📝 Tóm tắt nhanh bằng lời của bạn (Feynman Notebook): (Tự động lưu vào trình duyệt)

#08 Threat Actors & Motives (Phân loại Kẻ tấn công & Động cơ)

💡 BƯỚC 1: ẨN DỤ ĐỜI THƯỜNG (FEYNMAN ANALOGY)
Kẻ tấn công không phải ai cũng giống nhau: Có đứa trẻ tò mò nghịch ngợm tìm cách phá phách khoe khoang với bạn bè (Script Kiddies); có nhân viên bất mãn muốn trả thù sếp trước khi nghỉ việc (Insider Threat); có băng đảng tội phạm có tổ chức muốn tống tiền đòi Bitcoin (Cybercriminals); và có cả cơ quan tình báo quốc gia với nguồn kinh phí vô hạn muốn đánh sập lưới điện (Nation-state APT).
📊 HÌNH HỌA MINH HỌA (VISUAL FLOW): Threat Actors & Motives (Phân loại Kẻ tấn công & Động cơ)
Script Kiddies Dùng tool tự động, phá vặt Organized Crime Tống tiền Ransomware, tài chính Insider Threat Nhân viên nội bộ có đặc quyền Nation-State APT Tấn công có chủ đích, tài trợ ⚠️ Hiểu rõ đối thủ và động cơ để xây dựng chiến lược phòng thủ tương xứng
🧪 BƯỚC 2: PHÒNG THÍ NGHIỆM TƯƠNG TÁC (SANDBOX)
Mẫu thử nghiệm: ACTOR: Insider Threat (Nhân viên quản trị DB bất mãn)ACTOR: Script Kiddie using automated scannerACTOR: Nation-State Advanced Persistent Threat
⚠️ Nguy cơ từ nội bộ (Insider Threat): Người có sẵn quyền hợp pháp!
⚖️ BƯỚC 3: SO SÁNH CODE LỖI VS CODE CHUẨN (JAVA / SPRING BOOT)
❌ Vulnerable Java Code (Không an toàn)
// THIẾU KIỂM SOÁT NỘI BỘ: 1 Quản trị viên duy nhất có thể tự bấm nút chuyển 1 triệu USD
// mà không cần bất kỳ sự phê duyệt nào khác!
✅ Secure Java Code (Chuẩn bảo mật)
// CHUẨN AN TOÀN: Nguyên tắc Bốn mắt (Dual-control / Four-eyes Principle)
@PostMapping("/api/transfers/approve")
@PreAuthorize("hasRole('FINANCE_DIRECTOR')")
public ResponseEntity approveTransfer(@RequestParam Long transferId, 
                                        @AuthenticationPrincipal UserPrincipal director) {
    Transfer tx = transferRepo.findById(transferId).orElseThrow();
    // Người tạo lệnh (Maker) không bao giờ được phép tự duyệt (Checker)!
    if (tx.getCreatedByUserId().equals(director.getId())) {
        throw new SecurityException("Người tạo lệnh chuyển tiền không được tự mình phê duyệt!");
    }
    tx.approve(director.getId());
    return ResponseEntity.ok(transferRepo.save(tx));
}
🎯 BƯỚC 4: THỬ TÀI THẤU HIỂU (ACTIVE CHECK)
Biện pháp phòng ngừa hiệu quả nhất đối với mối đe dọa từ nội bộ (Insider Threat) là gì?
A. Phân chia quyền hạn (Separation of Duties), áp dụng quy trình kiểm soát kép (Four-eyes principle) và ghi log kiểm toán bất biến.
B. Không trả lương cho nhân viên.
C. Cấm nhân viên dùng máy tính.
D. Đổi mật khẩu WiFi mỗi 5 phút.
📝 Tóm tắt nhanh bằng lời của bạn (Feynman Notebook): (Tự động lưu vào trình duyệt)

#09 Attack Vectors & Attack Trees (Véc-tơ Tấn công & Cây Tấn công)

💡 BƯỚC 1: ẨN DỤ ĐỜI THƯỜNG (FEYNMAN ANALOGY)
Cây tấn công (Attack Tree) giống như sơ đồ chiến thuật của một tướng giặc muốn đánh chiếm một tòa thành (mục tiêu ở gốc cây: 'Đánh cắp CSDL'). Để đạt mục tiêu, hắn có 2 nhánh lớn: HOẶC là hack qua đường Internet (SQLi, SSRF), HOẶC là lừa nhân viên bảo vệ mở cửa (Phishing, Social Engineering). Mỗi nhánh lại rẽ ra các nhánh nhỏ hơn.
📊 HÌNH HỌA MINH HỌA (VISUAL FLOW): Attack Vectors & Attack Trees (Véc-tơ Tấn công & Cây Tấn công)
Gốc cây: Chiếm CSDL Mục tiêu tối thượng của Hacker Nhánh 1: SQL Injection Khai thác cổng Search API Nhánh 2: Stolen API Key Quét mã nguồn trên GitHub Phòng thủ toàn diện Chặt đứt mọi nhánh tấn công ⚠️ Cây tấn công giúp hình dung mọi con đường dẫn tới sự sụp đổ của hệ thống
🧪 BƯỚC 2: PHÒNG THÍ NGHIỆM TƯƠNG TÁC (SANDBOX)
Mẫu thử nghiệm: TARGET: Steal Admin Session via XSS on Comment FormTARGET: Phish Developer via Fake Slack MessageTARGET: Brute-force SSH Port 22
⚠️ Phân tích chuỗi mắt xích tấn công (Attack Chain) trên cây tấn công!
⚖️ BƯỚC 3: SO SÁNH CODE LỖI VS CODE CHUẨN (JAVA / SPRING BOOT)
❌ Vulnerable Java Code (Không an toàn)
// MẮT XÍCH YẾU: Để SessionID trong JavaScript Document.cookie
// Cho phép nhánh tấn công "XSS -> Steal Cookie" thành công rực rỡ!
✅ Secure Java Code (Chuẩn bảo mật)
// BẺ GÃY MẮT XÍCH: Đặt cờ HttpOnly cho Cookie
// Khiến nhánh tấn công cắp Cookie qua XSS bị chặn đứng hoàn toàn:
ResponseCookie cookie = ResponseCookie.from("JSESSIONID", id)
    .httpOnly(true) // JavaScript hoàn toàn bất lực không thể đọc!
    .secure(true)
    .sameSite("Strict")
    .build();
🎯 BƯỚC 4: THỬ TÀI THẤU HIỂU (ACTIVE CHECK)
Lợi ích lớn nhất của việc xây dựng Cây tấn công (Attack Tree) trong mô hình hóa mối đe dọa là gì?
A. Giúp đội ngũ an ninh nhìn thấy toàn diện tất cả các con đường khác nhau mà kẻ tấn công có thể đi để đạt được mục tiêu, từ đó ưu tiên nguồn lực bịt các nút thắt then chốt.
B. Dùng để trang trí văn phòng làm việc.
C. Tự động lập trình ứng dụng thay cho con người.
D. Tăng tốc độ kết nối 5G.
📝 Tóm tắt nhanh bằng lời của bạn (Feynman Notebook): (Tự động lưu vào trình duyệt)

#10 Defense-in-Depth Architecture (Kiến trúc Phòng thủ Chiều sâu / Đa tầng)

💡 BƯỚC 1: ẨN DỤ ĐỜI THƯỜNG (FEYNMAN ANALOGY)
Phòng thủ chiều sâu giống như trang bị bảo hộ cho một phi hành gia: Anh ta không chỉ có một lớp vải mỏng; anh ta có lớp vải chịu nhiệt bên ngoài, lớp sợi kevlar chống mảnh thiên thạch đâm thủng, lớp túi khí giữ áp suất, hệ thống dưỡng khí kép dự phòng, và bộ đàm cấp cứu. Nếu lớp ngoài cùng bị rách, các lớp bên trong vẫn giữ cho anh ta sống sót.
📊 HÌNH HỌA MINH HỌA (VISUAL FLOW): Defense-in-Depth Architecture (Kiến trúc Phòng thủ Chiều sâu / Đa tầng)
Lớp 1: Cloudflare WAF Chặn DDoS & Bad Bots Lớp 2: Spring Security MFA, JWT, CSRF Filter Lớp 3: Code Validation Jakarta Bean Validation Lớp 4: DB Least Privilege Mã hóa AES-256 tĩnh & động 🛡️ Defense-in-Depth: Không bao giờ phụ thuộc vào một chốt chặn bảo mật duy nhất
🧪 BƯỚC 2: PHÒNG THÍ NGHIỆM TƯƠNG TÁC (SANDBOX)
Mẫu thử nghiệm: DEFENSE_LAYERS: WAF only (Single point of failure)DEFENSE_LAYERS: WAF + Gateway + SpringSecurity + DB_Encryption
⚠️ Phân tích kiến trúc phòng thủ đa tầng nhiều lớp!
⚖️ BƯỚC 3: SO SÁNH CODE LỖI VS CODE CHUẨN (JAVA / SPRING BOOT)
❌ Vulnerable Java Code (Không an toàn)
// SAI LẦM TAI HẠI: "Đã có WAF ở cửa rồi nên code trong Java không cần sanitize dữ liệu nữa!"
// Nối chuỗi SQL thô vì tin rằng WAF sẽ chặn hết mọi ký tự nguy hiểm!
✅ Secure Java Code (Chuẩn bảo mật)
// CHUẨN AN TOÀN PHÒNG THỦ ĐA TẦNG:
// Lớp 1 (Network): WAF chặn các pattern tấn công phổ biến
// Lớp 2 (Transport): Bắt buộc HTTPS TLS 1.3
// Lớp 3 (App Perimeter): Spring Security xác thực MFA & OAuth2 JWT
// Lớp 4 (Input): Jakarta Bean Validation (@NotBlank, @Pattern)
// Lớp 5 (Logic): PreparedStatement tách rời tham số
// Lớp 6 (Storage): CSDL mã hóa TDE & cột nhạy cảm mã hóa AES-GCM
// Lớp 7 (Audit): Log kiểm toán bất biến đẩy về SIEM
🎯 BƯỚC 4: THỬ TÀI THẤU HIỂU (ACTIVE CHECK)
Nguyên lý cơ bản của triết lý 'Phòng thủ Chiều sâu' (Defense-in-Depth) là gì?
A. Triển khai nhiều lớp bảo vệ độc lập, sao cho nếu một lớp bảo mật bị kẻ tấn công vượt qua thì các lớp bảo mật kế tiếp vẫn ngăn chặn được cuộc tấn công.
B. Đào một cái hầm thật sâu dưới lòng đất để đặt máy chủ.
C. Chỉ mua phần mềm diệt virus đắt tiền nhất.
D. Đặt mật khẩu dài 1000 ký tự.
📝 Tóm tắt nhanh bằng lời của bạn (Feynman Notebook): (Tự động lưu vào trình duyệt)