上篇聊到，Cosmos DB 這類資料庫天生是為 OLTP（處理單筆交易）設計的，想拿來做 OLAP（跨資料分析），需要先把巢狀資料反正規化成寬表。攤平之後，還有兩件事要決定：資料要放進什麼樣的資料庫、以及用什麼工具讓業務人員自然語言查詢。作者：黃婉中（雲端架構師）

上篇聊到，Cosmos DB 這類資料庫天生是為 OLTP（處理單筆交易）設計的，想拿來做 OLAP（跨資料分析），需要先把巢狀資料反正規化成寬表。攤平之後，還有兩件事要決定：資料要放進什麼樣的資料庫、以及用什麼工具讓業務人員自然語言查詢。

[caption id="attachment_274302" align="alignnone" width="834"] （圖／AI生成）[/caption]

順帶一提，攤平不用另外建表、複製一份資料維護。微軟的 Fabric 是一套把資料整理、儲存、查詢、視覺化包在一起的分析平台，用它的 Mirroring 功能，Cosmos DB 資料同步過去後，可以直接下 query 把巢狀 JSON 展開，再用這段 query 建一個 view。View 不是實體資料，是存起來的查詢邏輯，不用寫 ETL，也不動 Cosmos DB 本身的結構。 

除了表怎麼設計，資料庫本身也要跟著換

客戶後來又問了我一個問題：既然只是把表格設計改一下，那是不是隨便找個資料庫，把表改成上篇那樣就好，不用大費周章換資料庫？

「AI履歷健檢」看見自己優勢：https://campaign.1111.com.tw/resume-review/

更多科技工作請上科技專區：https://techplus.1111.com.tw/

這裡有一層容易被忽略的細節：反正規化只是改變表怎麼設計，但資料庫底層如何存資料，也會影響效能。

傳統 SQL 資料庫（像 PostgreSQL、MySQL）是列式儲存（row storage）：同一筆記錄的所有欄位，實際存在硬碟上相鄰的位置。這對 OLTP 很合適，因為一筆交易通常要讀寫一整列的大部分欄位，例如結帳、更新個人資料，整列存在一起，一次讀寫就搞定。

但 OLAP 常見的查詢是「只挑幾個欄位，掃過幾百萬列」，例如上篇那張銷售事實表，只要「城市」跟「小計」這兩欄算加總，不需要其他欄位。如果資料是列式儲存，即使只要兩個欄位，硬碟還是得把整列讀出來才能挑出需要的部分，等於浪費大量讀取效能。這就是為什麼專門做 OLAP 的資料庫，用的是欄式儲存（columnar storage）：把同一個欄位的資料集中存在一起，查詢時只讀取需要的欄位，大幅加快分析查詢的速度。

所以「要不要換成專門的欄式儲存資料庫」，是看兩個條件：

查詢形狀：如果使用情境是「掃過很多列、只看幾個欄位、要加總分組」，欄式儲存更快。

寫入方式：如果是批次匯入、寫入後很少逐筆修改（像這個客戶每天把 Cosmos DB 資料批次同步過來），欄式儲存更有優勢。

為什麼是 Fabric，不是自己組一套？

資料整理好，也放進合適的資料庫之後，接下來要決定的是：業務人員要用什麼工具，才能用自然語言查到答案。

客戶問我：如果重點是「把資料攤平」，那用 Microsoft AI Foundry 直接接 Cosmos DB，用 AI agent 現場處理，是不是也可以？

技術上走得通，Cosmos DB 的 SQL API 本身也能查巢狀 JSON。但差別在於：Cosmos DB 沒有Create view這種把查詢邏輯存成物件的功能，agent 每次都得現查。要把攤平邏輯固化成一個大家共用的 view，需要使用Fabric。Fabric 可以針對鏡射資料建 view，之後 Data Agent、Power BI 都直接查這個 view 就好。

選 Fabric，等於買了一套資料整理、儲存、查詢介面、視覺化全部包在一起的服務。攤平好的資料留在 OneLake 裡，Fabric Data Agent 直接查，要做報表就接 Power BI，中間不用再多想「這份資料該放哪個資料庫」。

如果選 Foundry，拿到的是查詢介面跟 AI 推理引擎，但資料整理完要放哪裡，得自己決定，可以放 Azure SQL、放 PostgreSQL，甚至最後還是得繞回 Fabric 的 OneLake。要做視覺化報表，還得另外接 Power BI 或別的工具。

有內部工程團隊、想要高度客製化的公司，可能會選 Foundry 自己組；沒有工程團隊、想要幾個月內上線的中小企業，買一套包好的服務，反而更划算。

給讀者的判斷框架

回頭看整件事，其實可以歸納成四個問題，遇到類似情境時可以拿來問自己：

1. 我要做的是 OLTP 還是 OLAP？ 查一筆資料 vs. 算一堆資料的加總，需要不同資料庫設計。
2. 值不值得做反正規化？ 這是一次性的整理成本，換取之後每次查詢都更快更準。如果查詢頻率低、資料結構單純，不一定要大費周章。
3. 需不需要換成專門的欄式儲存？ 看查詢的形狀（找特定一筆，還是掃很多列算加總）跟寫入的方式（頻繁單筆修改，還是批次匯入），不是單純看資料量大小。
4. 要自己組，還是買整合服務？ 沒有工程團隊、想快速上線，選整合服務；有能力客製化、想要更大的彈性，可以自己組。

這篇文章 讓 Cosmos DB 的資料開口說話：攤平之後怎麼查？｜專家論點【黃婉中】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

有個貸款客戶想要回答一些商業問題，例如「這個月哪個合作機構的成交量最高」。他們本來是用 Cosmos DB 存資料，但每次想知道這類問題的答案，都得找分析師，寫一段查詢、等結果。為了縮短等待，我們幫他們把資料攤平、做反正規化，讓客戶從此可以直接用自然語言去查詢，不用再等分析師。作者：黃婉中（雲端架構師）

有個貸款客戶想要回答一些商業問題，例如「這個月哪個合作機構的成交量最高」。他們本來是用 Cosmos DB 存資料，但每次想知道這類問題的答案，都得找分析師，寫一段查詢、等結果。為了縮短等待，我們幫他們把資料攤平、做反正規化，讓客戶從此可以直接用自然語言去查詢，不用再等分析師。

[caption id="attachment_274110" align="alignnone" width="885"] （圖／AI生成）[/caption]

這篇想把中間比較細節的兩個部分拆開來講：一是為什麼 Cosmos DB 不適合直接分析，二是攤平跟反正規化在做什麼。

資料庫的兩種個性：OLTP 跟 OLAP

先講兩個詞，因為後面會一直用到。

