資通系統防護基準

構面4: 識別與鑑別

構面4包含：

措施4-1. 內部使用者之識別與鑑別
措施4-2. 身分驗證管理
措施4-3. 鑑別資訊回饋
措施4-4. 加密模組鑑別
措施4-5. 非內部使用者之識別與鑑別

這個構面應該是4-1比較需要提供符合技術面考量的設計實施方式之佐證，所以我們以此舉例建議系統開發人員提供到什麼程度的陳述。

措施4-1. 內部使用者之識別與鑑別

普|中|高
4-1-1. 資通系統應具備唯一識別及鑑別機關使用者(或代表機關使用者行為之程序)之功能，禁止使用共用帳號。

資通系統登入狀態管控系統設計文件

1. 目標與範圍

1.1 系統目標

確保使用者帳號的唯一性，禁止帳號共用。
避免同一帳號的多重登入，並提供多種登入控制策略。
提供登入狀態的實時監控和即時通知功能，強化系統安全性。

1.2 系統範圍

支援三種登入控制策略：
- 策略1：多重登入限制：拒絕重複登入的請求，提示用戶「帳號已登入」。
- 策略2：警示用戶：允許多重登入，但警示用戶異常登入行為。
- 策略3：強制登出舊的Session：新登入取代舊的Session，舊的Session會被強制登出。

2. 系統架構設計

2.1 系統架構圖

[使用者] │ └─> [前端應用] (token儲存於HttpOnly Cookie) │ └─> [API Gateway] │ └─> [後端伺服器] └─> [RDBMS (MySQL/PostgreSQL)] - 追蹤所有用戶的Session

2.2 主要組件

前端應用：提供使用者輸入帳號、密碼的登入界面，並在登入後接收系統回傳的登入成功/失敗提示。
API Gateway：處理API請求，對請求進行轉發、路由和身份驗證。
後端伺服器：管理使用者的登入流程、檢查登入狀態、執行Session控制策略、管理RDBMS的Session數據。

描述：當使用者登入後，系統會為該使用者創建一個唯一的Session（通常是儲存在伺服器端），並在使用者的瀏覽器中設置一個Session ID（通常是cookie）。

方法：

1. 使用者登入時，伺服器生成一個唯一的Session ID，並將其儲存在伺服器的Session儲存區（例如資料庫或記憶體）。
2. 伺服器端儲存每個使用者的Session ID，並檢查該帳號是否已經有一個有效的Session ID。如果該使用者已經有登入Session，則拒絕新的登入請求或強制終止舊的Session。
3. 當使用者進行登入時，伺服器檢查其Session資料庫，如果該使用者的帳號已經有活躍的Session，則不允許新的登入。
RDBMS：存儲用戶的登入狀態和活動Session，並支援複雜的查詢和事務操作。

描述：將Session資料（如Session ID）與使用者帳號綁定，並將其儲存在資料庫中。每次登入時，檢查資料庫中是否存在該帳號的活躍Session。

方法：

1. 當使用者登入時，將Session ID和使用者帳號資料存儲到資料庫中，並標記為"活躍"。
2. 每當使用者登入時，系統會檢查資料庫中是否存在該帳號的"活躍"Session。如果有，則拒絕登入並提示使用者帳號已經登入。
3. 當使用者登出時，應該刪除資料庫中的Session資料，並將Session標記為"已登出"。

3. 資料庫設計

3.1 資料庫表結構

(略)

4. 登入控制策略設計

4.1 策略1：多重登入限制

描述：如果用戶嘗試在其他設備上使用相同的帳號登入，則拒絕該登入請求。

業務邏輯流程：

