從 4 個分散工具到 1 個統一平台：AWS Security Hub 如何實現近即時威脅關聯與 1 年趨勢追蹤

一家金融服務公司的安全團隊每天早上都面臨同樣的挑戰：安全分析師需要登入 Amazon GuardDuty 檢查威脅偵測警報、切換到 Amazon Inspector 查看漏洞掃描結果、再開啟 Amazon Macie 確認資料洩漏風險、最後還要登入 Security Hub CSPM 檢查配置偏移。四個不同的主控台、四組不同的警報、四種不同的優先級判斷標準——當一個 EC2 執行個體同時出現在 GuardDuty 的惡意活動警報和 Inspector 的高風險漏洞清單中時，團隊需要手動拼湊這些訊號，才能理解真正的風險全貌。更糟的是，當資安長 (CISO) 詢問「過去三個月我們的整體安全態勢是改善還是惡化？」時，分析師必須從四個系統匯出資料、手動製作報表，而這個過程往往需要數天時間。這不是個案，而是許多企業在使用多個 AWS 安全服務時面臨的真實困境。今天，AWS Security Hub 正式發布 (General Availability)，透過統一平台、近即時威脅關聯、以及長達 1 年的歷史趨勢資料，徹底改變企業安全營運的方式。

4 個工具分散的真實困境：為什麼統一平台如此關鍵

當企業開始認真對待雲端安全時，通常會逐步採用多個專業工具來覆蓋不同的安全面向。Amazon GuardDuty 提供智慧型威脅偵測，持續分析 VPC 流量日誌、CloudTrail 事件和 DNS 查詢，識別可疑的網路活動、未經授權的 API 呼叫、或加密貨幣挖礦行為。Amazon Inspector 專注於漏洞管理，自動掃描 EC2 執行個體和容器映像檔，找出軟體漏洞、網路暴露和不安全配置。Amazon Macie 則保護敏感資料，使用機器學習自動發現和分類 S3 儲存桶中的個人識別資訊 (PII)、財務資料或智慧財產。Security Hub CSPM (雲端安全態勢管理) 評估資源配置是否符合安全最佳實踐和合規標準。每個工具在其專業領域都表現出色，但當它們各自為政時，就會產生三個嚴重問題。

警報疲勞與上下文缺失

第一個問題是警報疲勞與上下文缺失。一個大型企業可能每天收到數百甚至數千條安全警報，分散在四個不同的主控台中。安全分析師必須在工具之間來回切換，手動尋找相關警報之間的關聯。例如，Amazon GuardDuty 可能偵測到某個 EC2 執行個體正在與已知惡意 IP 通訊，而 Amazon Inspector 同時發現該執行個體存在一個高危遠端執行漏洞——這兩個訊號結合起來代表極高的入侵風險，但如果它們只是兩條獨立的警報，分析師可能無法立即意識到威脅的嚴重性。

優先級判斷的複雜性

第二個問題是優先級判斷的複雜性。每個安全工具都有自己的嚴重性評分系統——GuardDuty 使用 0.1 到 8+ 的數值評分，Inspector 使用 Critical/High/Medium/Low 分級，Macie 有自己的敏感度評估邏輯。當一個資源同時觸發多個工具的警報時，如何判斷哪個問題應該優先處理？是先修補 Inspector 發現的 Critical 漏洞，還是先調查 GuardDuty 標記的異常 API 呼叫？缺乏統一的風險評估框架，團隊往往只能依賴個人經驗和主觀判斷，這不僅降低了回應效率，也增加了遺漏重要威脅的風險。

歷史趨勢分析的缺乏

第三個問題是歷史趨勢分析的缺乏。即時警報能幫助團隊應對當下的威脅，但安全管理不只是「打地鼠」式的即時反應，更需要長期的策略規劃和持續改進。資安長需要回答這樣的問題：我們的整體安全態勢在過去六個月是改善還是惡化？我們在漏洞修補方面的平均回應時間是多少？哪些類型的威脅在我們的環境中最常出現？然而，當資料分散在四個工具中，每個工具又有不同的資料保留政策和匯出格式時，進行跨工具的歷史分析變成一項耗時且容易出錯的工作。許多企業只能依賴每月或每季的手動報表，而這種滯後的分析無法支持即時的策略調整。

