Microsoft 365 認定フレームワークの概要
この記事では、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 ソリューション
- Web アプリ (SaaS)
重要
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 認定資格を付与するには、アプリで次の手順を完了する必要があります。
発行元の検証 アプリに検証済みの発行元が存在する場合、アプリを発行する組織は Microsoft によって本物として検証されています。 アプリの検証には、検証済みの Microsoft Cloud Partner Program (CPP) アカウントの使用と、検証済みの PartnerID とアプリの登録の関連付けが含まれます。 発行元の検証を取得する
パブリッシャー構成証明 は、ISV がアプリのセキュリティとデータ処理のプラクティスに関する一連の質問に回答するセルフサービス プロセスです。 アプリは 、Microsoft パートナー センター で発行元の構成証明を行い、完了時に Microsoft AppSource マーケットプレースで不正なフィルターと専用フィルターを受け取ることができます。
コントロール条件を確認する認定を受けるために、すべてのコントロールに準拠する必要はありません。 ただし、この概要ドキュメントで説明されている 3 つのセキュリティ ドメインごとにしきい値 (公開されません) が設定されており、渡す必要があります。 一部のコントロールは "ハード フェイル" として分類されます。つまり、これらのセキュリティ コントロールが不足すると、評価が失敗します。
重要
提出期間: ISV が提出状態を頻繁に確認し、コメントや補足的な証拠要求にタイムリーに応答できる場合、評価プロセスは平均して 30 日かかります。 認定プロセスを開始すると、評価を完了するために最大 60 日が許可されます。 すべての申請が 60 日以内に完了していない場合、提出は失敗し、プロセスを再開する必要があります。 これらの結果は公開されません。
認定スコープ
スコープ内環境では、アプリ/アドイン コードの配信がサポートされ、アプリ/アドインが通信している可能性があるバックエンド システムがサポートされます。 スコープ内環境に接続されている追加の環境も、適切なセグメント化が行われ、接続された環境がスコープ内環境のセキュリティに影響を与えない限り、スコープに含まれます。
また、プライマリ環境に何らかの問題が発生した場合は、サービスを満たすためにこれらの環境が必要であるため、個別のディザスター リカバリー環境もスコープ内環境に含める必要があります。 また、これらの環境には Microsoft データが格納される可能性があるため、適切なセキュリティ制御を実施する必要があるため、リモート バックアップ環境も含める必要があります。
スコープ内システム コンポーネントという用語は、定義されたスコープ内環境内で使用されるすべてのデバイスとシステムを参照します。 スコープ内コンポーネントには、次のものが含まれますが、これらに限定されません。
- Web アプリケーション
- サーバー (オンプレミスまたはクラウド内に存在する物理または仮想)
- ファイアウォールなどのネットワーク セキュリティ制御 (NSC)
- スイッチ
- ロード バランサー
- 仮想インフラストラクチャ
- クラウド プロバイダー Web 管理ポータル
- クラウド リソース (Virtual Machines、App Service、ストレージ アカウント、EC2 インスタンスなど)
重要
パブリックに接続するシステム コンポーネントは、外部の脅威アクターからの攻撃の影響を受けやすいため、リスクが大幅に高くなります。 通常、これらのシステムは、非武装地帯 (DMZ) を作成するネットワーク セキュリティ制御 (NSC) を使用して、他の内部システム コンポーネントからセグメント化されます。 DMZ は内部ネットワークよりも信頼が低く、セキュリティを強化するという意図は、公開されているシステムが侵害された場合に内部システムとデータをさらに保護するのに役立ちます。 理想的には DMZ が使用されますが、一部の展開シナリオでは実現できないか、必要な場合もあります。
サービスとしてのインフラストラクチャ (IaaS)、サービスとしてのプラットフォーム (PaaS)、サービスとしてのソフトウェア (SaaS)
レビュー中のスコープ内環境をサポートするために IaaS または PaaS を使用する場合、クラウド プラットフォーム プロバイダーは、認定プロセス全体を通じて評価されるセキュリティ制御の一部を担当します。 アナリストは、PCI DSS、コンプライアンス構成証明 (AOC)、ISO 27001、SOC 2 Type II レポートなどの外部コンプライアンス レポートを通じて、クラウド プラットフォーム プロバイダーによるセキュリティベスト プラクティスの独立した外部検証を提供する必要があります。
付録 C では、次の種類の展開と、アプリが Microsoft 365 データを流出させるかどうかに基づいて、適用される可能性のあるセキュリティ制御の詳細を示します。
- ISV ホステッド
- IaaS Hosted
- PaaS/Serverless Hosted
- ハイブリッド ホステッド
- 共有ホステッド
IaaS または PaaS がデプロイされている場合は、これらのデプロイの種類に対する環境の配置を検証する証拠を提供する必要があります。
サンプリング
認定評価をサポートする証拠の要求は、さまざまなオペレーティング システム、デバイスの主な機能、さまざまなデバイスの種類 (サーバー、NSC、ルーターなど) と場所を考慮したスコープ内システム コンポーネントのサンプルに基づいている必要があります。 認定プロセスの開始時に適切なサンプルが選択されます。 次の表は、上記の要因に基づいてサンプリングを決定するガイドとして使用する必要があります。
| 人口サイズ | サンプル |
|---|---|
| <=5 | 1 |
| >5 & < 10= | 2 |
| >10 & <=30 | 3 |
| >30 | 4 |
注:
最初のサンプルに含まれるデバイス間で不一致が特定された場合、評価中にサンプル サイズが大きくなる可能性があります。
エンドツーエンドの認定プロセス
Microsoft 365 認定資格を開始するには:
パートナー センターに移動し、パブリッシャー構成証明を完了します。 提出が 3 か月を超える場合は、レビューと検証のために再送信してください。
パートナー センター内で、[認定資格の開始] を選択して、最初のドキュメントの提出を開始します。 これにより、認定アナリストは、アプリのアーキテクチャと Microsoft データの処理方法に基づいて、評価のスコープ内の内容を判断するのに役立ちます。
ヒント
詳しい手順については 、ハウツー ガイドに 従ってアプリ Microsoft 365 Certified を入手してください。
認定プロセスは、次の 2 つの段階で実行されます。
初期ドキュメント送信 は、アナリストがアプリ、データ フローを理解し、 スコープ内環境を定義し、適用できるセキュリティ制御を特定し、証拠を収集する必要があるシステム コンポーネントを決定するのに役立ちます。 ISV は、認定アナリストがプロセスのこの段階を完了するのに役立つ要求された情報を提供する必要があります。これは、プロセス全体の約 5% です。
完全な証拠レビュー は、 スコープ内環境 がセキュリティコントロールを満たす方法を示す証拠成果物を ISV が送信するプロセスです。 この監査段階では、ISV とアナリストの間で複数の対話が行われます。これはプロセスの残りの部分です。
料金の考え方の案内
最初のドキュメントの提出が受け入れられたら、一連のセキュリティ コントロールがポータルに自動的に表示されます。 ISV は、コントロールが配置され、すべての証拠を提出するために 60 日 があることを示す証拠を各コントロールに提供する必要があります。 アナリストは、証拠を確認し、コントロールを承認するか、新しい証拠または追加の証拠を要求します。
認定
アナリストによって提出が検証されると、ISV に認定の決定が通知されます。 認定を受けたアプリには、 AppSource 内のアプリケーションに関するバッジと、セキュリティとコンプライアンスの属性の詳細なレポートが記載された専用 の Microsoft ドキュメント ページが表示されます。
レビューと再認定
Microsoft 365 認定アプリは、年単位で再認定を行う必要があります。 これには、現在のスコープ内環境に対するスコープ内コントロールの再検証が必要になります。 このプロセスは、認定資格の有効期限の 90 日前まで開始できます。 既存の認定資格は、再認定期間中は期限切れになりません。 すべてのプログラムの再認定は、Microsoft 365 認定資格の 1 年の記念日に期限切れになります。
有効期限が切れる前に認定資格が更新されない場合、アプリの認定状態は取り消されます。 すべてのバッジ、アイコン、および関連する認定ブランドはアプリから削除され、ISV はアプリを Microsoft 365 Certified として宣伝することは禁止されます。
再認定申請期間外にアプリケーションが 大幅に変更 された場合、ISV の更新プログラムに通知するように求められます。
最初のドキュメントの提出
最初の提出には、次の情報が含まれている必要があります。
| ドキュメントの概要 | ドキュメントの詳細 |
|---|---|
| アプリ/アドインの説明 | アプリ/アドインの目的と機能の説明。 これにより、認定アナリストは、アプリ/アドインの機能とその用途について理解を深める必要があります。 |
| 侵入テスト レポート | 過去 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 アクセス許可。
- 必要な場合は、侵入テスト レポートはありません。
- マルウェア対策防御なし。
- 多要素認証は、管理アクセスを保護するために使用されていません。
- パッチ適用プロセスなし。
- 適切な GDPR プライバシーに関する通知はありません。
アプリケーションのセキュリティ
アプリケーション セキュリティ ドメインは、次の 3 つの領域に重点を置いています。
- GraphAPI アクセス許可の検証
- 外部接続チェック
- 侵入テスト
GraphAPI アクセス許可の検証
GraphAPI アクセス許可の検証は、アプリ/アドインが過度に制限されたアクセス許可を要求しないことを検証するために実行されます。 これは、要求されるアクセス許可を手動で確認することによって実行されます。 認定アナリストは、パブリッシャー構成証明の提出に対してこれらのチェックを相互参照し、要求されているアクセスレベルを評価して、"最小限の特権" プラクティスが満たされていることを確認します。 認定アナリストは、これらの "最小限の特権" プラクティスが満たされていないと考えている場合、認定アナリストは ISV とオープンディスカッションを行い、要求されるアクセス許可のビジネス上の正当な理由を検証します。 このレビュー中に見つかったパブリッシャー構成証明の提出に不一致がある場合は、修正する必要があります。
外部接続チェック
評価の一環として、アプリケーション機能の簡単なウォークスルーが実行され、Microsoft 365 の外部で行われている接続が特定されます。 Microsoft またはサービスへの直接接続として識別されない接続は、評価中にフラグが設定され、説明されます。
侵入テスト
アプリ/アドインとサポート環境に関連するリスクの適切なレビューは、アプリ/アドインのセキュリティを保証するために不可欠です。 侵入テストの形式でのアプリケーション セキュリティ テストは、アプリケーションが Microsoft によって公開されていないサービスに接続している場合に実行する必要があります。 アプリをデプロイした後、GraphAPI などの Microsoft サービスにのみアクセスしてスタンドアロンで動作する場合、侵入テストは必要ありません。 スコープ内環境が Azure 内でホストされている場合、侵入テストは引き続き必要です。
侵入テストスコープ
内部および外部のインフラストラクチャ侵入テストの場合、すべての侵入 テスト アクティビティは 、アプリ/アドインのデプロイをサポートするライブ運用環境 (たとえば、アプリ/アドイン コードがホストされており、通常はマニフェスト ファイル内のリソース) と、アプリ/アドインの操作をサポートする追加の環境 (たとえば、 アプリ/アドインが Microsoft 365 以外の他の Web アプリケーションと対話する場合)。 侵入テストのスコープを定義する場合は、スコープ内環境のセキュリティに影響を与える可能性がある "接続済み" システムまたは環境もすべての侵入テスト アクティビティに含まれるように注意する必要があります。
ライブ運用環境に対して Web アプリケーション侵入テストを実行することをお勧めします。 ただし、テスト時にまったく同じコードベースがテスト/UAT 環境内で動作していたことが侵入テスト レポート内で確認できれば、テスト/UAT 環境を使用して Web アプリケーションのみのテストを実行することは許容されます。
スコープ内の環境を他の環境からセグメント化するために手法を使用する場合、侵入テスト アクティビティは、上記のセグメント化手法の有効性を検証する必要があります。 これは、侵入テスト レポート内で詳しく説明する必要があります。
注:
ホスト環境が PaaS としてのみ分類されない限り、内部侵入テストを実行する必要があります。
侵入テストの要件
侵入テスト レポートは、以下のコントロールに記載されている次の 自動エラー条件 を満たす脆弱性がないことを確認するためにレビューされます。
| 抽出条件の種類 | 侵入テスト コントロール |
|---|---|
| 一般的な条件 | 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 365 認定資格に対して無料で実施できます。 Microsoft は、最大 12 日間の手動テストの侵入テストのコストを調整してカバーします。 侵入テストのコストは、スコープ内環境のテストに必要な日数に基づいて計算されます。 12 日間を超えるテスト費用は、ISV の責任となります。
- ISV は、侵入テストが実施される前に、証拠を提出し、スコープ内のコントロールの 50% の承認を受ける必要があります。 作業を開始するには、最初のドキュメント提出に記入し、評価の一部として侵入テストを含めるように選択します。 スコープに連絡し、コントロールの 50% を完了したときに侵入テストをスケジュールします。
- ペンテストが完了すると発行されたレポートは、認定が完了すると 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) がスコープ内環境の境界にインストールされ、境界ネットワークと内部ネットワークの間にインストールされていることを示す証拠を提供します。 |
| また、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) を指定します。 |
| 組織がインシデントにどのように対応しているかを示す証拠を提供し、その管理方法を示し、インシデント対応チームの詳細 (連絡先情報、インシデント中の内部通信計画、主要な利害関係者、支払いブランドや買収者、規制機関 (GDPR の場合は 72 時間など) などの関係者への外部通信を含む) を提供します。 監督当局、取締役、顧客、インシデント分類、封じ込め、軽減、復旧、インシデントの種類に応じた通常の業務への復帰などの活動の手順 | |
| インシデント対応チームのすべてのメンバーが、インシデントに対応できる年次トレーニングを受けたという証拠を提供します。 | |
| インシデント対応戦略とサポート ドキュメントが、テーブル トップ演習から学んだレッスン、インシデントへの対応から学んだ教訓、組織の変更に基づいてレビューおよび更新されていることを示す証拠を提供します。 | |
| 事業継続計画とディザスター リカバリー計画 | ビジネス継続性計画の概要を示すドキュメントが存在し、維持されていることを示す証拠を提供します。 |
| ビジネス継続計画に関連する担当者とその役割と責任の詳細を示す証拠を提供します。関連するコンティンジェンシー要件と目的を持つビジネス機能、システムとデータのバックアップ手順、構成、スケジュール/保有、回復の優先順位と期間のターゲット、アクション、手順、手順を詳細に示すコンティンジェンシー 計画。重要な情報システム、ビジネス機能、サービスを、発生時に運用する必要があります。予期しない、予定外の中断、最終的な完全なシステムの復元をカバーし、元の状態に戻る確立されたプロセス。 | |
| ドキュメントが存在し、維持され、ディザスター リカバリー 計画の概要を示し、少なくとも含まれている証拠を提供します。これには、人員とその役割、責任、エスカレーション プロセス、重要なビジネス機能とサービスをサポートするために使用される情報システムのインベントリ、システムとデータのバックアップ手順と構成、重要な情報システムとデータを操作に復元するためのアクションと手順の詳細を示す復旧計画が含まれています。 | |
| ビジネス継続計画とディザスター リカバリー 計画が少なくとも 12 か月ごとにレビューされ、有害な状況でも有効で有効であることを確認する証拠を提供します。 | |
| 計画の年次レビューに基づいてビジネス継続計画が更新される証拠を提供し、コンティンジェンシー 計画に割り当てられた役割と責任に関するトレーニングを受けるすべての関連担当者、計画/s がビジネス継続性またはディザスター リカバリー演習を通じてテストされ、演習や組織の変更から学んだ教訓を含むテスト結果が文書化されます。 |
データ処理のセキュリティとプライバシー
アプリケーション ユーザー、中間サービス、ISV のシステム間の転送中のデータは、TLS v1.1 の最小値をサポートする TLS 接続を介した暗号化によって保護する必要があります。 (TLS v1.2 以降をお勧めします)。 付録 Aを参照してください。
アプリケーションが Microsoft 365 データを取得して格納する場合は、 付録 B で定義されている仕様に従うデータ ストレージ暗号化スキームを実装する必要があります。
コントロール
| コントロール ファミリ | Controls |
|---|---|
| 転送中のデータ | TLS プロファイル構成要件 内で TLS 構成が TLS1.2 以上であることを検証し、信頼されたキーと証明書のインベントリが保持および保守されていることを示す証拠を提供します。 |
| 提供する証拠は、圧縮率の情報漏えいを防ぐために Web 要求を処理するすべての公開サービスに対して TLS 圧縮が無効になっていることを示す証拠を提供します。また、TLS HSTS が有効になっており、すべてのサイトで 180 日に構成されています。 | |
| 保存データ | 保存データが暗号化プロファイル要件に沿って暗号化されていることを示す証拠を提供します。暗号化キー サイズが 256 ビット以上の Advanced Encryption Standard (AES)、RSA、Twofish などの暗号化アルゴリズムを使用します。 |
| データの保持、バックアップ、破棄 | 承認されたデータ保持期間が正式に確立され、文書化されていることを証明します。 |
| 前のコントロールで説明したように、定義された保持期間に対してのみデータが保持されることを示す証拠を提供します。 | |
| 保持期間後にデータを安全に削除するためのプロセスが実施されていることを示す証拠を提供します。 | |
| 自動バックアップ システムが配置され、スケジュールされた時刻にバックアップを実行するように構成されていることを示す証拠を提供します。 | |
| バックアップ情報がバックアップ スケジュール手順に沿ってテストされ、データの信頼性と整合性を確認するために定期的に復元される証拠を提供します。 | |
| 承認されていないアクセスに対してバックアップ/システム スナップショットがセキュリティで保護され、バックアップ データの機密性、整合性、可用性を確保するために、適切なアクセス制御と保護メカニズム (つまり、不変バックアップ) が実装されている証拠を提供します。 | |
| データ アクセス管理 | データや暗号化キーへのアクセス権を持つユーザーの一覧が維持されていることを示す証拠を提供します。 各ユーザーのビジネス上の正当な理由と確認を含め、このユーザーの一覧は、ジョブ機能に必要なアクセス特権に基づいて正式に承認され、ユーザーは承認に記載されている特権で構成されます。 |
| データが共有されているすべてのサード パーティの一覧が維持され、データ共有契約がデータを使用するすべてのサード パーティと実施されていることを示す証拠を提供します。 | |
| プライバシー | 組織には、プライバシー情報管理 (PIM) システムが確立、実装、保守されており、ポリシーやその他の形式のドキュメント/コンピューター化されたシステムを使用して、プライバシー情報管理の取り組みがシステムの機密性と整合性のために維持される方法に関するリーダーシップコミットメントを保持していますか。 PII プロセッサやコントローラーなど、システムを保守する各ユーザーの役割、責任、権限を決定します。 |
| PII 最小化が行われていることを確認するためのプロセスの証拠を提供し、PII の識別解除と削除は処理期間の終わりに行われ、機密性を含む PII 転送の制御が行われ、特定の国/地域から別の国/地域への PII の移転記録が存在します。 | |
| GDPR | データ主体が SA を発生させ、ISV が SAR 要求に応答するときにデータ主体のデータのすべての場所を識別できること、SAR を介してデータの削除を要求するクライアントが一定期間のローリング バックアップが削除されるときに削除されることを許可する保持期間があることを示します (最も古いバックアップの削除/書き換えのライフサイクル)。 |
| 必要なすべての要素 (名前、住所、その他の個人を特定できる情報)、処理される個人データの種類、個人データの保持期間、個人データの処理の適法性、データ主体の権利など、必要なすべての要素を含むプライバシー通知を提供します。例: データ主体の権利、情報を提供する権利、データ主体によるアクセス権、消去する権利、処理の制限の権利、データの移植性に対する権利、異議を唱える権利、プロファイリングを含む自動化された意思決定に関連する権利。 | |
| HIPAA | という証拠を提供します。スタッフ、請負業者、ベンダーなどに対して、HIPAA と HIPAA の組織内での処理にポリシーが存在します。組織が ePH の機密性、整合性、可用性を確保していることを確認します。 |
| お客様が、プライバシー規則で許可されていない、合理的に予想される使用または開示に対する保護を提供し、従業員によるセキュリティ規則への準拠を確保することを確認します。 164.308 (a)(7)(ii)(A) および 164.308 (a)(7)(ii)(B) の下でデータバックアップとディザスター リカバリー計画を提供します。 |
オプションの外部コンプライアンス フレームワークレビュー
必須ではありませんが、現在 ISO 27001、PCI DSS、FedRAMP、SOC2 に準拠している場合は、これらの認定資格を使用して、Microsoft 365 の認定コントロールの一部を満たすことができます。アナリストは、既存の外部セキュリティ フレームワークを Microsoft 365 認定フレームワークに合わせようとします。 ただし、サポート ドキュメントが、Microsoft 365 認定コントロールが外部セキュリティ フレームワークの監査/評価の一部として評価されたことを保証できない場合は、上記のコントロールが実施されていることを示す追加の証拠を提供する必要があります。
ドキュメントでは、Microsoft 365 認定資格のスコープ内環境が、これらの外部セキュリティ フレームワークのスコープ内に含まれていることを十分に示す必要があります。 これらのセキュリティ フレームワークの検証は、信頼できる外部のサード パーティ企業によって実施された有効な認定資格の証拠を受け入れることによって満たされます。 これらの評判の高い企業は、関連するコンプライアンス プログラムの国際的な認定機関のメンバーである必要があります。 「ISO 27001 の ISO 認定および準拠基準」および「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 が保証レベルを得ることを可能にする、これらのセキュリティ標準/フレームワークのごく一部にすぎません。
外部コンプライアンス フレームワークを使用するための要件
✓ スコープ内環境 と サポートされる ビジネス プロセスは 、サポートされている外部セキュリティ コンプライアンス フレームワークのスコープ内に含める必要があり、付属のドキュメントで明確に示されている必要があります。
✓ サポートされている外部セキュリティ コンプライアンス フレームワークは最新である 必要があります 。つまり、過去 12 か月以内 (または再評価が現在実行されており、証拠を提供できる場合は 15 か月以内)。
✓サポートされている外部セキュリティコンプライアンスフレームワークは、独立した認定企業によって行われる 必要があります 。