1. 醫療保健資料分類框架
1.1。為什麼需要對資料進行分類？
並非所有資料都需要相同等級的保護。資料分類有助於：
- 優化安全成本：將資源集中在最重要的資料上
- 法律合規性：根據監管要求應用正確的控制
- 減少攻擊面：限制敏感資料的範圍
- 事件回應：發生違規時優先處理
1.2。醫療保健數據分類級別
| 水平 | 名稱 | 範例 | 加密 | 存取 | 稽核 |
|---|---|---|---|---|---|
| 4 - 受限 | 最大限制 | 愛滋病毒/愛滋病、心理健康、遺傳學、成癮治療、生殖健康 | 必要 (AES-256) | 僅指名個人 | 完整記錄、即時警報 |
| 3 - 機密 | 安全 | 醫療記錄、測試、處方、診斷成像、健康保險 | 必需 (AES-256) | 基於角色（治療臨床醫生） | 完整記錄 |
| 2 - 內部 | 內部 | 預約時間表、統計（匿名）、醫護人員、配置 | 推薦 | 部門為本 | 標準記錄 |
| 1 - 公開 | 公共 | 服務清單、工作時間、醫院聯絡方式、健康說明 | 不需要 | 公共 | 基本日誌記錄 |
1.3。 PostgreSQL 模式中的資料分類
-- Data classification metadata table
CREATE TABLE data_classification (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
schema_name VARCHAR(100) NOT NULL,
table_name VARCHAR(100) NOT NULL,
column_name VARCHAR(100) NOT NULL,
classification_level INTEGER NOT NULL CHECK (classification_level BETWEEN 1 AND 4),
classification_label VARCHAR(50) NOT NULL,
contains_phi BOOLEAN DEFAULT false,
encryption_required BOOLEAN DEFAULT false,
masking_rule VARCHAR(100),
retention_days INTEGER,
legal_basis TEXT,
created_at TIMESTAMPTZ DEFAULT NOW(),
updated_at TIMESTAMPTZ DEFAULT NOW()
);
-- Ví dụ classification cho patient table
INSERT INTO data_classification (schema_name, table_name, column_name,
classification_level, classification_label, contains_phi, encryption_required, masking_rule)
VALUES
('public', 'patients', 'id', 2, 'INTERNAL', false, false, NULL),
('public', 'patients', 'full_name', 3, 'CONFIDENTIAL', true, true, 'PARTIAL_MASK'),
('public', 'patients', 'date_of_birth', 3, 'CONFIDENTIAL', true, false, 'YEAR_ONLY'),
('public', 'patients', 'cccd_number', 3, 'CONFIDENTIAL', true, true, 'FULL_MASK'),
('public', 'patients', 'phone', 3, 'CONFIDENTIAL', true, true, 'PARTIAL_MASK'),
('public', 'patients', 'email', 3, 'CONFIDENTIAL', true, true, 'PARTIAL_MASK'),
('public', 'patients', 'address', 3, 'CONFIDENTIAL', true, true, 'CITY_ONLY'),
('public', 'patients', 'blood_type', 2, 'INTERNAL', false, false, NULL),
('public', 'patients', 'hiv_status', 4, 'RESTRICTED', true, true, 'FULL_MASK'),
('public', 'patients', 'insurance_number', 3, 'CONFIDENTIAL', true, true, 'PARTIAL_MASK');
2. 資料流映射
2.1。微服務中的 PHI 資料流
2.2。資料流文檔模板
| ＃|資料元素|來源 |目的地 |交通 |加密 |分類| |---|-------------|--------|------------||------------|------------||----------| | 1 |病人姓名 |門戶|病人服務 | HTTPS/TLS 1.3 |途中 + 休息 | L3 | | 2 |實驗室結果 |實驗室儀器|實驗室服務|基於 TLS 的 HL7v2/MLLP |途中 + 休息 | L3 | | 3 |診斷代碼|臨床服務|計費服務|卡夫卡（SSL）|應用級 | L3 | | 4 |愛滋病毒狀況|臨床服務|臨床資料庫| JDBC/SSL |列加密| L4 | | 5 |審計事件|所有服務 |審計服務|卡夫卡（SSL）|事件加密 | L2 | | 6 |預約 |排程服務|通知服務|卡夫卡（SSL）|在途| L2 |
3. 根據 NIST SP 800-30 進行風險評估
3.1。風險評估方法
3.2。醫療保健微服務的威脅識別
| 威脅類別 | 威脅 | 威脅來源 |
|---|---|---|
| 外部 | SQL 注入病人服務 | 攻擊者 |
| 外部 | 勒索軟體加密資料庫 | 網路犯罪 |
| 外部 | 對API呼叫的中間人攻擊 | 網路攻擊 |
| 外部 | 將憑證填入病患入口網站 | 機器人網路 |
| 內部 | 未經授權的員工存取 PHI | 內幕 |
| 內部 | 資料庫管理員匯出所有病患資料 | 特權使用者 |
| 內部 | 開發人員硬編碼憑證 | 疏忽的員工 |
| 環境 | 硬體故障導致資料庫損壞 | 基礎設施 |
| 環境 | 自然災害造成的資料遺失 | 自然災害 |
| 供應鏈 | Quarkus 依賴項中的漏洞 | 第三方 |
3.3。漏洞評估
// Ví dụ: Checklist kiểm tra vulnerabilities trong Quarkus service
public class SecurityVulnerabilityChecklist {
// V1: SQL Injection - Sử dụng parameterized queries
// ❌ VULNERABLE
String badQuery = "SELECT * FROM patients WHERE name = '" + userInput + "'";
// ✅ SECURE
@NamedQuery(name = "Patient.findByName",
query = "SELECT p FROM Patient p WHERE p.name = :name")
List<Patient> findByName(@Param("name") String name);
// V2: Broken Authentication - Token validation
// ❌ VULNERABLE: Không verify token
String userId = jwt.getClaim("sub"); // Không verify expiration, issuer
// ✅ SECURE: Quarkus OIDC tự động verify
@Authenticated
@RolesAllowed("doctor")
public Response getPatient(UUID id) { ... }
// V3: Sensitive Data Exposure in Logs
// ❌ VULNERABLE
log.info("Patient created: " + patient.toString()); // Logs PHI!
// ✅ SECURE
log.info("Patient created: id={}", patient.getId()); // Only log ID
}
3.4。風險矩陣
| 可以忽略不計 (1) | 低 (2) | 中 (3) | 高 (4) | 關鍵 (5) | |
|---|---|---|---|---|---|
| 非常高 (5) | 低 | 中 | 高 | 關鍵 | 關鍵 |
| 高 (4) | 低 | 中 | 高 | 高 | 關鍵 |
| 中 (3) | 低 | 低 | 中 | 高 | 高 |
| 低 (2) | 低 | 低 | 低 | 中 | 中 |
| 非常低 (1) | 低 | 低 | 低 | 低 | 中 |
4. 醫療保健微服務風險登記冊
4.1。風險登記冊模板
| 身分證 | 風險描述 | 可能性 | 影響 | 風險等級 | 緩解措施 | 業主 | 狀態 |
|---|---|---|---|---|---|---|---|
| R001 | SQL 注入到病患 API | 中 (3) | 關鍵 (5) | 高 | 參數化查詢、輸入驗證、WAF | 開發團隊 | 緩解措施 |
| R002 | 未經授權的內部存取 PHI | 高 (4) | 高 (4) | 高 | RBAC、RLS、審核日誌記錄、DLP | 安全團隊 | 進行中 |
| R003 | 勒索軟體加密 Patient_db | 中 (3) | 關鍵 (5) | 高 | 不可變備份、網路分段、EDR | 營運團隊 | 緩解措施 |
| R004 | Keycloak 令牌被盜 | 中 (3) | 高 (4) | 高 | 短期令牌、mTLS、DPoP | 開發團隊 | 進行中 |
| R005 | 日誌中的 PHI 暴露 | 高 (4) | 高 (4) | 高 | CI/CD 中的日誌清理、PHI 檢測 | 開發團隊 | 開啟 |
| R006 | Kafka 中未加密的 PHI | 中 (3) | 高 (4) | 高 | 應用級加密，Kafka SSL | 開發團隊 | 開啟 |
| R007 | 資料庫備份被盜 | 低 (2) | 關鍵 (5) | 中 | 加密備份、金鑰管理 | 營運團隊 | 緩解措施 |
| R008 | API 金鑰/憑證暴露 | 中 (3) | 高 (4) | 高 | Vault 機密管理，無硬編碼機密 | 所有團隊 | 進行中 |
| R009 | 病患入口網站上的 DDoS | 中 (3) | 中 (3) | 中 | 限速、WAF、CDN | 營運團隊 | 緩解措施 |
| R010 | 第三方依賴CVE | 高 (4) | 中 (3) | 高 | 自動掃描、Dependabot、SBOM | 開發團隊 | 正在進行 |
4.2。風險處理計劃
- 緩解 ← 高風險首選：實施控制，降低可能性/影響
- 轉移（轉移）：網路保險，外包給專業提供者
- ACCEPT（接受）← 僅適用於低風險：記錄風險接受度、監控
- AVOID（避免）：消除風險來源，改變架構
5. 資料保留政策
5.1。越南健康的保留要求
| 資料類型 | 儲存時間 | 法律依據 |
|---|---|---|
| 門診病歷 | 10年 | 46/2018/TT-BYT 通知 |
| 住院病歷 | 20年 | 46/2018/TT-BYT 通知 |
| 死亡病歷 | 20年 | 46/2018/TT-BYT 通知 |
| 測試結果 | 10年 | 醫院規定 |
| 診斷影像 | 10年 | 醫院規定 |
| 審核日誌 | 6 年 (HIPAA) | HIPAA §164.530(j) |
| 處方 | 5 年 | 藥學法 |
| 同意記錄 | 使用壽命 + 6 年 | HIPAA / 法令 13/2023 |
5.2。 PostgreSQL 中的自動保留
-- Partition strategy for data retention
CREATE TABLE audit_events (
id UUID DEFAULT gen_random_uuid(),
event_time TIMESTAMPTZ NOT NULL DEFAULT NOW(),
event_type VARCHAR(50) NOT NULL,
actor_id UUID NOT NULL,
resource_type VARCHAR(100) NOT NULL,
resource_id UUID,
action VARCHAR(20) NOT NULL,
outcome VARCHAR(20) NOT NULL,
details JSONB
) PARTITION BY RANGE (event_time);
-- Create monthly partitions
CREATE TABLE audit_events_2026_01 PARTITION OF audit_events
FOR VALUES FROM ('2026-01-01') TO ('2026-02-01');
CREATE TABLE audit_events_2026_02 PARTITION OF audit_events
FOR VALUES FROM ('2026-02-01') TO ('2026-03-01');
-- Automated partition management
-- Drop partitions older than retention period (6 years for HIPAA)
-- Archive to cold storage before dropping
6. 總結
在本課中，我們有：
- 為醫療資料開發4級資料分類架構
- 透過微服務架構為 PHI 建立資料流映射
- 根據 NIST SP 800-30 方法執行風險評估
- 建立風險登記冊以及風險處理計劃
- 根據越南法規和 HIPAA 定義資料保留政策
練習
- 將醫療系統資料庫中的所有表格/列分為 4 個級別
- 繪製 3 個主要用例的資料流程圖：登記檢查、記錄檢查結果、開藥
- 執行風險評估並為至少 15 個風險建立風險登記冊
- 制定適合組織的資料保留政策
| ◀ 上一篇 | 下一篇文章 ▶ |
|---|---|
| 第 2 課：使用 Quarkus Stack 實現醫療保健的安全微服務架構 | 第 4 課：健康資訊系統的威脅建模 STRIDE/DREAD |