AWS Security Hub 的統一平台設計正是為了解決這些問題。它不是要取代 GuardDuty、Inspector、Macie 或其他安全工具，而是作為一個中央整合層，自動收集這些工具的所有發現 (findings)，進行關聯分析，提供統一的風險評分，並在單一儀表板中呈現完整的安全態勢。這種「單一真相來源」 (single source of truth) 的方法，讓安全團隊能夠從「工具操作員」轉變為「威脅分析師」——不再花費大量時間在工具之間切換和手動關聯資料，而是專注於理解威脅的本質和制定有效的回應策略。

近即時威脅關聯：從分散訊號到統一洞察

AWS Security Hub 的核心價值在於其近即時的威脅關聯能力。「近即時」 (near real-time) 意味著當 Amazon GuardDuty、Amazon Inspector、Security Hub CSPM 或 Amazon Macie 發現新的安全問題時，AWS Security Hub 幾乎同時就能接收到這些發現，並立即開始關聯分析。這種即時性對於威脅回應至關重要——在網路攻擊的場景中，從初始入侵到橫向移動再到資料外洩，往往只有數小時甚至數分鐘的時間窗口。延遲的威脅關聯意味著錯失了阻止攻擊升級的最佳時機。

多維度關聯分析邏輯

威脅關聯的邏輯基於資源、時間和攻擊模式的多維度分析。最基本的關聯是資源層級的關聯：AWS Security Hub 會自動識別指向同一個資源 (例如同一個 EC2 執行個體、S3 儲存桶或 RDS 資料庫) 的多個發現。例如，如果一個 EC2 執行個體同時出現在以下發現中：GuardDuty 偵測到該執行個體正在進行 DNS 隧道傳輸 (可能的資料外洩手法)、Inspector 發現該執行個體有未修補的遠端執行漏洞、Security Hub CSPM 發現該執行個體的安全群組規則過於寬鬆 (允許來自任何 IP 的 SSH 連線) ——AWS Security Hub 會將這三個發現關聯起來，標記為一個高風險的「暴露」 (Exposure)。

第二種關聯是時間序列的關聯：AWS Security Hub 分析發現的發生順序和時間間隔，識別可能的攻擊鏈。例如，在一個典型的入侵場景中，攻擊者可能先透過釣魚郵件取得 IAM 使用者憑證 (GuardDuty 偵測到異常的主控台登入來源)，然後列舉環境中的資源 (CloudTrail 記錄大量的 Describe* API 呼叫)，接著嘗試提升權限 (GuardDuty 偵測到異常的 IAM 政策修改)，最後存取敏感資料 (Macie 偵測到不尋常的 S3 資料存取模式)。AWS Security Hub 能夠識別這些時間上相關的活動，將它們組合成一個完整的威脅事件，而不是四個孤立的警報。

第三種關聯是攻擊模式的關聯：基於對常見攻擊技術的理解，AWS Security Hub 能夠識別看似無關的發現實際上可能是同一攻擊活動的不同階段。例如，如果 GuardDuty 偵測到加密貨幣挖礦活動，同時 Inspector 發現受影響的執行個體有容器逃逸漏洞，AWS Security Hub 會推斷這可能是攻擊者利用容器漏洞獲得主機存取權限後部署挖礦軟體的攻擊鏈，並相應地提高整體風險評分。

暴露與威脅的具體區分

這種多維度的關聯分析產生了兩個關鍵成果：暴露 (Exposures) 和威脅 (Threats) 。暴露代表資源的脆弱性和錯誤配置，可能被攻擊者利用，但尚未觀察到主動攻擊跡象。例如，一個存在高危漏洞且安全群組配置不當的資料庫，即使目前沒有遭受攻擊，也構成嚴重的暴露風險。威脅則代表已經偵測到的惡意活動或攻擊跡象，需要立即調查和回應。AWS Security Hub 將所有相關發現組織在暴露或威脅之下，讓安全分析師能夠以業務風險的角度 (而非技術警報的角度) 理解問題的嚴重性。

