愛爾蘭銀行架構師 Ronan Hughes 針對 Apptio，給予了非常直接的肯定：「Apptio 的強大之處，在於能提供極其細緻的財務數據。這些數據直接勾勒出我們的發展藍圖該如何獲得資金支持，以及投資報酬率究竟如何 —— 帶來了巨大的效益。」

本文將深入剖析這家歐洲指標性金融機構，如何藉由 Apptio 的精細財務洞察理順複雜的 IT 架構，並在短時間內創造顯著的營運效益。

關於愛爾蘭銀行

愛爾蘭銀行是當地規模最大的零售與商業銀行。總部位於都柏林，擁有超過 8,000 名員工，年營收達 37 億歐元，全境市場佔有率高達 35%，對整體經濟具有舉足輕重的戰略地位。

身為全方位金融機構，其服務橫跨零售、企業金融、財資與國際金融。雖然具有區域性色彩，但他們面臨的數位轉型與 IT 膨脹挑戰，與全球大型跨國金融機構並無二致。

轉型契機：傳統管理模式瓶頸

前幾年，愛爾蘭銀行設定了一個核心目標：優化應用程式組合管理的實用性。面對日益複雜的業務與變幻莫測的科技環境，IT 主管們急需一套更有效的方法來控管全行的 IT 整體成本。

過去的痛點：流於感性爭辯

「過去我們在評估成本、規劃預算、追蹤實際支出，以及掌握技術生命週期與技術債時，都是用內部土法煉鋼的方式。」愛爾蘭銀行核心銀行與集團首席架構師 Ronan Hughes 坦言：「以前所有事情都是隨機處理的。相關利益關係人開會時，往往流於感性爭辯，而不是基於客觀事實。」

為了追求更客觀、透明且流程化的管理方式，團隊計劃在全企業落實應用程式組合管理。

而這項計劃的第一步，就是對全行的應用程式進行深度盤點，並計算出各自的總體擁有成本。這正是他們選擇導入 Apptio 的關鍵契機。

4 週快速完成概念驗證

在評估解決方案時，IT 團隊考察了多款產品。Hughes 表示：「Apptio 的態度非常積極，在短短 4 週內就完成了概念驗證，並展示了預期成效。當時使用基礎原始數據進行測試，結果非常驚艷，這正是我們尋求的轉型力量。」愛爾蘭銀行隨即決定採用 Apptio 並啟動導入。

落實應用的 5 大核心能力

經過數年的深耕與應用，愛爾蘭銀行透過 Apptio 成功啟動了應用程式組合管理的關鍵轉型：

一、用 Apptio 掌握 IT 總成本

Apptio 提供了橫向與縱向的總體擁有成本檢視視角，範圍涵蓋各項服務、應用程式、成本塔與價值流，讓 IT 團隊能以最直觀的方式掌握核心成本結構。

二、評估應用程式投資報酬率

Apptio 提供了每個應用程式組合的完整生命週期檢視，並將成本細分至軟體、硬體、人力、供應商等基礎類別。這讓高階主管能清楚掌握每款應用程式的具體開銷，進而精準調整未來的策略投資方向。

三、制定 5 年 IT 戰略藍圖

利用確切的成本、生命週期與投資數據來制定長期藍圖，並使之與企業的戰略目標保持一致。愛爾蘭銀行技術團隊藉此建立了 3 到 5 年的戰略投資藍圖，讓長期規劃變aAa得非常務實且具體。

四、優化供應商與合約授權

若要優化採購決策，企業必須清楚掌握各供應商在不同應用程式上的預算與實際支出。

「每當合約即將到期時，從 Apptio 獲取資訊變得非常容易，」Hughes 說：「我們可以輕鬆評估：目前花多少錢？回收了什麼效益？在談判新約時，我們該維持現狀、擴大還是縮減規模？甚至我們能直接抓出哪些系統根本不需要再續約。」

Apptio 協助愛爾蘭銀行將某款應用程式的授權數從 5,000 個大幅縮減至 400 個，為公司節省了巨額開銷。

五、汰換老舊系統精簡架構

愛爾蘭銀行利用 Apptio 成功找到了節省成本與淘汰老舊系統的機會。「Apptio 在第一年就幫助愛爾蘭銀行減少了 15% 的應用程式數量，有效降低整體 IT架構的複雜度。」

推薦閲讀：Starburst vs Trino：從開源核心到企業級效能，加速現代資料湖倉的分散式查詢

亮眼成績：首年省下 250 萬歐元

透過上述各項成本優化專案，Apptio 在第一年就幫助愛爾蘭銀行省下了 250 萬歐元（約新台幣 8,700 萬）。

在首年省下的總額中，約有 140 萬歐元是透過重新談判合約、降低合約支援費用、精簡供應商授權以及縮減相關基礎設施所達成。這項專案所建立的制度，也在後續幾年持續為全行帶來長期的成本優化效益。

延伸收穫：從 IT 控管延伸至商業決策

愛爾蘭銀行原本僅期望 Apptio 能落實 IT 管理，打底完成後，隨之而來的延伸效益遠超預期。當各部門看到成功的成本模型，原本處於次要地位的隱性效益便紛紛浮上檯面：

驅動跨部門商業策略

透過 Apptio 的數據分析，直接影響了全行的商業決策。

業務主管看到數據後會發現某些原本以為很貴的系統，其實幫公司賺了很多錢，應該加碼投資。相反地，以支付系統為例，由於某些系統只需在銀行營業時間內運作，銀行因此決定調降非營業時間的支援人力與時間，進而有效降低了營運成本。

降低整體營運風險

銀行必須定期向主管機關提交正式的風險報告並自行追蹤，而這些風險往往與成本掛鉤。如果能透過 Apptio 降低不必要的成本支出，就能同步優化整體的營運風險輪廓。

人力資源的戰略配置

透過數據，团队能清楚得知自有員工與第三方外包商分佈在哪裡、成本多高、產出了多少價值。這讓管理階層能更理性地討論人力應該部署在哪些核心業務，實現跨部門的戰略協調。

目前，除了 IT 部門，愛爾蘭銀行的財務與採購等跨部門團隊，也都已成為 Apptio 的核心用戶。

結語

愛爾蘭銀行最後獲得的成果遠不止於一開始的預期。Apptio 為全行的應用程式帶來了極其透明的可視性——從穩定性、可維護性、生命週期到具體成本一覽無遺，成功賦能了 IT 投資的戰略決策。

不論是財務、採購還是各個商業部門，都能在不同場景中運用 Apptio 的數據。Apptio 所帶來的精細財務洞察，徹底改變了企業規劃發展藍圖與評估投資報酬率的方式，無疑是數位轉型浪潮中不可或缺的關鍵利器。

想為您的企業優化 IT 成本結構、精準掌握每項應用程式的投資報酬率嗎？
身為 IBM Apptio 的專業合作夥伴，我們提供最符合在地企業需求的導入規劃與諮詢服務。歡迎隨時聯絡我們的專業團隊，或是 加入歐立威 Line 好友！讓我們協助您建構透明、高效的 IT 財務管理架構。

*本文內容整理自 IBM Apptio 官方公開資料，僅用於技術介紹與資訊分享。

*參考資料：Bank of Ireland Reduces IT Cost and Complexity Through Application Portfolio Management

機房處於封閉式網路環境，既要資安合規又想引進 AI 自動化維運？

在受限的內網環境中，當服務發生異常，工程師往往因為資料分散而耗時除錯，卻又受限於合規政策，無法將敏感的 Log 丟上雲端 AI 進行分析。

Elastic Observability 提供完整的全方位資料收集底座。在完全不連外網的純地端環境下，它能集中化儲存企業內部的 Log、Metrics 與 Traces，並直接作為後端平台，供本地端的 AI 代理人進行讀取與分析。

這個技術專題聚焦於「在地端落實 Agentic AI 智慧維運」的實務架構。我們將完整拆解從底層基礎架構到本地 LLM 的對接技術。在資料 100% 不外流的前提下，讓地端 AI Agent 自動關聯跨系統脈絡、解讀異常錯誤碼，大幅縮減故障根因分析（RCA）的時間

本活動將邀請 Elastic 原廠資深架構師 Jason，分享 Elastic 全地端可觀測性架構的建置步驟，協助企業告別人工撈 Log 的高成本排障，在私有雲內建立高合規的 AIOps 架構！

活動資訊

日期：2026.8.26 (三) 11:00 – 12:00

形式：線上

活動亮點

• 100% 地端架構建置： 在 Air-Gapped 封閉環境下，完成 Elastic 與本地 LLM 引擎對接。
• AI Agent 地端診斷： 本地 AI 自動關聯指標與日誌，免除雲端隱私風險。
• 企業級維運藍圖： 拆解地端資料流與 LLM 整合架構，落實 AIOps 轉型。

