Microsoft 365 變更管理

Microsoft 365 會在程式碼和非程式碼對其系統進行變更時強制執行變更管理程式,以維持其安全性狀態。 任何來自初始狀態的設定漂移都會造成弱點、中斷功能或中斷可用性。 在 Microsoft 365 內的資訊系統以健全的安全性狀態部署之後,系統會強制執行詳細的變更管理程式,以維護系統完整性。

Microsoft 365 有許多變更的驅動因素,包括新的功能或安全性需求、客戶的意見反應、已識別的弱點,以及稽核結果。 無論變更的驅動程式為何,服務小組都會使用票證或原始檔控制工具來記錄核准證據並追蹤所有變更。

原始程式碼變更

變更會透過 Microsoft 的安全開發生命週期 (SDL) 部署,後面接著 Microsoft 365 中的所有工程和開發專案。 這是軟體發展模型,其中包含程式碼檢閱、測試和核准的相關特定安全性考慮,然後才有系統地發行至 Microsoft 365 環境。

程式碼變更程式。

SDL 可作為架構,包括識別完成的開發專案可能的風險,以及可在開發階段實作和測試的風險降低策略。 也包含重要的安全性檢閱和核准檢查點。

變更識別和規劃

服務小組會定期開會討論建議的變更,包括理由、範圍、安全性影響、優先順序、相依性、部署計畫、角色和責任。 這項資訊記載于變更管理追蹤系統中。 如果變更遭到拒絕,則會在票證中明確記載理由,以供日後參考。

人員程式碼檢閱

負責實作程式碼變更的開發人員會提交提取要求,以複寫主要分支的程式碼,讓他們能夠進行必要的修改。 必須先通過人員程式碼檢閱,才能將任何新程式碼包含在新的組建中並加以部署。 這些檢閱的強制執行是透過附加至每個程式碼存放庫的自動化程式碼管線來處理,而且無法規避。 一旦收到必要的核准,程式碼就可以繼續進行下一個階段。

程式碼檢閱者會檢查程式碼錯誤、確認變更符合需求,以及執行安全性影響分析。 檢閱必須由開發程式碼的人員以外的人員進行,並強制執行職責區分原則。 防止相同人員提交和核准自己的程式碼是 Microsoft 嚴格強制執行的重要控制項。 這可大幅降低有人刻意或無意地釋放有害或錯誤程式碼的可能性。 如果檢閱者在程式碼檢閱期間發現問題,他們會停止變更,並讓開發人員使用建議的變更和其他測試重新提交程式碼。 程式碼檢閱者也可以決定完全拒絕簽入不符合識別需求的程式碼。 檢閱者認為程式碼令人滿意之後,就會提供核准,並將程式碼簽入主要分支作為認可。

自動化建置管線和安全性檢查

一旦將短期衝刺的所有變更都認可到主要分支,自動化建置程式就會開始。 這是程式碼受限於各種自動化安全性檢查的位置。 這些檢查包括靜態程式碼分析、二進位分析和加密掃描。 Microsoft 365 會定義一組必要的測試,每個組建都必須在部署至生產前環境之前通過。 未通過的組建會遭到拒絕,並傳回開發小組,在開發小組達到臨界值通過率之前,必須進行必要的調整。 成功的組建會透過自動化部署管線繼續進入生產前環境。

組建版本

組建一開始只會發行給開發此功能的服務小組。 在以邏輯隔離方式隔離的雲端環境中發行至逐漸較大的測試群組之前,它必須無問題地運作, 稱為通道。 在服務小組之後,組建會發行至所有內部 Microsoft 365 群組,然後將組建發行至所有內部 Microsoft 群組。 這項測試通常在內部稱為 dogfooding,可讓 Microsoft 在發行給外部客戶的組建之前,識別實際生產環境中的錯誤。 這些測試方法可確保 Microsoft 的程式碼在到達客戶和全球部署之前,安全且如預期般運作。 先前的組建一律會保留以供復原之用。

工程小組會先決定組建在高負載期間花費在每個通道的時間量,然後再繼續進行下一個通道。 如果每個內部通道中的所有測試都成功,則組建會發行給全球客戶,首先是針對已加入宣告該通道的客戶租使用者發行,然後再發行全球標準版。

非程式碼變更

非程式碼變更會定義為不涉及建立或編輯服務原始程式碼之 Microsoft 365 系統的任何修改。 這可能包括開啟埠、變更存取控制清單 (ACL) ,或基礎系統的其他變更。 相較之下,非程式碼變更的發生頻率低於程式碼變更,但仍需要高度的審查。

非程式碼變更程式。

變更的描述會連同實作步驟、驗證步驟和復原計畫一起記錄。 實作變更之前,系統會對等檢閱計畫,以取得至少一個人的精確度和安全性影響。 一旦核准,就會實作記載的計畫。 如果所有驗證步驟都成功通過,結果會記錄在票證中,並標示為已解決。

如果變更的實作不成功,就會觸發復原計畫,而小組會回到規劃階段,並重複此程式,直到成功為止。

資源