近即時關聯還包括自動風險評分的更新。當新的發現出現時，AWS Security Hub 不僅會更新相關的暴露或威脅，還會重新計算風險評分。例如，一個原本被評為中等風險的配置問題，如果 GuardDuty 後續偵測到針對該資源的主動掃描活動，AWS Security Hub 會自動將風險等級提升為高危或緊急，因為攻擊者已經注意到這個弱點並可能即將發動攻擊。這種動態的風險評估確保團隊始終關注最迫切的威脅，而不是被靜態的嚴重性評分誤導。

1 年歷史趨勢：從即時防禦到長期策略

如果說近即時威脅關聯是 AWS Security Hub 的「眼睛」，讓團隊能夠看清當下的安全狀態，那麼歷史趨勢分析就是它的「記憶」，讓團隊能夠從過去學習並規劃未來。AWS Security Hub 正式發布版本引入的趨勢 (Trends) 功能，透過摘要儀表板 (Summary Dashboard) 提供長達 1 年的歷史資料，涵蓋發現 (findings) 和資源 (resources) 的變化趨勢。這種長期視角對於安全管理的成熟度提升至關重要——它使得資料驅動的決策、持續改進的文化、以及策略性的資源配置成為可能。

識別長期變化與異常模式

歷史趨勢的第一個價值是識別安全態勢的長期變化。透過追蹤暴露和威脅的數量變化，團隊可以客觀評估安全工作的成效。例如，如果過去六個月的趨勢圖顯示高危漏洞的數量持續下降，這證明漏洞管理流程的改進 (如更頻繁的掃描、更快的修補週期、或更好的映像檔管理) 正在產生效果。相反，如果配置錯誤的數量不斷增加，可能表示基礎設施即程式碼 (Infrastructure as Code) 的安全審查流程存在缺陷，需要加強自動化檢查或開發者訓練。這種基於資料的評估比主觀感受或個別案例更可靠，能夠支持更明智的投資決策。

第二個價值是發現週期性模式和異常。某些安全問題可能具有時間週期性——例如，在重大版本發布前後，由於配置變更頻繁，配置偏移的發現可能會激增；在年度預算週期結束時，由於資源採購加速，未修補系統的數量可能會增加。透過 1 年的歷史資料，AWS Security Hub 能夠幫助團隊識別這些模式，並提前規劃應對措施。同時，當某個指標突然偏離歷史趨勢時 (例如，正常情況下每天只有 5-10 個新威脅，突然某一週激增到 50 個)，這種異常本身就是一個重要訊號，可能代表新的攻擊活動、系統配置變更、或監控工具的誤報問題。

量化 KPI 與主動規劃

第三個價值是量化安全營運的關鍵績效指標 (KPI) 。AWS Security Hub 的歷史資料使得計算平均解決時間 (Mean Time to Resolution, MTTR)、暴露視窗 (從發現到修復的時間差)、以及復發率 (修復後再次出現的問題比例) 成為可能。這些 KPI 不僅能夠用於內部績效追蹤，也是向董事會或監管機構報告時的重要指標。例如，能夠展示「我們的高危漏洞平均修補時間從 30 天降低到 7 天」比單純說「我們加強了漏洞管理」更有說服力。

摘要儀表板 (Summary Dashboard) 提供了視覺化這些趨勢的工具。儀表板包含可自訂的小工具 (widgets)，每個小工具可以顯示不同類型的資料。你可以新增、移除和重新排列小工具，打造最符合你需求的視圖。例如，一個安全分析師可能希望看到暴露和威脅的即時數量、過去 24 小時的新發現、以及最高風險資源的清單。而資安長可能更關注過去三個月的趨勢線、不同類型問題的分布、以及與上季度的比較。AWS Security Hub 允許不同角色建立自己的儀表板視圖，確保每個人都能看到最相關的資訊。

