金融級或醫療級登入設計

金融級或醫療級登入，不是指：

登入頁看起來很嚴肅
密碼規則很複雜
每 90 天強制改密碼

真正的重點是：

這個系統保護的是高價值資產、高敏感資料，或可能產生法律/金錢/健康後果的操作。

金融系統可能牽涉：

• 帳戶餘額。
• 交易紀錄。
• 收款帳號。
• 轉帳。
• 提款。
• 信用卡資料。
• 投資下單。
• 身分證明文件。

醫療系統可能牽涉：

• 病歷。
• 用藥紀錄。
• 檢驗報告。
• 健康檢查。
• 基因資料。
• 醫療影像。
• 醫病互動紀錄。
• 家屬與代理人授權。

這些都不是普通個人資料。

在台灣《個人資料保護法》裡，個人資料定義包含醫療、基因、健康檢查、財務情況等；其中病歷、醫療、基因、健康檢查等資料更有特別規範。也就是說，這類系統設計不能只問：

怎麼讓使用者登入？

而要問：

怎麼確保正確的人，在正確的風險等級下，存取正確範圍的敏感資料，並留下可追蹤證據？

一、 一句話回答

如果面試官問：

金融級或醫療級登入怎麼設計？

可以先回答：

金融級或醫療級登入要用風險分層設計，而不是只做一個強密碼登入。一般查詢可以用安全 session 加 MFA；查看高敏感資料、匯出資料、修改收款帳號、大額交易、醫療授權、提交申請等操作要做 step-up authentication，必要時使用 Passkey、硬體金鑰、自然人憑證、TW FidO 或交易簽章。Session 要有較短 idle timeout、absolute timeout、可撤銷與裝置管理；資料存取要做最小權限、資料遮蔽、目的限制和 audit log；高風險操作要記錄誰、何時、從哪裡、看了什麼、做了什麼、是否重新驗證、是否簽章。登入只證明身份，不能取代授權、同意、重新驗證或文件簽章。

短一點可以說：

金融/醫療登入的核心是風險分層：
低風險查詢少打擾，高風險操作強驗證、可追蹤、可撤銷、可稽核。

二、 先定義「金融級 / 醫療級」

金融級或醫療級不是一個固定技術規格。

比較準確地說，它代表：

面向	金融 / 醫療場景的特性
資料敏感度	財務、醫療、健康、身分資料
操作後果	金錢損失、醫療風險、法律效果、隱私傷害
攻擊誘因	高，因為資料和帳戶有價值
法規與稽核	通常需要留存證據與安全控管
體驗要求	不能太麻煩，但高風險時必須堅定
錯誤成本	高，錯誤授權或資料外洩後果嚴重

所以系統要分層，不要所有功能都同一套驗證強度。

可以先把操作分成：

低風險：查看一般資訊
中風險：查看部分敏感資料、修改一般設定
高風險：修改安全設定、匯出資料、變更收款帳號
極高風險：大額交易、醫療授權、文件簽章、法定申請

三、 風險分層模型

設計時可以用這張表。

等級	例子	驗證要求
Level 0	公開資訊、公告	不需登入
Level 1	查看基本個人資料	登入 session
Level 2	查看部分敏感資料	MFA 或 recent strong auth
Level 3	修改手機、收款帳號、匯出資料	Step-up authentication
Level 4	大額交易、醫療授權、簽署文件	Step-up + 交易簽章 / 數位簽章

這個分層可以對應到 NIST SP 800-63B 的 Authenticator Assurance Level 概念。

簡化理解：

• AAL1：單因素驗證，適合較低風險。
• AAL2：多因素驗證，適合較高風險。
• AAL3：硬體型、抗冒充更強的驗證，適合極高風險。

實務上不是每個產品都要照 NIST 名稱落地，但心智模型很好用：

不同操作需要不同 assurance level。

四、 整體架構

金融/醫療登入架構會比一般登入多幾個元件。

核心元件：

