フレームワークの問題のトラブルシューティング - AWS Audit Manager
カスタムフレームワークの詳細ページで、カスタムフレームワークを再作成するように求められます。カスタムフレームワークのコピーを作成できない送信済みの共有リクエストのステータスは失敗として表示されます共有リクエストの横に青いドットがあります。これは何を意味するのでしょうか? 共有フレームワークには、データソースとしてカスタム AWS Config ルールを使用するコントロールがあります。受信者はこれらのコントロールを収集することができますか?共有フレームワークで使用されているカスタムルールを更新しました。何かアクションを起こす必要がありますか?

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

フレームワークの問題のトラブルシューティング

このページの情報を使用して、Audit Manager の一般的なフレームワークの問題を解決できます。

フレームワークの一般的な問題
フレームワークの共有に関する問題

カスタムフレームワークの詳細ページで、カスタムフレームワークを再作成するように求められます。

評価を再作成するよう求めるポップアップメッセージのスクリーンショット。

「更新されたコントロール定義が利用可能」というメッセージが表示された場合は、Audit Manager がカスタムフレームワークにある一部の標準コントロールの新しい定義を提供するようになったことを示します。

標準コントロールが から証拠を収集できるようになりましたAWS managed source。つまり、Audit Manager が共通コントロールまたはコアコントロールの基盤となるデータソースを更新するたびに、関連する標準コントロールに同じ更新が自動的に適用されます。これにより、クラウドコンプライアンス環境の変化に応じて継続的なコンプライアンスを確保できます。これらの AWS マネージドソースのメリットを確実に享受するには、カスタムフレームワークのコントロールを置き換えることをお勧めします。

カスタムフレームワークでは、Audit Manager はどのコントロールに代替手段が利用可能かを示します。カスタムフレームワークのコピーを作成する前に、これらのコントロールを置き換える必要があります。次回カスタムフレームワークを編集するときに、これらのコントロールを他の編集に置き換えるよう求められます。

カスタムフレームワークのコントロールを置き換えるには、次の 2 つの方法があります。

1. カスタムフレームワークを再作成する

多数のコントロールで置換が可能な場合は、カスタムフレームワークを再作成することをお勧めします。これは、カスタムフレームワークが標準フレームワークに基づいている場合に最適なオプションである可能性があります。

  • 例えば、 を出発点NIST SP 800-53 Rev 5として使用してカスタムフレームワークを作成したとします。この標準フレームワークには 1007 個の標準コントロールがあり、20 個のカスタムコントロールを追加しました。

  • この場合、最も効率的なオプションは、フレームワークライブラリNIST 800-53 (Rev. 5) Low-Moderate-Highで を見つけ、そのフレームワークの編集可能なコピーを作成することです。このプロセス中に、以前に使用したものと同じ 20 個のカスタムコントロールを追加できます。標準フレームワークの最新の定義を開始点として使用しているため、カスタムフレームワークは 1007 のすべての標準コントロールの最新の定義を自動的に継承します。

2. カスタムフレームワークを編集する

少数のコントロールで置換が可能な場合は、カスタムフレームワークを編集し、コントロールを手動で置換することをお勧めします。

  • 例えば、カスタムフレームワークをゼロから作成したとします。カスタムフレームワークでは、自分で作成した 20 個のカスタムコントロールと、標準フレームワークの 8 個のACSC エッセンシャル 8 標準コントロールを追加しました。

  • この場合、最大 8 つのコントロールで更新が使用可能になるため、最も効率的なオプションは、カスタムフレームワークを編集し、それらのコントロールを 1 つずつ置き換えることです。詳細については、以下の手順を参照してください。

カスタムフレームワークのコントロールを手動で置き換えるには

  1. ホーム で AWS https://console.aws.amazon.com/auditmanager/Audit Manager コンソールを開きます。

  2. 左側のナビゲーションペインで、フレームワークライブラリ を選択し、カスタムフレームワークタブを選択します。

  3. 編集するフレームワークを選択し、[アクション]、[編集] の順に選択します。

  4. フレームワークの詳細の編集ページで、次へ を選択します。

  5. 「コントロールセットの編集」ページで、各コントロールセットの名前を確認して、そのコントロールのいずれかに代替のものがあるかどうかを確認します。

  6. 影響を受けるコントロールセットを選択して展開し、置き換える必要があるコントロールを特定します。

    ヒント

    コントロールをより迅速に識別するには、検索ボックスに Replacement available と入力します。

  7. 影響を受けるコントロールを削除するには、チェックボックスを選択し、コントロールセットから削除 を選択します。

  8. 同じコントロールを再追加します。このアクションは、先ほど削除したコントロールを最新のコントロール定義に置き換えます。

    1. 「コントロールの追加」で、コントロールタイプのドロップダウンリストを使用して、「標準コントロール」を選択します。

    2. 削除したコントロールの置き換えを見つけます。

      ヒント

      場合によっては、置換コントロール名は元のコントロール名とまったく同じではない場合があります。この場合、置換コントロール名は元のものと非常によく似ています。まれに、1 つのコントロールが 2 つのコントロール (または逆) に置き換えられることがあります。

      代替コントロールが見つからない場合は、部分検索を行うことをお勧めします。これを行うには、元のコントロール名の一部、または探しているものを表すキーワードを入力します。コンプライアンスタイプで検索して、結果のリストをさらに絞り込むこともできます。

    3. コントロールの横にあるチェックボックスを選択し、コントロールセット に追加を選択します。

    4. 表示されるポップアップウィンドウで、追加 を選択して確認します。

  9. すべてのコントロールを置き換えるまで、必要に応じてステップ 6～8 を繰り返します。

  10. [次へ] をクリックします。

  11. 確認と保存ページで、変更を保存 を選択します。