我們誠摯邀請您，一起來學習 Elastic 最新技術，掌握職場競爭力！

活動議程

本活動完全免費，誠摯邀請公司行業及政府單位的主管、IT 相關及專業技術人員踴躍報名參加！

若您不屬於上述類別人員，恕無法接受報名，敬請見諒，感謝您的理解與支持。

限時抽獎

只要報名成功就能抽 Elastic POLO T 一件（尺寸隨機）！大家把握機會！

每天被上萬條資安告警淹沒，卻分不清哪個才是真正的攻擊？

在傳統的 SOC 運作中，分析師常因為缺乏外部情報支援，只能在海量的日誌中大海撈針。

Elastic Security 是一套具備強大搜尋與分析能力的現代化資安平台。它能將企業內部的日誌數據，與全球的威脅情報進行高效率的自動化對齊，讓隱藏在暗處的惡意威脅無所遁形。

本次活動的核心，在於解決「情資進得來、系統卻跑不動」的痛點。我們將說明如何利用 Elastic 的高效能架構，將百萬級別的威脅指標與內部數據進行即時交叉比對，在不犧牲查詢速度的前提下，大幅精簡無效告警，真正釋放 SOC 團隊的實務效能 

本場活動將完整呈現 Elastic Security 的應用方式，協助您擺脫無效加班，精準升級企業的資安防禦力！

活動資訊

日期：2026.7.29 (三) 11:00 – 12:00

形式：線上

活動亮點

• 自動整合威脅情資： 高效匯入多元外部情資，自動識別惡意 IP 與檔案指標。
• 告警降噪提升效能： 自動補全情境資訊並過濾雜訊，縮短威脅應變時間。
• 現代化 SOC 營運規劃： 分享實務情資整合與調度流程，主動防範潛在風險。

我們誠摯邀請您，學習 Elastic 最新技術，掌握職場競爭力！

活動議程

本活動完全免費，誠摯邀請公司行業及政府單位的主管、IT 相關及專業技術人員踴躍報名參加！

若您不屬於上述類別人員，恕無法接受報名，敬請見諒，感謝您的理解與支持。

限時抽獎

報名成功即可抽 Elastic 筆記本（限量 2 個）！歡迎對 Elastic 有興趣的朋友報名！

要防止 AI 濫用機密資料，關鍵不在於引進更複雜的加密理論，而是透過現代化管理工具，將持續掃描、動態憑證與身分存取控制徹底自動化。

推薦閲讀：HashiCorp Vault – 零信任，每件事都要驗證身分與授權

AI 攻擊的 18 分鐘時間線

當惡意份子利用自主化 AI 攻擊工具時，傳統「被動式」的防禦模型就會崩解：

• T+0 分鐘： AI 在公開儲存庫（Repository）中發現 AWS 存取金鑰。
• T+5 分鐘： 自動驗證憑證、盤點 S3 儲存桶，找出權限過大的 IAM 政策。
• T+12 分鐘： 轉移至 EC2 中介資料服務（Metadata Service），萃取更廣泛的系統憑證。
• T+18 分鐘： 尋獲資料庫憑證，建立持續性存取權限，開始外洩資料。

當 AI 能以分鐘為單位串聯零日漏洞時，防禦者不能再依賴人工作業，必須徹底消滅環境中的靜態目標，直接切斷 AI 攻擊所需的燃料。

既有架構的三大破口

舊式防禦失效的核心原因在於人工作業的時間差。傳統事件響應的控制與驗證高度依賴人工決策，即使是頂尖 SOC 團隊也需要數小時處理，但 AI 攻擊在幾分鐘內即完成任務。

其次是靜態憑證的架構漏洞。長期不變的憑證散落在環境變數與設定檔中，AI 不需要破解加密，找到合法憑證就能直接入侵。

最後則是邊界防禦的盲目信任，一旦進入內網，AI 攻擊便能利用服務間的隱性信任橫向移動，防火牆根本無法分辨流量是來自合法系統，還是拿到遭竊憑證的 AI。

零信任三大原則

原則一、持續掃描靜態目標

AI 模型的情報能力來自它所讀取的資訊。企業應透過源碼掃描工具（如 Vault Radar）執行深度歷史紀錄掃描，並搭配可用性檢查與亂度分析，精準排除測試字串、找出真正活躍的隱藏金鑰。

同時必須將防禦左移（Shift-Left），在開發者 IDE 與 GitHub Pull Request 階段建立攔截機制，在不管理的 Token 進入遠端儲存庫前直接阻斷。此外，系統應自動標記並清除設定檔中暴露的個人識別資料（PII）與內部伺服器名稱，防止其成為 AI 下一步攻擊的跳板。

原則二、啟用動態憑證

根除憑證獵人最徹底的方法，就是讓伺服器上無機密可偷。透過機密管理系統（如 Vault），針對雲端環境（AWS, Azure, GCP）、各類資料庫與 SSH 金鑰，自動生成限時且隨用隨丟的「動態憑證（Dynamic Secrets）」。

即時動態機密

當應用程式遭遇遠端代碼執行（RCE）攻擊時，環境中因為沒有任何靜態密碼，等到 AI 處理完檔案系統準備橫向轉移時，合法系統剛才使用的暫時憑證早已過期。

原則三、密碼學身分驗證

零信任架構會將安全邊界從「網路拓撲」轉移到「密碼學身分」。所有應用程式存取機密前，必須提示可驗證的 Token（如 OIDC、JWT、Kubernetes Service Accounts）。

透過嚴格的身分驗證與行為隔離政策，限制存取的 CIDR 區塊與時間視窗，確保即使 AI 找到通往敏感 API 的網路路徑，也無法移地濫用遭竊的機器環境。

維運流程的自動化

手動變更密碼、每季定期更換憑證的維運步調已無法適應現狀。針對不支援動態憑證的舊基礎架構，企業應透過集中化排程與指數退避重試機制，實現高頻率自動變更，大幅縮短憑證被截獲後的有效窗口。

一旦入侵偵測系統（IDS）監測到異常，資安團隊必須能透過單一 API 呼叫，立刻執行全球快速撤銷（Revocation），瞬間切斷該身分綁定的所有活躍憑證，在跨雲環境中實時阻斷攻擊。

結論

AI 工具大幅加速了軟體漏洞的分析與利用速度，防禦藍圖的本質未變，但資安的「容錯率」已經歸零。手動修復與人工判斷的時間差已成為最大問題。企業必須將行之有年的防禦原則 —— 消滅靜態憑證、實施基於身分的存取控制、將防禦左移至開發階段 —— 透過現代化工具轉化為不間斷的自動化防線。

要將這些原則落實到維運流程，IBM HashiCorp Vault 與 Vault Radar 提供了關鍵的技術支撐。

透過 Vault Radar 在開發階段進行持續性的源碼掃描，能率先消滅 codebase 中的靜態殭屍憑證；再搭配 Vault 的動態憑證與密碼學身分驗證，則能徹底限縮系統受駭時的損害範圍。面對以機器速度演進的 AI 威脅，用自動化工具取代人工作業，是確保企業架構維持韌性的必要維運投資。

本文翻譯自：With great AI power comes the need for zero trust responsibility

想瞭解更多？歡迎聯絡我們，或是 加入歐立威 Line 好友！

這項指引代表台灣金融業必須開始面對後量子密碼（Post-Quantum Cryptography, PQC）的轉型挑戰。量子運算技術進步神速，現行的 RSA、ECC 等非對稱加密演算法未來隨時可能被破解，這將直接衝擊網路交易、電子簽章、身分驗證及 TLS/SSL 的通訊安全。

金融機構屬於高度監理產業，需要提早強化加密敏捷性（Crypto Agility），才能擋下量子破密風險，並符合金管會對內控、稽核與資安治理的要求。

我們在上一篇文章《HashiCorp Vault 如何解決 SSL/TLS 憑證有效期縮短的挑戰》中，聊過憑證生命週期縮短帶來的維運壓力；接著在《從 Let’s Encrypt 憑證政策更新，看企業 mTLS 與機器身份治理》中，也探討了 mTLS 從原本的附帶功能變成需要明確治理的機器身份管理議題。

這次金管會推動的 PQC 遷移指引，剛好跟這些資安趨勢完全對上 —— 憑證與加密管理不能再當作零散的 IT 雜事來做，而是必須走向制度化、自動化，且具備稽核追蹤能力的治理級議題。

為什麼金融業急需 PQC 遷移？

量子電腦一旦成熟，將能以指數級速度破解現行公鑰加密系統。這不僅會威脅金融機構的核心業務（例如線上交易、客戶個資保護、跨機構清算），還會放大供應鏈與生態系的連帶風險。