元件	責任
Auth Service	登入、MFA、session、重新驗證
Risk Engine	裝置、IP、地點、行為、交易風險
Authorization / Policy	權限、資料範圍、代理關係
Consent / Purpose Check	是否有同意、授權目的、存取理由
Signing Service	交易簽章、文件簽章
Data Masking	敏感資料遮蔽、最小揭露
Audit Log	身份、資料存取、敏感操作全紀錄
Alerting	異常登入、資料匯出、大額交易告警

登入只是入口。

後面的授權、資料保護、同意、簽章與稽核同樣重要。

五、 登入流程

一般登入流程：

金融/醫療場景的登入成功後，不應該直接給所有能力。

Session 應該帶上：

type AuthSession = {
  userId: string
  sessionId: string
  authenticatedAt: string
  lastStrongAuthAt?: string
  assuranceLevel: 'aal1' | 'aal2' | 'aal3'
  mfaMethods: string[]
  deviceId?: string
  riskScore: number
  expiresAt: string
}

後續每個敏感 API 依 assuranceLevel、lastStrongAuthAt、riskScore 和操作類型決定是否放行。

六、 MFA 與驗證方式

金融/醫療系統通常不應只靠密碼。

常見方法：

方法	適用
TOTP	一般高風險登入與重新驗證
Passkey / WebAuthn	抗釣魚登入，適合高價值帳號
硬體安全金鑰	管理員、醫師、內部高權限角色
SMS OTP	可作輔助，但不建議作為唯一高強度因素
Email OTP	帳號恢復或低風險輔助
自然人憑證 / TW FidO	台灣高信任身份、政府或醫療申辦場景
生物辨識	常是本機解鎖，不一定等於伺服器 MFA

要特別注意：

手機 Face ID / 指紋解鎖 App

很多時候只是解鎖本機保存的 token 或私鑰，不一定表示伺服器完成一次新的 MFA。

工程上要分清楚：

• 本機解鎖。
• 伺服器身份驗證。
• MFA。
• 交易簽章。

七、 Session 管理

高敏感系統的 session 要比一般網站嚴格。

建議：

設計	說明
idle timeout	閒置太久要求重新驗證或登出
absolute timeout	即使一直操作，也要定期重新驗證
recent auth	敏感操作要求最近完成強驗證
session rotation	登入、MFA、權限變更後旋轉
device list	使用者可查看與撤銷裝置
revoke all	密碼變更或異常時撤銷全部 session
risk-based timeout	高風險裝置或網路縮短 session

NIST SP 800-63B 把 reauthentication 放在 session 管理裡，並區分 overall timeout 和 inactivity timeout，核心目的就是確認使用者仍控制目前 session。

Cookie 建議：

Set-Cookie: __Host-session=<opaque-id>; Path=/; HttpOnly; Secure; SameSite=Lax

如果是高敏感後台或內部醫療系統，可考慮更嚴格：

SameSite=Strict

但要看跨站登入、支付跳轉、SSO 等流程。

八、 高風險操作重新驗證

金融/醫療系統的重點不是登入一次就通行全場。

以下操作應要求 step-up authentication：

金融

• 新增或修改收款帳號。
• 提款。
• 大額轉帳。
• 修改交易限額。
• 綁定新裝置。
• 修改手機或 Email。
• 查看完整卡號或敏感帳務資料。
• 下載大量交易紀錄。

醫療

• 查看完整病歷。
• 下載檢驗報告。
• 授權家屬或代理人查看資料。
• 修改緊急聯絡人。
• 提交醫療同意書。
• 匯出健康資料。
• 醫師開立或修改高風險醫囑。

流程：

使用者已登入
-> 執行敏感操作
-> API 判斷 assurance level 不足
-> 回 reauth_required
-> 使用者完成 MFA / Passkey / TW FidO
-> 發短效 step-up grant
-> API 驗證 grant purpose
-> 執行操作
-> 記錄 audit log / alert

Step-up grant 要：

• 短效。
• 單次使用。
• 綁定 user。
• 綁定 session。
• 綁定 purpose。
• 綁定具體操作資料，必要時。

