云原生日志審計系統面臨哪些挑戰

云原生日志審計系統面臨以下挑戰：

• 日志存儲分散：企業IT系統中的各種網絡設備、安全設備、應用系統等分散在網絡的不同位置，安全審計人員須通過不同的方式，查看設備/應用產生的日志、設備/應用的狀態。

• 日志數據量大：企業IT系統中的各種網絡設備、安全設備、應用系統等每天會產生大量的日志，安全審計人員很難通過人工的手段進行集中存儲管理以及有效分析。

• 日志格式不統一：企業IT系統中的各種網絡設備、安全設備、應用系統等不同的設備類型產生的日志格式都不相同，安全審計人員須了解每種設備/應用日志的格式才有可能分析日志，日志分析成本很大。

• 云原生系統自身特性復雜：針對云原生環境以及云原生應用的特性，其平臺、網絡以及應用在架構和行為上較傳統IT系統都有著更大的復雜性。因此，相比較傳統的日志審計，云原生架構下的日志審計面臨的挑戰將會更大。

• 云原生配置風險：無服務器使用的資產是品類多、動態的、用完即走的，各種安全配置分散在各個產品中，缺乏統一管理和運維平臺，難以做到管理和檢查，從而導致配置安全和隱患，配置安全這個是容易被忽略的。多產品聯動已經足夠困難，更棘手的是，不少項目會跨廠商聯動，比如組合了阿里云、騰訊云、高德開放平臺、百度云等的產品，造成難度系數陡增。

• 內部審計風險：云服務商的無服務器無法保障細粒度的操作的記錄和安全性，如更新代碼人員、部署新服務人員、刪除函數人員等，或要想實現付出的成本很高昂。

保證云原生安全的建議有以下這些：

• 安全左移：許多企業依然在使用已有的工具，卻無法處理云原生應用環境的速度、規模和動態網絡。如果再加上無服務器功能，會讓整個基礎設施變得更抽象，讓問題更嚴重。網絡攻擊者會尋找容器和無服務器代碼中的隱患，以及云基礎設施中的錯誤配置，以接入包含敏感信息的實體，再用它們提升權限，攻擊其他實體。另一個問題是企業在用CI/CD工具持續開發、測試和發布應用。當使用容器部署云原生應用的時候，開發者會從本地或者公共庫當中獲取鏡像，但一般不會檢查這些鏡像是否包含安全隱患。一種解決方案是給安全團隊提供一些工具，阻止不受信任的鏡像進入CI/CD管道，以及啟用一些機制讓不受信任的鏡像在進入生產前就避免產生安全問題。通過在開發流程早期掃描鏡像的漏洞、惡意軟件成分等，開發者可以貫徹安全標準。

• 在函數和容器級別應用邊界安全：在無服務器應用中，系統會被分解成幾個能從不同資源接受項目觸發的可調用組件。這就給了攻擊者更大的攻擊選擇，以及更多實施惡意行為的途徑。一個很重要的方式是使用為云原生環境而制作的API和應用安全工具。除此以外，一個很普遍的操作是在功能級別使用邊界安全——識別功能是否被一個和平時不同的來源所觸發，然后監控事件觸發中存在的異常情況。在容器化環境里，一個重要點是在不同級別都要實現安全——編排控制面板、物理主機、pod和容器。編排的一些最佳安全實踐包括節點隔離、限制和監測容器之間的流量、以及對API服務器使用第三方認證機制。

• 最小角色與最低權限：云原生資源之間會有大量頻繁的交互。如果能夠對每個無服務器功能或者容易都能配置一些獨特的許可，就能有極大概率提升安全性。可以通過基于每個函數使用IAM，或者對容器進行顆粒度的許可，加強接入控制。花一點時間創建最小角色，或者為每個函數或容器創建一系列的許可。這就確保了即使云原生結構中有一個點失陷，其造成的危害也是最小的，并且會防止其他元件產生提權問題。

• 保護應用依賴：無服務器函數和應用的代碼經常從npm或者PyPI的庫中獲取有依賴關系的包。為了保護應用的依賴，就需要包括完整開源組件以及其漏洞數據庫的自動化工具。同樣，還需要能夠在開發流程中觸發安全行為的云原生編排工具。通過持續運作這些工具，就可以防范產線上運行的有隱患的代碼包或者容器。

• 安全共責：在開發者、DevOps和安全團隊之間建立親密的關系。開發者并不是安全專家，但他們可以被教導安全操作知識，從而確保他們可以安全地編寫代碼。安全團隊應該知道應用是如何開發、測試和部署的，還有哪些工具在流程中被使用，從而安全團隊能夠在這些流程中有效地加入安全元素。云原生要求各種企業管理安全和開發的方式，因此盡快讓不同團隊減少隔閡至關重要。云原生的啟用對企業來說是一個形成合作和共享文化的罕見契機。

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