OLTP（Online Transaction Processing，線上交易處理）：例如打給客服、銀行轉帳。OLTP 資料庫的強項是「單一一筆」存取。

OLAP（Online Analytical Processing，線上分析處理）：例如「這個月哪個放款機構成交最多」。OLAP 資料庫的強項是「大量資料」統計。

「AI履歷健檢」看見自己優勢：https://campaign.1111.com.tw/resume-review/

更多科技工作請上科技專區：https://techplus.1111.com.tw/

Cosmos DB 是 OLTP，但跟 SQL 的 OLTP 不一樣

這裡有個容易搞混的地方：傳統 SQL 資料庫也是拿來做 OLTP 的，但它跟 Cosmos DB 做 OLTP 的方式不一樣。

SQL 資料庫：把資料拆細（正規化）。 客戶資料一張表、貸款資料一張表、還款紀錄一張表，彼此用關聯串起來。這樣做的好處是，如果客戶改名字，只要改一個地方，不會有些表改了、有些表忘記改，資料不會兜不起來。查詢的時候，用 JOIN 把幾張表接起來看。

Cosmos DB：把資料打包在一起。 一個客戶的姓名、聯絡方式、名下所有貸款、每筆貸款的還款紀錄，全部塞進同一份 JSON 文件裡。客服系統一查這個客戶，一次就把所有相關資料抓齊，不用像 SQL 那樣東拼西湊做 JOIN，速度極快。

這也是為什麼 Cosmos DB 裡的資料長得「一層包一層」，技術上叫巢狀結構（nested structure），客戶底下包貸款，貸款底下包還款紀錄，像俄羅斯娃娃一樣。是為了讓應用程式查詢快的刻意設計。

兩個產品都是為了讓「單筆存取」快，只是方法不同。

想做分析，才發現這個設計不夠用

當資料累積多了，客戶開始想要做分析，回答「這個月哪個放款機構成交最多」。像這種要攤開所有客戶、所有貸款，跨資料去加總比較，是巢狀打包結構最不擅長的事。因為資料被鎖在一份一份的文件裡，每份都要打開來看，才能湊出跨資料的統計結果。

解法：「反正規化」把資料變成一張寬表

要解決這個問題，做法是把巢狀資料攤平成表格。

用一個具體例子說明。一間店有兩個客戶：小明住台北，買過兩次東西；小華住高雄，買過一次。

如果是 SQL 正規化的做法，會拆成三張小表：

客戶表

產品表

訂單表

「小明」這兩個字只在客戶表裡出現過一次，訂單表只存客戶編號，不存名字。這樣做的好處是，小明改名字只要改一個地方；但想知道「小明總共花了多少錢」，得把三張表 JOIN 起來，先查出客戶編號、再對應產品單價，才能算出總金額。

如果是 OLAP 反正規化的做法，會攤平成一張寬表：

銷售事實表

「小明」「台北」這些資訊重複出現了兩次。在正規化的世界裡，這種重複是大忌；但在這裡是刻意設計的，因為現在想問「小明總共花了多少錢」，不用 JOIN 任何表，直接把小明那幾列的「小計」加起來就好；想問「哪個城市買最多」，把「城市」欄位拿出來加總分組就好。

這種「一列代表一筆事件、允許重複」的表，在資料倉儲的世界裡叫 fact table（事實表）；像「小明」「台北」這種會重複、用來描述這筆事件的欄位，叫 dimension（維度）。

一句話總結兩者的差異：正規化把「小明」這個名字存一次、用編號互相參照，換取修改資料時的安全；反正規化把「小明」這個名字允許重複貼在每一列上，換取統計加總時不用東拼西湊查好幾張表。

這裡說的「攤平」，就是反正規化，把 Cosmos DB 裡打包好的巢狀資料，拆開重組成扁平的寬表。欄位命名清楚、預先算好常用的加總。讓後面不管是人還是 AI，都能一眼看懂、快速查詢。

下篇想接著聊：整理完的資料放好之後，該用什麼工具讓業務人員自然語言查詢，這件事該自己組一套系統，還是買現成的整合服務。

這篇文章 讓 Cosmos DB 的資料開口說話：從等分析師，到自然語言查詢｜專家論點【黃婉中】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

上一篇提到，一間保險公司被 10 幾年累積下來的資料架構卡住：報表永遠慢半拍、同一份資料存了好幾次、沒人敢保證數字是乾淨的。作者：黃婉中（雲端架構師）

上一篇提到，一間保險公司被 10 幾年累積下來的資料架構卡住：報表永遠慢半拍、同一份資料存了好幾次、沒人敢保證數字是乾淨的。

[caption id="attachment_250943" align="alignnone" width="861"] 一份資料存了3次：保險公司的資料孤島求生記（上）｜專家論點【黃婉中】。（圖／AI生成）[/caption]

這篇來聊聊，他們後來怎麼解決，以及這件事對你來說，有什麼可以參考的地方。

讓資料「留在原地」

過去處理這類問題，標準做法是：把資料從原始系統抽出來，搬到分析用的地方，這個過程就是我們常聽到的 ETL（Extract、Transform、Load）。

「AI履歷健檢」看見自己優勢：https://campaign.1111.com.tw/resume-review/
更多科技工作請上科技專區：https://techplus.1111.com.tw/

問題是，搬一次，就多一次時間延遲、多一次儲存成本、多一個可能出錯的環節。

這間公司後來採用的做法，核心概念反過來：盡量讓資料留在原地，只在需要的時候，讓不同系統去「看」同一份資料，而不是各自複製一份。

具體做法，是用一個統一的資料底層（你可以想像成一個共用的大倉庫），把原始資料、整理過的資料、給主管看報表用的資料，分成三層放在同一個地方。業界常用「銅銀金」來比喻這三層，其實就是資料越往上走，越乾淨：

• 銅層（Bronze）：原封不動的原始資料，先進倉庫放著，不做任何加工
• 銀層（Silver）：整理過、算過的資料，給核保、財務這些部門做分析用
• 金層（Gold）：給主管看的整合報表，這層通常東西最少

這樣做的好處是，同一份資料只存一次，卻能同時給不同用途的人使用，不用每個部門各自搬一份、各自處理一次。

資料「即時」同步，卻不影響效能

你可能會問：資料放在原地，那報表要怎麼更新？如果每次要看報表，都要去正式的營運資料庫裡撈一次，那不就拖慢了原本系統的速度？

我用一個比喻說明：

想像資料庫是一間忙碌的廚房。如果你想知道廚房現在剩幾顆蛋，直接衝進廚房打開冰箱清點，會擋到廚師做菜。

但廚房通常會有一張「進出貨紀錄單」，放在冰箱旁邊，每次有東西進出，就會記一筆：「拿走 2 顆蛋」。