金管會指引參考了 NIST、G7、FS-ISAC 等國際標準，訂出了三階段推動時程：

• 短期（2026–2027 年）：建立治理架構、完成密碼技術盤點（Crypto BOM）、強化加密敏捷性基 礎。 
• 中期（2027–2029 年）：試辦驗證、基礎設施升級、跨機構共同測試。 
• 中長期（至 2035 年）：依風險排序完成高優先系統遷移，全面替換量子脆弱演算法。 

對金融業來說，實務上的主要挑戰有這四點：

• 密碼資產盤點太複雜： 加密點散落各處，橫跨負載平衡器、API 閘道、微服務、VPN 和資料庫憑證，數量動輒幾千個。
• 人工管理沒辦法長久： 面對頻繁的密鑰輪替、混合模式（Hybrid Cryptography）測試和供應鏈協作，單靠人工很容易出錯，進而導致服務中斷或合規缺失。
• 機器身份治理要延伸： mTLS、客戶端憑證都要明確定義用途、生命週期和稽核機制，這跟之前 Let’s Encrypt 的政策調整邏輯一樣。
• 加密敏捷性不可或缺： 系統必須有能力快速切換演算法，不能再把特定的加密函式直接寫死（Hard-coded）在程式碼裡面。

這些痛點跟我們之前討論的憑證縮短、mTLS 治理，本質上都是同一個問題 —— 核心關鍵都在於「怎麼把加密與身份管理從人工作業，轉型為可自動化、可治理、可擴充的平台機制」。

IBM HashiCorp Vault：金融業 PQC 遷移的自動化與治理核心平台

作為業界領先的機密管理與身份平台，IBM HashiCorp Vault 非常適合拿來協助金融機構應對後量子遷移。它的核心優勢就是提供加密敏捷性與自動化生命週期管理，讓企業集中治理憑證、金鑰與機器身份，同時支援混合加密模式與動態更新。

Vault 在 PQC 遷移中的關鍵應用：

一、集中管理與盤點資產

Vault 提供統一的平台來盤點並管理所有加密資產（包含 TLS 憑證、API 金鑰、資料庫憑證等）。搭配 PKI Secrets Engine，可以自動追蹤使用位置、演算法類型和風險等級，幫企業快速建置金管會要求的 Crypto BOM。

二、自動化憑證與金鑰輪替

就像應對 47 天短效憑證的做法一樣，Vault 可以和內外部 CA（包含未來支援 PQC 的 CA）串接，透過 ACME 協議或 API 做到動態簽發、輪替與撤銷。另外也支援 Hybrid Cryptography（傳統與 PQC 演算法並行），不怕遷移期間出現系統不相容的問題。

三、機器身份與 mTLS 治理

延續之前的討論，Vault 強化了機器身份管理，讓 mTLS 客戶端與伺服器端的憑證能明確宣告用途、設定短有效期限，並提供完整的稽核軌跡，滿足金融業內控、內稽、PCI DSS 與個資法等合規要求。

四、 動態密鑰（Dynamic Secrets）與加密敏捷性 

Vault 可以做到「按需生成」短效憑證或金鑰，用完就失效，把暴露風險降到最低。結合 Terraform、Kubernetes 等基礎設施即程式碼（IaC）工具後，還能自動把 PQC 相容設定部署到 F5、Nginx、微服務或雲端環境，輕鬆支援多雲與混合架構。

五、完整稽核與風險排序

透過完整的活動記錄和儀表板，金融機構可以按照風險矩陣優先遷移高風險系統，完全符合金管會指引提倡的「風險導向原則」。

金融機構實際導入情境

以一家採用雲地整合（混合雲）架構的金融機構為例，內部需要管理幾百個負載平衡器、API 閘道和 Kubernetes 微服務。遇到 PQC 遷移時，如果還用人工處理，不只盤點大費周章，輪替過程中也很容易弄斷服務或漏掉稽核。

導入 IBM HashiCorp Vault 後的具體改變：

• 自動產出加密資產清冊並完成風險評估。
• 透過 PKI 引擎與政策引擎，實現 Hybrid PQC 憑證的自動化輪替。
• 集中治理 mTLS 機器身份，確保跟證交所、聯卡中心這些外部單位的互通性測試順利。
• 大幅減輕 IT 的維運負擔，讓團隊可以專注在業務創新和高階的風險控管上。

這跟國內外大型企業的成功案例精神是一樣的，Vault 把機密與加密管理收攏成單一可信平台，既提升效率又降低成本。

如何啟動 Vault 輔助的 PQC 遷移計畫 

我們協助金融與製造業客戶導入 HashiCorp Vault 的步驟通常包含：

1. 現況評估： 盤點目前的加密使用點，找出具量子漏洞的資產，跟金管會的指引做對齊。
2. 架構設計： 規劃 Vault 的高可用性（HA）部署、PKI 引擎與 PQC 相容方案的整合。
3. 試辦驗證： 先在測試環境驗證 Hybrid 模式跟自動化流程。
4. 全面導入與培訓： 結合 IaC 實現自動化部署，並提供團隊教育訓練與後續的技術支援。

結語：提前布局量子安全，轉化挑戰為競爭優勢 

金管會發布「金融業後量子密碼遷移參考指引」，再度呼應了憑證短效化與 mTLS 治理的趨勢，也證明加密管理走向平台化、自動化、可治理是必然的路。

IBM HashiCorp Vault 不只能幫金融機構應付 2035 年前的全面遷移，還可以一併解決之前討論過的 SSL/TLS 與機器身份挑戰，讓企業在量子時代兼顧資安韌性與營運效率。

這不是應付單一政策的臨時做法，而是建立長期加密敏捷性的戰略布局。

想瞭解更多？歡迎聯絡我們，或是 加入歐立威 Line 好友！ 一起探討 IBM HashiCorp Vault 如何協助您的 PQC 轉型與整體資安治理！ 

公部門與大型單位的資安維運正處於關鍵轉折點。現有的資安工具大多無法應付這種攻擊速度，而維運團隊也正因預算限制、編制不足與日益繁重的防禦需求而面臨極限。對抗 AI 網路威脅的有效解方，就是導入 AI 防禦機制。

這正是公部門紛紛評估建置 AI 導向資安維運中心（SOC）的原因。以下將深入探討其核心架構，以及它如何解決大型單位的資安痛點。

什麼是 Agentic SOC？

Agentic SOC（代理型資安維運中心）是指透過具備自主推論能力的 AI Agent 執行後台自動化工作流程，藉此協助分析人員加速應變的新世代架構。

這種架構的目標並非實現「全自動化」或完全取代人工，而是確保第一線資安人員不會被 AI 攻擊的速度擊垮。在資安維運中，人工決策與透明度依然不可或缺。

Elastic Security 平台採用「人類主導」的設計思維：

• AI Agent 負責執行： 處理從資料回溯、威脅分析到初步應變的完整生命週期。
• 專家負責把關： 分析最終覆核、驗證與授權。
• 決策軌跡透明： AI 的每項推理與決策皆有完整紀錄，方便人工審查準確性。

接下來，我們來看 Agentic SOC 宏觀上如何解決傳統資安維運的兩大核心痛點：架構破碎化與回應速度慢。

痛點一：消除工具破碎化帶來的隱性成本

公部門與大型單位因業務、法規與機密等級不同，各部門系統各自獨立，甚至需要在完全實體隔離的環境中運作，這種架構破碎化反而成為應對快速 AI 威脅的阻礙。

研究顯示，高達 66% 的 SOC 團隊每週必須花費整整一天的工時，手動跨工具整合不同系統的資料。這種破碎化衍生出許多資安風險與成本：

• 依設備數量計價的授權模式，迫使單位因預算考量而放棄部分系統的日誌收集。
• 外掛式的自動化工具（Playbook）容易在關鍵資安事件發生時失效。
• 封閉式的 AI 方案無法看透其推論邏輯，資安團隊必須先耗費時間釐清工具脈絡，才能開始著手應變。

Elastic 的解決方案：
Elastic 透過單一平台整合 SIEM、XDR 與原生自動化技術，消除傳統的「端點稅（按設備計價的負擔）」，讓資安策略回歸風險導向而非授權預算。其開放式架構能串聯現有生態系，即使在隔離環境中，也能維持跨環境的資料能見度。

痛點二：大幅縮短資安事件回應時間

資安團隊普遍面臨嚴重的警報疲勞，而當前黑客從初步入侵到橫向移動的時間已縮短至平均 29 分鐘，傳統人工回應的速度完全無法跟上。

在破碎的工具環境中，缺乏情境脈絡的 AI 偵測只會產生大量誤報，讓資源有限的維運團隊更加疲於奔命。長期的過勞容易導致防禦出現破口，增加遭到入侵的風險。

