本文提供 Microsoft 365 認證的詳細資訊，包括所需的安全性控制清單，以及適用於 ISV 和開發人員的指引。
Microsoft 365 認證是針對應用程式、增益集、代理程式和支援的後端環境的獨立安全性和隱私權稽核 (統稱為與 Microsoft 365 平台整合) 應用程式。 通過的應用程式將在整個 Microsoft 365 生態系統中被指定為 Microsoft 365 認證，並且可以通過以合規性為重點的搜索、過濾器和品牌在 Microsoft 365 市集中輕鬆找到。 ISV 將有機會在此文件集中的專用頁面上共用其應用程式的合規性屬性。
Microsoft 365 認證適用於下列類型的應用程式：
- Microsoft 365 增益集 (Word、Excel、Outlook、PowerPoint、OneNote、Project)
- Teams 應用程式
- SharePoint 解決方案
- Web 應用程式 (SaaS)
- Copilot 擴充功能
重要事項
Microsoft 365 認證是根據 Microsoft 365 認證架構，對應用程式的安全性與合規性進行嚴格審查，需要投入大量的時間和資源才能完成。 開始之前，請檢閱 合規性控制架構 ，以確認您的應用程式符合資格。 如果您有任何疑問，請發送電子郵件 appcert@microsoft.com。
詞彙
參與 Microsoft 365 認證計畫即表示您同意這些補充條款，並遵守任何適用於您透過 Microsoft Corporation 參與 Microsoft 365 認證計畫的隨附文件 (「Microsoft」、「我們」或「我們的」) 。 您向我們聲明並保證，您有權代表您自己、公司和/或其他實體 （如適用） 接受這些 Microsoft 365 認證補充條款。 本公司得隨時變更、修正或終止本補充條款。 在任何變更或修訂之後，您繼續參與 Microsoft 365 認證計劃，即表示您同意新的補充條款。 如果您不同意新的補充條款，或我們終止這些補充條款，您必須停止參與 Microsoft 365 認證計畫。
必要條件
在授予 Microsoft 365 認證之前，應用程式必須先完成下列作業：
發行者驗證 如果應用程式具有已驗證的發行者，則表示發佈該應用程式的組織已由 Microsoft 驗證為正品。 驗證應用程式包括使用 Microsoft Cloud 合作夥伴計畫 (已驗證的 CPP) 帳戶，以及將已驗證的 PartnerID 與應用程式註冊建立關聯。 取得發行者驗證
發行者證明 是一種自助式程序，應用程式開發人員 (ISV，) 完成一組有關其安全性做法的問題，例如處理敏感性資料。 完成後，該應用程序將收到一個文檔頁面，他們可以與客戶共享，其中包含他們提供的響應。
檢閱 控制準則。 並不總是要求遵守所有控制措施才能獲得認證。 但是，本概述文件中討論的三個安全領域中的每一個都存在) 不會披露的閾值 (，並且必須通過。 不符合標示為「硬性失敗」的關鍵控制項將導致評估失敗。
成本結構
ISV 會與稽核公司合作支付認證費用。 欲了解更多信息並在審計公司 Claranet 開設賬戶 - 單擊此處。
| 稽核類型 | 包含的內容 | 條件 |
|---|---|---|
| 標準 | 針對所有適用的控制項進行全面評估 | 不符合衛星審核資格的新評估和重新認證所需。 如果重新認證未通過衛星審核設定的風險標準，則需要 |
| 衛星稽核 | 在符合標準的情況下，第二和第三評估年度的減少控制集 | 在第一年完成標準認證後符合資格。 對於第 2 年和第 3 年，如果沒有發生重大變化並通過風險評估 |
| 加時賽 | 可根據要求建造，包括報告時間 | 僅當提交內容需要更多時間與審核員一起時才新增 |
| 滲透測試天數 | 滲透測試範圍為每個參與，並符合涵蓋評估的全部商定範圍的認證要求 | 如果應用程式在過去 12 個月內沒有信譽良好的第三方滲透測試，則需要 |
| Clone | 確認複製提交，審查任何需要額外證據的控制項 | 與最近完成認證的應用程式共用相同後端環境的應用程式 |
提交時間範圍
獲得認證的提交流程有兩個階段：
第 1 階段：初始文件提交 (14 天的時間範圍)
在此階段，ISV 必須提交文件，以提供其應用程式支援環境概觀。 這包括但不限於：
- 架構圖表/資料流
- 系統元件清單
- 軟體資產清查
分析師將檢閱此文件以定義評估的範圍。 ISV 有 14 天的時間完成並上傳所需的文件。 未能在此截止日期前完成可能會延遲流程或導致提交失敗。
第 2 階段：60 天時間範圍 (完整證據審查)
一旦定義範圍，ISV 將進入證據收集階段。 在此階段：
ISV 必須針對範圍中定義的所有適用控制項上傳辨識項。
這些證據將經過審查、修改 (（如果需要) ）以及最終的問答過程。
在此期間也可以進行滲透測試。
ISV 有 60 天的時間完成此階段，從第一次提交證據開始，其中包括：
- 上傳所有控制項的證據
- 分析師檢閱與意見反應
- 對所提交證據的任何必要修訂
- 完成問答流程
未能在期限前完成
如果 ISV 無法在 60 天的時間範圍內完成此程序，評定將會失敗。 但是，根據分析師的判斷，在有效的情況下，最多可以延長 60 天，例如：
- 季節性假日
- 滲透測試延遲
- 內部變更
- 實作必要變更以符合控制要求所需的時間
一旦兩個 60 天的時間範圍都用完，就不能再授予延期。
認證範圍
範圍內環境包含傳遞應用程式、增益集或代理程式程式碼所需的所有系統和基礎結構，以及應用程式/增益集/代理程式可能與之通訊的任何支援後端系統。 任何連線至範圍內環境的其他環境也必須包含在範圍內，除非實作適當的分割，且連線的環境不會危害範圍內環境的安全性。
請注意：任何個別的災害復原環境也必須包含在範圍內環境中，因為這些環境對於在主要環境失敗時維持服務連續性可能至關重要。
此外，遠端備份環境也必須納入範圍，因為它們可能會儲存機密的 Microsoft 資料。 因此，必須為這些環境實作足夠的安全性控制。
術語範圍內系統元件包括在定義的範圍內環境內主動使用的所有設備和系統。 這些元素包括但不限於：
- Web 應用程式
- 伺服器 (實體或虛擬，位於內部部署或雲端)
- 選項
- 負載平衡器
- 虛擬基礎結構
- 雲端提供者網頁管理入口網站
- 雲端資源 (虛擬機器、應用程式服務、儲存體帳戶、資料庫等 )
重要事項
面向公眾的系統元件特別容易受到外部威脅行為者的攻擊，因此面臨更高的風險。 通常，這些系統應透過實施網路安全控制 (NSC) ，例如非軍事區 (DMZ) ，與內部系統元件隔離。 DMZ 的目的是充當緩衝區，限制對外部系統的信任並增強安全性以保護內部系統和資料。 雖然 DMZ 在某些情況下仍然是理想的選擇，但現代雲端架構通常依賴針對特定部署場景量身定制的替代安全措施。
基礎結構即服務 (IaaS) 、平台即服務 (PaaS) 和軟體即服務 (SaaS)
如果 IaaS 和/或 PaaS 用於支援正在審查的範圍內環境，雲端平台提供者將負責在整個認證過程中評估的一些安全性控制。 雲平台提供商需要通過外部合規性報告（例如 PCI-DSS、合規性證明) 、ISO 27001 或 SOC 2 Type II 報告）向分析師提供獨立的安全最佳實踐 (外部驗證。
如需哪些安全性控制項可能適用於部署類型，以及環境是否處理或傳輸 Microsoft 365 資料的詳細資訊，請參閱 附錄 C。部署類型包括：
- ISV 託管：由獨立軟體廠商託管的應用程式。
- IaaS 託管：由第三方雲端平台提供的基礎設施。
- PaaS/無伺服器託管：平均平台型或無伺服器架構的應用程式。
- 混合式託管： 內部部署和雲端託管元件的混合。
- 共用託管： 由多個租用戶使用的共用雲端環境。
在使用 IaaS 或 PaaS 的情況下，證據必須驗證部署是否與相關架構的預期安全性控制一致。
抽樣
為了確保徹底評估，範圍內系統組件的抽樣必須考慮作業系統、主要設備功能、設備類型 (例如伺服器、路由器、網路安全控制) 和地理位置等因素。 樣品是在認證過程開始時根據這些考慮因素選擇的。 下表根據範圍內元件的母體來指導取樣大小：
| 人口規模 | 範例 |
|---|---|
| <=5 | 1 |
| >5 & <10= | 2 |
| >10 & <=30 | 3 |
| >30 | 4 |
這可確保對不同組態和部署模型的環境合規性進行代表性評估。
注意事項
如果在評估期間發現設備之間存在差異，則可以調整樣本量以確保充分呈現環境。
認證程序概觀
若要開始 Microsoft 365 認證程序：
發行者證明 移至合作夥伴中心並填寫發行者證明表單。 注意：如果您提交的內容超過三個月，您必須重新提交以供審核和驗證。
開始認證 進入合作夥伴中心後，選取 [開始認證] 選項以開始提交初始文件。 此步驟可協助認證分析師根據應用程式的架構及其管理 Microsoft 資料的方式來識別評估的範圍。 此時，您將需要在 Claranet Limited 設置一個帳戶。
認證分兩個主要階段進行：
初始文件提交 在此階段，您會提供重要的詳細資料，以協助分析師瞭解應用程式的設計、資料流程和範圍內環境。 分析師將確定適用的安全控制措施，並概述需要證據的系統組件。 您必須提供準確的文件來促進此審查，這約佔整個流程的 5%。
完整證據檢閱 在此階段，您提交詳細證據，證明符合範圍內環境的安全性控制。 在此階段，分析師將與您密切合作，審查、澄清和驗證您提交的內容。 此階段會完成程序的剩餘部分。
評定
一旦核准初始文件提交，入口網站中將顯示所需安全控制的清單。 您有 60 天 的時間為每個控制措施提供證據，確認其已就位且可運作。 分析師將審查您的證據並批准它或要求其他細節或修改。
認證
分析師審查和驗證您的提交內容後，您將收到有關認證決定的通知。 成功符合認證準則的應用程式會獲得徽章，該徽章會顯示在其 AppSource 清單和相關聯的 Microsoft Docs 頁面上。 這些頁面還將提供有關應用程序的安全性和合規性屬性的詳細報告。
檢閱和重新認證
Microsoft 365 認證的應用程式必須進行年度重新認證，以確保持續符合 Microsoft 的標準。 重新認證程序涉及重新評估範圍內的控制項，以確認它們與目前的環境一致。 您可以在認證到期前 90 天開始重新認證流程，以避免任何中斷。 認證在此期間仍然有效。
如果在到期日之前未完成重新認證，認證將被撤銷。 因此：
將會移除應用程式的認證徽章和商標。
ISV 將不再被允許以 Microsoft 365 認證的形式行銷應用程式。
如果在排程的重新認證期間之外，應用程式發生 重大變更 ，ISV 必須通知 Microsoft 應用程式合規性計畫，以確保應用程式保持合規。
初始文件提交
您的初始提交必須包括以下資訊：
| 文件概觀 | 文件詳細資料 |
|---|---|
| 應用程式/增益集/代理程式描述 | 應用程式/增益集/代理程式的用途和功能的描述。 這應該可讓認證分析師充分了解應用程式/增益集/代理程式的運作方式及其預期用途。 |
| 滲透測試報告 | 滲透測試報告於過去 12 個月內完成。 此報告必須包括支援部署應用程式/增益集/代理程式的環境，以及支援應用程式/增益集/代理程式作業的任何其他環境。 注意： 如果 ISV 目前未執行年度滲透測試，稽核小組可以額外付費完成。 |
| 架構圖表 | 代表應用程式支援基礎結構高階概觀的邏輯架構圖。 這必須包括 所有 託管環境和支持應用程序的支援基礎設施。 此圖表必須描述環境中所有不同的支援系統元件，以協助認證分析師了解範圍內的系統並協助確定取樣。 另請註明使用的託管環境類型;ISV 託管、IaaS、PaaS 或混合式。 注意： 在使用 SaaS 的情況下，請註明用於在環境中提供支援服務的各種 SaaS 服務。 |
| 公用足跡 | 詳細說明支援基礎結構所使用 的所有 公用 IP 位址和 URL。 這必須包括配置給環境的完整可路由 IP 範圍，除非已實施足夠的分段來分割使用的範圍 (需要足夠的分段證據) 。 |
| 資料流程圖 | 流程圖詳細說明下列內容： |
| ✓ Microsoft 365 資料流與應用程式/附加元件/代理程式 (，包括 EUII 和 OII。) | |
| ✓ Microsoft 365 資料在支援基礎結構 (內的) 。 | |
| ✓ 圖表突出顯示數據的存儲位置和內容、數據如何傳遞給外部第三方 (包括第三方) 的詳細信息，以及如何在通過開放/公共網絡傳輸和靜態數據時受到保護。 | |
| API 端點詳細資料 | 您的應用程式使用的所有 API 端點的完整清單。 為協助瞭解環境範圍，請提供環境中的 API 端點位置。 |
| Microsoft API 權限 | 提供 文件，詳細 說明所有使用的 Microsoft API，以及應用程式/增益集/代理程式需要哪些權限才能正常運作，以及所要求權限的理由 |
| 資料儲存類型 | 資料儲存和處理描述的文件： |
| ✓ 接收和儲存 Microsoft 365 資料 EUII 和 OII 的程度 | |
| ✓ 資料保留期限。 | |
| ✓ 為何要擷取 Microsoft 365 資料。 | |
| ✓ 在儲存 Microsoft 365 資料的地方 (也應包含在上述) 提供的資料流程圖中。 | |
| 合規性確認 | 發行者證明提交中所包含或在檢閱 Microsoft 365 憑證安全性控制時要考慮的外部安全性架構的支援文件。 目前支援下列四種： |
| ✓ PCI DSS 合規性證明 (AOC) 。 | |
| ✓ SOC 2 I 型/II 型報告。 | |
| ✓ ISMS / IEC - 1S0/IEC 27001 SoA) 和認證 (適用性聲明。 | |
| ✓ FedRAMP FedRAMP 授權包和 FedRAMP 準備評估報告。 | |
| Web 相依性 | 列出應用程式使用及目前執行版本的所有相依性的文件。 |
| 軟體庫存 | 最新的軟體清查，包括範圍內環境內使用的所有軟體以及版本。 |
| 硬體清查 | 支援基礎結構使用的最新硬體詳細目錄。 這將用於在執行評估階段時進行抽樣。 如果您的環境包含 PaaS，請提供所耗用雲端服務/資源的詳細資料。 |
證據收集和評估活動
認證分析師需要審查定義樣本集中所有系統組件的證據。 支持評估過程所需的證據類型包括以下任何或所有：
證據收集
- 初始文件，在初始文件提交指南中強調顯示
- 原則文件
- 處理文件
- 系統組態設定
- 變更票證
- 變更控制記錄
- 系統報告
- 會議記錄
- 合約/協議
將使用各種方法來收集完成評估過程所需的證據。 此證據收集可以採用以下形式：
- 文件
- 螢幕擷取畫面
- 採訪
- 螢幕畫面分享
所使用的證據收集技術將在評估過程中確定。 如需提交所需證據類型的具體範例，請參閱範例 證據指南。
共享證據
在認證過程中，ISV 可能會選擇直接與潛在客戶共用其合規性辨識項。 檔案上傳對話方塊中的核取方塊預設會核取，授與 Microsoft 365 系統管理員存取 Teams 管理員中心和 Microsoft 365 系統管理 中心中應用程式認證辨識項的權限。 (Microsoft 365 管理員負責在組織內配置、管理和保護 Microsoft 365 服務和資源。) 這種透明度旨在簡化評估新應用程式以加速決策的組織盡職調查。 如果 ISV 不想公開此證據，他們只需在提交時取消勾選方塊，保留對揭露其合規性文件的方式和時間的完整控制權。
評定活動
認證分析師會檢閱提交的證據，以確認符合 Microsoft 365 認證所需的所有控制項。 為了加快流程，請確保 初始文件提交 中指定的所有文件都完整並提前提供。
在審查期間，分析師將評估來自初始提交和出版商證明的證據。 他們將確定調查範圍、抽樣方以及是否需要額外證據。 分析師會使用所有收集的資訊來評估是否符合 Microsoft 365 認證規格，並判斷您的應用程式是否符合定義的控制項。
應用程式認證準則
應用程式及其支援基礎結構，以及支援文件，將在下列三個安全性網域進行評估：
這些安全領域中的每一個都包含特定的關鍵控制，其中包含將作為評估過程的一部分進行評估的一或多個要求。 為了確保 Microsoft 365 認證適用於各種規模的開發人員，每個安全性網域會使用評分系統進行評估，以決定每個網域的整體分數。 每個 Microsoft 365 認證控制項的分數會根據未執行該控制措施的感知風險來分配 1 (低) 到 3 (高) 。 每個安全網域都有一個最低百分比標記才能被視為及格。 某些因素會導致自動失敗，包括：
使用不遵守最低權限原則的 API 權限 (PoLP)
需要時缺少滲透測試報告。
缺少反惡意程式碼防護。
無法實作多重要素驗證 (管理存取的 MFA) 。
修補程序缺失或不足。
缺乏符合規範的 GDPR 隱私權注意事項。
應用程式安全性
應用程式安全性網域會評估下列區域：
- 滲透測試
- 圖形 API 權限驗證
- 負責任的 AI
滲透測試
滲透測試對於識別和減輕與應用程式或增益集及其支援環境相關聯的風險至關重要。 這可確保應用程式為客戶提供足夠的安全保證。
對於連線到非由 Microsoft 託管或管理 的 外部服務的任何應用程式，都必須進行滲透測試。 如果應用程式部署為僅使用 GraphAPI 等 Microsoft 服務的獨立解決方案，則可能不需要滲透測試。 不過，在 Azure 中託管的應用程式必須經過滲透測試，以確保範圍內環境的安全性。
滲透測試範圍
基礎結構測試：對於內部和外部基礎結構，必須在支援應用程式、附加元件或代理程式的 即時生產環境中 進行滲透測試。 這包括：
裝載應用程式、增益集或代理程式程式碼的環境 (通常會在資訊清單檔案) 中參照。
與應用程式/增益集/代理程式操作互動或支援之操作的任何其他環境 (例如，應用程式/增益集/代理程式與 Microsoft 365) 以外的其他 Web 應用程式通訊。
定義滲透測試的範圍時，包括可能影響範圍內環境安全性的所有 連線系統或環境 至關重要。
建議
Web 應用程式滲透測試：建議直接針對即時生產環境執行 Web 應用程式滲透測試。 不過，Web 應用程式測試可以在測試/UAT (使用者驗收測試) 環境中進行，前提是滲透測試報告確認在測試時生產環境中使用相同的程式碼庫。
分割驗證：如果使用分割技術將範圍內環境與其他環境隔離，則滲透測試報告必須驗證這些分割技術的有效性。 這可確保在分段過程中不會引入任何漏洞。
滲透測試需求
將審查滲透測試報告，以確保不存在符合以下控制措施中概述的以下 自動故障標準 的漏洞。
| 準則類型 | 滲透測試控制項 |
|---|---|
| 一般準則 | Web 應用程式 (已驗證和未驗證的) ，如果) 適用，內部 (和外部基礎設施 滲透測試必須 每年 (每 12 個月進行一次) 並由信譽良好的獨立公司進行。 |
| 已識別之嚴重和高風險弱點的補救 必須 在滲透測試結束後一個月內完成，或根據 ISV 所記錄的修補程序而更早完成。 | |
| 完整的外部足跡 (IP 位址、URL、API 端點等 ) 必須 包含在滲透測試的範圍內，並且必須在滲透測試報告中明確記錄。 | |
| 除非環境與 PaaS 一致，否則完整的內部網路 必須 包含在滲透測試範圍內，並且必須在滲透測試報告中明確記錄。 | |
| Web 應用程式滲透測試 必須 包含所有弱點類別;例如，最新的 OWASP 前 10 名或 SANS 前 25 名 CWE。 建議在滲透測試報告中詳細說明這一點，否則將難以證明。 | |
| 關鍵和高風險漏洞或被視為 自動故障的 漏洞必須由滲透測試公司重新測試，並在滲透測試報告中明確強調為已修復。 | |
| 自動失敗準則： | 存在不支援的作業系統或不支援的 JavaScript 程式庫。 |
| 是否存在預設、可列舉或可猜測的系統管理帳戶。 | |
| 存在 SQL 插入式風險。 | |
| 跨網站指令碼的存在。 | |
| 存在目錄周遊 (檔案路徑) 弱點。 | |
| 存在 HTTP 弱點，例如，標頭回應分割、要求走私和 Desync 攻擊。 | |
| 是否存在原始程式碼洩漏 (，包括 LFI) 。 | |
| CVSS 修補程式管理指導方針定義的任何重大或高分數。 | |
| 任何可輕易利用以危害大量 EUII 或 OUI 的重大技術漏洞。 |
重要事項
報告必須能夠提供足夠的保證，以便可以證明上述滲透測試要求部分中詳細介紹的所有內容。
圖形 API 權限驗證
這可確保應用程式、增益集或代理程式不會要求過多或過於寬鬆的權限。 認證分析師會手動檢閱應用程式要求的權限，並根據發行者證明提交進行交叉檢查。
目的是確認要求的權限遵守最低權限原則。 如果分析師發現應用程式請求的權限超過必要的權限，他們將與 ISV 合作以驗證這些權限的商務理由。 要求的權限與發行者證明提交之間發現的任何差異都必須在此審查期間解決。
負責任的 AI
為了回應負責任的 AI 控制項而提交的資訊，將會與 ISV 提供的應用程式資訊清單檔案一起進行審查。 這可讓分析師檢查 Microsoft Copilot 與正在通過認證的應用程式的整合，清楚了解兩者如何互動，以及代表客戶採取哪些動作。 我們承認，無論是負責任地使用人工智慧，還是讓客戶充分了解情況，這一點至關重要。 如果所分享的資訊符合預期的應用程式功能，以及 Microsoft 的負責任 AI Standard 或 NIST 值得信賴 & 負責任的人工智慧資源中心，則這些控制項將視為已核准， (受限於一般的問答檢查) 。
目的是與 Microsoft 進一步合作，在相關公開頁面上提供這項檢查的一些詳細資料，讓客戶能夠在涉及 Copilot 和相關應用程式時，對其資料的使用做出明智的充分決策。
操作安全性
此網域會測量應用程式的支援基礎結構和部署程序與安全性最佳做法的一致性。
控制項
| 控制系列 | Controls |
|---|---|
| 意識訓練 | 提供證據證明組織向資訊系統使用者提供既定的安全意識培訓， (包括經理、高級管理人員和承包商，) 作為新用戶初始培訓的一部分或信息系統變更需要時。 |
| 提供組織定義的意識培訓頻率的證據。 | |
| 提供個人資訊系統安全意識活動的記錄和監控證據，同時在組織定義的頻率內保留個人培訓記錄。 | |
| 惡意程式碼防護 - 防毒軟體 | 提供證據，證明您的反惡意程式碼解決方案在所有取樣系統元件中處於作用中和啟用狀態，並設定為符合下列準則： |
| 如果是防毒軟體，則會啟用存取掃描，且簽章在 1 天內為最新狀態，且偵測到惡意程式碼時會自動封鎖惡意程式碼或警示和隔離。 | |
| 或者，如果 EDR/NGAV (端點偵測與回應/新一代防毒軟體) 則會執行定期掃描、產生稽核記錄，並持續保持最新狀態並具有自我學習功能。 | |
| 如果為 EDR/NGAV，則會封鎖已知的惡意程式碼，並根據巨集行為以及具有完整的安全清單功能來識別和封鎖新的惡意程式碼變種。 | |
| 惡意程式碼防護 - 應用程式控制 | 提供可證明的證據，證明具有業務理由的軟體/應用程式的核准清單存在且為最新狀態。 |
| 每個應用程式在部署之前都會經過核准程序並簽章。 | |
| 如文件所述，該應用程式控制技術已在所有取樣系統元件中處於作用中、啟用和設定狀態。 | |
| 修補程式管理 - 修補和風險排名 | 提供原則文件，用以管理如何識別新的安全性弱點並指派風險評分。 |
| 提供如何識別新安全性弱點的證據。 | |
| 提供證據，證明一旦識別出所有漏洞都會分配風險等級。 | |
| 提供證據，證明所有取樣的系統元件都按照組織定義的修補時間範圍進行修補，並且不支援的作業系統和軟體元件未在使用中。 如果適用，如果使用無伺服器技術或 PaaS，則應包括程式碼基底，或者如果使用 IaaS，則包括基礎結構和程式碼基底。 | |
| 修補時間範圍指導方針，例如「嚴重 – 14 天內，高 – 30 天內，中 – 60 天內」。 | |
| 弱點掃描 | 提供季度基礎結構和 Web 應用程式弱點掃描報告。 需要針對整個公用空間 (IP 位址和 URL) 和內部 IP 範圍執行掃描。 |
| 提供可證明的證據，證明在漏洞掃描期間識別的漏洞補救已按照您記錄的修補時間範圍進行修補。 | |
| NSC) (網路安全性控制 | 提供證據，證明網路安全性控制 (NSC) 安裝在範圍內環境的邊界上，並安裝在周邊網路與內部網路之間。 |
| 如果混合、內部部署 IaaS 也提供了所有公共存取終止於周邊網路的證據。 | |
| 驗證所有網路安全性控制 (NSC) 都設定為捨棄規則基底中未明確定義的流量，以及網路安全性控制 (NSC) 規則檢閱至少每 6 個月進行一次。 | |
| 變更控制項 | 提供證據，證明引入生產環境的任何變更都是透過記錄在案的變更請求來實施的，其中包括變更的影響、退出程序的詳細資訊、要進行的測試、授權人員的審查和批准。 |
| 提供存在不同環境的證據，以便：開發和測試/暫存環境強制從生產環境中分離職責，透過存取控制強制執行職責分離、開發或測試/暫存環境中未使用敏感性生產資料。 | |
| 安全的軟體開發/部署 | 提供支援安全軟體開發的政策和程序，並包含安全編碼的行業標準和/或最佳實踐。 例如 Open Web Application Security Project (OWASP) Top 10 或 SysAdmin， Audit， Network and Security (SANS) CWE () 的前 25 個常見弱點列舉。 |
| 提供程式碼存放庫受到安全保護的證據，以便：所有程式碼變更在與主要分支合併之前，都會經過第二個檢閱者的審查和核准程式，適當的存取控制已就緒，所有存取權都會透過多重要素驗證 (MFA 強制執行) | |
| 提供證據，證明所有放入生產環境 () 的發行版本在部署之前都經過審查和批准。 | |
| Account management | 提供證據，證明在取樣的系統元件中預設認證已停用、移除或變更。 |
| 提供證據，證明已制定程序來保護 (強化) 服務帳戶，並且已遵循此程序。 | |
| 提供證據證明：唯一使用者帳戶已發給所有使用者、環境中遵循使用者最低權限原則、強式密碼/複雜密碼原則或其他適當的緩和措施已就緒、已制定流程並至少每三個月遵循一次，以停用或刪除三個月內未使用的帳戶。 | |
| 驗證是否已針對所有遠端存取連線和所有非主控台管理介面設定 MFA，包括存取任何程式碼儲存庫和雲端管理介面。 | |
| 安全性事件記錄、檢閱和警示 | 提供證據，證明至少 30 天的安全性事件記錄資料可立即使用，並保留 90 天的安全性事件記錄。 |
| 提供證據，證明記錄會定期檢閱，並且會調查並解決檢閱過程中識別到的任何潛在安全性事件/異常 | |
| 提供證據，證明已設定警示規則，以便在適用情況下觸發警示以調查下列安全性事件：特殊權限帳戶建立/修改、特殊權限/高風險活動或作業、惡意程式碼事件、事件記錄竄改、IDPS/WAF 事件。 如果已設定) ( | |
| 資訊風險管理 | 提供證據證明已批准的正式資訊安全風險管理政策/流程已記錄和建立。 |
| 提供證據，證明至少每年進行一次正式的全公司資訊安全風險評估。 | |
| 或用於目標風險分析：針對傳統控制或行業最佳實踐不到位、設計/技術限制造成將漏洞引入環境的風險或使用戶和數據處於風險的每個實例，至少每 12 個月記錄一次和執行一次目標風險分析， 懷疑或確認遭入侵時。 | |
| 驗證資訊安全風險評估是否包括受影響的系統元件或資源、威脅和漏洞或等效物、影響和可能性矩陣或等效物、風險登記冊/風險處理計劃的建立。 | |
| 提供證據證明您已制定風險管理流程來評估和管理與供應商和業務合作夥伴相關的風險，並且您可以識別和評估可能影響內部控制系統的變更和風險。 | |
| 安全性事件回應 | (IRP) 提供您核准的安全性事件回應計畫/程序。 |
| 提供證據，概述貴組織如何回應事件、顯示其維護方式，以及其中包含事件回應團隊的詳細資料，包括連絡資訊、事件期間的內部通訊計劃，以及與相關方的外部通訊，例如主要專案關係人、支付品牌和收單機構、監管機構 (例如，GDPR) 的 72 小時、 監管機構、董事、客戶以及活動步驟，例如事件分類、遏制、緩解、恢復和恢復正常業務運營等，具體取決於事件類型 | |
| 提供證據證明事件應變小組的所有成員都接受過年度培訓，使他們能夠應對事件。 | |
| 提供證據，證明事件回應策略和支援文件是根據從桌面演習中學到的經驗教訓、從回應事件中學到的經驗教訓、組織變更來審查和更新的。 | |
| 業務連續性計劃和災害復原計劃 | 提供文件存在且已維護的證據，以概述業務連續性計畫。 |
| 提供證據，業務連續性計劃詳細說明相關人員及其角色和職責，包括：具有相關應急要求和目標的業務職能、系統和資料備份程序、配置和排程/保留、復原優先順序和時間範圍目標、應急計劃，詳細說明在發生關鍵資訊系統、業務功能和服務時恢復運作的行動、步驟和程序。非預期和非計劃性中斷，一個既定的過程，涵蓋最終的完整系統恢復並恢復到原始狀態。 | |
| 提供文件存在、維護的證據，並概述災難恢復計劃，並至少包括：人員及其角色、職責和升級流程、用於支援關鍵業務功能和服務的資訊系統清單、系統和資料備份程序和配置、復原計劃，詳細說明將關鍵資訊系統和資料恢復到運作中要遵循的行動和程序。 | |
| 提供證據證明業務連續性計劃和災難復原計劃至少每 12 個月審查一次，以確保其在不利情況下保持有效。 | |
| 提供證據證明業務連續性計劃是根據計劃的年度審查更新的，所有相關人員都接受了應急計劃中分配的角色和職責的培訓，計劃正在通過業務連續性或災難恢復演習進行測試，測試結果被記錄下來，包括從演習或組織變革中吸取的經驗教訓。 |
資料處理、安全性與隱私權
為了確保資料安全性，應用程式使用者、中繼服務與 ISV 系統之間傳輸的任何資料都必須使用 TLS (傳輸層安全性) 連線加密。 至少需要 TLS 1.2，強烈建議使用 TLS 1.3 或更高版本。 如需詳細資訊，請參閱附錄 A。
對於擷取或儲存 Microsoft 365 資料的應用程式，必須實作資料儲存加密配置。 這必須符合 附錄 B 中概述的規範。
控制項
| 控制系列 | Controls |
|---|---|
| 傳輸中的資料 | 提供證據，驗證 TLS 設定是否為 TLS 設定檔設定要求 內的 TLS1.2 或更高版本，且會保留並維護受信任金鑰和憑證的清查。 |
| 提供證據，顯示處理 Web 要求的所有公開對向服務皆已停用 TLS 壓縮，以防止壓縮比率、資訊外洩 (CRIME) ，且已在所有網站啟用 TLS HSTS 並將其設定為 180 天。 | |
| 待用資料 | 提供證據，證明待用資料已根據加密設定檔需求進行加密，使用加密演算法，例如 AES) 、RSA 和 Twofish Standard (加密金鑰大小為 256 位元或更高版本。 |
| 資料保留、備份和處置 | 提供已正式建立並記錄核准資料保留期間的證明。 |
| 提供證據，證明資料僅保留至先前控制中討論的定義保留期間。 | |
| 提供證據，證明已有程序在保留期間之後安全地刪除資料。 | |
| 提供證據證明自動備份系統已就緒，並設定為在預定時間執行備份。 | |
| 提供證據：備份資訊會依照備份排程程序進行測試，並定期還原，以確認資料的可靠性和完整性。 | |
| 提供證據適當的存取控制和保護機制， (即實施不可變的備份) 以確保備份/系統快照免受未經授權的存取，並確保備份資料的機密性、完整性和可用性。 | |
| 資料存取管理 | 提供有權存取資料和/或加密金鑰的使用者清單的證據。 包括每個人的業務理由並確認此使用者清單已根據其工作職能所需的存取權限正式核准，並且使用者會設定核准中概述的權限。 |
| 提供證據，證明已維護與之共用資料的所有第三方的清單，並且已與所有使用資料的第三方簽訂資料共用協議。 | |
| 隱私權 | 您的組織是否已建立、實施及維護隱私權資訊管理 (PIM) 系統，並透過原則或其他形式的文件/電腦化系統，對如何維護隱私權資訊管理工作以維持系統機密性和完整性，做出領導承諾。 決定維護系統的每個人的角色、責任和權限，包括 PII 處理者和控制者。 |
| 提供程序證據，以驗證 PII 最小化正在進行、PII 去識別化和刪除正在處理期結束時完成、PII 傳輸控制已就緒，包括任何機密性、存在 PII 從一個國家/地區到另一個國家/地區傳輸的記錄並並明確同意這樣做。 | |
| GDPR | 提供證據證明資料主體能夠提出 SAR，ISV 能夠在回應 SAR 要求時識別資料主體資料的所有位置，備份有保留期間，可讓透過 SAR 要求移除資料的用戶端被移除，因為在一段時間內的滾動備份會在) 最舊的備份刪除/重寫的生命週期 (移除。 |
| 提供應包含下列所有必要元素之隱私權注意事項：組織詳細資料 (名稱、地址及其他個人識別資訊) 、正在處理的個人資料類型、個人資料的保留時間、處理個人資料的合法性、資料主體權利;包括： 資料主體的權利、知情權、資料主體存取權、清除權、限制處理權、資料可攜性權、反對權、與自動化決策相關的權利，包括分析。 | |
| HIPAA | 提供證據證明： 存在組織內針對員工、承包商、供應商等的 HIPAA 和 HIPAA 處理政策。驗證我們的組織確保 ePH 的機密性、完整性和可用性。 |
| 確認您： 提供保護，防止合理預期使用或揭露隱私權規則不允許的此類資訊，確保其員工遵守安全規則。 根據 164.308 () (7) (ii) (A) 和 164.308 () (7) (ii) (B) 提供資料備份和災害復原計畫。 |
選用的外部合規性架構檢閱
如果您的組織已遵守外部安全性架構，例如 ISO 27001、PCI-DSS、FedRAMP 或 SOC 2 Type 2，您可以選擇利用這些認證來滿足部分 Microsoft 365 認證控制。 分析師的目標是使您現有的外部安全性架構與 Microsoft 365 認證需求保持一致。
不過，如果您的支援文件未證明 Microsoft 365 認證控制項已明確評估為外部架構稽核或評定的一部分，您必須提供其他證據，以確認這些控制措施已就緒。
文件需求：
文件必須清楚證明 Microsoft 365 認證的範圍內環境包含在永恆安全性架構的範圍內。 這些框架的驗證將通過接受由信譽良好、經認可的第三方審計師頒發的有效認證的證據來完成。
這些第三方審核員必須是國際認證機構的成員，例如：
ISO 27001 的認證和符合性標準
QSA) PCI-DSS (品質安全評估員
如需其他詳細資料，請參閱與您的認證相關的外部架構的特定指導方針和標準。
下表概述了認證分析師在驗證過程中接受的所需框架和文件。
| Standard | 需求 |
|---|---|
| ISO 27001 | 需要公開版本的 SOA) 適用 性聲明 (以及已簽發的 ISO 27001 證書副本。 SOA 總結了您對 114 項資訊安全控制措施中每一項的立場，並將用於識別是否有任何在 ISO 27001 憑證中未令人滿意詳細說明的控制措施排除。 如果無法透過檢閱面向公眾的 SOA 版本來判斷，則當 ISO 27001 用於驗證某些 Microsoft 365 認證安全性控制時，分析師可能需要存取完整的 SOA。 除了驗證 ISO 27001 評估活動的範圍外，分析師還將如上所述確認審核公司的有效性。 |
| ISO 22301 | 必須提供由認可的認證機構頒發的有效 ISO 22301 證書，以及描述業務連續性管理系統 (BCMS) 評估範圍的文件。 憑證和範圍文件將用於驗證範圍內的應用程式、支援服務和作業流程是否已作為正式業務連續性管理計劃的一部分進行評估。 評定分析師會檢閱認證的範圍、確認認證主體的有效性，並判斷透過 ISO 22301 評定證據可滿足哪些 Microsoft 365 認證業務連續性控制。 |
| ISO 27031 | 必須提供由認可的認證或評估機構簽發的有效 ISO 27031 證書或評估報告，明確標明範圍內的應用、基礎設施以及支援資訊和通訊技術 (ICT) 服務。 該文檔將用於評估 ICT 對業務連續性的準備情況，包括災難恢復計劃、恢復能力和彈性流程。 評定分析師會檢閱評定的範圍、確認評定組織的有效性，並判斷透過 ISO 27031 評定辨識項可以滿足哪些 Microsoft 365 認證災害復原和營運復原控制 |
| PCI DSS | 必須提供有效的 1 級合規性證明 (AOC) 文件，明確標識範圍內的應用程式和系統元件。 自我評估 AOC 不會 被接受為符合安全性最佳做法的證據。 AOC 將用於判斷哪些 Microsoft 365 認證規格控制項已進行評估並確認為 PCI DSS 評估的一部分。 |
| SOC 2 | SOC 2 (Type II) 報告必須是過去 15 個月內發佈的最新 (，並且聲明的時間段是在過去 27 個月內開始的，) 用作符合本 Microsoft 365 認證框架內任何評估控制的證據。 |
| FedRAMP | FedRAMP) (聯邦風險與授權管理計劃是一項成立於 2011 年的美國聯邦政府計劃。 它為雲端產品和服務提供了安全評估、授權和持續監控的標準化方法。 |
| 架構 | 其他考量 |
|---|---|
| ISO 27001 | 附錄 C：證據收集 – ISO 27001 的差異。 |
| PCI-DSS | 附錄 D：證據收集 – PCI-DSS 的差異。 |
| SOC 2 | 附錄 E：證據收集 – SOC 2 的差異。 |
注意事項
雖然外部安全性標準或架構可以提交為支援證據，以符合特定 Microsoft 365 認證控制項，但取得 Microsoft 365 認證需要個別評估。 取得 Microsoft 365 認證並不表示應用程式已完全通過這些外部架構的稽核。 Microsoft 365 認證規格著重於從這些架構衍生出的特定控制項子集，以針對您的應用程式安全性狀態，為 Microsoft 提供更高層級的保證。
使用外部合規性架構的需求
使用外部合規性架構的需求
範圍內環境和所有支援的商務程式必須包含在任何支援的外部安全性合規性架構的範圍內。 這些必須在提供的文件中清楚地記錄。
外部安全性合規性架構必須是最新的，這表示它們應該在過去 12 個月內進行評估， (或者如果正在進行的重新評估可以用支持證據進行驗證，則應在 15 個月內進行評估)
外部安全性合規性評估必須由獨立的認可公司進行。
外部架構驗證準則
SOC 2 類型 2 評定
- SOC 2 報告必須是類型 2 報告
- SOC 2 稽核必須包括正在評估的 M365 環境
- SOC 2 審核必須在過去 12 個月內完成
- 控制措施必須按照第 2 類報告的要求公平地呈現並正確設計
- SOC 2 稽核必須由合格的外部協力廠商進行
- 測試程序必須確認安全控制措施已到位並由審核員正確驗證。
ISO 27001 評估
- ISO 27001 稽核必須包含此 M365 評定中指定的環境
- ISO 27001 證書必須是最新的並適用於實體
- ISO 27001 評估必須由經認可的外部協力廠商進行 (不接受內部 ISO 27001 審核)
- ISO 27001 評估必須在過去 12 個月內完成
PCI-DSS 評定
- AOC 文件必須明確定義正在評估的 M365 環境
- AOC 必須為有效日期
- AOC 必須由 QSA 和實體簽章