九、 交易簽章與文件簽章

金融/醫療場景常常不只需要重新驗證。

有些操作需要：

對特定交易或文件留下可驗證承諾。

例如：

• 大額轉帳。
• 投資下單。
• 線上保險申請。
• 醫療授權書。
• 手術同意書。
• 政府/醫療申辦文件。

這時候不能只做：

使用者已重新驗證，所以等於簽署。

應該做交易簽章或數位簽章：

顯示具體內容
-> 產生 canonical content / digest
-> 使用者確認
-> 對內容或 digest 簽章
-> 保存 signature、hash、時間、憑證、驗章結果

交易簽章 payload 範例：

{
  "type": "transfer",
  "transactionId": "tx_123",
  "fromAccount": "123-456",
  "toAccount": "987-654",
  "amount": "200000",
  "currency": "TWD",
  "nonce": "random-request-id",
  "expiresAt": "2026-05-24T12:00:00+08:00"
}

醫療授權 payload 範例：

{
  "type": "medical_record_consent",
  "patientId": "patient_123",
  "authorizedParty": "family_456",
  "scope": ["lab_report", "medication"],
  "validFrom": "2026-05-24",
  "validUntil": "2026-08-24",
  "purpose": "care_assistance",
  "nonce": "random-request-id"
}

核心：

簽的不是「我同意」，
而是「我同意這一份具體內容」。

十、 授權與資料範圍

登入成功只回答：

你是誰。

金融/醫療還要回答：

你能看誰的資料？
你能看哪些欄位？
你是本人、代理人、醫師、客服、審核員，還是管理員？
你這次存取的目的是否合理？

金融例子

使用者可以看自己的帳戶。

客服可能只能看遮蔽後資料。

風控人員可以看交易風險資料，但不一定能執行退款。

財務人員可以處理退款，但不能修改使用者 MFA。

醫療例子

病患可以看自己的資料。

醫師可以看照護關係內的病患資料。

護理師可以看執行照護需要的資料。

家屬或代理人只能看授權範圍內的資料。

研究人員應使用去識別化或最小化資料。

權限模型不能只有：

role = doctor

還要有：

• patient relationship。
• care team membership。
• organization / hospital。
• consent scope。
• purpose of use。
• data category。
• time window。

十一、 資料遮蔽與最小揭露

高敏感資料不一定每次都要完整顯示。

常見策略：

資料	顯示方式
身分證字號	A123*****9
卡號	只顯示末四碼
手機	0912***789
醫療報告	依角色顯示不同欄位
地址	部分遮蔽
API key	只顯示一次或只顯示 prefix

查看完整資料可以要求：

• 重新驗證。
• 填寫查看原因。
• 記錄 audit log。
• 對大量查看做告警。

不要把遮蔽只做在前端。

後端 API 應該依權限和目的回傳最小必要資料。

十二、 Audit Log 設計

金融/醫療系統的 audit log 是核心能力。

不只記登入，還要記資料存取。

至少記：

類別	事件
身份	登入成功/失敗、MFA、登出、重新驗證
Session	新裝置、撤銷、timeout
資料存取	查看、搜尋、下載、匯出
敏感欄位	查看完整身分證、卡號、病歷
操作	修改收款帳號、轉帳、授權、醫囑
權限	代理人授權、醫療團隊關係、角色變更
簽章	文件版本、hash、signature、驗章結果
異常	高風險登入、大量查詢、失敗重試

資料表概念：

create table sensitive_access_audit_logs (
  id uuid primary key,
  actor_user_id uuid,
  actor_type text not null,
  subject_user_id uuid,
  resource_type text not null,
  resource_id text not null,
  action text not null,
  purpose text,
  result text not null,
  reauth_method text,
  assurance_level text,
  ip inet,
  user_agent text,
  request_id text not null,
  risk_score integer,
  metadata jsonb,
  created_at timestamp not null
);

注意：