趨勢資料還支援主動的容量規劃和資源配置。如果歷史資料顯示你的環境中 EC2 執行個體的數量持續增長，而漏洞掃描的覆蓋率卻沒有相應提升，這提示你需要擴展 Amazon Inspector 的掃描範圍或增加自動化修補的資源。如果某個特定類型的威脅 (例如異常 API 呼叫) 頻繁出現，可能需要投資於更先進的身份驗證機制或 API 閘道安全控制。歷史趨勢讓這些需求從反應式的「出了問題再處理」轉變為前瞻性的「預測需求並提前準備」。

Jira/ServiceNow 整合：打通安全到事件管理的最後一哩路

再強大的安全監控系統，如果無法有效地觸發修復行動，價值也會大打折扣。許多企業使用 Jira 管理開發和營運工作流程，或使用 ServiceNow 處理 IT 服務管理 (ITSM) 和事件回應。過去，當安全團隊在 AWS Security Hub 中發現問題時，他們需要手動在 Jira 或 ServiceNow 中建立工單，複製發現的詳細資訊、嚴重性評分、受影響資源、以及建議的修復步驟。這個手動過程不僅耗時，還容易出錯——可能遺漏關鍵資訊、錯誤分配優先級、或因為工作負載太大而延遲建立工單。

無縫銜接的工單系統

AWS Security Hub 的 Jira 和 ServiceNow 整合功能解決了這個「最後一哩路」的問題。當你在 AWS Security Hub 主控台查看一個發現時，你可以直接從介面中建立 Jira issue 或 ServiceNow incident。系統會自動填入發現的所有相關資訊：標題、詳細描述、嚴重性等級、受影響的資源 ID、AWS 帳戶、區域、以及建議的修復步驟。這些資訊會以結構化的方式呈現在工單中，確保接手處理的工程師能夠立即理解問題的背景和需要採取的行動。

這種整合的真正價值在於縮短從發現到行動的時間。在手動流程中，可能需要數小時甚至數天才能完成「安全團隊發現問題 → 建立工單 → 分配給相關團隊 → 開始修復」的循環。現在，這個過程可以在幾分鐘內完成。當 AWS Security Hub 識別出一個高風險暴露 (例如一個同時存在高危漏洞和不當網路暴露的資料庫)，安全分析師可以立即建立 Jira 工單分配給資料庫團隊，或建立 ServiceNow incident 觸發正式的事件回應流程。自動填入的詳細資訊減少了來回詢問和資訊補充的需要，讓修復工作能夠更快開始。

強化可追蹤性與自動化

整合還支援更好的可追蹤性和問責制。當安全發現轉化為工單後，它就進入了組織既有的工作追蹤系統，可以透過標準的專案管理流程進行追蹤——分配負責人、設定截止日期、追蹤進度、以及驗證完成。這避免了安全問題「發現後就被遺忘」的風險。而且，由於工單直接連結到 AWS Security Hub 的發現，修復團隊可以隨時點擊連結回到 Security Hub 查看最新狀態——例如，該漏洞是否已經被最新的掃描確認修復，或者是否有新的相關發現出現。

對於使用 ServiceNow 的組織，整合還能觸發更複雜的自動化工作流程。例如，當 AWS Security Hub 發現一個緊急威脅時，可以自動在 ServiceNow 中建立一個高優先級 incident，觸發值班輪替 (on-call rotation) 通知、自動升級流程、以及與其他 ITSM 流程 (如變更管理、資產管理) 的整合。這種深度整合使得安全營運能夠無縫嵌入到企業整體的 IT 營運框架中，而不是作為一個孤立的職能存在。

AWS Organizations 統一視圖：從單一帳戶到企業級安全營運

對於管理多個 AWS 帳戶的企業來說，安全可見性的挑戰會成倍增加。一個典型的企業可能有數十甚至數百個 AWS 帳戶——用於不同的業務單位、開發階段 (開發/測試/生產)、地理區域、或合規要求。如果安全團隊需要登入每個帳戶的 AWS Security Hub 來檢查安全狀態，這不僅極度耗時，更會導致可見性的缺口——可能某個較少關注的帳戶累積了大量安全問題卻無人察覺。