新一代的資料同步技術，做的就是：不去正式資料庫裡翻找，而是讀取這張「異動紀錄單」，看到有變動，就同步更新到分析用的那份資料上。

這樣一來，主管看到的報表可以接近即時更新，但完全不會影響到原本系統的運作速度。這也是為什麼很多企業現在能做到「資料一進來，馬上就能分析」，不用再等隔天。

減少「人搬資料」

除了讓資料留在原地，這間公司還做了一件事，是把整個資料搬運流程，從「人工處理」變成「全自動管線」。

過去要跟外部夥伴（比如維修廠、其他保險公司）交換資料，常常得靠人工，透過檔案傳輸的方式一來一往，資料格式對不對、有沒有漏傳、傳錯版本，都得靠人去確認，容易出錯。

現在這個流程改成透過自動化的資料管線（Pipeline），用 SFTP（一種安全的檔案傳輸協定）自動化地拉取、傳送資料，不用再有人手動下載、上傳、確認。這帶來兩個好處：第一，速度快很多；第二，資料出錯率降低。

同樣的邏輯，也用在公司內部原本的營運資料庫上。以前資料庫裡的資料，要先被「搬」到分析平台，才能進行下一步處理。

這次的做法，是直接讓分析平台去「還原」或「鏡像」既有的資料庫，等於少了一次額外的搬運，資料庫裡的東西不用真的被複製出去，分析平台就能直接取用。

權限管理

不是每個部門都應該看到同一份資料。

業務部門、資料分析團隊、財務部門，他們需要的資料範圍不同，能承受的風險也不同。如果讓所有人共用同一個工作環境，很容易發生兩個問題：一是權限管理混亂，誰該看什麼、不該看什麼很難釐清。二是效能互相干擾，如果資料分析團隊在跑一個很吃資源的大型查詢，可能會拖慢業務部門原本正常的日常操作，也就是所謂的「吵鬧鄰居」問題。

這間公司的做法，是依照使用情境，把工作區分開：日常營運用的、開放給業務部門自助分析用的、給資料科學家做進階建模用的，各自獨立，權限也依角色分層設定。這樣一來，不同部門可以在各自需要的範圍內工作，不會互相干擾，也降低了資料外洩或誤用的風險。

資料治理是地基

除了搬資料的效率問題，這間公司同時處理的，是資料治理，簡單說，就是「這份資料從哪來、誰能看、有沒有包含個資」，要有一套機制去管理。

具體來說，包含幾個部分：

• 資料目錄：清楚記錄公司到底有哪些資料、放在哪裡，不用再靠老員工的記憶
• 來源追蹤（Lineage）：一筆數字，能追溯回它最原始是從哪裡來、經過哪些加工
• 權限控管：誰能看什麼資料，依照角色分層管理，不是人人都是最高權限
• 個資偵測：自動掃描、標記出敏感資料（比如身分證字號、病歷資訊），提醒相關人員要特別小心處理

對一間受金融監理單位監管的公司來說，這套治理機制是合規的必要條件。而且提早把地基打好，之後不管是要導入 AI 分析、或是跟外部夥伴交換資料，都會輕鬆很多。

小結

就算你不是保險業，這個案例背後的邏輯，值得每個管理資料的人想一想：

這份資料被搬了幾次？
很多企業帳單暴增、報表又慢又亂，可能的原因之一，是資料在系統間被搬來搬去、被複製了好幾份。與其急著導入新的分析工具，不如先盤點一下：這份資料到底被搬了幾次？是不是都有必要？

降低資料流動的成本
不管你公司現在用的是哪一家供應商的工具，這幾年資料圈的趨勢，是想辦法減少資料被搬運、被複製的次數。下次評估架構的時候，這會是一個很實用的判斷標準。

這篇文章 一份資料存了3次：保險公司的資料孤島求生記（下）｜專家論點【黃婉中】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

上禮拜跟一個做保險業的客戶聊天，聊到他們內部的資料環境，我心裡默默算了一下：他們光是核心保單系統的資料庫，就有 400 到 450 GB，而且累積了 10 到 15 年的歷史資料。作者：黃婉中（雲端架構師）

上禮拜跟一個做保險業的客戶聊天，聊到他們內部的資料環境，我心裡默默算了一下：他們光是核心保單系統的資料庫，就有 400 到 450 GB，而且累積了 10 到 15 年的歷史資料。

[caption id="attachment_250939" align="alignnone" width="810"] 一份資料存了3次：保險公司的資料孤島求生記（上）｜專家論點【黃婉中】。（圖／AI生成）[/caption]

客戶說：「我們每天晚上跑資料整理，要跑 8 個小時。」

這段時間差限制了分析與財務洞察能力，也讓與合作夥伴的資料交換效率低落。 

「AI履歷健檢」看見自己優勢：https://campaign.1111.com.tw/resume-review/
更多科技工作請上科技專區：https://techplus.1111.com.tw/

這篇想跟你聊聊，一間傳統企業的資料環境，是怎麼一步步變成「不敢動」的樣子，以及這種狀況背後，到底卡在哪裡。

先講結論：資料太散

這間公司做的是車險，保戶買車廠配套保險的時候，背後的核保、理賠、財務資料，都要靠這套系統撐著。

問題不是資料量大，而是資料散落在太多地方：

• 好幾套版本不一的 SQL 資料庫，各自存著不同時期的保單資料
• 資料在地端（on-premises）和雲端之間，各放一部分
• 跟外部夥伴（維修廠、其他保險公司、產業公會）交換資料的時候，沒有安全又方便的管道
• 想知道「這筆資料是從哪裡來的、被誰改過」，答案幾乎是「不知道」

這就是我們常說的「資料孤島」（Data Silo），資料被鎖在各自的小房間裡，沒有人能拿到完整的全貌。

資料孤島

如果你也在企業裡管過資料，大概能想像這幾個場景：

報表是昨天的
因為資料每天晚上才批次處理一次，主管想看「現在」的數字，得到的永遠是「昨天算完的」數字。對這間保險公司來說，這代表核保、理賠、財務的決策，都慢一拍。

同一份資料，被存了好幾次
資料從原始系統，被搬到分析用的資料湖，又被搬到給主管看報表的資料倉儲。同樣的東西存三次、算三次，浪費儲存空間，如果是跨平台或地區，帳單也跟著長大三倍。

沒人敢保證資料是乾淨的
資料散落各處，加上缺乏治理機制，代表沒有人能很有信心地說：「這份數字是對的，來源也查得到。」對一間受金融監理單位監管的保險公司來說，這是合規風險。

維護像走鋼索
資料流程串了一堆環節，中間只要有一個關卡壞掉，整條線就卡住。而且這套系統背後，還牽涉到公司正在推動的核心系統轉換，舊資料架構跟新系統之間，需要一個可靠的橋樑。

