金融机构办理电子银行业务安全控管作业基准修正草案对照表.docx
《金融机构办理电子银行业务安全控管作业基准修正草案对照表.docx》由会员分享，可在线阅读，更多相关《金融机构办理电子银行业务安全控管作业基准修正草案对照表.docx（23页珍藏版）》请在冰豆网上搜索。
金融机构办理电子银行业务安全控管作业基准修正草案对照表
金融機構辦理電子銀行業務安全控管作業基準修正草案對照表990831
修正條文
現行條文
說明
肆、電子銀行業務之交易類別及風險
一、電子轉帳及交易指示類
二、非電子轉帳及交易指示類
係指與資金轉移無關或不直接影響客戶權益之服務項目。
非電子轉帳及交易指示類
服務項目
查詢
１、帳務類查詢：
存放款餘額查詢、交易明細查詢、額度查詢、歸戶查詢、託收票據查詢、匯入匯款查詢、信用狀查詢等交易。
２、非帳務類查詢：
敏感性資料、匯率查詢、利率查詢、共同基金查詢、金融法規查詢、股市行情查詢、投資理財資訊查詢、業務簡介查詢等交易。
通知
入扣帳通知、存款不足通知、存放款到期通知、放款繳息通知、託收票據狀況通知、消費通知等交易。
伍、本基準之構面
一、交易面之安全需求及安全設計
（一）交易面之安全需求
（二）各訊息傳輸途徑所應達到之安全防護措施如下：
訊息傳輸途徑
金融機構專屬網路
加值網路
網際網路
交易類別
防護措施
電子轉帳
及
交易指示類
非電子轉帳及交易指示類
電子轉帳
及
交易指示類
非電子轉帳及交易指示類
電子轉帳
及
交易指示類
非電子轉帳及交易指示類
高風險性之
交易
低風險性之
交易
高風險性之
交易
低風險性之
交易
高風險性之
交易
低風險性之
交易
訊息隱密性
非
必要
非
必要
非必要
非
必要
非
必要
非必要
必要
必要
備註一
訊息完整性
必要
必要
非必要
必要
必要
非必要
必要
必要
非必要
訊息來源辨識
必要
非
必要
非必要
必要
非
必要
非必要
必要
非
必要
非必要
訊息不可重複性
必要
必要
非必要
必要
必要
非必要
必要
必要
非必要
無法否認傳送訊息
必要
非
必要
非必要
必要
非
必要
非必要
必要
非
必要
非必要
無法否認接受訊息
必要
非
必要
非必要
必要
非
必要
非必要
必要
非
必要
非必要
【備註】
必要（Mandatory）：
係指金融機構必須具備該項防護措施。
非必要（Conditional）：
係指金融機構得視情況自行決定是否需要具備該項防護措施。
備註一：
透過網際網路傳送非電子轉帳及交易指示類之
足以識別該個人之資料訊息時，應具備訊息隱密
性防護措施。
（三）交易面之安全設計
係指客戶發送訊息時，其介面及訊息之通訊傳輸應達到之安全防護措施之設計方法，亦即金融機構於系統開發設計時，應加以考量或應具備之基本原則及項目。
１、介面之安全設計：
（１）使用晶片金融卡簽入之安全設計應符合晶片金融卡交易驗證碼之安全設計，於簽入作業時，應由原發卡行驗證交易驗證碼始得簽入（如：
餘額查詢交易）。
（２）使用一次性密碼（OneTimePassword，OTP）之安全設計，係運用動態密碼產生器（KeyToken）、晶片金融卡或以其他方式運用OTP原理，隨機產生限定一次使用之密碼者，經有效驗認後，得以進行簽入或低風險交易。
（３）使用憑證簽章之安全設計，應簽署適當內容並確認該憑證之合法性、正確性、有效性、保證等級及用途限制。
於簽入作業時，應簽署足以識別該個人之資料（如：
身分證字號）；於帳務交易時，應簽署完整付款指示；於憑證展期時，應簽署展期訊息。
（４）使用具有下述兩項（含）以上技術並經有效驗認後，得以進行簽入、低風險交易或輔助認證機制。
◆客戶所知道的資訊（如：
密碼）
◆客戶所持有的設備（如：
密碼產生器、密碼卡、晶片卡、電腦、手機、憑證載具）
◆客戶所擁有的生物特徵（如：
指紋、臉部、虹膜、聲音、掌紋、靜脈）
（５）透過網際網路傳輸途徑並採用戶代號及密碼進行唯一驗證之簽入介面，其應具備之安全設計原則如後，惟若金融機構另佐以其他簽入驗證或交易驗證者，得將下述密碼之安全設計列為最低要求。
（５．１）用戶代號之安全設計：
（５．１．１）金融機構不得使用客戶之顯性資料（如統一編號、身分證號及帳號）作為唯一之識別，否則應另行增設使用者代號以資識別。
（５．１．２）不應少於六位。
（５．１．３）不應訂為相同的英數字、連續英文字或連號數字。
（５．１．４）客戶於申請後若未於一個月（日曆日）內變更密碼，則不得再以該用戶代號執行簽入。
（５．１．５）客戶同一時間內只能登入一次密碼。
（５．１．６）如增設使用者代號，至少應依下列方式辦理：
（５．１．６．１）不得為客戶之顯性資料。
（５．１．６．２）如輸入錯誤達五次，金融機構應做妥善處理。
（５．１．６．３）新建立時不得相同於用戶代號及密碼；變更時，亦同。
（５．２）密碼之安全設計：
（５．２．１）不應少於六位。
若搭配交易密碼使用則不應少於四位。
（５．２．２）建議採英數字混合使用，且宜包含大小寫英文字母或符號。
（５．２．３）不應訂為相同的英數字、連續英文字或連號數字。
（５．２．４）密碼與代號不應相同。
（５．２．５）密碼連續錯誤達五次，不得再繼續執行交易。
（５．２．６）變更密碼不得與前一次相同。
（５．２．７）首次登入時，應強制變更預設密碼。
（５．２．８）密碼超過一年未變更，金融機構應做妥善處理。
２、網際網路應用系統之安全設計：
金融機構應遵循網路應用系統開發注意事項，十四項必要措施如下：
（１）於低風險非約定轉入帳戶轉帳或高風險交易時，系統應設計人工介入機制。
（如：
具遮罩功能之圖形驗證碼（GOTP，GraphicOneTimePassword）、隨機按鈕或動態頁面呈現等方式）
（２）於交易時，載具密碼不應於網際網路上傳送。
（３）系統應設計連線（Session）控制及網頁逾時（TimeOut）中斷機制。
（４）系統應辨識外部網站及其所傳送交易資料之訊息來源及交易資料正確性。
（５）系統應辨識客戶輸入與系統接收之非約轉交易指示一致性
（６）系統應避免存在網頁程式安全漏洞（如：
Injection,Cross-SiteScripting）。
（７）系統應偵測網頁與程式異動時，進行紀錄與通知措施。
（８）元件應驗證網站正確性。
（９）元件應採用被作業系統認可之數位憑證進行程式碼簽章（CodeSign）。
（１０）於低風險非約定轉入帳戶轉帳或高風險交易時，須於載具上需經由人工確認後才回傳交易驗證訊息（如：
交易驗證碼TAC、憑證簽章值）；或於交易過程增加額外具兩項（含）以上技術之介面設計認證機制。
（１１）採用憑證為交易介面者，系統經驗章後應依據原簽章值內之交易指示進行交易。
（１２）採用晶片金融卡為交易介面者，應遵循下列措施：
（１２‧１）系統應依每筆交易動態產製隨機變動之端末設備查核碼，並檢核網頁回傳資料之正確性與有效性。
（１２‧２）於帳務性交易時，系統應每次輸入卡片密碼產生交易驗證碼（TAC，TransactionAuthenticationCode）。
（１２‧３）元件應設計存取卡片時限定為獨占模式。
（１３）採用經本會審核之確認型讀卡機或載具並可人工確認交易內容者，得不執行本安全設計之第
（1）,（4）,（10）必要措施項目。
（１４）一有駭客入侵時，金融機構即應依狀況關閉服務、伺服器或網站，以確保交易安全。
３、訊息傳輸之安全設計：
防護措施
安全設計之基本原則/基本配備
訊息隱密性
（１）訊息處理：
可採對稱性加解密系統或非對稱性加解密系統。
（１．１）對稱性加解密系統如NIST之DES（NationalInstituteofStandardsandTechnology，DataEncryptionStandard，以下簡稱DES）等機制。
（１．１．１）應至少採用DES（金鑰有效長度固定為56位元）或其他安全強度相同之演算法。
４、交易訊息之安全限制：
（１）金融機構應與事業單位以契約規範「限定性繳費稅」業務。
「限定性繳費稅」倘以本人帳戶繳納本人帳單者，其交易指示雖未經客戶事先約定轉出帳戶，但因其轉入帳戶已限定為個別金融機構與個別事業單位事先以契約約定規範之，故金融機構得不使用前述簽入介面之安全設計；惟金融機構得斟酌透過帳務異動通知，達成客戶事後覆核，以提高其安全控管層次。
（２）金融機構應遵循憑證機構之憑證作業基準檢核其憑證措施，以加強安控機制，維護網路交易安全。
（２．１）使用憑證應用於『電子轉帳及交易指示類』時，金融機構應確認憑證之合法性、正確性、有效性、保證等級及用途限制。
（２．２）跨行憑證應用應使用經本會認可之憑證機構簽發之憑證並遵循「金融XML憑證共用性技術規範」且法人戶必須使用硬體裝置儲存金鑰。
憑證跨網使用時必須使用經本會審核通過之中介軟體所支援的憑證載具。
（２．３）金融機構應確實依憑證作業基準辦理相關業務。
如使用臺灣網路認證股份有限公司（下稱TWCA）之NBCA憑證（NetworkBankingCA，網路銀行使用之憑證）客戶，應以臨櫃或郵遞方式向註冊中心申請新憑證；使用金融XML（eXtensibleMarkupLanguage，延伸性標籤語言）憑證客戶，應以使用中有效私密金鑰簽章後傳遞註冊中心申請新憑證。
（２．４）憑證線上更新時˙需以原使用中有效私密金鑰對「憑證更新訊息」做成簽章傳送至註冊中心提出申請。
（２．５）金融機構提供個人戶將其憑證儲存於軟／硬碟，隨身碟等裝置時，除經特殊保護可防止該私鑰被匯出或複製外，交易過程應增加額外具兩項（含）以上技術之介面設計認證機制後始能用於高風險交易作業；且該認證機制不得與產生交易指示採用同一設備。
（３）『電子轉帳及交易指示類』之限制
透過網際網路執行『電子轉帳及交易指示類』之低風險交易指示訊息，除限定性繳費稅交易外，其運用安全機制若不具備『無法否認傳遞訊息』、『無法否認接收訊息』等基本防護措施者，則其運用之對稱性加解密系統之金鑰長度不得小於128位元，且必須增設額外認證機制，以健全安全防護機制。
配合採用各種嚴密的技術防護措施時，且能有效防範密碼資料被竊取或交易資料被竄改之攻擊手法，其非約定轉入帳戶之轉帳限額，可由個別金融機構視其風險承擔之能力斟酌予以適當提高。
（４）『電子轉帳及交易指示類』無加密功能者之限制
電信網路（PSTN）無法提供加密功能者（如電話銀行交易），因係以明碼資料於線上傳輸，故以約定轉出功能，且轉入帳號逐戶約定，公用事業費及各類稅費繳納以概括約定方式為限，惟倘屬限定性繳費稅之低風險性交易，得採非約定轉出功能。
（５）『非電子轉帳及交易指示類』中『帳務類查詢』之限制
透過網際網路執行『非電子轉帳及交易指示類』中『帳務類查詢』之交易指示訊息，其運用之安全機制應具備『訊息隱密性』之基本防護措施，若涉及他行居間代理者除以合約約定者外，其安全機制應具備『訊息來源辨識』之基本防護措施。
（６）除限定性繳費稅交易外之低風險非約定轉入帳戶之交易密碼規定低風險非約定轉入帳戶之轉帳應增設交易密碼，並配合採用各種嚴密的技術防護措施，且能有效防範客戶端被植入木馬程式竊取密碼資料之攻擊手法。
（７）敏感性資料之保護
透過網際網路呈現敏感性資料，其簽入之介面安全設計應採用兩項（含）以上技術保護。
５、雙因素認證：
以上所述採用『兩項（含）以上技術』係指伍、一、（三）、1、
（4）所述技術。
二、管理面之安全需求及安全設計
（一）管理面之安全需求
（二）管理面之安全設計
系統管理面之安全設計係指針對金融機構於系統開發設計時，於系統管理面應加以考量或應具備之基本原則及基本項目。
防護措施
安全設計
建立安全防護策略
應以下列方式處理及管控：
１、系統應依據網路服務需要區隔出獨立的邏輯網域（如Internet,DMZ,Intranet），每個網域皆有既定的防護措施並有通訊閘道管制過濾網域間資料的存取。
２、系統應採用入侵偵測與防護措施，提高資安防護。
３、系統應將重要參數檔加密防護。
（如：
電腦系統密碼檔）
得以下列方式處理及管控：
１、建置安全防護軟硬體。
（如：
防火牆（Firewall）、安控軟體、偵測軟體等）
２、設計存取權控制（AccessControl）如使用密碼、身分證字號、磁卡、IC卡等。
３、簽入（Login）時間控制。
４、單次簽入（Single-Sign-on）。
５、撥接控制（Dial-upControl）。
６、專線（Lease-Line）使用。
７、記錄使用者查詢電話。
８、控制密碼錯誤次數。
９、電腦系統密碼檔加密。
10、留存交易紀錄（TransactionLog）及稽核追蹤紀錄（AuditTrail）。
11、分級。
12、業務面控制如約定帳戶、限定金額等。
13、系統提供各項服務功能時，應確保個人資料保護措施。
提高系統可靠性之措施
應以下列方式處理及管控：
1.建置病毒偵測軟體（VirusDetectionSoftware），定期對網路節點及伺服器進行掃毒並應定期更新病毒碼。
2.系統進行弱點掃瞄與修補。
3.系統應配合作業系統修正檔公佈，盡速修補系統漏洞。
4.定期更換提供給操作者之應用軟體及作業系統密碼。
得以下列方式處理及管控：
１、建立備援及故障預防措施：
（１）預備主機、伺服器、通訊設備、線路、週邊設備等備援裝置。
（２）建置病毒偵測軟體（VirusDetectionSoftware），定期對網路節點及伺服器進行掃毒。
（３）放置網路伺服器於上鎖密室中。
２、強制更換應用軟體及網路作業系統之預設密碼等。
三、環境及端末設備面之安全需求及安全設計
（一）環境面之安全需求
（二）端末設備面之安全設計
防護措施
安全設計
建立安全防護策略
自動櫃員機之安全設計：
８、運用自動櫃員機（CD/ATM）處理卡片交易時，應符合下述規範：
（６）金融機構應確保自動櫃員機之合法性。
自動櫃員機應有唯一之ID（端末設備代號），且針對晶片卡交易應依每筆交易動態產製隨機變動之端末設備查核碼，並檢核資料之正確性與有效性。
實體卡片銷售端末設備之安全設計：
運用銷售端末設備（PointOfSale：
POS）處理交易時，應符合下述規範：
２、金融機構應確保銷售端末設備之合法性。
銷售端末設備應有唯一之ID（端末設備代號），且針對晶片卡交易應依每筆交易動態產製隨機變動之端末設備查核碼，並檢核資料之正確性與有效性。
肆、電子銀行業務之交易類別及風險
一、電子轉帳及交易指示類
二、非電子轉帳及交易指示類
係指與資金轉移無關或不直接影響客戶權益之服務項目。
電子轉帳及交易指示類
服務項目
查詢
１、帳務類查詢：
存放款餘額查詢、交易明細查詢、額度查詢、歸戶查詢、託收票據查詢、匯入匯款查詢、信用狀查詢等交易。
２、非帳務類查詢：
個人資料、匯率查詢、利率查詢、共同基金查詢、金融法規查詢、股市行情查詢、投資理財資訊查詢、業務簡介查詢等交易。
通知
入扣帳通知、存款不足通知、存放款到期通知、放款繳息通知、託收票據狀況通知、消費通知等交易。
伍、本基準之構面
一、交易面之安全需求及安全設計
（一）交易面之安全需求
（二）各訊息傳輸途徑所應達到之安全防護措施如下：
訊息傳輸途徑
金融機構專屬網路
加值網路
網際網路
交易類別
防護措施
電子轉帳
及
交易指示類
非電子轉帳及交易指示類
電子轉帳
及
交易指示類
非電子轉帳及交易指示類
電子轉帳
及
交易指示類
非電子轉帳及交易指示類
高風險性之
交易
低風險性之
交易
高風險性之
交易
低風險性之
交易
高風險性之
交易
低風險性之
交易
訊息隱密性
非
必要
非
必要
非必要
非
必要
非
必要
非必要
必要
必要
非必要
訊息完整性
必要
必要
非必要
必要
必要
非必要
必要
必要
非必要
訊息來源辨識
必要
非
必要
非必要
必要
非
必要
非必要
必要
非
必要
非必要
訊息不可重複性
必要
必要
非必要
必要
必要
非必要
必要
必要
非必要
無法否認傳送訊息
必要
非
必要
非必要
必要
非
必要
非必要
必要
非
必要
非必要
無法否認接受訊息
必要
非
必要
非必要
必要
非
必要
非必要
必要
非
必要
非必要
【備註】
必要（Mandatory）：
係指金融機構必須具備該項防護措施。
非必要（Conditional）：
係指金融機構得視情況自行決定是否需要具備該項防護措施。
（三）交易面之安全設計
係指客戶發送訊息時，其介面及訊息之通訊傳輸應達到之安全防護措施之設計方法，亦即金融機構於系統開發設計時，應加以考量或應具備之基本原則及項目。
１、介面之安全設計：
（１）使用晶片金融卡簽入之安全設計應符合晶片金融卡交易驗證碼之安全設計。
（2）使用動態密碼（OneTimePassword，OTP）或採憑證驗證方式為簽入密碼者，得不使用簽入介面之安全設計。
動態密碼係運用動態密碼產生器（KeyToken）、晶片金融卡或以其他方式運用OTP原理，隨機產生限定一次使用之密碼者，其安控層次已較採用固定密碼簽入者高，故得不再使用簽入介面之安全設計。
（３）透過網際網路傳輸途徑並採用戶代號及密碼進行唯一驗證之簽入介面，其應具備之安全設計原則如後，惟若金融機構另佐以其他簽入驗證或交易驗證者，得將下述密碼之安全設計列為最低要求。
（３．１）用戶代號之安全設計：
（３．１．１）金融機構不得使用客戶之顯性資料（如統一編號、身分證號及帳號）作為唯一之識別，否則應另行增設使用者代號以資識別。
（３．１．２）不應少於六位。
（３．１．３）不應訂為相同的英數字、連續英文字或連號數字。
（３．１．４）客戶於申請後若未於一個月（日曆日）內變更密碼，則不得再以該用戶代號執行簽入。
（３．１．５）客戶同一時間內只能登入一次密碼。
（３．１．６）如增設使用者代號，至少應依下列方式辦理：
（３．１．６．１）不得為客戶之顯性資料。
（３．１．６．２）如輸入錯誤達五次，金融機構應做妥善處理。
（３．１．６．３）新建立時不得相同於用戶代號及密碼；變更時，亦同。
（３．２）密碼之安全設計：
（３．２．１）不應少於六位。
若搭配交易密碼使用則不應少於四位。
（３．２．２）建議採英數字混合使用，且宜包含大小寫英文字母或符號。
（３．２．３）不應訂為相同的英數字、連續英文字或連號數字。
（３．２．４）密碼與代號不應相同。
（３．２．５）密碼連續錯誤達五次，不得再繼續執行交易。
（３．２．６）變更密碼不得與前一次相同。
（３．２．７）首次登入時，應強制變更預設密碼。
（６）金融機構應遵循晶片金融卡網路應用系統開發注意事項，十四項必要措施如下：
（６．１）網站應採用SSL（SecureSocketsLayer，網頁安全傳輸協定）加密或其他方式加密傳輸資料。
（６．２）系統應依每筆交易動態隨機變動端末設備查核碼或以亂碼化保護。
（６．３）系統應設計具遮罩功能之圖形驗證碼（GOTP，GraphicOneTimePassword）或隨機按鈕等方式。
（６．４）系統應建立防止SendKeyControl（模擬鍵盤控制）攻擊之機制（如動態頁面呈現或限制滑鼠點選）。
（６．５）系統應有連線（Session）控制及網頁逾時（TimeOut）中斷機制。
（６．６）於帳務性交易時，系統應每次輸入卡片密碼產生交易驗證碼（TAC，TransactionAuthenticationCode）。
（６．７）若有多網頁設計，系統應驗證前一網頁正確性。
（６．８）系統應驗證網站正確性。
（６．９）元件應具有防盜用機制，以驗證正確網站。
（６．１０）元件應經過作業系統被認可之數位憑證簽章（CodeSign）。
（６．１１）元件應設計存取卡片時限定為獨占模式。
（６．１２）於帳務性交易時，元件應設計需經由人工抽拔卡片動作後才回傳交易驗證碼TAC。
（６．１３）採用經銀行公會審核之確認型讀卡機者，得不執行本注意事項之第3,7,12必要項目。
（６．１４）一有駭客入侵時，金融機構即應立即關閉網路ATM（WebATM、eATM）非約定轉帳功能，以確保交易安全。
２、訊息傳輸之安全設計：
防護措施
安全設計之基本原則/基本配備
訊息隱密性
（１）訊息處理：
可採對稱性加解密系統或非對稱性加解密系統。
（１．１）對稱性加解密系統如NIST之DES（NationalInstituteofStandardsandTechnology，DataEncryptionStandard，以下簡稱DES）等機制。
（１．１．１）應至少採用DES（金鑰有效長度固定為56位元）或其他安全強度相同之演算法。
（４）金融機構應與事業單位以契約規範「限定性繳費稅」業務。
「限定性繳費稅」倘以本人帳戶繳納本人帳單者，其交易指示雖未經客戶事先約定轉出帳戶，但因其轉入帳戶已限定為個別金融機構與個別事業單位事先以契約約定規範之，故金融機構得不使用前述簽入介面之安全設計；惟金融機構得斟酌透過帳務異動通知，達成客戶事後覆核，以提高其安全控管層次。
（５）金融機構應遵循憑證機構之憑證作業基準檢核其憑證措施，以加強安控機制，維護網路交易安全。
（５．１）金融機構應確實依憑證作業基準辦理相關業務。
如使用臺灣網路認證股份有限公司（下稱TWCA）之NBCA憑證（NetworkBankingCA，網路銀行使用之憑證）客戶，應以臨櫃或郵遞方式向註冊中心申請新憑證；使用TWCA之金融XML（eXtensibleMarkupLanguage，延伸性標籤語言）憑證客戶，應以使用中有效私密金鑰簽章後傳遞註冊中心申請新憑證。
（５．２）使用金融XML憑證者依「金融XML憑證共用性技術規範」第七章憑證更新說明，需以原金鑰對「憑證訊息」做成簽章傳送至註冊中心，並應依第八章法人戶必須使用硬體裝置儲存金鑰。
（５．３）金融機構提供個人戶將其憑證儲存於軟／硬碟，隨身碟等裝置時，除經特殊保護可防止該私鑰被匯出或複製外，交易過程應增加額外認證機制後始能用於高風險交易作業。
（四）『電子轉帳及交易指示類』之限制
1、透過網際網路執行『電子轉帳及交易指示類』之低風險交易指示訊息，除限定性繳費稅交易外，其運用安全機制若不具備『無法否認傳遞訊息』、『無法否認接收訊息』等基本防護措施者，則其運用之對稱性加解密系統之金鑰長度不得小於128位元，且必須採用用戶代號、密碼，以健全安全防護機制。
2、透過網路服務執行『晶片金融卡交易』時，代理行應於其交易過程中加入操作者回應事項查核功能（Challenge&Response）。
（五）『電子轉帳及交易指示類』無加密功能者之限制
電信網路（PSTN）無法提供加密功能者（如電話銀行交易），因係以明碼資料於線上傳輸，故以約定轉出功能，且轉入帳號逐戶約定，公用事業費及各類稅費繳納以概括約定方式為限，惟倘屬限定性繳費稅之低風險性交易，得採非
升级会员 