• Audit log 不要記完整密碼、OTP、token。
• 不要把完整病歷塞進 log。
• metadata 要控管敏感資料。
• log 要防竄改。
• log 查詢本身也要被記錄。
• log retention 要符合法規和業務需求。

十三、 異常偵測

金融/醫療系統要看行為。

常見異常：

• 新裝置登入後立即匯出資料。
• 短時間查詢大量病歷。
• 非照護關係人查病歷。
• 夜間大量資料下載。
• 新增收款帳號後立即大額轉帳。
• 使用者所在地短時間跨國變化。
• MFA 失敗多次後成功。
• 多帳號從同一裝置登入。
• 客服查詢名人或敏感人物資料。

風控動作：

風險	動作
低	記錄
中	安全通知
高	要求 step-up
很高	暫停操作、人工審核、告警
事故	撤銷 session、凍結帳號、啟動應變

異常偵測不要只看登入。

資料存取和操作行為更重要。

十四、 通知與使用者補救

敏感操作後應通知使用者。

例如：

• 新裝置登入。
• 密碼修改。
• MFA 停用。
• 新增收款帳號。
• 大額交易。
• 醫療資料被匯出。
• 家屬授權被建立。
• 帳號資料被修改。

通知內容要包含：

• 發生時間。
• 操作類型。
• 大略裝置或地點。
• 如果不是本人該怎麼處理。

不要在通知中放完整敏感資料。

補救入口要清楚：

不是本人操作？
-> 立即凍結帳號
-> 撤銷 session
-> 聯絡客服/安全團隊
-> 啟動帳號恢復

十五、 醫療場景特別注意

醫療系統不是只有病患登入。

角色很多：

• 病患。
• 家屬。
• 代理人。
• 醫師。
• 護理師。
• 藥師。
• 檢驗人員。
• 行政人員。
• 研究人員。

醫療權限常常依「照護關係」而不是單純 role。

例如：

醫師 A 可以看病患 X，
不是因為他是 doctor，
而是因為他正在照護 X。

所以醫療登入設計要包含：

• care team membership。
• patient consent。
• proxy access。
• emergency access。
• break-glass access。
• purpose of use。
• access audit。

Emergency access 或 break-glass access 必須：

• 填寫原因。
• 立即記錄。
• 事後審查。
• 告警。
• 不能變成日常繞權限手段。

十六、 金融場景特別注意

金融系統要把「查看」和「交易」分開。

查看餘額：

登入 + MFA 或 recent auth

修改收款帳號：

重新驗證 + 冷卻期 + 通知

大額轉帳：

重新驗證 + 交易內容確認 + 交易簽章 + 風控

常見設計：

• 新增收款帳號後延遲生效。
• 新裝置登入後暫停大額交易。
• 大額交易需要更強驗證。
• 交易簽章綁定金額和對象。
• 風險高時人工審核。
• 使用者可設定交易限額。

不要讓攻擊者拿到 session 後立刻完成：

新增收款帳號 -> 提高限額 -> 大額轉出

這一串應該被風控拆斷。

十七、 帳號恢復

高敏感系統的帳號恢復常常比登入更危險。

使用者可能遇到：

• 忘記密碼。
• 手機遺失。
• MFA 裝置遺失。
• Email 被盜。
• 身分證件更新。
• 家屬代理變更。

恢復流程不能太弱。

建議：

• 密碼重設 token 短效、單次、存 hash。
• MFA 重設要有較高身份確認。
• 高風險恢復後暫時限制交易或資料匯出。
• 恢復後撤銷舊 session。
• 發安全通知。
• 記錄 audit log。
• 必要時人工審核。

金融/醫療場景不要讓：

控制 email = 完全接管帳號

至少高風險功能應有額外保護。

十八、 法規與合規語意

這篇不是法律意見，但工程設計要知道：

法規不是只要求你能登入，
而是要求你合理蒐集、保護、限制使用、留存證據，並能處理事故。

台灣個資法重點可以轉成工程語言：

