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

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
                                               │

package/content/series/architecture/xay-dung-he-thong-y-te-microservices/chapters/04-phan-4-microservices-quarkus/lessons/04-bai-16-mtls-service-mesh.md

@@ -33,61 +33,26 @@ mTLS và Service Mesh giải quyết tất cả các vấn đề trên.
 
 ### 1.1. Defense-in-Depth cho Inter-Service Communication
 
-```
-┌─────────────────────────────────────────────────────────────┐
-│       Secure Inter-Service Communication Layers              │
-│                                                              │
-│  Layer 1: Network Policies (Kubernetes)                      │
-│    ├── Namespace isolation                                   │
-│    ├── Pod-to-pod firewall rules                             │
-│    └── Egress restrictions                                   │
-│                                                              │
-│  Layer 2: mTLS (Istio Service Mesh)                          │
-│    ├── Automatic certificate provisioning                    │
-│    ├── Certificate rotation (24h default)                    │
-│    └── Mutual authentication (both sides verified)           │
-│                                                              │
-│  Layer 3: Authorization Policies (Istio)                     │
-│    ├── Service-to-service access control                     │
-│    ├── Path-based authorization                              │
-│    └── JWT claim-based policies                              │
-│                                                              │
-│  Layer 4: Application Security (Quarkus)                     │
-│    ├── JWT validation                                        │
-│    ├── RBAC (@RolesAllowed)                                  │
-│    └── Business logic authorization                          │
-│                                                              │
-│  Layer 5: Payload Encryption (JWE)                           │
-│    ├── Field-level encryption                                │
-│    └── End-to-end encryption                                 │
-└─────────────────────────────────────────────────────────────┘
-```
+![5 Security Layers cho Inter-Service Communication — Network → mTLS → AuthZ → JWT → Encryption](/storage/uploads/2026/04/healthcare-service-communication-layers.png)
+
+**5 lớp bảo vệ:**
+
+- **Layer 1**: Network Policies (Kubernetes) — Namespace isolation, pod-to-pod firewall, egress restrictions
+- **Layer 2**: mTLS (Istio) — Auto certificate provisioning, rotation 24h, mutual authentication
+- **Layer 3**: Authorization Policies (Istio) — Service-to-service ACL, path-based, JWT claim-based
+- **Layer 4**: Application Security (Quarkus) — JWT validation, RBAC, business logic authorization
+- **Layer 5**: Payload Encryption (JWE) — Field-level encryption, end-to-end encryption
 
 ### 1.2. mTLS vs One-Way TLS
 
-```
-┌─────────────────────────────────────────────────────────┐
-│  One-Way TLS (Standard HTTPS)                            │
-│                                                          │
-│  Client ──────────────────────────► Server               │
-│         ◄── Server Certificate ──┘                       │
-│                                                          │
-│  • Client verifies server identity                       │
-│  • Server does NOT verify client                         │
-│  • Any client can connect                                │
-│                                                          │
-├─────────────────────────────────────────────────────────┤
-│  Mutual TLS (mTLS)                                       │
-│                                                          │
-│  Client ──── Client Certificate ──► Server               │
-│         ◄── Server Certificate ──┘                       │
-│                                                          │
-│  • Client verifies server identity ✓                     │
-│  • Server verifies client identity ✓                     │
-│  • Both sides authenticated                              │
-│  • Encrypted channel established                         │
-└─────────────────────────────────────────────────────────┘
-```
+![So sánh One-Way TLS vs Mutual TLS (mTLS)](/storage/uploads/2026/04/healthcare-tls-comparison.png)
+
+| | One-Way TLS | Mutual TLS (mTLS) |
+|---|---|---|
+| Client verify server | ✓ | ✓ |
+| Server verify client | ✗ | ✓ |
+| Kết nối | Any client có thể connect | Cả hai đều authenticated |
+| Kênh truyền | Encrypted | Encrypted + verified |
 
 ## 2. mTLS Configuration trong Quarkus
 
@@ -441,42 +406,15 @@ istioctl analyze -n healthcare
 
 ### 4.2. Istio Architecture với Healthcare Services
 