カスタムフレームワークのコピーを作成できない

フレームワークの詳細ページでコピーを作成ボタンが使用できない場合は、カスタムフレームワークのコントロールの一部を置き換える必要があります。

手順については、「」を参照してくださいカスタムフレームワークの詳細ページで、カスタムフレームワークを再作成するように求められます。。

送信済みの共有リクエストのステータスは失敗として表示されます

カスタムフレームワークを共有しようとして操作が失敗した場合は、次の事項を確認することをお勧めします。

  1. Audit Manager が受信者の AWS アカウント および指定されたリージョンで有効になっていることを確認します。サポートされている AWS Audit Manager リージョンのリストについては、アマゾン ウェブ AWS Audit Manager サービス全般のリファレンスの「 エンドポイントとクォータ」を参照してください。

  2. 受信者アカウントを指定したときに、正しい AWS アカウント ID を入力していることを確認してください。

  3. AWS Organizations 管理アカウントを受信者として指定していないことを確認してください。委任された管理者とカスタムフレームワークを共有できますが、管理アカウントとカスタムフレームワークを共有しようとすると、操作は失敗します。

  4. カスタマーマネージドキーを使用して Audit Manager データを暗号化する場合は、KMSキーが有効になっていることを確認してください。KMS キーが無効になっていて、カスタムフレームワークを共有しようとすると、オペレーションは失敗します。無効になっているKMSキーを有効にする方法については、「 AWS Key Management Service デベロッパーガイド」の「キーの有効化と無効化」を参照してください。

共有リクエストの横に青いドットがあります。これは何を意味するのでしょうか?

青いドットの通知は、共有リクエストに注意が必要であることを示唆しています。

ステータスが [Expiring] (まもなく期限切れ) の送信済み共有リクエストの横に青い通知ドットが表示されます。Audit Manager は青いドットの通知を表示して、共有リクエストの有効期限が切れる前にアクションを実行するよう受信者に注意喚起できるようにします。

青い通知ドットが表示されないようにするには、受信者は、リクエストを承諾または辞退する必要があります。共有リクエストを取り消すと、青いドットも表示されなくなります。

次の手順を実行して、まもなく期限が切れる共有リクエストを確認し、アクションを実行するようオプションのリマインダーを受信者に送信できます。

送信済みリクエストに関する通知を表示するには

  1. ホーム で AWS https://console.aws.amazon.com/auditmanager/Audit Manager コンソールを開きます。

  2. 共有リクエスト通知がある場合、Audit Manager は、ナビゲーションメニューのアイコンの横に赤いドットを表示します。

    最小化されたナビゲーションメニューアイコンのスクリーンショット。通知を示す赤いドットが付いています。

  3. ナビゲーションペインを展開し、[Share requests] (共有リクエスト) の横を確認します。通知バッジは、注意が必要な共有リクエストの数を示します。

    展開されたナビゲーションメニューのスクリーンショット。[Shared framework requests] (共有フレームワークリクエスト) が強調表示され、通知バッジにより通知が 1 件あることがわかります。

  4. [Share requests] (共有リクエスト) を選択してから、[Sent requests] (送信済みリクエスト) のタブを選択します。

  5. 青いドットを探して、今後 30 日以内に期限切れになる共有リクエストを特定します。または、[All statuses] (すべてのステータス) フィルターのドロップダウンから [Expiring] (まもなく期限切れ) を選択して、期限切れになりそうな共有リクエストを表示することもできます。

    フレームワーク名の横に青いドットが表示されている、受信した共有リクエストのスクリーンショット。

  6. (オプション) 共有リクエストの有効期限が切れる前に、アクションを実行する必要があることを受信者に通知します。共有リクエストがアクティブまたはまもなく期限切れになる場合、Audit Manager は、コンソールで通知を送信して受信者に知らせるため、この手順はオプションです。ただし、希望する通信チャネルを使用して、受信者に独自のリマインダーを送信することもできます。