為什麼改架構這麼難

看到這裡你可能會想：「那就重新設計架構啊，有什麼難的？」

難的地方在於，這種老舊架構通常已經運作了 10 年以上，牽一髮動全身。財務、理賠、核保，每個部門都依賴著現有的報表和流程，貿然改動，風險比維持現狀還高。

再加上企業內部往往缺乏足夠的資料治理經驗，就算知道問題在哪，也不知道怎麼下手：是先解決資料搬運的效率問題？還是先補上治理和安全的缺口？兩件事其實環環相扣，很難單獨處理。

這也是為什麼很多企業的資料環境，會一直維持「堪用但很痛」的狀態，不是不知道問題，是不知道從何改起。

下一篇，我會跟你分享這間公司後來怎麼解決這個問題，用的是現在資料圈很熱門的一種新架構思維，把「搬資料」這件事的複雜度，降到最低。

這篇文章 一份資料存了3次：保險公司的資料孤島求生記（上）｜專家論點【黃婉中】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

今年初，OpenClaw 突然爆紅。那陣子很多人買一台 Mac mini 放在家裡，跑這個開源的 AI Agent 框架，讓它自動處理各種工作任務，大家戲稱這叫「養龍蝦」。作者：黃婉中（雲端架構師）

今年初，OpenClaw 突然爆紅。那陣子很多人買一台 Mac mini 放在家裡，跑這個開源的 AI Agent 框架，讓它自動處理各種工作任務，大家戲稱這叫「養龍蝦」。

[caption id="attachment_227405" align="alignnone" width="776"] Microsoft 正式發表了 Microsoft Scout。（圖／AI生成）[/caption]

現實也很殘酷。我就聽說過有人因為 OpenClaw 失控，把自己過去幾年在公司累積的 Email 全部刪除乾淨。

大約在那個時候，我跟一位客戶開會，他問我：「現在 OpenClaw 這麼夯，Microsoft 有沒有相應的東西？」

我當時沒辦法正面回答他。

幾天前終於可以了。

在 Build 2026 大會上，Microsoft 正式發表了 Microsoft Scout，一個基於 OpenClaw 技術底層打造、同時套上企業級安全治理的全新 AI Agent。它代表著一整個新世代的工作方式。

「AI履歷健檢」看見自己優勢：https://campaign.1111.com.tw/resume-review/
更多科技工作請上科技專區：https://techplus.1111.com.tw/

從「問答助理」到「自主代理人」

要理解 Scout，得先理解它屬於哪一類產品。

過去幾年，我們已經習慣了 Copilot 的工作模式：你問，它答。你下指令，它執行。這是一種反應式（reactive）的 AI，很有用，但是被動的，需要人持續在旁邊驅動。

Scout 屬於另一個類別。Microsoft 把這個新類別叫做 Autopilot，隨時待命、主動行動、有自己的身份（Entra identity），在你設定的權限範圍內自主判斷、自主執行。

AI 不再只是讓你更快做完一件事，而是開始代替你做一整串的事。

Scout、Copilot、Copilot Studio不同定位

這3個產品很容易搞混，但定位各自不同。

Copilot / Copilot Pro 是問答助理層。你在 Word 裡叫它幫你改稿、在 Outlook 裡請它摘要郵件，它就做那一件事，然後等你下一個指令。

Copilot Studio 是開發平台層。讓企業的 IT 團隊自己建立客製化 Agent 的工具，要有人設計、部署、維護。

Scout 是個人自主 Agent 層。直接幫你做事，不需要 IT 團隊介入建置，也不需要你一直盯著它。

我怎麼用它

身為一個雲端架構師，我日常工作有大量資訊串接任務。

我最常用Scout處理跨應用程式自動化。舉例來說，我可以用自然語言告訴它：「當我收到關於客戶需求的郵件時，把重點自動更新到 CRM 系統裡。」，不需要寫程式，Scout能夠打開瀏覽器，自己執行。

過去需要靠 RPA 工具才能完成的跨系統串接，現在開始可以用自然語言描述來取代。對工作流程的設計方式來說，這是個不小的改變。

Scout 能做什麼

功能還在快速迭代，詳細的清單建議直接參考官方文件，這裡只點幾個對企業用戶比較有感的部分。

第一是跨 M365 應用的串接。郵件、行事曆、Teams、OneDrive 可以在同一個對話裡一起處理，例如你可以叫它找出某封郵件的內容、根據內容安排會議、再把會議摘要傳到 Teams 頻道，一氣呵成。

第二是背景自主執行。Scout 支援兩種模式：Heartbeat 是定期（每 15 分鐘到 2 小時）在背景執行你設定的任務；Automations 則是排程或條件觸發。你不在電腦前，它還是在跑。這也是 Autopilot 和 Copilot 最本質的差異。

第三是敏感度標籤的整合。Scout 會追蹤你在工作階段中存取內容的敏感度等級，如果你試圖把標記為「機密」的內容寫到未受保護的地方，它會先提醒你確認。對 IT 治理來說，這個設計很重要。

官方文件會持續更新，建議定期回去看：Microsoft Scout (Frontier) overview | Microsoft Learn

現在怎麼取得？費用怎麼算？

目前 Scout 以「實驗性版本」的形式，透過Frontier 計畫開放給早期採用者，在 Windows 和 macOS 上皆可使用。

要啟用 Scout，需要同時具備 Microsoft 365 Copilot 授權、GitHub Copilot 授權（AI token 的計費透過 GitHub Copilot 進行），以及企業端 Intune 政策設定和管理員開通。

Scout 只是開始

Autopilot 這個新類別的出現，對企業 IT 治理會帶來新的課題。一個隨時待命、能讀寫文件、能執行指令、能操作瀏覽器的 AI Agent，資料治理、存取控制、稽核日誌的重要性只會更高。

本文為作者個人整理，不代表公司的官方立場。實際執行時如有疑問，請聯繫你的微軟客戶經理。

這篇文章 Microsoft Scout 登場：Microsoft 對 OpenClaw 熱潮的企業級回應｜專家論點【黃婉中】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

許多企業在使用 Azure 一段時間後，都會面臨合約轉換的需求，可能是因為企業規模改變，或是希望透過不同的採購方式降低成本。 作者：黃婉中（雲端架構師）

許多企業在使用 Azure 一段時間後，都會面臨合約轉換的需求，可能是因為企業規模改變，或是希望透過不同的採購方式降低成本。 

[caption id="attachment_227397" align="alignnone" width="841"] 許多企業在使用 Azure 一段時間後，都會面臨合約轉換的需求（圖／AI生成）[/caption]

合約轉換這件事比想像中複雜，既有人以為「按個按鈕就好」，也有人擔心「轉換一定會停機」。 

