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)
🧪 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ì?
📝 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)
🧪 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ì?
📝 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)
🧪 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ì?
📝 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)
🧪 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ì?
📝 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)
🧪 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?
📝 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)
🧪 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?
📝 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)
🧪 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?
📝 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ơ)
🧪 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ì?
📝 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)
🧪 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ì?
📝 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)
🧪 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ì?
📝 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)