ステータスが [Active] (アクティブ) または [Expiring] (まもなく期限切れ) の受信済み共有リクエストの横に青い通知ドットが表示されます。Audit Manager は青いドットの通知を表示して、共有リクエストの有効期限が切れる前にアクションを実行するようユーザーに注意喚起します。青い通知ドットが表示されないようにするには、リクエストを承諾または辞退する必要があります。送信者が共有リクエストを取り消すと、青いドットも表示されなくなります。

次の手順を実行して、アクティブな共有リクエストやまもなく期限切れの共有リクエストを確認できます。

受信したリクエストに関する通知を表示するには

  1. ホーム で AWS https://console.aws.amazon.com/auditmanager/Audit Manager コンソールを開きます。

  2. 共有リクエスト通知がある場合、Audit Manager は、ナビゲーションメニューのアイコンの横に赤いドットを表示します。

    最小化されたナビゲーションメニューアイコンのスクリーンショット。通知を示す赤いドットが付いています。

  3. ナビゲーションペインを展開し、[共有リクエスト] の横を確認します。通知バッジは、注意が必要な共有リクエストの数を示します。

    展開されたナビゲーションメニューのスクリーンショット。[共有リクエスト] が強調表示され、通知バッジにより通知が 1 件あることがわかります。

  4. [共有リクエスト] を選択します。デフォルトでは、このページは [受信したリクエスト] のタブで開きます。

  5. 青いドットが表示されている項目を探して、アクションが必要な共有リクエストを特定します。

    フレームワーク名の横に青いドットが表示されている、受信した共有リクエストのスクリーンショット。

  6. (オプション) 今後 30 日以内に期限切れになるリクエストのみを表示するには、[All statuses] (すべてのステータス) ドロップダウンリストを見つけて、[Expiring] (まもなく期限切れ) を選択します。

共有フレームワークには、データソースとしてカスタム AWS Config ルールを使用するコントロールがあります。受信者はこれらのコントロールを収集することができますか?

はい、受信者はこれらのコントロールの証拠を収集できますが、そのためにはいくつかの手順が必要です。

Audit Manager が AWS Config ルールをデータソースマッピングとして使用して証拠を収集するには、次の条件を満たす必要があります。これらの基準は、マネージドルールとカスタムルールの両方に適用されます。

  • ルールは受信者の AWS 環境に存在する必要があります。

  • ルールは受信者の AWS 環境で有効にする必要があります。

アカウントの AWS Config ルールが受信者の AWS 環境にまだ存在しない可能性があることに注意してください。さらに、受信者が共有リクエストを受け入れるとき、Audit Manager は受信者のアカウントにカスタムルールを再作成しません。受信者がデータソースマッピングとしてカスタムルールを使用して証拠を収集するには、 のインスタンスに同じカスタムルールを作成する必要があります AWS Config。受信者が でルールを作成して有効にすると AWS Config、Audit Manager はそのデータソースから証拠を収集できます。

受信者と通信して、 のインスタンスにカスタム AWS Config ルールを作成する必要があるかどうかを知らせることをお勧めします AWS Config。

共有フレームワークで使用されているカスタムルールを更新しました。何かアクションを起こす必要がありますか?

AWS 環境内のルール更新の場合

AWS 環境内のカスタムルールを更新する場合、Audit Manager でアクションは必要ありません。Audit Manager は、次の表で説明されている方法でルールの更新を検出し、処理します。Audit Manager は、ルールの更新が検出されても通知しません。

シナリオ Audit Manager の機能 必要な作業

カスタムルールは、 のインスタンスで更新されます AWS Config。

 Audit Manager は、更新されたルール定義を使用して、そのルールに関する検出結果を引き続き報告します。 アクションは不要です。

カスタムルールは、 のインスタンスで削除されます AWS Config。

 Audit Manager は、削除されたルールに関する検出結果の報告を停止します。

アクションは不要です。

必要に応じて、削除されたルールをデータソースマッピングとして使用していたカスタムコントロールを編集することができます。その後、削除されたルールを取り除き、コントロールのデータ ソース設定を整理できます。そうしない場合、削除されたルール名は未使用のデータソースマッピングとして残ります。
AWS 環境外のルール更新の場合

受信者の AWS 環境では、Audit Manager はルールの更新を検出しません。これは、送信者と受信者がそれぞれ別々の AWS 環境で作業するためです。次の表は、このシナリオの推奨アクションを示しています。

役割 シナリオ 推奨されるアクション

送信者

  • カスタムルールをデータソースマッピングとして使用するフレームワークを共有しました。

  • フレームワークを共有した後、 でこれらのルールのいずれかを更新または削除しました AWS Config。

 受信者に連絡して、更新について知らせてください。そうすれば、受信者は同じ更新を行い、最新のルール定義と同期した状態を保つことができます。
受取人

  • カスタムルールをデータソースマッピングとして使用する共有フレームワークを受け入れました。

  • のインスタンスでカスタムルールを再作成すると AWS Config、送信者はそれらのルールの 1 つを更新または削除します。

 AWS Configのインスタンスで、対応するルールを更新してください。