2024年12月16日【守護 AI 未來：CyberArk 與 Red Hat 的聯合創新】
從開放平台到身分安全，奠定值得信任的 AI 基礎架構
- 活動地點：台北寒舍艾美 角宿廳
- 議程時間：2025/12/16 (二) 13:30-16:30
本次由 CyberArk × Red Hat 攜手，從開放平台出發，延伸到 身分安全、遠端連線與憑證管理，分享企業如何以零信任思維，讓 AI 安全落地、架構穩定運行。
資訊悅報 Vol.24｜REFORM RATE : 70% 雲支出都被浪費：Showback 與 Chargeback 為什麼已經不敷使用？
促進以數據為基礎的討論部落格來源網址：Platform Engineering vs DevOps: How Different Are They?
Showback 與 Chargeback？這個問題在 2010 年還合理，但現在已不再適用。
因為這兩種模式，
它們無法支援 即時交付（real-time delivery）、平台與環境的高度複雜性，也無法滿足 工程團隊的自主權（developer autonomy）。
那麼，你是否應該徹底放下「Showback vs. Chargeback」的討論？
如果答案是「是」，那下一個問題會是：
在高度複雲、多環境、需要大幅擴展性的架構下，
答案是：FinOps。
一種更聰明、即時、彈性，且能隨著規模成長的雲財務營運方法論。
接下來，讓我們帶你深入說明。
在開始之前：Showback 與 Chargeback 的基本概念
讓我們快速看看 Showback 與 Chargeback 的核心特性有何不同。
什麼是 Showback？
Showback 指的是：
各團隊可以看到自己花了多少雲成本，但不需要為該花費負責。
就像收到一張雲成本的「成績單」，內容大概是：
「嘿，團隊，讓你們知道一下⋯⋯我們上個月剛支付了 12,000 美元的 AWS 費用。」
Showback 的功能就是提升「成本意識」，僅此而已。
事實上：
- 沒有任何團隊需要對花費負責
- 不會影響預算
- 不會促成習慣改變
- 不會帶來任何最佳化行動
在最「樂觀」的情況下，就是季度結算時，如果預算爆了，
那 Chargeback 呢？比較好嗎？
Chargeback 則是更進一步。
它不只是報告成本，而是 把成本實際回 charge（回充）給使用該資源的團隊或部門。
你可以把它想像成一封急件備忘：
「各位團隊成員，上個月你們在 AWS 的支出已達 12,000 美元，相當於我們季度預算的 60%。請檢視現行流程，評估是否有任何項目可削減或直接取消。
Chargeback 的最大優點是：會建立起「財務責任」與「成本擁有感」。
但它也可能引發副作用：
- 團隊覺得被「懲罰」
- 引起彼此推卸責任
- 團隊為了降低帳單做出短視近利的決策（例如：
把關鍵服務配置降太低，影響穩定度）
Showback vs. Chargeback：哪些做得對？哪些已經失效？
Showback 與 Chargeback 的初衷其實都很好──
它們本來的目的，是 讓團隊更清楚自己花了多少雲成本，進而逐步提升責任感與成本效率
然而，雖然這個理念至今沒有錯，但 它們的限制卻隨著多雲與雲原生架構的普及而快速放大。
如今，它們已經無法跟上企業規模、速度與複雜度的變化。
Showback 的優缺點
| 優點 | 缺點 |
|
|
Chargeback 優缺點
| 優點 | 缺點 |
|
|
如果你仍然使用 Showback 或 Chargeback 來管理多雲環境，很可能正在面臨以下這些問題：
1. Showback 的結果是——什麼都沒發生
沒錯，團隊看到了數字……但接著就沒下文了。
Showback 缺乏 激勵機制、行動指引，也沒有任何改善的路線圖。
報告出了，事情卻沒有往前進。
2. Chargeback 會製造內部摩擦
當團隊收到被回 charge 的費用，但卻缺乏控制成本的權限與上下文資訊，很容易演變成：
- 推諉責任
- 團隊互相指責
- 財務 vs 工程的「預算大戰」
這樣的結果完全無效，因為焦點從「合作最佳化」變成「誰該付錢」
3. 它們跟不上現代雲端的交付速度
雲端使用量早就不是靠「月報」就能掌握的時代了。
現在的雲資源是 動態、自動化、跨環境分散。
說白一點：如果問題在 30 天前就已發生，月底才看到報告根本於事無補。
4. 缺乏即時的「上下文 Context」資訊
假設你看到 EC2 使用量上週突然飆升——知道「發生了」根本不夠。
你不知道：
- 是一次性事件？
- 是自動擴展失誤？
- 還是哪個團隊的新版本造成的？
當你不知道 發生什麼、為什麼發生、怎麼避免再發生，
為什麼多雲環境讓 Showback / Chargeback 完全失效？
過去，企業大多把工作負載放在單一雲，或少數集中式 VM 上，那時候的成本結構簡單又容易追蹤：
但多雲環境帶來的挑戰完全不同：
- 多家雲服務供應商（AWS、Azure、GCP、阿里雲…）
同時使用 - 不同的定價模式、分級、折扣方案、計費週期全都不一樣
- 服務分散在各種環境、帳號、區域、VPC、訂閱中
- 共享基礎架構與微服務造成責任歸屬模糊不清
傳統 Showback/Chargeback 的前提是：基礎架構線性、可控、集中、變化不大。
但多雲的世界是：快速、動態、分散、複雜、跨團隊、跨環境。
在這種架構下，唯一能跟上速度的方法就是：讓成本責任（Cost Accountability）具備「即時性（Real-
而這正是 FinOps 的價值所在。
FinOps 為什麼對多雲管理更有價值？
FinOps 架構 2025，由 FinOps Foundation 繪製
Showback 與 Chargeback 最擅長的是「事後報告」──但當報告送達時，往往已經太遲。FinOps 則將焦點從被動回顧，全面轉向 即時、協作、以數據驅動的決策方式。要真正理解 FinOps 為什麼在今天已經成為「必須」，
1. 即時（Real-time）的雲成本可視性
如果你想爬到山頂，你會選「地圖」還是「報告」？
FinOps 的本質不是「回報發生什麼事」，而是「
但像 RE:FORM RATE 這類 FinOps 工具能提供 跨所有雲端、所有環境的即時統一視圖：
- 你能看到使用量 spike 是「當下」在發生
- 你能知道是哪個團隊、哪個服務、在哪裡造成的
- 你能理解「為什麼會發生」
這是 Showback/Chargeback 完全做不到的。
2. 共享責任（Shared Accountability）
當財務與工程部門各看各的數字版本，
- 共享相同的雲使用與支出視圖
- 透明的團隊、專案、服務級拆分成本
- 以事實協作，而不是以預算爭吵
這能建立責任感，而不是製造政治角力。
3. 帶著上下文採取行動（Actions with Context）
FinOps 能將成本數據直接連到工程行為：部署（deployments）
- Kubernetes 成本突然飆高
- FinOps 能立即告訴你：是某個團隊在 staging 做了緊急 scale-up
在共享資源成為常態的多雲架構中，這種上下文能讓企業從「
4. 將焦點放在改善，而不是責備（Focus on Change, Not Blame）
你一定有這種經驗：
財務或 CFO 在你後面盯著每一筆支出，彷彿你不知道成本會爆掉。但背後真正的問題不是人，而是 缺乏掌控成本的策略與工具。FinOps 的目標不是揪出誰要負責，而是：
- 提前發現異常（如 RATE 的 anomaly detection）
- 把成本問題在「爆掉之前」處理
- 讓團隊學會找出模式、消除浪費、做更聰明的技術決策
FinOps 建立的是「能力」，而不是「懲罰」。
5. 同時擴展團隊、雲環境與流程（Scaling Teams, Clouds, Workflows）
當基礎架構不斷擴張，成本管理模式也必須同步擴張。
但 Showback/Chargeback 一遇到：
- 多雲
- 多環境
- 多團隊
- 多服務
就會崩潰。FinOps 天生為擴展而設計，因為它提供：
- 可重複的框架（repeatable framework）
- 標準化流程（standardized workflow）
- 一套政策就能適用所有雲環境（tagging、alert、
optimization policies）
這表示隨著規模擴大，企業能強化責任與治理，
RE:FORM RATE 如何為企業最佳化多雲成本？
RATE 是專為雲端支出規模龐大的企業所打造，用來解決組織在多雲管理中最棘手、最常見的痛點，包括：
1. 單一儀表板掌握完整多雲可視性
透過 RATE，你可以在同一個介面中即時查看 AWS、Azure、GCP、阿里雲的所有成本與使用狀態，
重新奪回對雲資源的掌控力。
重新奪回對雲資源的掌控力。
2. 自動化節費，具備雲供應商專屬建議的可執行命令
RATE 會根據不同雲供應商的最佳化策略，產出可直接執行的自動化指令，
不再只是報告「問題在哪」，而是直接「幫你解決」。
不再只是報告「問題在哪」，而是直接「幫你解決」。
3. 告別標籤混亂與突發費用飆升
RATE 透過標準化標籤、資源分組與異常成本偵測，
消除因標籤混亂、權責不清與意外爆量所造成的混亂與財務風險。
消除因標籤混亂、權責不清與意外爆量所造成的混亂與財務風險。
4. 同時支援雲原生資源與 Kubernetes 成本管理
無論你的工作負載在雲資源或 K8s，RATE 都提供完整的使用量、成本與優化建議，
讓 FinOps 能真正延伸到每個環境。
讓 FinOps 能真正延伸到每個環境。
30 天內可辨識平均 25% 的可立即節費機會
根據 RATE 客戶的實際結果，企業通常能在導入後的 30 天內找出約 25% 的立即節省空間，同時強化治理流程與跨部門責任制度。
Showback / Chargeback 已經無法支撐你的雲預算？
FinOps 才是下一步的答案。如果舊模式已經無法讓你的雲預算與企業策略一致，
FinOps —— 搭配 RATE —— 才是能真正驅動組織成長與成本效率的核心方法論。
FinOps —— 搭配 RATE —— 才是能真正驅動組織成長與成本效率的核心方法論。
若退款或成本回溯機制已無法使雲端預算與您的商業願景保持一致，FinOps 便是您的解決方案。
資訊悅報 Vol.23｜Vicarius: 攻擊者最常利用的 3 大 CVE 模式：為什麼你的補丁永遠追不上駭客？
部落格來源網址：Top Exploited CVE Patterns (And What They Reveal)
在這一年整體數位威脅急速升溫的背景下，漏洞被攻擊（
報告指出，這項攻擊手法年成長率高達 34%，主要受到自動化攻擊工具普及，
例如 Citrix NetScaler、Cisco ASA 這類作為「內外網交界」的關鍵設備，在 2025 年被發現與近 25% 的漏洞利用型入侵事件有直接關聯；
三大最常見的攻擊模式
即便企業對漏洞風險的認知逐漸提高、補丁也普遍可取得，但「
雖然企業的攻擊面越來越大，但攻擊成功的方式其實高度重複——
以下是當前最常見的三大攻擊模式：
1. 面向外部網路（Edge-facing）設備的遠端程式碼執行（RCE）攻擊：
三種攻擊模式中，最危險也最具破壞性的，就是發生在邊界設備（edge-facing devices）上的遠端程式碼執行漏洞（RCE）。例如Citrix NetScaler 與 Cisco IOS XE，就曾曝露出 RCE 弱點，使攻擊者能：
- 植入惡意程式
- 任意修改設備組態
- 建立長期滲透的持久化後門
- 甚至完全不需要認證就能取得控制權
這類設備通常具備高權限且位於網路與外部的交界，是企業最重要的防線。然而，它們往往：
- 使用老舊韌體
- 暴露過度開放、缺乏限制的管理界面
這讓攻擊者只需要投入極低成本，就能取得極高報酬的攻擊結果。換句話說，只要邊界設備一被突破，後面的攻擊就會像推倒骨牌一樣迅速展開。
2. 認證與工作階段（Session）繞過漏洞：
第二種常被忽略的攻擊模式，是透過繞過登入或 Session 驗證的方式直接取得存取權限。像 Atlassian Confluence 等企業常用協作工具，就曾出現讓攻擊者完全跳過登入流程、直接取得存取權限的漏洞。
這類問題並不是單一小 bug，而是能大幅放大攻擊威脅的加速器。
當這些漏洞與遠端程式碼執行（RCE）或本機權限提升（LPE）搭配使用時，攻擊者不只可以輕鬆取得初始入侵點，還能：
- 長期維持滲透
- 偽裝成合法使用者或正常流量
- 在企業網路中橫向移動而不易被偵測
換言之，只要認證流程被繞過，攻擊者就能在系統裡「躲很久、動很快、抓不到」。
3. 已知（且可修補）CVE 的持續性攻擊：
第三種攻擊模式，也是最令防禦者挫折的部分——攻擊者持續利用那些早已公開、甚至早已發布補丁的已知漏洞。
許多組織一次又一次地因為這些漏洞遭受攻擊——而這些弱點其實早在數個月、甚至數年前就已經被揭露並提供修補。
這種現象之所以持續，是因為：
- 組態漂移：系統設定在日常變動中逐漸偏離安全基準。
- 遺留系統：老舊系統無法上補丁或不敢上補丁。
- 未受管控的資產：設備不在 IT/資安掌控之內。
結果就是一個緩慢但持久、難以根除的威脅環境：昨天的漏洞新聞報導，往往成為明天真正的入侵事件來源。
這不只是單純的流程雜症，而是一個明確的警訊：僅依賴「弱點分類與排程」的漏洞管理策略，正在全面失效。
如果企業沒有把組態管理和補丁衛生視為「持續性、且必須高優先處理的核心任務」，那麼再好的弱掃工具、告警平台，都只能淪為事後反應型的防禦手段，而無法真正降低風險。
KEV：漏洞優先順序的「北極星」指引
當所有事情都被標示為「緊急」，那其實等於沒有任何一件真正緊急
這正是為什麼 CISA 已知被利用漏洞清單（Known Exploited Vulnerabilities, KEV）成為如此關鍵的資源。
不同於 CVSS 只會把許多漏洞標成「高風險」或「嚴重」，KEV 專注於那些已經在真實攻擊中被利用的漏洞。
它不再只是理論上的風險評分，而更像是「來自戰場的第一手情資」
對齊 KEV 的安全團隊能更果斷行動，不再迷失在「滿天 Critical」的漏洞清單中，而是把有限資源投注在確實會被
事實上，許多在 KEV 中被點名的漏洞，CVSS 分數可能不高，但因為：
- 使用範圍廣
- 位置高度暴露
而被攻擊者大量武器化。
更重要的是，KEV 改變了企業處理漏洞的方式，KEV 不只幫助企業排定優先順序，它還：
- 提供修補優先權的清晰依據
- 簡化主管報告流程
- 清楚界定補丁修復的 SLA
只要訂閱 KEV 更新，並將其整合至弱掃工具或資產管理平台中，
KEV 並不是用來取代 CVSS，而是一個更加貼近現實的風險校正器——它過濾掉噪音，
vRx：讓修補速度真正「跟上 KEV」的關鍵加速器
vRx 能將 KEV（已知被利用漏洞）情資直接轉化為可立即落地的修補行動。平台會持續自動匯入KEV 清單，並即時對照企業的實際資產清冊，不需人工比對或撰寫自製腳本，就能清楚標示：
- 哪些設備正暴露於已被攻擊者實際利用的漏洞
- 哪些設備已處於安全狀態
讓修補優先順序真正與攻擊者的行為保持同步。
vRx 的核心差異：真正能落地的修補引擎
不同於傳統只能「部署補丁」的 Patch Management 工具，
vRx 具備完整的修補引擎，其中包含：
✓ 漸進式環狀部署策略
補丁以小範圍、低風險資產做為第一波測試，確認穩定後再逐步擴散至更關鍵的設備。
✓ 支援回滾機制
若補丁造成異常，可透過 Script Engine 執行 rollback 操作立即回復至前一狀態，大幅降低停機或服務中斷的風險。
此部署方式讓團隊得以快速修補、降低影響面、提升成功率。
把策略變成可執行行動：vRx 補上政策與落地之間的缺口
在多數企業中，「政策」與「實際修補行動」之間往往存在巨大落差：
- 哪些補丁已完成？
- 哪些沒做？
- 為什麼？
- 是否符合 SLA？
這些資訊在傳統工具裡常常難以追蹤。
vRx 完整補上這個缺口，提供：
- 清楚標示已修補與未修補項目
- 修補原因與例外狀態
- 即時儀表板
- 修補 SLA 進度追蹤
- 可下載的完整稽核報表
無論是內部治理、主管報告、或外部法遵稽核，企業都能確切展示：
我們何時修補、修補了哪些系統、如何修補，以及是否符合SLA。
vRx 不只是「打補丁」，而是協助企業真正做到可驗證、可證明的修補能力。
將 SLA 與修補流程真正「制度化」：以 KEV 為核心的修補作業手冊
制定補丁時程不只是訂出一個基準點，而是用來強化 組織可信度、反應能力與可被稽核性 的重要依據。
一套定義清晰的 SLA，不僅代表企業「想修補」的意圖，更代表企業在高壓環境下
在以 KEV 為核心的修補模式中，SLA 的設定更必須反映出：
- 真實世界中攻擊者的行為速度
- 組織實際曝露的風險程度
- 以及漏洞被武器化的週期
也就是說，SLA 不再只是內部 KPI，而是企業是否能跟上攻擊節奏的「生存指標」。
為了協助企業將這套作法制度化，下表提供了一個分層式（
然而，僅僅設定時程還不夠。
若要讓 KEV-first 修補策略真正奏效，必須把「執行」深度融入日常營運流程中。
也就是說，政策必須透過一致的行動反覆操練，
以下是完整 Playbook 中不可或缺的要素：
- KEV 情資的整合：
確保弱掃工具、資產盤點平台、ITSM 系統都能自動匯入 KEV 資料，並自動標記受影響資產，避免手動比對造成延遲與遺漏。 - 明確的角色分工與升級路徑：
清楚定義誰負責修補、誰負責風險接受、誰負責例外核准。
若補丁超過 SLA 未完成，系統須能自動升級到更高層級處理。 - 補丁驗證流程：
建立明確的測試 → Staging → 部署流程，尤其是邊界設備，必須避免補丁造成服務中斷，確保部署可控、安全。 - 桌上推演演練：
依照實際 KEV 條目，定期模擬攻擊情境，以測試：
✓ 修補反應速度
✓ 團隊協作流程
✓ 回滾（Rollback）機制是否可用
✓ 緊急情況下的溝通流程
一套 KEV-first 策略要真正有效，必須具備三個條件：
- SLA 是可持續達成的
- 責任歸屬沒有不確定性
- 流程持續被測試與驗證
否則，政策只是文件上的承諾，而非能真的降低風險的能力。
但如果這套策略落地正確，它不只降低被攻擊風險，
讓資安負責人有能力提出「真正的證據」，
這是一套能被驗證、能被審核、能被信任的安全框架。
實現真正可落地的 KEV-first 修補策略
只依賴 CVSS 分數來進行漏洞分類與排程（triage），
KEV 的價值就在於，它讓安全團隊把資源聚焦在「
將 KEV 完整導入日常作業流程，企業能獲得：
- 更快的修補週期
- 更完整且可稽核的追蹤軌跡
- 顯著降低的攻擊面
商業價值非常明確：安全事件更少、事件處理時間縮短、
資訊悅報 Vol.22｜Bitdefender: 安全工具越買越多，風險卻越來越高：為什麼中大型企業成了最大受害者？
部落格來源網址：Complexity In Security: Why It’s Hitting Hardest at Mid-Sized Organizations
如果要用一句話總結《Bitdefender 2025 資安現況評估報告》的主軸，那就是：原本用來保護企業的資安工具
多重工具重疊、解決方案過度複雜、法遵要求彼此拼布式（
評估結果揭露：安全複雜度的真實規模
Bitdefender 對 1,200 位 IT 與資安專業人士的調查顯示，目前最主要的資安挑戰依序為：
第一名：架構與工具的複雜度（31%）
第二名：跨環境防護延伸（29%）
第三名：內部技能缺口（28%）
第四名：工具太多、難以管理（27%）
資安複雜度的成因：從人力到工具，問題彼此緊扣
Bitdefender 網路安全服務 總監Nick Jackson 與組織密切合作，他觀察到這些複雜度問題其實彼此高度連動：
「你看著這個挑戰清單，很容易就能把它們連成一條線。技能不足，
他補充：
「法規也越來越多，工具彼此未必相容，流程也越堆越厚，
更糟的是，複雜度還衍生另一個風險：能見度不足。
高達 77% 受訪者坦言他們對自身環境缺乏足夠的洞察力。
複雜性：中大型企業面臨的雙重風險
大型企業有龐大的資安團隊與成熟架構，本來就複雜。
- 資源不足，卻要管理越來越多的工具
- 攻擊者開始以「中型企業」作為與大型企業同等級的目標
Bitdefender 技術解決方案總監 Martin Zugec 說得很直白：
「攻擊者不再在乎你是哪個產業，而是你用的是哪些軟體、
他點出複雜度的核心問題：
「我們總是買那個功能最多、打勾框最完整的產品。
這就是核心困境：
許多中大型企業導入了企業級的資安堆疊，
結果就是一片難以整合的工具叢林，既難優化、也不具效率。
合規法遵壓力：讓複雜度再加一層
25% 的受訪者表示，遵循 GDPR、CCPA 等法規要求本身就是主要挑戰之一。
諷刺的是：為了合規，企業往往再添購一套工具或報表系統。
看起來像增強管控，實際上卻：增加更多孤島、更破碎的流程、
當複雜度變成真正的風險
每多一層複雜度，就多一層攻擊面：
- 更多整合 → 更多配置錯誤
- 更多供應商 → 更多第三方風險
- 更多單點工具 → 更多告警、更多盲點
而企業新增工具的速度，往往還比不上整合的速度，
簡化與策略性夥伴：未來必須採取的方向
好消息是：簡化並不等於功能縮水。
真正的簡化，是：
- 使用單一統一平台，而不是堆疊不同產品工具
- 用整合式架構保護端點、雲端、身分、網路
- 透過自動化接手雜務減少手動作業，讓人力花在真正重要的地方
對許多企業來說，導入 MDR（託管式偵測與回應）是下一步必然選擇。MDR 不只是補人力，而是提供：
- 7×24 專家監控
- 統一事件分析
- 標準化回應流程
- 減少誤判與人力壓力
這讓複雜度不再成為壓垮團隊的重擔。
反應式到策略性：組織必須做的轉型
如何讓企業從複雜混亂 → 精簡有序 → 策略主導？
Nick Jackson 的建議很務實：
「你必須退一步，用策略思維問自己：我們最終想達成什麼？
Bitdefender 如何協助企業簡化資安
Bitdefender 提供多項協助降低複雜度的關鍵工具：
- 統一的 GravityZone 平台 ：單一 Agent、單一 Console
- GravityZone PHASR：主動強化與攻擊面縮減
- GravityZone Compliance Manager：合規自動化
- Bitdefender MDR 服務 ：專家託管 7×24 監控與回應
唯一目標就是：減少破碎化、提升能見度，並在攻擊發生前阻斷威脅
總結
複雜度不會自己消失。
如同調查所示，企業在面對攻擊者之前，
未來能真正提升資安韌性的企業，是那些
- 聰明整合，而非盲目堆疊
- 將瑣事交給自動化處理
- 與策略夥伴協作，而非單打獨鬥
相關網路研討會： 從人工智慧到攻擊面：2025 年形塑資安優先事項的關鍵因素
立即聯絡我們
資訊悅報 Vol.21｜CyberArk: 身分安全從人類到 AI，企業是否已跟上資料驅動的治理模式？
當我剛進入職涯、在加拿大某家銀行的交易大廳工作時，
這段經歷讓我學到一件事，也成為我與客戶溝通時最核心的觀念：
但我也見過完全相反的情況：身份安全像一台調校良好的機器，
真正的轉折點在於，我意識到「商業脈絡資料（Business Context Data）」才是缺失的那塊關鍵拼圖。
它是讓身份安全與效率連結在一起的核心要素。沒有它，所有權、
但一旦具備這層脈絡資料，合規就能從周期性作業，轉變成持續、
引擎教會我關於身分安全自動化的事
在進入科技產業之前，我曾經當過汽車技師。我調校過化油器、
這場效率競賽，推動世界從傳統化油器（想像 1985 年的 Honda Civic）走向數位化控制的電子噴射系統（例如 2025 年的 BMW 3 Series）。化油器必須靠人手反覆微調；
我在身分安全領域也看到很相似的情況。所謂的「效率」，
手動的合規流程就像化油器：被動、低效，而且高度倚賴人工調整、
自動化的控管則像現代的電子噴射系統：透過資料、感測、
商業脈絡資料如何讓「身分引擎」維持最佳狀態
那麼，究竟是什麼力量，讓企業能從手動合規邁向自動化合規？
答案就在於商業脈絡資料（Business Context Data）。
在身分安全中，商業脈絡資料就像現代引擎的感測器系統——
以稽核為例，稽核人員通常都會問一些再熟悉不過的問題：
- 這個帳號的擁有者是誰？
- 它的業務用途是什麼？
- 它能存取哪些系統或資料？
- 存取敏感度與風險層級為何？
這些問題完全合理，但大多數企業卻無法輕鬆回答。原因是：
身份相關資料往往散落在 HR 系統、應用清冊、工單系統、Log、SIEM、CMDB 等不同平台中，彼此缺乏連結。
每一次稽核都變成一場追逐「業務合理性、擁有者、權限、風險」
而商業脈絡資料能補上這道缺口。
它負責串聯各系統，並針對所有身份類型（包含人員、機器帳號、
- 業務合理性（Business justification）：身分／存取為何存在？目的為何？
業務擁有者（Business ownership）：誰負責此身分或存取？
技術擁有者（Technical ownership）：由誰管理、維運？
風險等級與風險標記（Risk rating & risk flags）：存取敏感度、控管要求、法遵標準。
當身分系統具備這些脈絡後，系統即可像「自動調校的引擎」一樣，
- 自動化生命週期管理（角色調整時自動調降或撤權）
- 風險優先排序（高價值資產套用更嚴格控管）
- 自動生成合規證據（因為系統永遠知道每個身分的 Who / Why / How）
當這些要素整合在一起時，身份安全就像運轉順暢的高效能引擎——
將身分資料轉化為「持續合規」
當商業脈絡資料被納入身分管理流程時，企業便能把合規從「
我曾經看到許多客戶在把身分資料與權威資料來源（如 HR 系統、ITSM、CMDB、應用清冊）串接後，
結論其實很簡單：當你用商業脈絡資料強化身分安全，
企業不再害怕下一次稽核，而是能更早做好準備、持續維持合規、
但理解商業脈絡資料為什麼重要，只是故事的一半。
這個過程需要調校、反覆迭代，以及一連串「以資料為基礎」
在多數企業中，商業脈絡資料其實早已存在——
如今，像 CyberArk 這類的平台已能在整個身分管理流程中，自動同步、
將身分安全延伸到所有身分類型
要從人工流程轉向自動化，企業必須採取 全方位（holistic） 的方法，處理組織中各種不同身分類型所帶來的挑戰。
身分安全需要涵蓋多種截然不同的身分類型，
- 人類身份（Human identities）：
範例：具有薪資系統或 HR 系統存取權的員工
關鍵數據元素： 業務合理性、業務擁有者 - 機器身分（Machine identities）：
範例：用於自動化雲端備份的服務帳戶
關鍵數據元素： 技術擁有者、風險等級 - 人工智慧代理程式（AI Agents）：
範例：用於生成報表、存取財務資料的 AI 助理
關鍵數據元素： 業務合理性、風險標記（例如 SOX / PCI / 隱私相關）
當所有身分類型都在「正確的商業脈絡」下運作時，
就像引擎需要乾淨的燃料與即時感測器才能高效運作一樣，身分安全
從單一可信來源打造「持續合規」
當企業具備正確且完整的商業脈絡資料後，「持續合規（
一切從盤點（Discovery）開始──
透過將 HR、ITSM、CMDB 與各種雲端系統同步，你能維持持續的可視性與控管能力，
脈絡化後的身分，會呈現出可預測的模式
當所有身分被正確建置（onboard）到身分治理或特權存取（
- 高價值資產 → 必須套用更嚴格控管
- 中低價值資產 → 套用分級治理（Risk-Proportionate Controls）
當策略與實際風險相互對齊後，團隊就能減少噪音，更有效率地落實
自動化建置讓缺口在形成前就被封閉
下一步，是在身分生成的瞬間（例如伺服器建立、應用部署、
這能確保新憑證、新帳號、新工作負載在產生的第一秒就被保護，
從反應式 → 持續式：自動化讓身分治理真正「活起來」
隨著自動化逐漸成熟，身分管理會從過去的被動、事件觸發，轉變為
- 角色改變 → 存取權限自動調整或撤銷
- 不必要權限 → 自動識別並移除
- 每一次變更 → 自動記錄、作為稽核證據
換句話說，身分治理不再依賴人工追蹤，
持續合規真正落地的時刻，是當企業做到以下四件事：
- 身分流程在「申請階段」就能蒐集業務合理性：
也就是在請求權限、請求帳號、請求憑證的當下，就直接取得用途、目的與業務責任，而不是等到稽核時才到處補資料。 - 自助化與自動化取代傳統工單流程（Manual Ticketing）
權限調整、憑證續期、帳號管理等作業不再需要人工核准或等待工單輪班， 而是依政策自動化處理。 - 以量化指標追蹤效率，包含：
孤兒帳號減少率（Orphan Account Reduction）
憑證輪替平均時間（Mean Time to Rotation）
稽核時間節省（Audit Hours Saved）
透過可量化的 KPI，團隊能清楚看到治理改善的幅度。 - 合規流程直接嵌入日常營運（Embedded Compliance）
不再是「每年一次的大型專案」，而是作為日常營運的一部分，自動生成可稽核的證據。
當這套機制運作順暢時，安全團隊便不再受制於前期準備工作，
成果：一套能「自我證明」的合規系統
當這些最佳實務真正落地後，企業能立即感受到、
那些以商業脈絡資料調校身分安全的組織，
- 稽核準備時間從數週縮短到「立即可供稽核」的狀態
- 孤兒帳號與殭屍帳號大幅減少甚至消失
- 政策能更一致地套用在人類、機器帳號與 AI agent 上
- 合規程度更貼近 SOX、PCI DSS 及 HIPAA 等法規要求
我看過許多企業從「被動式、清單驅動」的稽核模式，轉變成「
而所有成功案例背後的共同核心，就是商業脈絡資料。
它就像感測器資料一樣，推動整體的效率、韌性與信任。
當身分安全順暢運作到這個程度時，稽核不再是一種負擔，
證明這個組織確實做到它承諾的事──保護人員、保護系統、
Lorie Papple 現任 CyberArk Solutions Engineer，專注於企業身份安全與機器身分治理技術。
立即聯絡我們
資訊悅報 Vol.20｜REFORM DEPLOY : 讓交付快3倍、省一半人力：Platform Engineering 為何取代 DevOps？
部落格來源網址：Platform Engineering vs DevOps: How Different Are They?
Platform Engineering vs. DevOps：它們有多不一樣？
DevOps 與 Platform Engineering（平臺工程）
它們是不是同一件事的兩面？或是，
事實上，兩者確實在提升應用交付流程方面有許多共通點，
你是否只要有一支開發團隊，就算是「正在做 DevOps」？
或是當你開始負責團隊使用的工具與基礎架構時，就已經成為「
更重要的是——這兩種方法各自帶來哪些關鍵優勢，
這篇文章將帶你釐清 DevOps 與平臺工程的本質，了解它們的異同，並提供實際洞見，
什麼是 DevOps？
過去，應用開發（Development）與系統維運（
直到 2016 年，Amazon 技術長 Werner Vogels 提出那句著名的理念：「你打造它，就要負責運行它（You build it, you run it）」，正式揭開 DevOps 思維的時代。
自此之後，DevOps 的概念被廣泛採用：開發與運維團隊密切合作，透過持續整合（
自動化流程大幅減少人為錯誤，讓軟體交付更快速、更穩定、
然而，DevOps 不只是技術或工具的集合，而是一種文化與思維的轉變。
它倡導團隊間的透明協作、共享責任與持續學習，
DevOps 的挑戰
隨著 DevOps 成為業界主流，
除了要熟悉各式雲端工具與自動化技術外，
這樣的要求導致開發人員長期面臨資訊過載與高壓負荷，
DevOps 的優勢
儘管挑戰不少，DevOps 的價值仍十分明確，它能帶來以下四大效益：
1. 更快的產品上市時間
透過 CI/CD 流程整合，DevOps 能加速開發與部署，使產品能更快回應市場需求。
2. 自動化提升效率
自動化測試、部署與監控等重複性工作，減少人為錯誤，
3. 跨團隊協作更順暢
DevOps 打破開發與運維的隔閡，推動透明與高效率的協作文化。
4. 資源最佳化與成本下降
自動化與流程優化能降低人工作業成本，讓資源運用更精準，
從 2000 到 2020 年的開發者「認知負荷（Cognitive Load）」呈現持續上升趨勢，DevOps 雖提升效率，但也讓團隊面臨越來越高的技術與資訊壓力。
表格：認知負荷趨勢（2000-2020）
什麼是 Platform Engineering（平臺工程）？
平臺工程專注於設計、打造與維護自助式（Self-
平臺工程透過簡化 CI/CD、自動化部署與全程監控，
簡單比喻：
如果應用開發像經營一間餐廳，開發人員就是廚師；
他們維持一個「乾淨、透明、高效」的廚房環境，
最終目標很明確——讓每個人都能專注在自己最擅長的領域，
Platform Engineering 的優勢
根據多份業界報告與研究，平臺工程已為企業帶來可量化的績效改善
在 Puppet 發布的《State of Platform Engineering 2023 調查報告》中，高達 94% 的受訪者認為平臺工程讓他們更能發揮 DevOps 的效益。
其中包括：
- 系統穩定度提升（60%）
- 團隊生產力與效率提升（59%）
- 工作流程標準化改善（57%）
多數企業一致認為：平臺工程讓開發者「工作更輕鬆、交付更穩定、
除了上述效益外，平臺工程還能：
- 透過標準化流程，大幅降低開發者的認知負荷（Cognitive Load）
- 提升開發與營運團隊的整體生產力
- 增強系統的可擴充性與可靠性
- 維持流程一致性與合規治理
- 提升資訊安全，減少人為錯誤
- 以自動化降低成本，同時鼓勵創新與持續改善
Platform Engineering 的挑戰
然而，導入平臺工程並非一蹴可幾。
一個有效的平臺工程方案，必須被視為「產品（Product）」
這意味著：平台需要根據「使用者需求」——
如果平臺工程團隊沒有與 DevOps 團隊緊密合作，或未納入實際開發者的回饋，就可能導致：
- 平台無法符合實際使用情境；
- 投入高昂卻產出有限；
- ROI（投資報酬率）下降；
- 開發者反而覺得工作變更麻煩。
此外，平台的運作也需要長期的維運資源與專業支持。
閱讀更多： 何謂平臺工程？您是否需要它？
Gartner
DevOps vs Platform Engineering：在應用開發與交付上的差異
DevOps 與平臺工程（Platform Engineering）之間的差異其實相當明顯。
DevOps 是一種文化與方法論，強調開發與運維團隊的緊密協作，
相對地，平臺工程的重心則在於設計與維護一個自助式的開發平臺，
藉由標準化的流程與工具組合，協助開發者減輕認知負荷（
DevOps vs Platform Engineering 全面比較
DevOps 與 Platform Engineering 的簡易比較
在應用開發與交付的整體架構中，DevOps 與 Platform Engineering 既相輔相成，又各自扮演不同的關鍵角色。
1. 核心焦點（Primary Focus）
DevOps：
DevOps 是一種著重於「應用開發與交付流程」的思維與實踐模式。
它涵蓋從規劃、撰碼、測試、發布、部署到監控的完整生命週期。
透過持續整合（CI）、持續交付（CD）與自動化工具，
Platform Engineering：
平臺工程則著重於設計、建置與維護應用所依賴的基礎平臺。
平臺工程師的核心任務是確保整個開發平臺的安全性、穩定性與效率
2. 目標與任務（Objectives & Goals）
DevOps 的目標：
DevOps 旨在運用自動化的力量來簡化並加速應用交付流程，打破開發（
成功的 DevOps 團隊，能夠快速回應市場變化，穩定且無誤地交付高品質應用，
Platform Engineering 的目標：
平臺工程師的日常任務，則圍繞於了解與整合各團隊的實際需求，
平臺工程是一項持續性工作，需要快速回應業務變化與技術挑戰，
最終目標是為技術與業務團隊提供穩定、可擴展的基礎環境，
3. 思維模式（Mindset）
DevOps：
DevOps 團隊以「專案導向（Project-Oriented）」為主，
然而，隨著工具鏈與基礎架構的快速膨脹，DevOps 團隊除了開發與維運外，還必須兼顧安全、合規與文件維護等責任，
Platform Engineering：
平臺工程師則採取「產品導向（Product-
他們會傾聽開發、運維與業務團隊的挑戰與需求，
此外，平臺工程師也負責在組織內推動思維轉型（Mindset Shift），說明平台價值、提升跨團隊協作。
可以說，平臺工程師是應用交付流程中最關鍵的「協調者」與「
Platform Engineering 是否比 DevOps 更適合應用開發？
要比較 DevOps 與 Platform Engineering 誰「更好」，其實就像在比橘子與紅蘿蔔——兩者本質不同，
在核心理念上，DevOps 與 Platform Engineering 都是為了打造更高效、更穩定的應用交付體驗。
DevOps 的重點在於加速應用開發與部署，而 Platform Engineering 則扮演強化與穩定現有 DevOps 環境的基礎引擎。
它提供一個穩固的平台架構，
然而，若真正了解 何謂平臺工程 的運作原理，你也會發現——並
那麼，該如何判斷「你的企業是否需要它」呢？
你的企業是否需要導入 Platform Engineering？
在跳上平臺工程列車」之前，
根據 RE:FORM 的實務經驗，當企業具備以下條件時，導入平臺工程最能發揮成效：
- 擁有明確的數位轉型目標與商業願景
若你的公司正積極推動數位轉型，Platform Engineering 能加速落地與執行。 - 團隊跨部門協作頻繁且流程複雜
當多個部門（如開發、運維、安全、業務）同時參與交付時，容易出現混亂與溝通落差， 平臺工程能有效建立一致標準與透明流程。 - 應用部署頻繁且更新速度快
若公司每週甚至每日都有新版本上線，Platform Engineering 可讓自動化與治理同步進化；但若部署頻率較低，導入成本可能高於效益。 - 企業正準備快速擴張規模
當產品或服務已經成熟並進入成長期，平臺工程可協助你在不增加人力的情況下快速擴張， 同時降低人為錯誤與環境風險。 - 團隊熟悉 DevOps 文化與敏捷開發模式
Platform Engineering 並非取代 DevOps，而是延伸並強化 DevOps 的實踐。
若你的團隊已具備敏捷文化與持續回饋機制，那就已經做好導入的準備。
我該如何開始導入 Platform Engineering？
想知道平臺工程如何幫助你優化應用交付效能嗎？
RE:FORM 提供 All-in-One 的 Platform Engineering（平臺工程）解決方案，結合智慧化、
無論你目前的 DevOps 成熟度為何，RE:FORM DEPLOY 都能幫助你加速、簡化、並穩定整個交付旅程。
立即聯絡我們
2024年10月21日【《2025 NMT 資安即未來論壇》－新竹場】
活動地點：新竹喜來登飯店 3F 東館宴會廳III
議程時間：2025/10/21 (二) 15:20-15:50
演講題目：《向左走的資安：憑證管理自動化 ＆ 漏洞 AI 修補》 – 力悅資訊 總經理 / 彭國達
議程時間：2025/10/21 (二) 15:20-15:50
演講題目：《向左走的資安：憑證管理自動化 ＆ 漏洞 AI 修補》 – 力悅資訊 總經理 / 彭國達
.
在 AI 驅動的資安新時代，傳統「被動偵測」已不足以因應日益複雜的威脅。力悅資訊將分享「向左走的資安」理念，從憑證管理自動化到 AI 驅動的漏洞修補，說明如何以早期防禦、快速修復與自動化機制，協助企業實現零信任防護，避免營運中斷與資安風險，邁向高效率與永續的資安治理未來。
.
感謝當天不論在現場或是線上聆聽議程的朋友們！
如欲了解當天活動的更多解決方案細節，歡迎隨時與我們的業務夥伴聯繫
.
#網路資訊 #NMT資安即未來論壇 #AI資安 #零信任 #憑證管理自動化 #AI修補 #漏洞修補 #力悅資訊 #CyberviewCloud
資訊悅報 Vol.19｜Vicarius: 每年超過 40,000 個 CVE 爆發後，傳統漏洞管理還撐得住嗎？
部落格來源網址：How Modern Vulnerability Management Keeps Up with 40,000+ CVEs
隨著漏洞揭露數量持續暴增，「漏洞管理（
僅在 2024 年，就有超過 40,000 個 CVE（Common Vulnerabilities and Exposures） 被公布，比 2023 年的 28,961 個再度大幅成長。
傳統的漏洞掃描機制早已不足以因應這樣的速度。
現代企業需要的是結合 持續監控（Continuous Monitoring）、漏洞掃描（Vulnerability Scanning） 與 風險導向優先排序（Risk-Based Prioritization）的新一代漏洞管理架構。
因為駭客往往能在幾天內就利用新漏洞展開攻擊。
只有持續監控能及時偵測新風險，
出現的漏洞，而基於風險的優先級排序則決定應修復哪些漏洞。
為什麼「定期掃描」的時代已經結束
過去多年，企業普遍採取「每月、每季、甚至每年」
如今，新漏洞每 17 分鐘就會出現一次 ，而攻擊者只需 5 天 就能將漏洞武器化、實際利用。沒有持續監控的防禦機制，就代表在兩次掃描之間的數週或數月內，
現代化的漏洞管理平台能針對地端與雲端環境進行近乎即時的動態評
讓「從發現漏洞到完成修補」之間的落差大幅縮短。
但光有掃描還不夠，企業必須導入「風險導向優先排序」
用風險導向策略應對爆炸成長的漏洞數量
根據美國 NVD（National Vulnerability Database）資料，目前已追蹤超過 23 萬筆獨立漏洞記錄，而大型企業往往內部就有成千上萬個已知弱點。
事實上， 僅約 2%的暴露點會直接危及關鍵資產，75%的漏洞實為死胡同。
例如，EPSS（Exploit Prediction Scoring System）能預測哪些漏洞最可能被武器化，而像 CISA KEV 清單等資料能指出已被攻擊者利用的高風險項目。當持續監控偵測到
現代漏洞管理工具更能分析攻擊路徑（Attack Path），將漏洞結果與設定錯誤（
這種整合視角正是有效漏洞管理的關鍵。
持續自動化監控：現代漏洞管理的骨幹
想要在大規模環境中落實持續監控，自動化（
手動掃描已無法跟上現代基礎架構的速度。
雲端部署、微服務（Microservices）、
自動化掃描工具能與 CMDB（組態管理資料庫）及 雲端 API 整合，
在資產出現的瞬間即自動辨識並觸發掃描，確保不遺漏任何新節點。
在資產出現的瞬間即自動辨識並觸發掃描，確保不遺漏任何新節點。
這些自動化流程（Automated Pipelines）是現代漏洞管理的中樞，
能將偵測結果直接導入工單系統，追蹤修補進度並建立稽核紀錄。透過 「掃描＋持續監控＋風險導向優先排序」 的組合，資安團隊能專注於最有影響力的漏洞，並以自動化的節奏維
研究指出，自動化至關重要，
結合持續監控與暴露面管理（Exposure Management）
現代攻擊者不僅利用漏洞，還會結合錯誤設定、
因此，資安領導者逐漸採用 CTEM（Continuous Threat Exposure Management，持續威脅暴露管理）框架，
範疇定義（Scoping）→ 發現（Discovery）→ 優先排序（Prioritization）→ 驗證（Validation）→ 動員（Mobilization）。
這套流程強調的不只是掃描，而是持續監控與風險驗證。
藉由結合漏洞掃描與組態分析，
透過對漏洞、錯誤設定與身分風險的持續監控，
最終成果是建立一個「橫跨掃描、監控與優先排序」
實踐持續性漏洞管理的最佳做法
為有效實施持續監控與漏洞管理，請考慮以下實務做法：
1. 完整資產盤點（Asset Inventory）
你無法修補你看不到的風險。
透過自動化發現與持續監控整合，
2.採用持續掃描（Continuous Scanning）
從季度掃描轉向即時、持續性的評估。
讓系統在新資產上線時自動觸發掃描，成為漏洞管理的基礎。
3. 導入風險導向優先排序（Risk-Based Prioritization）
結合 CVSS、EPSS、CISA KEV 等指標，再依資產關鍵性與可利用性動態排序，聚焦真正威脅。
4. 自動化工作流程（Automate Workflows）
整合掃描工具與工單系統，讓高風險漏洞自動派單與修補。
自動化讓團隊能即時反應，保持修補節奏不間斷。
5. 納入暴露面管理（Exposure Management）
別只看軟體漏洞，也要檢視組態錯誤與身分風險。
暴露面管理能為風險排序提供更完整脈絡，確保防護面面俱到。
6. 教育用戶並衡量成效（Awareness & Metrics）
人為疏失仍是主要攻擊途徑。
持續的資安意識教育與量化指標（如平均修補時間 MTTR）能幫助組織優化整體防禦流程。
結語：漏洞管理不再是「定期檢查」，而是一場持續的攻防戰
季度掃描的時代已然終結。在每年數萬個新漏洞、
但「發現」並不等於「防護」。
風險導向優先排序（Risk-Based Prioritization）是將無數漏洞資料轉化為可執行行
現代漏洞管理講求三者的協作：
- 持續監控
- 漏洞掃描
- 風險導向優先排序
唯有三者相互結合，企業才能真正控制風險洪流。
透過自動化與脈絡化分析，漏洞管理不再只是「例行打勾」的項目，
在這個每 17 分鐘就有新漏洞誕生的世界裡，只有「持續防護（
立即聯絡我們
資訊悅報 Vol.18｜Bitdefender: 你的虛擬化主機，已經變成勒索軟體的新首要目標了嗎？
部落格來源網址：Why Hypervisors Are the New-ish Ransomware Target
資安最大的挑戰之一，就是威脅不停在換招。
這篇文章的目的，就是把最新的攻擊趨勢攤開來講，
現在的勒索攻擊團體（Ransomware Groups）刻意維持低調，避免被執法單位盯上或被制裁。
傳統「加密資料檔案」的勒索模式，從 2022 年開始一路在下滑，現在仍在下降。但這並不是好消息。相反地，
這個策略轉向，某種程度也解釋了一個很令人擔心的現象：
我們的推測是：攻擊者開始打關鍵基礎架構、動作越來越隱蔽，
在此期間，根據 Chainalysis 數據顯示，勒索軟體支付金額亦呈現下降趨勢。我們當然希望，
從「檔案被加密」到「整台機器起不來」
攻擊 Hypervisor 的目標，並不是去加密 Hypervisor 自己的核心系統，而是鎖死整台 Hypervisor 上跑的所有虛擬機（VM）。
因為現在企業內部的大部分 IT 基礎環境都已經虛擬化了，只要 Hypervisor 被入侵，攻擊者基本上就拿到整個公司的命脈，等於一拳打在中樞，
攻擊端點（工作站、伺服器本機）跟攻擊 Hypervisor，最大的差別在於「攻擊範圍」與「
傳統勒索打端點時，通常做的事是：
但攻擊 Hypervisor 是完全不同的打法。它直接下手在虛擬化管理層本身：入侵 Hypervisor 後，攻擊者會把上面所有 VM 的虛擬磁碟檔案整批加密。結果就是——這些 VM 直接無法開機。你的應用系統、後端服務、關鍵伺服器，
這不只是「資料不可讀」的問題，而是「整個 IT 環境被打到完全不能運作」。本質上，這是一種從「影響單一機器」
攻擊 Hypervisor 的目標，並不是去加密 Hypervisor 自己的核心系統，而是鎖死整台 Hypervisor 上跑的所有虛擬機（VM）。
因為現在企業內部的大部分 IT 基礎環境都已經虛擬化了，只要 Hypervisor 被入侵，攻擊者基本上就拿到整個公司的命脈，等於一拳打在中樞，
攻擊端點（工作站、伺服器本機）跟攻擊 Hypervisor，最大的差別在於「攻擊範圍」與「
傳統勒索打端點時，通常做的事是：
但攻擊 Hypervisor 是完全不同的打法。它直接下手在虛擬化管理層本身：入侵 Hypervisor 後，攻擊者會把上面所有 VM 的虛擬磁碟檔案整批加密。結果就是——這些 VM 直接無法開機。你的應用系統、後端服務、關鍵伺服器，
這不只是「資料不可讀」的問題，而是「整個 IT 環境被打到完全不能運作」。本質上，這是一種從「影響單一機器」
為什麼攻擊者開始鎖定 Hypervisor？
勒索組織基本上是很務實的犯罪集團。他們做每一步，都是算過投報率（ROI）。也就是說，他們不是迷信媒體炒作的「AI 超級駭客神技」，而是選擇最有效、最賺、風險最低的路徑。例如：打邊界設備（edge devices）、打關鍵基礎架構（像虛擬化平台），而不是炫技。
當我們觀察到多個勒索即服務（RaaS, Ransomware-as-a-Service）集團同時開始用一樣的手法，幾乎可以確定：這不是巧合，而是這條路真的「好用又好收」。
跨作業系統（OS-Independent）語言帶來的新武器
讓攻擊者更容易鎖定 Hypervisor 的一個關鍵因素，是他們開始大量使用支援多平台編譯的現代語言，
這些語言讓他們可以用同一套原始碼，
過去，勒索程式往往得為單一平台客製（例如只針對 Windows）。現在，攻擊者只要寫一個 Golang 或 Rust 的「加密器（encryptor）」，就能同時打到：
- Linux-based 的 VMware ESXi Hypervisor
- 傳統 Windows 或 Linux 伺服器
針對虛擬化管理程式的關鍵驅動因素，在於運用現代跨平台語言，
這表示什麼？表示他們可以一套武器吃多種環境，擴張非常快，
「影響面縮到最小、施壓力道反而更大」
勒索集團的生意模式，說白了就是「勒索＋談判」。
打 Hypervisor 對他們有幾個超現實的優勢：
- 他們可以直接把關鍵後端基礎架構（後端系統、資料庫、服務 VM）加密鎖死，但終端使用者（一般員工 PC、前台系統）一開始還能正常登入、正常用。
- 對一般員工來說，只是覺得「系統怪怪的、系統掛了」，
很像日常的系統當機，沒人會立刻大喊「我們被勒索了」。 - 這和傳統勒索很不一樣：
傳統勒索是每一台被感染的電腦都跳勒索告示， 整家公司瞬間都知道出事，媒體甚至馬上有風聲。
對攻擊者來說，低噪音代表什麼？代表壓力被「鎖在 IT 團隊的房間裡」，不一定馬上變成公關危機或法遵問題。
這一點，對受害企業（尤其是關鍵基礎設施、受法規約束的單位）
更高「成功復原率」= 更高談判籌碼
攻擊 Hypervisor 還有一個讓勒索集團超愛的優勢：他們提供的解密工具，
原因在於流程設計本身。攻擊者在加密前，會先把所有 VM 都正常 shutdown。這代表：
- VM 裡的檔案都關閉，不在使用中
- 不會有「檔案被占用所以沒加密到」的遺漏
- 虛擬磁碟檔案（vmdk 之類）是穩定靜止狀態下被加密
結果是：加密幾乎可以做到「接近完美」。
那解密呢？因為被加的是 VM 磁碟檔，而不是散在各台端點的各種資料夾，所以事後只要在 Hypervisor 上跑一次解密工具，就有機會整批把虛擬機復原，
這種「高成功率的解密承諾」，反過來會提高受害公司「
安全管控面的斷層
在很多企業裡，Infra / 系統管理團隊的 KPI 是「穩定營運、不中斷」，不是「資安零風險」。結果往往是：
最典型的案例之一是 CVE-2024-37085。這個弱點被像 Black Basta、Akira 這類勒索集團實際利用過。問題點在於：
- 只要 ESXi Hypervisor 有加入網域
- 網域裡只要有一個名叫「ESX Admins」的群組
- 任何被加進這個群組的人，就自動拿到該 ESXi 的完整系統管理權限
而且重點是：Hypervisor 不會去檢查這個群組是不是合法的、SID（安全識別碼）
也就是說，一個已經摸進內網的攻擊者，只要在 AD 裡新建一個群組、或把一個群組改名成「ESX Admins」，再把自己帳號丟進去，他就秒變整個 ESXi 叢集的超級管理員。這是設計層級的致命洞。
另一個大家應該都聽過的例子是 ESXiArgs 勒索行動。該攻擊大規模利用 OpenSLP 服務的已知弱點（CVE-2021-21974）拿下成千上萬台 ESXi 主機的控制權。問題在於，修補程式其實早就釋出快兩年了，
還有一個現實問題：很多 Hypervisor 本身官方並不支援在宿主層安裝 EDR / XDR Agent。廠商往往建議「你在每台 VM 裡面裝安全代理就好」。但如前面所說，Hypervisor 攻擊手法是先把 VM 關機再加密磁碟，VM 裡的 EDR 完全派不上用場。等於傳統端點型防護直接被繞過。
把壓力集中在最小的一群人：IT
最後一個殘酷的現實：攻擊 Hypervisor 的副作用，是把全部壓力直接丟在內部最小的一個團隊上——系統/
這不是像傳統勒索那樣，整家公司幾千個使用者報案說「
相反地，Hypervisor 攻擊的後果，瞬間集中在一小群關鍵技術人員身上：
- 他們要緊急救服務
- 要面對停機壓力
- 還要跟對方談判
- 還要同時回報 CIO / 董事會「什麼時候可以復原」
換句話說，攻擊者是故意「把人關進小房間裡壓著談」，
案例觀察
多個勒索即服務（RaaS）集團已經證實會直接鎖 Hypervisor。對這些成熟的勒索營運團隊來說，
CACTUS
CACTUS 是一個很典型的「多平台勒索」案例。
這個團隊在同一波攻擊裡，同時針對 Hyper-V 跟 ESXi；
- 對 Hyper-V（偏 Windows 陣營）用他們原本的 Windows 勒索程式
- 對 ESXi（偏 Linux-based）則丟進去客製版的加密工具
攻擊流程非常工整：他們會把客製工具複製到 ESXi 主機上，給它執行權限，然後用指定參數啟動。指令可以很細，
RedCurl
RedCurl 通常被描述成「企業間諜型」攻擊者，但有一個相當可信的推測是：
我們觀察到一個很有意思的手法：RedCurl 在執行攻擊時，會刻意「不加密」負責網路路由／連線的那些關鍵 VM。也就是說，內網網路還會留著、基礎連線還可以用，
其他 RaaS 組織
我們也看到其他成熟勒索團體或其後繼者延續同樣套路：
- LockBit：長年高知名度的勒索集團，早就有針對 ESXi Hypervisor 的 Linux 版加密器。
- BlackCat / ALPHV：相當具侵略性的 RaaS，雖然目前受到重大打擊與瓦解，但他們用 Rust 寫加密器的作法，讓惡意程式可以很快適配不同作業系統。
- ESXiArgs：嚴格說來它比較像是一個勒索家族，
而不是單一組織；它以大規模、機會型（ opportunistic）的掃描攻擊成名， 鎖了上千台未修補的 ESXi。即使原始行動告一段落，那套手法仍在被其他團體複用。 - Hunters International：這個團隊是在接手 Hive 勒索組織的原始碼與基礎架構後浮上檯面，延續並改良原本的 ESXi 加密能力。
- RansomHouse：已知會針對 Hypervisor 投放名為 MrAgent 的客製工具，重點是自動化，把所有受控的 VM 一次性鎖死。
- Scattered Spider：這個團體一開始通常用社交工程釣客服務台（
Help Desk），騙到內部權限後，再往上竄升到高權限帳號。 它們不只靠自己一套工具，而是直接跟其他 RaaS（例如 Akira、ALPHV、RansomHub）合作， 把各式各樣的 Hypervisor 加密器拉進自己武器庫。
要特別說明的是：RaaS 團體本身很常解散、改名、或被法辦。但武器（像是專門針對 Hypervisor 的加密器）、攻擊手法 SOP、談判腳本，會被轉賣或沿用。也就是說，就算某個名字「
建議與防禦重點
最基本的底線，真的就是把 Hypervisor 和它的管理軟體維持在最新可用版本，該打的補丁要打。
接下來幾個是不能退讓的底線：
- 一定要強制多因子驗證（MFA）
尤其是 Hypervisor 管理介面、vCenter / Hyper-V Manager 這類超管入口。
不要再用單一帳號密碼守國門。 - 最小權限原則（PoLP，Principle of Least Privilege）要真的落地
不該有誰拿到超管就一路暢行。帳號與服務帳號都只能拿到它工作所需的最低權限。
- 強化主機本身的防護面（Hardening）
停用不必要的服務（例如 OpenSLP 這類歷史包袱服務）、把管理介面鎖在專用的管理網段，用防火牆規則限制誰能連、從哪裡連。
- 偵測＋回應是標配，不是選配
像 Bitdefender GravityZone 這類 EDR / XDR 平台，能提供關鍵的偵測與回應能力。但請注意，工具只是工具，還需要人來運營。
你可以自己建 SOC，也可以把 24×7 監控外包給像 Bitdefender MDR 這樣的託管式安全團隊，讓專業人員幫你看控管、幫你做關聯分析，而不是只丟一堆告警給你。
- 不要只做「事後反應」的資安模型
很多 XDR / EDR 的定位，還是偏向「發生了再處理」。
但像 Scattered Spider 這種社交工程＋橫向移動的攻擊速度非常快，還會用 Living-off-the-Land（LOTL，也就是濫用內建合法工具）來降低暴露度。如果你只等告警響， 再來跑 Playbook，往往已經太慢。
這裡的關鍵，是要在攻擊鏈裡「加摩擦、拖時間」，讓攻擊者沒辦法一路暢行，逼出他們的行為特徵， 讓你提早抓到異常。
Bitdefender 的 PHASR（主動強化與攻擊面縮減，Proactive Hardening & Attack Surface Reduction） 就是為此設計：
-
- 它會分析實際使用者行為，為「每一個人」、「每一台機器」
動態建立自己專屬的行為輪廓， 而不是用死板的部門角色或職稱去套政策。 - 它會把這些行為輪廓拿去對照已知威脅集團的手法，
一旦偵測到高風險動作（例如大量關閉 VM、批次存取虛擬磁碟、異常權限提升）， 就能主動建議或自動下政策去擋。 - 重點是：在不影響日常營運的前提下，實際「壓縮攻擊面」。
- 它會分析實際使用者行為，為「每一個人」、「每一台機器」
- 備援不是「有備份就好」
你的最後一道防線是復原能力，但這一層必須假設「攻擊者已經拿到高權限，甚至會試圖破壞備份」。
現在業界公認的高標準是所謂的「3-2-1-1-0 備援準則」：
-
- 至少保留 3 份資料備份。
-
- 放在 2 種不同媒介。
-
- 其中 1 份要異地保存。
-
- 再加 1 份必須是不可變更（Immutable）或等同離線隔離（
air-gapped），攻擊者拿到系統權限也刪不了、 也加不了密。
- 再加 1 份必須是不可變更（Immutable）或等同離線隔離（
-
- 最後的「0」代表「零意外」，也就是你要定期演練還原，
確定備份真的救得回來，而不是紙上談兵 。
- 最後的「0」代表「零意外」，也就是你要定期演練還原，
同時，企業也必須針對「Hypervisor 遭攻擊」情境，事先寫好、練過的事件應變流程（Incident Response Plan）。
這份計畫至少要包含：
- 如何快速隔離／下架被入侵的 Hypervisor 主機，避免感染擴散
- 誰負責對內溝通、誰負責對外溝通（從一般員工到董事會、
甚至對主管機關） - 復原順序與開機順序，而不是「全部一起硬啟」
說清楚白話一點：不要等整個虛擬化叢集被鎖死後，才開始問「
立即聯絡我們
資訊悅報 Vol.17｜CyberArk: 一張過期憑證，讓整個企業停擺？ 揭開「機器身分失控」你看不見卻最危險的資安風暴！
部落格文章出處：The invisible threat: Machine identity sprawl and expired certificates
一個「未受管控」的機器身分，就足以讓整個企業停擺！
只要一個未受管控的機器身分——無論是一張TLS憑證、
沒有人能倖免。事實上，過去 24 個月有 83% 的企業組織 在過去24個月內曾發生過憑證相關的中斷事件。即使是科技巨頭，
問題的根源在於：
- 組織每新增一個應用程式、API、連線工作負載或自動化流程，
就會產生一個機器身分 - 這可能是一張 TLS 憑證 、一把SSH金鑰、一張程式碼簽章憑證，
或一個API秘密金鑰。 - 當這些身份橫跨混合與多雲環境迅速擴張時，
資安團隊必須管理的數量動輒上萬。
而一旦缺乏管控，這些「無主機器身分」將成為一種無聲卻致命的中
為何機器身分暴增成為企業新危機？
沒有機器身分，系統根本無法運作。
這些身分是讓應用程式、AI 代理 、伺服器、機器人與IoT裝置能安全交換資料的信任基礎。
但當數位生態系爆炸性成長時，這些身份的管理變得愈來愈複雜，
1. 數量爆炸
成千上萬、甚至百萬等級的識別（TLS 憑證、SSH 金鑰、程式碼簽章憑證、雲端存取金鑰與 API 機密）如今在應用程式、API、伺服器與工作負載中悄然擴散，
隨著 AI 代理與自動化程式的普及，每一個自動流程都需要新的金鑰、
2. 生命週期加速
數位憑證的使用壽命正在縮短。由於新的安全命令與瀏覽器規範，
94% 的資安主管擔心其組織尚未準備好面對更短的憑證壽命——
3. 管理複雜度攀升
從金鑰格式到加密標準再到 後量子密碼學（PQC），
結果是：機器身份爆炸（Machine Identity Sprawl）已成為營運中斷、
能見度不足如何導致中斷與合規風險
大多數企業組織根本不知道自己擁有多少機器身分，
在沒有中央可視性的情況下，
重複因憑證過期而造成的連續中斷不僅消耗團隊士氣，
對於資安長（CISO）來說，這會成為一個極為棘手的營運問題。
- 營收損失：一張過期的憑證就可讓 API、數位服務或網站停擺，每小時造成數百萬的損失。一個被遺
忘的雲端存取 Token 也可能觸發停機或服務中斷。 - 法規風險：當過期、未被追蹤或設定錯誤的憑證導致敏感資料外洩時
，企業組織可能違反GDPR、HIPAA 以及 PCI DSS 等法規。 - 聲譽受損：每一次數位中斷都是削弱信任的考驗。當「安全」系統頻
繁當機或發生合規失誤時，導致客戶轉向競爭對手。 - 安全威脅：攻擊者會把未被控管的身份視為橫向滲透和勒索軟體攻擊
的切入點。被遺忘的 SSH 金鑰尤其危險，因為它們不會過期，且可能在被發現之前默默提供持 續的存取權限。
隨著憑證的有效期限持續縮短，而企業組織同時倚賴越來越多樣化的 SSH 金鑰、機密憑證與程式碼簽章證書時，
實務對策：從失控到掌控
首先，組織必須建立明確的政策及全組織一致的憑証管理標準。清楚
接著：朝自動化邁進。隨著憑證有效期限日益縮短且環境日益複雜，
以下是自動化憑證生命週期管理如何消除盲點並協助資安團隊專注於
將憑證風險轉化為安全與合規優勢
過去被視為「後勤 IT 問題」的憑証管理，如今已成為董事會層級的優先議題。
機器身份安全不僅關乎系統穩定，更直接影響企業韌性、
透過主動式管理與自動化治理，
結論很明確：別讓看不見的複雜度擾亂你的未來。
自動化、以政策為導向的機器身分管理——涵蓋憑證、SSH 金鑰、程式碼簽章憑證與機密資訊，並具備嚴格治理——
CyberArk Certificate Manager（SaaS／Self-Hosted）
讓您以自動化方式安全掌控所有機器身分：
- 自動盤點與發現：即時找出所有TLS憑證與金鑰。
- 自動續期與部署：在憑證到期前完成更新，不需人工干預。
- 整合CA與DevOps工具鏈：支援ACME、Jenkins、
cert-manager、ServiceNow。 - 合規報告與稽核追蹤：即時掌握誰發出、哪裡使用、何時失效。
別再讓 Excel 當你的防線。
以 CyberArk Certificate Manager 讓憑證管理邁向零中斷、零人錯、零罰則的新世代。
Florin Lazurca 是 CyberArk 的產品行銷總監。