Elastic 的解決方案：
Elastic 採用資料網格（Data Mesh）架構，無需將資料集中搬移，即可即時跨雲端、混合雲及實體隔離環境進行關聯分析。每條資安警報皆會自動生成脈絡敘述，將端點行為、身分變更、網路流量與雲端日誌串聯，協助小團隊以機器般的速度進行精準決策。

公部門與大型機構開始規模化導入

各國政府正積極強化國家級的資安韌性框架，導入 AI 導向的資安防禦已成為主流趨勢。

2026 年 6 月美國白宮發布的最新 AI 行政命令中，明確要求加強 AI 創新與資安防禦。政府單位必須在升級技術基礎架構的同時，管控 AI 帶來的全新風險，並確保營運韌性與透明度。

當資安決策逐步委派給 AI Agent 時，五眼聯盟（美、英、加、澳、紐）發布的聯合指引特別強調「維運可視性」：人類必須能理解 AI Agent 做了什麼、為什麼做，以及使用者的真實意圖。

目前，許多指標型機構已陸續大規模採用 Elastic Security：

• 結合 Google 分佈式雲端（GDC）： 為完全不連網的實體隔離環境提供 embedded 安全防護層，讓敏感機密業務也能享有 Agentic SOC 的主動防禦。
• 美國聯邦民事機構： Elastic 已正式成為美國 CISA 近期推出「SIEM 即服務（SIEMaaS）」的核心 AI 資安平台。

結論：用單一平台化解防禦破口

Elastic 是專為化解資安破口而設計的 Agentic 資安維運平台，旨在減輕維運團隊在時間、預算與專注力上的壓力。

導入這套架構能為組織的防禦策略帶來以下效益：

• 強化能見度並兼顧合規： 開放、彈性的架構可直接在資料源頭串聯跨環境資訊，即時識別關鍵風險，符合嚴格的本地隱私與法規法條。
• 阻斷快速移動的威脅： 將資安專用的 AI Agent 內嵌於工作流程中，將「偵測到應變」的時間壓縮至秒級，提供即時情境脈絡以加速決策。
• 建立可信賴的 AI 機制： 完整呈現 AI 的每項行動與推論邏輯，讓分析人員掌握所有輸入與輸出，確保決策透明。
• 精準配置有限的維運資源： 自動化技術能消除手動整合資料與篩選無效警報的耗時流程，讓資安人員能專注於戰略規劃與 AI 模型的微調。
• 交付可驗證的防禦成效： Elastic Security 實證可減少組織內高達 90% 的資安事件。在 2025 年 AV-Comparatives 的獨立評測中，Elastic 也是唯一在真實世界與惡意軟體測試中全年維持 100% 防護率的品牌。

總結來說，面對 AI 時代更具速度與威脅性的網路攻擊，傳統被動且分散的工具堆疊已無法有效因應。透過 Elastic 的預防優先架構，公部門與企業能在兼顧高透明度與法規合規的前提下，真正落實兼具效率與安全的新世代自動化資安防禦。

本文翻譯自：Agentic SOCs: The public sector’s new AI cybersecurity defense

想了解更多資訊，歡迎聯絡我們，或是 加入歐立威 Line 好友！

這時候你該怎麼做？

傳統的作法是先將這些資料經歷複雜的 ETL（擷取、轉換、載入）流程，通通搬移並集中到同一個地方，然後才能開始跑分析。

簡單來說，Query Federation（聯合查詢）是一種跨資料庫的資料虛擬化技術。只要撰寫單一條 SQL 指令，就能直接橫跨、串聯多個完全不同的資料系統進行運算，就像這些資料原本就存在同一個資料庫一樣。

透過這種「資料留在原地，讓運算過去」的方式，Query Federation 改變了傳統必須搬移資料的分析做法，徹底翻轉現代資料分析與 AI 工作負載的遊戲規則。

改變資料架構：從資料搬移走向邏輯虛擬層

聯合查詢帶來的影響很直接。這不只是一個方便的查詢功能，更是現代資料分析與 AI 工作負載在架構思維上的根本轉變。

傳統架構一味追求資料集中化，卻換來高昂的儲存成本與漫長的資料等待期。

而聯合查詢能直接從不同的資料源查詢資料，完全不需要複製、搬移。這等於是在既有的資料生態系上，直接建立一層橫跨企業整體的「虛擬資料層」。

支援多元資料環境

這項技術的核心價值，在於能直接融入企業現有的 IT 環境。聯合查詢並不是要汰換掉既有的 IT 資產，而是與現有的資料湖、資料倉儲、以及線上交易系統協同運作。

當企業需要更嚴格的資料治理或資料落地時，可以將這種聯合查詢與 Apache Iceberg 等開放表格式結合。如此一來，查詢結果不僅能實體化儲存，還能獲得 Iceberg 標配的 Time Travel（時間旅行/版本回溯）與版本控制能力。

在開發 AI 應用時，架構師需要迅速從多個系統中抓取資料來組裝訓練資料集。透過 Starburst 的優化加速，團隊可以快速完成原型設計，再將最終的資料集落進 Iceberg，確保每一次模型訓練的資料都具備完全的可複製性。

傳統聯合查詢面臨的挑戰

在實務落地時，如果缺乏企業級的工具支援，傳統的聯合查詢往往會伴隨以下真實挑戰：

• 效能難以預測： 當你跨越不同算力、不同規格的資料系統進行合併運算時，查詢速度往往受限於最慢的資料庫。
• 安全控管複雜化： 資料源五花八門，如何在不搬移資料的前提下，維持各系統一致的權限、去識別化與資料治理原則？
• 維運成本失控： 管理跨系統的連線、資料庫綱要變更以及快取重新整理，常讓 IT 維運團隊疲於奔命。

這些架構上的漏洞，直接導致的後果就是專案時程延宕、雲端費用增加，以及業務端遲遲拿不到跨系統洞察的挫折感。因此，選擇對的企業級平台來落實聯合查詢，比技術概念本身更重要。

為什麼現代資料架構需要聯合查詢？

隨著 SaaS 服務、雲端平台與特定專門資料庫（如向量資料庫、NoSQL）的成長，企業的核心資產註定會走向碎片化。

一個典型的台灣企業，其客戶資料可能在 Salesforce、財務紀錄在 ERP、點擊流在 Amazon S3，而即時營運指標則在 PostgreSQL 裡。分析的本質需要綜觀全局，但建立複雜的 ETL 管線去集中資料，代價太高了。

這正是聯合查詢展現價值的時刻。與其大費周章建立複雜的 ETL 資料管道，不如透過跨目錄的聯合查詢，在幾小時內搞定跨系統的分析需求。同時，因為不需等待批次載入，資料隨時保持最新，更能省下在各處複製、堆疊資料的隱性儲存成本。

AI 對彈性資料存取的需求

AI 與機器學習的崛起，讓聯合查詢變得更加關鍵。訓練模型通常需要從數十個來源組裝資料集，而每個來源的更新頻率和存取模式都不同。

與其為每種組合建立脆弱、容易斷掉的資料管道，資料團隊大可利用聯合查詢進行快速探索與原型設計，接著將最終的資料集實體化到 Iceberg 中，以便進行具備可複製性的模型訓練。

現代 AI 與分析解決方案越來越依賴這種彈性，直接存取多元資料源，免除傳統資料搬移模式所帶來的龐大維運開銷。

推薦閲讀：Starburst 成功案例｜首家支援 NVIDIA Vera：全面加速企業級 AI 效能

法規合規與分散式架構的結合

在受到高度監管的產業，聯合查詢更是不容忽視的剛需。資料落地與合規要求（例如資料主權）是沒有妥協空間的。

許多銀行與資本市場企業正是利用聯合查詢技術，在資料不搬移的前提下，橫跨不同邊界與業務單位進行全局分析，同時將敏感資訊完好地保留在符合法規的特定據點。這種架構讓企業既能滿足當地的資料治理與合規要求，又能搞定跨系統的全局洞察。

Starburst ：如何導入聯合查詢？

要在企業中成功導入聯合查詢，關鍵在於擁有清晰的架構策略與務實的預期。我們建議企業應從高價值的特定情境切入，而非盲目地一開始就想串聯所有資料。

一、決策初期切入的資料源

最佳的起手式，是選擇具有互補優勢且合併後能帶來直接商業價值的系統。常見的組合是：「前端快速運行的線上交易資料庫（查當前最新狀態）」+「後端儲存歷史趨勢的資料湖（查歷史軌跡）」。這種組合讓你的分析既能看到現在的狀態，也能了解過去的演進，且完全不需要進行複雜的資料同步。

