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

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

一般的なフレームワークの問題

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

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

フレームワークの共有の問題

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

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

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

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

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

更新されたコントロール定義が使用可能というメッセージが表示された場合は、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 個のカスタムコントロールと、ACSC Essential Eight 標準フレームワークの 8 個の標準コントロールを追加しました。

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

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

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

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

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

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

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

5. [コントロールセットの編集] ページで、各コントロールセットの名前を確認して、そのコントロールのいずれかに代替が使用可能かどうかを確認します。

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

   ヒント

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

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

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

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

   2. 先ほど削除したコントロールの代替を見つけます。

      ヒント

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

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

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

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

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

10. [Next (次へ)] を選択します。

11. [レビューと保存] ページで [変更を保存] を選択します。

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

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

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

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

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

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

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

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

4. Audit Manager データを暗号化するためにカスタマーマネージドキーを使用する場合は、KMS キーが有効になっていることを確認します。KMS キーが無効になっているときにカスタムフレームワークを共有しようとすると、操作は失敗します。無効になっている KMS キーを有効にする手順については、AWS Key Management Service 開発者ガイドのキーの有効化と無効化を参照してください。

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

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

送信者向けの青いドットの通知

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

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

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

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

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

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

   

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

   

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

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

   

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

受信者向けの青いドットの通知

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

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

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

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

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

   

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

   

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のインスタンスで、対応するルールを更新してください。