這篇文章希望幫你釐清Azure各種合約之間的轉換邏輯，讓你在行動前有清楚的判斷依據。

先認識這幾種合約

在進入轉換討論之前，先簡單說明幾種主要的 Azure 合約類型：

• PAYG（Pay-As-You-Go）：隨用隨付，無需承諾，適合剛起步或用量不穩定的企業
• EA（Enterprise Agreement）：企業合約，適合大型組織
• MCA-E（Microsoft Customer Agreement Enterprise）：EA 的現代化版本，帳單架構更靈活，支援多張發票與多租用戶管理
• CSP（Cloud Solution Provider）：透過合作夥伴採購，由合作夥伴提供支援與管理

「AI履歷健檢」看見自己優勢：https://campaign.1111.com.tw/resume-review/
更多科技工作請上科技專區：https://techplus.1111.com.tw/

轉換路線地圖

不同合約之間的轉換，難度差異很大。以下是主要路線的整理：

最重要的是轉換的方向，你會發現，無論是EA、MCA-E要轉往CSP，如果透過Azure Expert MSP，都相對單純，反之則複雜。

附註：你可以前往Microsoft Marketplace | cloud solutions, AI apps, and agents搜尋目前微軟全球的Azure Expert MSP清單。

5個常見誤解

跟你分享5個我實務上常被問的問題。

1：合約轉換就是按個按鈕

大多數轉換都需要提前規劃、跨團隊協調，涉及財務、IT、採購等多個部門。 即使是「純帳單變更」的路線，也有許多周邊事項需要處理，建議預留至少一到三個月的準備時間。

2：轉換一定會造成服務停機

不一定。 

走帳單變更路線的轉換，Azure 服務會持續運作，使用者完全無感。但如果需要手動搬移資源，就可能停機，視資源類型而定。

3：帳單資料會自動帶過去

不會。

費用與使用量記錄不會隨訂閱一起轉移，必須在轉換前自行下載匯出。

4：Reservation 和 Savings Plan 一定沒問題

不一定。 

Reservation 和 Savings Plan 在某些轉換路線下可能被取消並重新計算期限，等於從頭開始。這點務必在轉換前與合作夥伴或微軟客戶團隊確認。

5：剩餘的 EA Commit 費用可以帶走

不行。 

轉換到 CSP 後，EA 預付但尚未使用的 Commit 費用會直接消失，無法轉移。建議規劃在 EA Commit 用完後再換，避免損失。

轉換前的檢查清單

在決定轉換之前，建議先確認以下幾點：

• 確認現有合約類型與到期時間，避免在錯誤的時間點啟動轉換
• 盤點現有資源，特別是 Reservation、Savings Plan 和 Marketplace 服務
• 確認合作夥伴資格，若目標是 CSP，合作夥伴具備 Azure Expert MSP 資格的話，能夠省掉手動遷移資源的工作
• 提前匯出帳單與使用量資料，作為轉換前的備份
• 預留足夠的規劃時間，複雜的環境至少需要兩到三個月

結語

這篇是我這幾年來碰到的案例，加上官方文件的整理。很多問題只要提前知道，都是可以避開的。實際要動手之前，還是建議找你的微軟客戶經理聊一下，IT產業更新很快，今天查到的資訊，過幾個月可能就不一樣了。

本文為作者個人整理，不代表任何公司的官方立場。實際執行時如有疑問，請聯繫你的微軟客戶經理。

這篇文章 EA、MCA-E、CSP 與 Pay-As-You-Go：Azure 合約轉換前你必須知道的事｜專家論點【黃婉中】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

企業搬遷的核心動力是成本控制，但「自建更便宜」需多維度評估。作者：黃婉中（雲端架構師）

企業搬遷的核心動力是成本控制，但「自建更便宜」需多維度評估。

[caption id="attachment_222913" align="alignnone" width="863"] （圖／黃婉中提供）[/caption]

我最近觀察到有些客戶開始考慮把部分工作負載搬回私有環境。但這不代表企業在逃離雲端，公有雲整體仍在成長，2025 年全球公有雲支出預計達 723 億美元，年成長 21%。

我認為更準確的描述是：更多企業打算採用混合模式，公有雲和私有雲並存。

「AI履歷健檢」看見自己優勢：https://campaign.1111.com.tw/resume-review/
更多科技工作請上科技專區：https://techplus.1111.com.tw/

最大動力：節省成本

企業轉向私有雲或混合雲，最大原因就是成本控制。根據 IDC 調查，59% 的組織在 2024 年雲端支出超出預算。

37signals（Basecamp 的母公司）每年付 AWS $320 萬，搬回去後預計五年省超過 $700 萬。而巴菲特旗下的美國保險公司 GEICO，經歷了十年的雲端遷移，結果費用漲了 2.5 倍。

「費用更低」不是對所有企業都成立

但仔細研究，會發現這些案例有個共同點：他們的工作負載非常穩定，不是偶爾爆發。

如果你的工作負載是「偶爾爆發、容易停」，那公有雲的彈性優勢仍然明顯，成本會更低。問題是，現在有越來越多企業發現自己的工作負載其實是「穩定型」，不是「爆發型」。對於這類工作，自建硬體的總持有成本（TCO）可能比長期租用公有雲便宜。

但成本不是唯一因素

不過，穩定的工作負載 = 自建更便宜，這個方程式有例外。

以 AI 工作負載為例。這幾年 GenAI 爆發，AI 從「實驗」變成「持續業務」，看起來工作負載穩定了。但企業面臨新的問題：不願因為三年承諾就被鎖定在特定方案上。

開源模型品質快速提升，已能應付大多數需求，而 AI 市場變化太快，下個月可能有更便宜或更好的選擇出現。結果是很多企業選擇：不簽長約，保有轉換的靈活性。 他們願意付略高的價格，換來隨時切換的自由。

這說明：在市場變化快速的領域，即使工作負載穩定，企業也可能為了保留靈活性而放棄純成本優勢。

自建不是簡單的決定

GEICO 的案例很有啟發性。他們決定搬遷回私有雲後，才發現自建帶來的實際挑戰遠比想像中複雜。他們在一年後公開談論搬遷過程中碰到的問題：

• 電源系統不相容，得自己開發混合方案
• 韌體管理幾乎要從零建起
• 跨不同硬體廠商的管理工具各自為政，難以統一
• 需要招募一批在傳統 OEM 採購模式下根本不需要的專業人才

GEICO 的經驗說明：自建不只是成本問題，還有運維複雜度、人才要求、技術整合等多個維度的挑戰。

所以，如果你發現自己的工作負載其實是穩定型，在考慮自建之前，可以評估以下幾個方面：

1. 人力資源（最大挑戰）

