이 페이지에서는 기존 정적 숨기기 규칙을 동적 숨기기 규칙으로 마이그레이션하는 방법을 설명합니다.
동적 숨기기 규칙은 정적 숨기기 규칙보다 유연하므로 숨기기 규칙 구성에서만 사용하는 것이 좋습니다. 정적 숨기기 규칙에 비해 동적 숨기기 규칙에는 다음과 같은 세 가지 주요 이점이 있습니다.
동적 숨기기 규칙에는 기존 및 새 발견 항목에 적용됩니다. 동적 숨기기 규칙은 필터 기준과 일치하는 기존 발견 항목과 새 발견 항목 또는 업데이트된 발견 항목을 모두 자동으로 숨깁니다.
동적 숨기기 규칙에는 만료 옵션이 제공됩니다. 동적 숨기기 규칙을 사용하면 특정 발견 항목과 일시적으로 일치하도록 커스텀 만료 기간을 설정할 수도 있습니다. 만료 기간이 설정되지 않은 경우 동적 숨기기 규칙은 발견 항목이 더 이상 규칙과 일치하지 않을 때까지 무기한으로 숨깁니다.
동적 숨기기 규칙은 자동으로 발견 항목을 숨기기 취소합니다. 다음 중 하나라도 발생하면 Security Command Center가 발견 항목을 자동으로 숨기기 취소합니다.
동적 숨기기 규칙이 만료됩니다.
발견 항목의 속성이 더 이상 필터 기준과 일치하지 않도록 변경됩니다.
필터 기준이 더 이상 발견 항목과 일치하지 않도록 변경됩니다.
정적 숨기기 규칙과 동적 숨기기 규칙을 동시에 사용하지 않는 것이 좋습니다. 동일한 발견 항목에 적용되는 경우 정적 숨기기 규칙이 동적 숨기기 규칙보다 우선 적용됩니다. 따라서 동적 숨기기 규칙이 의도한 대로 작동하지 않아 발견 항목을 관리할 때 혼란이 발생할 수 있습니다.
동적 숨기기 규칙만 사용하려는 경우 다음 섹션에서는 정적 숨기기 규칙을 마이그레이션하는 데 필요한 권한과 단계에 대해 설명합니다.
권한
동적 숨기기 마이그레이션 프로세스를 수행하는 데 필요한 권한을 얻으려면 관리자에게 Google Cloud 조직, 폴더 또는 프로젝트에 대한 다음 IAM 역할을 부여해 달라고 요청하세요.
동적 숨기기 규칙만 사용하려면 다음 단계를 완료하여 동적 숨기기 규칙을 만들고 마이그레이션 후에도 기존 숨겨진 발견 항목이 숨겨진 상태로 유지되도록 합니다.
새 동적 숨기기 규칙을 만듭니다. 숨기기 규칙 유형이 생성된 후에는 해당 유형을 수정할 수 없습니다. 따라서 유지하려는 각 정적 숨기기 규칙에 대해 하나의 동적 숨기기 규칙을 만들어야 합니다. 새 동적 숨기기 규칙 이름은 기존 숨기기 규칙과 달라야 합니다. Security Command Center에서 동적 숨기기 규칙을 적절한 발견 항목에 적용하는 데 몇 시간이 걸릴 수 있습니다. 동적 숨기기 규칙을 만드는 방법에 관한 안내는 숨기기 규칙 만들기를 참조하세요.
해당하는 발견 항목의 숨기기 상태를 확인합니다. 동적 숨기기 규칙이 적절하게 적용되었는지 검증하려면 Security Command Center API에서 muteInfo 속성을 사용해서 적용 가능한 발견 항목을 나열하고 해당 숨기기 필드를 검사할 수 있습니다. 적용 가능한 발견 항목에 동적 또는 정적 숨기기 규칙이 사용되는지 여부를 확인하는 데 도움이 됩니다.
예를 들어 쿼리에서 muteInfo.dynamicMuteRecords를 사용하여 새 동적 숨기기 규칙에 의해 숨기기된 관련 발견 항목을 나열할 수 있습니다.
모든 정적 숨기기 규칙을 삭제합니다. 해당하는 이후의 발견 항목에는 새로 만든 동적 규칙이 적용됩니다. 기존의 정적 숨기기 규칙을 모두 삭제하여 새 발견 항목에 대한 새 동적 숨기기 규칙이 재정의되지 않도록 합니다.
숨기기 규칙을 삭제하는 방법에 관한 안내는 숨기기 규칙 삭제를 참조하세요.
정적 숨기기 규칙을 삭제해도 기존 발견 항목의 정적 숨기기 상태는 변경되지 않습니다.
모든 발견 항목에서 정적 숨기기 상태를 재설정합니다. 기존 발견 항목의 정적 숨기기 상태를 일괄적으로 재설정하려면 다음 작업 중 하나를 실행합니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-06-17(UTC)"],[],[],null,["| Standard, Premium, and Enterprise [service tiers](/security-command-center/docs/service-tiers)\n\nThis page explains how to migrate your existing static mute rules to dynamic\nmute rules.\n\nWe recommend using dynamic mute rules exclusively in your mute rule\nconfigurations because they are more flexible than static mute rules. Compared\nto static mute rules, dynamic mute rules have three key benefits:\n\n- **Dynamic mute rules apply to existing and new findings**. Dynamic mute rules automatically mute both existing and new or updated findings that match your filter criteria.\n- **Dynamic mute rules offer an expiration option**. Dynamic mute rules also allow you to set a custom expiration period to temporarily match specific findings. If no expiration period is set, dynamic mute rules mute findings indefinitely until they no longer match the rule.\n- **Dynamic mute rules automatically unmute findings**. When any of the\n following occurs, Security Command Center automatically unmutes the finding:\n\n - The dynamic mute rule expires.\n - The properties of a finding change to no longer match your filter criteria.\n - The filter criteria change to no longer match the finding.\n\nWe don't recommend using static and dynamic mute rules simultaneously. Static\nmute rules override dynamic mute rules when they are applied to the same\nfinding. As a result, dynamic mute rules won't work as intended, which can\ncreate confusion when managing your findings.\n\nIf you want to use dynamic mute rules exclusively, the following sections\ndescribe the permissions and steps necessary migrate your static mute rules.\n\nPermissions\n\n\nTo get the permissions that\nyou need to perform the dynamic mute migration process,\n\nask your administrator to grant you the\nfollowing IAM roles on your Google Cloud organization, folder, or project:\n\n- [Security Center Admin Viewer](/iam/docs/roles-permissions/securitycenter#securitycenter.adminViewer) (`roles/securitycenter.adminViewer`)\n- [Security Center Settings Viewer](/iam/docs/roles-permissions/securitycenter#securitycenter.settingsViewer) (`roles/securitycenter.settingsViewer`)\n- [SecurityCenter Mute Configurations Viewer](/iam/docs/roles-permissions/securitycenter#securitycenter.muteConfigsViewer) (`roles/securitycenter.muteConfigsViewer`)\n- [Security Center Admin](/iam/docs/roles-permissions/securitycenter#securitycenter.admin) (`roles/securitycenter.admin`)\n- [Security Center AdminEditor](/iam/docs/roles-permissions/securitycenter#securitycenter.adminEditor) (`roles/securitycenter.adminEditor`)\n- Security Center Settings Editor(`roles/securitycenter.settingsEditor`)\n- [Security Center Mute ConfigurationsEditor](/iam/docs/roles-permissions/securitycenter#securitycenter.muteConfigsEditor) (`roles/securitycenter.muteConfigsEditor`)\n- [Security Center FindingsEditor](/iam/docs/roles-permissions/securitycenter#securitycenter.findingsEditor) (`roles/securitycenter.findingsEditor`)\n\n\nFor more information about granting roles, see [Manage access to projects, folders, and organizations](/iam/docs/granting-changing-revoking-access).\n\n\nYou might also be able to get\nthe required permissions through [custom\nroles](/iam/docs/creating-custom-roles) or other [predefined\nroles](/iam/docs/roles-overview#predefined).\n\nMigrate to dynamic mute rules\n\nTo use dynamic mute rules exclusively, complete the following steps to create\ndynamic mute rules and ensure existing muted findings remain muted after\nmigration.\n\n1. **Create new dynamic mute rules** . You can't modify a mute rule's type after it has been created. Therefore, you must create one dynamic mute rule for each static mute rule you want to retain. Each new dynamic mute rule name must be unique from the existing mute rules. Security Command Center might take a few hours to apply the dynamic mute rules to the appropriate findings. For instructions on how to create a dynamic mute rule, see [Create a mute\n rule](/security-command-center/docs/how-to-mute-findings#create_a_mute_rule).\n2. **Validate the mute state of applicable findings** . To validate that the\n dynamic mute rules have been applied appropriately, you can use the\n `muteInfo` attribute in the Security Command Center API to list the applicable\n findings and inspect their mute fields. This helps you to determine whether\n the applicable findings are using dynamic or static mute rules.\n\n For example, use `muteInfo.dynamicMuteRecords` in a query to list the\n applicable findings that are being muted by the new dynamic mute rule: \n\n contains(muteInfo.dynamicMuteRecords, muteConfig =\n \"organizations/123/muteConfigs/my-dynamic-rule\")\n\n For more information on how to list\n findings, see [Listing security findings using the Security Command Center\n API](/security-command-center/docs/how-to-api-list-findings).\n3. **Delete all static mute rules** . Applicable future findings are covered by\n the new dynamic rules you created. Delete all your existing static mute rules\n to ensure they won't override the new dynamic mute rules for new findings.\n For instructions on how to delete a mute rule, see [Delete mute\n rules](/security-command-center/docs/how-to-mute-findings#delete_mute_rules).\n Deleting static mute rules does not change the static mute state of existing\n findings.\n\n4. **Reset the static mute state on all findings**. To reset the\n static mute state of existing findings in bulk, perform one of the following\n actions:\n\n - Use either the [`gcloud scc findings\n bulk-mute`](/sdk/gcloud/reference/scc/findings/bulk-mute) command or the\n `bulkMute` API method with the `muteState` attribute set to `UNDEFINED`. Do\n this for each static mute rule that you deleted. For instructions on how to\n perform bulk mute operations, see [Mute or reset multiple existing findings](/security-command-center/docs/how-to-mute-findings#bulk_mute_findings).\n\n - If the bulk mute operation times out, you can clear the static mute\n state from all findings by updating your bulk mute filter to use less\n granular filters that cover all the relevant findings you need to update.\n\n Consider the following example of a filter in a static mute rule: \n\n filter: \"category = \\\"OPEN_SSH_PORT\\\" AND\n (resource.parentDisplayName = \\\"organizations/123\\\"\n OR resource.parentDisplayName = \\\"folder/456\")\"\n\n To clear the mute state on all findings that match the criteria of this\n static mute rule filter, you can modify the filter by removing the\n additional conditions that follow the finding category. For this example,\n the result would be as follows: \n\n filter: \"category = \\\"OPEN_SSH_PORT\"\"\n\n If you have manually set the mute state for any findings, this method\n might also reset the mute state of those findings.\n\n For more information on updating a mute rule, see [Update mute\n rules](/security-command-center/docs/how-to-mute-findings#update_mute_rules).\n\nIf you need help migrating your static mute rules to dynamic mute rules, contact\n[support](/security-command-center/docs/getting-support).\n\nWhat's next\n\nLearn more about [creating and managing mute rules](/security-command-center/docs/how-to-mute-findings#create_mute_rules)."]]