FUNCTION login(email, password)    AUTH_RESULT = verify_user(email, password)    IF AUTH_RESULT IS FAILED        RETURN "登入失敗"    END IF
    USER_ID = AUTH_RESULT.user_id    ACTIVE_SESSION = SELECT * FROM sessions WHERE user_id = USER_ID AND status = 'active'
    IF ACTIVE_SESSION IS NOT EMPTY        RETURN "該帳號已登入，請先登出"    END IF
    NEW_SESSION_ID = GENERATE_UUID()    INSERT INTO sessions (session_id, user_id, device_id, ip_address, login_time, status)     VALUES (NEW_SESSION_ID, USER_ID, GET_DEVICE_IDENTIFIER(), GET_USER_IP(), CURRENT_TIMESTAMP, 'active')
    RETURN "登入成功"END FUNCTION

4.2 策略2：警示用戶

描述：允許多重登入，但向舊的Session用戶發送警告通知，如簡訊、郵件或系統消息提示。

業務邏輯流程：

FUNCTION login(email, password)    AUTH_RESULT = verify_user(email, password)    IF AUTH_RESULT IS FAILED        RETURN "登入失敗"    END IF
    USER_ID = AUTH_RESULT.user_id    ACTIVE_SESSION = SELECT * FROM sessions WHERE user_id = USER_ID AND status = 'active'
    IF ACTIVE_SESSION IS NOT EMPTY        SEND_ALERT(USER_ID, "您的帳號在新的裝置上登入")    END IF
    NEW_SESSION_ID = GENERATE_UUID()    INSERT INTO sessions (session_id, user_id, device_id, ip_address, login_time, status)     VALUES (NEW_SESSION_ID, USER_ID, GET_DEVICE_IDENTIFIER(), GET_USER_IP(), CURRENT_TIMESTAMP, 'active')
    RETURN "登入成功"END FUNCTION

4.3 策略3：強制登出舊的Session

描述：允許新設備登入，刪除舊的Session，並使舊的登入裝置失效。

業務邏輯流程：

FUNCTION login(email, password)    AUTH_RESULT = verify_user(email, password)    IF AUTH_RESULT IS FAILED        RETURN "登入失敗"    END IF
    USER_ID = AUTH_RESULT.user_id    UPDATE sessions SET status = 'terminated' WHERE user_id = USER_ID AND status = 'active'
    NEW_SESSION_ID = GENERATE_UUID()    INSERT INTO sessions (session_id, user_id, device_id, ip_address, login_time, status)     VALUES (NEW_SESSION_ID, USER_ID, GET_DEVICE_IDENTIFIER(), GET_USER_IP(), CURRENT_TIMESTAMP, 'active')
    RETURN "登入成功"END FUNCTION

5. 系統安全性設計

身份驗證：
- 使用bcrypt加密用戶密碼，避免明文儲存。
- 使用JWT進行身份驗證，令牌有效期設置為1小時。
Session管理：
- RDBMS的sessions表記錄用戶的所有活動會話，支援多個登入策略。
異常檢測與提醒：
- 當檢測到多重登入或異地登入時，向用戶發送警示。

6. 非功能性需求

性能要求：
- Session查詢和管理的響應時間應控制在100ms以內。
可擴展性：
- 支援數據庫的讀寫分離架構，在高並發請求下仍能維持穩定的性能。
可用性：
- 如果數據庫發生中斷，系統應提供備援機制，確保Session數據不會丟失。

高
4-1-2. 對資通系統之存取採取多重認證技術。

資通系統多重因素身分驗證系統設計文件

1. 目標與範圍

1.1 系統目標

確保使用者的身份驗證具備更高的安全性，減少憑證被盜的風險。
使用多重因素的身份驗證，確保驗證具備至少兩種不同類型的因素。

1.2 系統範圍

支援以下三類驗證類型：
- 所知之事：密碼、特定問題的答案。
- 所持之物：一次性驗證碼（OTP）、硬體安全金鑰、智慧卡。
- 所具之形：生物特徵（如指紋、虹膜或人臉辨識）。

2. 系統架構設計

2.1 系統架構圖

[使用者] │ └─> [前端應用] (包含登入頁面、多重驗證提示界面) │ └─> [API Gateway] │ └─> [後端伺服器] └─> [身份驗證服務 (Authentication Service)] └─> [RDBMS] - 儲存用戶憑證和驗證狀態 └─> [生物辨識系統] - 進行生物特徵驗證 └─> [OTP/Token 發送系統] - 發送一次性密碼（OTP）

