【編者按】雲原生技術正在助力銀行通過差異化業務進行創新，卻也帶來了由于研發/運維人員對新架構不熟悉所導緻的基礎設施風險、業務風險及資料暴露風險。如何在飛速更疊的技術環境下保持業務持續發展，同時保證業務整體的安全性，滿足不斷增強的監管合規要求，其中蘊含着複雜的技術與管理挑戰。
作者 | 王郁 責編 | 楊陽
出品 | 《新程式員》編輯部
在金融行業數字化轉型浪潮下，從國有銀行、股份制銀行到各級商業銀行，都紛紛步入雲原生的程序。以容器、微服務、API為代表的雲原生技術，重塑了雲端應用的設計、開發、部署和運作模式，實作了自動化、易管理、可觀測的全新DevOps體系，開發者和運維人員能夠最大限度地提高生産力，更靈活、更高效地進行應用疊代。但與此同時，雲原生體系也帶來了技術、産品、标準和生态系統的不斷擴大，由此産生了新的基礎設施暴露風險、通信風險和資料傳輸風險。為了滿足雲原生平台高可靠、高性能的基本保障，安全建設至關重要，但這又非常宏觀，涉及到方方面面。新技術的誕生和應用必然面臨着新威脅面的擴充與遷移，這也要求安全技術必須随着業務的技術架構做出即時改變，在新架構上實作安全能力的同步延展。
為此，本文将分别論述：雲原生的底層彈性基礎設施、容器平台和雲原生體系的基礎通信及資料傳輸體系、API在金融科技領域的應用所帶來的威脅面，以及應對相關問題的分析方法和安全實踐。
雲原生的基礎設施——容器平台的威脅面與安全監測技術
容器技術在金融行業的快速落地帶來了彈性伸縮、快速部署等優勢之外，也為業務系統安全帶來了諸如容器逃逸、容器提權、鏡像風險、管理平台暴露等嶄新的攻擊面，而開發和運維人員缺乏對容器的安全威脅和最佳實踐的認識也可能會使業務從一開始就埋下安全隐患。
根據Tripwire的調研報告，60%的受訪者在過去一年使用容器過程中至少發生了一起容器安全事故。在部署規模超過100個容器的使用者中，安全事故的比例上升到75%。由此可見，快速擁抱容器化帶來的安全風險不容忽視。
以攻擊者視角看待容器平台的威脅面
在實際雲環境中，由于開發/運維人員對于容器叢集安全機制的了解和配置能力不一，在賬号建立、AK/SK部署、容器平台端鑒權等位置容易出現憑證洩露、管理平台暴露等風險，可能導緻整個容器平台被攻擊者擷取控制權。我們也曾多次看到由此導緻的嚴重基礎設施入侵事件，對相關金融機構造成了嚴重損失。
如圖1所示，從攻擊的角度，目前行業内已經梳理了多個針對容器的威脅矩陣。以阿裡雲容器ATT&CK攻防矩陣為例，攻擊者在其攻擊流程的初始通路、執行、持久化、權限提升、防禦逃逸、竊取憑證、探測、橫向移動等階段，分别可以對于容器産生的相關攻擊進行嘗試。
圖1：阿裡雲容器ATT&CK攻防矩陣
這些攻擊手段分别從容器的不同暴露點位入手，結合不同的配置缺陷，竊取認證資訊，以此獲得持久化的控制權限，最終能夠達到破壞容器叢集系統及資料、劫持資源、拒絕服務和加密勒索的目的。
解決容器安全問題的三層面分析
面對容器帶來的擴充威脅面，基于容器平台的層次架構，我們可以從以下三個層面來看待這個問題。
在容器及K8s層面，通常我們需要保證鏡像安全、容器運作時安全、容器網絡安全、權限安全等問題。另外，可進一步關注K8s的Pod安全政策。
在平台層，叢集隔離、租戶安全、使用者隔離、網絡ACL與通路控制、審計、DevSecOps、平台高可用等都是平台層面提供的安全能力。平台自身的漏洞掃描、元件漏洞等問題需要做嚴格的漏掃，做到有效處理。
在應用層，可通過DevSecOps在開發過程中為應用提供安全保障。另外，平台應提供應用高可用保障、應用安全接入、跨域政策、資料高可用等能力，為應用進一步提供安全保障。對于面向網際網路的應用，可疊加前端安全裝置的WAF、anti-DDOS、防注入等能力，進一步提升應用的安全性。
容器平台安全防護實踐
雲原生安全離不開容器安全，而容器的安全防護可從以下方面開始着手評估和實踐。
基礎設施層
作業系統安全：涉及容器雲工作節點的作業系統要遵循安全準則。使用端口政策等安全措施，使用最小化作業系統，同時精簡和平台不相關的預置元件，進而降低系統的攻擊面。使用第三方安全工具，檢測系統和應用程式的運作狀态，實作程序和檔案的通路控制等。
平台層安全
安全掃描：對容器排程和管理平台本身，需要先實作安全基線測試，平台安全掃描。
審計：對平台層使用者操作進行審計，同時也需要項目層面的資源和操作審計。
授權：對平台實行權限控制，能基于角色/項目/功能等不同次元進行授權。
備份：定期備份平台資料。
容器安全
鏡像安全：容器使用非root使用者運作，使用安全的基礎鏡像，定時對鏡像進行安全漏洞掃描。
運作時安全：主要是對容器在容器平台上運作過程中對于主控端系統以内進行安全設定，例如容器特權、提升權限、主機PID、主機IPC、主機網絡、隻讀檔案系統等安全限制。同時，建議限制容器對于底層主控端目錄的通路，并設定其對于外部網絡端口暴露的範圍限制。使用者限定某些敏感項目獨占主控端，實作業務隔離。
雲原生的通信血液——API的威脅面與安全監測技術
随着金融行業數字化轉型的深入，API作為雲原生環境下的基礎通信設施，在金融機構的離櫃交易、移動支付、線上服務等多種業務中變得越來越高頻多元。API作為驅動開放共享的核心能力，已深度應用于金融行業。與此同時，其巨大的流量和通路頻率也讓API的風險面變得更廣、影響更大。
當下，由API傳輸的核心業務資料、個人身份資訊等資料的流動性大大增強，是以這些資料面臨着較大的洩漏和濫用風險，成為資料保護的薄弱一環，外部惡意攻擊者會利用API接口批量擷取敏感資料。而從金融的生态開放角度看，目前資料的互動、傳輸、共享等過程往往有多方參與，涉及到交易方、使用者、應用方等多個主體，由此使得資料洩露風險點激增，風險環境愈發複雜。
以攻擊者視角看待API的威脅面
對于API的威脅分析，行業内也有多個組織提出過相關的評估标準。如圖2所示，OWASP在APISecurityTop10-2019架構中總結出，排名前十位的安全風險依次為：對象授權失效、使用者授權失效、資料暴露過度、資源缺失和速率限制、功能級授權失效、批量配置設定、安全配置錯誤、注入、資産管理不當、日志與監控不足。
圖2 OWASPTOP10-2021和OWASPAPISecurityTop10-2019的對比
從圖中不難看出，API安全風險與網絡應用風險高度重合(相同顔色的标記代表同類風險)。這就意味着，API除了自身的獨特漏洞和相關風險外，也面臨着基于網絡的應用程式多年來一直在解決的同類問題。
結合當下金融科技領域API保護的實踐場景，并對OWASPAPISecurityTop10中的風險進行合并與整合，以攻防角度來看，在落地層面主要有以下六點威脅。
水準越權：利用失效的對象授權通過周遊參數批量拖取資料，這是目前衆多金融科技企業API設施所面臨的最主要威脅。随着API生态和多方互動場景的落地，潛在的API越權缺陷極大程度地縮短了攻擊者竊取金融敏感資料的路徑，即攻擊者隻需找到一個可越權的API，無需經曆複雜的打點滲透及橫向移動即可竊取高價值的金融敏感資料。當下手機銀行、微信銀行、小程式、第三方業務開放的大量API接口由于開發規範不一，可能缺乏良好的鑒權認證機制(JWT/Token校驗等)，進而面臨此類風險。
敏感資料暴露：脫敏失效，或一次性傳回多餘不必要的敏感資料。在金融行業重監管的背景下，為滿足數安法、個保法及下屬各地方/行業監管要求，需對個人使用者隐私資料進行治理和合規管理，這對API需要識别、分類和脫敏的資料也提出了較高要求，但目前大量現存API缺乏相應的資料管控能力。
代碼漏洞：SQL注入、指令執行等由業務開發者導緻的風險。API接口本身容易受到代碼漏洞的威脅，如各類型的注入、反序列化威脅等，由于金融行業API本身數量較多且連接配接性較強，需在開發過程中做好代碼審計與相應的安全測試工作。
API基礎設施漏洞：API後端中間件、基礎設施漏洞，如Log4j2、APISIX漏洞。
錯誤配置：不安全、不完整或錯誤配置，如臨時調試API、未鑒權API、存儲權限公開、不必要的http方法、跨越資源共享等。
業務邏輯缺陷：無校驗、無防重放、無風控政策、高并發導緻條件競争等。
API全生命周期安全防護實踐
由于API的安全問題貫穿了從設計、管理到下線的全流程，是以也需要從整個API的生命周期來着手。如圖3所示，表示如何在API生命周期的不同階段落地相應的安全能力。
圖3 API安全生命周期
設計階段
在設計API之初，安全人員需要和産品、開發等角色對焦需求和設計方案，基于企業API安全設計規範，建設自動化威脅模組化能力，将威脅模組化加入API設計階段，給出可能發生的風險解決建議和方案，同時根據業務安全損失及業務重要性對API安全設計進行分層，以不同的安全強度和研發成本适配不同的業務場景。
開發階段
安全團隊可針對API的安全風險，設計面向研發流程的安全開發規範檔案，進行安全意識貫宣，同時提供認證、鑒權、資料通路等包含安全能力的插件或代碼庫，同時可以向CI/CD流程中植入白盒審計能力，将存在漏洞的代碼通過安全開發規範和安全代碼庫收斂，降低人為因素引入漏洞的機率。
測試階段
API場景存在大量的鑒權、越權、編碼、加密問題對傳統安全測試能力提出挑戰。用web攻擊的思路進行黑盒測試無疑收效甚微，目前fuzz工具針對API場景存在以下能力缺失：基于複雜協定解碼(協定級解碼+參數級解碼)的參數污染、基于API通路順序(調用鍊)的fuzz、基于認證狀态的越權漏洞檢測。
運作階段
API安全監測需要從業務、資料、威脅三個視角進行能力建設，包括API的識别與管理、敏感資料流動監測、攻擊事件監測、API異常行為監測等場景。通過實時流量分析的方案，可以針對API行為、通路者行為、通路拓撲等多元度對API行為進行模組化，并結合API網關等安全裝置，針對攻擊特征及已經監控到的安全威脅進行阻斷。
疊代與下線
我們需建設相應的API疊代發現能力，當API發生高風險疊代時，介入安全評審流程。此過程可以監控API的名稱、參數、傳回值、代碼倉庫變更，觸發新一輪的安全自動化測試，并按照業務重要性配置設定安全評審人力資源。同時，舊版API如果沒有被及時下線，不僅會浪費系統資源，還會變成潛在的線上風險，企業可通過API管理平台以及流量側API行為發現失活、棄用的API，及時下線。
API運作時防護實踐
此外，由于API本身涉及到雲原生通信體系在金融科技領域的各項業務，較多API可能已經在未進行安全審計的狀态下，越過了設計、開發、測試階段直接處于運作時狀态。對于這一部分已經投入生産的API，最好能夠建立對于API安全的管控平台。如圖4所示，對已有API進行風險監測、攻擊防護、關聯防禦和智能分析。
圖4：API運作時防護
在風險監測能力上，需要做好API清點，即安全管控平台要對每一個API進行清晰的記錄，包括與什麼類型的資料進行互動、所有者是誰、基礎設施中的相關網絡、實體資源是誰，以及它屬于哪個應用程式或業務部門。
同時，在内容次元，需要能夠識别API參數和有效載荷中的敏感資料類型，并适當地标記API端點。API承載了應用各元件間資料的流動，我們需要關注API攜帶了哪些敏感資料、對誰開放、對方如何使用這些資料等問題。企業被爆出資料洩露事件屢見不鮮，除了資料庫被攻陷之外，其中很大部分是攜帶敏感資料的API鑒權出問題，導緻外部攻擊者通過不斷通路API拖取敏感資料。
在攻擊防護方面，需要能夠阻止針對API協定的攻擊，除了plainHTTP、REST等可複用傳統安全能力的協定之外，仍有諸多協定标準，如GRPC、Dubbo、GraphQL等。還要能夠阻斷WEB攻擊，尤其是針對OWASPAPI安全十大問題中定義的網絡攻擊。
此外，安全管控平台需要具備與各種業務系統整合關聯的能力，應提供與常見IT和安全系統的整合，在發現網絡攻擊和資料安全事件時，聯合所有資源進行處置。這種整合不應局限于基本的日志儲存和資料傳輸，應智能地對事件進行優先排序，提供可操作的安全警報，并配合SOC和IT人員的工作流程。這意味着問題可以在被發現時自動配置設定給适當的團隊或系統，不需要改變工作流程或不同的系統來檢查。通常情況下，安全團隊需要與IT、DevOps或業務部門合作來處置風險。
在智能分析能力上，可以在AI/ML的協助下高頻收集和持續分析API流量，并與每個源IP位址、每個使用者和每個會話的攻擊行為聯系起來。因為攻擊者在早期都會被動地、隐蔽地進行目标探測，還通常對用戶端應用程式代碼進行逆向工程以了解後端API的功能以及如何與之通信。這種被動分析技術可以逃避大多數檢測，因為它們通常是作為合法流量出現的。而API安全産品應該能夠檢測到這樣流量的細微變化，達到早期攻擊預防的目的。
結語
綜上，雲原生平台的安全建設并非一蹴而就，而是一個需要不斷完善、疊代積累的過程，本文以容器平台的安全和API安全為例，分析威脅并給出相關的能力建設點。在實際的安全建設過程中，還會涉及到功能規劃、平台運維、更新實施、安全保障、流程設計等一系列相關問題，在使用全新技術來賦能業務的同時，維護安全同樣也是一個體系化的多元度工程。金融科技企業應從自身情況出發，有針對性地規避雲原生改造過程中的安全問題，平穩且高效地實作金融級雲原生平台的安全建構。
我們相信，雲原生技術在金融科技領域的應用，必然向更加安全、可信的方向發展。
作者介紹
王郁
星闌科技CEO，清華大學網絡空間研究院網絡空間安全碩士。網絡安全戰隊Blue-Lotus、TeaDeliverers前核心成員，HITCON、GEEKPWN國際黑客競賽冠軍，DEFCON-Finals Top3獲得者，曾擔任多個國際級網絡安全賽事命題人及裁判，多個CyberSecurity研究成果發表于CCS等國際頂級安全會議。