保障微服務應用安全從哪些方面入手

保障微服務應用安全從以下方面入手：

• 身份認證：多數業務功能類的應用的首要任務就是需要做身份認證。對于數據公開或新聞發布類的門戶網站類應用不需要考慮這一點，他們更關注的是數據開放之前的管理和審批。身份認證或身份驗證，顧名思義就是對應用程序的”訪問者”的身份進行驗證識別。訪問者分兩類。基于用戶登錄的客戶端(Login-based Client)：用戶訪問服務提供者的應用程序的功能時，需要通過一個客戶端交互界面來與服務提供者交互，用戶需要先登錄，然后由客戶端代表用戶身份去訪問服務提供者應用程序。API客戶端(API Client)：客戶端程序類型的訪問者，這類客戶端自身具備部分API的訪問權限，不需要用戶授予其訪問權限。

• 訪問授權：如果訪問者是API客戶端時，API調用的權限需由網關進行控制。建議采用先訂閱再訪問的授權模式，網關應該僅允許API客戶端訪問其訂閱過的API。具體實現方法就是絕大多數網關都會提供的基于APIKey控制API訪問的方式。需要注意的是，僅使用APIkey的訪問控制是不夠的。API Key是在網關訂閱API時生成的一串唯一編號，并不具備識別客戶端身份的能力。就好比以前買火車票是不實名的，誰拿到火車票，都可以乘坐對應車次。火車票實名制之后，首先需要核驗身份證，核驗通過后才能購票乘車。如果證票不符，則不允許乘車。將客戶端認證和API Key配合進行訪問認證和權限校驗才是個更安全的方案。

• 通信安全：通信安全的方案就是基于傳輸過程加密的方式，常見的選擇就是使用Https協議通信。微服務架構體系中，邏輯層面上外部請求接入都是通過網關作為入口，網關作為內外網的分界，實際部署上，網關本身也是多實例分布式的高可用部署形態，前面架設有一個負載均衡F5或nginx，用來對外提供Https協議接入和路由轉發，而網關內部就是企業內網，默認是可信任的，內網的系統之間的通信會采用更輕量級的HTTP協議。此方案中微服務換成SOA，把網關換成ESB，就是傳統的SOA架構中的安全通信方案，本質上沒有區別。

• 代碼安全：要保證密碼不泄露的辦法就是做好敏感數據保密，技術手段上則要求存儲密碼、憑證的地方(配置文件和數據庫表)需要加密存儲。如：配置文件中的數據庫口令、數據表中存放的密碼數據等。建議在開發期對于編碼規范進行制定，還可以通過工具進行輔助檢查和控制，如開源的代碼質量管理工具Sonar，可以支持多種程序語言，方便的與編譯構建工具集成如Maven，在代碼進入正式提交對應分支前就將一些安全問題在前期預防，如SQL注入等。測試階段，可以通過安全掃描軟件，如AppScan等工具對業務系統的前后端功能進行掃描，檢查系統漏洞并即時修復。盡量減小在上線運行后出現安全事故的風險。

• 管理審計：運維管理安全方面，根據安全需求，要有安全相關的管理規范和工具支撐，對系統管理、權限分配和關鍵數據進行嚴格管控，并做好操作審計日志記錄。比如很多安全級別高的行業或企業中如軍工類，對于業務系統的修改、權限管理審計做了嚴格的流程規范和功能支撐。如典型的三員管理，采用三權分立、互相制約的思路，包含系統管理員、安全管理員、安全審計員三個角色，互相能看到對方的信息，將業務過程分成不同的段，每段由對應人員負責，不讓任何人掌控全局。審計工作是非常重要的一環，沒有任何系統和流程是絕對安全的。關鍵的操作、數據變化等審計日志需要完整記錄。一旦發生問題，可以通過審計日志排查分析追蹤。

回答所涉及的環境：聯想天逸510S、Windows 10。