跨帳戶的集中化管理

AWS Security Hub 與 AWS Organizations 的整合提供了企業級的統一安全視圖。AWS Organizations 是 AWS 的多帳戶管理服務，允許你將所有 AWS 帳戶組織在一個階層結構中，並集中管理政策和設定。當你為整個 Organization 啟用 AWS Security Hub 時，系統會自動在所有成員帳戶中啟用 Security Hub，並將所有發現聚合到一個中央管理帳戶。

這種聚合提供了真正的企業級可見性。安全團隊可以在單一儀表板中查看整個組織的安全態勢——所有帳戶的暴露總數、最高風險的資源 (無論它們位於哪個帳戶)、以及跨帳戶的趨勢分析。例如，如果某個業務單位的帳戶在過去一個月內威脅數量激增，這會立即在組織層級的儀表板中凸顯出來，促使安全團隊深入調查。同時，摘要儀表板的可自訂小工具也支援組織層級的視圖——你可以建立顯示「所有生產環境帳戶的高危暴露」或「所有區域的 Macie 敏感資料發現」的小工具。

資源優先級與合規標準化

統一視圖還支援更有效的資源優先排序。當安全資源有限 (例如只有一個小型安全團隊服務整個企業) 時，必須做出策略性的選擇——先處理哪些問題、哪些可以延後。透過 AWS Organizations 整合的 AWS Security Hub，團隊可以基於跨帳戶的風險評分進行排序，確保首先處理對業務影響最大的問題，而不是被單一帳戶的局部視圖限制。例如，生產環境帳戶中的中等風險問題可能比開發環境帳戶中的高風險問題更優先處理，因為前者直接影響客戶服務。

組織層級的整合也簡化了合規報告和稽核。許多監管要求 (如 PCI DSS、HIPAA、或 GDPR) 需要證明整個企業的安全控制措施，而不僅是個別系統或帳戶。透過 AWS Security Hub 的組織視圖，合規團隊可以生成涵蓋所有帳戶的統一報告，展示安全態勢、已識別問題、以及修復狀態。這比從數十個帳戶分別匯出資料再手動合併要高效得多。而且，由於 AWS Security Hub 保留長達 1 年的歷史資料，稽核人員可以查看過去任何時間點的安全狀態，滿足「時點稽核」的要求。

啟用組織層級的 AWS Security Hub 也確保了一致的安全標準。當新的 AWS 帳戶加入組織時，Security Hub 會自動在這些新帳戶中啟用，並應用相同的安全標準和監控設定。這避免了「影子 IT」或「孤島帳戶」成為安全盲點——每個帳戶從創建的第一天起就納入統一的安全監控框架。

可自訂儀表板：讓每個團隊看到最重要的指標

雖然統一平台解決了資料分散的問題，但「一刀切」的儀表板可能無法滿足不同角色和團隊的特定需求。安全分析師關注的是即時威脅和需要調查的異常活動；DevOps 工程師想要看到他們負責的應用程式和資源的安全狀態；資安長需要高階的趨勢和 KPI 來評估整體安全策略；合規經理則專注於特定法規標準的符合程度。AWS Security Hub 的摘要儀表板透過可自訂小工具解決了這個多元需求的挑戰。

靈活配置的視覺化工具

小工具系統的核心設計理念是靈活性與簡易性的平衡。你可以透過拖放介面新增、移除和重新排列小工具，無需編寫任何程式碼或配置檔案。每個小工具專注於特定類型的資訊——例如，一個小工具可能顯示暴露和威脅的即時數量，另一個顯示過去 30 天的趨勢線，第三個列出最高風險的 10 個資源。你可以根據自己的工作流程安排這些小工具的位置和大小，創造最符合直覺的視覺佈局。

預先建置的小工具涵蓋了最常見的監控需求。例如，「暴露概覽」小工具顯示當前環境中的總暴露數量，按嚴重性分類，讓你一眼就能看出有多少個緊急、高危、中等和低風險的暴露。「威脅概覽」小工具以類似方式展示主動威脅。「資源覆蓋」小工具顯示有多少資源正在被 AWS Security Hub 監控，以及監控覆蓋的百分比——這對於確保沒有資源成為監控盲點很重要。「趨勢」小工具則提供時間序列圖，顯示發現和資源數量在過去幾週或幾個月的變化。