透過 Starburst connector ecosystem，不論是傳統關聯式資料庫還是現代雲端服務都能輕鬆介接。在架構設計時，必須深入了解每個連接器的「算力下推」能力、驗證機制以及寫入限制，才能最大化查詢效益。

實務佈署考量： 了解 Starburst 企業版與開源 Trino 之間的架構差異，能幫你根據自身的維運能力與企業級架構需求，做出正確的平台選擇。

二、規劃實體化策略

純粹的虛擬化聯合查詢非常適合用於科學家的探索性分析。但如果面對的是高頻率的正式生產環境，為了穩定效能與控管成本，適度地實體化是必須的。

我們建議及早規劃實體化策略，利用 CREATE TABLE AS SELECT 進行初始載入，並透過實體化檢視表（Materialized Views）搭配排程重新整理來維持資料同步。將目標格式設定為 Apache Iceberg，能讓 Lakehouse 架構同時兼顧靈活性與嚴格的資料治理。

三、導入高階效能優化模式

Starburst 之所以能跟開源的 Trino / Presto 拉開差距，關鍵就在於其底層的優化機制：

• 動態過濾： 在進行跨庫合併運算時，系統會自動在資料源端過濾掉不需要的資料，大幅減少網路傳輸量的頻寬消耗（系統預設開啟）。
• 完全查詢穿透（Full Query Passthrough）： 遇到複雜的特定原生語法時，能將整段 SELECT 語句直接外包給源端資料庫執行，充分利用源端本地算力。
• 快取服務（Starburst Cache Service）： 自動將頻繁掃描的資料表重新導向至實體化複本，讓聯合查詢同時擁有資料倉儲等級的速度。

對於正在開發資料驅動應用程式的團隊來說，這些效能優化模式是打造高回應速度、橫跨多資料源應用的關鍵底層。

四、建立一體化的安全與資安治理模型

分散式架構的資安不能只靠拼湊式的片段防護。Starburst 內建的基於角色存取控制（RBAC）、資料行遮罩與資料列過濾提供了細粒度的權限控管。

同時，透過整合 Apache Ranger，企業能在單一中央介面管理所有異質資料庫的資安政策。對於已有既定資料治理基礎架構的企業，標籤化政策能在你加入新的聯合查詢來源時維持一致性。提早佈局資安模型，絕對比事後補強來得更安全且省時！

五、持續監控與優化

成功的聯合查詢架構需要持續關注效能、成本與資料品質。利用資料血緣追蹤來掌握聯合查詢資料集的前後端依賴關係；持續監控查詢模式，藉此辨識哪些查詢適合進行實體化或進一步的優化。

針對實體化結果，必須落實正確的資料表維護程序：包含資料緊實化、快照過期處理以及統計資訊收集。這些維運細節，決定了聯合查詢策略究竟能擴展到企業級規模，還是淪為 IT 團隊的維運泥潭。

結語：將技術轉化為企業的策略資產

無論你是選擇 Starburst Galaxy 來享受完全託管的雲端體驗，還是佈署 Starburst Enterprise 來保留地端與混合雲的絕對主權，核心目標都在於極大化企業的資料流速。

在現代商業競爭中，跑得最快的企業，往往不是擁有最多資料的公司，而是能最快把分散資料變成決策依據的公司。聯合查詢不只是一個技術功能，它是加速傳統資料分析與次世代 AI 應用的策略性能力。投入對的工具、建立清晰的資料治理模式，這項技術將成為企業資料轉型的推手。

本文翻譯自：What is Query Federation? 

想了解更多資訊，歡迎聯絡我們，或是 加入歐立威 Line 好友！

 跨多個 Data Lake 與資料庫查詢時，常因 Connector 效能與語法不相容而卡關？

Trino（前身為 PrestoSQL）是現代數據架構中，解決跨源聯邦查詢（Federated Query）的黃金標準。然而，當企業資料量與併發需求達到規模化，開源版本在效能調校、安全管控與叢集維護上，帶來龐大隱形成本。

Starburst 由 Trino 創辦團隊打造，在承襲核心 MPP 架構的同時，建構出「跨雲無縫、安全可治理」的企業級 Lakehouse 平台。

Starburst 不僅優化了 Trino 查詢引擎、提供 50 多種商業級連接器，更能將分散的數據整合至以 Iceberg 為基礎的開放架構，無痛接軌 BI 分析與 AI 運算。

本場活動將深入拆解 Trino 與 Starburst 的共同架構優勢，並全方位對比開源與企業級產品的關鍵差異，協助你評估最適合企業的數據查詢策略！

活動資訊

日期：2026.7.15 (三) 11:00 – 12:00

形式：線上

活動亮點

 打破資料孤島： 承襲 Trino 的 MPP 架構，實現「不搬動資料」的跨源秒級查詢。
 Starburst 效能與安全升級： 內建進階快取、成本優化器，並補足企業級權限管控（RBAC/ABAC）。
 開源 vs. 商業決策指南： 釐清開源自建與 Starburst 的功能分水嶺，精準評估落地指標。

我們誠摯邀請您，一同深入學習 Starburst 最新技術，掌握職場競爭力！

 活動議程

本活動完全免費，誠摯邀請公司行業及政府單位的主管、IT 相關及專業技術人員踴躍報名參加！

若您不屬於上述類別人員，恕無法接受報名，敬請見諒，感謝您的理解與支持。

PostgreSQL 規格已經升到最高，但跑數據分析還是很卡？

當資料量成長到數十億列，分析型查詢（OLAP）讓單機資料庫不堪負荷——這時你需要的不是更貴的硬體，而是能橫向擴展的資料倉儲。

WarehousePG 是一套開源、以 PostgreSQL 為核心的企業級資料倉儲。它承襲開源 Greenplum、由 EDB 接續發展，透過 MPP（大規模平行處理）架構把海量資料分散到多個節點平行運算，讓你在熟悉的 PostgreSQL 生態裡，直接擁有 PB 級的分析能力。

本場活動聚焦在 WarehousePG 的產品介紹與核心功能，帶你快速掌握它如何賦能企業資料分析 —— 我們將跳過繁複的底層細節，直擊「核心功能與實際應用的痛點解方」。

活動資訊

日期：2026.7.1 (三) 11:00 – 12:00

形式：線上

活動亮點

 產品定位： 一次搞懂 WarehousePG 是什麼、適合哪些場景。
 PostgreSQL 生態無痛接軌： 熟悉的 SQL、既有 BI 工具高度相容，學習與導入成本低。  
 MPP 分散式架構解密： 拆解協調與運算節點機制，理解如何做到秒級響應。

我們誠摯邀請您，一同深入學習 Postgresql 最新技術，掌握職場競爭力！

 活動議程

本活動完全免費，誠摯邀請公司行業及政府單位的主管、IT 相關及專業技術人員踴躍報名參加！

若您不屬於上述類別人員，恕無法接受報名，敬請見諒，感謝您的理解與支持。

如果要求 LLM 針對正式環境資料庫寫 SQL，寫出來的結構通常看起來正確，但可能引用了不存在的資料表、半年前就改名的欄位，或憑空捏造 JOIN 條件。這會導致查詢直接失敗，甚至面臨更糟情況：指令成功執行，卻回傳了錯誤的數據。

為了解決 LLM 亂寫 SQL 的問題，目前的作法是透過 MCP，利用 PostgreSQL 的原生架構來確保查詢的準確性。

技術背景與初步嘗試

在 2024 年初還沒有 MCP 或 AI Agent 的概念。為了讓聊天機器人能串接 API 取得即時資料，當時通常採用比較拼湊的流程：

1. 把 OpenAPI spec 餵給 LLM。
2. 要求 LLM 只能回傳 curl 指令。
3. 透過 Go 函式去執行這個 curl 指令。
4. 把執行的結果再丟回給 LLM，讓它轉換成一般人看得懂的回答。

User: "What's the CPU usage and total DB connections right now?"
 -> LLM + API Spec -> curl -X GET https://portal.curiousone.in/api/v1/metrics?names=cpu,db_conn
 -> execute() -> { cpu: 72%, conn: 84 }
 -> LLM: "CPU is at 72% and there are 84 active DB connections."

這做法雖然可行，但完全無法擴充。每增加一個新資料來源，就得寫一套新的 parser；而且 Prompt 工程脆弱，必須針對每一種 spec 或 schema 重新調整。

後來也發現不少團隊在開發這類應用時，也都面臨一模一樣的挑戰。直到 Anthropic 釋出 MCP作為開放標準，問題才得到解決。

為何 LLM 總是寫錯 SQL？

LLM 其實看得懂 SQL 語法，也能寫出包含 CTE、子查詢的複雜指令。但它無法得知資料表名稱、欄位名稱或關聯性，只能單純根據訓練資料的盲猜。

