Microsoft 365 認證架構概觀
本文提供有關 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 解決方案
- (SaaS) 的 Web 應用程式
- CoPilot 擴充功能
重要事項
Microsoft 365 認證是針對 Microsoft 365 認證架構對應用程式安全性與合規性的嚴格檢閱，需要大量時間和資源承諾才能完成。 開始之前，請檢閱 合規性控制架構 ，以確認您的應用程式符合資格。 如果您有任何問題，請傳送電子郵件給 appcert@microsoft.com。
條款
藉由參與 Microsoft 365 認證計畫，您同意這些補充條款，並遵守適用於您參與 Microsoft 365 認證計畫的任何隨附檔，Microsoft Corporation (“Microsoft”、“we”、“us” 或 “our”) 。 您代表並保證您有權接受這些Microsoft 365 憑證補充條款，代表您自己、公司及/或其他實體，視情況適用。 我們隨時可能會變更、修改或終止這些補充條款。 在任何變更或增修之後，您繼續參與 Microsoft 365 認證計劃，表示您同意新的補充條款。 如果您不同意新的補充條款，或我們終止這些補充條款，您必須停止參與Microsoft 365 認證計劃。
必要條件
在Microsoft 365 認證獲得授權之前，應用程式必須先完成下列作業：
發行者驗證 當應用程式具有已驗證的發行者時，發佈應用程式的組織已由Microsoft驗證為驗證。 驗證應用程式包括使用已驗證的 Microsoft Cloud Partner 計劃 (CPP) 帳戶，並將已驗證的 PartnerID 與應用程式註冊產生關聯。 取得已驗證的發行者
發行者證明 是一個自助程式，應用程式開發人員 (ISV) 完成一組有關其安全性做法的問題，例如處理敏感數據。 完成後，應用程式將會在 Microsoft AppSource 市集上收到特殊的徽章和清單。
檢閱 控制準則 不一定需要遵守所有控制件才能獲得認證。 不過，本概觀檔中所討論的三個安全性網域中，每一個都已 (不會公開) 的臨界值，而且必須通過。 無法符合標示為「硬性失敗」的重要控件會導致評定失敗。
提交時間範圍
提交程式有兩個階段可達成認證：
階段 1：初始檔提交 (14 天的時間範圍)
在此階段中，ISV 必須提交檔，以提供其支援環境的應用程式概觀。 這包括但不限於：
- 架構圖表/數據流
- 系統元件清單
- 軟體資產清查
分析師將會檢閱這份檔，以定義評定的範圍。 ISV 有 14 天的時間可完成並上傳所需的檔。 不符合此期限可能會延遲程式，或導致提交失敗。
階段 2：完整辨識項檢閱 (60 天的時間範圍)
定義範圍之後，ISV 會繼續進行辨識項收集階段。 在此階段中：
- ISV 必須針對從範圍定義的所有適用控件上傳辨識項。
- 此辨識項將會進行檢閱、視需要 (修訂) ，以及最終的 QA 程式。
- 如有需要，也可能會在這段期間進行滲透測試。
從第一個辨識項提交開始，ISV 有 60 天的時間可完成此階段，包括：
- 上傳所有控件的辨識項
- 分析師檢閱和意見反應
- 提交辨識項的任何必要修訂
- QA 程式完成
無法符合期限
如果ISV無法在60天的時間範圍內完成程式，則評定將會失敗。 不過，在分析師的判斷下，在有效的情況下，最多可以再延長 60 天，例如：
- 季節性假日。
- 滲透測試延遲。
- 內部變更。
- 實作必要的變更以符合控制需求所需的時間。
一旦兩個 60 天的時間範圍都用盡之後，就無法授與任何進一步的擴充功能。
認證範圍
範圍內環境包含傳遞應用程式或載入巨集程式代碼所需的所有系統和基礎結構，以及應用程式/載入巨集可能與之通訊的任何支援後端系統。 除非實作適當的分割，而且連線的環境無法危害範圍內環境的安全性，否則任何連線到範圍內環境的其他環境也都必須包含在範圍內。
請注意：任何個別的災害復原環境也都必須包含在範圍內的環境中，因為在發生主要環境失敗時，這些環境對於維護服務持續性至關重要。
此外，遠端備份環境也必須併入範圍，因為它們可能會儲存敏感性Microsoft數據。 因此，必須針對這些環境實作適當的安全性控制。
範圍內系統元件一詞包含在定義的範圍內環境中主動使用的所有裝置和系統。 這些元件包括但不限於：
- Web 應用程式
- 位於內部部署或雲端 (實體或虛擬的伺服器)
- 開關
- 負載平衡器
- 虛擬基礎結構
- 雲端提供者 Web 管理入口網站
- 雲端資源 (虛擬機器、應用程式服務、記憶體帳戶、資料庫等 )
重要事項
公開的系統元件特別容易受到外部威脅執行者的攻擊，因此風險較高。 一般而言，這些系統應該透過實作網路安全性控制 (NSC) 來與內部系統元件隔離，例如 DMZ) (非目標區域。 DMZ 的目的是做為緩衝區，限制擴充至外部系統的信任，並增強安全性以保護內部系統和數據。 雖然在某些情況下 DMZ 仍然很理想，但新式雲端架構通常會依賴專為特定部署案例量身打造的替代安全性措施。
基礎結構即服務 (IaaS) 、平臺即服務 (PaaS) 和軟體即服務 (SaaS)
在IaaS和/或 PaaS 用來支援受檢閱的範圍內環境時，雲端平臺提供者將負責在整個認證程式中評估的一些安全性控制措施。 雲端平臺提供者必須透過PCI DSS、合規性證明 (AOC) 、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數據來識別評量的範圍。
認證會在兩個主要階段進行：
初始檔提交 在此階段，您會提供重要詳細數據，協助分析師瞭解應用程式的設計、數據流和範圍內環境。 分析師將判斷適用的安全性控制措施，並概述需要辨識項的系統元件。 您必須提供精確的檔以協助進行這項檢閱，這大約是整體程式的5%。
完整辨識項檢閱 在此階段中，您會提交詳細的辨識項，示範是否符合範圍內環境的安全性控制措施。 分析師將在此階段與您密切合作，以檢閱、釐清及驗證您的提交。 此階段會採用程序的其餘部分。
評定
一旦核准初始檔提交，入口網站中就會出現必要的安全性控件清單。 您有 60 天 的時間提供每個控件的辨識項，確認控件已就緒且可運作。 分析師會檢閱您的辨識項並核准，或要求其他詳細數據或修訂。
認證
一旦分析師檢閱並驗證您的提交，您將會收到有關認證決策的通知。 成功符合認證準則的應用程式將會獲得徽章，其會顯示在其AppSource清單和相關聯的 Microsoft Docs 頁面上。 這些頁面也會提供應用程式安全性與合規性屬性的詳細報告。
檢閱和重新認證
Microsoft 365 認證應用程式必須經過年度重新認證，以確保持續符合Microsoft的標準。 重新認證程式牽涉到重新評估範圍內的控件，以確認它們與目前的環境一致。 您最多可在認證到期前 90 天開始重新認證程式，以避免任何中斷。 在這段時間內，認證會保持有效。
如果重新認證未在到期日之前完成，則會撤銷認證。 因此：
將會移除應用程式的認證徽章和商標。
ISV 將不再允許以 Microsoft 365 認證方式行銷應用程式。
如果應用程式在排定的重新認證期間以外有 重大變更 ，ISV 必須通知Microsoft應用程式合規性計劃，以確保應用程式保持相容。
初始檔提交
您的初始提交必須包含下列資訊：
| 檔概觀 | 檔詳細數據 |
|---|---|
| 應用程式/載入巨集描述 | 應用程式/載入巨集用途和功能的描述。 這應該可讓認證分析師充分瞭解應用程式/載入巨集的功能及其用途 |
| 滲透測試報告 | 滲透測試報告已在過去 12 個月內完成。 此報告必須包含支援部署應用程式/新增的環境，以及支援應用程式/載入巨集作業的任何其他環境。 注意： 如果ISV目前未執行年度滲透測試，Microsoft將透過認證程式來涵蓋手寫筆測試的成本。 |
| 架構圖表 | 邏輯架構圖，代表應用程序支援基礎結構的高階概觀。 這必須包含 所有 裝載環境和支援支援應用程式的基礎結構。 此圖表必須描述環境中所有不同的支持系統元件，以協助認證分析師瞭解範圍內的系統，並協助判斷取樣。 也請指出使用何種裝載環境類型;ISV Hosted、IaaS、PaaS 或混合式。 注意： 使用 SaaS 的位置，請指出用來在環境中提供支援服務的各種 SaaS 服務。 |
| 公用使用量 | 詳細說明支援基礎結構使用 的所有 公用IP位址和URL。 這必須包含配置給環境的完整可路由IP範圍，除非已實作適當的分割來分割使用中的範圍 (需要適當的分割辨識項) |
| 資料流程圖 | 詳細說明下列各項的流程圖： |
| ✓ Microsoft 365 數據流經應用程式/載入巨集 (，包括 EUII 和 OII.) | |
| ✓ Microsoft 365 在適用) 的情況下，支持的基礎結構 (內的數據流。 | |
| ✓ 圖表醒目提示儲存數據的位置和內容、如何將數據傳遞給外部第三方 (包括第三方) 的詳細數據，以及如何透過開放/公用網路和待用網路保護傳輸中的數據。 | |
| API 端點詳細數據 | 應用程式所使用之所有 API 端點的完整清單。 若要協助了解環境範圍，請在您的環境中提供 API 端點位置。 |
| Microsoft API 許可權 | 提供文件，詳細說明 所有 所使用的Microsoft API，以及應用程式/載入巨集要運作的要求許可權，以及所要求許可權的理由 |
| 數據記憶體類型 | 描述下列項目的資料儲存和處理檔： |
| ✓ 接收和儲存 365 數據 EUII 和 OII 的範圍Microsoft | |
| ✓ 數據保留期間。 | |
| ✓ 擷取Microsoft 365 數據的原因。 | |
| ✓ 儲存Microsoft 365 數據的位置 (也應該包含在上述) 提供的數據流圖中。 | |
| 合規性確認 | 在發行者證明提交中包含的外部安全性架構支持檔，或在檢閱 365 認證安全性控件時Microsoft考慮。 目前支援下列四項： |
| ✓ PCI DSS 合規性證明 (AOC) 。 | |
| ✓ SOC 2 類型 I/類型 II 報告。 | |
| ✓ ISMS / IEC - 1S0/IEC 27001 適用性聲明 (SoA) 和認證。 | |
| ✓ FedRAMP FedRAMP 授權套件和 FedRAMP 整備評估報告。 | |
| Web 相依性 | 列出應用程式搭配目前執行中版本使用之所有相依性的檔。 |
| 軟體庫存 | 最新的軟體清查，其中包含範圍內環境中使用的所有軟體以及版本。 |
| 硬體清查 | 支援基礎結構所使用的最新硬體清查。 這會用來協助您在執行評定階段時進行取樣。 如果您的環境包含 PaaS，請提供已取用雲端服務/資源的詳細數據。 |
辨識項收集和評量活動
認證分析師必須在定義的範例集內檢閱所有系統元件的辨識項。 支援評估程式所需的辨識項類型包括下列任何或所有專案：
Evidence 集合
- 初始檔，在初始檔提交指南中反白顯示
- 原則檔
- 處理檔
- 系統組態設定
- 變更票證
- 變更控制項記錄
- 系統報告
- 會議分鐘數
- 合約/合約
將使用各種方法來收集完成評定程式所需的辨識項。 此辨識項集合的格式可能如下：
- 文件
- 螢幕擷取畫面
- 採訪
- 屏幕共用
在評估程序期間，將會決定所使用的辨識項集合技術。 如需提交中所需辨識項類型的特定範例，請參閱範 例辨識項指南。
評定活動
認證分析師會檢閱提交的辨識項，以確認符合Microsoft 365 認證所需的所有控件。 若要加速此程式，請確定 初始檔提交 中指定的所有檔都已完成並事先提供。
在檢閱期間，分析師會評估來自初始提交和發行者證明的辨識項。 它們會決定查詢範圍、取樣端，以及是否需要其他辨識項。 分析師將使用所有收集的信息來評估Microsoft 365 認證規格的合規性，並決定您的應用程式是否符合定義的控件。
應用程式認證準則
應用程式及其支援的基礎結構和支援檔案將評估於下列三個安全性網域：
這些安全性網域都包含特定的關鍵控制件，其中包含一或多個將在評定程式中評估的需求。 為了確保Microsoft 365 認證包含所有大小的開發人員，系統會使用評分系統來評估每個安全性網域，以判斷每個網域的整體分數。 每個Microsoft 365 認證控件的分數會根據該控件未實作的認知風險，在 1 (低) 和 3 (高) 之間配置。 每個安全性網域都有要視為通過的最小百分比標記。 某些因素會導致自動失敗，包括
使用不符合最低許可權原則的 API 許可權 (PoLP)
必要時缺少滲透測試報告。
沒有反惡意代碼防禦。
無法針對系統管理存取 (MFA) 實作多重要素驗證。
缺少或不足的修補程式。
缺少相容的 GDPR 隱私權注意事項。
應用程式安全性
應用程式安全性網域會評估下列區域：
- GraphAPI 許可權驗證
- 外部連線檢查
- 滲透測試
GraphAPI 許可權驗證
這可確保應用程式或載入巨集不會要求過多或過度寬鬆的許可權。 認證分析師會手動檢閱應用程式要求的許可權，並針對發行者證明提交進行交叉檢查。
目標是要確認要求的許可權遵守最低許可權原則。 如果分析師發現應用程式要求的許可權超過所需的許可權，他們會與ISV互動，以驗證這些許可權的商業理由。 在此檢閱期間，必須解決所要求許可權與發行者證明提交之間所識別的任何不一致。
外部連線檢查
在認證程式中，分析師會執行應用程式功能的高階檢閱，以識別在 Microsoft 365 外部建立的任何外部連線。
任何未識別為Microsoft服務或與您的服務無關的連線，都會在評估期間標示為討論，以確保符合安全性和功能標準。
滲透測試
滲透測試對於識別和降低與應用程式或載入巨集及其支援環境相關的風險非常重要。 這可確保應用程式為客戶提供適當的安全性保證。
任何連線到未由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 弱點的存在，例如標頭回應分割、要求破壞和還原同步攻擊。 | |
| 原始程式碼洩漏 (包括 LFI) 。 | |
| CVSS 修補程式管理指導方針所定義的任何重要或高分。 | |
| 任何可輕易利用來危害大量 EUII 或 OUI 的重大技術弱點。 |
重要事項
報告必須能夠提供足夠的保證，才能示範上述滲透測試需求一節中詳述的所有專案。
免費滲透測試需求和規則
對於目前未執行滲透測試的ISV，Microsoft在Microsoft 365 認證程式中提供免費的滲透測試服務。 此服務涵蓋最多 12 天的手動測試，除了 ISV 的責任之外，還需支付任何必要天數的額外成本。
主要需求
測試前需求：ISV 必須先提交辨識項，並取得 50% 範圍內控件的核准，才能排程滲透測試。
測試報告：此報告與您的Microsoft 365 認證，可用來向客戶證明您的環境是安全的。
弱點補救：ISV 負責解決測試期間所識別的任何弱點，才能獲得認證。 不過，不需要清除報告，只確認弱點已充分解決的辨識項。
其他考量
一旦排列滲透測試之後，ISV 會負責涵蓋與重新排程或取消相關聯的任何費用。
| 重新排程費用時幅 | 可支付的比例 |
|---|---|
| 重新排程要求在排定的開始日期之前收到超過 30 天。 | 0% 可支付 |
| 在排定的開始日期前 8 到 30 天收到重新排程要求。 | 25% 可付款 |
| 在排程開始日期之前的 2 到 7 天內收到重新排程要求，並提供公司重新預約日期。 | 50% 可付款 |
| 重新排程要求在開始日期之前不到 2 天收到。 | 100% 可付款 |
| 取消費用時幅 | 可支付的比例 |
|---|---|
| 取消要求在排定的開始日期之前收到超過 30 天。 | 25% 可付款 |
| 在排定的開始日期前 8 到 30 天收到取消要求。 | 50% 可付款 |
| 在排定的開始日期之前的 7 天內收到取消要求。 | 90% 可支付 |
作業安全性
此網域會使用安全性最佳做法來測量應用程式支援基礎結構和部署程式的一致性。
控制項
| 控制系列 | Controls |
|---|---|
| 認知訓練 | 提供證據，讓組織為資訊系統使用者提供已建立的安全性意識訓練， (包括經理、資深主管和約聘人員) 作為新使用者初始訓練的一部分，或資訊系統變更時。 |
| 提供組織定義之認知訓練頻率的辨識項。 | |
| 提供個別資訊系統安全性感知活動的檔和監視證據，同時保留組織定義頻率的個別訓練記錄。 | |
| 惡意代碼保護 - 防病毒軟體 | 提供證據，證明您的反惡意代碼解決方案已在所有取樣的系統元件中啟用，並已設定為符合下列準則： |
| 如果是防病毒軟體，則會啟用該存取掃描，且簽章在 1 天內是最新的，而且會在偵測到惡意代碼時自動封鎖惡意代碼或警示和隔離。 | |
| 或者，如果 EDR/NGAV (端點偵測和回應/新一代防病毒軟體) 則會執行定期掃描、產生稽核記錄，並持續保持在最新狀態，並具有自我學習功能。 | |
| 如果是 EDR/NGAV，則會封鎖已知的惡意代碼，並根據巨集行為以及具有完整安全清單功能來識別和封鎖新的惡意代碼變體。 | |
| 惡意代碼保護 - 應用程控 | 提供可辨識的辨識項，證明具有商業理由的軟體/應用程式已核准清單存在且為最新狀態。 |
| 每個應用程式都會經歷核准程式，並在部署之前先註銷 | |
| 該應用程控技術已在所有取樣的系統元件上啟用、啟用及設定，如所述。 | |
| 修補程式管理 - 修補和風險排名 | 提供原則檔，控管如何識別新的安全性弱點並指派風險分數。 |
| 提供如何識別新安全性弱點的辨識項。 | |
| 提供辨識項，證明一旦識別出所有弱點，都會獲指派風險排名。 | |
| 提供證據，證明所有取樣的系統元件都會與組織定義的修補時間範圍進行修補，且不支援的操作系統和軟體元件不在使用中。 如果使用無伺服器技術或 PaaS，這應該包含程式代碼基底，如果使用 IaaS，則應包含基礎結構和程式代碼基底。 | |
| 修補時間範圍指導方針：重大 – 在 14 天內、高 – 30 天內、中 – 60 天內。 | |
| 弱點掃描 | 提供每季的基礎結構和 Web 應用程式弱點掃描報告。 必須針對整個公用使用量進行掃描， (IP位址和URL) 和內部IP範圍。 |
| 提供可辨識的辨識項，證明在弱點掃描期間所識別的弱點補救會依照您記載的修補時間範圍進行修補。 | |
| NSC) (網路安全性控制 | 提供辨識項，證明 NSC) (網路安全性控制已安裝在範圍內環境的界限上，並安裝在周邊網路與內部網路之間。 |
| AND 如果 Hybrid、On-prem、IaaS 也提供證據，證明所有公用存取都會在周邊網路終止。 | |
| 驗證 NSC) (的所有網路安全性控制項都設定為卸除未在規則基底內明確定義的流量，而且至少每 6 個月會執行一次 NSC) 規則檢閱 (網路安全性控制。 | |
| 變更控制件 | 提供證據，證明對生產環境引進的任何變更都是透過記載的變更要求來實作，其中包含變更的影響、備份程式的詳細數據、要執行的測試、由授權的人員檢閱和核准。 |
| 提供個別環境存在的辨識項，以便：開發和測試/預備環境會強制區分職責與生產環境、透過訪問控制強制執行職責區分、敏感性生產數據不在開發或測試/預備環境中使用。 | |
| 安全軟體開發/部署 | 提供支援安全軟體開發的原則和程式，並包含用於安全編碼的業界標準和/或最佳做法。 例如 Open Web Application Security Project (OWASP) Top 10 或 SysAdmin、Audit、Network and Security (SANS) 前 25 大常見弱點列舉 (CWE) 。 |
| 提供程式代碼存放庫受到保護的辨識項，如此一來：所有程式代碼變更都會先由第二位檢閱者進行檢閱和核准程式，再與主要分支合併、適當的訪問控制就緒、所有存取都會透過多重要素驗證強制執行， (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 壓縮，以防止壓縮比例資訊外洩使 (性) 變得簡單，而且 TLS HSTS 已在所有網站中啟用並設定為 180 天。 | |
| 待用數據 | 使用進階加密 Standard (AES) 、RSA 和具有 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 的認證和一致性標準
適用於PCI DSS (QSA) 的品質安全性評估人員
如需其他詳細數據，請參閱與您的認證相關的外部架構的特定指導方針和標準。
下表概述認證分析師在驗證程式中接受的必要架構和檔。
| Standard | 需求 |
|---|---|
| ISO 27001 | 需要公開版本 的適用性 聲明 (SOA) ，以及發行的 ISO 27001 憑證複本。 SOA 會摘要說明您在114個資訊安全性控件中的位置，並用來識別是否排除ISO 27001 憑證中未令人滿意的控件。 如果無法藉由檢閱公開版本的SOA來判斷這點，如果ISO 27001將用來驗證某些Microsoft 365 認證安全性控件，則分析師可能需要存取完整的SOA。 除了驗證 ISO 27001 評定活動的範圍之外，分析師也會確認稽核公司的有效性，如上所述。 |
| PCI DSS | 必須提供有效的 合規性層級 1 證明 (AOC) 檔，以清楚識別範圍內的應用程式和系統元件。 自我評定 AOC 將不會 被接受為會議安全性最佳做法的辨識項。 AOC 將用來判斷哪些Microsoft 365 認證規格控件已評估並確認為PCI DSS評量的一部分。 |
| SOC 2 | SOC 2 (類型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 個月內，如果目前正在執行重新評估，且可以提供辨識項) 。
✓ 支援的外部安全性合規性架構 必須 由獨立認證的公司執行。