客製化過濾與深入分析

自訂能力還延伸到過濾和聚焦。每個小工具都可以應用過濾條件，只顯示符合特定標準的資料。例如，一個 DevOps 團隊可以建立一個儀表板，其中所有小工具都過濾為只顯示標記了特定應用程式標籤 (tag) 的資源。一個區域性的安全團隊可以建立只關注特定 AWS 區域的儀表板。一個合規團隊可以建立專注於特定合規標準 (如 PCI DSS 或 CIS AWS Foundations Benchmark) 發現的儀表板。這種過濾能力確保每個團隊只看到與他們相關的資訊，不會被不相關的資料淹沒。

儀表板的另一個強大功能是深入分析的流暢體驗。當你點擊儀表板上的任何數字或圖表元素時，AWS Security Hub 會帶你深入到對應的詳細視圖。例如，如果你在「暴露概覽」小工具中點擊「15 個高危暴露」，系統會顯示這 15 個暴露的完整清單，包括受影響的資源、相關的發現、以及建議的修復步驟。從清單中選擇一個特定暴露，你可以進一步查看該暴露的所有關聯發現——可能包括來自 Amazon GuardDuty 的威脅偵測、Amazon Inspector 的漏洞資訊、以及 Security Hub CSPM 的配置檢查結果。這種從高階概覽到詳細分析的無縫導航，讓調查工作變得高效且直觀。

為了支援不同的使用場景，AWS Security Hub 允許你建立多個儀表板並在它們之間快速切換。例如，你可以建立一個「日常監控」儀表板用於每天的例行檢查、一個「事件回應」儀表板專注於主動威脅和緊急暴露、一個「月度回顧」儀表板顯示長期趨勢和 KPI、以及一個「高階管理」儀表板用於向管理層報告。每個儀表板都可以儲存和共享，使得團隊成員能夠使用一致的視圖進行協作。

從分散到統一：重新定義雲端安全營運的新標準

AWS Security Hub 的正式發布標誌著雲端安全營運從「工具集合」到「統一平台」的典範轉移。透過將 Amazon GuardDuty、Amazon Inspector、Amazon Macie 和 Security Hub CSPM 的發現自動關聯並統一呈現，企業安全團隊不再需要在多個主控台之間切換或手動拼湊威脅拼圖。近即時的威脅關聯讓團隊能夠即時理解複雜攻擊的全貌，長達 1 年的歷史趨勢資料支援資料驅動的策略規劃，Jira 和 ServiceNow 整合打通了從發現到修復的最後一哩路，AWS Organizations 整合提供了真正的企業級可見性，而可自訂的儀表板則確保每個角色都能看到最相關的資訊。

當安全從被動的「發現問題」演進為主動的「預測風險」，當監控從孤立的工具操作升級為整合的威脅情報，當報告從手動的資料拼湊轉變為自動化的趨勢分析——這就是 AWS Security Hub 正在為雲端安全營運定義的新標準。對於那些仍在四個工具之間疲於奔命的安全團隊來說，統一平台不僅是效率的提升，更是安全成熟度的質變。

想了解如何為你的組織啟用 AWS Security Hub 並整合現有安全工具，或探索如何透過 AWS Organizations 建立企業級統一安全視圖？立即聯絡 AWS 台灣團隊，讓我們的解決方案架構師協助你打造更智慧、更主動的雲端安全營運框架。

參考資料

•    AWS Security Hub 產品頁面
•    AWS News Blog：AWS Security Hub 正式發布，提供近即時分析與風險優先排序
•    Amazon GuardDuty 產品頁面
•    AWS re:Invent 2025 重點發布

無法去拉斯維加斯親自體驗？歡迎報名參與 Best of AWS re:Invent (AWS 雲端科技發表會) 線上參與，一樣精彩！

本文章內容由「Amazon Web Services (AWS)」提供。