自建最大的成本來自人。不只是「有人會裝機器」，還要「有持續的人來維護、優化、處理突發狀況」，就像 GEICO 遇到的韌體管理和工具整合問題。組一個團隊，光薪資成本就很龐大，必須節省夠多才值得。

判斷標準：

• 你現在有多少人懂基礎設施管理？
• 自建的成本節省是否超過他們的薪資？
• 如果關鍵人物離職了，有接班人嗎？

2. 工作負載的穩定性

如果有臨時的、不可預測的專案，自建不只是不划算，甚至會來不及。

混合雲的做法是：穩定的放在私有，臨時的放在公有。 但代價是複雜度增加，跨雲管理、資料一致性、工具整合都需要額外投入。

3. 合規與安全

某些行業（金融、醫療、政府）或地區有特殊的監管要求，資料必須在特定地區、有特定的安全認證。

判斷標準：

• 你的行業是否有數據位置或安全認證的硬性要求？
• 公有雲廠商是否在你需要的地區有合適的 Data Center？

先檢查公有雲廠商是否提供符合要求的服務（Azure EU、阿里雲等）。只有都不符合，才需考慮自建。

4. 未來的靈活性需求

如果你計劃全球擴展，自建可能不夠靈活。建立全球私有基礎設施的成本和複雜度很高。

判斷標準：

• 業務是否會擴展到新的地理區域？
• 業務模式或技術棧是否會頻繁改變？

如果是，公有雲的靈活性更有價值。如果業務相對穩定，自建的長期成本優勢更明顯。

所以，我該怎麼辦

如果你在考慮是否應該轉向私有雲或混合雲，我建議這樣評估：

第一步：評估你的工作負載

• 哪些是持續穩定跑的？
• 有沒有臨時或不可預測的專案？

第二步：評估你的人力資源

• 有多少人懂基礎設施管理？轉向混合需要改變什麼？
• 你有沒有辦法在關鍵人物離職後保持營運？

第三步：評估你的特殊需求

• 有沒有合規或地理位置的硬性要求？
• 是否需要對特定資料有完全的控制權？

第四步：做成本計算 別只看公有雲的月費。要算上：

• 硬體購買、安裝、更新的成本
• 人力成本（招聘、培訓、流失）
• 機房成本（電力、冷卻、物理安全）
• 隱性成本（緊急維修、停機時間）

如果能清楚回答上面 4 個評估維度時，自然會知道什麼選擇最好。

這篇文章 混合雲時代：為什麼「省成本」可能是假命題｜專家論點【黃婉中】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

秒懂ISO27001合規生態系中各角色的功能與協作方式作者：黃婉中（雲端架構師）

秒懂ISO27001合規生態系中各角色的功能與協作方式

[caption id="attachment_222901" align="alignnone" width="864"] 很多人第一次接觸 ISO 27001 都會被搞糊塗。（圖／黃婉中提供）[/caption]

很多人第一次接觸 ISO 27001 都會被搞糊塗。

證書是誰發的？顧問是幹嘛的？工具又算什麼角色？這幾件事只要搞混，合規的邏輯就會轉不清楚，結果就是花了錢、花了時間，卻不知道為什麼要做。

我後來發現用健身來解釋最好懂。

「AI履歷健檢」看見自己優勢：https://campaign.1111.com.tw/resume-review/
更多科技工作請上科技專區：https://techplus.1111.com.tw/

教練：輔導顧問公司

想健身，第一步通常是找教練。請他幫你評估現在的體能狀況、教正確的動作，讓你不要做白工或受傷。

這個角色，在 ISO 的世界裡，就是輔導顧問公司。台灣市場上的顧問生態，大致可以歸納為三種類型：

第一種：專業管理認證顧問公司 例如鼎新資安、萬弘資訊、領導力企管等。這類公司專精於管理制度的合規輔導，從風險評估、政策文件建置、員工訓練、到內部稽核，能一路陪企業準備好接受最終的正式審查。

第二種：資安技術服務商提供之輔導 例如中華資安國際 (CHT Security)。這類公司本身具備強大的資安技術背景，在提供 ISO 27001 輔導的同時，能針對技術面的控制項（如弱點掃描、系統加固等）提供技術支援，將合規與防禦技術整合在一起。

第三種：大型管理顧問公司 即 Deloitte（勤業眾信）、PwC（資誠）、KPMG（安侯建業）、EY（安永） 等四大會計師事務所。他們通常服務大型企業或金融機構，擅長處理組織整體的治理框架（Governance），並將資安管理與企業內部控制制度對接。

顧問的角色是幫你把整套「資訊安全管理系統（ISMS）」從零建起來。他們確保你的組織架構、文件流程與日常執行都能符合國際標準要求，讓你在面對正式稽核時，能拿出合規的證據，也能確保制度在公司落地。

裁判：驗證機構

教練很厲害，卻不能發證書給你。要確認達到 ISO 27001 的標準，必須由獨立的第三方機構來評估。

很多人以為是 ISO 組織本身派人來審查，其實不是。ISO（國際標準化組織）只負責制定標準，本身不做認證。真正來現場「考試」的，是各國經過認可的驗證機構。

台灣常見的驗證機構包括：

• BSI（英國標準協會）
• SGS（台灣檢驗科技）
• TÜV Nord（北德）
• Afnor（環亞貝爾）
• TCIC（環球認證）

這些機構都必須經過財團法人認證基金會（TAF）的「認證（Accreditation）」，才有資格幫企業進行稽核 並核發帶有 TAF 標章的正式證書。

審查流程分為兩階段：第一階段（Stage 1）是文件審查，確認你的管理架構符合標準要求。第二階段（Stage 2）是實地稽核，稽核員會到現場抽查，確認你真的有照著制度走。從零開始到最終取證，企業通常需要預留 6 到 12 個月的準備時間。

健身 App：合規管理工具

隨著科技進步，大家開始流行健身 App。

你不需要每天請教練在旁邊盯著，App 可以給你訓練菜單、追蹤你每天的訓練完成狀況、提醒你今天該做什麼、幫你記錄有沒有達標。

在 ISO 27001 合規這件事上，這個角色對應的是 GRC（Governance, Risk, and Compliance）合規自動化平台，例如Sprinto、Drata、Vanta，各有不同的強項和適用規模。

它把顧問幫你建起來的那套制度，變成一個可以日常持續運作的平台：

• 跨多個合規框架的控制項自動對應，不需要每次新增框架就重新來過
• 佐證蒐集自動化，持續從你的系統抓取資料，讓你隨時都有稽核就緒的證據，不需要臨時動員
• 稽核人員可以直接登入專屬儀表板，查看所有控制項的狀態和佐證，減少來回溝通的時間

