金融服務作為一種基礎服務，存在于“無形”又無處不在，商業銀行紛紛與互聯網巨頭及政府機構合作，借助金融科技云和特色金融服務的能力輸出，嵌入場景生態，促進金融服務開放。2020年2月13日，中國人民銀行發布《商業銀行應用程序接口安全管理規范》（JR/T0185—2020）（以下簡稱《規范》）金融行業標準，促進開放銀行服務模式安全穩健發展，指導銀行業金融機構和集成接口服務的應用方落實網絡安全責任?！兑幏丁肥紫榷x了商業銀行應用程序接口的類型與安全級別，然后提出了應用程序接口安全體系，包括安全設計、安全部署、安全集成、安全運維、服務終止與系統下線、安全管理等維度。本文主要圍繞《規范》中的安全設計內容談談認識和理解，供大家參考。

商業銀行應用程序接口邏輯結構

商業銀行為增加金融生態黏性，依托API技術，為合作伙伴提供用以互聯的應用程序接口，輸出自身金融服務與信息技術能力。開放的應用程序接口根據開放的范圍和對象差異，可分為內部API、企業定制API與外部API三種類型?！兑幏丁匪鰬贸绦蚪涌诩礊橥獠緼PI，用戶或應用方的連接方式包括API直連和SDK間接連接兩種。SDK主要功能為降低接入復雜度，同時保證接入的安全性，主要用于涉及資金交易與賬戶信息查詢類服務接入。應用方可根據服務安全風險等級選擇相應的接入方式。

商業銀行應用程序接口服務的邏輯結構如圖1所示，包括應用程序接口、應用程序接口服務層和銀行業務系統三個部分。用戶或應用方通過應用程序接口提交服務請求，并通過商業銀行應用程序接口服務層調用銀行業務系統以獲得商業銀行業務服務。商業銀行應用程序接口服務層將用戶或應用方請求轉發至銀行業務系統處理，并反饋處理結果，其功能包括認證鑒權、流量控制、監控分析、報文交換、服務組合等功能，但不涉及具體業務邏輯處理，主要用以實現對商業銀行應用程序接口、用戶和應用方的管理。

圖1商業銀行應用程序接口邏輯結構

商業銀行應用程序接口安全設計

開放銀行服務模式在增加金融機構獲客場景和提升金融服務黏性的同時，其開放性也擴大了商業銀行受攻擊范圍，增加了網絡安全風險隱患。例如應用方可能會訪問或獲取商業銀行內部數據和客戶信息，增加了商業銀行數據泄露風險。甚至可能因應用方平臺系統的安全漏洞或缺陷，導致應用程序接口的非法訪問或服務超負荷等安全隱患，最終導致商業銀行聲譽風險和監管合規風險。本文依據《規范》“安全設計”內容要求，就如何防范網絡安全風險，設計安全可靠接口進行探討，包括設計基本要求、接口安全設計和服務安全設計三個部分。

1.設計基本要求

“設計基本要求”是商業銀行應用程序接口安全設計的基礎，貫穿接口安全設計和服務安全設計的始終。主要從密碼技術的安全應用和應用系統安全性保證兩方面提出基礎要求，應用系統安全性保證又分為自主開發應用安全保證和第三方組件安全保證。

其一，密碼技術的安全應用。應用系統安全性的核心機制在于密碼技術的安全應用，因此《規范》中明確規定密碼算法、技術及產品的使用，應符合國家密碼管理部門及行業主管部門要求，防范因密碼技術產品本身缺陷導致的安全風險。

其二，應用系統安全性保證。確保應用系統安全需要在開發過程中加強事中控制，既要保證自主開發部分安全可控，也要防范第三方組件安全風險。針對自主開發部分，企業內部安全開發標準和規范的落地實施，是保障商業銀行應用程序接口安全性的必要條件，因此《規范》規定了安全設計的基本要求，如制定安全編碼規范、進行安全編碼培訓、開展代碼安全審計、制定版本管理與控制規程、防范信息泄露等。針對非商業銀行開發的第三方組件安全風險，要求商業銀行進行安全性驗證，并持續關注相關平臺的信息披露和更新情況，適時更新相關組件。

2.接口安全設計

開放銀行服務模式通過開放API接口嵌入跨境、運動等場景生態，輸出金融服務能力。從業務服務維度看，對于涉及資金交易與用戶敏感信息服務的API接口，承受較高的網絡安全風險，相反則風險較低。因此《規范》將商業銀行應用程序接口分為兩類，一類是安全級別較高的A2級接口，例如實現支付、轉賬、金融產品與服務購買等功能的接口，以及實現查詢客戶賬戶余額、交易歷史、付款時間以及金融產品和服務持有情況等功能的接口，另一類是安全級別較低的A1級接口，用于實現金融產品和服務信息的查詢，不涉及用戶個人敏感信息。進而《規范》從技術維度細化安全要求，并重點規范A2級接口的安全設計要求。