對比如下：

LLM 猜測資料表叫 users，但實際上是 app_customers；猜測欄位叫 name，但實際上是 full_name；猜測外鍵（Foreign Key）是 o.user_id，但實際上是 o.customer_id。它的每一次猜測聽起來都很合理，但結果全都是錯的。

上下文斷層（Context Gap）

這類錯誤歸根究底，都是因為缺乏上下文所導致的：

解決這個問題的關鍵並不是去寫更好的 Prompt，而是要在 LLM 進行查詢的當下，直接讓它讀取到真實的資料庫 Schema。

解決方案：Model Context Protocol (MCP)

MCP 是一種開放標準，主要用來連接 AI 模型與外部資料來源和工具。

在技術架構上的核心特點是：單一 MCP 用戶端可以連接多個 MCP 伺服器，而每個伺服器各自封裝不同的資料來源。以 Postgres 運作來說，代表同一個 AI 助理可以同時存取多個資料來源，例如：

                    ┌─ Postgres MCP Server ──→ PostgreSQL (live schema & queries)
                    │
MCP Client ─────────┼─ Filesystem MCP Server ─→ PG Logs (log file analysis)
(Claude, IDEs)      │
                    └─ Prometheus MCP Server ─→ Telemetry (metrics & alerting data)

在這個架構中，Client 端就是 AI 應用程式，而每個 Server 端則提供工具供 LLM 呼叫，彼此透過 stdio 或 SSE 傳輸協定來跑 JSON-RPC 2.0。LLM 會根據使用者的問題，自己決定要呼叫哪一個 Server。

舉例來說：如果詢問的是 Schema 相關問題，它會去找 Postgres MCP；但如果問的是「為什麼昨天晚上資料庫變慢？」，就可能同時呼叫 Filesystem MCP（去看 Log 紀錄）和 Prometheus MCP（去抓指標數據）。

核心組成要素

在 MCP 的三種基本元件中，資料庫應用最核心的是 Tools：

• Tools： 這是供 LLM 呼叫的函式，會直接回傳即時結果。例如 execute_sql、list_schemas、list_objects 等，這類工具回傳的是最新狀態，而不是過期的快照。
• Resources： 透過 URI 提供的唯讀靜態資料。如果把資料庫 Schema 當成這種靜態資源發布，資訊很快就會過期，因此並不適合用來處理動態的資料庫元資料。
• Prompts： 封裝了上下文與指令的重複使用範本。雖然實用，但在資料庫的操作中屬於輔助角色。

PostgreSQL 結合 MCP：pg-airman-mcp

pg-airman-mcp 是一款針對 PostgreSQL 設計的 MCP 伺服器，能讓 LLM 即時存取資料庫的結構與資料。以下是它所提供的核心工具：

查詢流程

當使用者詢問「幫我列出營收前五名的客戶」時，LLM 不再用盲猜的方式，而是依序執行以下步驟：

1. 呼叫 list_schemas： 確認目前有哪些可用的 Schema。
2. 呼叫 list_objects： 取得真實的資料表與檢視表（View）名稱。
3. 呼叫 get_object_details： 掌握欄位、資料型態、條件約束與索引。
4. 呼叫 explain_query： 驗證執行計畫並檢查效能。
5. 呼叫 execute_sql： 在具備存取控制與安全解析的機制下執行查詢。

到了第 3 步，LLM 已經明確知道資料表叫 app_customers、欄位是 full_name，且外鍵是 customer_id。整個過程完全不需要任何猜測。

透過 pg_catalog 讓 Postgres 自行維護元資料

這套架構最核心的優勢，在於 Postgres 本身就已經完整記錄了所有需要的元資料。MCP 伺服器完全不需要依賴外部的設定檔、Schema 傾印檔案，或是常常忘記更新的系統文件。它只需要直接查詢 Postgres 的系統目錄：

• pg_class：記錄所有的資料表、檢視表與序列。
• pg_attribute：記錄欄位名稱與資料型態。
• pg_constraint：記錄主鍵（PK）、外鍵（FK）與 CHECK 條件約束。
• pg_index：記錄用於查詢最佳化的索引資訊。
• pg_namespace：記錄 Schema。
• pg_description：記錄 COMMENT ON 的註解內容（這能直接當作 LLM 的文件說明）。

在底層運作上，MCP 伺服器就是透過執行這類的查詢來獲取即時資訊：

-- list_schemas
SELECT
  schema_name, schema_owner,
  CASE
    WHEN schema_name LIKE 'pg_%' THEN 'System Schema'
    WHEN schema_name = 'information_schema' THEN 'System Info Schema'
    ELSE 'User Schema'
  END AS schema_type
FROM information_schema.schemata
ORDER BY schema_type, schema_name;
-- list_objects
SELECT
  CASE c.relkind
    WHEN 'r' THEN 'table'
    WHEN 'v' THEN 'view'
  END AS object_type,
  n.nspname AS table_schema,
  c.relname AS table_name,
  d.description AS comment
FROM pg_catalog.pg_class c
JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace
LEFT JOIN pg_catalog.pg_description d
  ON d.objoid = c.oid AND d.objsubid = 0
WHERE n.nspname = $1 AND c.relkind IN ('r','v')
ORDER BY c.relname;
-- get_object_details
SELECT
  column_name, data_type,
  is_nullable, column_default
FROM information_schema.columns
WHERE table_schema = $1
  AND table_name = $2
ORDER BY ordinal_position;

這些查詢是直接針對線上資料庫即時執行。不論欄位是新增、改名或刪除，MCP 伺服器都能在第一時間同步反應最新狀態。

透過 EXPLAIN 最佳化查詢

掌握正確的資料表與欄位是第一步，接下來還必須確保寫出來的查詢具備良好的執行效率。

透過 explain_query 工具，系統會把 LLM 生成的 SQL 先丟給 Postgres 的查詢規劃器（Query Planner）進行評估。如果 EXPLAIN 的結果顯示該執行計畫不夠理想，LLM 就能在幾毫秒內、在使用者完全沒有察覺的情況下，重寫並修正語法，才正式執行。

例如，以下是 LLM 的第一次嘗試：

SELECT c.full_name, SUM(o.total_price)
FROM   app_customers c
JOIN   customer_orders o ON c.id = o.customer_id
GROUP BY c.full_name
ORDER BY total DESC;

透過 EXPLAIN 的分析發現：這段查詢會對約 50 萬筆資料進行全表掃描，且沒有設定日期篩選（導致掃描了歷史至今的所有訂單），執行時間長達近 3,000 毫秒。

LLM 讀取 EXPLAIN 的輸出結果後，便會主動重寫 SQL：

SELECT c.full_name, SUM(o.total_price)
FROM   app_customers c
JOIN   customer_orders o ON c.id = o.customer_id
WHERE  o.created_at >= NOW() - INTERVAL '90 days'
GROUP BY c.id, c.full_name
ORDER BY total DESC
LIMIT 10;

優化後轉為索引掃描，掃描筆數縮減至約 3,000 筆，執行時間縮短到 20 毫秒，速度提升了約 150 倍。

在這個過程中，LLM 透過分析 EXPLAIN 執行計畫的結果，主動加上了日期篩選條件、修正了 GROUP BY（納入 c.id 以確保資料正確性），並加上了 LIMIT。這完全是基於即時的執行計畫評估，而不是死背硬記的最佳化規則。

安全防護機制（Guardrails）

要讓 LLM 能夠存取資料庫，必須部署多層安全機制。以下是推薦的標準配置方法：

首先，從配置唯讀帳號開始，並且只授予 GRANT SELECT 權限。這樣一來，即使 LLM 生成了 DROP TABLE 這類的指令，Postgres 也會在資料庫引擎層級直接拒絕執行。

CREATE ROLE mcp_reader LOGIN PASSWORD '...';
GRANT CONNECT ON DATABASE mydb TO mcp_reader;
GRANT USAGE ON SCHEMA public TO mcp_reader;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO mcp_reader;

針對多租戶架構的資料庫，可以啟用資料列級安全性（Row-Level Security, RLS）。這能直接在 Postgres 引擎層級強制隔離資料，即使面臨 SQL 注入（SQL Injection）攻擊也無法繞過這層防禦。

ALTER TABLE customer_orders ENABLE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation ON customer_orders
  FOR SELECT USING (
    tenant_id = current_setting('app.tenant_id')::int
  );

execute_sql 工具本身也提供了可自訂的存取控制、強制唯讀模式、安全的 SQL 解析機制，以及針對長時間異常查詢的 statement_timeout 限制。系統也會為每筆查詢記錄包含上下文的 Log，並強制執行速率限制。

這些安全機制並非選配，而是將 MCP 應用在任何真實資料庫時都必須具備的基本防線。