法規語意	工程設計
特定目的	API 存取要有 purpose / scope
必要範圍	最小權限、最小欄位、資料遮蔽
當事人權利	查詢、更正、刪除/停止利用流程
醫療等敏感資料	更高驗證、授權、稽核
安全維護	MFA、session、安全儲存、風控
外洩通知與紀錄	incident response、audit log、通知

HIPAA Security Rule 也強調電子受保護健康資訊的行政、實體與技術保護措施；工程上會落在 access control、audit controls、integrity、transmission security 等方向。

不同國家、產業和產品的法規不同，真實上線要請法務、資安、合規一起確認。

十九、 常見錯誤

1. 只加強密碼規則

錯誤：

金融級 = 密碼一定要大小寫數字特殊符號。

正確：

更重要的是 MFA、風控、session、step-up、交易簽章、audit log。

2. 登入成功後所有功能都放行

錯誤：

使用者登入後可以直接改收款帳號和匯出資料。

正確：

敏感操作要重新驗證，極高風險操作要簽章或審核。

3. 把重新驗證當成簽章

錯誤：

大額交易前有 MFA，所以等於使用者簽署交易。

正確：

MFA 只是確認身份；交易簽章要綁定金額、對象和交易內容。

4. 醫療權限只看角色

錯誤：

doctor 可以看所有病歷。

正確：

要看照護關係、授權範圍、目的和緊急例外。

5. Audit log 只記登入

錯誤：

只記 login success / failure。

正確：

敏感資料查看、下載、匯出、授權、簽章、權限變更都要記。

6. 資料遮蔽只做前端

錯誤：

後端回完整資料，前端用 CSS 或 JS 遮蔽。

正確：

後端依權限回傳最小資料，完整資料另走重新驗證與 audit。

二十、 面試追問題庫

Q1：金融級或醫療級登入和一般登入差在哪？

差在風險分層。一般登入只確認身份；金融/醫療還要依資料敏感度和操作後果要求 MFA、重新驗證、交易簽章、最小權限、資料遮蔽、audit log 和異常偵測。

Q2：是否所有操作都要 MFA？

不一定。應依風險分層。低風險查詢可以用有效 session；查看敏感資料、修改安全設定、匯出資料、交易或醫療授權才提高驗證強度。

Q3：大額交易要怎麼設計？

要做重新驗證、交易內容確認、風險評估、交易簽章，簽章 payload 要綁定金額、帳號、交易 id、nonce 和過期時間，完成後記錄 audit log 並通知使用者。

Q4：醫療資料存取要怎麼控權？

不只看 role，還要看病患與醫療人員的照護關係、授權範圍、資料類型、目的、時間範圍和緊急例外。所有存取都要 audit。

Q5：重新驗證和數位簽章差在哪？

重新驗證確認目前操作者身份；數位簽章或交易簽章是對特定內容留下可驗證承諾。登入和 MFA 都不能自動取代簽章。

Q6：Audit log 要記哪些欄位？

要記 actor、subject、resource、action、purpose、result、time、IP、device、session、reauth method、assurance level、risk score、request id。不要記完整密碼、OTP、token 或過多敏感內容。

Q7：帳號恢復要注意什麼？

恢復流程是高風險入口。要做短效單次 token、較強身份確認、撤銷舊 session、安全通知、audit log，並在恢復後暫時限制高風險操作。

二十一、 實作題

題目一：設計大額轉帳流程

好的流程：

1. 使用者已登入。
2. 建立轉帳草稿。
3. 後端計算風險分數。
4. 顯示轉帳金額、收款帳號、手續費。
5. 要求 step-up authentication。
6. 產生交易 payload / digest。
7. 使用者確認並完成交易簽章。
8. 後端驗章與檢查 nonce。
9. 執行或送人工審核。
10. 記錄 audit log。
11. 發送交易通知。

題目二：設計醫療報告下載

好的答案：

• require session。
• 檢查病患本人、代理人或照護關係。
• 檢查資料類型與授權範圍。
• 要求 recent MFA。
• 下載連結短效。
• 檔案可加浮水印或存取標記。
• 記錄誰下載了哪份報告。
• 大量下載告警。