3. 資料庫設計

(略)

4. 驗證流程設計

4.1 登入與多重驗證流程

FUNCTION login(email, password)    AUTH_RESULT = verify_user(email, password)    IF AUTH_RESULT IS FAILED        RETURN "登入失敗"    END IF
    USER_ID = AUTH_RESULT.user_id    INITIATE_MFA(USER_ID)    RETURN "請完成多重身份驗證"END FUNCTION
FUNCTION INITIATE_MFA(USER_ID)    FACTOR_1_RESULT = verify_knowledge_factor(USER_ID)    IF FACTOR_1_RESULT IS SUCCESSFUL        FACTOR_2_RESULT = verify_possession_factor(USER_ID)        IF FACTOR_2_RESULT IS SUCCESSFUL            FACTOR_3_RESULT = verify_inherence_factor(USER_ID)            IF FACTOR_3_RESULT IS SUCCESSFUL                RETURN "驗證成功"            ELSE                RETURN "生物特徵驗證失敗"            END IF        ELSE            RETURN "持有物驗證失敗"        END IF    ELSE        RETURN "所知之事驗證失敗"    END IFEND FUNCTION

5. 驗證因子設計

5.1 所知之事 (Knowledge Factor)

驗證方式：
- 驗證密碼是否與數據庫中的加密密碼匹配。
- 提供安全問題的答案作為額外的驗證步驟。

虛擬碼表示：

FUNCTION verify_knowledge_factor(USER_ID) PASSWORD_INPUT = GET_USER_INPUT("輸入您的密碼") STORED_PASSWORD = SELECT password FROM users WHERE user_id = USER_ID IF HASH(PASSWORD_INPUT) = STORED_PASSWORD RETURN "成功" ELSE RETURN "失敗" END IFEND FUNCTION
5.2 所持之物 (Possession Factor)

驗證方式：
- 發送一次性密碼（OTP）至用戶的註冊電子郵件或行動電話，要求用戶輸入。

虛擬碼表示：FUNCTION verify_possession_factor(USER_ID) OTP = GENERATE_OTP() SEND_OTP_TO_USER(USER_ID, OTP) OTP_INPUT = GET_USER_INPUT("輸入您收到的OTP") IF OTP_INPUT = OTP RETURN "成功" ELSE RETURN "失敗" END IFEND FUNCTION

5.3 所具之形 (Inherence Factor)

驗證方式：
- 驗證用戶的生物特徵，如指紋、人臉或虹膜。

虛擬碼表示：

FUNCTION verify_inherence_factor(USER_ID) BIOMETRIC_INPUT = GET_BIOMETRIC_DATA_FROM_USER() STORED_BIOMETRIC = SELECT biometric_data FROM users WHERE user_id = USER_ID IF COMPARE_BIOMETRIC(BIOMETRIC_INPUT, STORED_BIOMETRIC) IS TRUE RETURN "成功" ELSE RETURN "失敗" END IFEND FUNCTION

6. 系統安全性設計

數據加密：
- 使用bcrypt對密碼進行加密，生物特徵數據也應加密存儲。
防止重放攻擊：
- OTP僅允許使用一次且有時效性，驗證請求加上唯一的請求ID以防重放攻擊。
失敗嘗試限制：
- 每個驗證因素的嘗試次數有限制（例如，5次失敗後鎖定帳號）。

7. 非功能性需求

性能要求：
- 系統應在500ms內完成多重驗證的所有檢查。
可擴展性：
- 支援負載平衡和分散式架構，確保高並發時的可用性和穩定性。
可用性：
- 系統應支援多地部署，確保災難復原能力。

以上範例是詢問ChatGPT後再稍加整理而成的，其中或許有部分不容易落實，或者在專案執行時某些考量下不夠充分，所以在參考引用這些內容仍應仔細斟酌合宜性。