以前這些事情都靠人工追蹤，Excel 表格、Email 來回、各種提醒，費時費力又容易漏掉。現在這類工具的出現，讓日常合規管理這件事從「靠人盯」變成「讓平台跑」。

智慧手錶：雲端資安監控工具

手腕上的智慧手錶，做的事情是：隨時告訴你身體現在的狀態。 心跳、血氧、睡眠品質，數值出現異常馬上通知你，讓你不用等到健康檢查當天才發現問題。

這就是Microsoft Defender for Cloud（DFC）在雲端合規上扮演的角色。

它持續評估你的雲端環境，哪台伺服器設定錯了、帳號權限過高、資源沒有加密、SSL 憑證快過期。並在 Regulatory Compliance Dashboard 上即時顯示每個控制項的合規狀態。

它的覆蓋範圍不只是 Azure，還可以同時監控 AWS 和 GCP。透過 Azure Arc，可以把地端私有雲的伺服器也納入同一個儀表板，讓你在單一介面看到整個混合環境的合規狀態。

它支援的合規框架包含 ISO/IEC 27001:2022、PCI DSS、SOC 2、NIST 等主流標準，並且可以直接產出 PDF 或 CSV 格式的稽核報告，提供給稽核人員作為佐證。

把 4 個角色放在一起看

顧問公司（教練）：幫你把制度建起來，評估風險、設計控制項、建立流程。

認證機構 BSI、SGS（裁判）：定期來做正式評估，確認你真的達到要求，核發證書。

合規管理工具（健身 App） ：讓這套制度在日常持續運作，追蹤政策更新、員工訓練、佐證蒐集，不需要每次靠人工動員。

Defender for Cloud（智慧手錶） ：隨時監測雲端環境的技術面合規狀態，出問題馬上告訴你，不用等到稽核季才發現。

這個生態系不只適用於 ISO 27001，SOC 2、PCI-DSS、資通安全管理法都是同樣的邏輯。

💡延伸閱讀：我如何轉職成為雲端解決方案架構師

這篇文章 搞懂 ISO 27001生態系，其實跟健身沒什麼兩樣｜專家論點【黃婉中】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

在 Azure 工作這幾年，我常在會議室聽到客戶提到「避免 Vendor Lock-in」。但觀察久了，你會發現這句話通常不是架構師在擔心的，而是採購或決策者在說的。作者：黃婉中（雲端架構師）

在 Azure 工作這幾年，我常在會議室聽到客戶提到「避免 Vendor Lock-in」。但觀察久了，你會發現這句話通常不是架構師在擔心的，而是採購或決策者在說的。

[caption id="attachment_215083" align="alignnone" width="880"] 所謂的「抽象層」，其實就像是為了在不同雲端間切換而設計的「萬用轉接頭」。（圖／AI生成）[/caption]

他們真正的意思，其實不是怕技術上搬不走，而是想保留一個「我隨時可以離開」的姿態。這是一種商業談判：客戶會在單一雲端環境穩定使用三到五年，等量跑大了、折扣拿夠了，在合約快到期時，再拿著這些使用量去跟另一家談。

就像我們手機門號約滿了，不一定是因為收訊不好才想轉電信商，單純只是想看看別家能不能給出更優惠的續約條件。在雲端市場，這種採購策略其實每天都在發生。

更多科技工作請上科技專區：https://techplus.1111.com.tw/
科技社群討論區：https://pei.com.tw/feed/c/tech-plus

為了追求「隨時能搬走」所付出的代價

我曾經遇到一個客戶，為了保持「跨雲可攜性」，花了三年在做一套中立的架構。

他們規定所有的東西都要跑在 Kubernetes (AKS) 上，完全不碰 Azure 的原生服務，像是 Azure Functions、Service Bus 或 Cosmos DB。

所謂的「抽象層」，其實就像是為了在不同雲端間切換而設計的「萬用轉接頭」。但為了讓這個轉接頭相容，你必須放棄每家雲端最強的獨特功能，導致工程師大半的時間都在維修這個轉接頭，而不是在開發產品。

三年後，他們的 CTO 來找我，決定放棄這套架構，改為大量採用原生服務。因為他們發現，如果直接用雲端長好的功能，部署週期能大幅縮短。

這就是最弔詭的地方：為了防範「萬一要搬家」的風險，他們付出了三年研發緩慢的「確定損失」。

我們常擔心被廠商綁架，但冷靜想想，雲端大廠倒閉或惡意漲價的機率，跟我們自己公司因為產品出太慢而倒閉的機率，哪個比較高？至少在過去十年，雲端市場整體定價都是下降的。

有時讓團隊痛苦的，是為了追求靈活性而過度複雜的架構設計。

Egress Cost 不是供應商的陷阱

很多人把跨雲傳輸的成本當成鎖定的風險，其實有點誤會了。

不論你選哪一家雲，只要有資料傳輸，就會產生 Egress Cost。就算你在同一個 Azure 帳號下，跨區域 (Region) 傳輸一樣會計費。所以，成本高低跟「你選哪家雲」其實關係不大，反而是跟「你的資料流怎麼設計」有直接關係。

如果架構設計得不好，製造了大量不必要的跨區傳輸，那這就是病因，而帳單只是症狀。

監管合規的現實：服務完整性與法規

每次談到「為了合規所以要多雲」，其實背後有個假設：每家雲在各個地區的服務都一樣好用。但現實完全不是這樣。

以中國市場為例，雲端環境與全球是分開的。Azure 由世紀互聯營運，AWS 則由本地合作夥伴營運，兩者的架構邏輯相似，帳號與全球版不互通。受限於當地的營運環境，中國區的服務項目通常會比全球版少一些。而 GCP 則選擇了不同的市場策略，目前在中國境內不提供直接的雲端服務。

在美國聯邦政府市場，情況又不一樣。Azure Government 和 AWS GovCloud 都是實體與邏輯完全獨立的專屬雲端平台。而 GCP 則主要透過 Assured Workloads 等技術控管手段來滿足合規要求。

所以，你的業務在哪、面對什麼法規，決定了你的選項。

如果供應商在當地的服務支援並不符合你的特定業務需求，那麼談論多雲架構的靈活性，在實務上就會面臨很大的挑戰。

「深度整合」帶來的競爭優勢

其實，如果能把 Azure 的生態系用深、用透，這反而是你的優勢。當服務之間能無縫串接，開發節奏會快很多。

統一的 IAM 權限、監控和成本管理，能省下許多維運心力。如果你的對手更敢用這些工具，讓產品迭代得更快，那他雖然「被鎖定」了，卻能跑得更快。

我常跟客戶分享：先想辦法讓產品成功。等到公司真的大到需要擔心 Vendor Lock-in 的時候，你到時絕對有足夠的資源去處理它。在那之前，專注在業務的成長吧。