-```
-┌─────────────────────────────────────────────────────────────┐
-│                Kubernetes Cluster                            │
-│                                                              │
-│  ┌────────────────── istio-system ─────────────────────┐     │
-│  │  istiod (control plane)                              │     │
-│  │    ├── Certificate Authority (Citadel)               │     │
-│  │    ├── Configuration (Pilot)                         │     │
-│  │    └── Telemetry (Mixer replacement)                 │     │
-│  └──────────────────────────────────────────────────────┘     │
-│                                                              │
-│  ┌────────────────── healthcare ───────────────────────┐     │
-│  │                                                      │     │
-│  │  ┌──────────────────────────────────────────────┐   │     │
-│  │  │ Pod: patient-service                          │   │     │
-│  │  │ ┌───────────────┐  ┌────────────────────────┐│   │     │
-│  │  │ │ Envoy Proxy   │  │ patient-service        ││   │     │
-│  │  │ │ (sidecar)     │◄►│ (Quarkus container)    ││   │     │
-│  │  │ │               │  │                        ││   │     │
-│  │  │ │ - mTLS        │  │ - Business logic       ││   │     │
-│  │  │ │ - Auth policy │  │ - JWT validation       ││   │     │
-│  │  │ │ - Telemetry   │  │ - RBAC                 ││   │     │
-│  │  │ └───────────────┘  └────────────────────────┘│   │     │
-│  │  └──────────────────────────────────────────────┘   │     │
-│  │                    ^ mTLS v                          │     │
-│  │  ┌──────────────────────────────────────────────┐   │     │
-│  │  │ Pod: lab-service                              │   │     │
-│  │  │ ┌───────────────┐  ┌────────────────────────┐│   │     │
-│  │  │ │ Envoy Proxy   │  │ lab-service            ││   │     │
-│  │  │ │ (sidecar)     │◄►│ (Quarkus container)    ││   │     │
-│  │  │ └───────────────┘  └────────────────────────┘│   │     │
-│  │  └──────────────────────────────────────────────┘   │     │
-│  │                                                      │     │
-│  └──────────────────────────────────────────────────────┘     │
-└─────────────────────────────────────────────────────────────┘
-```
+![Istio Service Mesh Architecture cho Healthcare — istiod + Envoy sidecars](/storage/uploads/2026/04/healthcare-istio-mesh.png)
+
+**Architecture:**
+
+- **istio-system**: istiod control plane (Citadel CA, Pilot config, Telemetry)
+- **healthcare namespace**: Pods với Envoy sidecar proxies
+  - Patient Service + Envoy (mTLS, auth policy, telemetry)
+  - Lab Service + Envoy
+- Tất cả traffic giữa services đi qua Envoy → mã hóa mTLS tự động
 
 ### 4.3. PeerAuthentication - STRICT mTLS
 

package/content/series/architecture/xay-dung-he-thong-y-te-microservices/chapters/05-phan-5-compliance-audit/lessons/01-bai-17-hipaa-technical-safeguards.md

@@ -23,41 +23,33 @@ course:
 
 ![HIPAA Security Rule — Administrative, Physical, Technical Safeguards](/storage/uploads/2026/04/healthcare-hipaa-security-rule.png)
 
-
 HIPAA Security Rule yêu cầu các tổ chức xử lý ePHI (electronic Protected Health Information) phải triển khai **Technical Safeguards** — các biện pháp kỹ thuật bảo vệ dữ liệu y tế điện tử. Đây là phần quan trọng nhất đối với developers và engineers.
 
 ### 1.1. Cấu trúc HIPAA Security Rule
 
-```
-┌─────────────────────────────────────────────────────────────┐
-│              HIPAA Security Rule §164.302-318                │
-│                                                              │
-│  §164.308 Administrative Safeguards                          │
-│    ├── Risk Analysis                                         │
-│    ├── Workforce Security                                    │
-│    ├── Information Access Management                         │
-│    ├── Security Awareness Training                           │
-│    ├── Security Incident Procedures                          │
-│    ├── Contingency Plan                                      │
-│    └── Evaluation                                            │
-│                                                              │
-│  §164.310 Physical Safeguards                                │
-│    ├── Facility Access Controls                              │
-│    ├── Workstation Use & Security                            │
-│    └── Device and Media Controls                             │
-│                                                              │
-│  §164.312 Technical Safeguards  ◄── BÀI NÀY                 │
-│    ├── Access Control (§164.312(a))                           │
-│    ├── Audit Controls (§164.312(b))                          │
-│    ├── Integrity Controls (§164.312(c))                      │
-│    ├── Person/Entity Authentication (§164.312(d))            │
-│    └── Transmission Security (§164.312(e))                   │
-│                                                              │
-│  §164.314 Organizational Requirements                        │
-│    ├── Business Associate Agreements (BAA)                   │
-│    └── Group Health Plan Requirements                        │
-└─────────────────────────────────────────────────────────────┘
-```
+**HIPAA Security Rule §164.302-318:**
+
+- **§164.308 Administrative Safeguards**
+  - Risk Analysis
+  - Workforce Security
+  - Information Access Management
+  - Security Awareness Training
+  - Security Incident Procedures
+  - Contingency Plan
+  - Evaluation
+- **§164.310 Physical Safeguards**
+  - Facility Access Controls
+  - Workstation Use & Security
+  - Device and Media Controls
+- **§164.312 Technical Safeguards** ← **BÀI NÀY**
+  - Access Control (§164.312(a))
+  - Audit Controls (§164.312(b))
+  - Integrity Controls (§164.312(c))
+  - Person/Entity Authentication (§164.312(d))
+  - Transmission Security (§164.312(e))
+- **§164.314 Organizational Requirements**
+  - Business Associate Agreements (BAA)
+  - Group Health Plan Requirements
 
 ### 1.2. Required vs Addressable
 
