この記事では、必要なセキュリティ制御の一覧や ISV や開発者向けのガイダンスなど、Microsoft 365 認定資格に関する詳細情報を提供します。
Microsoft 365 認定は、Microsoft 365 プラットフォームと統合されるアプリ、アドイン、エージェント、サポート バックエンド環境 (総称してアプリといいます) の独立したセキュリティおよびプライバシー監査です。 合格したアプリは、Microsoft 365 エコシステム全体で Microsoft 365 認定として指定され、コンプライアンスに重点を置いた検索フィルターとブランド化を介して Microsoft 365 Marketplace で簡単に見つけることができます。 ISV は、このドキュメント セット内の専用ページでアプリのコンプライアンス属性を共有する機会があります。
Microsoft 365 認定は、次の種類のアプリケーションで利用できます。
- Microsoft 365 アドイン (Word、Excel、Outlook、PowerPoint、OneNote、Project)
- Teams アプリ
- SharePoint ソリューション
- Web アプリ (SaaS)
- Copilot 拡張機能
重要
Microsoft 365 認定は、Microsoft 365 認定フレームワークに対するアプリのセキュリティとコンプライアンスの厳密なレビューであり、完了するにはかなりの時間とリソースを費やす必要があります。 開始する前に、 コンプライアンス管理フレームワークを確認し て、アプリが適格であることを確認してください。 ご質問がある場合は、 appcert@microsoft.comメールでお問い合わせください。
Terms
Microsoft 365 認定プログラムに参加することにより、これらの補足条項に同意し、Microsoft Corporation (以下「Microsoft」といいます) との Microsoft 365 認定プログラムへの参加に適用される付随文書に準拠することになります。 お客様は、ご自身、会社、およびその他の団体 (該当する場合) を代表して、これらの Microsoft 365 認定補足条項に同意する権限があることを表明し保証するものとします。 Microsoft は、本追加条項を随時変更、修正、または終了することができます。 変更または修正後も Microsoft 365 認定プログラムに引き続き参加するということは、新しい補足条項に同意したことを意味します。 新しい補足条項に同意しない場合、または Microsoft がこれらの補足条項を終了する場合は、Microsoft 365 認定プログラムへの参加を中止する必要があります。
前提条件
Microsoft 365 認定資格を取得するには、アプリで次の作業を完了する必要があります。
発行元の検証アプリに検証済みの発行元がある場合、アプリを発行する organization は Microsoft によって本物として検証されています。 アプリの確認には、確認済みの Microsoft Cloud パートナー Program (CPP) アカウントを使用し、確認済みの PartnerID をアプリの登録に関連付けることが含まれます。 発行元の確認を受ける
発行元の構成証明 は、アプリ開発者 (ISV) が機密データの処理などのセキュリティ プラクティスに関する一連の質問に回答するセルフサービス プロセスです。 完了すると、アプリは、提供された応答を含む顧客と共有できるドキュメント ページを受け取ります。
管理基準を確認します。 認定を授与されるためには、必ずしもすべてのコントロールに準拠する必要は限りません。 ただし、この概要ドキュメントで説明した 3 つのセキュリティ ドメインのそれぞれについて、しきい値 (非公開) が設定されており、合格する必要があります。 "ハード フェイル" というラベルの付いた重要なコントロールを満たしていない場合、評価は不合格になります。
コスト構造
ISV は監査法人と協力して認定の費用を支払います。 詳細と監査法人Claranetでのアカウントのセットアップについては、 ここをクリックしてください。
| 監査の種類 | 含まれるもの | 資格 |
|---|---|---|
| 標準 | 適用可能なすべてのコントロールに対する完全な評価 | サテライト監査の対象とならない新しい評価と再認定に必要です。 再認証がサテライト監査に設定されたリスク基準に合格しない場合に必要 |
| サテライト監査 | 基準が満たされている場合は、2 年目と 3 年目のコントロール セットを減らしました | 1 年目に標準認定資格を完了した後に資格があります。 2 年目と 3 年目は、大きな変更がなく、リスク評価に合格した場合 |
| 延長戦のボルトオン | リクエストに応じて構築可能、レポート時間を含む | 提出物が監査人とより多くの時間を必要とする場合にのみ追加されます |
| テスト日割り | エンゲージメントごとにスコープが設定され、合意された評価の完全なスコープをカバーするサーティフィケーション要件に沿った侵入テスト | 過去 12 か月間に、アプリに評判の良いサード パーティの侵入テストがない場合に必要 |
| Clone | 複製された提出の確認、追加の証拠が必要なコントロールのレビュー | 最近認定を完了したアプリと同じバックエンド環境を共有するアプリ |
提出時間枠
サーティフィケーションを取得するための提出プロセスには、次の 2 つの段階があります。
ステージ 1: 最初のドキュメントの提出 (14 日間の範囲)
この段階では、ISV はアプリのサポート環境の概要を提供するドキュメントを提出する必要があります。 これには次のものが含まれますが、これらに限定されません:
- アーキテクチャ図/データ フロー
- システム コンポーネントの一覧
- ソフトウェア資産インベントリ
アナリストは、このドキュメントを確認して、評価の範囲を定義します。 ISV には、必要なドキュメントを完了してアップロードするのに 14 日が与えられます。 この期限に間に合わないと、プロセスが遅れたり、提出が失敗したりする可能性があります。
ステージ 2: 完全な証拠レビュー (60 日間の時間枠)
スコープが定義されると、ISV は証拠収集フェーズに進みます。 この段階の内容:
ISV は、スコープから定義されたすべての適用可能なコントロールに対する証拠をアップロードする必要があります。
この証拠は、レビュー、改訂 (必要な場合)、および最終的な Q/A プロセスを受けます。
この間、侵入テストも実施される場合があります。
ISV は、最初の証拠の提出から開始して、この段階を完了するのに 60 日間かかります。これには以下が含まれます。
- すべてのコントロールの証拠のアップロード
- アナリストのレビューとフィードバック
- 提出された証拠に必要な改訂
- Q/A プロセスの完了
期限を満たしていない
ISV が 60 日以内にプロセスを完了できない場合、評価は失敗します。 ただし、アナリストの裁量により、次のような有効な状況下では、さらに最大 60 日間の延長が許可される場合があります。
- 季節の休日
- 侵入テストの遅延
- 内部の変更
- 管理要件を満たすために必要な変更を実装するために必要な時間
両方の 60 日間の期間が使い果たされると、それ以上の延長は許可されません。
証明範囲
スコープ内環境には、アプリ、アドイン、またはエージェント コードの配信に必要なすべてのシステムとインフラストラクチャ、およびアプリ/アドイン/エージェントが通信する可能性のあるサポート バックエンド システムが含まれます。 適切なセグメンテーションが実装されていて、接続された環境がスコープ内環境のセキュリティを損なうことができない限り、スコープ内環境に接続されている追加の環境もスコープに含める必要があります。
注: プライマリ環境に障害が発生した場合にサービスの継続性を維持するために重要な場合があるため、スコープ内環境内には個別のディザスター リカバリー環境も含める必要があります。
さらに、リモート バックアップ環境は Microsoft の機密データを格納する可能性があるため、スコープに組み込む必要があります。 そのため、これらの環境に対して適切なセキュリティ制御を実装する必要があります。
スコープ内のシステム コンポーネントという用語には、定義されたスコープ内環境内でアクティブに使用されるすべてのデバイスとシステムが含まれます。 これらのコンポーネントには次のものが含まれます (ただし、これらに限定されません)。
- Web アプリケーション
- サーバー (物理または仮想、オンプレミスまたはクラウド内)
- スイッチ
- ロード バランサー
- 仮想インフラストラクチャ
- クラウド プロバイダーの Web 管理ポータル
- クラウド リソース (Virtual Machines、App Services、ストレージ アカウント、データベースなど)
重要
一般に公開されているシステム コンポーネントは、外部の脅威アクターによる攻撃に対して特に脆弱であるため、より高いリスクにさらされます。 通常、これらのシステムは、非武装地帯 (DMZ) などのネットワーク セキュリティ制御 (NSC) の実装を通じて、内部システム コンポーネントから分離する必要があります。 DMZ の目的は、緩衝ゾーンとして機能し、外部システムに拡張される信頼を制限し、セキュリティを強化して内部システムとデータを保護することです。 場合によっては DMZ が依然として理想的ですが、最新のクラウド アーキテクチャは、多くの場合、特定の展開シナリオに合わせて調整された代替のセキュリティ対策に依存しています。
サービスとしてのインフラストラクチャ (IaaS)、サービスとしてのプラットフォーム (PaaS)、サービスとしてのソフトウェア (SaaS)
審査対象のスコープ内環境をサポートするために IaaS および/または PaaS が使用されている場合、クラウド プラットフォーム プロバイダーは、認証プロセス全体を通じて評価されるセキュリティ制御の一部に責任を負います。 アナリストは、PCI-DSS、Attestation of Compliance (AOC)、ISO 27001、SOC 2 Type II レポートなどの外部コンプライアンス レポートを通じて、クラウド プラットフォーム プロバイダーによるセキュリティのベスト プラクティスに関する独立した外部検証を受ける必要があります。
展開の種類に適用できる可能性が高いセキュリティ制御と、環境が Microsoft 365 データを処理するか転送するかの詳細については、 付録 C を参照してください。展開の種類は次のとおりです。
- ISV ホスト: 独立系ソフトウェア ベンダーによってホストされるアプリケーション。
- IaaS Hosted: サードパーティのクラウド プラットフォームによって提供されるインフラストラクチャ。
- PaaS/サーバーレス・ホステッド: プラットフォーム・ベースまたはサーバーレス・アーキテクチャを平均するアプリケーション。
- ハイブリッド ホステッド: オンプレミスとクラウドでホストされるコンポーネントの混在。
- 共有ホスト型: 複数のテナントによって使用される共有クラウド環境。
IaaS または PaaS を使用している場合、展開が関連するアーキテクチャに予想されるセキュリティ制御と一致していることを証拠で検証する必要があります。
サンプリング
徹底的な評価を行うには、スコープ内のシステム コンポーネントのサンプリングでは、オペレーティング システム、プライマリ デバイスの機能、デバイスの種類 (サーバー、ルーター、ネットワーク セキュリティ制御など)、地理的位置などの要素を考慮する必要があります。 サンプルは、これらの考慮事項に基づいて、サーティフィケーション プロセスの開始時に選択されます。 次の表は、スコープ内のコンポーネントの母集団に基づいたサンプリング サイズを示しています。
| 個体数 | サンプル |
|---|---|
| <=5 | 1 |
| >5 & < 10= | 2 |
| >10 & <=30 | 3 |
| >30 | 4 |
これにより、さまざまな構成と展開モデルにわたる環境のコンプライアンスの代表的な評価が保証されます。
注:
評価中にデバイス間で不一致が特定された場合は、環境の適切なプレゼンテーションを確保するためにサンプル サイズを調整できます。
サーティフィケーション プロセスの概要
Microsoft 365 認定プロセスを開始するには:
発行元の構成証明: パートナー センターに移動し、発行元構成証明フォームに入力します。 注: 提出物が 3 か月以上経過している場合は、レビューと検証のために再提出する必要があります。
サーティフィケーションの開始 パートナー センターに移動したら、[サーティフィケーションの開始] オプションを選択して最初のドキュメントの送信を開始します。 この手順は、サーティフィケーション アナリストがアプリのアーキテクチャと Microsoft データの管理方法に基づいて評価の範囲を特定するのに役立ちます。 この時点で、 Claranet Limited のアカウントを設定する必要があります。
認証は、次の 2 つの主要な段階で実施されます。
最初のドキュメントの提出 この段階では、アナリストがアプリの設計、データ フロー、スコープ内環境を理解するのに役立つ重要な詳細を指定します。 アナリストは、適用可能なセキュリティ制御を決定し、証拠を必要とするシステムコンポーネントの概要を示します。 このレビューを容易にするために、正確なドキュメントを提供する必要があります。これはプロセス全体の約 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 認定セキュリティ管理を確認するときに考慮される外部セキュリティ フレームワークのサポート ドキュメント。 現時点では、次の 4 つがサポートされています。 |
| ✓ PCI DSS のコンプライアンス証明 (AOC)。 | |
| ✓ SOC 2 Type I/Type II レポート。 | |
| ✓ ISMS / IEC - 1S0/IEC 27001 適用性声明 (SoA) および認証。 | |
| ✓ FedRAMP FedRAMP 承認パッケージと FedRAMP 準備評価レポート。 | |
| Web の依存関係 | 現在実行中のバージョンでアプリで使用されるすべての依存関係を一覧表示したドキュメント。 |
| ソフトウェア インベントリ | スコープ内環境内で使用されているすべてのソフトウェアとバージョンを含む、最新のソフトウェア インベントリ。 |
| ハードウェア インベントリ | サポート インフラストラクチャで使用される最新のハードウェア インベントリ。 これは、評価フェーズを実行する際のサンプリングに役立ちます。 環境に PaaS が含まれている場合は、使用されるクラウド サービス/リソースの詳細を指定します。 |
証拠の収集と評価活動
サーティフィケーション アナリストは、定義されたサンプル セット内のすべてのシステム コンポーネントにわたる証拠を確認する必要があります。 評価プロセスを裏付けるために必要な証拠の種類には、次のいずれかまたはすべてが含まれます。
証拠収集
- 初期ドキュメント提出ガイド内で強調表示されている初期ドキュメント
- ポリシー ドキュメント
- ドキュメントを処理する
- システム構成の設定
- チケットの変更
- 変更管理レコード
- システム レポート
- 議事録
- 契約/合意
評価プロセスを完了するために必要な証拠を収集するために、さまざまな方法が使用されます。 この証拠収集は、次の形式になる場合があります。
- ドキュメント
- スクリーンショット
- インタビュー
- 画面共有
使用される証拠収集手法は、評価プロセス中に決定されます。 提出で要求する証拠の具体的な例については、 証拠ガイドの例を参照してください。
証拠の共有
認定プロセス中に、ISV はコンプライアンス証拠を潜在的な顧客と直接共有することを選択できます。 ファイル アップロード ダイアログにあるチェック ボックスは既定でオンになっていますが、Microsoft 365 管理者は Teams 管理センターと Microsoft 365 管理センターでアプリの認定証拠にアクセスできます。 (Microsoft 365 管理者は、organization内の Microsoft 365 サービスとリソースの構成、管理、セキュリティ保護を担当します。)この透明性は、意思決定を加速するために新しいアプリケーションを評価する組織のデューデリジェンスを合理化することを目的としています。 ISV がこの証拠を公開したくない場合は、提出時にチェック ボックスをオフにするだけで、コンプライアンス文書をいつ、どのように開示するかを完全に制御できます。
評価アクティビティ
認定アナリストは、提出された証拠をレビューして、Microsoft 365 認定に必要なすべてのコントロールが満たされていることを確認します。 プロセスを迅速化するには、 最初のドキュメント提出 で指定されたすべてのドキュメントが完了し、事前に提供されていることを確認してください。
レビュー中に、アナリストは最初の提出と発行元の構成証明からの証拠を評価します。 彼らは、調査の範囲、サンプリング側、および追加の証拠が必要かどうかを決定します。 アナリストは、収集されたすべての情報を使用して、Microsoft 365 認定仕様への準拠を評価し、アプリが定義されたコントロールを満たしているかどうかを判断します。
アプリの認定条件
アプリとそのサポート インフラストラクチャ、およびサポート ドキュメントは、次の 3 つのセキュリティ ドメインにわたって評価されます。
これらの各セキュリティ ドメインには、評価プロセスの一部として評価される 1 つ以上の要件を含む特定のキー制御が含まれています。 Microsoft 365 認定があらゆる規模の開発者に確実に及ぶことを保証するために、各セキュリティ ドメインはスコアリング システムを使用して評価され、各ドメインからの全体的なスコアが決定されます。 Microsoft 365 認定機関の各コントロールのスコアは、そのコントロールが実装されないリスクに基づいて、1 (低) から 3 (高) の間で割り当てられます。 各セキュリティ ドメインには、合格と見なされるための最小パーセンテージ マークがあります。 次のような特定の要因によって自動エラーが発生します。
最小限の特権 (PoLP) の原則に従わない API アクセス許可の使用
必要な場合の侵入テスト レポートの欠如。
マルウェア対策防御が存在しない。
管理アクセスに多要素認証 (MFA) を実装していません。
パッチ適用プロセスが見つからないか不十分です。
GDPR プライバシー通知 に準拠していない。
アプリケーション セキュリティ
アプリケーション セキュリティ ドメインは、次の領域を評価します。
- 侵入テスト
- Graph API アクセス許可の検証
- 責任ある AI
侵入テスト
侵入テストは、アプリまたはアドインとそのサポート環境に関連するリスクを特定して軽減するために重要です。 これにより、アプリが顧客に適切なセキュリティ保証を提供できるようになります。
Microsoft がホストまたは管理していない外部サービスに接続するアプリに対して、侵入テストが 必須 です。 アプリが GraphAPI などの Microsoft サービスのみを使用するスタンドアロン ソリューションとして展開されている場合は、侵入テストは必要ない場合があります。 ただし、Azure でホストされているアプリは、スコープ内環境のセキュリティを確保するために侵入テストを受ける必要があります。
侵入テストの範囲
インフラストラクチャ テスト: 内部インフラストラクチャと外部インフラストラクチャの両方について、アプリ、アドイン、またはエージェントをサポートする ライブ運用環境 で侵入テストを実施する必要があります。 保持されるデータには以下が含まれます。
アプリ、アドイン、またはエージェントのコードがホストされる環境 (通常はマニフェスト ファイルで参照されます)。
アプリ/アドイン/エージェントの操作と対話する、または操作をサポートする追加の環境 (アプリ/アドイン/エージェントが Microsoft 365 以外の他の Web アプリケーションと通信する場合など)。
侵入テストのスコープを定義するときは、スコープ内環境のセキュリティに影響を与える可能性のある すべての接続済みシステムまたは環境 を含めることが重要です。
推奨事項
Web アプリケーション侵入テスト: Web アプリの侵入テストは、ライブ運用環境に対して直接実行することをお勧めします。 ただし、テスト時に同じコードベースが運用環境で使用されていることが侵入テスト レポートで確認されている場合に、Web アプリのテストはテスト/UAT (ユーザー受け入れテスト) 環境で実施できます。
セグメンテーションの検証: セグメンテーション手法を使用してスコープ内の環境を他の環境から分離する場合、侵入テスト レポートはこれらのセグメンテーション手法の有効性を検証する必要があります。 これにより、セグメンテーション プロセスを通じて脆弱性が導入されなくなります。
侵入テストの要件
侵入テスト レポートは、以下のコントロールで概説する次の 自動障害基準 を満たす脆弱性がないことを確認するためにレビューされます。
| 条件の種類 | 侵入テストのコントロール |
|---|---|
| 一般的な基準 | Web アプリケーション (認証済みおよび未認証) と、内部 (該当する場合) と外部インフラストラクチャの侵入テストは、毎年 (12 か月ごと) 実施し、評判の良い独立系企業によって実施 されなければなりません 。 |
| 特定された重大かつリスクの高い脆弱性の修復は、ペネトレーション テストの終了から 1 か月以内、または ISV の文書化されたパッチ適用プロセスに応じてそれより早く完了 する必要があります 。 | |
| 完全な外部フットプリント (IP アドレス、URL、API エンドポイントなど)は、侵入テストの範囲に含める 必要があり 、侵入テスト レポート内に明確に文書化する必要があります。 | |
| 環境が PaaS と一致しない限り、完全な内部ネットワークは侵入テストの範囲に含まれ、侵入テスト レポート内に明確に文書化されなければなりません。 | |
| Web アプリケーション侵入テストには、すべての脆弱性クラスを含める 必要があります。 たとえば、最新の OWASP Top 10 や SANS Top 25 CWE などです。 これは、ペネトレーション テスト レポート内で詳しく説明することをお勧めします。そうでない場合、実証が困難になります。 | |
| 重大かつリスクの高い脆弱性、または自動障害と見なされる脆弱性は、侵入テスト会社によって再テストされ、侵入テスト レポート内で修正済みとして明確に強調表示され なければなりません 。 | |
| 自動失敗の基準: | サポートされていないオペレーティング システムまたはサポートされていない JavaScript ライブラリの存在。 |
| 既定、列挙可能、または推測可能な管理アカウントの存在。 | |
| SQL インジェクション リスクの存在。 | |
| クロスサイト スクリプティングの存在。 | |
| ディレクトリ トラバーサル (ファイル パス) の脆弱性が存在します。 | |
| ヘッダー応答の分割、要求の密輸、Desync 攻撃など、HTTP の脆弱性の存在。 | |
| ソース コード開示 ( LFI を含む) の有無。 | |
| CVSS パッチ管理ガイドラインで定義されているクリティカル スコアまたはハイ スコア。 | |
| 大量の EUII または OUI を侵害するために容易に悪用される可能性のある重大な技術的脆弱性。 |
重要
レポートは、上記の侵入テスト要件セクションで詳しく説明されているすべてを実証できるという十分な保証を提供できなければなりません。
Graph API アクセス許可の検証
これにより、アプリ、アドイン、またはエージェントが過度または過度に寛容なアクセス許可を要求しないようにします。 認定アナリストは、アプリによって要求されたアクセス許可を手動で確認し、発行元構成証明の提出に対してクロスチェックします。
目標は、要求されたアクセス許可が最小限の特権の原則に従っていることを確認することです。 アナリストは、アプリが必要以上のアクセス許可を要求していることが判明した場合、ISV と連携して、これらのアクセス許可のビジネス上の正当性を検証します。 要求されたアクセス許可と発行元による構成証明の提出の間で特定された不一致は、このレビュー中に対処して解決する必要があります。
責任ある AI
責任ある AI コントロールに応じて提出された情報は、ISV によって提供されるアプリ マニフェスト ファイルと共にレビューされます。 これにより、アナリストは認定に合格したアプリと Microsoft Copilot の統合をチェックし、2 つの相互にどのようにやり取りし、顧客に代わってどのようなアクションが実行されるかを明確に理解できます。 私たちは、AI が責任を持って、また顧客に十分な情報を得られる場所の両方で活用することが重要であることを認識しています。 共有される情報が、予想されるアプリの機能および Microsoft の責任ある AI Standard または NIST 信頼できる & 責任ある人工知能リソース センターと一致している場合、これらのコントロールは承認されたものとみなされます (通常の Q/A チェックの対象になります)。
これは、Microsoft とさらに連携して、関連する公開ページにこのチェックの詳細を提供し、お客様が Copilot および関連アプリに関するデータの使用について十分な情報に基づいた決定を行えるようにすることです。
オペレーショナル セキュリティ
この領域は、アプリでサポートするインフラストラクチャと展開プロセスの、セキュリティのベスト プラクティスとの整合性を測定します。
コントロール
| コントロール ファミリ | Controls |
|---|---|
| 意識向上トレーニング | 新規ユーザー向けの初期トレーニングの一環として、または情報システムの変更に必要な場合に、organization が情報システム ユーザー (マネージャー、上級管理職、請負業者を含む) に確立されたセキュリティ意識トレーニングを提供している証拠を提供します。 |
| organization が定義した意識向上トレーニングの頻度の証拠を提供します。 | |
| 個々の情報システムのセキュリティ意識向上活動の文書化と監視の証拠を提供しながら、organization が定義した頻度で個々のトレーニング記録を保持します。 | |
| マルウェア対策 - ウイルス対策 | サンプリングされたすべてのシステム コンポーネントでマルウェア対策ソリューションがアクティブであり有効であり、次の条件を満たすように構成されているという証拠を提供します。 |
| ウイルス対策の場合、オンアクセス スキャンが有効になり、署名が 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) の Top 25 Common Weakness Enumeration (CWE) などです。 |
| コード リポジトリがセキュリティで保護されているという証拠を提供して、すべてのコード変更が Main ブランチにマージされる前に 2 番目のレビュー担当者によるレビューと承認プロセスが行われ、適切なアクセス制御が適用され、すべてのアクセスが多要素認証 (MFA) によって適用されます | |
| 実稼働環境に行われたすべてのリリースが、展開前にレビューされ、承認されているという証拠を提供します。 | |
| アカウント管理 | サンプリングされたシステム コンポーネント全体で、既定の資格情報が無効化、削除、または変更されていることを示す証拠を提供します。 |
| サービス アカウントをセキュリティで保護 (強化) するプロセスが実施され、このプロセスに従っているという証拠を提供します。 | |
| 次の証拠を提出してください: 一意のユーザー アカウントがすべてのユーザーに発行されている、環境内でユーザーの最小特権原則が守られている、強力なパスワード/パスフレーズ ポリシーまたはその他の適切な軽減策が設定されている、プロセスが設定されていて、少なくとも 3 か月ごとに、3 か月以内に使用されていないアカウントを無効化または削除します。 | |
| すべてのリモート アクセス接続と、すべてのコンソール以外の管理インターフェイス (コード リポジトリやクラウド管理インターフェイスへのアクセスを含む) に対して MFA が構成されていることを確認します。 | |
| セキュリティ イベントのログ記録、確認、およびアラート | 90 日間分のセキュリティ イベント ログが保持され、最低 30 日分のセキュリティ イベント ログ データがすぐに利用できるという証拠を提供します。 |
| ログが定期的に確認され、レビュー プロセス中に特定された潜在的なセキュリティ イベント/異常が調査および対処されているという証拠を提供します | |
| 該当する場合は、次のセキュリティ イベントの調査のためにアラートがトリガーされるようにアラート ルールが構成されているという証拠を提供します: 特権アカウントの作成/変更、特権/高リスクのアクティビティまたは操作、マルウェア イベント、イベント ログの改ざん、IDPS /WAF イベント。 (設定されている場合) | |
| 情報リスク管理 | 承認された正式な情報セキュリティ リスク管理ポリシー/プロセスが文書化され、確立されているという証拠を提供します。 |
| 正式な全社的な情報セキュリティ リスク評価が少なくとも 1 年に 1 回実施されているという証拠を提供します。 | |
| またはターゲットを絞ったリスク分析の場合: 従来の管理や業界のベスト プラクティスが実施されていない場合、設計/技術的な制限により環境に脆弱性が導入されるリスクが生じたり、ユーザーとデータを危険にさらしたりする場合、すべてのインスタンスに対して、ターゲットを絞ったリスク分析が文書化され、少なくとも 12 か月ごとに実行されます。 侵害の疑いまたは確認時。 | |
| 情報セキュリティ・リスク評価に、影響を受けるシステム・コンポーネントまたはリソース、脅威と脆弱性または同等物、影響および度度マトリックスまたは同等物、リスク・レジスタ/リスク処理計画の作成が含まれることを検証します。 | |
| ベンダーやビジネスパートナーに関連するリスクを評価および管理するリスク管理プロセスが導入されているという証拠を提供し、内部統制システムに影響を与える可能性のある変更とリスクを特定して評価できます。 | |
| セキュリティ インシデント対応 | 承認済みのセキュリティ インシデント対応計画/手順 (IRP) を提供します。 |
| organization がインシデントにどのように対応するかを概説する証拠を提供し、その維持方法を示し、連絡先情報、インシデント中の内部コミュニケーション計画、主要な利害関係者、支払いブランドおよびアクワイアラー、規制機関 (GDPR の場合は 72 時間など)、監督当局、 取締役、顧客、インシデントの種類に応じて、インシデントの分類、封じ込め、軽減、回復、通常の事業運営への復帰などの活動の手順 | |
| インシデント対応チームのすべてのメンバーが、インシデントに対応できる年次トレーニングを受けているという証拠を提供します。 | |
| インシデント対応戦略とサポート ドキュメントが、卓上演習から学んだ教訓、インシデントへの対応から学んだ教訓、組織の変更に基づいてレビューおよび更新されているという証拠を提供します。 | |
| 事業継続計画と障害復旧計画 | ドキュメントが存在し、維持されているという証拠を提供し、事業継続計画の概要を示します。 |
| 関連する緊急時の要件と目標を伴うビジネス機能、システムとデータのバックアップ手順、構成とスケジュール/保持、復旧の優先順位と時間枠の目標、緊急時対応計画、緊急時対応計画、重要な情報システム、ビジネス機能、およびサービスを運用に戻すために従うべきアクション、手順、手順を詳述した緊急時対応計画などの証拠を提供します予期しない予定外の中断。最終的な完全なシステム復元と元の状態への復帰をカバーする確立されたプロセス。 | |
| ドキュメントが存在し、維持されているという証拠を提供し、災害復旧計画の概要を示し、少なくとも、人員とその役割、責任、エスカレーションプロセス、重要なビジネス機能とサービスをサポートするために使用される情報システムのインベントリ、システムとデータのバックアップ手順と構成、重要な情報システムとデータを運用に復元するために従うべきアクションと手順を詳述した復旧計画が含まれます。 | |
| 事業継続計画と災害復旧計画が少なくとも 12 か月ごとに見直され、不利な状況下でも有効かつ有効であることを確認するための証拠を提供します。 | |
| 事業継続計画がプランの年次レビューに基づいて更新されていること、すべての関係者が緊急時対応計画で割り当てられた役割と責任に関するトレーニングを受けていること、計画が事業継続性または災害復旧の演習を通じてテストされていること、演習から学んだ教訓や組織の変更を含むテスト結果が文書化されていることの証拠を提供します。 |
データ処理のセキュリティとプライバシー
データ セキュリティを確保するには、アプリケーション ユーザー、仲介サービス、および ISV システム間で転送されるすべてのデータを TLS (トランスポート層セキュリティ) 接続を使用して暗号化する必要があります。 少なくとも TLS 1.2 が必要です。TLS 1.3 以降を強く推奨します。 詳細については、付録 A を参照してください。
Microsoft 365 データを取得または保存するアプリケーションの場合、データ ストレージ暗号化スキームを実装する必要があります。 これは 、付録 B に記載されている仕様に一致する必要があります。
コントロール
| コントロール ファミリ | Controls |
|---|---|
| 転送中のデータ | TLS 構成が TLS プロファイル構成要件 内で TLS1.2 以上であり、信頼できるキーと証明書のインベントリが保持および維持されていることを検証する証拠を提供します。 |
| 圧縮率情報漏洩容易 (CRIME) を防ぐために、Web 要求を処理するすべての公開サービスで TLS 圧縮が無効になっていることを示す証拠を提供し、TLS HSTS が有効になり、すべてのサイトで 180 日間に構成されています。 | |
| 保存データ | Advanced Encryption Standard (AES)、RSA、Twofish などの暗号化アルゴリズムを 256 ビット以上の暗号化キー サイズで使用して、保存データが暗号化プロファイルの要件に従って暗号化されているという証拠を提供します。 |
| データの保持、バックアップ、廃棄 | 承認されたデータ保持期間が正式に確立され、文書化されていることを証明するものを提供します。 |
| 前のコントロールで説明したように、定義された保持期間のみデータが保持されるという証拠を提供します。 | |
| 保持期間後にデータを安全に削除するためのプロセスが実施されているという証拠を提供します。 | |
| 自動バックアップ システムが導入され、スケジュールされた時間にバックアップを実行するように構成されているという証拠を提供します。 | |
| バックアップ情報がバックアップ スケジュール手順に従ってテストされ、定期的に復元され、データの信頼性と整合性を確認する証拠を提供します。 | |
| バックアップ/システム スナップショットを不正アクセスから確実に保護し、バックアップ データの機密性、整合性、および可用性を確保するために、適切なアクセス制御と保護メカニズム (不変のバックアップ) が実装されているという証拠を提供します。 | |
| データ アクセス管理 | データや暗号化キーにアクセスできるユーザーのリストが保持されているという証拠を提供します。 各ユーザーのビジネス上の正当性や確認を含めて、このユーザーのリストは、その職務に必要なアクセス権限に基づいて正式に承認されており、ユーザーは承認に記載されている権限で構成されます。 |
| データが共有されるすべての第三者のリストが維持され、データを使用するすべての第三者とデータ共有契約が締結されているという証拠を提供します。 | |
| プライバシー | あなたの organization には、プライバシー情報管理の取り組みがシステムの機密性と整合性のためにどのように維持されるかについて、ポリシーまたはその他の形式のドキュメント/コンピューター化されたシステムを通じてリーダーシップを果たすプライバシー情報管理 (PIM) システムが確立、実装、維持されていますか? PII プロセッサやコントローラーを含む、システムを維持する各人の役割、責任、および権限を決定します。 |
| PII の最小化が行われていること、PII の匿名化と削除が処理期間の終了時に行われていること、機密保持を含む PII 送信の管理が実施されていること、ある国/地域から別の国/地域への PII の転送の記録が明確な同意を得て存在していることを確認するためのプロセスの証拠を提供します。 | |
| GDPR | データ主体が SAR を発生させることができること、ISV が SAR 要求に応答するときにデータ主体のデータのすべての場所を識別できること、バックアップに保持期間があり、それによってクライアントが一定期間にわたってローリング バックアップを削除すると、SAR を介してデータの削除を要求していること (最も古いバックアップの削除/書き換えのライフサイクル) を削除できるという証拠を提供します。 |
| プライバシーに関する通知を提供します。これには、組織の詳細 (名前、住所、およびその他の個人を特定できる情報)、処理される個人データの種類、個人データの保持期間、個人データ処理の合法性、データ主体の権利など、必要な要素がすべて含まれている必要があります。対象: データ主体の権利、情報を得る権利、データ主体によるアクセス権、消去する権利、処理を制限する権利、データのポータビリティに対する権利、異議を唱える権利、プロファイリングを含む自動化された意思決定に関連する権利。 | |
| HIPAA | 次の証拠を提出してください: スタッフ、請負業者、ベンダーなどに対する HIPAA および HIPAA 処理のポリシーが organization 内で存在することを確認します。Verify our organization ensure of confidentiality (機密性、整合性、および可用性) ePH. |
| 次のことを確認する: プライバシー ルールで許可されていない情報の合理的に予想される使用または開示に対する保護を提供し、その従業員がセキュリティ ルールを確実に遵守するようにします。 164.308 (a)(7)(ii)(A) および 164.308 (a)(7)(ii)(B) に基づいてデータ バックアップと障害復旧計画を提供します。 |
オプションの外部コンプライアンス フレームワークのレビュー
organizationが ISO 27001、PCI-DSS、FedRAMP、SOC 2 Type 2 などの外部セキュリティ フレームワークに既に準拠している場合、これらの認定を利用して、Microsoft 365 認定コントロールの一部を満たすことを選択できます。 アナリストは、既存の外部セキュリティ フレームワークを Microsoft 365 認定要件に合わせることを目指します。
ただし、Microsoft 365 認定コントロールが外部フレームワークの監査または評価の一環として明示的に評価されたことをサポート文書で証明できない場合は、これらのコントロールが実施されていることを確認するための追加の証拠を提供する必要があります。
ドキュメント要件:
ドキュメントは、Microsoft 365 認定のスコープ内環境が永続的なセキュリティ フレームワークの範囲に含まれていることを明確に示す必要があります。 これらのフレームワークの検証は、評判の良い認定された第三者監査人によって発行された有効な証明書の証拠を受け入れることによって行われます。
これらの第三者監査人は、次のような国際的な認定機関のメンバーである必要があります。
ISO 27001の認証および適合基準
PCI-DSS の品質セキュリティ評価者 (QSA)
詳細については、認定資格に関連する外部フレームワークの特定のガイドラインと標準を参照してください。
次の表は、検証プロセスの一環として認定アナリストが受け入れる必要なフレームワークとドキュメントの概要を示しています。
| Standard | Requirements |
|---|---|
| ISO 27001 | SOA (Statement of Applicability) の公開版と、発行された 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 対応性を評価するために使用されます。 評価アナリストは、評価の範囲をレビューし、評価organizationの妥当性を確認し、ISO 27031 評価の証拠を通じて満たすことができる Microsoft 365 認定のディザスター リカバリーと運用の回復性のコントロールを決定します |
| PCI DSS | 有効な レベル 1 のコンプライアンス証明書 (AOC) ドキュメントを提出し、対象内のアプリケーションとシステム コンポーネントを明確に識別する必要があります。 自己評価の AOC は、セキュリティのベスト プラクティスを満たしている証拠として受け入れ られません 。 AOC は、PCI DSS 評価の一部として評価および確認された Microsoft 365 認定仕様コントロールを決定するために使用されます。 |
| SOC 2 | SOC 2 (タイプ II) レポートは、この Microsoft 365 認定フレームワーク内のいずれかの評価コントロールに準拠している証拠として使用される最新のもの (過去 15 か月以内に発行され、宣言された期間が過去 27 か月以内に開始された) である必要があります。 |
| FedRAMP | Federal Risk and Authorization Management Program (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 とエンティティによってサインオフされる必要があります