Microsoft 365 認證架構概觀
本文提供詳細資訊，包括Microsoft 365 認證安全性控件的清單，以及ISV和開發人員Microsoft 365 認證的支援。
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 應用程式
重要事項
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合作夥伴中心 進行發行者證明，並在完成時接收 Microsoft AppSource 市集內的徽章和專用篩選器。
檢閱 控制準則 不需要遵守所有控件，即可獲得認證。 不過，本概觀檔中所討論的三個安全性網域中，每一個都已 (不會公開) 的臨界值，而且必須通過。 某些控制項會分類為「硬性失敗」，這表示缺少這些安全性控件會導致評定失敗。
重要事項
提交時間範圍： 評定程式平均需要 30 天的時間，前提是 ISV 能夠經常檢查提交狀態，並及時回應批註和補充辨識項要求。 開始認證程式時，最多允許 60 天完成評定。 如果所有提交尚未在 60 天的期間內完成，提交將會發出失敗，而且程式必須重新開始。 這些結果不會公開。
認證範圍
範圍內 的環境 支援傳遞應用程式/載入巨集程序代碼，並支援應用程式/載入巨集可能與之通訊的任何後端系統。 除非已備妥適當的分割，且連線到環境不會影響範圍內環境的安全性，否則連線到範圍內環境的任何其他環境也會包含在範圍內。
任何個別的災害復原環境也都必須包含在範圍內的環境中，因為如果主要環境發生任何狀況，則需要這些環境才能完成服務。 此外，也必須包含遠端備份環境，因為這些環境可能會儲存Microsoft數據，因此必須備妥適當的安全性控制。
範圍 內系統元件 一詞會參考定義的範圍內環境中所使用 的所有 裝置和系統。 範圍內的元件包括但不限於：
- Web 應用程式 (的)
- 伺服器 (內部部署或雲端中的實體或虛擬)
- 網路安全性控制 (NSC) ，例如防火牆
- 開關
- 負載平衡器
- 虛擬基礎結構
- 雲端提供者 Web 管理入口網站
- 雲端資源 (虛擬機器、App Service、記憶體帳戶、EC2 實例等。)
重要事項
公開的系統元件容易受到來自外部威脅執行者的攻擊，因此風險更大。 一般而言，使用網路安全性控制 (NSC，這些系統會與其他內部系統元件區隔開，) 在 DMZ) (建立非目標區域。 其目的是 DMZ 不受內部網路的信任，而額外的安全性有助於在公開的系統遭到入侵時，進一步保護內部系統和數據。 在理想情況下，會使用 DMZ，不過這在某些部署案例中是不可行或甚至是必要的。
基礎結構即服務 (IaaS) 、平臺即服務 (PaaS) 和軟體即服務 (SaaS)
在IaaS和/或 PaaS 用來支援受檢閱的範圍內環境時，雲端平臺提供者將負責在整個認證程式中評估的一些安全性控制措施。 雲端平臺提供者必須透過PCI DSS、合規性證明 (AOC) 、ISO 27001 或 SOC 2 Type II 報告等外部合規性報告，為分析師提供獨立的外部安全性最佳做法驗證。
附錄 C 會根據下列部署類型，並根據應用程式是否Microsoft 365 資料來提供可能適用的安全性控件詳細資料：
- ISV 裝載
- 裝載的 IaaS
- 裝載的 PaaS/無伺服器
- 混合式託管
- 共用託管
部署 IaaS 或 PaaS 時，必須提供辨識項來驗證環境與這些部署類型的一致性。
採樣
支持認證評量的辨識項要求應以考慮不同操作系統、裝置的主要功能、不同裝置類型 (例如伺服器、NSC、路由器等 ) 和位置的範圍內系統元件範例為基礎。 在認證程序開始時，將會選取適當的範例。 下表應作為參考線，其中取樣會根據上述詳細的因素來決定：
| 母體大小 | 範例 |
|---|---|
| <=5 | 1 |
| >5 & <10= | 2 |
| >10 & <=30 | 3 |
| >30 | 4 |
注意事項
如果在初始範例中包含的裝置之間發現不一致，則在評估期間可能會增加樣本大小。
端對端認證程式
若要開始Microsoft 365 認證：
在合作夥伴中心內，選取 [開始認證] 以開始初始檔提交。 這可協助認證分析師根據應用程式的架構，以及其處理Microsoft數據的方式，判斷評量的範圍。
提示
請遵循 操作指南 以取得您的應用程式Microsoft 365 認證的逐步指示。
認證程式會執行兩個階段，如下所述：
初始檔提交 可協助分析師瞭解應用程式、數據流、定義 範圍內的環境、識別適用的安全性控件，以及判斷需要從中收集辨識項的系統元件。 ISV 必須提供要求的資訊，以協助認證分析師完成程式的這個階段，這大約是整體程式的 5%。
完整辨識項檢閱 是ISV提交辨識項成品的程式，示範 範圍內環境 如何符合安全性控制措施。 在這個稽核階段，ISV 與分析師之間會進行多個互動，這是程式的其餘部分。
評定
一旦接受初始檔提交，一組安全性控件就會自動顯示在入口網站中。 ISV 必須為每個控件提供辨識項，以證明控件已就緒，且有 60 天 可提交所有辨識項。 分析師會檢閱辨識項，並核准控件或要求新的或額外的辨識項。
認證
一旦提交經過分析師驗證，ISV 就會收到認證決策的通知。 獲得認證的應用程式將會在其 AppSource 內的應用程式上收到徽章，以及具有其安全性與合規性屬性詳細報告的專用 Microsoft文件 頁面。
檢閱和重新認證
Microsoft需要 365 個認證應用程式，才能每年進行重新認證。 這需要針對目前的範圍內環境重新驗證範圍內的控件。 此程式最多可在認證到期前 90 天開始。 現有的認證不會在重新認證期間過期。 所有計劃的重新認證會在您Microsoft 365 認證的一周年日到期。
如果認證未在到期日之前更新，則會撤銷應用程式認證狀態。 所有徽章、圖示和相關聯的認證商標都會從您的應用程式中移除，且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) 。
- 不需要滲透測試報告。
- 沒有反惡意代碼防禦。
- Multi-Factor Authentication 不會用來保護系統管理存取權。
- 沒有修補程式。
- 沒有適當的 GDPR 隱私權注意事項。
應用程式安全性
應用程式安全性網域著重於三個領域：
- GraphAPI 許可權驗證
- 外部連線檢查
- 滲透測試
GraphAPI 許可權驗證
執行 GraphAPI 許可權驗證，以驗證應用程式/載入巨集不會要求過度寬鬆許可權。 這是透過手動檢查要求的許可權來執行。 認證分析師會針對發行者證明提交交叉參考這些檢查，並評估所要求的存取層級，以確保符合「最低許可權」做法。 在認證分析師認為不符合這些「最低許可權」做法的情況下，認證分析師會與ISV進行開放討論，以驗證所要求許可權的商業理由。 在此檢閱期間找到的任何發行者證明提交不一致，都必須更正。
外部連線檢查
在評估過程中，將會執行應用程式功能的簡易逐步解說，以識別在 Microsoft 365 之外建立的任何連線。 任何未識別為Microsoft連線或直接連線至您服務的連線，都會在評量期間標示並討論。
滲透測試
適當檢閱與應用程式/載入巨集和支援環境相關聯的風險，對於為客戶提供應用程式/載入巨集安全性的保證至關重要。 如果您的應用程式與Microsoft未發佈的任何服務有任何連線，則必須執行滲透測試形式的應用程式安全性測試。 如果您的應用程式一旦部署，就只能獨立存取 GraphAPI 等Microsoft服務，則不需要滲透測試。 如果範圍內 的環境裝載於 Azure 內，則仍然需要滲透測試。
滲透測試範圍
針對內部和外部基礎結構滲透測試，所有滲透測試活動 都必須 在支援應用程式/載入巨集 (部署的實時生產環境中進行，例如;其中裝載應用程式/載入巨集程序代碼，這通常是指令清單檔案內的資源，) 以及支援應用程式/載入巨集 (作業的任何其他環境，例如，如果應用程式/載入巨集與 Microsoft 365) 以外的其他 Web 應用程式通訊。 定義滲透測試的範圍時，必須小心確保所有滲透測試活動中也包含任何可能影響範圍內環境安全性的「連線到」系統或環境。
建議針對即時生產環境進行 Web 應用程式滲透測試。 不過，只使用測試/UAT 環境執行 Web 應用程式測試是可接受的，前提是在滲透測試報告中確認測試時，完全相同的程式代碼基底在測試/UAT 環境中運作。
在使用技術來區隔範圍內環境與其他環境時，滲透測試活動必須驗證上述分割技術的有效性。 這必須在滲透測試報告中詳細說明。
注意事項
除非裝載環境只分類為 PaaS，否則必須執行內部滲透測試。
滲透測試需求
系統會檢閱滲透測試報告，以確保沒有任何弱點符合下列控件中所述的 自動失敗準則 。
| 準則類型 | 滲透測試控制件 |
|---|---|
| 一般準則 | 如果適用) 和外部基礎結構滲透測試，Web 應用程式 (已驗證和未經驗證的) 和內部 (必須 每隔 12 個月 () 一次，並由信譽良好的獨立公司進行。 |
| 根據ISV記載的修補程式， 必須在 滲透測試結束後的一個月內完成已識別嚴重和高風險弱點的補救，或更快完成。 | |
| 完整的外部使用量 (IP位址、URL、API端點等。) 必須 包含在滲透測試範圍內，而且必須在滲透測試報告中清楚記載。 | |
| 除非環境對齊 PaaS，否則完整的內部網路 必須 包含在滲透測試範圍內，而且必須在滲透測試報告中清楚記載。 | |
| Web 應用程式滲透測試 必須 包含所有弱點類別;例如，最新的 OWASP 前 10 名或 SANS 前 25 名 CWE。 建議您在滲透測試報告中詳細說明，否則將難以示範。 | |
| 被視為自動失敗的重大和高風險弱點或弱點 必須 由滲透測試公司重新測試，並在滲透測試報告中明確地反白顯示為已修正。 | |
| 自動失敗準則： | 不支援的操作系統或不支援的 JavaScript 連結庫存在。 |
| 預設、可列舉或可猜測的系統管理帳戶存在。 | |
| 存在 SQL 插入式風險。 | |
| 存在跨網站腳本。 | |
| 存在目錄周遊 (檔案路徑) 弱點。 | |
| HTTP 弱點的存在，例如標頭回應分割、要求破壞和還原同步攻擊。 | |
| 原始程式碼洩漏 (包括 LFI) 。 | |
| CVSS 修補程式管理指導方針所定義的任何重要或高分。 | |
| 任何可輕易利用來危害大量 EUII 或 OUI 的重大技術弱點。 |
重要事項
報告必須能夠提供足夠的保證，才能示範上述滲透測試需求一節中詳述的所有專案。
免費滲透測試需求和規則
- 對於目前不參與滲透測試的ISV，您可以免費進行Microsoft 365 認證的滲透測試。 Microsoft會安排並涵蓋最多 12 天手動測試的滲透測試成本。 滲透測試成本是根據測試範圍內環境所需的天數來計算。 任何超過 12 天的測試費用都會由 ISV 負責。
- 在進行滲透測試之前，ISV 必須提交辨識項，並取得範圍內 50% 控件的核准。 若要開始使用，請填寫您的初始檔提交，並選擇在評量中包含滲透測試。 當您完成 50% 的控制件時，將會連絡您以設定滲透測試的範圍和排程。
- 手寫筆測試完成後發出的報告會在ISV完成認證後提供給ISV。 此報告與您的 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 v1.1的TLS連線進行加密保護。 建議 (TLS v1.2+) 。 請參閱附錄 A。
當您的應用程式擷取並儲存Microsoft 365 數據時，您必須實作遵循 附錄 B 中所定義之規格的數據記憶體加密配置。
控制項
| 控件系列 | Controls |
|---|---|
| 傳輸中的數據 | 提供在 TLS 設定檔設定需求 內驗證 TLS 組態為 TLS1.2 或更高版本的辨識項，並保留並維護受信任密鑰和憑證的清查。 |
| 提供辨識項顯示所有處理 Web 要求的公開服務都已停用 TLS 壓縮，以防止壓縮比例資訊外洩使 (性) 變得簡單，而且 TLS HSTS 已在所有網站中啟用並設定為 180 天。 | |
| 待用數據 | 提供證明待用數據會根據加密配置檔需求進行加密，並使用進階加密演算法，例如進階加密 Standard (AES) 、RSA 和具有 256 位或更高加密密鑰大小的 Twofish。 |
| 數據保留、備份和處置 | 提供已正式建立並記載已核准數據保留期限的證明。 |
| 提供證據，證明數據只會保留在先前控件中所討論的已定義保留期間。 | |
| 提供已備妥處理程式的辨識項，以便在數據保留期間之後安全地刪除數據。 | |
| 提供自動化備份系統已就緒並設定為在排程時間執行備份的辨識項。 | |
| 提供辨識項備份資訊會依照備份排程程式進行測試，並定期還原，以確認數據的可靠性和完整性。 | |
| 提供辨識項適當的訪問控制和保護機制 (也就是實作不可變的備份) ，以確保備份/系統快照集會受到保護，防止未經授權的存取，並確保備份數據的機密性、完整性和可用性。 | |
| 數據存取管理 | 提供可存取資料和/或加密金鑰之使用者清單的辨識項。 包括每個人的商業理由，並確認此使用者清單已根據其作業函式所需的訪問許可權正式核准，而使用者則是以核准中所述的許可權進行設定。 |
| 提供證據，證明已維護與數據共用的所有第三方清單，且數據共享協定已與所有使用數據的第三方一起準備就緒。 | |
| 隱私權 | 貴組織是否有隱私權資訊管理 (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 或 SOC2 的規範，您可以選擇使用這些認證來滿足某些Microsoft 365 認證控件。分析師會嘗試將現有的外部安全性架構與Microsoft 365 認證架構對齊。 不過，如果支援檔無法保證Microsoft 365 認證控件已評估為外部安全性架構稽核/評估的一部分，您就必須提供上述控件的其他辨識項。
文件必須充分證明Microsoft 365 認證的範圍內環境已包含在這些外部安全性架構的範圍內。 接受由信譽良好的外部第三方公司所進行之有效認證的辨識項，即可完成這些安全性架構的驗證。 這些信譽良好的公司必須是相關合規性計劃之國際認證機構的成員。 請參閱 ISO 27001 的 ISO 認證和一致性標準，以及 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在參考安全性狀態時獲得保證層級。
使用外部合規性架構的需求
✓ 範圍內環境 和 任何支援的商務程式 都必須 包含在任何支援的外部安全性合規性架構範圍內，而且必須在提供的檔中清楚指出。
✓ 支援的外部安全性合規性架構 必須 是最新的，也就是說，在過去 12 個月內 (或在 15 個月內，如果目前正在執行重新評估，且可以提供辨識項) 。
✓ 支援的外部安全性合規性架構 必須 由獨立認證的公司執行。