このページでは、既存の静的ミュートルールを動的ミュートルールに移行する方法について説明します。
動的ミュートルールは静的ミュートルールよりも柔軟性が高いため、ミュートルール構成では動的ミュートルールのみを使用することをおすすめします。静的ミュートルールと比較して、動的ミュートルールには主に次の 3 つメリットがあります。
- 動的ミュートルールは、既存の検出結果と新しい検出結果に適用されます。動的ミュートルールでは、フィルタ条件に一致する既存の検出結果と新しい検出結果の両方、または更新された検出結果が自動的にミュートされます。
- 動的ミュートルールには有効期限オプションがあります。動的ミュートルールでは、カスタムの有効期限を設定して、特定の検出結果を一時的に照合することもできます。有効期限が設定されていない場合、動的ミュートルールは、検出結果がルールと一致しなくなるまで無期限にミュートします。
動的ミュートルールは検出結果のミュートを自動的に解除します。次のいずれかが発生すると、Security Command Center は検出結果のミュートを自動的に解除します。
- 動的ミュートルールが期限切れになる。
- 検出結果のプロパティが変更されて、フィルタ条件と一致しなくなる。
- フィルタ条件が変更されて、検出結果と一致しなくなる。
静的ミュートルールと動的ミュートルールを同時に使用することはおすすめしません。同じ検出結果に適用されると、静的ミュートルールは動的ミュートルールをオーバーライドします。その結果、動的ミュートルールが意図したとおりに機能せず、検出結果の管理時に混乱が生じる可能性があります。
動的ミュートルールのみを使用する場合は、次のセクションをご覧ください。静的ミュートルールを移行するために必要な権限と手順について説明します。
権限
動的ミュート移行プロセスを実行するために必要な権限を取得するには、 Google Cloud 組織、フォルダ、プロジェクトに対する次の IAM ロールを付与するよう管理者に依頼します。
- セキュリティ センター管理閲覧者(
roles/securitycenter.adminViewer
) - セキュリティ センター設定の閲覧者(
roles/securitycenter.settingsViewer
) - セキュリティ センターのミュート構成閲覧者(
roles/securitycenter.muteConfigsViewer
) - セキュリティ センター管理者(
roles/securitycenter.admin
) - セキュリティ センター管理者編集者(
roles/securitycenter.adminEditor
) - セキュリティ センター設定の編集者(
roles/securitycenter.settingsEditor
) - セキュリティ センターのミュート構成編集者(
roles/securitycenter.muteConfigsEditor
) - セキュリティ センターの検出編集者(
roles/securitycenter.findingsEditor
)
ロールの付与については、プロジェクト、フォルダ、組織へのアクセス権の管理をご覧ください。
必要な権限は、カスタムロールや他の事前定義ロールから取得することもできます。
動的ミュートルールに移行する
動的ミュートルールのみを使用するには、次の手順で動的ミュートルールを作成し、移行後に既存のミュートされた検出結果がミュートされたままになるようにします。
- 新しい動的ミュートルールを作成します。作成後にミュートルールのタイプを変更することはできません。したがって、保持する静的ミュートルールごとに 1 つの動的ミュートルールを作成する必要があります。新しい動的ミュートルールの名前は、既存のミュートルールと重複しないようにする必要があります。Security Command Center が適切な検出結果に動的ミュートルールを適用するまでに数時間かかることがあります。動的ミュートルールの作成方法の手順については、ミュートルールを作成するをご覧ください。
該当する検出結果のミュート状態を検証します。動的ミュートルールが適切に適用されていることを確認するには、Security Command Center API の
muteInfo
属性を使用して、該当する検出結果を一覧表示し、ミュート フィールドを検査します。これにより、該当する検出結果で動的ミュートルールと静的ミュートルールのどちらが使用されているかを判断できます。たとえば、クエリで
muteInfo.dynamicMuteRecords
を使用して、新しい動的ミュートルールによってミュートされている該当する検出結果を一覧表示します。contains(muteInfo.dynamicMuteRecords, muteConfig = "organizations/123/muteConfigs/my-dynamic-rule")
検出結果を一覧表示する方法の詳細については、Security Command Center API を使用してセキュリティの検出結果を一覧表示するをご覧ください。
すべての静的ミュートルールを削除します。適用可能な今後の検出結果は、作成した新しい動的ルールでカバーされます。既存の静的ミュートルールをすべて削除して、新しい検出結果の新しい動的ミュートルールがオーバーライドされないようにします。ミュートルールを削除する手順については、ミュートルールを削除するをご覧ください。静的ミュートルールを削除しても、既存の検出結果の静的ミュート状態は変更されません。
すべての検出結果の静的ミュート状態をリセットします。既存の検出結果の静的ミュート状態を一括でリセットするには、次のいずれかの操作を行います。
UNDEFINED
に設定したmuteState
属性で、gcloud scc findings bulk-mute
コマンドまたはbulkMute
API メソッドを使用します。削除した静的ミュートルールごとにこの操作を実行します。一括ミュート オペレーションを行う方法の手順については、複数の既存の検出結果をミュートまたはリセットするをご覧ください。一括ミュート オペレーションがタイムアウトした場合は、一括ミュート フィルタを更新して、より粒度が粗い(更新が必要な関連するすべての検出結果を対象とする)フィルタを使用することで、すべての検出結果から静的ミュート状態を消去できます。
静的ミュートルールのフィルタの次の例を検討します。
filter: "category = \"OPEN_SSH_PORT\" AND (resource.parentDisplayName = \"organizations/123\" OR resource.parentDisplayName = \"folder/456")"
この静的ミュートルール フィルタの条件に一致するすべての検出結果のミュート状態をクリアするには、検出結果のカテゴリの後に続く追加の条件を削除して、フィルタを変更します。この例の場合、結果は次のようになります。
filter: "category = \"OPEN_SSH_PORT""
検出結果のミュート状態を手動で設定した場合、この方法では、検出結果のミュート状態もリセットされる場合があります。
ミュートルールの更新の詳細については、ミュートルールを更新するをご覧ください。
静的ミュートルールから動的ミュートルールへの移行についてサポートが必要な場合は、サポートにお問い合わせください。
次のステップ
ミュートルールの作成と管理の詳細を確認する。