題目三：設計敏感資料查看

例如查看完整身分證字號或病歷。

好的答案：

• 預設遮蔽。
• 點擊查看完整資料。
• 要求重新驗證。
• 必要時要求填寫目的。
• 後端只回傳該欄位。
• 記錄 audit log。
• 短時間大量查看觸發告警。

題目四：設計帳號恢復

好的答案：

• reset token 短效、單次、存 hash。
• 高風險帳號要求額外身份確認。
• MFA 遺失不能只靠 email 解除。
• 恢復後撤銷所有 session。
• 恢復後限制高風險操作一段時間。
• 發通知。
• 記錄 audit log。

二十二、 資深視角

1. 金融/醫療不是技術堆疊，是風險語意

不是用了 JWT、MFA、AES 就叫金融級。

重點是：

每個操作的風險是什麼？
需要什麼驗證強度？
資料是否最小揭露？
爭議時拿得出什麼證據？

2. 使用者體驗要分層

如果每次點頁面都要 MFA，使用者會疲乏。

好的設計是：

平常順暢，
敏感時明確，
高風險時堅定。

3. 內部人員也是威脅模型的一部分

金融/醫療系統不是只防外部攻擊。

客服、醫療人員、管理員、工程師都可能因誤用、濫權或帳號被盜造成事件。

所以內部後台也要：

• 最小權限。
• 資料遮蔽。
• 存取理由。
• Audit log。
• 異常告警。

4. 證據鏈比功能完成更重要

高敏感系統出事時，會被問：

• 誰登入？
• 如何驗證？
• 看了什麼？
• 改了什麼？
• 是否有同意或授權？
• 是否有重新驗證？
• 是否有簽章？
• 當時風險訊號是什麼？
• 系統有沒有通知？

能回答這些問題，才是成熟的身份系統。

---

總結

面向	設計重點
風險分層	不同資料與操作使用不同驗證強度
MFA	高敏感資料與操作應使用強 MFA
Session	idle timeout、absolute timeout、recent auth、撤銷
Step-up	修改安全設定、匯出資料、交易、授權前重新驗證
簽章	大額交易、文件、醫療授權要綁定具體內容
授權	不只看 role，還看資料範圍、照護關係、目的
資料遮蔽	後端最小揭露，完整資料需重新驗證
Audit	登入、資料存取、下載、簽章、權限變更全紀錄
異常偵測	新裝置、大量查詢、異常交易、越權存取告警
合規	法規語意要轉成目的、範圍、紀錄、通知與應變

一句完整的面試回答可以是：

金融級或醫療級登入要用風險分層設計，而不是只靠強密碼。一般查詢可以用安全 session，但查看高敏感資料、匯出資料、修改收款帳號、大額交易、醫療授權或提交文件時，要依風險要求 MFA、Passkey、TW FidO、自然人憑證或 step-up authentication。交易或文件類操作不能只靠登入或 MFA，還要對具體內容做交易簽章或數位簽章。Session 要有 idle timeout、absolute timeout、recent auth、可撤銷和裝置管理；資料存取要做最小權限、資料遮蔽、目的限制和 audit log；異常登入、大量查詢、資料匯出和高風險交易要告警。核心是正確的人、在足夠信任等級下、存取正確範圍資料，並留下可稽核證據。

延伸閱讀

• 下一篇：Auth Audit Log 設計
• 前一篇：後台管理員登入安全
• 專題總覽：身份驗證與登入系統設計
• 相關專題：高風險操作重新驗證
• 相關專題：身份驗證與數位簽章
• 相關專題：健保卡登入
• 相關專題：自然人憑證登入
• 相關專題：TW FidO
• 相關專題：Risk-based Authentication
• NIST SP 800-63B：Authentication and Lifecycle Management
• OWASP Application Security Verification Standard
• OWASP Authentication Cheat Sheet
• OWASP Session Management Cheat Sheet
• OWASP Logging Cheat Sheet
• 個人資料保護法：全國法規資料庫
• HHS：Summary of the HIPAA Security Rule