回顧系列
- 場次 01:現代交易生命週期:從交易到結算
- 場次 02:Goldman Sachs:透過 Fast Track 將應用程式移至雲端 - AWS FSI Meetup Q1/2023
- 場次 03:Zurich Insurance Group:在 AWS 上建置有效的日誌管理解決方案
- 場次 04:FSI Meetup 2025 Q4 - Brex 資料庫災難復原
- 場次 05:FSI Meetup 2025 Q4 - Graviton 遷移成功案例
- 場次 06:FSI Meetup 2025 Q4 - Stifel 現代化資料平台
- 場次 07:FSI Meetup 2025 Q4 - PayPal 金融交易資料對帳器
- 場次 08:FSI Meetup 2025 Q4 - 擴展韌性
場次筆記
議程 從基礎開始
- 什麼是日誌管理,以及為何它對金融業組織至關重要
- 日誌管理在法規遵循、安全性與營運效率方面扮演的角色
探討金融機構在日誌管理方面面臨的獨特挑戰
- 處理大量資料
- 符合法規要求
- 管理成本
討論 Zurich 對日誌管理解決方案的具體目標
- 瞭解所採用的方法
深入探討解決方案的技術細節
- 概述所使用的主要 AWS 服務
- 說明可擴展性、成本效益與效率的設計原則
檢視所達成的成果與效益
- 將經驗應用於其他金融業組織
最後總結重點
- 為正在使用或評估使用 AWS 進行日誌管理的組織提供可執行的洞見
內容務實且貼近實際,著重於真實世界的策略,並為聽眾的實踐歷程提供啟發
從基本概念開始:
- 為什麼日誌管理在金融業很重要?
日誌管理的基礎
- 日誌來源:日誌來自伺服器、設備、網路裝置、雲端服務等
- 日誌收集:集中收集日誌對可視性與法規遵循至關重要
- 處理與分析:濾除雜訊、加入脈絡資訊,以及識別模式或警訊
- 儲存與保留:安全、有條理且長期的儲存(例如 S3 儲存層)對法規遵循至關重要
- 洞見與行動:運用資料取得可執行的洞見並採取因應措施
日誌管理對金融服務業至關重要,主要有三個原因:
- 法規遵循:監管機關要求提出已盡適當注意義務的證明,而日誌可作為證據。
- 安全性:日誌對及早偵測與緩解威脅至關重要。
- 營運效率:系統順暢運作能讓客戶、員工與監管機關都感到滿意。
- 日誌管理不只是收集資料,而是將資料轉化為有用的洞見,以保護系統、符合法規並提升營運效率。
主要痛點:
Zurich 在日誌管理方面面臨的具體挑戰:
- 集中式日誌記錄的成本可能迅速攀升。
- 原有方法將所有日誌一視同仁,把一切都存放在高成本儲存空間,並將所有日誌當作關鍵資料處理,導致成本快速增加。
資料量:
- 金融服務業會從各種來源產生大量日誌資料(防火牆規則、存取嘗試、弱點掃描等)。
- 由於需要處理敏感資料,安全系統每天會產生數 TB 的日誌。
- 並非所有安全日誌都同等重要;有些可以稍後分析,而關鍵警示則需要立即處理。
法規遵循要求:
- PCI DSS 與 GDPR 等法規要求保留日誌(例如為稽核保留七年)及詳細的存取紀錄。
- 要確保日誌安全、防竄改且可供存取,同時又不產生過高成本,是一項挑戰。
成本效益:
- 在完整日誌管理需求與具成本效益的解決方案之間取得平衡至關重要。
將所有日誌一視同仁會造成資源浪費:
- 並非所有日誌都需要高成本的即時處理。
- 範例:一次性的偵錯日誌,與包含安全關鍵資訊的 API 存取日誌。
- 需要根據日誌的重要性與潛在用途進行儲存和保留。
複雜性與整合挑戰:
- 日誌來自採用不同格式的各種來源(舊式系統、雲端服務、應用程式、裝置)。
- 在系統之間轉換可能造成延遲與監控盲區。
- 範例:弱點管理系統與 CASB 工具(Cloud Access Security Broke)採用不同格式。
安全性與即時分析:
- SIME(安全資訊與事件管理)日誌對威脅偵測與因應至關重要。
- 需要快速且有效率地分析日誌,以偵測模式(例如登入失敗嘗試可能表示暴力破解攻擊)。
- 信任在金融業至關重要,因此及時偵測威脅不可或缺。
挑戰摘要:
- 龐大的資料量
- 嚴格的法規遵循要求
- 高昂的日誌記錄成本
- 混亂的整合作業
- 即時安全性的需求
解決方案目標:
- 現代化日誌管理方法:
- 不再將每一筆日誌一視同仁。
- 使用可擴展的工具,依重要性排定資料收集的優先順序。
降低成本:
- 在不犧牲效能與法規遵循的前提下,降低每 GB 的擷取成本。
- 在擷取前濾除不必要的日誌,以更聰明的方式管理資料。
淘汰舊有 SIME(安全資訊與事件管理)基礎設施:
- 停用舊式系統,以減少技術債、高額維護成本、效能緩慢及擴展能力有限等問題。
- 釋出資源,投入更現代化且有效率的解決方案。
改善分析效能:
- 降低延遲並縮短日誌搜尋時間,以更快取得洞見並進行即時決策。
- 著重提供更佳效能,避免不必要的延遲。
目標摘要:
- 實現更聰明的日誌管理,以降低成本、簡化環境並提供更佳效能。
- 專注於最重要的事項。
解決方案架構: 依重要性排定日誌優先順序:
- 高優先順序日誌(例如安全事件)會路由至即時分析。
- 較低優先順序日誌(例如法規遵循相關日誌)則存放在 S3 等具成本效益的封存空間。
- 確保資源集中於關鍵資料,同時控制成本。
ETL 管線:
- 如同日誌的交通指揮,濾除不必要的資料以降低擷取成本。
- 以額外的中繼資料豐富資料內容,讓日誌更具可操作性。
- 將資料路由至適當目的地(即時分析或長期儲存)。
- 這對降低每 GB 擷取成本,以及確保有價值的資料能在需要之處使用至關重要。
將日誌路由至 SIME 與 AWS 基礎設施:
- 經過優先排序和處理後,日誌會導向 SIME(安全資訊與事件管理)與 AWS 基礎設施,以進行進一步分析和儲存。
AWS 基礎設施元件及其角色: Amazon OpenSearch Service:
- 透過快速日誌搜尋實現即時分析。
- 為 DevOps 與安全團隊提供儀表板和監控工具。
- 有助於快速找出根本原因(例如登入失敗嘗試突然激增)。
Amazon S3:
- 儲存所有日誌以供法規遵循使用。
- 可擴展、安全且具成本效益。
- 非常適合法規遵循需求。
AWS Glue 與 Data Catalog:
- 整理日誌並使其可供搜尋。
- 減少搜尋原始資料所花費的時間。
Amazon Athena:
- 無須移動資料,即可直接查詢 S3 中的資料。
- 適合以具成本效益的方式進行深入調查與臨時分析。
- 適用於調查潛在的法規遵循問題。
結合資料優先排序、ETL 功能與 AWS 服務:
- 將日誌管理方法現代化。
- 僅儲存及處理最重要的日誌,以降低成本。
- 停用舊式 SIME(安全資訊與事件管理)系統,以簡化基礎設施。
- 透過更快速的日誌搜尋和更完善的分析來改善效能。
解決方案的效益與成果: 節省成本:
- 將 SIME(安全資訊與事件管理)的擷取量從每天 5 TB 降至每天 500 GB。
- 透過部署具備版本控制與自動備份功能的 Cribl 達成。
- 在擷取前濾除不必要的日誌。
- 使用 Terraform 快速擴展。
效能改善:
- 用於計算每個防火牆事件數量的範例查詢,執行時間從 93 秒縮短至 2 秒。
- OpenSearch 經證實速度快且易於管理。
- 一鍵部署與升級。
- 使用具版本控制的 Terraform,實現一致且可靠的推出作業。
清理環境並減少技術債:
- 停用舊有 SIME(安全資訊與事件管理)基礎設施,消除技術債。
- 轉換至簡潔、現代化的架構。
可擴展性:
- 使用 S3 等 AWS 服務進行分層資料儲存(頻繁存取、低頻存取及 Glacier)。
- 使用 Terraform 快速擴展 Cribl 與其他元件。
- 系統可隨組織需求成長。
法規遵循與安全性:
- 日誌安全地存放於 S3,並可在 OpenSearch 中輕鬆搜尋。
- 讓法規報告與安全監控更快速、更簡單且更可靠。
從這段歷程中學到的主要經驗: 優先處理正確的資料:
- 並非所有日誌都相同;應根據重要性分別處理。
- Zurich 透過優先處理關鍵日誌,將擷取成本降低了 50% 以上。
投資現代化工具:
- 使用針對當前挑戰而設計的工具(例如 Cribl、AWS OpenSearch、S3)。
- 這些工具可隨組織無縫擴展。
透過自動化確保一致性:
- 運用自動化(例如 Terraform)進行部署、升級和擴展。
- 減少人為錯誤,並讓團隊能投入策略性工作。
超越法規遵循的思維:
- 現代化日誌管理可提供更快速的搜尋、即時洞見與更完善的安全監控。
- 著重讓資料為組織創造效益,而不只是符合法規要求。
摘要:
- 更聰明的日誌管理方法能帶來徹底轉變。
- 優先處理重要事項、投資現代化工具、將流程自動化,並以超越法規遵循的角度思考。
日誌管理的未來計畫:
持續專注於節省成本:
- 改良 S3 分層策略,以最佳化儲存效率。
- 根據使用情況,在頻繁存取、低頻存取與 Glacier 儲存層之間移動日誌。
擴大自動化:
- 使用 Terraform 進一步簡化擴展與組態更新。
- 目標是打造幾乎能自行運作的基礎設施。
整合進階分析:
- 運用 OpenSearch 內建的機器學習功能,例如異常偵測。
- 在日誌資料中的異常模式惡化之前加以掌握。
匯入並最佳化 SIME 關聯搜尋與警示:
- 持續從舊式 SIME(安全資訊與事件管理)轉移,將這些項目匯入 OpenSearch 並加以最佳化。
- 在採用現代化平台的同時,維持高標準的監控。
強化資料治理:
- 使用 AWS Glue 等工具強化中繼資料管理。
- 維持日誌井然有序,並提前因應法規遵循要求。
探索結合 OpenSearch 的生成式 AI:
- 使用 OpenSearch 作為向量資料庫,為 AI 使用案例提供檢索增強生成(RAG)能力。
- 範例:使用日誌訓練 AI 模型,在系統問題發生前加以預測。
