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

package/content/series/architecture/xay-dung-he-thong-y-te-microservices/chapters/01-phan-1-kien-truc-nen-tang/lessons/04-bai-4-threat-modeling-stride-dread.md

@@ -203,25 +203,25 @@ public PatientSummaryDTO getPatient(@PathParam("id") UUID id) {
 
 #### D - Denial of Service
 
-```
-Threat: Tấn công DDoS khiến hệ thống cấp cứu ngừng hoạt động
-───────────────────────────────────────────────────────────
-Impact trong Y Tế:
-  - Không thể tra cứu dị ứng thuốc → kê đơn sai → nguy hiểm
-  - Không truy cập được lab results → chẩn đoán chậm
-  - Hệ thống đặt lịch down → bệnh nhân không thể đến khám
-
-Mitigations:
-  ┌────────────────────────────────────────────┐
-  │ M1: Rate limiting at API Gateway           │
-  │ M2: Circuit breaker (Quarkus Fault Toler.) │
-  │ M3: Auto-scaling Kubernetes pods           │
-  │ M4: CDN/WAF (Cloudflare, AWS Shield)       │
-  │ M5: Database connection pooling            │
-  │ M6: Fallback mode / offline capability     │
-  │ M7: Priority queuing for ER requests       │
-  └────────────────────────────────────────────┘
-```
+![DoS mitigation — 7 lớp bảo vệ chống DDoS cho hệ thống y tế](/storage/uploads/2026/04/healthcare-stride-dos-mitigation.png)
+
+**Threat:** Tấn công DDoS khiến hệ thống cấp cứu ngừng hoạt động
+
+**Impact trong Y Tế:**
+
+- Không thể tra cứu dị ứng thuốc → kê đơn sai → nguy hiểm
+- Không truy cập được lab results → chẩn đoán chậm
+- Hệ thống đặt lịch down → bệnh nhân không thể đến khám
+
+**Mitigations:**
+
+- **M1:** Rate limiting at API Gateway
+- **M2:** Circuit breaker (Quarkus Fault Tolerance)
+- **M3:** Auto-scaling Kubernetes pods
+- **M4:** CDN/WAF (Cloudflare, AWS Shield)
+- **M5:** Database connection pooling
+- **M6:** Fallback mode / offline capability
+- **M7:** Priority queuing for ER requests
 
 #### E - Elevation of Privilege
 
@@ -325,39 +325,28 @@ public class PrescriptionResource {
 
 ### 5.1. Attack Tree: Steal Patient Medical Records
 
-```
-Goal: Steal Patient Medical Records
-│
-├── 1. External Attack
-│   ├── 1.1 Exploit Web Application
-│   │   ├── 1.1.1 SQL Injection [DREAD: 8.6] ★
-│   │   ├── 1.1.2 XSS to steal session [DREAD: 7.2]
-│   │   └── 1.1.3 IDOR to access other patients [DREAD: 7.0]
-│   │
-│   ├── 1.2 Compromise Authentication
-│   │   ├── 1.2.1 Credential stuffing [DREAD: 5.4]
-│   │   ├── 1.2.2 Phishing doctor credentials [DREAD: 6.8]
-│   │   └── 1.2.3 Brute force Keycloak [DREAD: 3.2]
-│   │
-│   └── 1.3 Network Attack
-│       ├── 1.3.1 MITM on API calls [DREAD: 4.6]
-│       └── 1.3.2 DNS spoofing [DREAD: 4.2]
-│
-├── 2. Internal Attack (Insider Threat)
-│   ├── 2.1 Privileged User Abuse
-│   │   ├── 2.1.1 DBA exports database [DREAD: 6.8]
-│   │   ├── 2.1.2 Admin disables audit [DREAD: 5.6]
-│   │   └── 2.1.3 Doctor accesses non-patient [DREAD: 6.0]
-│   │
-│   └── 2.2 Stolen Credentials
-│       ├── 2.2.1 Shared workstation session [DREAD: 6.2]
-│       └── 2.2.2 Post-it password [DREAD: 5.0]
-│
-└── 3. Supply Chain Attack
-    ├── 3.1 Compromised dependency [DREAD: 7.8]
-    ├── 3.2 Malicious Docker image [DREAD: 6.4]
-    └── 3.3 Compromised CI/CD pipeline [DREAD: 7.0]
-```
+![Attack Tree — các vector tấn công đánh cắp hồ sơ bệnh nhân với DREAD scoring](/storage/uploads/2026/04/healthcare-attack-tree.png)
+
+**Goal: Steal Patient Medical Records**
+
+| Attack Path | DREAD | Priority |
+|---|---|---|
+| 1.1.1 SQL Injection | 8.6 | CRITICAL |
+| 1.1.2 XSS to steal session | 7.2 | HIGH |
+| 1.1.3 IDOR to access other patients | 7.0 | HIGH |
+| 1.2.1 Credential stuffing | 5.4 | MEDIUM |
+| 1.2.2 Phishing doctor credentials | 6.8 | HIGH |
+| 1.2.3 Brute force Keycloak | 3.2 | LOW |
+| 1.3.1 MITM on API calls | 4.6 | MEDIUM |
+| 1.3.2 DNS spoofing | 4.2 | MEDIUM |
+| 2.1.1 DBA exports database | 6.8 | HIGH |
+| 2.1.2 Admin disables audit | 5.6 | MEDIUM |
+| 2.1.3 Doctor accesses non-patient | 6.0 | MEDIUM |
+| 2.2.1 Shared workstation session | 6.2 | MEDIUM |
+| 2.2.2 Post-it password | 5.0 | MEDIUM |
+| 3.1 Compromised dependency | 7.8 | HIGH |
+| 3.2 Malicious Docker image | 6.4 | HIGH |
+| 3.3 Compromised CI/CD pipeline | 7.0 | HIGH |
 
 ## 6. Từ Threat Model đến Security Requirements
 

package/content/series/architecture/xay-dung-he-thong-y-te-microservices/chapters/02-phan-2-iam-keycloak/lessons/01-bai-5-setup-keycloak-realm-benh-vien.md

@@ -26,46 +26,13 @@ course:
 
 Khi xây dựng hệ thống y tế cho nhiều bệnh viện/phòng khám, có 3 chiến lược:
 
-```
-Strategy A: Realm per Hospital (Isolation cao)
-┌───────────────────────────────────────────┐
-│ Keycloak Instance                         │
-│  ┌──────────┐ ┌──────────┐ ┌──────────┐  │
-│  │ BV Chợ   │ │ BV Bình  │ │ BV Nhân  │  │
-│  │ Rẫy      │ │ Dân      │ │ Dân 115  │  │
-│  │ Realm    │ │ Realm    │ │ Realm    │  │
-│  └──────────┘ └──────────┘ └──────────┘  │
-│  → Isolated users, roles, clients         │
-│  → Best for: Independent hospitals        │
-└───────────────────────────────────────────┘
-
-Strategy B: Shared Realm + Organizations (Keycloak 26+)
-┌───────────────────────────────────────────┐
-│ Keycloak Instance                         │
-│  ┌──────────────────────────────────────┐ │
-│  │         Healthcare Realm              │ │
-│  │  ┌─────────┐ ┌─────────┐ ┌────────┐  │ │
-│  │  │ Org:    │ │ Org:    │ │ Org:   │  │ │
-│  │  │ BV CR   │ │ BV BD   │ │ BV ND  │  │ │
-│  │  └─────────┘ └─────────┘ └────────┘  │ │
-│  │  → Shared identity + org isolation    │ │
-│  │  → Best for: Hospital networks        │ │
-│  └──────────────────────────────────────┘ │
-└───────────────────────────────────────────┘
-
-Strategy C: Shared Realm + Groups (Simple)
-┌───────────────────────────────────────────┐
-│ Keycloak Instance                         │
-│  ┌──────────────────────────────────────┐ │
-│  │         Healthcare Realm              │ │
-│  │  Groups: /hospitals/bv-cho-ray        │ │
-│  │          /hospitals/bv-binh-dan       │ │
-│  │          /hospitals/bv-nhan-dan       │ │
-│  │  → Simple, less isolation             │ │
-│  │  → Best for: Small clinic networks    │ │
-│  └──────────────────────────────────────┘ │
-└───────────────────────────────────────────┘
-```
+![3 chiến lược Keycloak Multi-tenancy cho hệ thống đa bệnh viện](/storage/uploads/2026/04/healthcare-keycloak-multitenancy.png)
+
+| Strategy | Mô hình | Isolation | Phù hợp |
+|----------|---------|-----------|----------|
+| **A: Realm per Hospital** | Mỗi bệnh viện 1 Realm riêng | Cao nhất — isolated users, roles, clients | Bệnh viện độc lập |
+| **B: Shared Realm + Organizations** | 1 Healthcare Realm, mỗi BV là 1 Organization | Trung bình — shared identity + org isolation | Chuỗi bệnh viện, Sở Y tế |
+| **C: Shared Realm + Groups** | 1 Realm, phân chia bằng Groups | Thấp — simple, less isolation | Phòng khám nhỏ |
 
 ### 1.2. Khuyến nghị cho Y Tế Việt Nam
 
@@ -143,29 +110,23 @@ Strategy C: Shared Realm + Groups (Simple)
 
 ### 3.1. Clients Overview
 
-```
-┌─────────────────────────────────────────────────────┐
-│              Healthcare Keycloak Clients              │
-├─────────────────────┬───────────────────────────────┤
-│ Client              │ Type        │ Description      │
-├─────────────────────┼─────────────┼─────────────────┤
-│ his-web-app         │ Public      │ HIS Web Frontend │
-│ emr-web-app         │ Public      │ EMR Web Frontend │
-│ patient-portal      │ Public      │ Patient Portal   │
-│ mobile-doctor-app   │ Public      │ Doctor Mobile App│
-│ patient-service     │ Confidential│ Patient API      │
-│ clinical-service    │ Confidential│ Clinical API     │
-│ lab-service         │ Confidential│ Lab Results API  │
-│ pharmacy-service    │ Confidential│ Pharmacy API     │
-│ scheduling-service  │ Confidential│ Scheduling API   │
-│ billing-service     │ Confidential│ Billing API      │
-│ notification-service│ Confidential│ Notifications    │
-│ audit-service       │ Confidential│ Audit/Logging    │
-│ api-gateway         │ Confidential│ Kong/APISIX      │
-│ admin-cli           │ Confidential│ Admin Operations │
-│ fhir-server         │ Confidential│ HAPI FHIR Server │
-└─────────────────────┴─────────────┴─────────────────┘
-```
+| Client | Type | Description |
+|--------|------|-------------|
+| his-web-app | Public | HIS Web Frontend |
+| emr-web-app | Public | EMR Web Frontend |
+| patient-portal | Public | Patient Portal |
+| mobile-doctor-app | Public | Doctor Mobile App |
+| patient-service | Confidential | Patient API |
+| clinical-service | Confidential | Clinical API |
+| lab-service | Confidential | Lab Results API |
+| pharmacy-service | Confidential | Pharmacy API |
+| scheduling-service | Confidential | Scheduling API |
+| billing-service | Confidential | Billing API |
+| notification-service | Confidential | Notifications |
+| audit-service | Confidential | Audit/Logging |
+| api-gateway | Confidential | Kong/APISIX |
+| admin-cli | Confidential | Admin Operations |
+| fhir-server | Confidential | HAPI FHIR Server |
 
 ### 3.2. Patient Portal Client (Public)
 
@@ -400,27 +361,15 @@ Realm Roles:
 
 ### 6.2. Shared Workstation Support
 
-```
-Bệnh viện thường có shared workstations — nhiều bác sĩ/y tá
-dùng chung 1 máy tính. Giải pháp:
-
-┌──────────────────────────────────────────────┐
-│ Option 1: Fast User Switching               │
-│ → Keycloak short session + badge login       │
-│ → Pro: Nhanh, tiện lợi                      │
-│ → Con: Cần infrastructure (badge reader)     │
-├──────────────────────────────────────────────┤
-│ Option 2: Auto-logoff + Quick re-auth       │
-│ → Session timeout 10-15 min + PIN            │
-│ → Pro: Simple, no hardware needed            │
-│ → Con: Slower than badge                     │
-├──────────────────────────────────────────────┤
-│ Option 3: Virtual Desktop (VDI)             │
-│ → Each user has own virtual desktop          │
-│ → Pro: Full isolation                        │
-│ → Con: Expensive, higher latency             │
-└──────────────────────────────────────────────┘
-```
+Bệnh viện thường có shared workstations — nhiều bác sĩ/y tá dùng chung 1 máy tính. Giải pháp:
+
+![3 phương án xác thực trên shared workstation bệnh viện](/storage/uploads/2026/04/healthcare-shared-workstation-auth.png)
+
+| Option | Cơ chế | Ưu điểm | Hạn chế |
+|--------|---------|---------|----------|
+| **1. Fast User Switching** | Keycloak short session + badge login | Nhanh, tiện lợi | Cần infrastructure (badge reader) |
+| **2. Auto-logoff + Quick re-auth** | Session timeout 10-15 min + PIN | Simple, no hardware needed | Chậm hơn badge |
+| **3. Virtual Desktop (VDI)** | Mỗi user 1 virtual desktop riêng | Full isolation | Đắt, higher latency |
 
 ## 7. Realm Export/Import Automation
 

package/content/series/architecture/xay-dung-he-thong-y-te-microservices/chapters/02-phan-2-iam-keycloak/lessons/02-bai-6-phan-quyen-rbac-abac.md

@@ -23,7 +23,6 @@ course:
 
 ![Kiến trúc 4 lớp kiểm soát truy cập: RBAC, ABAC, RLS, Patient Consent](/storage/uploads/2026/04/healthcare-rbac-abac-layers.png)
 
-
 ### 1.1. Role-Based Access Control (RBAC)
 
 RBAC gán quyền dựa trên **vai trò** của người dùng trong tổ chức:
@@ -58,28 +57,12 @@ Policy: ALLOW if
 
 ### 1.3. Kết hợp RBAC + ABAC cho Y Tế
 
-```
-┌──────────────────────────────────────────────────────┐
-│              Healthcare Access Decision               │
-│                                                       │
-│  Layer 1: RBAC (Keycloak Roles)                      │
-│  ├── Is user a doctor? → Can access clinical data     │
-│  ├── Is user a nurse? → Can access vital signs        │
-│  └── Is user a patient? → Can access own records      │
-│                                                       │
-│  Layer 2: ABAC (Keycloak Authorization Services)     │
-│  ├── Department match? → Only own department data     │
-│  ├── Treatment relationship? → Assigned patients only │
-│  ├── Time-based? → After-hours requires MFA           │
-│  └── Location-based? → External requires VPN          │
-│                                                       │
-│  Layer 3: RLS (PostgreSQL Row-Level Security)        │
-│  └── Database enforces per-row access based on JWT    │
-│                                                       │
-│  Layer 4: Consent (Patient consent check)            │
-│  └── Patient has granted access for this purpose?     │
-└──────────────────────────────────────────────────────┘
-```
+| Layer | Tên | Cơ chế | Ví dụ |
+|-------|-----|---------|--------|
+| **Layer 1** | RBAC (Keycloak Roles) | Is user a doctor? → Can access clinical data. Is user a nurse? → Can access vital signs. Is user a patient? → Can access own records. | `@RolesAllowed("doctor")` |
+| **Layer 2** | ABAC (Keycloak Authorization Services) | Department match? → Only own department data. Treatment relationship? → Assigned patients only. Time-based? → After-hours requires MFA. Location-based? → External requires VPN. | Custom policies |
+| **Layer 3** | RLS (PostgreSQL Row-Level Security) | Database enforces per-row access based on JWT claims | `CREATE POLICY` |
+| **Layer 4** | Consent (Patient consent check) | Patient has granted access for this purpose? | FHIR Consent resource |
 
 ## 2. Keycloak Authorization Services
 

package/content/series/architecture/xay-dung-he-thong-y-te-microservices/chapters/02-phan-2-iam-keycloak/lessons/03-bai-7-smart-on-fhir-oauth2-oidc.md

@@ -23,7 +23,6 @@ course:
 
 ![SMART on FHIR Launch Flow — OAuth2/OIDC qua Keycloak cho EHR](/storage/uploads/2026/04/healthcare-smart-fhir-launch-flow.png)
 
-
 ### 1.1. SMART là gì?
 
 **SMART (Substitutable Medical Applications, Reusable Technologies)** on FHIR là một tiêu chuẩn mở cho phép các ứng dụng third-party truy cập dữ liệu y tế một cách an toàn thông qua FHIR APIs. SMART định nghĩa:
@@ -35,41 +34,31 @@ course:
 
 ### 1.2. SMART App Launch Flows
 
-```
-┌──────────────────────────────────────────────────────┐
-│               EHR Launch Flow                         │
-│                                                       │
-│ 1. User clicks "Launch App" in EHR                   │
-│ 2. EHR sends launch request with context              │
-│    (patient ID, encounter ID)                        │
-│ 3. App redirects to Authorization Server (Keycloak)  │
-│ 4. User authenticates (or SSO)                       │
-│ 5. Keycloak issues access token with SMART scopes    │
-│ 6. App uses token to access FHIR resources           │
-└──────────────────────────────────────────────────────┘
-
-┌──────────────────────────────────────────────────────┐
-│            Standalone Launch Flow                     │
-│                                                       │
-│ 1. User opens app directly (e.g., mobile app)        │
-│ 2. App redirects to Keycloak for authentication      │
-│ 3. User authenticates with credentials + MFA         │
-│ 4. App requests SMART scopes                         │
-│ 5. If patient context needed → patient picker        │
-│ 6. Keycloak issues access token                      │
-│ 7. App accesses FHIR resources                       │
-└──────────────────────────────────────────────────────┘
-
-┌──────────────────────────────────────────────────────┐
-│       Backend Services Authorization                  │
-│                                                       │
-│ 1. Service authenticates with signed JWT assertion   │
-│ 2. Keycloak validates JWT and issues access token    │
-│ 3. Service accesses FHIR resources                   │
-│ → No user interaction required                       │
-│ → Used for: data sync, analytics, reporting          │
-└──────────────────────────────────────────────────────┘
-```
+**EHR Launch Flow:**
+
+1. User clicks "Launch App" in EHR
+2. EHR sends launch request with context (patient ID, encounter ID)
+3. App redirects to Authorization Server (Keycloak)
+4. User authenticates (or SSO)
+5. Keycloak issues access token with SMART scopes
+6. App uses token to access FHIR resources
+
+**Standalone Launch Flow:**
+
+1. User opens app directly (e.g., mobile app)
+2. App redirects to Keycloak for authentication
+3. User authenticates with credentials + MFA
+4. App requests SMART scopes
+5. If patient context needed → patient picker
+6. Keycloak issues access token
+7. App accesses FHIR resources
+
+**Backend Services Authorization:**
+
+1. Service authenticates with signed JWT assertion
+2. Keycloak validates JWT and issues access token
+3. Service accesses FHIR resources
+→ No user interaction required. Used for: data sync, analytics, reporting.
 
 ## 2. SMART Scopes
 

package/content/series/architecture/xay-dung-he-thong-y-te-microservices/chapters/02-phan-2-iam-keycloak/lessons/04-bai-8-mfa-passkeys-emergency-access.md

@@ -23,7 +23,6 @@ course:
 
 ![Ma trận MFA cho nhân viên y tế — Passkeys, TOTP, Emergency Access](/storage/uploads/2026/04/healthcare-mfa-decision-matrix.png)
 
-
 ### 1.1. Thách thức MFA trong Bệnh viện
 
 Bệnh viện có môi trường vận hành đặc biệt so với doanh nghiệp thông thường:
@@ -38,28 +37,13 @@ Bệnh viện có môi trường vận hành đặc biệt so với doanh nghi
 
 ### 1.2. MFA Factor Matrix
 
-```
-┌──────────────────────────────────────────────────────────┐
-│               Healthcare MFA Decision Matrix              │
-├──────────────┬───────────┬────────────┬──────────────────┤
-│ User Type    │ Primary   │ Secondary  │ Fallback          │
-├──────────────┼───────────┼────────────┼──────────────────┤
-│ Doctor       │ Passkey/  │ TOTP App   │ Recovery codes    │
-│              │ WebAuthn  │            │                    │
-├──────────────┼───────────┼────────────┼──────────────────┤
-│ Nurse        │ Proximity │ PIN (6     │ TOTP App          │
-│              │ Badge     │ digits)    │                    │
-├──────────────┼───────────┼────────────┼──────────────────┤
-│ Lab Tech     │ TOTP App  │ Security   │ Recovery codes    │
-│              │           │ Key        │                    │
-├──────────────┼───────────┼────────────┼──────────────────┤
-│ Admin        │ Security  │ TOTP App   │ Admin recovery    │
-│              │ Key       │            │ procedure          │
-├──────────────┼───────────┼────────────┼──────────────────┤
-│ Patient      │ SMS OTP   │ Email OTP  │ Support call       │
-│ Portal       │           │            │                    │
-└──────────────┴───────────┴────────────┴──────────────────┘
-```
+| User Type | Primary | Secondary | Fallback |
+|-----------|---------|-----------|----------|
+| **Doctor** | Passkey / WebAuthn | TOTP App | Recovery codes |
+| **Nurse** | Proximity Badge | PIN (6 digits) | TOTP App |
+| **Lab Tech** | TOTP App | Security Key | Recovery codes |
+| **Admin** | Security Key | TOTP App | Admin recovery procedure |
+| **Patient Portal** | SMS OTP | Email OTP | Support call |
 
 ## 2. Keycloak Authentication Flow cho Y Tế
 

package/content/series/architecture/xay-dung-he-thong-y-te-microservices/chapters/03-phan-3-data-layer-postgresql/lessons/01-bai-9-postgresql-security-hardening.md

@@ -26,30 +26,17 @@ PostgreSQL là lựa chọn phổ biến cho hệ thống y tế nhờ tính lin
 
 ### 1.1. Các lớp bảo mật PostgreSQL
 
-```
-┌─────────────────────────────────────────────────────┐
-│                  Application Layer                   │
-│    Quarkus / Spring Boot + Connection Pool           │
-├─────────────────────────────────────────────────────┤
-│                  Network Layer                       │
-│    Firewall Rules + VPN/Private Network              │
-├─────────────────────────────────────────────────────┤
-│              Authentication Layer                    │
-│    pg_hba.conf + SSL/TLS + Client Certificates       │
-├─────────────────────────────────────────────────────┤
-│              Authorization Layer                     │
-│    Roles + Privileges + Row-Level Security           │
-├─────────────────────────────────────────────────────┤
-│                Encryption Layer                      │
-│    TDE + Column Encryption + Backup Encryption       │
-├─────────────────────────────────────────────────────┤
-│                  Audit Layer                         │
-│    pgAudit + Custom Triggers + Log Shipping          │
-├─────────────────────────────────────────────────────┤
-│              Operating System Layer                  │
-│    File Permissions + SELinux/AppArmor               │
-└─────────────────────────────────────────────────────┘
-```
+![7 lớp bảo mật PostgreSQL — từ Application đến OS Layer](/storage/uploads/2026/04/healthcare-postgresql-security-layers.png)
+
+| Layer | Tên | Thành phần |
+|-------|-----|------------|
+| 7 | Application | Quarkus / Spring Boot + Connection Pool |
+| 6 | Network | Firewall Rules + VPN/Private Network |
+| 5 | Authentication | pg_hba.conf + SSL/TLS + Client Certificates |
+| 4 | Authorization | Roles + Privileges + Row-Level Security |
+| 3 | Encryption | TDE + Column Encryption + Backup Encryption |
+| 2 | Audit | pgAudit + Custom Triggers + Log Shipping |
+| 1 | Operating System | File Permissions + SELinux/AppArmor |
 
 ### 1.2. Checklist bảo mật cần hoàn thành
 
@@ -145,7 +132,8 @@ hostssl all             all               0.0.0.0/0            reject
 sudo -u postgres psql
 ```
 
-**Rule 4 - `hostssl` + `scram-sha-256`**: 
+**Rule 4 - `hostssl` + `scram-sha-256`**:
+
 - `hostssl` = bắt buộc SSL/TLS
 - `scram-sha-256` = password hashing mạnh nhất PostgreSQL hỗ trợ
 
@@ -273,28 +261,13 @@ WHERE usename IS NOT NULL;
 
 ### 4.1. Nguyên tắc Least Privilege cho Healthcare
 
-```
-┌──────────────────────────────────────────────────────┐
-│              PostgreSQL Role Hierarchy                │
-│                                                      │
-│  postgres (superuser) ← CHỈ dùng cho maintenance    │
-│      │                                               │
-│      ├── dba_admin (CREATEDB, CREATEROLE)            │
-│      │       └── Quản lý schema, backup, monitoring  │
-│      │                                               │
-│      ├── app_roles (LOGIN, limited privileges)       │
-│      │       ├── app_patient_svc                     │
-│      │       ├── app_lab_svc                         │
-│      │       ├── app_pharmacy_svc                    │
-│      │       └── app_gateway_svc                     │
-│      │                                               │
-│      ├── readonly_role (SELECT only)                 │
-│      │       ├── readonly_analytics                  │
-│      │       └── readonly_reporting                  │
-│      │                                               │
-│      └── monitoring_user (pg_monitor)                │
-└──────────────────────────────────────────────────────┘
-```
+![PostgreSQL Role Hierarchy cho hệ thống y tế](/storage/uploads/2026/04/healthcare-postgresql-role-hierarchy.png)
+
+- **postgres** (superuser) ← CHỈ dùng cho maintenance
+  - **dba_admin** (CREATEDB, CREATEROLE) — Quản lý schema, backup, monitoring
+  - **app_roles** (LOGIN, limited privileges) — app_patient_svc, app_lab_svc, app_pharmacy_svc, app_gateway_svc
+  - **readonly_role** (SELECT only) — readonly_analytics, readonly_reporting
+  - **monitoring_user** (pg_monitor)
 
 ### 4.2. Tạo Role Hierarchy
 
@@ -570,33 +543,13 @@ WHERE rolcanlogin = true
 ### 6.1. Tại sao cần PgBouncer
 
 Trong hệ thống microservices, mỗi service instance tạo connection pool riêng. PgBouncer giúp:
+
 - Giảm tổng số connections tới PostgreSQL
 - Thêm một lớp authentication
 - Rate limiting
 - Connection routing
 
-```
-┌─────────────────────────────────────────────────────┐
-│  Microservices (mỗi cái 20 connections)             │
-│  ┌──────────┐ ┌──────────┐ ┌──────────┐            │
-│  │ Patient  │ │ Lab      │ │ Pharmacy │            │
-│  │ Service  │ │ Service  │ │ Service  │            │
-│  │ x3 pods  │ │ x2 pods  │ │ x2 pods  │            │
-│  └────┬─────┘ └────┬─────┘ └────┬─────┘            │
-│       │ 60 conn     │ 40 conn    │ 40 conn          │
-│       └─────────────┼────────────┘                  │
-│                     │ 140 total                     │
-│              ┌──────┴───────┐                       │
-│              │  PgBouncer   │                       │
-│              │  Pool: 50    │ ← Giảm từ 140 → 50   │
-│              └──────┬───────┘                       │
-│                     │ 50 conn                       │
-│              ┌──────┴───────┐                       │
-│              │  PostgreSQL  │                       │
-│              │  max: 200    │                       │
-│              └──────────────┘                       │
-└─────────────────────────────────────────────────────┘
-```
+![PgBouncer connection pooling — giảm 140 connections xuống 50](/storage/uploads/2026/04/healthcare-pgbouncer-connection-pooling.png)
 
 ### 6.2. PgBouncer Configuration
 
@@ -1011,6 +964,7 @@ Trong bài học này, chúng ta đã triển khai **PostgreSQL Security Hardeni
 8. **OS-Level** - File permissions và systemd hardening
 
 Các nguyên tắc cốt lõi:
+
 - **Defense in Depth**: Nhiều lớp bảo mật chồng chéo
 - **Least Privilege**: Mỗi role chỉ có quyền tối thiểu cần thiết
 - **Encrypt Everything**: SSL/TLS cho mọi connection