重點回顧

• 「避免 Vendor Lock-in」是談判桌上的語言：客戶三到五年跳一次雲，是為了用離開的可能性，換回議價的籌碼。
• 為了保持可攜性付出的確定損失，可能大於被 Lock-in 傷害的不確定風險。
• Egress Cost 跟選哪家雲無關，跟資料流怎麼設計才有關。
• 監管合規的真正問題不是「要不要多雲」，而是你需要的那家雲，在你需要的地區，服務完不完整、法規合不合規。

💡延伸閱讀：我如何轉職成為雲端解決方案架構師

延伸閱讀：當 ETL 不再需要工程師：Databricks、Fabric、Snowflake 開戰，資料人的下一站在哪？｜專家論點【黃婉中】

這篇文章 雲端供應商綁定（Vendor Lock-in）沒有你想的那麼可怕｜專家論點【黃婉中】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

想像一下：週五下午五點，你正想著等下要點哪一家的鹹酥雞，手機突然震了一下。收到雲平台的安全警告，甚至暫時停用。作者：黃婉中（雲端架構師）

想像一下：週五下午五點，你正想著等下要點哪一家的鹹酥雞，手機突然震了一下。收到雲平台的安全警告，甚至暫時停用。

[caption id="attachment_215078" align="alignnone" width="816"] 雲端供應商負責維護實體機房與底層網路的安全，但「你的客戶」在平台上傳了什麼資料、這些資料是否違規，屬於你必須控管的「資料治理」範疇。（圖／AI生成）[/caption]

電話接不完，你甚至不知道是哪一個天兵客戶上傳了什麼東西。

原因不是你的程式碼出錯，而是因為你的客戶上傳了惡意程式（Malware）的檔案，觸發了底層的自動防禦機制。

這不是都市傳說，是我客戶的真實經歷。

這就是 ISV 最擔心的「連帶風險」。雖然違規的是你的客戶，但承擔損失的卻是你。等到問題擴大到影響系統安全或觸犯法規紅線，停權與法律訴訟的壓力就會接踵而來。

更多科技工作請上科技專區：https://techplus.1111.com.tw/
科技社群討論區：https://pei.com.tw/feed/c/tech-plus

我們不能預期每個用戶都守規矩，但可以思考：如何在這些行為影響到 Azure 訂閱帳號之前，系統就能自動處理掉？

誰的責任？

根據 Azure 官方的雲端共享責任：無論你使用的是 IaaS、PaaS 還是 SaaS，「資料分類與保護」始終是你的責任。

換句話說，雲端供應商負責維護實體機房與底層網路的安全，但「你的客戶」在平台上傳了什麼資料、這些資料是否違規，屬於你必須控管的「資料治理」範疇。

當風險發生時，供應商會依據此模型要求你履行保護義務。如果你沒有建立過濾機制，就可能面臨訂閱帳號被暫停的風險。

安檢站的架構建議：利用 Defender for Cloud 建立防線

當違規事件發生時，雲端供應商的處理速度通常很快。與其等著收通知，不如在自己的架構裡先蓋好「安檢站」。

你的系統需要資料落地前，就具備初步的判斷能力。

機場安檢不會因為你看起來像好人就放你走。你的雲端架構也該有一套「不信任何人」的安檢站。

我們不需要從頭開發，Azure 已經提供了現成的工具來搭建這套防護網。

第一層：靜態過濾（Defender for Storage + Purview）

檔案上傳時，建議先經過一個「暫存區」，而不是直接進入正式儲存區。

• 安全性掃描： 透過 Microsoft Defender for Storage 的惡意軟體掃描（Malware Scanning），可以在檔案進入 Blob 的瞬間攔截有害程式。
• 合規性檢查： 配合 Microsoft Purview，系統可以識別出檔案中是否包含未經授權的敏感資料（如身分證號或信用卡資訊）。這能幫你的客戶擋掉許多無心但具備法律風險的上傳行為。

除了主動掃描內容，建議你也參考 Azure 官方的適用於 Blob 儲存體的安全性建議，從帳號權限、網路控制與記錄監視等維度，為你的儲存基礎設施打好底子。

第二層：行為分析（Microsoft Sentinel）

除了檔案本身，我們也要監控用戶的行為模式。 如果某個帳號在短時間內出現異常的大量上傳或存取，這常是是攻擊或違規的徵兆。這時 Defender for Cloud 會發出警報，並將數據匯入 Microsoft Sentinel。

你可以利用 Sentinel 的自動化功能（Playbooks）來設定規則：一旦偵測到高風險行為，系統就自動暫停該用戶的權限。這種「壯士斷腕」的做法，能確保問題被鎖定在單一用戶身上，而不會延燒到你的整個 Azure 訂閱帳號。

影像內容：補足防禦的缺口

文字過濾已經是基本功，但現代的違規內容大多藏在圖片或影片中。 如果你的 SaaS 有大量影像分享，建議整合 Azure AI Content Safety。它能以極低的成本（每千張影像約 $1 美元）自動偵測暴力或不當內容。

比起人工審核，這能提供更即時、更全面的保護。

架構之外的應變準備

除了技術手段，還有兩件事對 SaaS 服務商很重要：

1. 完善的服務條款（ToS）： 確保你有權力在用戶違規時終止其服務。
2. 詳盡的防禦日誌： Defender for Cloud 留下的攔截紀錄非常重要。萬一帳號真的被偵測到異常，這些紀錄就是你向 Azure 團隊說明「我已盡到管理責任且有過濾機制」的最佳證據。

好的架構設計除了處理流量，也要在異常發生時，把損害控制在最小範圍。透過這套自動化安檢機制，你可以將「用戶違規」這個不確定因素，化為系統可以自行消化的例行程序。

重點回顧

1. 釐清連鎖風險：你的客戶若行為違規，會直接影響你的 Azure 帳號。
2. 入口即時掃描：善用 Defender for Storage 掃毒並配合 Purview 識別個資，在資料進入你的儲存區前就攔下風險。
3. 自動化隔離異常：透過 Microsoft Sentinel 監控，一旦發現某位客戶有異常行為，系統可自動限制其權限。
4. 補齊影像盲點：別漏掉圖片與影片，整合 Azure AI Content Safety 才能確保你的客戶上傳的視覺內容也符合合規要求。
5. 留存證據：防禦日誌能幫你爭取復權。

💡延伸閱讀：我如何轉職成為雲端解決方案架構師

延伸閱讀：當 ETL 不再需要工程師：Databricks、Fabric、Snowflake 開戰，資料人的下一站在哪？｜專家論點【黃婉中】

這篇文章 雲端服務怎麼自動抓違禁資料？一個「安檢站」比喻讓你秒懂｜專家論點【黃婉中】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。