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 ソリューション
- Web アプリ (SaaS)
- CoPilot 拡張機能
重要
Microsoft 365 認定資格は、Microsoft 365 認定フレームワークに対するアプリのセキュリティとコンプライアンスの厳格なレビューであり、完了するにはかなりの時間とリソースコミットメントが必要です。 開始する前に、 コンプライアンス制御フレームワーク を確認して、アプリが適格であることを確認してください。 ご質問がある場合は、メール appcert@microsoft.com。
Terms
Microsoft 365 認定プログラムに参加することで、お客様は、これらの補足条項に同意し、Microsoft Corporation ("Microsoft"、"Microsoft"、"us"、または "Microsoft") による Microsoft 365 認定プログラムへの参加に適用される付随するドキュメントに準拠することに同意するものとします。 お客様は、該当する場合、お客様自身、会社、またはその他のエンティティに代わって、Microsoft 365 サーティフィケーション補助条項に同意する権限があることを当社に表明し、保証するものとします。 当社は、これらの補足条項をいつでも変更、修正、または終了することができます。 変更または修正後も Microsoft 365 認定プログラムに継続的に参加することは、新しい補足条項に同意することを意味します。 新しい補足条項に同意しない場合、またはこれらの補足条項を終了する場合は、Microsoft 365 認定プログラムへの参加を停止する必要があります。
前提条件
Microsoft 365 認定資格を付与するには、アプリで次の手順を完了する必要があります。
発行元の検証アプリに検証済みの発行元が存在する場合、アプリを発行するorganizationは、Microsoft によって本物として検証されています。 アプリの検証には、検証済みの Microsoft Cloud Partner Program (CPP) アカウントの使用と、検証済みの PartnerID とアプリの登録の関連付けが含まれます。 発行元の検証を取得する
Publisher Attestation は、アプリ開発者 (ISV) が機密データの処理など、セキュリティ プラクティスに関する一連の質問を完了するセルフサービス プロセスです。 完了すると、アプリは Microsoft AppSource マーケットプレースで特別なバッジと一覧を受け取ります。
コントロール条件を確認する認定を受けるすべてのコントロールに準拠することが常に要件であるとは限りません。 ただし、この概要ドキュメントで説明されている 3 つのセキュリティ ドメインごとにしきい値 (公開されません) が設定されており、渡す必要があります。 "ハード フェイル" というラベルが付いた重要なコントロールを満たしていないと、評価が失敗します。
提出期間
認定を取得するための申請プロセスには、次の 2 つの段階があります。
ステージ 1: 初期ドキュメントの提出 (14 日間の時間枠)
この段階では、ISV は、アプリのサポート環境の概要を示すドキュメントを送信する必要があります。 これには、次のものが含まれますが、これらに限定されません。
- アーキテクチャ図/データ フロー
- システム コンポーネントの一覧
- ソフトウェア資産インベントリ
アナリストはこのドキュメントを確認して、評価の範囲を定義します。 ISV は、必要なドキュメントを完了してアップロードするために 14 日間与えられます。 この期限を満たしないと、プロセスが遅れたり、提出が失敗したりする可能性があります。
ステージ 2: 完全な証拠レビュー (60 日の時間枠)
スコープが定義されると、ISV は証拠収集フェーズに進みます。 このステージでは、次の手順を実行します。
- ISV は、スコープから定義されたすべての適用可能なコントロールに対して証拠をアップロードする必要があります。
- この証拠は、レビュー、リビジョン (必要に応じて)、最終的な QA プロセスを受けます。
- 必要に応じて、この期間中に侵入テストを行うこともできます。
ISV には、最初の証拠の提出から始まり、このステージを完了するまでに 60 日があります。これには、次のものが含まれます。
- すべてのコントロールの証拠のアップロード
- アナリストのレビューとフィードバック
- 提出された証拠に必要な修正
- QA プロセスの完了
期限に間に合わない
ISV が 60 日以内にプロセスを完了できない場合、評価は失敗します。 ただし、アナリストの裁量により、次のような有効な状況では、最大 60 日間の延長が許可される場合があります。
- 季節の休日。
- 侵入テストの遅延。
- 内部の変更。
- 制御要件を満たすために必要な変更を実装するために必要な時間。
60 日間の両方の時間枠が使い果たされると、それ以上の拡張機能を許可することはできません。
認定スコープ
スコープ内環境には、アプリまたはアドインのコードを配信するために必要なすべてのシステムとインフラストラクチャと、アプリ/アドインが通信できるサポート バックエンド システムが含まれます。 スコープ内環境に接続されている追加の環境も、適切なセグメント化が実装され、接続された環境がスコープ内環境のセキュリティを侵害できない限り、スコープに含める必要があります。
注: プライマリ環境で障害が発生した場合にサービス継続性を維持するには、これらの環境が重要な場合があるため、個別のディザスター リカバリー環境もスコープ内環境に含める必要があります。
さらに、リモート バックアップ環境は機密性の高い Microsoft データを格納する可能性があるため、スコープに組み込む必要もあります。 そのため、これらの環境に対して適切なセキュリティ制御を実装する必要があります。
スコープ内システム コンポーネントという用語には、定義されたスコープ内環境内でアクティブに使用されるすべてのデバイスとシステムが含まれます。 これらのコンポーネントには、次のものが含まれますが、これらに限定されません。
- Web アプリケーション
- サーバー (オンプレミスまたはクラウド内にある物理または仮想)
- スイッチ
- ロード バランサー
- 仮想インフラストラクチャ
- クラウド プロバイダー Web 管理ポータル
- クラウド リソース (Virtual Machines、App Services、ストレージ アカウント、データベースなど)
重要
公開されているシステム コンポーネントは、特に外部の脅威アクターによる攻撃に対して脆弱であるため、リスクが高くなります。 通常、これらのシステムは、非武装地帯 (DMZ) などのネットワーク セキュリティ制御 (NSC) の実装を通じて、内部システム コンポーネントから分離する必要があります。 DMZ の目的は、バッファー ゾーンとして機能し、外部システムに対する信頼を制限し、内部システムとデータを保護するためのセキュリティを強化することです。 DMZ は依然として理想的な場合もありますが、最新のクラウド アーキテクチャは、特定のデプロイ シナリオに合わせて調整された代替のセキュリティ対策に依存することがよくあります。
サービスとしてのインフラストラクチャ (IaaS)、サービスとしてのプラットフォーム (PaaS)、サービスとしてのソフトウェア (SaaS)
レビュー中のスコープ内環境をサポートするために IaaS または PaaS を使用する場合、クラウド プラットフォーム プロバイダーは、認定プロセス全体を通じて評価されるセキュリティ制御の一部を担当します。 アナリストは、PCI DSS、コンプライアンス構成証明 (AOC)、ISO 27001、SOC 2 Type II レポートなどの外部コンプライアンス レポートを通じて、クラウド プラットフォーム プロバイダーによるセキュリティベスト プラクティスの独立した外部検証を提供する必要があります。
展開の種類に適用できる可能性のあるセキュリティ制御と、環境が Microsoft 365 データを処理または転送するかどうかの詳細については、「 付録 C」を参照してください。デプロイの種類は次のとおりです。
ISV Hosted: 独立系ソフトウェア ベンダーによってホストされるアプリケーション IaaS Hosted: サードパーティのクラウド プラットフォームによって提供されるインフラストラクチャ。 PaaS/Serverless Hosted: プラットフォーム ベースまたはサーバーレス アーキテクチャを平均化するアプリケーション。 ハイブリッドホステッド: オンプレミスとクラウドでホストされるコンポーネントの組み合わせ。 共有ホスト: 複数のテナントによって利用される共有クラウド環境。
IaaS または PaaS が使用されている場合は、展開が関連するアーキテクチャの想定されるセキュリティ制御と一致していることを検証する必要があります。
サンプリング
徹底的な評価を行うには、スコープ内のシステム コンポーネントのサンプリングでは、オペレーティング システム、プライマリ デバイス機能、デバイスの種類 (サーバー、ルーター、ネットワーク セキュリティ制御など)、地理的な場所などの要因を考慮する必要があります。 これらの考慮事項に基づいて、認定プロセスの開始時にサンプルが選択されます。 次の表は、スコープ内コンポーネントの母集団に基づいてサンプリング サイズを示しています。
| 人口サイズ | サンプル |
|---|---|
| <=5 | 1 |
| >5 & < 10= | 2 |
| >10 & <=30 | 3 |
| >30 | 4 |
これにより、さまざまな構成とデプロイ モデルにわたる環境のコンプライアンスの代表的な評価が保証されます。
注:
評価中にデバイス間で不一致が特定された場合は、環境の適切な表示を確保するためにサンプル サイズを調整できます。
認定プロセスの概要
Microsoft 365 認定プロセスを開始するには:
パブリッシャー構成証明 パートナー センターに移動し、パブリッシャー構成証明フォームに入力します。 注: 申請が 3 か月を超える場合は、レビューと検証のために再送信する必要があります。
パートナー センターで認定資格を開始したら、[認定資格の開始] オプションを選択して、最初のドキュメントの提出を開始します。 この手順は、認定アナリストがアプリのアーキテクチャと Microsoft データの管理方法に基づいて評価の範囲を特定するのに役立ちます。
認定は、次の 2 つのメインステージで行われます。
初期ドキュメントの提出 この段階では、アナリストがアプリの設計、データ フロー、およびスコープ内環境を理解するのに役立つ重要な詳細を提供します。 アナリストは、該当するセキュリティ制御を決定し、証拠を必要とするシステム コンポーネントの概要を説明します。 このレビューを容易にするために、プロセス全体の約 5% を表す正確なドキュメントを提供する必要があります。
完全な証拠のレビュー この段階では、スコープ内環境のセキュリティ制御への準拠を示す詳細な証拠を提出します。 アナリストは、このフェーズ中にあなたと緊密に連携して、提出物を確認、明確に、検証します。 このフェーズは、プロセスの残りの部分を受け取ります。
料金の考え方の案内
最初のドキュメント提出が承認されると、ポータルに必要なセキュリティコントロールの一覧が表示されます。 コントロールごとに 60 日間 の証拠を提供し、そのコントロールが所定の位置にあり、運用されていることを確認します。 アナリストは、証拠を確認し、それを承認するか、追加の詳細またはリビジョンを要求します。
認定
提出がアナリストによってレビューおよび検証されると、認定の決定に関する通知が届きます。 認定基準を満たすアプリにはバッジが付与され、AppSource の一覧と関連付けられているMicrosoft Docs ページに表示されます。 これらのページでは、アプリのセキュリティとコンプライアンスの属性に関する詳細なレポートも提供されます。
レビューと再認定
Microsoft 365 認定アプリは、Microsoft の標準に継続的に準拠するために、毎年再認定を受ける必要があります。 再認定プロセスでは、スコープ内コントロールを再評価して、現在の環境と一致することを確認します。 中断を回避するために、認定の有効期限が切れる 90 日前までに再認定プロセスを開始できます。 認定資格は、この期間中も有効なままになります。
有効期限が切れる前に再認定が完了しなかった場合、認定は取り消されます。 結果として：
アプリの認定バッジとブランドが削除されます。
ISV は、Microsoft 365 Certified としてアプリの販売を許可されなくなります。
スケジュールされた再認定期間外にアプリに 大幅な変更 がある場合、ISV は Microsoft アプリ コンプライアンス プログラムに通知して、アプリが準拠したままであることを確認する必要があります。
最初のドキュメントの提出
最初の提出には、次の情報が含まれている必要があります。
| ドキュメントの概要 | ドキュメントの詳細 |
|---|---|
| アプリ/アドインの説明 | アプリ/アドインの目的と機能の説明。 これにより、認定アナリストは、アプリ/アドインの機能とその用途について理解を深める必要があります。 |
| 侵入テスト レポート | 過去 12 か月以内に完了した侵入テスト レポート。 このレポートには、アプリ/アドインの展開をサポートする環境と、アプリ/アドインの操作をサポートする追加の環境が含まれている必要があります。 注: ISV が現在年間侵入テストを実行していない場合、Microsoft は認定プロセスを通じてペン テストのコストをカバーします。 |
| アーキテクチャ図 | アプリのサポート インフラストラクチャの概要を表す論理アーキテクチャ図。 これには、 すべての ホスティング環境と、アプリをサポートするサポート インフラストラクチャが含まれている必要があります。 この図では、認定アナリストがスコープ内のシステムを理解し、サンプリングを決定するのに役立つ、環境内のさまざまなサポート システム コンポーネントをすべて示す必要があります。 使用されるホスティング環境の種類も指定してください。ISV Hosted、IaaS、PaaS、または Hybrid。 手記： SaaS が使用されている場合は、環境内でサポート サービスを提供するために使用されるさまざまな SaaS サービスを指定してください。 |
| パブリック フットプリント | サポート インフラストラクチャで使用 されるすべての パブリック IP アドレスと URL の詳細。 これには、使用範囲を分割するために適切なセグメント化が実装されていない限り、環境に割り当てられたルーティング可能な完全な IP 範囲が含まれている必要があります (セグメント化の十分な証拠が必要になります) |
| データ フロー図 | 次の詳細を示すフロー図: |
| ✓ アプリ/アドインとの間の Microsoft 365 データ フロー ( EUII と OII を含む)。 | |
| ✓ サポート インフラストラクチャ内の Microsoft 365 データ フロー (該当する場合)。 | |
| ✓ 保存されるデータの場所と内容、外部サード パーティへのデータの受け渡し方法 (サード パーティの詳細を含む)、オープン/パブリック ネットワークと保存中の転送中のデータの保護方法を示す図。 | |
| API エンドポイントの詳細 | アプリで使用されるすべての API エンドポイントの完全な一覧。 環境のスコープを理解するために、環境内の API エンドポイントの場所を指定します。 |
| Microsoft API のアクセス許可 | アプリ/アドインが機能するために要求されているアクセス許可と、要求されたアクセス許可の正当な理由と共に使用 されるすべての Microsoft API の詳細を示すドキュメントを提供する |
| データ ストレージの種類 | 以下を説明するデータストレージと処理ドキュメント: |
| ✓ Microsoft 365 Data EUII と OII がどの程度受信および保存されているか | |
| ✓ データ保持期間。 | |
| ✓ Microsoft 365 データがキャプチャされている理由。 | |
| ✓ Microsoft 365 データが格納されている場所 (上記のデータ フロー図にも含める必要があります)。 | |
| コンプライアンスの確認 | Publisher Attestation 申請に含まれる外部セキュリティ フレームワークのサポート ドキュメント、または Microsoft 365 認定のセキュリティ制御を確認するときに考慮する必要があります。 現在、次の 4 つがサポートされています。 |
| ✓ PCI DSS コンプライアンス構成証明 (AOC)。 | |
| ✓ SOC 2 タイプ I/Type II レポート。 | |
| ✓ ISMS / IEC - 1S0/IEC 27001 適用性に関する声明 (SoA) と認定。 | |
| ✓ FedRAMP FedRAMP 承認パッケージと FedRAMP 準備評価レポート。 | |
| Web の依存関係 | 現在実行中のバージョンのアプリで使用されるすべての依存関係を示すドキュメント。 |
| ソフトウェア インベントリ | スコープ内環境内で使用されるすべてのソフトウェアとバージョンを含む最新のソフトウェア インベントリ。 |
| ハードウェア インベントリ | サポート インフラストラクチャによって使用される最新のハードウェア インベントリ。 これは、評価フェーズの実行時のサンプリングに役立ちます。 環境に PaaS が含まれている場合は、使用されるクラウド サービス/リソースの詳細を提供します。 |
証拠の収集と評価のアクティビティ
認定アナリストは、定義されたサンプル セット内のすべてのシステム コンポーネントの証拠を確認する必要があります。 評価プロセスをサポートするために必要な証拠の種類には、次のいずれかまたはすべてが含まれます。
証拠の収集
- 初期ドキュメント提出ガイド内で強調表示されている 初期ドキュメント
- ポリシー ドキュメント
- ドキュメントの処理
- システム構成設定
- チケットの変更
- 制御レコードの変更
- システム レポート
- 会議の議事録
- 契約/契約
評価プロセスを完了するために必要な証拠を収集するために、さまざまな方法が使用されます。 この証拠の収集は、次の形式になります。
- ドキュメント
- スクリーンショット
- インタビュー
- スクリーン共有
使用される証拠収集手法は、評価プロセス中に決定されます。 提出に必要な証拠の種類の具体的な例については、「 サンプル証拠ガイド」を参照してください。
評価アクティビティ
認定アナリストは、提出された証拠を確認して、Microsoft 365 認定に必要なすべてのコントロールが満たされていることを確認します。 プロセスを迅速化するには、 初期ドキュメント提出 に指定されているすべてのドキュメントが完了し、事前に提供されていることを確認します。
レビュー中に、アナリストは最初の提出と発行元の構成証明からの証拠を評価します。 調査の範囲、サンプリング側、追加の証拠が必要かどうかを判断します。 アナリストは、収集されたすべての情報を使用して、Microsoft 365 認定仕様への準拠を評価し、アプリが定義されたコントロールを満たしているかどうかを判断します。
アプリの認定基準
アプリとそのサポート インフラストラクチャ、およびサポート ドキュメントは、次の 3 つのセキュリティ ドメインで評価されます。
これらの各セキュリティ ドメインには、評価プロセスの一部として評価される 1 つ以上の要件を含む特定のキー コントロールが含まれています。 Microsoft 365 認定資格がすべてのサイズの開発者に包括的であることを確認するために、各セキュリティ ドメインはスコアリング システムを使用して評価され、各ドメインから全体的なスコアが決定されます。 Microsoft 365 認定の各コントロールのスコアは、そのコントロールが実装されていないと認識されるリスクに基づいて、1 (低) から 3 (高) の間で割り当てられます。 各セキュリティ ドメインには、パスと見なされる最小割合のマークが付けられます。 特定の要因により、次のような自動エラーが発生します。
最小特権 (PoLP) の原則に準拠していない API アクセス許可の使用
必要に応じて侵入テスト レポートが不足しています。
マルウェア対策防御が存在しない。
管理アクセスに多要素認証 (MFA) を実装できない。
修正プログラムの適用プロセスが見つからないか、不十分です。
準拠している GDPR プライバシーに関する通知の欠如。
アプリケーションのセキュリティ
アプリケーション セキュリティ ドメインは、次の領域を評価します。
- GraphAPI アクセス許可の検証
- 外部接続チェック
- 侵入テスト
GraphAPI アクセス許可の検証
これにより、アプリまたはアドインが過度または過度に制限されたアクセス許可を要求しないようにします。 認定アナリストは、アプリによって要求されたアクセス許可を手動で確認し、パブリッシャー構成証明申請に対してクロスチェックします。
目標は、要求されたアクセス許可が最小特権の原則に準拠していることを確認することです。 アナリストは、アプリが必要なアクセス許可を超えるアクセス許可を要求している場合は、ISV と連携して、これらのアクセス許可のビジネス上の正当な理由を検証します。 要求されたアクセス許可とパブリッシャー構成証明申請の間で特定された不一致については、このレビュー中に対処して解決する必要があります。
外部接続チェック
認定プロセスの一環として、アナリストはアプリケーションの機能の概要を確認して、Microsoft 365 の外部で行われた外部接続を特定します。
Microsoft サービスであると識別されていない接続、またはサービスに関連しない接続は、評価中に、セキュリティと機能の標準に準拠していることを確認するために、ディスカッションのフラグが設定されます。
侵入テスト
侵入テストは、アプリまたはアドインとそのサポート環境に関連するリスクを特定して軽減するために重要です。 これにより、アプリが顧客に適切なセキュリティ保証を提供します。
侵入テストは、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 を侵害するためにすぐに悪用できる重大な技術的脆弱性。 |
重要
レポートは、上記の侵入テスト要件のセクションで詳しく説明したすべてが実証できる十分な保証を提供できる必要があります。
無料の侵入テストの要件と規則
現在侵入テストを実行していない 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 |
|---|---|
| 認識トレーニング | organizationが、新規ユーザーの初期トレーニングの一環として、または情報システムの変更によって必要な場合に、情報システム ユーザー (マネージャー、上級幹部、請負業者を含む) に対して確立されたセキュリティ認識トレーニングを提供する証拠を提供します。 |
| organization定義された認識トレーニングの頻度の証拠を提供します。 | |
| organization定義された頻度で個々のトレーニング レコードを保持しながら、個々の情報システムのセキュリティ認識アクティビティのドキュメントと監視の証拠を提供します。 | |
| マルウェア保護 - ウイルス対策 | マルウェア対策ソリューションがアクティブであり、サンプリングされたすべてのシステム コンポーネントで有効になっており、次の条件を満たすように構成されていることを示す証拠を提供します。 |
| ウイルス対策の場合、そのオンアクセス スキャンが有効になり、署名が 1 日以内に最新の状態になり、マルウェアが検出されたときにマルウェアまたはアラートと検疫が自動的にブロックされます。 | |
| または、EDR/NGAV (エンドポイント検出と応答/次世代ウイルス対策) の場合は、定期的なスキャンが実行され、監査ログが生成され、継続的に最新の状態に保たれ、自己学習機能を備えています。 | |
| EDR/NGAV は既知のマルウェアをブロックし、マクロの動作に基づいて新しいマルウェアバリアントを識別してブロックし、セーフリストの完全な機能を持ちます。 | |
| マルウェア保護 - アプリケーションコントロール | ビジネス上の正当な理由を持つソフトウェア/アプリケーションの承認されたリストが存在し、最新であることを実証可能な証拠を提供します。 |
| 各アプリケーションが承認プロセスを受け、デプロイの前にサインオフすること | |
| このアプリケーション制御テクノロジは、文書化されているように、サンプリングされたすべてのシステム コンポーネントにわたってアクティブ、有効、および構成されています。 | |
| パッチ管理 - パッチ適用とリスクのランク付け | 新しいセキュリティの脆弱性を特定し、リスク スコアを割り当てる方法を管理するポリシー ドキュメントを提供します。 |
| 新しいセキュリティの脆弱性がどのように識別されるかを示す証拠を提供します。 | |
| すべての脆弱性が特定されるとリスク ランク付けが割り当てられることを示す証拠を提供します。 | |
| サンプリングされたすべてのシステム コンポーネントが、組織が定義したパッチ適用期間に沿って修正プログラムが適用され、サポートされていないオペレーティング システムとソフトウェア コンポーネントが使用されていないことを示します。 該当する場合は、サーバーレス テクノロジまたは PaaS が使用されている場合はコード ベース、IaaS が使用されている場合はインフラストラクチャとコード ベースの両方を含める必要があります。 | |
| パッチ適用期間のガイドライン: クリティカル – 14 日以内、高 – 30 日以内、中 – 60 日以内。 | |
| 脆弱性スキャン | 四半期ごとのインフラストラクチャと Web アプリケーションの脆弱性スキャン レポートを提供します。 スキャンは、パブリック フットプリント全体 (IP アドレスと URL) と内部 IP 範囲に対して実行する必要があります。 |
| 脆弱性スキャン中に特定された脆弱性の修復が、文書化されたパッチ適用期間に沿って修正されるという実証可能な証拠を提供します。 | |
| ネットワーク セキュリティ制御 (NSC) | ネットワーク セキュリティ制御 (NSC) がスコープ内環境の境界にインストールされ、境界ネットワークと内部ネットワークの間にインストールされていることを示す証拠を提供します。 |
| また、Hybrid、オンプレミス、IaaS の場合、すべてのパブリック アクセスが境界ネットワークで終了するという証拠も提供されます。 | |
| すべてのネットワーク セキュリティ制御 (NSC) が、規則ベース内で明示的に定義されていないトラフィックを削除するように構成されていること、およびネットワーク セキュリティ制御 (NSC) ルール レビューが少なくとも 6 か月ごとに実行されることを検証します。 | |
| 変更コントロール | 運用環境に導入された変更が、変更の影響、バックアウト手順の詳細、実行されるテスト、承認された担当者によるレビューと承認を含む文書化された変更要求を通じて実装されていることを示す証拠を提供します。 |
| 開発環境とテスト/ステージング環境が運用環境からの職務の分離を強制し、アクセス制御を介して職務の分離が適用され、機密性の高い運用環境データが開発環境またはテスト/ステージング環境内で使用されていないことを示す証拠を提供します。 | |
| ソフトウェアの開発/展開をセキュリティで保護する | セキュリティで保護されたソフトウェア開発をサポートし、セキュリティで保護されたコーディングの業界標準やベスト プラクティスを含むポリシーと手順を提供します。 Open Web Application Security Project (OWASP) Top 10 や SysAdmin、Audit、Network and Security (SANS) Top 25 Common Weakness 列挙 (CWE) など。 |
| コード リポジトリがセキュリティで保護されていることを示す証拠を提供します。すべてのコード変更は、メイン ブランチにマージされる前に 2 番目のレビュー担当者によってレビューと承認プロセスを受け、適切なアクセス制御が実施され、すべてのアクセスが多要素認証 (MFA) によって適用されます | |
| 運用環境に対して行われたすべてのリリースが、デプロイの前にレビューされ、承認されていることを示す証拠を提供します。 | |
| アカウント管理 | 既定の資格情報が、サンプリングされたシステム コンポーネント全体で無効、削除、または変更されていることを示す証拠を提供します。 |
| サービス アカウントをセキュリティで保護 (強化) するためのプロセスが実施されており、このプロセスに従っていることを示す証拠を提供します。 | |
| 一意のユーザー アカウントがすべてのユーザーに発行され、ユーザーの最小特権原則が環境内で従われている、強力なパスワード/パスフレーズ ポリシーまたはその他の適切な軽減策が実施されている、プロセスが実施され、少なくとも 3 か月ごとに実行され、3 か月以内に使用されていないアカウントを無効または削除するという証拠を提供します。 | |
| すべてのリモート アクセス接続とコンソール以外のすべての管理インターフェイス (コード リポジトリやクラウド管理インターフェイスへのアクセスを含む) に対して MFA が構成されていることを検証します。 | |
| セキュリティ イベントログ、レビュー、アラート | 90 日間のセキュリティ イベント ログが保持され、30 日以上のセキュリティ イベント ログ データがすぐに利用できる証拠を提供します。 |
| ログが定期的にレビューされ、レビュー プロセス中に特定された潜在的なセキュリティ イベント/異常が調査され、対処されていることを示す証拠を提供します | |
| 特権アカウントの作成/変更、特権/リスクの高いアクティビティまたは操作、マルウェア イベント、イベント ログ改ざん、IDPS /WAF イベントなど、該当する場合に、次のセキュリティ イベントの調査のためにアラートがトリガーされるようにアラート ルールが構成されていることを示す証拠を提供します。 (構成されている場合) | |
| 情報リスク管理 | 承認された正式な情報セキュリティ リスク管理ポリシー/プロセスが文書化され、確立されていることを示す証拠を提供します。 |
| 正式な会社全体の情報セキュリティ リスク評価が少なくとも年に 1 回行われるという証拠を提供します。 | |
| または対象リスク分析の場合: 従来のコントロールまたは業界のベスト プラクティスが実施されていないすべてのインスタンスについて、対象となるリスク分析が少なくとも 12 か月ごとに文書化され、実行されます。ここで、設計/技術的制限によって、環境に脆弱性が導入されたり、ユーザーやデータが危険にさらされたりします。 侵害の疑いまたは確認が必要な場合。 | |
| 情報セキュリティ リスク評価に、影響を受けるシステム コンポーネントまたはリソース、脅威と脆弱性または同等のもの、影響と可能性のマトリックスまたは同等のリスク レジスタ/リスク処理計画の作成が含まれていることを検証します。 | |
| ベンダーやビジネス パートナーに関連するリスクを評価および管理するリスク管理プロセスがあることを示す証拠を提供し、内部コントロールのシステムに影響を与える可能性のある変更とリスクを特定して評価できます。 | |
| セキュリティ インシデント対応 | 承認されたセキュリティ インシデント対応計画/手順 (IRP) を指定します。 |
| organizationがインシデントにどのように対応するか、それがどのように維持されているかを示す証拠を提供し、連絡先情報、インシデント中の内部通信計画、主要な利害関係者、支払いブランドと買収者、規制機関 (例: GDPR の場合は 72 時間)、監督当局などの関係者への外部通信を含むインシデント対応チームの詳細を示します。 取締役、顧客、インシデント分類、封じ込め、軽減、復旧、インシデントの種類に応じた通常の業務への復帰などのアクティビティの手順 | |
| インシデント対応チームのすべてのメンバーが、インシデントに対応できる年次トレーニングを受けたという証拠を提供します。 | |
| インシデント対応戦略とサポート ドキュメントが、テーブル トップ演習から学んだレッスン、インシデントへの対応から学んだ教訓、組織の変更に基づいてレビューおよび更新されていることを示す証拠を提供します。 | |
| 事業継続計画とディザスター リカバリー計画 | ビジネス継続性計画の概要を示すドキュメントが存在し、維持されていることを示す証拠を提供します。 |
| ビジネス継続計画に関連する担当者とその役割と責任の詳細を示す証拠を提供します。関連するコンティンジェンシー要件と目的を持つビジネス機能、システムとデータのバックアップ手順、構成、スケジュール/保有、回復の優先順位と期間のターゲット、アクション、手順、手順を詳細に示すコンティンジェンシー 計画。重要な情報システム、ビジネス機能、サービスを、発生時に運用する必要があります。予期しない、予定外の中断、最終的な完全なシステムの復元をカバーし、元の状態に戻る確立されたプロセス。 | |
| ドキュメントが存在し、維持され、ディザスター リカバリー 計画の概要を示し、少なくとも含まれている証拠を提供します。これには、人員とその役割、責任、エスカレーション プロセス、重要なビジネス機能とサービスをサポートするために使用される情報システムのインベントリ、システムとデータのバックアップ手順と構成、重要な情報システムとデータを操作に復元するためのアクションと手順の詳細を示す復旧計画が含まれています。 | |
| ビジネス継続計画とディザスター リカバリー 計画が少なくとも 12 か月ごとにレビューされ、有害な状況でも有効で有効であることを確認する証拠を提供します。 | |
| 計画の年次レビューに基づいてビジネス継続計画が更新される証拠を提供し、コンティンジェンシー 計画に割り当てられた役割と責任に関するトレーニングを受けるすべての関連担当者、計画/s がビジネス継続性またはディザスター リカバリー演習を通じてテストされ、演習や組織の変更から学んだ教訓を含むテスト結果が文書化されます。 |
データ処理のセキュリティとプライバシー
データ セキュリティを確保するには、アプリケーション ユーザー、中間サービス、ISV システム間で転送中のデータを TLS (トランスポート層セキュリティ) 接続を使用して暗号化する必要があります。 少なくとも TLS 1.2 が必要です。TLS 1.3 以上を強くお勧めします。 詳細については、付録 A を参照してください。
Microsoft 365 データを取得または格納するアプリケーションでは、データ ストレージ暗号化スキームを実装することが必須です。 これは 、付録 B に記載されている仕様と一致している必要があります。
コントロール
| コントロール ファミリ | Controls |
|---|---|
| 転送中のデータ | TLS プロファイル構成要件 内で TLS 構成が TLS1.2 以上であることを検証し、信頼されたキーと証明書のインベントリが保持および保守されていることを示す証拠を提供します。 |
| 提供する証拠は、圧縮率の情報漏えいを防ぐために Web 要求を処理するすべての公開サービスに対して TLS 圧縮が無効になっていることを示す証拠を提供します。また、TLS HSTS が有効になっており、すべてのサイトで 180 日に構成されています。 | |
| 保存データ | 保存データが暗号化プロファイルの要件に沿って暗号化されていることを示す証拠を提供します。暗号化キー サイズが 256 ビット以上の Advanced Encryption Standard (AES)、RSA、Twofish などの暗号化アルゴリズムを使用します。 |
| データの保持、バックアップ、破棄 | 承認されたデータ保持期間が正式に確立され、文書化されていることを証明します。 |
| 前のコントロールで説明したように、定義された保持期間に対してのみデータが保持されることを示す証拠を提供します。 | |
| 保持期間後にデータを安全に削除するためのプロセスが実施されていることを示す証拠を提供します。 | |
| 自動バックアップ システムが配置され、スケジュールされた時刻にバックアップを実行するように構成されていることを示す証拠を提供します。 | |
| バックアップ情報がバックアップ スケジュール手順に沿ってテストされ、データの信頼性と整合性を確認するために定期的に復元される証拠を提供します。 | |
| 承認されていないアクセスに対してバックアップ/システム スナップショットがセキュリティで保護され、バックアップ データの機密性、整合性、可用性を確保するために、適切なアクセス制御と保護メカニズム (つまり、不変バックアップ) が実装されている証拠を提供します。 | |
| データ アクセス管理 | データや暗号化キーへのアクセス権を持つユーザーの一覧が維持されていることを示す証拠を提供します。 各ユーザーのビジネス上の正当な理由と確認を含め、このユーザーの一覧は、ジョブ機能に必要なアクセス特権に基づいて正式に承認され、ユーザーは承認に記載されている特権で構成されます。 |
| データが共有されているすべてのサード パーティの一覧が維持され、データ共有契約がデータを使用するすべてのサード パーティと実施されていることを示す証拠を提供します。 | |
| プライバシー | organizationには、プライバシー情報管理 (PIM) システムが確立、実装、保守されており、ポリシーやその他の形式のドキュメントやコンピューター化されたシステムを使用して、プライバシー情報管理の取り組みがシステムの機密性と整合性のために維持される方法に関するリーダーシップ コミットメントを保持していますか。 PII プロセッサやコントローラーなど、システムを保守する各ユーザーの役割、責任、権限を決定します。 |
| PII 最小化が行われていることを確認するためのプロセスの証拠を提供し、PII の識別解除と削除は処理期間の終わりに行われ、機密性を含む PII 転送の制御が行われ、特定の国/地域から別の国/地域への PII の移転記録が存在します。 | |
| GDPR | データ主体が SA を発生させ、ISV が SAR 要求に応答するときにデータ主体のデータのすべての場所を識別できること、SAR を介してデータの削除を要求するクライアントが一定期間のローリング バックアップが削除されるときに削除されることを許可する保持期間があることを示します (最も古いバックアップの削除/書き換えのライフサイクル)。 |
| 組織の詳細 (名前、住所、その他の個人を特定できる情報)、処理される個人データの種類、個人データの保存期間、個人データの処理の適法性、データ主体の権利など、必要なすべての要素を含むプライバシー通知を提供します。例: データ主体の権利、情報を提供する権利、データ主体によるアクセス権、消去する権利、処理の制限の権利、データの移植性に対する権利、異議を唱える権利、プロファイリングを含む自動化された意思決定に関連する権利。 | |
| HIPAA | スタッフ、請負業者、ベンダーなどのために、お客様のorganization内に HIPAA と HIPAA の処理に関するポリシーが存在することを示す証拠を提供します。organizationが 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) の公開バージョンと、発行された ISO 27001 証明書のコピーが必要です。 SOA は、114 個の情報セキュリティ コントロールのそれぞれの位置を要約し、ISO 27001 証明書で十分に詳しく説明されていないコントロールの除外があるかどうかを識別するために使用されます。 SOA の一般向けバージョンを確認してこれを決定できない場合、ISO 27001 を使用して Microsoft 365 認定のセキュリティコントロールの一部を検証する場合、アナリストは完全な SOA にアクセスする必要がある可能性があります。 アナリストは、ISO 27001評価活動の範囲を検証するだけでなく、上記のように監査会社の妥当性も確認します。 |
| PCI DSS | スコープ内のアプリケーションとシステム コンポーネントを明確に識別する有効な レベル 1 コンプライアンス構成証明 (AOC) ドキュメントを提供する必要があります。 自己評価 AOC は、 セキュリティのベスト プラクティスを満たす証拠として受け入れられない。 AOC は、PCI DSS 評価の一環として評価および確認された Microsoft 365 認定仕様コントロールのどれを決定するために使用されます。 |
| SOC 2 | SOC 2 (Type II) レポートは、この Microsoft 365 認定フレームワーク内のいずれかの評価コントロールとの適合性の証拠として使用するために、最新のレポート (過去 15 か月以内に発行され、過去 27 か月以内に開始された宣言された期間) である必要があります。 |
| 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 か月以内)。
✓サポートされている外部セキュリティコンプライアンスフレームワークは、独立した認定企業によって行われる 必要があります 。