Cette page explique comment migrer vos règles de désactivation statiques existantes vers des règles de désactivation dynamiques.
Nous vous recommandons d'utiliser exclusivement des règles Ignorer dynamiques dans vos configurations de règles Ignorer, car elles sont plus flexibles que les règles Ignorer statiques. Par rapport aux règles Ignorer statiques, les règles Ignorer dynamiques présentent trois avantages clés :
- Les règles Ignorer dynamiques s'appliquent aux résultats existants et nouveaux. Les règles Ignorer dynamiques ignorent automatiquement les résultats existants, nouveaux ou mis à jour qui correspondent à vos critères de filtrage.
- Les règles Ignorer dynamiques proposent une option d'expiration. Les règles de blocage dynamiques vous permettent également de définir une période d'expiration personnalisée pour faire correspondre temporairement des résultats spécifiques. Si aucune période d'expiration n'est définie, les règles Ignorer dynamiques bloquent les résultats indéfiniment jusqu'à ce qu'ils ne correspondent plus à la règle.
Les règles Ignorer dynamiques réactivent automatiquement les résultats. Lorsque l'un des événements suivants se produit, Security Command Center réactive automatiquement le résultat :
- La règle Ignorer dynamique expire.
- Les propriétés d'un résultat changent et ne correspondent plus à vos critères de filtrage.
- Les critères de filtrage ne correspondent plus au résultat.
Nous vous déconseillons d'utiliser simultanément des règles Ignorer statiques et dynamiques. Les règles de désactivation statiques remplacent les règles de désactivation dynamiques lorsqu'elles sont appliquées à la même découverte. Par conséquent, les règles Ignorer dynamiques ne fonctionneront pas comme prévu, ce qui peut créer de la confusion lors de la gestion de vos résultats.
Si vous souhaitez utiliser exclusivement des règles de blocage dynamiques, les sections suivantes décrivent les autorisations et les étapes nécessaires pour migrer vos règles de blocage statiques.
Autorisations
Pour obtenir les autorisations nécessaires pour effectuer le processus de migration de la mise en sourdine dynamique, demandez à votre administrateur de vous accorder les rôles IAM suivants sur votre organisation Google Cloud , votre dossier ou votre projet :
- Lecteur administrateur du centre de sécurité (
roles/securitycenter.adminViewer) - Lecteur de paramètres du centre de sécurité (
roles/securitycenter.settingsViewer) - Lecteur des configurations de mise en sourdine du centre de sécurité (
roles/securitycenter.muteConfigsViewer) - Administrateur du centre de sécurité (
roles/securitycenter.admin) - Éditeur administrateur du centre de sécurité (
roles/securitycenter.adminEditor) - Éditeur de paramètres du centre de sécurité(
roles/securitycenter.settingsEditor) - Éditeur des configurations de mise en sourdine du centre de sécurité (
roles/securitycenter.muteConfigsEditor) - Éditeur de résultats du centre de sécurité (
roles/securitycenter.findingsEditor)
Pour en savoir plus sur l'attribution de rôles, consultez Gérer l'accès aux projets, aux dossiers et aux organisations.
Vous pouvez également obtenir les autorisations requises avec des rôles personnalisés ou d'autres rôles prédéfinis.
Migrer vers les règles Ignorer dynamiques
Pour utiliser exclusivement les règles de blocage dynamiques, procédez comme suit pour créer des règles de blocage dynamiques et vous assurer que les résultats bloqués existants le restent après la migration.
- Créez des règles de blocage dynamiques. Vous ne pouvez pas modifier le type d'une règle de blocage une fois qu'elle a été créée. Vous devez donc créer une règle de blocage dynamique pour chaque règle de blocage statique que vous souhaitez conserver. Le nom de chaque nouvelle règle de blocage dynamique doit être unique par rapport aux règles de blocage existantes. Security Command Center peut mettre quelques heures à appliquer les règles de blocage dynamiques aux résultats appropriés. Pour savoir comment créer une règle de blocage dynamique, consultez Créer une règle de blocage.
Validez l'état de mise en sourdine des résultats applicables. Pour vérifier que les règles de désactivation dynamique ont été appliquées correctement, vous pouvez utiliser l'attribut
muteInfodans l'API Security Command Center pour lister les résultats applicables et inspecter leurs champs de désactivation. Cela vous permet de déterminer si les résultats applicables utilisent des règles Ignorer dynamiques ou statiques.Par exemple, utilisez
muteInfo.dynamicMuteRecordsdans une requête pour lister les résultats applicables qui sont mis en sourdine par la nouvelle règle de mise en sourdine dynamique :contains(muteInfo.dynamicMuteRecords, muteConfig = "organizations/123/muteConfigs/my-dynamic-rule")Pour savoir comment lister les résultats, consultez Lister les résultats de sécurité à l'aide de l'API Security Command Center.
Supprimez toutes les règles de blocage statiques. Les futurs résultats applicables sont couverts par les nouvelles règles dynamiques que vous avez créées. Supprimez toutes vos règles Ignorer statiques existantes pour vous assurer qu'elles ne remplacent pas les nouvelles règles Ignorer dynamiques pour les nouveaux résultats. Pour savoir comment supprimer une règle Ignorer, consultez Supprimer des règles Ignorer. La suppression des règles Ignorer statiques ne modifie pas l'état Ignorer statique des résultats existants.
Réinitialisez l'état de désactivation statique de tous les résultats. Pour réinitialiser l'état de désactivation statique des résultats existants de manière groupée, effectuez l'une des actions suivantes :
Utilisez la commande
gcloud scc findings bulk-muteou la méthode d'APIbulkMuteavec l'attributmuteStatedéfini surUNDEFINED. Pour le flag--filterou le champfilter, utilisez un filtre de résultats qui correspond aux résultats qui ont été mis en sourdine par la règle Ignorer statique que vous avez supprimée.L'exemple suivant utilise la commande
gcloud scc findings bulk-mute. Si vous avez supprimé une règle Ignorer statique avec le filtrecategory="OPEN_SSH_PORT", vous pouvez réinitialiser l'état "Ignorer" des résultats correspondant à ce filtre en exécutant la commande suivante :gcloud scc findings bulk-mute --organization=ORGANIZATION_ID --filter="category=\"OPEN_SSH_PORT\"" --mute-state=UNDEFINEDRemplacez
ORGANIZATION_IDpar l'ID de votre organisation. Vous pouvez remplacer--organizationpar--projectou--folder, selon le champ d'application des résultats que vous devez réinitialiser.Pour savoir comment effectuer des opérations de désactivation groupées, consultez Désactiver ou réinitialiser plusieurs résultats existants.
Si l'opération de désactivation groupée expire, effacez l'état de désactivation statique de tous les résultats. Pour ce faire, mettez à jour votre filtre de désactivation groupée afin d'utiliser des filtres moins précis qui couvrent tous les résultats pertinents.
Prenons l'exemple suivant de filtre dans une règle de mise en sourdine statique :
filter: "category = \"OPEN_SSH_PORT\" AND (resource.parentDisplayName = \"organizations/123\" OR resource.parentDisplayName = \"folder/456\")"Pour annuler l'état de mise en sourdine de tous les résultats correspondant aux critères de ce filtre de règle Ignorer statique, vous pouvez modifier le filtre en supprimant les conditions supplémentaires qui suivent la catégorie de résultat. Dans cet exemple, le résultat serait le suivant :
filter: "category = \"OPEN_SSH_PORT""Si vous avez défini manuellement l'état "Ignorer" pour certains résultats, cette méthode peut également réinitialiser l'état "Ignorer" de ces résultats.
Pour en savoir plus sur la mise à jour d'une règle Ignorer, consultez Mettre à jour des règles Ignorer.
Si vous avez besoin d'aide pour migrer vos règles Ignorer statiques vers des règles Ignorer dynamiques, contactez l'assistance.
Étapes suivantes
Découvrez comment créer et gérer des règles de mise en sourdine.