@xdev-asia/xdev-knowledge-mcp 1.0.39 → 1.0.40

package/content/series/architecture/xay-dung-he-thong-y-te-microservices/chapters/03-phan-3-data-layer-postgresql/lessons/02-bai-10-ma-hoa-du-lieu-postgresql.md

@@ -23,37 +23,18 @@ course:
 
 ![4 lớp mã hóa dữ liệu y tế: Disk, TDE, Column, Application](/storage/uploads/2026/04/healthcare-encryption-layers.png)
 
-
 Dữ liệu y tế (PHI) yêu cầu mã hóa ở **hai trạng thái**: at-rest (khi lưu trữ) và in-transit (khi truyền). HIPAA Security Rule §164.312(a)(2)(iv) và §164.312(e)(2)(ii) quy định cụ thể về encryption requirements.
 
 ### 1.1. Encryption Layers
 
-```
-┌─────────────────────────────────────────────────────────┐
-│                    Data Lifecycle                        │
-│                                                         │
-│  Application ──── In-Transit ────► Database              │
-│                   (TLS 1.3)                              │
-│                                                         │
-│  ┌─────────────────────────────────────────────────┐    │
-│  │              At-Rest Encryption                  │    │
-│  │                                                  │    │
-│  │  Level 1: Full Disk Encryption (LUKS/dm-crypt)  │    │
-│  │     └── Bảo vệ khi disk bị đánh cắp            │    │
-│  │                                                  │    │
-│  │  Level 2: Transparent Data Encryption (TDE)     │    │
-│  │     └── Encrypt data files, WAL, temp files     │    │
-│  │                                                  │    │
-│  │  Level 3: Column-Level Encryption (pgcrypto)    │    │
-│  │     └── Encrypt từng field PHI riêng biệt       │    │
-│  │                                                  │    │
-│  │  Level 4: Application-Level Encryption          │    │
-│  │     └── Encrypt trước khi gửi tới database      │    │
-│  └─────────────────────────────────────────────────┘    │
-│                                                         │
-│  Backup ──── Encrypted Backup ────► S3 (SSE-KMS)       │
-└─────────────────────────────────────────────────────────┘
-```
+![Các lớp mã hóa dữ liệu y tế — In-Transit, At-Rest (4 levels), Backup](/storage/uploads/2026/04/healthcare-encryption-layers.png)
+
+- **In-Transit**: TLS 1.3 giữa Application và Database
+- **At-Rest Level 1**: Full Disk Encryption (LUKS/dm-crypt) — bảo vệ khi disk bị đánh cắp
+- **At-Rest Level 2**: Transparent Data Encryption (TDE) — encrypt data files, WAL, temp files
+- **At-Rest Level 3**: Column-Level Encryption (pgcrypto) — encrypt từng field PHI riêng biệt
+- **At-Rest Level 4**: Application-Level Encryption — encrypt trước khi gửi tới database
+- **Backup**: Encrypted Backup → S3 (SSE-KMS)
 
 ### 1.2. So sánh các phương pháp mã hóa
 
