@xdev-asia/xdev-knowledge-mcp 1.0.37 → 1.0.38
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/content/series/architecture/xay-dung-he-thong-y-te-microservices/chapters/01-phan-1-kien-truc-nen-tang/lessons/01-bai-1-tong-quan-he-thong-y-te-yeu-cau-bao-mat.md +22 -62
- package/content/series/architecture/xay-dung-he-thong-y-te-microservices/chapters/01-phan-1-kien-truc-nen-tang/lessons/02-bai-2-thiet-ke-kien-truc-microservices-y-te.md +33 -143
- package/content/series/architecture/xay-dung-he-thong-y-te-microservices/chapters/01-phan-1-kien-truc-nen-tang/lessons/03-bai-3-phan-loai-du-lieu-y-te-danh-gia-rui-ro.md +25 -145
- package/package.json +1 -1
|
@@ -23,7 +23,6 @@ course:
|
|
|
23
23
|
|
|
24
24
|
|
|
25
25
|
|
|
26
|
-
|
|
27
26
|
Dữ liệu y tế là một trong những loại dữ liệu nhạy cảm nhất. Một bản ghi y tế (medical record) chứa thông tin cá nhân, lịch sử bệnh án, kết quả xét nghiệm, đơn thuốc, và thông tin bảo hiểm — tất cả đều có giá trị cao trên thị trường đen.
|
|
28
27
|
|
|
29
28
|
### Thống kê đáng lo ngại
|
|
@@ -129,29 +128,13 @@ Security Rule đặt ra yêu cầu bảo mật cho ePHI, chia thành 3 loại sa
|
|
|
129
128
|
|
|
130
129
|
#### Technical Safeguards (focus chính của series này)
|
|
131
130
|
|
|
132
|
-
|
|
133
|
-
|
|
134
|
-
|
|
135
|
-
|
|
136
|
-
|
|
137
|
-
|
|
138
|
-
|
|
139
|
-
│ │ • Encryption & Decryption (Addressable) │
|
|
140
|
-
├─────────────────┼───────────────────────────────────────────┤
|
|
141
|
-
│ Audit Controls │ • Hardware, software, procedural │
|
|
142
|
-
│ │ mechanisms to record and examine │
|
|
143
|
-
│ │ access to ePHI (Required) │
|
|
144
|
-
├─────────────────┼───────────────────────────────────────────┤
|
|
145
|
-
│ Integrity │ • Mechanism to authenticate ePHI │
|
|
146
|
-
│ │ (Addressable) │
|
|
147
|
-
├─────────────────┼───────────────────────────────────────────┤
|
|
148
|
-
│ Authentication │ • Person or Entity Authentication │
|
|
149
|
-
│ │ (Required) │
|
|
150
|
-
├─────────────────┼───────────────────────────────────────────┤
|
|
151
|
-
│ Transmission │ • Integrity Controls (Addressable) │
|
|
152
|
-
│ Security │ • Encryption (Addressable) │
|
|
153
|
-
└─────────────────┴───────────────────────────────────────────┘
|
|
154
|
-
```
|
|
131
|
+
| Danh mục | Controls |
|
|
132
|
+
|----------|----------|
|
|
133
|
+
| **Access Control** | Unique User Identification (Required), Emergency Access Procedure (Required), Automatic Logoff (Addressable), Encryption & Decryption (Addressable) |
|
|
134
|
+
| **Audit Controls** | Hardware, software, procedural mechanisms to record and examine access to ePHI (Required) |
|
|
135
|
+
| **Integrity** | Mechanism to authenticate ePHI (Addressable) |
|
|
136
|
+
| **Authentication** | Person or Entity Authentication (Required) |
|
|
137
|
+
| **Transmission Security** | Integrity Controls (Addressable), Encryption (Addressable) |
|
|
155
138
|
|
|
156
139
|
> **Lưu ý**: "Required" = bắt buộc triển khai. "Addressable" = phải đánh giá và triển khai nếu hợp lý, hoặc document lý do không triển khai.
|
|
157
140
|
|
|
@@ -174,23 +157,14 @@ Khi xảy ra data breach liên quan đến PHI:
|
|
|
174
157
|
|
|
175
158
|
FHIR định nghĩa các security components:
|
|
176
159
|
|
|
177
|
-
|
|
178
|
-
|
|
179
|
-
|
|
180
|
-
|
|
181
|
-
|
|
182
|
-
|
|
183
|
-
|
|
184
|
-
|
|
185
|
-
│ Authorization (Scopes, Consent) │
|
|
186
|
-
├──────────────────────────────────────────┤
|
|
187
|
-
│ Audit (AuditEvent resource) │
|
|
188
|
-
├──────────────────────────────────────────┤
|
|
189
|
-
│ Digital Signatures (Provenance) │
|
|
190
|
-
├──────────────────────────────────────────┤
|
|
191
|
-
│ Consent Management (Consent resource) │
|
|
192
|
-
└──────────────────────────────────────────┘
|
|
193
|
-
```
|
|
160
|
+
|
|
161
|
+
|
|
162
|
+
- **Communication Security**: HTTPS/TLS
|
|
163
|
+
- **Authentication**: OAuth2, SMART on FHIR
|
|
164
|
+
- **Authorization**: Scopes, Consent
|
|
165
|
+
- **Audit**: AuditEvent resource
|
|
166
|
+
- **Digital Signatures**: Provenance
|
|
167
|
+
- **Consent Management**: Consent resource
|
|
194
168
|
|
|
195
169
|
### 4.3. SMART on FHIR
|
|
196
170
|
|
|
@@ -240,27 +214,13 @@ Quy định về hồ sơ bệnh án điện tử:
|
|
|
240
214
|
|
|
241
215
|
### 6.1. NIST Cybersecurity Framework
|
|
242
216
|
|
|
243
|
-
|
|
244
|
-
|
|
245
|
-
|
|
246
|
-
|
|
247
|
-
|
|
248
|
-
|
|
249
|
-
|
|
250
|
-
└────┬─────┘
|
|
251
|
-
↓
|
|
252
|
-
┌──────────┐
|
|
253
|
-
│ DETECT │ → Anomalies, Monitoring, Detection Processes
|
|
254
|
-
└────┬─────┘
|
|
255
|
-
↓
|
|
256
|
-
┌──────────┐
|
|
257
|
-
│ RESPOND │ → Response Planning, Communications, Mitigation
|
|
258
|
-
└────┬─────┘
|
|
259
|
-
↓
|
|
260
|
-
┌──────────┐
|
|
261
|
-
│ RECOVER │ → Recovery Planning, Improvements, Communications
|
|
262
|
-
└──────────┘
|
|
263
|
-
```
|
|
217
|
+
|
|
218
|
+
|
|
219
|
+
- **IDENTIFY**: Asset Management, Risk Assessment
|
|
220
|
+
- **PROTECT**: Access Control, Data Security, Training
|
|
221
|
+
- **DETECT**: Anomalies, Monitoring, Detection Processes
|
|
222
|
+
- **RESPOND**: Response Planning, Communications, Mitigation
|
|
223
|
+
- **RECOVER**: Recovery Planning, Improvements, Communications
|
|
264
224
|
|
|
265
225
|
### 6.2. ISO 27799 - Health Informatics Security
|
|
266
226
|
|
|
@@ -40,113 +40,37 @@ Microservices giải quyết bằng cách:
|
|
|
40
40
|
|
|
41
41
|
### 1.2. Healthcare Domain Services
|
|
42
42
|
|
|
43
|
-
|
|
44
|
-
|
|
45
|
-
|
|
46
|
-
|
|
47
|
-
|
|
48
|
-
|
|
49
|
-
|
|
50
|
-
|
|
51
|
-
|
|
52
|
-
|
|
53
|
-
|
|
54
|
-
|
|
55
|
-
|
|
56
|
-
|
|
57
|
-
┌───────────────┼───────────────┐
|
|
58
|
-
│ │ │
|
|
59
|
-
┌─────┴─────┐ ┌─────┴─────┐ ┌──────┴──────┐
|
|
60
|
-
│ Scheduling │ │ Imaging │ │ Notification│
|
|
61
|
-
│ Service │ │ Service │ │ Service │
|
|
62
|
-
│ │ │ (RIS/ │ │ │
|
|
63
|
-
│ • Appoint. │ │ PACS) │ │ • SMS/Email │
|
|
64
|
-
│ • Calendar │ │ • Studies │ │ • Push │
|
|
65
|
-
│ • Waitlist │ │ • Reports │ │ • Alerts │
|
|
66
|
-
└────────────┘ └───────────┘ └─────────────┘
|
|
67
|
-
```
|
|
43
|
+
|
|
44
|
+
|
|
45
|
+
**Core Services:**
|
|
46
|
+
|
|
47
|
+
| Service | Chức năng chính |
|
|
48
|
+
|---------|----------------|
|
|
49
|
+
| **Patient Service** | Patient Registry, Demographics |
|
|
50
|
+
| **Clinical Service (EMR)** | Encounters, Diagnosis, Notes, Vitals |
|
|
51
|
+
| **Lab Service (LIS)** | Orders, Results, Specimens, Reports |
|
|
52
|
+
| **Pharmacy Service** | Prescriptions, Dispensing, Drug DB |
|
|
53
|
+
| **Billing Service** | Invoices, Insurance, Claims, Payments |
|
|
54
|
+
| **Scheduling Service** | Appointments, Calendar, Waitlist |
|
|
55
|
+
| **Imaging Service (RIS/PACS)** | Studies, Reports |
|
|
56
|
+
| **Notification Service** | SMS/Email, Push, Alerts |
|
|
68
57
|
|
|
69
58
|
## 2. Reference Architecture: Secure Healthcare Platform
|
|
70
59
|
|
|
71
60
|
### 2.1. High-Level Architecture
|
|
72
61
|
|
|
73
|
-
|
|
74
|
-
┌─────────────────────────┐
|
|
75
|
-
│ Internet/WAN │
|
|
76
|
-
└───────────┬──────────────┘
|
|
77
|
-
│
|
|
78
|
-
┌───────────▼──────────────┐
|
|
79
|
-
│ WAF/CDN │
|
|
80
|
-
│ (Cloudflare/AWS WAF) │
|
|
81
|
-
└───────────┬──────────────┘
|
|
82
|
-
│
|
|
83
|
-
┌───────────▼──────────────┐
|
|
84
|
-
│ DMZ Network │
|
|
85
|
-
│ ┌─────────────────────┐ │
|
|
86
|
-
│ │ API Gateway │ │
|
|
87
|
-
│ │ (Kong / APISIX) │ │
|
|
88
|
-
│ └─────────┬───────────┘ │
|
|
89
|
-
└────────────┼──────────────┘
|
|
90
|
-
│
|
|
91
|
-
┌────────────────────────┼────────────────────────┐
|
|
92
|
-
│ Internal Network │
|
|
93
|
-
│ │
|
|
94
|
-
│ ┌──────────────┐ ┌──────────────┐ │
|
|
95
|
-
│ │ Keycloak │ │ Service │ │
|
|
96
|
-
│ │ Cluster │ │ Mesh │ │
|
|
97
|
-
│ │ (IAM/SSO) │ │ (Istio) │ │
|
|
98
|
-
│ └──────┬───────┘ └──────┬───────┘ │
|
|
99
|
-
│ │ │ │
|
|
100
|
-
│ ┌──────▼──────────────────▼───────┐ │
|
|
101
|
-
│ │ Quarkus Microservices │ │
|
|
102
|
-
│ │ ┌─────┐ ┌─────┐ ┌─────┐ │ │
|
|
103
|
-
│ │ │Pati.│ │Clin.│ │Lab │ ... │ │
|
|
104
|
-
│ │ └──┬──┘ └──┬──┘ └──┬──┘ │ │
|
|
105
|
-
│ └─────┼───────┼───────┼───────────┘ │
|
|
106
|
-
│ │ │ │ │
|
|
107
|
-
│ ┌─────▼───────▼───────▼───────────┐ │
|
|
108
|
-
│ │ Data Layer │ │
|
|
109
|
-
│ │ ┌──────┐ ┌────┐ ┌─────┐ │ │
|
|
110
|
-
│ │ │Postgr│ │Kafka│ │Redis │ │ │
|
|
111
|
-
│ │ │ SQL │ │ │ │Cache │ │ │
|
|
112
|
-
│ │ └──────┘ └────┘ └─────┘ │ │
|
|
113
|
-
│ └─────────────────────────────────┘ │
|
|
114
|
-
│ │
|
|
115
|
-
│ ┌─────────────────────────────────┐ │
|
|
116
|
-
│ │ Observability Stack │ │
|
|
117
|
-
│ │ ┌─────┐ ┌──────┐ ┌──────┐ │ │
|
|
118
|
-
│ │ │ELK │ │Prome.│ │Jaeger│ │ │
|
|
119
|
-
│ │ │Stack│ │+Graf.│ │/Tempo│ │ │
|
|
120
|
-
│ │ └─────┘ └──────┘ └──────┘ │ │
|
|
121
|
-
│ └─────────────────────────────────┘ │
|
|
122
|
-
└──────────────────────────────────────────────────┘
|
|
123
|
-
```
|
|
62
|
+
|
|
124
63
|
|
|
125
64
|
### 2.2. Network Segmentation (Defense-in-Depth)
|
|
126
65
|
|
|
127
|
-
|
|
128
|
-
|
|
129
|
-
|
|
130
|
-
|
|
131
|
-
|
|
132
|
-
|
|
133
|
-
Zone
|
|
134
|
-
|
|
135
|
-
├── Keycloak
|
|
136
|
-
└── Message Queue (Kafka)
|
|
137
|
-
|
|
138
|
-
Zone 3: Data Zone (Most restricted)
|
|
139
|
-
├── PostgreSQL Clusters
|
|
140
|
-
├── Redis Cache
|
|
141
|
-
├── Backup Storage
|
|
142
|
-
└── Key Management (Vault)
|
|
143
|
-
|
|
144
|
-
Zone 4: Management Zone
|
|
145
|
-
├── Monitoring (Prometheus, Grafana)
|
|
146
|
-
├── Logging (ELK Stack)
|
|
147
|
-
├── CI/CD Pipeline
|
|
148
|
-
└── Admin Access
|
|
149
|
-
```
|
|
66
|
+
|
|
67
|
+
|
|
68
|
+
| Zone | Thành phần |
|
|
69
|
+
|------|------------|
|
|
70
|
+
| **Zone 1: DMZ** | API Gateway, Static content / CDN origin, Reverse Proxy |
|
|
71
|
+
| **Zone 2: Application** | Quarkus Microservices, Keycloak, Message Queue (Kafka) |
|
|
72
|
+
| **Zone 3: Data** (Most restricted) | PostgreSQL Clusters, Redis Cache, Backup Storage, Key Management (Vault) |
|
|
73
|
+
| **Zone 4: Management** | Monitoring (Prometheus, Grafana), Logging (ELK Stack), CI/CD Pipeline, Admin Access |
|
|
150
74
|
|
|
151
75
|
**Firewall Rules giữa các zones:**
|
|
152
76
|
|
|
@@ -294,53 +218,19 @@ public class PatientResource {
|
|
|
294
218
|
|
|
295
219
|
### 4.1. Data Isolation Strategy
|
|
296
220
|
|
|
297
|
-
|
|
298
|
-
|
|
299
|
-
|
|
300
|
-
|
|
301
|
-
|
|
302
|
-
|
|
303
|
-
|
|
304
|
-
|
|
305
|
-
|
|
306
|
-
├── clinical_notes (encrypted)
|
|
307
|
-
└── vital_signs
|
|
308
|
-
|
|
309
|
-
Lab Service ──→ lab_db (PostgreSQL)
|
|
310
|
-
├── lab_orders
|
|
311
|
-
├── lab_results (encrypted)
|
|
312
|
-
├── specimens
|
|
313
|
-
└── reference_ranges
|
|
314
|
-
|
|
315
|
-
Pharmacy Service ──→ pharmacy_db (PostgreSQL)
|
|
316
|
-
├── prescriptions
|
|
317
|
-
├── dispensing_records
|
|
318
|
-
└── drug_interactions
|
|
319
|
-
|
|
320
|
-
Audit Service ──→ audit_db (PostgreSQL - append-only)
|
|
321
|
-
├── audit_events (immutable)
|
|
322
|
-
├── access_logs
|
|
323
|
-
└── security_incidents
|
|
324
|
-
```
|
|
221
|
+
|
|
222
|
+
|
|
223
|
+
| Service | Database | Tables |
|
|
224
|
+
|---------|----------|--------|
|
|
225
|
+
| **Patient Service** | patient_db | patients (demographics, contacts), patient_consents, patient_identifiers |
|
|
226
|
+
| **Clinical Service** | clinical_db | encounters, diagnoses, clinical_notes (encrypted), vital_signs |
|
|
227
|
+
| **Lab Service** | lab_db | lab_orders, lab_results (encrypted), specimens, reference_ranges |
|
|
228
|
+
| **Pharmacy Service** | pharmacy_db | prescriptions, dispensing_records, drug_interactions |
|
|
229
|
+
| **Audit Service** | audit_db (append-only) | audit_events (immutable), access_logs, security_incidents |
|
|
325
230
|
|
|
326
231
|
### 4.2. Shared Data via Events (Event Sourcing)
|
|
327
232
|
|
|
328
|
-
|
|
329
|
-
┌──────────┐ ┌─────────┐ ┌──────────┐
|
|
330
|
-
│ Patient │────▶│ Kafka │────▶│ Clinical │
|
|
331
|
-
│ Service │ │ Topics │ │ Service │
|
|
332
|
-
└──────────┘ │ │ └──────────┘
|
|
333
|
-
│ patient.│
|
|
334
|
-
│ created │────▶┌──────────┐
|
|
335
|
-
│ patient.│ │ Lab │
|
|
336
|
-
│ updated │ │ Service │
|
|
337
|
-
│ patient.│ └──────────┘
|
|
338
|
-
│ consent.│
|
|
339
|
-
│ changed │────▶┌──────────┐
|
|
340
|
-
└─────────┘ │ Pharmacy │
|
|
341
|
-
│ Service │
|
|
342
|
-
└──────────┘
|
|
343
|
-
```
|
|
233
|
+
|
|
344
234
|
|
|
345
235
|
> **Quan trọng**: Kafka messages chứa PHI phải được mã hóa. Sử dụng Kafka encryption at-rest và application-level encryption cho sensitive fields.
|
|
346
236
|
|
|
@@ -22,7 +22,6 @@ course:
|
|
|
22
22
|
|
|
23
23
|
|
|
24
24
|
|
|
25
|
-
|
|
26
25
|
### 1.1. Tại sao cần phân loại dữ liệu?
|
|
27
26
|
|
|
28
27
|
Không phải tất cả dữ liệu đều cần cùng mức độ bảo vệ. Phân loại dữ liệu giúp:
|
|
@@ -34,46 +33,14 @@ Không phải tất cả dữ liệu đều cần cùng mức độ bảo vệ.
|
|
|
34
33
|
|
|
35
34
|
### 1.2. Healthcare Data Classification Levels
|
|
36
35
|
|
|
37
|
-
|
|
38
|
-
|
|
39
|
-
|
|
40
|
-
|
|
41
|
-
|
|
42
|
-
|
|
43
|
-
|
|
44
|
-
|
|
45
|
-
│ → Access: Named individuals only │
|
|
46
|
-
│ → Audit: Full logging, real-time alerts │
|
|
47
|
-
├─────────────────────────────────────────────────────────┤
|
|
48
|
-
│ Level 3: CONFIDENTIAL (Bảo mật) │
|
|
49
|
-
│ ├── Hồ sơ bệnh án (EMR) │
|
|
50
|
-
│ ├── Kết quả xét nghiệm │
|
|
51
|
-
│ ├── Đơn thuốc │
|
|
52
|
-
│ ├── Chẩn đoán hình ảnh │
|
|
53
|
-
│ └── Thông tin bảo hiểm y tế │
|
|
54
|
-
│ → Encryption: Required (AES-256) │
|
|
55
|
-
│ → Access: Role-based (treating clinicians) │
|
|
56
|
-
│ → Audit: Full logging │
|
|
57
|
-
├─────────────────────────────────────────────────────────┤
|
|
58
|
-
│ Level 2: INTERNAL (Nội bộ) │
|
|
59
|
-
│ ├── Thông tin lịch hẹn │
|
|
60
|
-
│ ├── Dữ liệu thống kê (ẩn danh) │
|
|
61
|
-
│ ├── Thông tin nhân viên y tế │
|
|
62
|
-
│ └── Cấu hình hệ thống │
|
|
63
|
-
│ → Encryption: Recommended │
|
|
64
|
-
│ → Access: Department-based │
|
|
65
|
-
│ → Audit: Standard logging │
|
|
66
|
-
├─────────────────────────────────────────────────────────┤
|
|
67
|
-
│ Level 1: PUBLIC (Công khai) │
|
|
68
|
-
│ ├── Danh mục dịch vụ y tế │
|
|
69
|
-
│ ├── Giờ làm việc phòng khám │
|
|
70
|
-
│ ├── Thông tin liên hệ bệnh viện │
|
|
71
|
-
│ └── Hướng dẫn sức khỏe chung │
|
|
72
|
-
│ → Encryption: Not required │
|
|
73
|
-
│ → Access: Public │
|
|
74
|
-
│ → Audit: Basic logging │
|
|
75
|
-
└─────────────────────────────────────────────────────────┘
|
|
76
|
-
```
|
|
36
|
+
|
|
37
|
+
|
|
38
|
+
| Level | Tên | Ví dụ | Encryption | Access | Audit |
|
|
39
|
+
|-------|-----|--------|------------|--------|-------|
|
|
40
|
+
| **4 - RESTRICTED** | Hạn chế tối đa | HIV/AIDS, sức khỏe tâm thần, di truyền, điều trị nghiện, sức khỏe sinh sản | Required (AES-256) | Named individuals only | Full logging, real-time alerts |
|
|
41
|
+
| **3 - CONFIDENTIAL** | Bảo mật | Hồ sơ bệnh án, xét nghiệm, đơn thuốc, chẩn đoán hình ảnh, BHYT | Required (AES-256) | Role-based (treating clinicians) | Full logging |
|
|
42
|
+
| **2 - INTERNAL** | Nội bộ | Lịch hẹn, thống kê (ẩn danh), nhân viên y tế, cấu hình | Recommended | Department-based | Standard logging |
|
|
43
|
+
| **1 - PUBLIC** | Công khai | Danh mục dịch vụ, giờ làm việc, liên hệ bệnh viện, hướng dẫn SK | Not required | Public | Basic logging |
|
|
77
44
|
|
|
78
45
|
### 1.3. Data Classification trong PostgreSQL Schema
|
|
79
46
|
|
|
@@ -115,45 +82,7 @@ VALUES
|
|
|
115
82
|
|
|
116
83
|
### 2.1. PHI Data Flow trong Microservices
|
|
117
84
|
|
|
118
|
-
|
|
119
|
-
┌──────────┐ HTTPS/TLS ┌──────────┐ OIDC ┌──────────┐
|
|
120
|
-
│ Patient │ ──────────────▶ │ API │ ──────────▶ │ Keycloak │
|
|
121
|
-
│ Portal │ │ Gateway │ │ │
|
|
122
|
-
└──────────┘ └────┬─────┘ └──────────┘
|
|
123
|
-
│
|
|
124
|
-
JWT Token + PHI Request
|
|
125
|
-
│
|
|
126
|
-
┌───────────────────┼───────────────────┐
|
|
127
|
-
▼ ▼ ▼
|
|
128
|
-
┌──────────┐ ┌──────────┐ ┌──────────┐
|
|
129
|
-
│ Patient │ │ Clinical │ │ Lab │
|
|
130
|
-
│ Service │ │ Service │ │ Service │
|
|
131
|
-
└────┬─────┘ └────┬─────┘ └────┬─────┘
|
|
132
|
-
│ │ │
|
|
133
|
-
PHI (encrypted) PHI (encrypted) PHI (encrypted)
|
|
134
|
-
│ │ │
|
|
135
|
-
▼ ▼ ▼
|
|
136
|
-
┌──────────┐ ┌──────────┐ ┌──────────┐
|
|
137
|
-
│patient_db│ │clinical │ │ lab_db │
|
|
138
|
-
│(RLS+Enc) │ │_db (RLS) │ │(RLS+Enc) │
|
|
139
|
-
└──────────┘ └──────────┘ └──────────┘
|
|
140
|
-
│ │ │
|
|
141
|
-
└──────────────────┼────────────────────┘
|
|
142
|
-
│
|
|
143
|
-
Audit Events (encrypted)
|
|
144
|
-
│
|
|
145
|
-
▼
|
|
146
|
-
┌──────────────┐
|
|
147
|
-
│ Kafka │
|
|
148
|
-
│ (audit topic)│
|
|
149
|
-
└──────┬───────┘
|
|
150
|
-
│
|
|
151
|
-
▼
|
|
152
|
-
┌──────────────┐
|
|
153
|
-
│ Audit DB │
|
|
154
|
-
│ (append-only)│
|
|
155
|
-
└──────────────┘
|
|
156
|
-
```
|
|
85
|
+
|
|
157
86
|
|
|
158
87
|
### 2.2. Data Flow Documentation Template
|
|
159
88
|
|
|
@@ -170,24 +99,7 @@ VALUES
|
|
|
170
99
|
|
|
171
100
|
### 3.1. Risk Assessment Methodology
|
|
172
101
|
|
|
173
|
-
|
|
174
|
-
Bước 1: Xác định Threats (Mối đe dọa)
|
|
175
|
-
│
|
|
176
|
-
▼
|
|
177
|
-
Bước 2: Xác định Vulnerabilities (Lỗ hổng)
|
|
178
|
-
│
|
|
179
|
-
▼
|
|
180
|
-
Bước 3: Đánh giá Likelihood (Khả năng xảy ra)
|
|
181
|
-
│
|
|
182
|
-
▼
|
|
183
|
-
Bước 4: Đánh giá Impact (Mức độ ảnh hưởng)
|
|
184
|
-
│
|
|
185
|
-
▼
|
|
186
|
-
Bước 5: Tính Risk Level = Likelihood × Impact
|
|
187
|
-
│
|
|
188
|
-
▼
|
|
189
|
-
Bước 6: Xác định Risk Response (Giảm thiểu, chấp nhận, chuyển giao)
|
|
190
|
-
```
|
|
102
|
+
|
|
191
103
|
|
|
192
104
|
### 3.2. Threat Identification cho Healthcare Microservices
|
|
193
105
|
|
|
@@ -239,27 +151,15 @@ public class SecurityVulnerabilityChecklist {
|
|
|
239
151
|
|
|
240
152
|
### 3.4. Risk Matrix
|
|
241
153
|
|
|
242
|
-
|
|
243
|
-
|
|
244
|
-
|
|
245
|
-
|
|
246
|
-
Very High
|
|
247
|
-
|
|
248
|
-
|
|
249
|
-
|
|
250
|
-
|
|
251
|
-
─────────┼────────────┼──────────┼──────────┼──────────┼──────────
|
|
252
|
-
Medium │ │ │ │ │
|
|
253
|
-
(3) │ LOW │ LOW │ MEDIUM │ HIGH │ HIGH
|
|
254
|
-
─────────┼────────────┼──────────┼──────────┼──────────┼──────────
|
|
255
|
-
Low │ │ │ │ │
|
|
256
|
-
(2) │ LOW │ LOW │ LOW │ MEDIUM │ MEDIUM
|
|
257
|
-
─────────┼────────────┼──────────┼──────────┼──────────┼──────────
|
|
258
|
-
Very Low │ │ │ │ │
|
|
259
|
-
(1) │ LOW │ LOW │ LOW │ LOW │ MEDIUM
|
|
260
|
-
─────────┴────────────┴──────────┴──────────┴──────────┴──────────
|
|
261
|
-
Impact → Likelihood ↑
|
|
262
|
-
```
|
|
154
|
+
|
|
155
|
+
|
|
156
|
+
| | Negligible (1) | Low (2) | Medium (3) | High (4) | Critical (5) |
|
|
157
|
+
|-|----------------|---------|------------|----------|-------------|
|
|
158
|
+
| **Very High (5)** | LOW | MEDIUM | HIGH | CRITICAL | CRITICAL |
|
|
159
|
+
| **High (4)** | LOW | MEDIUM | HIGH | HIGH | CRITICAL |
|
|
160
|
+
| **Medium (3)** | LOW | LOW | MEDIUM | HIGH | HIGH |
|
|
161
|
+
| **Low (2)** | LOW | LOW | LOW | MEDIUM | MEDIUM |
|
|
162
|
+
| **Very Low (1)** | LOW | LOW | LOW | LOW | MEDIUM |
|
|
263
163
|
|
|
264
164
|
## 4. Risk Register cho Healthcare Microservices
|
|
265
165
|
|
|
@@ -280,32 +180,12 @@ Very Low │ │ │ │ │
|
|
|
280
180
|
|
|
281
181
|
### 4.2. Risk Treatment Plan
|
|
282
182
|
|
|
283
|
-
|
|
284
|
-
|
|
285
|
-
|
|
286
|
-
|
|
287
|
-
|
|
288
|
-
|
|
289
|
-
│ ├── Reduce likelihood or impact │
|
|
290
|
-
│ └── Example: Add RLS to prevent unauthorized access │
|
|
291
|
-
│ │
|
|
292
|
-
│ TRANSFER (Chuyển giao) │
|
|
293
|
-
│ ├── Insurance (cyber insurance) │
|
|
294
|
-
│ ├── Outsource to specialist provider │
|
|
295
|
-
│ └── Example: Cloud provider handles physical security │
|
|
296
|
-
│ │
|
|
297
|
-
│ ACCEPT (Chấp nhận) ← Only for LOW risks │
|
|
298
|
-
│ ├── Document risk acceptance │
|
|
299
|
-
│ ├── Monitor for changes │
|
|
300
|
-
│ └── Example: Accept risk of public info disclosure │
|
|
301
|
-
│ │
|
|
302
|
-
│ AVOID (Tránh) │
|
|
303
|
-
│ ├── Eliminate the risk source │
|
|
304
|
-
│ ├── Change architecture/process │
|
|
305
|
-
│ └── Example: Don't store SSN if not absolutely needed │
|
|
306
|
-
│ │
|
|
307
|
-
└─────────────────────────────────────────────────────────┘
|
|
308
|
-
```
|
|
183
|
+
|
|
184
|
+
|
|
185
|
+
- **MITIGATE** (Giảm thiểu) ← Preferred cho HIGH risks: Implement controls, giảm likelihood/impact
|
|
186
|
+
- **TRANSFER** (Chuyển giao): Cyber insurance, outsource cho specialist provider
|
|
187
|
+
- **ACCEPT** (Chấp nhận) ← Chỉ cho LOW risks: Document risk acceptance, monitor
|
|
188
|
+
- **AVOID** (Tránh): Loại bỏ nguồn rủi ro, thay đổi architecture
|
|
309
189
|
|
|
310
190
|
## 5. Data Retention Policy
|
|
311
191
|
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@xdev-asia/xdev-knowledge-mcp",
|
|
3
|
-
"version": "1.0.
|
|
3
|
+
"version": "1.0.38",
|
|
4
4
|
"description": "MCP Server - Toàn bộ kiến thức xDev.asia: 57 series, 1200+ lessons, blog, showcase (AI, Architecture, DevSecOps, Programming)",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"main": "dist/index.js",
|