開始使用 pg-airman-mcp

只花幾分鐘，就能完成 pg-airman-mcp 的設定。請將以下內容新增到 MCP 用戶端設定檔中：

{
  "mcpServers": {
    "postgres": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "-e",
        "AIRMAN_MCP_DATABASE_URL",
        "enterprisedb/pg-airman-mcp",
        "--access-mode=unrestricted"
      ],
      "env": {
        "AIRMAN_MCP_DATABASE_URL": "postgresql://mcp_reader:pass@localhost:5432/mydb"
      }
    }
  }
}

在正式環境中，請使用 --access-mode=restricted（受限模式）。完成後重新啟動你的 MCP 用戶端，接下來就能自由進行任何查詢了。（更多設定説明）

更棘手的問題：悄悄出錯的查詢

Schema 探索機制只能解決表面上的明顯錯誤，例如寫錯資料表、漏掉欄位或語法錯誤的 JOIN。但還有另一個問題是它無法解決的。

當你詢問 LLM：「我們這個月的營收是多少？」時，SQL 順利執行了，跑出來的數據看起來也非常合理。但實際上，那個數字是錯的。

-- What the LLM generates
SELECT SUM(o.total_price)
FROM   customer_orders o
WHERE  o.created_at >= '2026-04-01'

這段查詢能正常執行，也會回傳一個數字。但這個數字卻把「已取消的訂單」、「已退款的訂單」，以及 is_deleted = true 的軟刪除（Soft-deleted）資料全都算進去了。

正確的查詢應該是：

-- What the query should be
SELECT SUM(o.total_price)
FROM   customer_orders o
WHERE  o.created_at >= '2026-04-01'
  AND  o.status != 'cancelled'
  AND  o.is_deleted = false
  AND  o.is_refunded = false

這就是所謂的「內部潛規則」。這些邏輯只存在於開發人員的腦袋裡，根本沒有寫進 Schema。不論再怎麼去查 pg_catalog，系統目錄也絕對不會告訴你：只要查詢 customer_orders，就必須一律加上 is_deleted = false 這個篩選條件。

解決方案：利用 FastMCP 客製化 MCP 伺服器

解決這個問題的方法，是將業務邏輯直接封裝進 MCP 工具中。讓 LLM 直接呼叫一個早已寫好規則的工具，而不是讓它從頭開始盲寫 SQL。

from fastmcp import FastMCP
import psycopg2

mcp = FastMCP("revenue-server")

@mcp.tool()
def get_monthly_revenue(month: str, year: int) -> dict:
    """Get actual revenue excluding cancelled,
    refunded, and soft-deleted orders."""
    conn = psycopg2.connect(DB_URL)
    cur = conn.cursor()
    cur.execute("""
        SELECT SUM(o.total_price)
        FROM   customer_orders o
        WHERE  DATE_TRUNC('month', o.created_at)
               = DATE_TRUNC('month', %s::date)
        AND    o.status != 'cancelled'
        AND    o.is_deleted = false
        AND    o.is_refunded = false
    """, [f"{year}-{month}-01"])
    result = cur.fetchone()
    return {"revenue": float(result[0] or 0)}

if __name__ == "__main__":
    mcp.run()

透過 Python 的 Docstring（文件字串），我們可以直接告訴 LLM 這個工具的功能；而真實的業務規則則已經寫死在函式實作中。這樣一來，當 LLM 遇到營收相關的問題時，它會直接呼叫 get_monthly_revenue，而不是自己瞎猜語法。

混合模式

在實際應用中，這兩種做法缺一不可，必須搭配使用。

• Postgres MCP 負責結構層： 處理 Schema、資料表、欄位與外鍵，告訴 LLM 資料庫裡「存在哪些東西」，防止 LLM 產生結構上的幻覺（Structural Hallucinations）。
• 客製化 MCP 負責邏輯層： 封裝了業務邏輯、篩選條件、合規規則與團隊內部的潛規則，告訴 LLM 這些資料「代表什麼意思」，杜絕語義上的幻覺（Semantic Hallucinations）。

實際運作時的互補效果：

• 面對欄位命名古怪的舊系統？由 Postgres MCP 即時探索結構。
• 面對複雜的狀態旗標或潛規則 JOIN？由客製化 MCP 內建規則。

為什麼不直接用其他方法？

要把資料庫的 Context 提供給 LLM，其實還有其他幾種做法。以下是它們與 MCP 的對比：

• 直接貼 Schema： 這種做法玩玩小專案還可以，一旦資料表結構發生變化就直接破功。
• RAG 模式： 適合用來對文件進行語義搜尋，但面對需要百分之百精準的「結構化元資料」時，表現並不理想。
• 微調模型： 等於是把 Schema 的硬編碼進模型裡，只要資料庫一版更，模型懂的知識就過期了。
• MCP 機制： 每次遇到提問，都是直接去查當下最即時的線上資料庫。

核心結論

• 精準的 Prompt 無法解決幻覺： LLM 會寫出錯誤的 SQL，核心原因在於它們缺乏資料庫的即時上下文，這一點光靠優化提示詞是無法根治的。
• MCP 是橋接的關鍵： MCP 是一個將 LLM 連接到外部資料的開放協定。pg-airman-mcp 正是利用了 pg_catalog 與 information_schema，將 Postgres 原生的「自我認知」直接轉化為 LLM 的背景知識。
• 客製化 MCP 補足盲點： 透過 FastMCP 建立的客製化 MCP 伺服器，能進一步將業務邏輯與團隊內部的「潛規則」封裝起來，解決單靠結構探索無法得知的業務語義。
• 雙劍合璧才是正解： 運用 Postgres MCP 搞定結構，加上 客製化 MCP 搞定語義 —— 這種混合模式才是讓 LLM 真正落地、搞定企業級複雜資料庫的終極方案。

本文翻譯自：Building Real-Time, Data-Aware Intelligence with Postgres and the Model Context Protocol

參考資料：

• Model Context Protocol Specification
• pg-airman-mcp
• PostgreSQL System Catalogs

想瞭解更多？歡迎聯絡我們，或是 加入歐立威 Line 好友！

本次 2.0 改版核心在於引進全新層級的架構編排能力，並同步強化組織身分治理、安全合規與多環境遷移的流暢度，提供具備高擴充性的維運管理平台。

Terraform Enterprise 2.0 重點更新

當基礎架構隨著業務規模拆分為多個配置檔案後，團隊耗費大量人工協調彼此的依賴關係、管理部署順序，並重複在不同環境中複製相同的架構。

Terraform Enterprise 2.0 引入了「Stacks」能力，改變了多層級、多環境的部署模式：

• 系統化集中管理： Stacks 允許團隊將分布於不同環境、區域與雲端帳號的基礎架構，視為單一系統進行定義與管理。
• 自動化依賴管理： 系統會自動處理不同架構元件之間的依賴關係與先後順序，減少跨團隊溝通成本。
• 確保部署一致性： 透過將編排能力內建於平台中，企業能以可重複的方式快速擴展環境，消除人為操作引發的配置落差。

專案級通知管理

在過去的運作模式中，維運團隊針對每個獨立的工作區逐一設定通知條件。這在多團隊的大型企業中帶來了顯著的管理負擔，且新建立的工作區容易因漏設通知，導致團隊未能及時收到告警。

Terraform Enterprise 2.0 導入的專案級通知（Project-level notifications）機制優化了這項流程。

管理團隊現在只需在「專案層級」定義一次通知設定，該專案下所有既有及未來新創的工作區皆會自動繼承。這種繼承式管理模型建立了一個中央控制平面，確保所有環境納入合規的監控基線中，消除人為疏漏造成的管理盲點。

SCIM 2.0 身分治理

Terraform Enterprise 2.0 針對身分驗證與權限控管進行了全方位升級，協助企業在實施自助服務的同時兼顧嚴格控管。

在身分同步方面，平台支援了 SCIM 2.0 標準協議，與企業現有的身分驗證中心（目前支援 Okta 與 Azure Entra ID）直接連線。當員工職務變動時，其權限將自動即時同步或註銷，免除手動管理的資安風險。

此外，為了降低長期憑據外洩所帶來的潛在威脅，新建立的 API Token 引入了生命週期管理，全面強制實施過期機制（預設最長兩年）。

新版也提供更精準的權限委派控管，允許特定團隊在定義的範圍內，自行覆蓋未通過的軟性策略檢查。

最後，平台新增了專為資安稽核設計的「站點審計員」唯讀角色，此角色可完整檢視組織運行狀態與策略設定，但會自動屏蔽狀態檔案等敏感數據，確保稽核流程安全合規。

跨組織工作區遷移

