安全基準提供的是控制要求，但真正進行系統設計時，還需要將這些要求轉換成架構上的決策，讓安全控制成為架構設計的一部分。

從安全控制回到架構設計

前面的內容分別介紹了 CIS Benchmark 如何整理安全控制，以及 Microsoft Cloud Security Benchmark 如何將這些控制進一步對應到 Microsoft Cloud 的平台能力。到了實際的架構設計階段，架構師面對的問題就會從「有哪些安全控制」轉變成「這些控制應該如何反映在架構中」。

例如，安全基準要求落實適當的身分與存取控制，架構師就需要進一步思考系統應該採用什麼樣的身分架構；如果控制要求網路隔離，就需要在架構中考量網路區隔、流量路徑與信任邊界；如果要求重要資料受到保護，則需要進一步思考資料存放位置、加密方式以及金鑰管理機制。

因此，安全控制本身並不是架構設計的答案，而是提供架構師進行設計時需要滿足的安全條件。

安全控制如何轉換成架構設計

從架構師的角度來看，可以將這個過程理解成一個由需求逐步往下展開的過程。

首先，從架構所面對的業務需求、資產與風險出發，確認需要處理哪些安全問題；接著參考適用的安全基準，找出對應的控制要求；最後，再依據平台能力與系統特性，決定這些控制應該如何反映在實際架構中。

例如，一個系統需要降低未授權存取的風險，對應到安全控制後，可能涉及身分驗證、多因素驗證、最小權限以及特權存取管理等要求。架構師接下來就需要將這些要求轉換成實際的架構決策，例如身分服務如何配置、使用者與工作負載如何進行身分驗證，以及高權限操作如何與一般操作區隔。

同樣地，如果系統需要降低網路暴露風險，安全控制可能要求適當的網路隔離與存取限制，而架構設計就需要進一步決定網路區域如何劃分、哪些元件可以直接對外，以及不同元件之間允許哪些通訊。

因此，安全控制描述的是需要達成的安全要求，架構設計則決定如何透過系統結構與技術元件來達成這些要求。

同一項控制可能對應多個架構決策

一項安全控制通常不會只對應到單一元件或單一設定，而可能同時影響架構中的不同部分。

以資料保護為例，控制要求可能涉及資料加密，但架構師需要考量的不只是「是否啟用加密」，還包括資料儲存在哪裡、資料傳輸經過哪些區域、金鑰由誰管理，以及不同資料類型是否需要採用不同的保護方式。

因此，在進行架構設計時，如果只將 Benchmark 中的控制項逐項打勾，很容易忽略控制之間的關係。真正需要處理的是，這些控制如何共同影響系統的架構、元件、資料流與信任邊界。

這也是為什麼架構師需要理解控制背後的安全目的，而不只是記住控制本身。

哪些安全要求需要在架構階段處理？

並不是所有安全控制都需要在架構設計階段完成，但有些控制如果沒有在架構階段納入，後續再補強可能會增加成本，甚至需要重新調整系統設計。

例如：

這些要求如果在架構設計階段就被納入，後續的平台設定與維運工作就能建立在既有的架構基礎上；反之，如果等到系統完成後才發現架構本身無法支援某項控制，往往需要重新調整元件、資料流或權限模型。

架構設計與平台組態並不是同一件事

安全控制進入架構設計後，還需要區分「架構決策」與「平台組態」之間的差異。

例如，架構師可能決定系統採用集中式身分管理、管理流量與使用者流量分離，以及重要資料必須使用加密儲存。這些屬於架構層面的決策。

至於實際使用哪一項 Azure 服務、如何設定網路規則、啟用哪些安全功能，則會進一步進入平台組態與實作階段。

因此，可以將兩者理解為不同層次：

安全控制 → 架構決策 → 平台實作

安全控制提供需要達成的要求，架構設計決定整體系統應如何滿足這些要求，而平台組態則將架構決策落實到實際環境。

避免安全基準與架構設計彼此脫節

如果安全基準與架構設計沒有建立對應關係，就可能出現一個常見問題：文件中已經存在安全要求，但實際架構卻沒有反映這些要求。

例如，安全基準要求重要系統必須受到網路隔離，但架構設計沒有明確定義信任邊界與網路區域；安全基準要求特權操作受到控管，但架構中卻沒有考量管理平面與一般使用流量的區隔。

這些情況並不一定代表控制本身沒有制定，而是控制要求沒有真正進入架構決策。

因此，在架構設計過程中，可以將適用的安全控制轉換成架構設計條件，並進一步確認架構是否已經提供滿足控制要求所需要的能力。如此一來，安全基準就不會只存在於檢查清單或文件之中，而能夠真正成為架構設計時的輸入。

從 Benchmark 到架構決策

從 CIS Benchmark、Microsoft Cloud Security Benchmark 到實際的架構設計，可以看到安全要求會經過不同層次的轉換。

CIS Benchmark 提供跨平台的安全基準；Microsoft Cloud Security Benchmark 將相關安全要求進一步對應到 Microsoft Cloud 的平台能力；到了架構設計階段，架構師則需要依據系統的需求與風險，判斷哪些控制適用，以及這些控制應該如何反映在架構中。

因此，架構師真正需要做的不是把 Benchmark 逐項搬進設計文件，而是理解控制的目的，再將控制要求轉換成架構決策。

小結

安全基準提供的是安全控制要求，而架構設計需要進一步回答這些要求應該如何落實在系統之中。

從風險與需求出發，經過安全控制的對應，再轉換成架構決策與平台實作，可以讓安全要求真正進入系統設計，而不是等到建置完成後才透過檢查發現缺口。

對架構師而言，重要的能力不是熟記每一項 Benchmark 控制，而是能夠理解控制背後的安全目的，並判斷哪些要求需要在架構階段處理，以及如何將這些要求轉換成實際的架構決策。

如此一來，Benchmark 不只是用來檢查已經完成的系統，也可以成為架構設計時的重要輸入。