@@ -490,35 +471,15 @@ public class SslVerificationService {
 
 ### 5.1. Vault Transit Secrets Engine
 
-```
-┌─────────────────────────────────────────────────────────┐
-│              Envelope Encryption Pattern                 │
-│                                                         │
-│  ┌──────────┐      ┌──────────┐      ┌──────────┐     │
-│  │ Quarkus  │      │  Vault   │      │ HSM/KMS  │     │
-│  │ App      │      │ Transit  │      │          │     │
-│  └────┬─────┘      └────┬─────┘      └────┬─────┘     │
-│       │                  │                  │           │
-│  1. Generate DEK         │                  │           │
-│  (Data Encryption Key)   │                  │           │
-│       │                  │                  │           │
-│  2. Encrypt data         │                  │           │
-│     with DEK             │                  │           │
-│       │                  │                  │           │
-│  3. ─── Encrypt DEK ──►│                  │           │
-│       │                  │ 4. Wrap DEK     │           │
-│       │                  │    with KEK ────►│           │
-│       │  ◄── Wrapped ───│                  │           │
-│       │      DEK         │                  │           │
-│       │                  │                  │           │
-│  5. Store encrypted      │                  │           │
-│     data + wrapped DEK   │                  │           │
-│     in PostgreSQL        │                  │           │
-│                                                         │
-│  DEK = Data Encryption Key (per-record hoặc per-table) │
-│  KEK = Key Encryption Key (master key trong Vault)     │
-└─────────────────────────────────────────────────────────┘
-```
+![Envelope Encryption Pattern với Vault Transit — DEK + KEK](/storage/uploads/2026/04/healthcare-vault-envelope-encryption.png)
+
+**Quy trình Envelope Encryption:**
+
+1. Generate DEK (Data Encryption Key) — per-record hoặc per-table
+2. Encrypt data with DEK
+3. Gửi DEK tới Vault Transit để wrap
+4. Vault wrap DEK với KEK (Key Encryption Key) qua HSM/KMS
+5. Lưu encrypted data + wrapped DEK trong PostgreSQL
 
 ### 5.2. Vault Configuration
 
@@ -895,30 +856,13 @@ echo "Restore completed from: ${BACKUP_FILE}"
 
 ### 8.1. Quy trình Key Rotation
 
-```
-┌─────────────────────────────────────────────────────┐
-│              Key Rotation Timeline                   │
-│                                                      │
-│  Day 0          Day 90         Day 180               │
-│  ├──────────────┼──────────────┤                     │
-│  │   Key v1     │   Key v2     │   Key v3            │
-│  │  (active)    │  (active)    │  (active)           │
-│  │              │              │                     │
-│  │  Encrypt     │  RE-encrypt  │  RE-encrypt         │
-│  │  new data    │  old data    │  old data           │
-│  │  with v1     │  with v2     │  with v3            │
-│  │              │              │                     │
-│  │              │  v1 still    │  v1 retired         │
-│  │              │  can decrypt │  v2 can decrypt     │
-│  └──────────────┴──────────────┴─────────────────────│
-│                                                      │
-│  Vault tự động:                                      │
-│  - Rotate KEK mỗi 90 ngày                           │
-│  - OLD versions vẫn decrypt được                     │
-│  - NEW data encrypt bằng latest version              │
-│  - Rewrap: re-encrypt DEK với new KEK version        │
-└─────────────────────────────────────────────────────┘
-```
+![Key Rotation Timeline — v1 → v2 → v3 mỗi 90 ngày với Vault auto-rotation](/storage/uploads/2026/04/healthcare-key-rotation-timeline.png)
+
+- **Day 0–90**: Key v1 active — encrypt new data
+- **Day 90–180**: Key v2 active — re-encrypt old data, v1 vẫn decrypt được
+- **Day 180+**: Key v3 active — v1 retired, v2 vẫn decrypt được
+- Vault tự động rotate KEK, OLD versions vẫn decrypt, NEW data encrypt bằng latest
+- **Rewrap**: re-encrypt DEK với new KEK version
 
 ### 8.2. Batch Re-encryption Script
 
@@ -1004,6 +948,7 @@ Trong bài học này, chúng ta đã triển khai **mã hóa toàn diện** cho
 9. **Key Rotation**: Automated DEK rewrapping khi KEK rotate
 
 Nguyên tắc quan trọng:
+
 - **Never store encryption keys cùng với encrypted data**
 - **Always use authenticated encryption** (AES-GCM)
 - **Implement key rotation** với zero-downtime

package/content/series/architecture/xay-dung-he-thong-y-te-microservices/chapters/03-phan-3-data-layer-postgresql/lessons/03-bai-11-row-level-security-column-encryption.md

@@ -23,7 +23,6 @@ course:
 
 ![Row-Level Security Pipeline — JWT Claims → SET LOCAL → RLS Policy](/storage/uploads/2026/04/healthcare-rls-request-flow.png)
 
-
 Row-Level Security (RLS) cho phép PostgreSQL kiểm soát **hàng nào** trong bảng mà user có thể nhìn thấy hoặc thao tác. Đây là tính năng critical cho healthcare vì:
 
 - **Bác sĩ A** chỉ thấy bệnh nhân của mình
@@ -33,63 +32,35 @@ Row-Level Security (RLS) cho phép PostgreSQL kiểm soát **hàng nào** trong
 
 ### 1.1. RLS vs Application-Level Filtering
 
-```
-┌─────────────────────────────────────────────────────────┐
-│         Application-Level Filtering (KHÔNG AN TOÀN)      │
-│                                                          │
-│  SELECT * FROM patients WHERE doctor_id = :currentDoctor │
-│                                                          │
-│  Vấn đề:                                                │
-│  - Developer quên WHERE clause → data leak               │
-│  - SQL injection bypass WHERE clause                     │
-│  - Direct DB access bypass application logic             │
-│  - Reporting tools bypass application                    │
-└─────────────────────────────────────────────────────────┘
-
-┌─────────────────────────────────────────────────────────┐
-│         Row-Level Security (AN TOÀN)                     │
-│                                                          │
-│  SELECT * FROM patients;  ← Trả về CHỈ rows allowed    │
-│                                                          │
-│  Ưu điểm:                                               │
-│  - Database enforce, không bypass được                   │
-│  - Transparent cho application                           │
-│  - Works với mọi tool (psql, reporting, BI)             │
-│  - Defense in depth layer                               │
-└─────────────────────────────────────────────────────────┘
-```
+![So sánh Application-Level Filtering vs Row-Level Security trong PostgreSQL](/storage/uploads/2026/04/healthcare-rls-vs-app-filtering.png)
+
+**Application-Level Filtering (KHÔNG AN TOÀN):**
+
+- `SELECT * FROM patients WHERE doctor_id = :currentDoctor`
+- Developer quên WHERE clause → data leak
+- SQL injection bypass WHERE clause
+- Direct DB access bypass application logic
+- Reporting tools bypass application
+
+**Row-Level Security (AN TOÀN):**
+
+- `SELECT * FROM patients;` — Trả về CHỈ rows allowed
+- Database enforce, không bypass được
+- Transparent cho application
+- Works với mọi tool (psql, reporting, BI)
+- Defense in depth layer
 
 ### 1.2. RLS Architecture cho Healthcare
 
-```
-┌─────────────────────────────────────────────────────────┐
-│                  Request Flow                            │
-│                                                          │
-│  Quarkus App                                             │
-│      │                                                   │
-│      │ 1. Extract JWT claims                             │
-│      │    (user_id, role, department, hospital_id)       │
-│      │                                                   │
-│      │ 2. SET LOCAL session variables                    │
-│      │    SET LOCAL app.current_user_id = 'uuid';       │
-│      │    SET LOCAL app.current_role = 'doctor';        │
-│      │    SET LOCAL app.current_dept = 'cardiology';    │
-│      │    SET LOCAL app.hospital_id = 'uuid';           │
-│      │                                                   │
-│      │ 3. Execute query                                  │
-│      │    SELECT * FROM patients;                        │
-│      ▼                                                   │
-│  PostgreSQL                                              │
-│      │                                                   │
-│      │ 4. RLS Policy evaluates                           │
-│      │    current_setting('app.current_role')            │
-│      │    current_setting('app.current_dept')            │
-│      │                                                   │
-│      │ 5. Return ONLY allowed rows                       │
-│      ▼                                                   │
-│  Results (filtered by RLS)                               │
-└─────────────────────────────────────────────────────────┘
-```
+![RLS Request Flow — JWT → Session Variables → Policy Evaluation → Filtered Results](/storage/uploads/2026/04/healthcare-rls-request-flow.png)
+
+**Request Flow:**
+
+1. **Quarkus App** — Extract JWT claims (user_id, role, department, hospital_id)
+2. **SET LOCAL** session variables (`app.current_user_id`, `app.current_role`, `app.current_dept`, `app.hospital_id`)
+3. **Execute query** — `SELECT * FROM patients;`
+4. **PostgreSQL RLS Policy** evaluates `current_setting('app.current_role')`, `current_setting('app.current_dept')`
+5. **Return ONLY allowed rows** — Results filtered by RLS
 
 ## 2. Thiết lập RLS cơ bản
 

package/content/series/architecture/xay-dung-he-thong-y-te-microservices/chapters/03-phan-3-data-layer-postgresql/lessons/04-bai-12-audit-logging-cdc-pgaudit.md

@@ -23,61 +23,43 @@ course:
 
 ![Kiến trúc Audit Logging — pgAudit, Debezium CDC, Fluent Bit, ELK](/storage/uploads/2026/04/healthcare-audit-logging-stack.png)
 
-
 HIPAA Security Rule §164.312(b) yêu cầu **hardware, software, and/or procedural mechanisms that record and examine activity** trong hệ thống chứa ePHI. Audit logging không chỉ là compliance requirement mà còn là công cụ **phát hiện intrusion, forensics, và accountability**.
 
 ### 1.1. Audit Requirements cho Y Tế
 
-```
-┌─────────────────────────────────────────────────────────┐
-│              Healthcare Audit Requirements               │
-│                                                          │
-│  WHO?     ──► User identity (Keycloak subject)          │
-│  WHAT?    ──► Action performed (SELECT, INSERT, UPDATE)  │
-│  WHEN?    ──► Timestamp (with timezone)                  │
-│  WHERE?   ──► Source IP, application, service            │
-│  WHICH?   ──► Object accessed (table, column, row)       │
-│  HOW?     ──► Query text, parameters                     │
-│  RESULT?  ──► Success/failure, rows affected             │
-│                                                          │
-│  Additional Healthcare Requirements:                     │
-│  - PHI access tracking                                   │
-│  - Break-the-glass audit                                 │
-│  - Before/After values cho data changes                  │
-│  - Immutable audit trail (no tampering)                  │
-│  - 6-year retention (HIPAA minimum)                      │
-└─────────────────────────────────────────────────────────┘
-```
+| Yêu cầu | Mô tả |
+|---------|--------|
+| **WHO?** | User identity (Keycloak subject) |
+| **WHAT?** | Action performed (SELECT, INSERT, UPDATE) |
+| **WHEN?** | Timestamp (with timezone) |
+| **WHERE?** | Source IP, application, service |
+| **WHICH?** | Object accessed (table, column, row) |
+| **HOW?** | Query text, parameters |
+| **RESULT?** | Success/failure, rows affected |
+
+**Yêu cầu bổ sung cho Healthcare:**
+
+- PHI access tracking
+- Break-the-glass audit
+- Before/After values cho data changes
+- Immutable audit trail (no tampering)
+- 6-year retention (HIPAA minimum)
 
 ### 1.2. Audit Architecture
 
-```
-┌─────────────────────────────────────────────────────────┐
-│                      Audit Stack                         │
-│                                                          │
-│  ┌──────────┐     ┌──────────┐     ┌──────────┐        │
-│  │ Quarkus  │     │PostgreSQL│     │ Debezium │        │
-│  │ App Logs │     │ pgAudit  │     │ CDC      │        │
-│  └────┬─────┘     └────┬─────┘     └────┬─────┘        │
-│       │                │                 │               │
-│       │ JSON logs      │ CSV/syslog     │ Kafka events  │
-│       │                │                 │               │
-│       └────────────────┼─────────────────┘               │
-│                        │                                 │
-│                   ┌────▼─────┐                           │
-│                   │ Fluent   │                           │
-│                   │ Bit      │                           │
-│                   └────┬─────┘                           │
-│                        │                                 │
-│              ┌─────────┼─────────┐                       │
-│              │         │         │                       │
-│         ┌────▼───┐ ┌───▼────┐ ┌──▼──────┐              │
-│         │OpenSear│ │ S3     │ │PostgreSQ│              │
-│         │ch/ELK  │ │Archive │ │L Audit  │              │
-│         │(Query) │ │(7 yrs) │ │DB       │              │
-│         └────────┘ └────────┘ └─────────┘              │
-└─────────────────────────────────────────────────────────┘
-```
+![Audit Stack — Quarkus + pgAudit + Debezium CDC → FluentBit → OpenSearch/S3/PostgreSQL](/storage/uploads/2026/04/healthcare-audit-architecture.png)
+
+**Audit Sources:**
+
+- **Quarkus App Logs** → JSON logs
+- **PostgreSQL pgAudit** → CSV/syslog
+- **Debezium CDC** → Kafka events
+
+**Pipeline:** Tất cả → **FluentBit** → phân phối tới:
+
+- **OpenSearch/ELK** — Query & visualization
+- **S3 Archive** — Lưu trữ 7 năm
+- **PostgreSQL Audit DB** — Structured query
 
 ## 2. pgAudit - Installation & Configuration
 
@@ -179,6 +161,7 @@ SELECT * FROM patient_schema.patients;
 ```
 
 Audit log output (CSV format):
+
 ```
 2025-01-15 10:30:45.123 ICT [12345] user=app_patient_svc,db=healthcare_db,app=patient-service,client=10.0.1.10
 AUDIT: SESSION,1,1,WRITE,INSERT,,patient_schema.patients,
@@ -240,6 +223,7 @@ ORDER BY relname;
 ## 4. Custom Audit Trigger Functions
 
 pgAudit ghi lại **SQL statements**, nhưng không capture:
+
 - **Before/After values** (old vs new data)
 - **Application-level context** (JWT user, IP)
 - **Business-level events** (who viewed which patient record)
@@ -524,38 +508,20 @@ $$ LANGUAGE plpgsql SECURITY DEFINER;
 
 ### 5.1. CDC Architecture
 
-```
-┌─────────────────────────────────────────────────────────┐
-│              CDC với Debezium + Kafka                    │
-│                                                          │
-│  PostgreSQL                                              │
-│  ┌──────────┐                                            │
-│  │ WAL      │ ← Write-Ahead Log (logical replication)   │
-│  │ (changes)│                                            │
-│  └────┬─────┘                                            │
-│       │ Logical Decoding                                 │
-│       ▼                                                  │
-│  ┌──────────┐                                            │
-│  │ Debezium │ ← Kafka Connect Source Connector           │
-│  │Connector │                                            │
-│  └────┬─────┘                                            │
-│       │ JSON change events                               │
-│       ▼                                                  │
-│  ┌──────────────────────────────────────────┐            │
-│  │              Apache Kafka                 │            │
-│  │  Topics:                                  │            │
-│  │  ├── healthcare.patient_schema.patients   │            │
-│  │  ├── healthcare.patient_schema.records    │            │
-│  │  └── healthcare.audit_schema.changes      │            │
-│  └────┬─────────────┬───────────┬───────────┘            │
-│       │             │           │                        │
-│  ┌────▼───┐   ┌─────▼──┐  ┌────▼────┐                  │
-│  │OpenSear│   │ Audit  │  │ Alert   │                  │
-│  │ch Sink │   │ S3     │  │ Engine  │                  │
-│  │Connect │   │Archive │  │(KSQL)   │                  │
-│  └────────┘   └────────┘  └─────────┘                  │
-└─────────────────────────────────────────────────────────┘
-```
+![CDC Pipeline — PostgreSQL WAL → Debezium → Kafka → OpenSearch/S3/KSQL](/storage/uploads/2026/04/healthcare-cdc-pipeline.png)
+
+**CDC Flow:**
+
+1. **PostgreSQL WAL** — Write-Ahead Log (logical replication)
+2. **Logical Decoding** → **Debezium Connector** (Kafka Connect Source)
+3. **JSON change events** → **Apache Kafka** Topics:
+   - `healthcare.patient_schema.patients`
+   - `healthcare.patient_schema.records`
+   - `healthcare.audit_schema.changes`
+4. **Consumers:**
+   - **OpenSearch Sink Connect** — Full-text search
+   - **Audit S3 Archive** — Long-term retention
+   - **Alert Engine (KSQL)** — Real-time anomaly detection
 
 ### 5.2. PostgreSQL Configuration cho CDC
 
@@ -1200,13 +1166,11 @@ Trong bài học này, chúng ta đã xây dựng **hệ thống Audit Logging t
 9. **Monitoring**: Prometheus alerting cho replication lag, trigger health, access anomalies
 
 Architecture tổng thể:
-```
-App Audit (Quarkus)  ──► Kafka  ──► OpenSearch (real-time query)
-                              └──► S3 (archive 7+ years)
-DB Audit (pgAudit)   ──► CSV   ──► Fluent Bit ──► OpenSearch
-Custom Triggers      ──► audit_schema tables ──► Compliance Reports
-CDC (Debezium)       ──► Kafka  ──► KSQL (anomaly detection)
-```
+
+- **App Audit (Quarkus)** → Kafka → OpenSearch (real-time query) + S3 (archive 7+ years)
+- **DB Audit (pgAudit)** → CSV → Fluent Bit → OpenSearch
+- **Custom Triggers** → `audit_schema` tables → Compliance Reports
+- **CDC (Debezium)** → Kafka → KSQL (anomaly detection)
 
 ## Bài tập
 

package/content/series/architecture/xay-dung-he-thong-y-te-microservices/chapters/04-phan-4-microservices-quarkus/lessons/03-bai-15-ma-hoa-end-to-end-microservices.md

@@ -26,42 +26,14 @@ Trong hệ thống microservices y tế, dữ liệu PHI di chuyển qua **nhi
 
 ### 1.1. Encryption Architecture
 
-```
-┌─────────────────────────────────────────────────────────────┐
-│            End-to-End Encryption Architecture                │
-│                                                              │
-│  Client                                                      │
-│    │  TLS 1.3 (transport encryption)                         │
-│    ▼                                                         │
-│  API Gateway                                                 │
-│    │  JWT token validation                                   │
-│    ▼                                                         │
-│  Patient Service                                             │
-│    │  Field-level encryption (SSN, diagnosis)                │
-│    │  ┌─────────────────────┐                                │
-│    │  │ Vault Transit Engine │ ◄── Key Management            │
-│    │  │ (envelope encryption)│     Key Rotation               │
-│    │  └─────────────────────┘                                │
-│    │                                                         │
-│    ├──► PostgreSQL (encrypted columns stored)                │
-│    │    AES-256-GCM encrypted fields                         │
-│    │                                                         │
-│    ├──► Kafka (encrypted messages)                           │
-│    │    JWE (JSON Web Encryption)                             │
-│    │    Custom Serializer/Deserializer                        │
-│    │                                                         │
-│    └──► Lab Service (JWE payload)                            │
-│         Decrypt with shared transit key                       │
-│                                                              │
-│  ┌──────────────────────────────────────────────────────┐    │
-│  │            HashiCorp Vault                            │    │
-│  │  Transit Engine ──► Encryption keys                   │    │
-│  │  KV Engine      ──► Database credentials              │    │
-│  │  PKI Engine     ──► TLS certificates                  │    │
-│  │  Auto-unseal    ──► Cloud KMS                         │    │
-│  └──────────────────────────────────────────────────────┘    │
-└─────────────────────────────────────────────────────────────┘
-```
+![End-to-End Encryption Architecture — Client → API Gateway → Services → Database với Vault](/storage/uploads/2026/04/healthcare-e2e-encryption-flow.png)
+
+**Encryption Flow:**
+
+- **Client** → **API Gateway**: TLS 1.3 (transport encryption) + JWT validation
+- **Patient Service**: Field-level encryption (SSN, diagnosis) với Vault Transit Engine
+- **Outputs**: PostgreSQL (AES-256-GCM encrypted columns), Kafka (JWE messages), Lab Service (JWE payload)
+- **HashiCorp Vault**: Transit Engine (encryption keys), KV Engine (credentials), PKI Engine (TLS certs), Auto-unseal (Cloud KMS)
 
 ### 1.2. Encryption Layers
 
@@ -231,33 +203,15 @@ CREATE INDEX idx_blind_hash ON healthcare.patients_blind_index(field_name, blind
 
 ### 3.1. Envelope Encryption Pattern
 
-```
-┌─────────────────────────────────────────────────────────┐
-│              Envelope Encryption Pattern                  │
-│                                                          │
-│  1. App generates random Data Encryption Key (DEK)       │
-│  2. App encrypts plaintext with DEK (AES-256-GCM)       │
-│  3. App sends DEK to Vault Transit for wrapping          │
-│  4. Vault encrypts DEK with Key Encryption Key (KEK)    │
-│  5. App stores: encrypted_data + wrapped_DEK             │
-│                                                          │
-│  ┌──────────┐    ┌───────────────┐    ┌──────────┐      │
-│  │ Plaintext│    │ Vault Transit │    │ Database │      │
-│  │ "SSN:    │    │               │    │          │      │
-│  │  123..."  │    │ KEK (master)  │    │ encrypted│      │
-│  └────┬─────┘    │               │    │ _data +  │      │
-│       │          │ wrap(DEK)→    │    │ wrapped  │      │
-│       ▼          │ wrapped_DEK   │    │ _DEK     │      │
-│  DEK(random)     │               │    │          │      │
-│       │          │ unwrap(       │    │          │      │
-│       ▼          │ wrapped_DEK)  │    │          │      │
-│  AES-256-GCM     │ → DEK         │    │          │      │
-│  encrypt         │               │    │          │      │
-│       │          └───────────────┘    └──────────┘      │
-│       ▼                                                  │
-│  encrypted_data                                          │
-└─────────────────────────────────────────────────────────┘
-```
+![Envelope Encryption Pattern — DEK + KEK với Vault Transit](/storage/uploads/2026/04/healthcare-envelope-encryption.png)
+
+**Quy trình:**
+
+1. App generates random Data Encryption Key (DEK)
+2. App encrypts plaintext with DEK (AES-256-GCM)
+3. App sends DEK to Vault Transit for wrapping
+4. Vault encrypts DEK with Key Encryption Key (KEK)
+5. App stores: `encrypted_data` + `wrapped_DEK` trong database
 
 ### 3.2. Vault Transit Engine Setup
 
@@ -1200,6 +1154,7 @@ Trong bài học này, chúng ta đã xây dựng **End-to-End Encryption** toà
 7. **PHI Masking**: Logging filter ngăn PHI leak vào logs, exception sanitization
 
 Encryption landscape:
+
 ```
 Client ──[TLS 1.3]──► Gateway ──[TLS]──► Service
                                               │