API接口的安全設計，主要考慮身份識別和認證、數據安全交互和敏感信息保護等三方面內容。

第一，身份識別和認證，主要考慮如何識別和認證接口調用方的真實身份，以解決誰在用以及是否根據授權進行合法使用的問題。在對A2級別接口應用方身份進行認證時，要求使用數字證書或公私鑰對的方式進行雙向身份認證，以確保應用方身份合法并根據授權范圍使用API接口。同時商業銀行還應對使用開放銀行服務的用戶身份進行認證，履行客戶資金和信息保護義務，對于A2級別接口中的資金交易類服務，用戶登錄身份認證應至少使用雙因子認證的方式來保護賬戶財產安全。

第二，數據安全交互，主要考慮如何有效校驗和審核通過API接口交互的數據，以解決數據污染，系統安全運行問題。商業銀行應用程序接口應對雙方系統間連通有效性進行驗證，如接口版本、參數格式等，并對數據的完整性進行保護，以確保應用系統按照規劃設計運行。對于A2級別的接口，商業銀行和應用方均應使用數字簽名來保證交互數據的完整性和不可抵賴性，以確保用戶辦理業務數據的真實性、有效性和安全性。

第三，敏感信息保護，主要是規劃敏感信息使用、交互及存儲規則，以滿足客戶敏感信息保護要求，解決敏感信息泄露等問題。相關要求可從兩個維度來理解，一是交易過程中，對于登錄口令、支付密碼類敏感信息，應采取自定義軟鍵盤、防鍵盤竊聽、防截屏等安全防護措施，確保用戶口令不被惡意軟件盜??；對于賬號、卡號、卡有效期、姓名、證件號碼、手機號碼等敏感信息，在傳輸過程中應使用集成在SDK中的加密組件進行加密，或對相關報文進行整體加密處理，確保數據傳輸過程安全；對于應用方客戶信息獲取需求，確需商業銀行提供的，如賬號、卡號、姓名等用戶敏感信息應脫敏或去標識化處理；因清分與清算、差錯對賬等需求，確需將卡號等支付賬號傳輸至應用方時，應使用加密通道進行傳輸，并保證信息的完整性等要求；二是交易認證結束后，商業銀行需及時清除用戶支付敏感信息，防范攻擊者通過讀取臨時文件、內存數據等方式獲得全部或部分用戶信息。

3.服務安全設計

開放銀行服務模式既要采取有效措施防范潛在網絡安全威脅，做好安全防護能力建設，抵御已知網絡攻擊手段，也要充分考慮用戶和應用方差異化服務需求，滿足商業銀行安全管理和安全運維需求?！兑幏丁分嗅槍υ摬糠种饕獜臋嘞薰芾?、密碼密鑰安全使用和管理、接口日志管理等三方面提出要求。

其一，權限管理。針對應用方差異化服務需求，服務安全設計需遵循最小化授權原則，配置靈活易用的接口權限控制策略，以滿足商業銀行對接口權限的授權及管理需求，當應用方服務需求變更時，能夠根據需求評估結果及時調整開放給應用方的接口范圍及使用周期等權限。

其二，密碼密鑰的安全使用和管理。安全管理的核心問題在于密碼密鑰的安全使用和管理，《規范》針對商業銀行應用程序接口使用授權和控制的關鍵要素，即數字證書或公私鑰對等的使用進行規范，一是建議加密和簽名分配不同的密鑰，且分離存儲。二是禁止將密鑰編寫在應用程序代碼或本地配置文件中，防止因代碼泄露造成的安全隱患。三是要求依據應用程序接口安全等級設置不同的密鑰有效期，并定期更新密鑰。

其三，接口日志管理。針對系統安全運維需求，商業銀行可通過在接口訪問日志中記錄交易流水號、應用唯一標識、接口唯一標識、調用耗時、時間戳、返回結果等信息，支持對接口使用情況的監控，從而實現監測指標預警，保障服務安全穩定運行。針對應用方運維監控需求，規范中明確規定因清分清算、差錯對賬等業務需要，接口日志中應以部分屏蔽的方式記錄支付賬號或其等效信息，除此之外的個人金融信息不應在應用方接口日志中進行記錄。

（本文作者就職于中國銀行軟件中心）

責任編輯：陳愛