安全基準不是憑經驗自行定義，而是以既有標準與實務經驗為依據，逐步形成企業一致且可落實的安全要求。

安全設定需要建立一致的基準

當企業開始建置新的系統時，經常會遇到一個很實際的問題：一套系統需要具備哪些基本的安全設定？

例如，一臺新的 Windows Server 應該關閉哪些服務？Linux 主機需要調整哪些系統參數？Kubernetes 叢集有哪些安全設定需要優先完成？不同的雲端服務，又應該啟用哪些安全功能？

這些問題看起來都是技術設定，但實際上往往沒有唯一的答案。上課時老師可能有說、參考書籍可能會寫、原廠也可能提供最佳實務（Best Practice），而工程師過去累積的經驗，也可能形成另一套做法。

問題就在於，當不同團隊依照不同的經驗進行設定時，即使最後系統都能正常運作，安全設定的完整程度與管理方式仍可能產生落差。久而久之，同一類型的系統可能出現不同的設定標準，也增加後續管理、稽核與安全檢視的複雜度。

因此，企業需要的不只是「這個產品要怎麼操作」的文件，而是能夠提供一致設定方向與安全要求的共同基準，讓不同團隊在建置與管理系統時，有一套可以參考、檢視與持續維護的標準。

而這樣的安全基準，不一定需要完全由企業自行從零建立。企業可以參考已經累積多年實務經驗的國際標準與安全基準，再依照自身環境與需求進行調整。

架構需求需要轉化為具體的安全控制

前面幾章談到架構分析時，我們從信任邊界（Trust Boundary）、攻擊面（Attack Surface）、高價值資產（Critical Assets） 以及 單點故障（Single Point of Failure） 等角度，逐步理解一套架構需要面對哪些安全與營運需求。

但架構分析完成之後，看到的通常仍然是風險、需求與設計條件，還不能直接變成工程師可以執行的設定。

例如，我們知道某個系統需要受到更嚴格的存取控制，但實際上應該如何設定？知道某些服務需要降低暴露風險，那麼主機、網路或平台層面又有哪些設定需要調整？當企業需要管理大量相同類型的系統時，又要如何確認每一套環境都符合基本的安全要求？

這中間其實存在一個重要的轉換過程：從架構與安全需求，逐步落實成可以被執行、檢查與維護的安全控制。

這也是企業需要參考安全基準的重要原因。透過既有的國際標準、產業最佳實務與技術基準，架構師與資安團隊可以將較高層次的安全要求，進一步對應到具體的設定與控制措施。

例如，CIS Benchmarks 就針對作業系統、雲端平台、資料庫、網路設備、容器與伺服器軟體等不同技術，提供具體的安全設定建議。CIS 官方也說明，其 Benchmarks 是由全球資安專家透過共識過程建立的安全設定指南。

因此，企業在建立自己的 安全基準（Security Baseline） 時，可以將這些成熟的國際基準視為參考（Reference），再根據企業的架構、風險、業務需求與營運條件，決定哪些控制應該納入、哪些需要調整，以及哪些情境需要建立例外。

但在真正納入之前，我們仍需要進一步檢視這些安全要求是否適合企業環境。對我而言，可以從三個角度來判斷：風險導向（Risk-Based）、可驗證（Verifiable） 以及 可實踐（Practical） 。

這三個面向分別協助我們確認：這項控制是否有明確的風險依據、是否能夠被客觀檢查，以及企業是否具備實際落實的條件。

風險導向（Risk-Based）：先理解控制要降低什麼風險

安全控制並不是愈多愈好，而是應該根據系統所面對的風險，決定哪些控制需要優先建立。

參考 CIS Benchmark 等國際安全基準時，可以進一步思考：這項安全要求究竟希望降低什麼風險？

例如，有些控制著重於降低未授權存取的風險，有些是為了保護系統與資料，也有些則是為了提升事件發生後的追蹤與稽核能力。不同控制所處理的風險不同，因此在企業實際建立安全基準時，也需要依據系統的重要性與風險情境，決定控制的適用範圍與優先程度。

因此，安全基準不是把所有控制全部套用，而是將需要管理的風險轉換成具體的安全要求。

可驗證（Verifiable）：安全基準需要能夠被客觀檢查

安全基準建立之後，還需要能夠持續確認這些要求是否真正落實。

如果安全要求只停留在「應該啟用」、「建議設定」或「需要做好管理」等描述，就很難判斷實際環境是否符合。因此，一項好的安全基準，應該盡可能將要求轉化成可以被客觀檢查的設定或狀態。

例如，某項功能是否啟用、某個組態是否符合要求、某項服務是否使用指定的安全設定，都應該能夠透過系統設定、組態檢查或管理工具進行確認。

如此一來，安全基準就不只是文件中的要求，而可以進一步被納入弱點掃描、組態管理、雲端安全平台或其他自動化檢查機制，持續確認環境是否維持在符合要求的狀態。

可實踐（Practical）：安全基準需要符合企業環境

即使安全要求具備明確的風險依據，也能夠被客觀驗證，如果實際環境無法落實，仍然很難成為企業真正採用的安全基準。

因此，在參考 CIS Benchmark 或其他國際標準時，還需要進一步考量企業自身的環境與限制，包括系統架構、業務需求、可用性要求、維運方式、法規要求以及管理成本。

例如，某項設定在一般環境中可能是合理的安全要求，但如果套用到特定業務系統後會影響既有功能，就需要進一步評估是否適用，以及是否存在其他方式可以達到相同的安全目的。

因此，參考國際標準不代表所有控制都必須原封不動套用。架構師需要理解控制背後的安全目的，再依據企業環境決定如何落實，必要時也可以針對特定情境建立例外管理與補償性控制。

安全基準真正建立的是一致的安全要求

當這些條件都被確認之後，國際標準就不再只是參考文件，而可以進一步轉化成企業自己的安全基準。

安全基準不是把 CIS Benchmark 或其他國際標準中的設定逐項複製，而是依據企業自身的架構、風險、業務需求與營運條件，整理出一套可以共同遵循的安全要求。

例如，同一項安全控制，在不同企業可能有不同的適用情境；有些控制可以直接納入標準，有些則需要依照既有架構調整，也可能存在因業務需求而必須保留的例外。這些判斷完成之後，才能形成真正適合企業的 安全基準（Security Baseline）。

而這套基準的價值，也不只是提供建置時的設定依據。後續還可以進一步納入建置流程、組態管理、稽核與持續監控，讓安全要求從一次性的設定，逐步成為企業日常架構治理的一部分。

因此，國際標準提供的是經過驗證的參考，企業需要做的則是將這些參考轉化成符合自身需求、可以持續執行的安全基準。

小結

CIS Benchmark 的價值，在於提供一套經過大量實務經驗累積的參考依據，讓企業在面對系統設定與安全控制時，不必完全從零開始思考。

但真正的架構工作，仍然是理解這些控制背後要解決的問題，再依據企業自身的架構、風險與營運條件進行判斷。

透過 風險導向（Risk-Based）、可驗證（Verifiable） 與 可實踐（Practical） 三個面向，架構師可以進一步判斷哪些控制值得採用、如何確認控制已經落實，以及如何讓這些要求真正進入日常的建置與治理流程。

最終，國際標準不再只是外部參考，而是成為企業建立一致安全要求、持續檢查與改善架構治理的重要依據。