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、專案)
• Teams 應用程式
• SharePoint 解決方案
• 網頁應用程式 (SaaS)
• 副駕駛分機

條款

參與Microsoft 365認證計畫即表示您同意這些補充條款，並遵守適用於您參與Microsoft 365認證計畫的相關文件，Microsoft (「Microsoft」、「我們」、「我們」或「我們的」) 。 您代表並向我們保證，您有權代表自己、公司及/或其他適用實體接受這些 Microsoft 365 認證補充條款。 我們可隨時更改、修訂或終止這些補充條款。 您在任何變更或修訂後繼續參與 Microsoft 365 認證計畫，即表示您同意新的補充條款。 如果您不同意新的補充條款，或我們終止這些補充條款，您必須停止參與 Microsoft 365 認證計畫。

必要條件

在授予 Microsoft 365 認證之前，應用程式必須完成以下條件：

出版商驗證 當應用程式擁有經過驗證的發佈者時，發布該應用程式的組織已經過 Microsoft 驗證為真實。 驗證應用程式包括使用已驗證Microsoft雲端合作夥伴計畫 (CPP) 帳戶，並將已驗證的合作夥伴ID與應用程式註冊綁定。 讓出版商認證

出版者認證 是一種自助式流程，應用程式開發者 (獨立軟體供應商（ISV）) 填寫一組關於其安全實務的問題，例如如何處理敏感資料。 完成後，應用程式會收到一個文件頁面，讓他們可以分享給客戶，裡面包含他們提供的回應。