@@ -1221,36 +1213,33 @@ fi
 
 Khi sử dụng third-party services (cloud providers, SaaS), BAA yêu cầu các đảm bảo kỹ thuật:
 
-```
-┌─────────────────────────────────────────────────────────────┐
-│          BAA Technical Requirements Mapping                  │
-│                                                              │
-│  Cloud Provider (AWS/GCP/Azure)                              │
-│    ├── Encryption at rest: AES-256                           │
-│    ├── Encryption in transit: TLS 1.2+                       │
-│    ├── Access logging: CloudTrail/Cloud Audit Logs           │
-│    ├── Data residency: Specify region                        │
-│    └── Incident notification: ≤ 60 days                      │
-│                                                              │
-│  Database Service (RDS/Cloud SQL)                            │
-│    ├── Encrypted storage volumes                             │
-│    ├── Encrypted backups                                     │
-│    ├── Audit logging enabled                                 │
-│    ├── Network isolation (VPC)                               │
-│    └── IAM authentication                                    │
-│                                                              │
-│  Monitoring Service (Datadog/New Relic)                      │
-│    ├── PHI masking before sending                            │
-│    ├── Data processing agreement                             │
-│    ├── EU/US data residency                                  │
-│    └── Log retention controls                                │
-│                                                              │
-│  Email Service (SendGrid/SES)                                │
-│    ├── TLS enforced                                          │
-│    ├── No PHI in email content                               │
-│    └── Breach notification capability                        │
-└─────────────────────────────────────────────────────────────┘
-```
+**Cloud Provider (AWS/GCP/Azure):**
+
+- Encryption at rest: AES-256
+- Encryption in transit: TLS 1.2+
+- Access logging: CloudTrail/Cloud Audit Logs
+- Data residency: Specify region
+- Incident notification: ≤ 60 days
+
+**Database Service (RDS/Cloud SQL):**
+
+- Encrypted storage volumes + backups
+- Audit logging enabled
+- Network isolation (VPC)
+- IAM authentication
+
+**Monitoring Service (Datadog/New Relic):**
+
+- PHI masking before sending
+- Data processing agreement
+- EU/US data residency
+- Log retention controls
+
+**Email Service (SendGrid/SES):**
+
+- TLS enforced
+- No PHI in email content
+- Breach notification capability
 
 ### 8.2. BAA Compliance Verification
 

package/content/series/architecture/xay-dung-he-thong-y-te-microservices/chapters/05-phan-5-compliance-audit/lessons/02-bai-18-audit-trail-opentelemetry-elk.md

@@ -331,40 +331,17 @@ public class PatientService {
 
 ### 3.1. Correlation ID Architecture
 
-```
-┌─────────────────────────────────────────────────────────────┐
-│        Distributed Tracing - Patient Data Flow               │
-│                                                              │
-│  Client Request                                              │
-│  Headers: X-Request-ID: req-abc-123                          │
-│           traceparent: 00-trace123-span456-01                │
-│    │                                                         │
-│    ▼                                                         │
-│  API Gateway (span-1)                                        │
-│    │  trace_id: trace123                                     │
-│    │  span_id: span-gw-001                                   │
-│    │  attributes: {user_id, request_id, client_ip}           │
-│    │                                                         │
-│    ▼                                                         │
-│  Patient Service (span-2, parent: span-gw-001)               │
-│    │  span_id: span-ps-001                                   │
-│    │  attributes: {patient_id, action, department}           │
-│    │                                                         │
-│    ├──► PostgreSQL Query (span-3, parent: span-ps-001)       │
-│    │    span_id: span-db-001                                 │
-│    │    attributes: {db.statement, db.operation}             │
-│    │                                                         │
-│    ├──► Kafka Publish (span-4, parent: span-ps-001)          │
-│    │    span_id: span-kafka-001                              │
-│    │    attributes: {messaging.destination, event_type}      │
-│    │                                                         │
-│    └──► Lab Service REST Call (span-5, parent: span-ps-001)  │
-│         span_id: span-ls-001                                 │
-│         attributes: {http.method, http.url}                  │
-│                                                              │
-│  Trace ID: trace123 liên kết TẤT CẢ spans trong flow        │
-└─────────────────────────────────────────────────────────────┘
-```
+![Distributed Tracing — Patient Data Flow qua API Gateway → Patient Service → DB/Kafka/Lab Service](/storage/uploads/2026/04/healthcare-distributed-tracing-flow.png)
+
+**Trace Flow:**
+
+- **Client Request** với `X-Request-ID` + `traceparent` headers
+- **API Gateway** (span-1) → trace_id, user_id, client_ip
+- **Patient Service** (span-2) → patient_id, action, department
+  - PostgreSQL Query (span-3) — db.statement, db.operation
+  - Kafka Publish (span-4) — messaging.destination, event_type
+  - Lab Service REST Call (span-5) — http.method, http.url
+- **Trace ID** liên kết TẤT CẢ spans trong flow
 
 ### 3.2. MDC (Mapped Diagnostic Context) Integration