共用方式為

平台程式碼完整性

  • 發行項

在操作 Microsoft Azure 這類複雜系統時，有一項重大挑戰是確保系統中只執行授權的軟體。 未經授權的軟體會對任何企業造成數個風險：

  • 安全性風險，例如專用攻擊工具、自訂惡意程式碼以及具有已知弱點的第三方軟體
  • 已核准的變更管理程序未用來帶入新軟體時的合規性風險
  • 來自外部開發軟體的品質風險，這可能不符合企業的操作需求

在 Azure 中，我們面臨相同的挑戰，並且更為複雜。 我們有數千部執行軟體的伺服器，而軟體是由數千位工程師所開發和維護。 這會呈現無法單獨透過商務程序所管理的大型受攻擊面。

新增授權閘道

Azure 使用豐富的工程程序來實作我們所部署軟體的安全性、合規性和品質的閘道。 此程序包括原始程式碼的存取控制、進行對等程式碼檢閱、針對安全性弱點執行靜態分析、遵循 Microsoft 的安全性開發生命週期 (SDL)，以及進行功能和品質測試。 我們需要保證我們所部署的軟體已經過此程序。 程式碼完整性可協助我們達到該項保證。

程式碼完整性作為授權閘道

程式碼完整性是從 Windows Server 2016 開始變成可用的核心層級服務。 只要載入驅動程式或動態連結程式庫 (DLL)、執行可執行的二進位檔案或執行指令碼，程式碼完整性就可以套用嚴格的執行控制原則。 Linux 有類似的系統，例如 DM-Verity。 程式碼完整性原則包含一組授權指標 (程式碼簽署憑證或 SHA256 檔案雜湊)，而其核心會在載入或執行二進位檔或指令碼之前相符。

程式碼完整性可讓系統管理員定義原則，而此原則只授權特定憑證已簽署或符合所指定 SHA256 雜湊的二進位檔和指令碼。 核心會封鎖不符合所設定原則的所有項目執行，以強制執行此原則。

程式碼完整性原則的考量在於除非原則完全正確，否則可以封鎖生產環境中的重大軟體並造成中斷。 基於此考量，有人可能會詢問為何使用安全性監視不足以偵測何時執行未經授權的軟體。 程式碼完整性具有稽核模式 (而非防止執行)，可以在未經授權的軟體執行時發出警示。 警示當然可以增加解決合規性風險的價值，但針對勒索軟體或自訂惡意程式碼這類安全性風險，即使是延遲回應幾秒鐘，都可能是保護與敵人在機群中取得持續立足點之間的差異。 在 Azure 中，我們已大幅投資來管理任何程式碼完整性風險，進而影響客戶中斷。

建置流程

如上所討論，Azure 建置系統具有一組豐富的測試，以確保軟體變更安全且符合規範。 建置在完成驗證之後，建置系統會使用 Azure 建置憑證來對其進行簽署。 憑證指出建置已通過整個變更管理程序。 建置所經歷的最終測試稱為「程式碼簽章驗證 (CSV)」。 CSV 會先確認新建置的二進位檔符合程式碼完整性原則，再將其部署至生產環境。 這讓我們高度確信不會因未正確簽署二進位檔而造成客戶影響中斷。 如果 CSV 發現問題，則建置會中斷，而且相關工程師會分頁調查並修正問題。

部署期間的安全

即使我們會針對每個建置執行 CSV，但生產環境中仍有一些變更或不一致可能會導致程式碼完整性相關中斷。 例如，機器可能正在執行舊版的程式碼完整性原則，或者可能處於狀況不良狀態，而此狀態會在程式碼完整性中產生誤判。 (以 Azure 規模來說，我們各式各樣的情況都見識過了。)因此，我們需要在部署期間繼續防範中斷的風險。

Azure 中的所有變更都需要透過一系列的階段進行部署。 其中第一個是內部 Azure 測試執行個體。 下一個階段僅用來服務其他 Microsoft 產品小組。 最終階段會為第三方客戶提供服務。 變更在部署時會依序移至所有這些階段，並暫停以測量階段的健康情況。 如果發現變更沒有任何負面影響，則會移至下一個階段。 如果我們對程式碼完整性原則進行不良的變更，則會在此分段部署期間偵測到變更，並予以復原。

事件回應

即使使用這種分層保護，機群中的某部伺服器還是可能會封鎖正確授權的軟體，並導致客戶遇到問題，這是我們遇到的其中一種最糟案例。 我們的最後一層防禦是人為調查。 每次程式碼完整性封鎖檔案時，都會引發待命工程師調查的警示。 不論問題是實際攻擊的指標、誤判還是其他客戶影響情況，警示都可讓我們開始安全性調查並介入。 這會將減輕任何程式碼完整性相關問題所需的時間降到最少。

下一步

若要深入了解我們推動平台完整性和安全性的方法，請參閱：