在操作 Microsoft Azure 這類複雜系統時，有一項重大挑戰是確保系統中只執行授權的軟體。 未經授權的軟體會對任何企業造成數個風險：
- 安全性風險，例如專用攻擊工具、自訂惡意程式碼以及具有已知弱點的第三方軟體
- 已核准的變更管理程序未用來帶入新軟體時的合規性風險
- 來自外部開發軟體的品質風險，可能不符合企業的營運需求
Azure 也面臨同樣的挑戰，且複雜度極高。 數千台伺服器運行著數千名工程師開發與維護的軟體。 這種規模帶來龐大的攻擊面，單靠業務流程無法管理。
新增授權閘道
Azure 採用豐富的工程流程，對已部署軟體的安全性、合規性與品質實施閘門。 此流程包括原始碼存取控制、同儕審查、安全漏洞的靜態分析、Microsoft 的安全開發生命週期（SDL）以及功能與品質測試。 Microsoft 需要確保部署的軟體能順利通過這個流程。 程式碼完整性有助於實現這種保證。
程式碼完整性作為授權閘道
程式碼完整性是一項核心層級服務，從 Windows Server 2016 開始提供。 只要載入驅動程式或動態連結程式庫 (DLL)、執行可執行的二進位檔案或執行指令碼，程式碼完整性就可以套用嚴格的執行控制原則。 Linux 有類似的系統，例如 DM-Verity。 程式碼完整性政策由一組授權指標組成，可能是程式碼簽署憑證或 SHA-256 檔案雜湊值，核心會在載入或執行二進位檔或腳本前匹配這些指標。
程式碼完整性允許系統管理員定義政策，僅授權特定憑證簽署的二進位檔與腳本，或符合指定的 SHA-256 雜湊值。 核心會封鎖不符合所設定原則的所有項目執行，以強制執行此原則。
程式碼完整性政策可能會在生產環境中阻擋關鍵軟體，除非該政策完全正確，否則可能導致停機。 基於這個疑慮，你可能會問為何安全監控不足以偵測未經授權的軟體執行。 程式碼完整性有一種稽核模式，該模式不會阻止執行，而是能在未經授權軟體執行時發出警示。 警示在處理合規風險方面能帶來極大價值。 然而，對於安全風險如勒索軟體或自訂惡意軟體，即使延遲幾秒鐘回應，也可能是保護與敵對者在你車隊中取得持續立足點的關鍵差別。 在 Azure 領域，Microsoft 投入大量資金來管理可能導致客戶中斷的程式碼完整性風險。
建置流程
如前所述，Azure 建置系統擁有豐富的測試，確保軟體變更安全且合規。 建置經過驗證後，建置系統會用 Azure 建置憑證簽名。 憑證表示建置已通過整個變更管理流程。 建置最後的測試是程式碼簽章驗證（CSV）。 CSV 確認新建置的二進位檔符合程式碼完整性政策，然後 Microsoft 才會部署到生產環境。 這項驗證讓 Microsoft 有高度信心，錯誤簽署的二進位檔不會造成影響客戶的故障。 如果 CSV 發現問題，建置就會中斷，相關工程師會被呼叫去調查並修正問題。
部署期間的安全
即使 Azure 對每個建置執行 CSV，生產環境的某些變更或不一致仍可能導致程式碼完整性相關的故障。 例如，一台機器可能執行舊版的程式碼完整性政策，或處於不健康狀態，導致程式碼完整性出現誤報。 以 Azure 這樣的規模，Microsoft 什麼情況都見識過了。 Azure 持續保護部署期間的故障風險。
Azure 上的所有變更都必須經過一系列階段部署。 第一階段是內部 Azure 測試實例。 下一階段僅服務其他 Microsoft 產品團隊。 最終階段會為第三方客戶提供服務。 當 Azure 部署變更時，變更會依序移動到每個階段，並暫停以測量該階段的健康狀況。 若變更無負面影響，則進入下一階段。 如果 Microsoft 對程式碼完整性原則進行了不當變更，分階段部署機制會偵測到這項變更並將其回復。
事件回應
即使有這種多層防護，伺服器群中仍有可能阻擋正確授權的軟體，造成面向客戶的問題，這是 Microsoft 最糟糕的情況之一。 最後一層防禦是人為調查。 每次程式碼完整性封鎖檔案時，都會引發待命工程師調查的警示。 此警示讓工程師能夠啟動安全調查並介入，無論問題是真實攻擊的指標、誤判，還是其他影響客戶的情況。 此警示可縮短減少與程式碼完整性相關問題所需的時間。
下一步
想了解更多關於 Microsoft 如何推動平台完整性與安全性的資訊，請參閱：