檢視 控制標準。 並非總是必須遵守所有管制才能獲得認證。 然而，對於本概述文件中討論的三個安全領域，) (門檻不會公開，且必須通過。 未達到標示為「硬失敗」的關鍵控制項，將導致評量不及格。

提交時間範圍

申請認證的過程分為兩個階段：

第一階段：初次文件提交 (14天期限)

在此階段，ISV 必須提交文件，概述其應用程式的支援環境。 這包括但不限於：

• 架構圖/資料流程

• 系統元件清單

• 軟體資產清單

分析師會審查這些文件以界定評估範圍。 ISV 有 14 天時間完成並上傳所需文件。 未能按時完成此期限可能會延誤申請過程或導致提交失敗。

第二階段：完整證據審查， (60天期限)

一旦範圍明確，ISV將進入證據收集階段。 在這個階段：

1. ISV必須上傳針對範圍中定義的所有適用控制措施的證據。

2. 這些證據將經過審查、必要時 (修訂，) ，以及最終的問答程序。

3. 此期間也可能進行滲透測試。

獨立軟體供應商有60天時間完成此階段，從首次提交證據開始，內容包括：

• 上傳所有控制的證據

• 分析師審查與回饋

• 提交的證據有需要修改的地方嗎？

• 問答流程完成

未能如期完成

若ISV未能在60天內完成流程，評估將失敗。 然而，分析師可酌情在有效情況下，批准最多60天的延長，例如：

• 季節性假期
• 滲透測試延遲
• 內部變動
• 實施必要變更以符合控制要求所需的時間

一旦兩個60天期限都用盡，將不再允許任何延期。

認證範圍

範圍內環境涵蓋所有提供應用程式、外掛程式或代理程式碼所需的系統與基礎設施，以及該應用程式/外掛/代理可能與之通訊的任何支援後端系統。 除非實施足夠的分段且連接環境不會影響範圍內環境的安全，否則任何與範圍內環境相連的額外環境也必須納入範圍。

請注意：任何獨立的災難復原環境也必須包含在範圍內環境中，因為這些環境對於在主要環境故障時維持服務連續性可能至關重要。

此外，遠端備份環境也必須納入範圍，因為它們可能儲存敏感的 Microsoft 資料。 因此，必須對這些環境實施足夠的安全控管。

「範圍內系統元件」一詞涵蓋所有在定義範圍內環境中積極使用的裝置與系統。 這些組成部分包括但不限於：

• Web 應用程式
• 伺服器 (實體或虛擬，無論是本地部署或雲端)
• 交換機
• 負載平衡器
• 虛擬基礎架構
• 雲端供應商網頁管理入口網站
• 雲端資源 (虛擬機器、應用程式服務、儲存帳號、資料庫等等 )

基礎設施即服務 (IaaS) 、平台即服務 (PaaS) ，以及軟體即服務 (SaaS)

若使用 IaaS 和/或 PaaS 支援審查範圍內環境，雲端平台提供者將負責整個認證過程中評估的一些安全控管。 分析師需透過外部合規報告（如 PCI-DSS、合規證明 (AOC) 、ISO 27001 或 SOC 2 第二類報告）獲得獨立外部安全最佳實務驗證。

關於部署類型可能適用哪些安全控制措施，以及環境是否處理或傳輸 Microsoft 365 資料，請參閱 附錄 C。部署類型包括：

• ISV 託管：由獨立軟體廠商託管的應用程式
• IaaS 託管：由第三方雲端平台提供的基礎設施。
• PaaS/無伺服器託管：採用平台或無伺服器架構的平均應用。
• 混合主機：結合本地與雲端主機元件。
• 共享主機：由多個租戶共用的雲端環境。

在使用 IaaS 或 PaaS 的情況下，必須有證據證明部署符合相關架構預期的安全控管。

抽樣

為確保全面評估，涵蓋範圍內系統元件的抽樣必須考量作業系統、主要裝置功能、裝置類型 (例如伺服器、路由器、網路安全控制) 及地理位置等因素。 樣品會在認證流程開始時根據這些考量選出。 下表根據範圍內元件的人口數量，指導抽樣大小：

這確保了對環境在不同配置與部署模式中合規性的具代表性評估。

認證流程概述

要開始 Microsoft 365 認證流程：

1. 出版商認證 前往合作夥伴中心並填寫出版商認證表格。 注意：若提交超過三個月，必須重新提交以供審核與驗證。

2. 開始認證 進入合作夥伴中心後，選擇「開始認證」選項，開始提交初始文件。 此步驟協助認證分析師根據您的應用程式架構及其管理 Microsoft 資料的方式，確定評估範圍。

認證分為兩個主要階段：

1. 初始文件提交 此階段，你提供關鍵細節，幫助分析師了解應用程式的設計、資料流及範圍內環境。 分析師將確定適用的安全控管，並列出需要證據的系統組件。 您必須提供準確的文件以促進此審查，約佔整體流程的5%。

2. 完整證據審查 在此階段，您提交詳細證據，證明其符合範圍內環境的安全控管。 分析師在此階段將與您密切合作，審查、釐清並驗證您的提交內容。 這個階段佔據了整個過程的剩餘部分。

評定

一旦初步文件提交獲准，入口網站中會出現一份必要的安全控管清單。 你有 60天 時間為每個控制措施提供證據，確認其已實施且可運作。 分析師會審查你的證據，並批准或要求補充細節或修訂。

認證

當您的申請經過分析師審核並驗證後，您將收到有關認證決定的通知。 成功符合認證標準的應用程式將獲得徽章，該徽章會顯示在其 AppSource 列表及相關的 Microsoft Docs 頁面上。 這些頁面也會提供應用程式安全與合規屬性的詳細報告。

審查與重新認證

Microsoft 365 認證應用程式必須每年重新認證，以確保持續符合 Microsoft 標準。 重新認證過程包括重新評估範圍內的控制措施，以確認其符合當前環境。 您可以在認證到期前最多90天開始重新認證程序，以避免任何中斷。 認證在此期間將持續有效。

若在到期日前未完成重新認證，認證將被撤銷。 因此：

• 該應用程式的認證徽章和品牌標籤將會被移除。

• ISV 將不再被允許以 Microsoft 365 認證的名義行銷該應用程式。

若應用程式在預定重新認證期間之外有 重大變更 ，ISV 必須通知 Microsoft 應用程式合規計畫，以確保該應用程式持續合規。

初次提交文件

您的初始提交必須包含以下資訊：

證據收集與評估活動

認證分析師需審查定義樣本集中所有系統組件的證據。 支持評估流程所需的證據類型包括以下任何或全部：

證據蒐集

• 初步文件，於初始文件提交指南中標示
• 政策文件
• 程序文件
• 系統設定
• 換票
• 變更控制紀錄
• 系統報告
• 會議記錄
• 合約/協議

將採用多種方法收集完成評估程序所需的證據。 這些證據收集可能以以下形式進行：

• 文件
• 螢幕擷取畫面
• 訪談
• 螢幕共享

所採用的證據蒐集技術將在評估過程中決定。 關於提交文件中所需證據類型的具體範例，請參閱 範例證據指南。

證據分享

在認證過程中，獨立軟體供應商可選擇直接與潛在客戶分享合規證據。 檔案上傳對話框中預設勾選的方框，會授權 Microsoft 365 管理員存取 Teams 管理員中心及 Microsoft 365 系統管理中心的應用程式認證證據。 (Microsoft 365 管理員負責在組織內配置、管理及保障 Microsoft 365 服務與資源。) 此透明度旨在簡化組織評估新應用程式時的盡職調查流程，以加速決策。 若ISV不願公開此證據，他們可在提交時取消勾選，保有完全自主權決定合規文件何時何地揭露。

評估活動

認證分析師將審查提交的證據，以確保 Microsoft 365 認證所需的所有控制措施均已達成。 為加快流程，請確保 初始文件 提交中所有文件皆已完整並提前提供。

在審查過程中，分析師將評估最初提交及出版社聲明的證據。 他們將決定調查範圍、抽樣方，以及是否需要額外證據。 分析師將利用所有收集的資訊評估是否符合 Microsoft 365 認證規範，並判斷您的應用程式是否符合定義的控制範圍。

應用程式認證標準

該應用程式及其支援基礎設施和相關文件將在以下三個安全領域進行評估：

1. 應用程式安全
2. 作戰安全
3. 資料處理、安全性與隱私

每個安全領域都包含包含一項或多項將作為評估過程一部分需求的具體關鍵控制。 為確保 Microsoft 365 認證對各種規模的開發者皆具包容性，每個安全領域皆使用評分系統評估，以確定各領域的整體分數。 每個Microsoft 365認證控制的分數，根據該控制未實施的風險，分配介於1 (低) 與3 (高) 之間。 每個安全領域都會有一個最低百分比標記，才能被視為通過。 某些因素會導致自動故障，包括：

• 使用不符合最小權限原則 (PoLP)

• 必要時缺乏滲透測試報告。

• 缺乏反惡意軟體防禦措施。

• 未能實作多重驗證 (多重驗證) 用於管理存取。

• 缺少或不足的補丁流程。

• 缺乏符合GDPR 規範的 隱私聲明。

應用程式安全

應用安全領域評估以下領域：

• 滲透測試
• 圖形 API 權限驗證
• 負責任的 AI

滲透測試

滲透測試對於識別及減輕應用程式或外掛及其支援環境相關風險至關重要。 這確保應用程式能為客戶提供足夠的安全保障。

滲透測試是任何連接非 Microsoft 託管或管理外部服務的 應用程式的強制 性。 若應用程式作為僅使用 Microsoft 服務（如 GraphAPI）的獨立解決方案部署，則可能不需要滲透測試。 然而，託管於 Azure 的應用程式必須通過滲透測試，以確保範圍內環境的安全性。

滲透測試範圍

基礎設施測試：無論是內部或外部基礎設施，滲透測試都必須在支援該應用程式、外掛或代理程式的 正式生產環境中 進行。 這包括：

應用程式、外掛程式或代理程式所託管的環境通常 (在清單檔案) 中被引用。

任何與應用程式/外掛/代理程式互動或支援其運作的額外環境 (，例如該應用程式/外掛/代理程式與 365) 外的其他網頁應用程式Microsoft通訊。

在定義滲透測試的範圍時，必須納入所有可能影響範圍內環境安全的 連網系統或環境 。

建議

網頁應用程式滲透測試：建議直接針對現場生產環境進行滲透測試。 然而，只要滲透測試報告確認測試時生產環境中仍使用相同的程式碼庫，網頁應用程式測試仍可在 test/UAT (使用者驗收測試) 環境中進行。

分群驗證：若使用分段技術將範圍內環境與其他環境隔離，滲透測試報告必須驗證這些分群技術的有效性。 這確保了分段過程中不會引入任何漏洞。

滲透測試要求

滲透測試報告將被審查，以確保不存在符合以下控制措施中所述 自動失敗標準 的漏洞。

免費滲透測試要求與規則

對於目前尚未執行滲透測試的獨立軟體供應商，Microsoft 提供免費的滲透測試服務，作為 Microsoft 365 認證流程的一部分。 此服務涵蓋最多 12天的人工測試，超出此期間的額外費用由獨立服務供應商負責。

關鍵要求：

預測試要求：ISV 必須提交證據並取得 50% 範圍內控制的批准，方可排程滲透測試。

測試報告：此報告與您的 Microsoft 365 認證一同，可用來向客戶展示您的環境是安全的。

漏洞修復：ISV 負責在測試中解決任何在認證前發現的漏洞。 然而，不需要一份乾淨的報告，只需確認漏洞已被妥善處理的證據即可。

其他考量：

一旦安排了滲透測試，ISV 將負責支付與重新排程或取消相關的費用。

圖形 API 權限驗證

這確保應用程式、外掛或代理程式不會要求過多或過度寬容的權限。 認證分析師會手動審查應用程式所請求的權限，並與出版者認證提交進行交叉比對。

目標是確認所請求的權限是否符合最小權限原則。 如果分析師發現應用程式請求的權限超出必要範圍，他們會與 ISV 聯繫，驗證這些權限的商業合理性。 若申請許可與出版商認證提交之間發現任何不一致，必須在本審查期間加以處理與解決。

負責任的 AI

針對負責任的 AI 控管所提交的資訊，將與 ISV 提供的應用程式清單檔案一同審查。 這讓分析師能檢查 Microsoft Copilot 與應用程式的整合，進而清楚了解兩者如何互動，以及客戶會採取哪些行動。 我們深知，AI 必須負責任且讓客戶充分知情地使用。 只要所分享的資訊符合預期應用程式功能及Microsoft負責任 AI Standard或 NIST 可信賴 & 負責任人工智慧資源中心，這些控制措施將被視為核准 (並需通過常規的問答檢查) 。

計畫是與 Microsoft 進一步合作，在相關公開頁面提供部分檢查細節，讓客戶能在使用 Copilot 及相關應用程式時，做出充分知情的決策。

作戰安全

此領域衡量應用程式支援基礎設施與部署流程與安全最佳實務的一致性。

控制項

資料處理、安全性與隱私

為確保資料安全，應用程式使用者、中介服務與 ISV 系統之間傳輸的資料必須使用 TLS (傳輸層安全) 連線加密。 至少需要TLS 1.2，強烈建議TLS 1.3或以上。 欲了解更多細節，請參閱附錄A。

對於擷取或儲存 Microsoft 365 資料的應用程式，必須實作資料儲存加密方案。 此規定必須符合 附錄B所列規範。

控制項

可選的外部合規架構審查

如果您的組織已經符合外部安全框架，如 ISO 27001、PCI-DSS、FedRAMP 或 SOC 2 Type 2，您可以選擇利用這些認證來滿足部分 Microsoft 365 認證的控制要求。 分析師將致力於使現有的外部安全架構與 Microsoft 365 認證要求對齊。

然而，若您的支持文件未顯示 Microsoft 365 認證控制措施在外部框架的審核或評估中被明確評估，您必須提供額外證據以驗證這些控制措施的存在。

文件要求：

文件必須明確證明 Microsoft 365 認證的範圍內環境包含在永續安全框架的範圍內。 這些框架的驗證將透過接受由可信且具認證的第三方審核員核發的有效認證證明來完成。

這些第三方審核員必須是國際認可機構的成員，例如：

• ISO 27001 認證與合規標準

• 品質安全評估員 (QSA) PCI-DSS

欲了解更多細節，請參閱與您認證相關的外部框架的具體指引與標準。

下表列出認證分析師在驗證過程中接受的必要框架與文件。

使用外部合規架構的要求

使用外部合規框架的要求

範圍內環境及所有支援的業務流程必須納入任何支援的外部安全合規框架之內。 這些必須在所提供的文件中清楚記錄。

外部安全合規框架必須是最新的，也就是說，若有持續的重新評估並有支持證據，則應在過去12個月 (或15個月內進行)

外部安全合規評估必須由獨立且具認證的公司執行。

外部框架驗證標準

SOC 2 第二類評量

• SOC 2 報告必須是第二類報告
• SOC 2 稽核必須包含被評估的 M365 環境
• SOC 2 審計必須在過去 12 個月內完成
• 控制措施必須公平呈現，並依照第二類報告的要求適當設計
• SOC 2 審計必須由合格的外部第三方執行
• 測試程序必須確認安全控管已到位，並由稽核員妥善驗證。

ISO 27001 評估

• ISO 27001 審核必須包含本 M365 評估中指定的環境
• ISO 27001 證書必須是最新且適用於該實體的
• ISO 27001 評估必須由經認可的外部第三方進行 (內部 ISO 27001 審核不被接受)
• ISO 27001 評估必須在過去 12 個月內完成

PCI-DSS 評估

• AOC 文件必須明確定義被評估的 M365 環境
• AOC 必須符合日期
• AOC必須經QSA及實體簽署

深入了解

• 什麼是出版商識別？
• 如何取得 Microsoft 365 認證