為簡化平台的維護工作並強化系統韌性，2.0 版本優化了底層管理工具，包含內建的升級前驗證檢查，可在執行平台升級前主動識別潛在的相容性問題，降低升級中斷的風險。

當企業因組織架構調整需要移動工作區時，新版提供了原生的非同步遷移 API，讓基礎架構的搬移過程更加安全合規。系統在移轉期間會自動鎖定來源端工作區，並在目標端建立新工作區以完整複製狀態版本等關鍵數據。

團隊可在目標環境完成驗證測試後再正式過渡，此時系統會自動重新對應（remap）原始外部 ID 並刪除來源端，確保生產系統與架構狀態在遷移期間完全不中斷。

推薦閲讀：Terraform 資源搜尋與匯入教學：自動生成代碼，完成 IaC 遷移

IBM 支援週期政策

Terraform Enterprise 2.0 起將全面採用 IBM Support Cycle-2 政策，為企業引進更清晰、可預測的軟體生命週期規劃。

在此全新模式下，每個主要版本將獲得至少兩年的標準支援。

在此之後，企業可選擇延長支援：第三年將持續提供關鍵錯誤修復、使用支援與特定的安全性更新；第四至第六年則提供使用指引與已知問題協助。此一穩健的支援架構，將為企業的關鍵任務工作負載提供更具延續性的維運保障。

結語

Terraform Enterprise 2.0 的發布，標誌著現代企業在管理複雜雲端架構時的重要里程碑。

從全新 Stacks 功能帶來的多環境集中編排，到專案級通知與 SCIM 2.0 所構建的資安合規防線，新版平台不再只是協助團隊編寫基礎架構代碼（IaC），而是全方位重塑了大跨度、多團隊環境下的維運治理模式。

隨著平台支援週期的標準化，企業在邁向大規模雲端維運的過程中，將能擁有更穩健、安全且高效率的現代化管理基石。

本文翻譯自：Terraform Enterprise 2.0: Evolving infrastructure operations for scale

想瞭解更多？歡迎聯絡我們，或是 加入歐立威 Line 好友！

Trino（前身為 PrestoSQL）是目前主流的開源分散式 SQL 查詢引擎，支援跨來源的資料聯邦（Data Federation）能力，讓企業不需要搬移資料，就能直接就地查詢。

然而，當企業規模擴大、資料量暴增，自建與管理開源 Trino 的基礎設施維運成本會大幅增加 —— 包含叢集的自動擴張、安全管控到持續的效能調校。

Starburst 是由 Trino 原創團隊打造的商業化企業級平台。它在開源 Trino 的核心架構上，加入了企業級功能擴充，目標是幫企業免除底層基礎設施的維運負擔，並提升大資料分析的成本效益。

Starburst 實際應用成效

這項架構移轉在各產業的實際應用中，帶來了具體的指標提升：

• 廣告科技資產（El Toro）：大數據查詢效能提升 300%。
• 雲端客服平台（Talkdesk）：系統錯誤率降低 150 倍，並成功整合了內部 20 多種分散的資料工具。
• 資料驅動供應鏈（7bridges）：洞察時間縮短 98%。
• 數位金融銀行（Banco Inter）：優化基礎設施開銷，每月節省達 100,000 美元。
• 大型遊戲電商（Junglee Games）：在降低 40% 雲端成本的同時，讓資料查詢效能提升 30%。
• 智慧出行平台（Kovi）：Ad-hoc（隨機查詢）速度獲得了 85% 的成長。

推薦閲讀：Starburst 成功案例｜首家支援 NVIDIA Vera：全面加速企業級 AI 效能

為什麼 Trino 創始團隊要打造 Starburst？

Trino 最初設計 Staburt 的目的，是想要解決跨資料湖與異質資料來源的 PB 級資料查詢。為了讓企業能進一步發揮這套開源工具的架構優勢，Trino 的創始團隊隨後創立了 Starburst。

目前全球許多大型企業選擇將內部的 Trino 部署升級為 Starburst，主要基於兩大關鍵。

首先是核心代碼的掌握度。Starburst 擁有全球規模最大的 Trino 專家團隊，統計顯示，2024 年有高達 84% 的 Trino 開源代碼提交（Code commits）來自 Starburst 團隊，這確保了商業版能獲得即時的技術支援與高度穩定的版本釋出。

其次是技術資源配置的優化。轉用託管平台後，團隊不需要再耗費精力在叢集的日常管理與底層微調，能把研發資源集中在資料本身的分析與業務應用。

Starburst vs Trino：效能對比

在基礎的 PB 級資料查詢上，Trino 與 Starburst 都能應付，幕後面對企業級的複雜工作負載與高併發查詢，兩者在架構設計上有以下差異：

從技術細節來看，兩者的最大分水嶺在於 Warp Speed 加速層。這是 Starburst 的內建專利技術，透過智慧索引與快取機制，系統會自動辨識高頻查詢並進行硬體級加速，不需要資料工程師手動建立與維護索引。

另一個痛點在於容錯執行架構。開源 Trino 在執行數十 TB 的大型查詢時，只要其中一個節點故障，整個查詢就會失敗重來。Starburst 則支援高達 60 TB 的增強型容錯，保障了長時間運算任務的穩定度。此外，針對現代資料湖倉愛用的 Iceberg 資料表，Starburst 也提供了開源版缺乏的自動化資料優化與串流導入功能。

規模擴充與 FinOps 成本控管

管理開源 Trino 的高難度項目之一是叢集的動態調整。自建架構通常只能做到基礎的資源群組劃分，而 Starburst 則引入了自動化維運機制，直接對接雲端基礎設施的成本管理（FinOps）。

雲端資源自動化控管

Starburst 支援自動叢集暫停與閒置關閉（Automatic cluster suspension & idle shutdown）。當系統偵測到一段時間內沒有查詢請求時，會自動暫停或關閉叢集，避免雲端運算資源白白空轉，造成費用浪費。

動態彈性擴充與排程

配合自動彈性擴展與排程（Automatic autoscaling & cluster scheduling），系統能根據當前的查詢負載動態增減節點。在分析高峰期提供充足算力，低峰期則自動縮減，藉此嚴格控管雲端帳單成本。

這也是自建開源架構在缺乏專職維運人力時，最難做到的自動化效益。

資料治理與安全權限控管

全局搜尋與綱要發現

Starburst 將安全與觀測需求整合進平台內。在全局搜尋與綱要發現（Universal search & Schema discovery）功能中，允許使用者跨越所有異質資料來源，直接搜尋特定的資料，並由系統動態偵測 Schema 的變更。

資料產品與血緣追蹤

針對現代資料網格（Data Mesh）架構，平台也支援資料產品與血緣追蹤（Data products & Data lineage）。這項功能讓資料能以「資料產品」的形式打包共享，並讓團隊清晰追蹤從源頭到報表的完整血緣關係。

自動化資安權限控管

最核心的升級在於自動化安全控管。Starburst 內建的角色與屬性存取控制，能直接做到動態的欄位遮罩（Column masking）與資料列過濾（Row-level filtering）。

資料工程團隊無須在底層各個資料庫重複設定權限，簡化了企業資安合規的流程。

企業級 AI 與 LLM 整合

隨著企業導入 AI 應用，分散式查詢引擎也需要對接相關工作負載。開源 Trino 目前在 AI 與機器學習的整合上僅提供非常有限的功能。

Starburst 則將查詢引擎的觸角延伸至 AI 領域（部分功能目前處於私有預覽 Private preview 階段）。透過 Starburst Agents，企業能讓 AI Agent 直接理解並查詢內部的異質資料架構。

而 SQL LLM Functions 則允許分析師直接在 SQL 語法中呼叫大語言模型，執行文本分析或資料摘要。搭配向量搜尋（Vector Search）的整合，進一步加速 RAG 應用的檢索，並透過統一的模型治理確保 AI 模型的資料存取受到企業級安全權限的規範。

結論：企業該如何選擇？

選擇開源 Trino，企業能獲得優異的分散式查詢核心，缺點是在後續會需要投入專職的工程團隊來解決維運、安全控管、效能調校與 AI 整合的技術債。

而選擇 Starburst，則是透過商業平台的自動化維運、內建 Warp Speed 加速、安全治理與 AI 支援，讓團隊跳過基礎設施的底層封裝與維護，直接專注於資料價值的開發。

總結來説，兩者並沒有絕對的優劣，企業可以根據自身的架構規模、團隊維運人力以及預算配置，選擇最符合當前業務需求的方案。

*本文內容整理自 Starburst 官方公開資料，僅用於技術介紹與資訊分享。

*參考資料：https://www.starburst.io/starburst-vs-trino/

想了解更多資訊，歡迎聯絡我們，或是 加入歐立威 Line 好友！