Corriger les résultats de Security Health Analytics

Cette page fournit une liste de guides de référence et de techniques permettant de corriger les résultats de Security Health Analytics à l'aide de Security Command Center.

Vous devez disposer des rôles IAM (Identity and Access Management) appropriés pour afficher ou modifier les résultats, et pour accéder aux ressources Google Cloud ou les modifier. Si vous rencontrez des erreurs d'autorisation lorsque vous accédez à Security Command Center dans la consoleGoogle Cloud , demandez de l'aide à votre administrateur. Pour en savoir plus sur les rôles, consultez Contrôle des accès. Pour résoudre les erreurs de ressources, consultez la documentation des produits concernés.

Correction de Security Health Analytics

Cette section inclut des instructions correctives pour tous les résultats d'analyses de l'état de sécurité.

Pour les types de résultats mappés aux benchmarks CIS, les conseils de correction proviennent du Center for Internet Security (CIS), sauf indication contraire. Pour en savoir plus, consultez Détecteurs et conformité.

Désactivation automatique des résultats

Une fois que vous avez corrigé une faille ou une erreur de configuration, Security Health Analytics définit automatiquement l'état du résultat sur INACTIVE lors de la prochaine analyse. Si vous désactivez un détecteur dans Security Health Analytics, l'état de tous les résultats générés par ce détecteur est défini sur INACTIVE. Le temps nécessaire à Security Health Analytics pour définir un résultat corrigé sur INACTIVE dépend du moment où le résultat est corrigé et du calendrier de l'analyse qui le détecte.

Security Health Analytics définit également l'état d'un résultat sur INACTIVE lorsqu'une analyse détecte que la ressource concernée par le résultat a été supprimée. Si vous souhaitez supprimer un résultat pour une ressource supprimée de votre affichage en attendant que Security Health Analytics détecte que la ressource a été supprimée, vous pouvez le désactiver. Pour masquer un résultat, consultez Masquer des résultats dans Security Command Center.

N'utilisez pas la fonctionnalité de mise en sourdine pour masquer les résultats corrigés des ressources existantes. Si le problème se reproduit et que Security Health Analytics restaure l'état ACTIVE du résultat, il est possible que vous ne voyiez pas le résultat réactivé, car les résultats mis en sourdine sont exclus de toute requête de résultat spécifiant NOT mute="MUTED", comme la requête de résultat par défaut.

Pour en savoir plus sur les intervalles d'analyse, consultez Types d'analyse Security Health Analytics.

Access Transparency disabled

Nom de la catégorie dans l'API : ACCESS_TRANSPARENCY_DISABLED

Les journaux Access Transparency enregistrent les actions des employés Google Cloud lorsqu'ils accèdent aux projets de votre organisation pour vous fournir une assistance. Activez Access Transparency pour enregistrer qui, au sein de Google Cloud , accède à vos informations, quand et pourquoi. Pour en savoir plus, consultez Access Transparency.

Pour activer Access Transparency sur un projet, celui-ci doit être associé à un compte de facturation.

Rôles requis

Pour obtenir les autorisations nécessaires pour effectuer cette tâche, demandez à votre administrateur de vous accorder le rôle IAM Administrateur de transparence des accès (roles/axt.admin) au niveau de l'organisation. Pour en savoir plus sur l'attribution de rôles, consultez la section Gérer les accès.

Ce rôle prédéfini contient les autorisations axt.labels.get et axt.labels.set, qui sont nécessaires pour effectuer cette tâche. Vous pouvez également obtenir ces autorisations avec un rôle personnalisé ou d'autres rôles prédéfinis.

Étapes de résolution

Pour corriger ce résultat, procédez comme suit :

1. Vérifiez les autorisations au niveau de votre organisation :

   1. Accédez à la page Identity and Access Management de la consoleGoogle Cloud .

      Accéder à Identity and Access Management

   2. Si vous y êtes invité, sélectionnez l'organisation Google Cloud dans le menu de sélection.

2. Sélectionnez un projet Google Cloud au sein de l'organisation à l'aide du menu de sélection.

   La fonctionnalité Access Transparency est configurée sur une page de Google Cloud projet, mais elle est activée pour l'ensemble de l'organisation.

3. Accédez à la page IAM et administration > Paramètres.

4. Cliquez sur Activer Access Transparency.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

AlloyDB auto backup disabled

Nom de la catégorie dans l'API : ALLOYDB_AUTO_BACKUP_DISABLED

Les sauvegardes automatiques ne sont pas activées pour un cluster AlloyDB pour PostgreSQL.

Afin d'éviter de perdre des données, activez les sauvegardes automatiques pour votre cluster. Pour en savoir plus, consultez Configurer des sauvegardes automatiques supplémentaires.

Pour corriger ce résultat, procédez comme suit :

1. Accédez à la page des clusters AlloyDB pour PostgreSQL dans la consoleGoogle Cloud .

   Accéder aux clusters AlloyDB pour PostgreSQL

2. Cliquez sur un cluster dans la colonne Nom de la ressource.

3. Cliquez sur Protection des données.

4. Sous la section Règle de sauvegarde automatique, cliquez sur Modifier à la ligne Sauvegardes automatiques.

5. Cochez la case Automatiser les sauvegardes.

6. Cliquez sur Mettre à jour.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

AlloyDB backups disabled

Nom de la catégorie dans l'API : ALLOYDB_BACKUPS_DISABLED

Les sauvegardes automatiques et continues ne sont pas activées pour un cluster AlloyDB pour PostgreSQL.

Afin d'éviter de perdre des données, activez les sauvegardes automatiques ou continues pour votre cluster. Pour en savoir plus, consultez Configurer des sauvegardes supplémentaires.

Pour corriger ce résultat, procédez comme suit :

1. Accédez à la page des clusters AlloyDB pour PostgreSQL dans la consoleGoogle Cloud .

   Accéder aux clusters AlloyDB pour PostgreSQL

2. Dans la colonne Nom de la ressource, cliquez sur le nom du cluster identifié dans le résultat.

3. Cliquez sur Protection des données.

4. Configurez une stratégie de sauvegarde.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

AlloyDB CMEK disabled

Nom de la catégorie dans l'API : ALLOYDB_CMEK_DISABLED

Un cluster AlloyDB n'utilise pas de clés de chiffrement gérées par le client (CMEK).

Avec CMEK, les clés que vous créez et gérez dans Cloud KMS encapsulent les clés que Google utilise pour chiffrer vos données, vous permettant ainsi de mieux contrôler vos accès. Pour en savoir plus, consultez À propos de CMEK. CMEK entraîne des coûts supplémentaires liés à Cloud KMS.

Pour corriger ce résultat, procédez comme suit :

1. Accédez à la page des clusters AlloyDB pour PostgreSQL dans la consoleGoogle Cloud .

   Accéder aux clusters AlloyDB pour PostgreSQL

2. Dans la colonne Nom de la ressource, cliquez sur le nom du cluster identifié dans le résultat.

3. Cliquez sur Créer une sauvegarde. Définissez un ID de secours.

4. Cliquez sur Créer.

5. Dans la section Sauvegarder/Restaurer, cliquez sur Restaurer à côté de l'entrée ID de sauvegarde de votre choix.

6. Définissez un nouvel ID de cluster et un nouveau réseau.

7. Cliquez sur Options de chiffrement avancées. Sélectionnez la clé CMEK avec laquelle vous souhaitez chiffrer le nouveau cluster.

8. Cliquez sur Restaurer.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

AlloyDB log min error statement severity

Nom de la catégorie dans l'API : ALLOYDB_LOG_MIN_ERROR_STATEMENT_SEVERITY

L'option de base de données log_min_error_statement n'est pas définie sur error ni sur une autre valeur recommandée pour une instance AlloyDB pour PostgreSQL.

L'option log_min_error_statement détermine si les instructions SQL provoquant des conditions d'erreur sont enregistrées dans les journaux du serveur. Les instructions SQL présentant un niveau de gravité supérieur ou égal à celui spécifié sont consignées. Plus le niveau de gravité est élevé, moins le nombre de messages enregistrés est important. Si elle est définie sur un niveau de gravité trop élevé, il se peut que les messages d'erreur ne soient pas consignés.

Pour en savoir plus, consultez la page Configurer des indicateurs de base de données.

Pour corriger ce résultat, procédez comme suit :

1. Accédez à la page des clusters AlloyDB pour PostgreSQL dans la consoleGoogle Cloud .

   Accéder aux clusters AlloyDB pour PostgreSQL

2. Cliquez sur le cluster dans la colonne Nom de la ressource.

3. Dans la section Instances de votre cluster, cliquez sur Modifier pour l'instance.

4. Cliquez sur Options de configuration avancées.

5. Dans la section Options, définissez l'option de base de données log_min_error_statement sur l'une des valeurs recommandées suivantes, en fonction de la stratégie de journalisation de votre organisation.

   • debug5
   • debug4
   • debug3
   • debug2
   • debug1
   • info
   • notice
   • warning
   • error

6. Cliquez sur Mettre à jour l'instance.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

AlloyDB log min messages

Nom de la catégorie dans l'API : ALLOYDB_LOG_MIN_MESSAGES

L'option de base de données log_min_messages d'une instance AlloyDB pour PostgreSQL n'est pas définie sur warning au minimum.

L'option log_min_messages contrôle les niveaux de message enregistrés dans les journaux du serveur. Plus le niveau de gravité est élevé, moins le nombre de messages enregistrés est important. Si vous définissez un seuil trop bas, la taille et la longueur des journaux stockés peuvent augmenter, ce qui risque de compliquer la recherche d'erreurs réelles.

Pour en savoir plus, consultez la page Configurer des indicateurs de base de données.

Pour corriger ce résultat, procédez comme suit :

1. Accédez à la page des clusters AlloyDB pour PostgreSQL dans la consoleGoogle Cloud .

   Accéder aux clusters AlloyDB pour PostgreSQL

2. Cliquez sur le cluster dans la colonne Nom de la ressource.

3. Dans la section Instances de votre cluster, cliquez sur Modifier pour l'instance.

4. Cliquez sur Options de configuration avancées.

5. Dans la section Options, définissez l'option de base de données log_min_messages sur l'une des valeurs recommandées suivantes, en fonction de la stratégie de journalisation de votre organisation.

   • debug5
   • debug4
   • debug3
   • debug2
   • debug1
   • info
   • notice
   • warning

6. Cliquez sur Mettre à jour l'instance.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

AlloyDB log error verbosity

Nom de la catégorie dans l'API : ALLOYDB_LOG_ERROR_VERBOSITY

L'option de base de données log_error_verbosity d'une instance AlloyDB pour PostgreSQL n'est pas définie sur default ou une autre valeur moins restrictive.

L'option log_error_verbosity contrôle la quantité de détails des messages consignés. Plus la verbosité est élevée, plus les messages enregistrés contiennent de détails. Nous vous recommandons de définir cette option sur default ou sur une autre valeur moins restrictive.

Pour en savoir plus, consultez la page Configurer des indicateurs de base de données.

Pour corriger ce résultat, procédez comme suit :

1. Accédez à la page des clusters AlloyDB pour PostgreSQL dans la consoleGoogle Cloud .

   Accéder aux clusters AlloyDB pour PostgreSQL

2. Cliquez sur le cluster dans la colonne Nom de la ressource.

3. Dans la section Instances de votre cluster, cliquez sur Modifier pour l'instance.

4. Cliquez sur Options de configuration avancées.

5. Dans la section Options, définissez l'option de base de données log_error_verbosity sur l'une des valeurs recommandées suivantes, en fonction de la stratégie de journalisation de votre organisation.

   • default
   • verbose

6. Cliquez sur Mettre à jour l'instance.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

AlloyDB Public IP

Nom de la catégorie dans l'API : ALLOYDB_PUBLIC_IP

Une instance de base de données AlloyDB pour PostgreSQL possède une adresse IP publique.

Pour réduire la surface d'attaque de votre organisation, utilisez des adresses IP privées plutôt que publiques. Les adresses IP privées offrent une sécurité réseau améliorée et une latence réduite pour votre application.

Pour corriger ce résultat, procédez comme suit :

1. Accédez à la page des clusters AlloyDB pour PostgreSQL dans la consoleGoogle Cloud .

   Accéder aux clusters AlloyDB pour PostgreSQL

2. Dans la colonne Nom de la ressource, cliquez sur le nom du cluster identifié dans le résultat.

3. Dans la section Instances de votre cluster, cliquez sur Modifier pour l'instance.

4. Dans la section Connectivité, décochez la case Activer les adresses IP publiques.

5. Cliquez sur Mettre à jour l'instance.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

AlloyDB SSL not enforced

Nom de la catégorie dans l'API : ALLOYDB_SSL_NOT_ENFORCED

Une instance de base de données AlloyDB pour PostgreSQL ne nécessite pas que toutes les connexions entrantes utilisent SSL.

Pour éviter la fuite de données sensibles pendant leur transit via des communications non chiffrées, toutes les connexions entrantes à votre instance de base de données AlloyDB doivent utiliser le protocole SSL. Apprenez-en plus sur la configuration de SSL/TLS.

Pour corriger ce résultat, procédez comme suit :

1. Accédez à la page des clusters AlloyDB pour PostgreSQL dans la consoleGoogle Cloud .

   Accéder aux clusters AlloyDB pour PostgreSQL

2. Dans la colonne Nom de la ressource, cliquez sur le nom du cluster identifié dans le résultat.

3. Dans la section Instances de votre cluster, cliquez sur Modifier pour l'instance.

4. Sous la section Sécurité réseau, cochez la case Chiffrement SSL requis.

5. Cliquez sur Mettre à jour l'instance.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

Admin service account

Nom de la catégorie dans l'API : ADMIN_SERVICE_ACCOUNT

Un compte de service au sein de votre organisation ou de votre projet bénéficie des droits d'administrateur, de propriétaire ou d'éditeur. Ces rôles disposent d'autorisations étendues et ne doivent pas être attribués à des comptes de service. Pour en savoir plus sur les comptes de service et les rôles disponibles, consultez la page Comptes de service.

Pour corriger ce résultat, procédez comme suit :

1. Accédez à la page de la stratégie IAM de la console Google Cloud .

   Accéder à la stratégie IAM

2. Pour chaque compte principal identifié dans le résultat :

   1. Cliquez sur edit Modifier le compte principal à côté du compte principal.
   2. Pour supprimer des autorisations, cliquez sur delete Supprimer le rôle à côté du rôle.
   3. Cliquez sur Enregistrer.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

Alpha cluster enabled

Nom de la catégorie dans l'API : ALPHA_CLUSTER_ENABLED

Les fonctionnalités de cluster alpha sont activées pour un cluster Google Kubernetes Engine (GKE).

Les clusters alpha permettent aux utilisateurs de la première heure de tester des charges de travail exploitant de nouvelles fonctionnalités avant leur lancement public. Toutes les fonctionnalités de l'API GKE sont activées sur les clusters alpha, mais ceux-ci ne sont pas couverts par le contrat de niveau de service GKE. Ils ne reçoivent pas de mises à jour de sécurité. Les fonctionnalités de mise à niveau et de réparation automatiques des nœuds y sont désactivées, et ils ne peuvent pas être mis à niveau. Ils sont aussi automatiquement supprimés au bout de 30 jours.

Pour corriger ce résultat, procédez comme suit :

Les clusters alpha ne peuvent pas être désactivés. Vous devez créer un cluster avec les fonctionnalités alpha désactivées.

1. Accédez à la page Clusters Kubernetes de la console Google Cloud .

   Accéder à la page "Clusters Kubernetes"

2. Cliquez sur Create (Créer).

3. Sélectionnez Configurer à côté du type de cluster que vous souhaitez créer.

4. Sous l'onglet Fonctionnalités, assurez-vous que l'option Activer les fonctionnalités alpha Kubernetes dans ce cluster est désactivée.

5. Cliquez sur Create (Créer).

6. Pour déplacer des charges de travail vers le nouveau cluster, consultez la section Migrer des charges de travail vers différents types de machines.

7. Pour supprimer le cluster d'origine, consultez la section Supprimer un cluster.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

API key APIs unrestricted

Nom de la catégorie dans l'API : API_KEY_APIS_UNRESTRICTED

Certaines clés API sont utilisées à trop grande échelle.

Les clés API sans restriction ne sont pas sécurisées, car elles peuvent être récupérées à partir d'appareils sur lesquels elles sont stockées ou visibles publiquement, par exemple à partir d'un navigateur. Conformément au principe du moindre privilège, configurez les clés API pour n'appeler que les API requises par l'application. Pour en savoir plus, consultez Appliquer des restrictions de clé API.

Pour corriger ce résultat, procédez comme suit :

1. Accédez à la page Clés API dans la console Google Cloud .

   Accéder aux Clés API

2. Pour chaque clé API :

   1. Dans la section Clés API, sur la ligne correspondant à chaque clé API pour laquelle vous devez restreindre des API, cliquez sur more_vert Actions.
   2. Dans le menu Actions, cliquez sur Modifier la clé API. La page Modifier la clé API s'affiche.
   3. Dans la section Restrictions relatives aux API, sélectionnez Restreindre des API. Le menu déroulant Sélectionner des API s'affiche.
   4. Dans la liste déroulante Sélectionner des API, choisissez les API que vous souhaitez autoriser.
   5. Cliquez sur Enregistrer. L'application des paramètres peut prendre jusqu'à cinq minutes.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

API key apps unrestricted

Nom de la catégorie dans l'API : API_KEY_APPS_UNRESTRICTED

Des clés API sont utilisées de manière non restreinte, autorisant une utilisation par n'importe quelle application non approuvée.

Les clés API sans restriction ne sont pas sécurisées, car elles peuvent être récupérées sur des appareils qui les stockeront ou les rendront visibles au public, par exemple depuis un navigateur. Conformément au principe du moindre privilège, limitez l'utilisation des clés API aux hôtes, référents HTTP et applications de confiance. Pour en savoir plus, consultez Appliquer des restrictions de clé API.

Pour corriger ce résultat, procédez comme suit :

1. Accédez à la page Clés API dans la console Google Cloud .

   Accéder aux Clés API

2. Pour chaque clé API :

   1. Dans la section Clés API, sur la ligne correspondant à chaque clé API pour laquelle vous devez restreindre des applications, cliquez sur more_vert Actions.
   2. Dans le menu Actions, cliquez sur Modifier la clé API. La page Modifier la clé API s'affiche.
   3. Sur la page Modifier la clé API, sous Restrictions liées aux applications, sélectionnez une catégorie de restriction. Vous pouvez définir une restriction de ce type par clé.
   4. Dans le champ Ajouter un élément, qui s'affiche lorsque vous sélectionnez une restriction, cliquez sur Ajouter un élément pour ajouter des restrictions en fonction des besoins de votre application.
   5. Une fois les éléments ajoutés, cliquez sur Terminé.
   6. Cliquez sur Enregistrer.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

API key exists

Nom de la catégorie dans l'API : API_KEY_EXISTS

Un projet utilise des clés API au lieu de l'authentification standard.

Les clés API sont moins sécurisées que les autres méthodes d'authentification, car il s'agit de chaînes simples chiffrées qui peuvent être facilement découvertes et utilisées par d'autres utilisateurs. Elles peuvent être récupérées sur des appareils qui les stockeront ou les rendront visibles de tous, par exemple dans un navigateur. De plus, les clés API n'identifient pas de manière unique les utilisateurs ou les applications qui effectuent des requêtes. Vous pouvez également utiliser un flux d'authentification standard avec des comptes de service ou des comptes utilisateur.

Pour corriger ce résultat, procédez comme suit :

1. Assurez-vous que vos applications sont configurées avec une autre forme d'authentification.

2. Accédez à la page Identifiants de l'API dans la console Google Cloud .

   Accéder aux identifiants de l'API

3. Dans la section Clés API de la ligne correspondant à chaque clé API que vous souhaitez supprimer, cliquez sur more_vert Actions.

4. Dans le menu Actions, cliquez sur Supprimer la clé API.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

API key not rotated

Nom de la catégorie dans l'API : API_KEY_NOT_ROTATED

Une clé API n'a pas subi de rotation depuis plus de 90 jours.

Les clés API n'ont pas de date d'expiration. En cas de vol, la clé peut être utilisée indéfiniment, à moins que le propriétaire du projet ne décide de la révoquer ou d'alterner les clés. En renouvelant fréquemment vos clés API, vous réduisez la durée pendant laquelle une clé API volée pourrait être utilisée pour accéder à des données depuis un compte compromis ou résilié. Effectuez une rotation des clés API au moins tous les 90 jours. Pour en savoir plus, consultez la section Bonnes pratiques pour gérer les clés API.

Pour corriger ce résultat, procédez comme suit :

1. Accédez à la page Clés API dans la console Google Cloud .

   Accéder aux Clés API

2. Pour chaque clé API :

   1. Dans la section Clés API, sur la ligne correspondant à chaque clé API que vous souhaitez faire pivoter, cliquez sur more_vert Actions.
   2. Dans le menu Actions, cliquez sur Modifier la clé API. La page Modifier la clé API s'affiche.
   3. Sur la page Modifier la clé API, si la date figurant dans le champ Date de création date de plus de 90 jours, cliquez sur refresh Faire tourner la clé. Une clé est générée.
   4. Vous pouvez également modifier le nom de la clé API.
   5. Cliquez sur Créer.
   6. Mettez à jour vos applications afin qu'elles utilisent la nouvelle clé.
   7. Une fois vos applications mises à jour, revenez à la page Modifier la clé API et cliquez sur Supprimer la clé précédente pour supprimer l'ancienne clé. L'ancienne clé ne sera pas supprimée automatiquement.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

Audit config not monitored

Nom de la catégorie dans l'API : AUDIT_CONFIG_NOT_MONITORED

Les métriques et les alertes de journal ne sont pas configurées pour surveiller les modifications apportées à la configuration d'audit.

Cloud Audit Logging génère des journaux sur l'activité des administrateurs et les accès aux données, qui permettent d'effectuer des analyses de sécurité, le suivi des modifications des ressources et des audits de conformité. En surveillant les modifications apportées à la configuration d'audit, vous vous assurez que toutes les activités de votre projet peuvent être auditées à tout moment. Pour en savoir plus, consultez la présentation des métriques basées sur les journaux.

Selon la quantité d'informations, les coûts liés à Cloud Monitoring peuvent être importants. Pour comprendre votre utilisation du service et son coût, consultez les tarifs de Google Cloud Observability.

Pour les activations du niveau Premium de Security Command Center au niveau des projets, ce résultat n'est disponible que si le niveau Standard est activé dans l'organisation parente.

Pour corriger ce résultat, créez des métriques, si nécessaire, et des règles d'alerte :

Créer une métrique

1. Accédez à la page Métriques basées sur les journaux de la console Google Cloud .

   Accéder aux métriques basées sur les journaux

2. Cliquez sur Créer la métrique.

3. Sous Type de métrique, sélectionnez Compteur.

4. Sous Détails :

   1. Définissez un nom de métrique de journal.
   2. Ajoutez une description.
   3. Définissez le champ Unités sur 1.

5. Sous Sélection du filtre, copiez et collez le texte suivant dans la zone Créer un filtre, en remplaçant le texte existant si nécessaire :

     protoPayload.methodName="SetIamPolicy"
     AND protoPayload.serviceData.policyDelta.auditConfigDeltas:*

6. Cliquez sur Créer la métrique. Un message de confirmation s'affiche.

Créer une règle d'alerte

1. Dans la console Google Cloud , accédez à la page Métriques basées sur les journaux :

   Accéder à la page Métriques basées sur les journaux

   Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est Logging.

2. Sous la section Métriques définies par l'utilisateur, sélectionnez la métrique que vous avez créée dans la section précédente.

3. Cliquez sur Plus more_vert, puis sur Créer une alerte à partir de la métrique.

   La boîte de dialogue Nouvelle condition s'affiche, avec les options de métrique et de transformation de données préremplies.

4. Cliquez sur Suivant.
   1. Vérifiez les paramètres préremplis. Vous voudrez peut-être modifier le champ Valeur du seuil.
   2. Cliquez sur Nom de la condition, puis saisissez un nom pour la condition.
5. Cliquez sur Suivant.

6. Pour ajouter des notifications à votre règle d'alerte, cliquez sur Canaux de notification. Dans la boîte de dialogue, sélectionnez un ou plusieurs canaux de notification dans le menu, puis cliquez sur OK.

   Pour recevoir une notification en cas d'ouverture et de fermeture d'un incident, cochez la case Notifier en cas de fermeture des incidents. Par défaut, les notifications ne sont envoyées que lorsque des incidents sont ouverts.

7. (Facultatif) Mettez à jour la durée de fermeture automatique de l'incident. Ce champ détermine à quel moment Monitoring ferme les incidents en l'absence de données de métriques.
8. Facultatif : Cliquez sur Documentation, puis ajoutez les informations à inclure dans le message de notification.
9. Cliquez sur Nom de l'alerte et saisissez un nom pour la règle d'alerte.
10. Cliquez sur Créer une règle.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

Audit logging disabled

Nom de la catégorie dans l'API : AUDIT_LOGGING_DISABLED

Ce résultat n'est pas disponible pour les activations au niveau du projet.

La journalisation d'audit est désactivée pour un ou plusieurs services Google Cloud , ou un ou plusieurs comptes principaux sont exemptés de la journalisation d'audit de l'accès aux données.

Activez Cloud Logging pour tous les services afin de suivre l'ensemble des activités d'administration, ainsi que des accès en lecture et en écriture aux données utilisateur. Selon la quantité d'informations, les coûts liés à Cloud Logging peuvent être importants. Pour comprendre votre utilisation du service et son coût, consultez les tarifs de Google Cloud Observability.

Si des comptes principaux sont exemptés de la journalisation d'audit des accès aux données dans la configuration par défaut ou dans les configurations de journalisation de services individuels, supprimez l'exemption.

Pour corriger ce résultat, procédez comme suit :

1. Accédez à la page Configuration par défaut des journaux d'audit des accès aux données dans la consoleGoogle Cloud .

   Accéder à la configuration par défaut

2. Dans l'onglet Types de journaux, activez la journalisation des audits d'accès aux données dans la configuration par défaut :

   1. Sélectionnez Lecture administrateur, Lecture de données et Écriture de données.
   2. Cliquez sur Enregistrer.

3. Dans l'onglet Comptes principaux exemptés, supprimez tous les utilisateurs exemptés de la configuration par défaut :

   1. Supprimez chaque compte principal listé en cliquant sur delete Supprimer à côté de chaque nom.
   2. Cliquez sur Enregistrer.

4. Accédez à la page Journaux d'audit.

   Accéder aux journaux d'audit

5. Supprimez tous les comptes principaux exemptés des configurations de journaux d'audit des accès aux données des services individuels.

   1. Sous Configuration des journaux d'audit des accès aux données, cliquez sur chaque service pour lequel un compte principal exempté est affiché. Un panneau de configuration des journaux d'audit s'ouvre pour le service.
   2. Dans l'onglet Comptes principaux exemptés, supprimez tous les comptes principaux exemptés en cliquant sur delete Supprimer à côté de chaque nom.
   3. Cliquez sur Enregistrer.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

Auto backup disabled

Nom de la catégorie dans l'API : AUTO_BACKUP_DISABLED

Les sauvegardes automatiques ne sont pas activées pour une base de données Cloud SQL.

Pour éviter toute perte de données, activez les sauvegardes automatiques pour vos instances SQL. Pour plus d'informations, consultez la section Créer et gérer des sauvegardes à la demande et automatiques.

Pour corriger ce résultat, procédez comme suit :

1. Dans la console Google Cloud , accédez à la page Instances Cloud SQL.

   Accéder à la page "Instances"

2. Cliquez sur le nom de l'instance.

3. Cliquez sur Sauvegardes.

4. À côté de Paramètres, cliquez sur edit Modifier.

5. Cochez la case Sauvegardes quotidiennes automatiques.

6. Facultatif : Dans la zone Nombre de jours, saisissez le nombre de jours de sauvegarde que vous souhaitez conserver.

7. Facultatif : Dans la liste Intervalle de sauvegarde, sélectionnez l'intervalle de temps pendant lequel effectuer les sauvegardes.

8. Cliquez sur Enregistrer.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

Auto repair disabled

Nom de la catégorie dans l'API : AUTO_REPAIR_DISABLED

La fonctionnalité de réparation automatique d'un cluster Google Kubernetes Engine (GKE), qui permet de maintenir les nœuds dans un état sain et d'exécution, est désactivée.

Lorsque cette fonction est activée, GKE vérifie périodiquement l'état de chaque nœud de votre cluster. Si les vérifications d'état réalisées sur un nœud échouent de manière consécutive sur une période prolongée, GKE déclenche un processus de réparation pour ce nœud. Pour en savoir plus, consultez la section Réparer automatiquement des nœuds.

Pour corriger ce résultat, procédez comme suit :

1. Accédez à la page Clusters Kubernetes de la console Google Cloud .

   Accéder à la page "Clusters Kubernetes"

2. Cliquez sur l'onglet Nœuds.

3. Pour chaque pool de nœuds :

   1. Cliquez sur le nom du pool de nœuds pour accéder à sa page d'informations.
   2. Cliquez sur edit Modifier.
   3. Dans la section Gestion, sélectionnez Activer la réparation automatique.
   4. Cliquez sur Enregistrer.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

Auto upgrade disabled

Nom de la catégorie dans l'API : AUTO_UPGRADE_DISABLED

La fonctionnalité de mise à niveau automatique des clusters GKE, qui conserve les clusters et les pools de nœuds sur la dernière version stable de Kubernetes, est désactivée.

Pour en savoir plus, consultez la page Mettre à niveau automatiquement des nœuds.

Pour corriger ce résultat, procédez comme suit :

1. Accédez à la page Clusters Kubernetes de la console Google Cloud .

   Accéder à la page "Clusters Kubernetes"

2. Dans la liste des clusters, cliquez sur le nom du cluster.

3. Cliquez sur l'onglet Nœuds.

4. Pour chaque pool de nœuds :

   1. Cliquez sur le nom du pool de nœuds pour accéder à sa page d'informations.
   2. Cliquez sur edit Modifier.
   3. Sous Gestion, sélectionnez Activer la mise à niveau automatique.
   4. Cliquez sur Enregistrer.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

BigQuery table CMEK disabled

Nom de la catégorie dans l'API : BIGQUERY_TABLE_CMEK_DISABLED

Une table BigQuery n'est pas configurée pour utiliser une clé de chiffrement gérée par le client (CMEK).

Avec CMEK, les clés que vous créez et gérez dans Cloud KMS encapsulent les clés utilisées par Google Cloud pour chiffrer vos données, ce qui vous permet de mieux contrôler l'accès à vos données. Pour en savoir plus, consultez Protéger des données avec des clés Cloud KMS.

Pour corriger ce résultat, procédez comme suit :

1. Créez une table protégée par Cloud Key Management Service.
2. Copiez votre table dans la nouvelle table compatible avec les CMEK.
3. Supprimez la table d'origine.

Pour définir une clé CMEK par défaut qui chiffre toutes les nouvelles tables d'un ensemble de données, consultez la page Définir une clé par défaut de l'ensemble de données.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

Binary authorization disabled

Nom de la catégorie dans l'API : BINARY_AUTHORIZATION_DISABLED

L'autorisation binaire est désactivée sur un cluster GKE.

L'autorisation binaire inclut une fonctionnalité facultative qui protège la sécurité de la chaîne d'approvisionnement en n'autorisant que le déploiement des images de conteneurs signées par des autorités de confiance lors du processus de développement dans le cluster. Grâce au déploiement basé sur la signature, vous contrôlez mieux votre environnement de conteneurs, en vous assurant que seules les images validées peuvent être déployées.

Pour corriger ce résultat, procédez comme suit :

1. Accédez à la page Clusters Kubernetes de la console Google Cloud .

   Accéder à la page "Clusters Kubernetes"

2. Dans la section Sécurité, cliquez sur edit Modifier dans la ligne Autorisation binaire.

   Si la configuration du cluster a récemment été modifiée, il est possible que le bouton "Modifier" ne soit pas disponible. Si vous ne pouvez pas modifier les paramètres du cluster, attendez quelques minutes, puis réessayez.

3. Dans la boîte de dialogue, sélectionnez Activer l'autorisation binaire.

4. Cliquez sur Enregistrer les modifications.

5. Accédez à la page de configuration de l'autorisation binaire.

   Accéder à la page "Autorisation binaire"

6. Assurez-vous qu'une stratégie exigeant des certificateurs est configurée et que la règle par défaut du projet n'est pas configurée sur Autoriser toutes les images. Pour en savoir plus, consultez Configurer pour GKE.

   Pour vous assurer que les images qui ne respectent pas la stratégie sont autorisées à être déployées et que les violations sont consignées dans Cloud Audit Logs, vous pouvez activer le mode de simulation.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

Bucket CMEK disabled

Nom de la catégorie dans l'API : BUCKET_CMEK_DISABLED

Un bucket n'est pas chiffré avec des clés de chiffrement gérées par le client (CMEK).

La définition d'une clé CMEK par défaut sur un bucket vous permet de mieux contrôler l'accès à vos données. Pour en savoir plus, consultez la page Clés de chiffrement gérées par le client.

Pour corriger ce résultat, utilisez CMEK avec un bucket en suivant la procédure Utiliser des clés de chiffrement gérées par le client. CMEK entraîne des coûts supplémentaires liés à Cloud KMS.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

Bucket IAM not monitored

Nom de la catégorie dans l'API : BUCKET_IAM_NOT_MONITORED

Les métriques et les alertes de journal ne sont pas configurées pour surveiller les modifications apportées aux autorisations IAM Cloud Storage.

La surveillance des modifications apportées aux autorisations des buckets Cloud Storage vous permet d'identifier les utilisateurs bénéficiant de droits trop élevés ou les activités suspectes. Pour en savoir plus, consultez la présentation des métriques basées sur les journaux.

Selon la quantité d'informations, les coûts liés à Cloud Monitoring peuvent être importants. Pour comprendre votre utilisation du service et son coût, consultez les tarifs de Google Cloud Observability.

Pour les activations du niveau Premium de Security Command Center au niveau des projets, ce résultat n'est disponible que si le niveau Standard est activé dans l'organisation parente.

Pour corriger ce résultat, procédez comme suit :

Créer une métrique

1. Accédez à la page Métriques basées sur les journaux de la console Google Cloud .

   Accéder aux métriques basées sur les journaux

2. Cliquez sur Créer la métrique.

3. Sous Type de métrique, sélectionnez Compteur.

4. Sous Détails :

   1. Définissez un nom de métrique de journal.
   2. Ajoutez une description.
   3. Définissez le champ Unités sur 1.

5. Sous Sélection du filtre, copiez et collez le texte suivant dans la zone Créer un filtre, en remplaçant le texte existant si nécessaire :

     resource.type=gcs_bucket
     AND protoPayload.methodName="storage.setIamPermissions"

6. Cliquez sur Créer la métrique. Un message de confirmation s'affiche.

Créer une règle d'alerte

1. Dans la console Google Cloud , accédez à la page Métriques basées sur les journaux :

   Accéder à la page Métriques basées sur les journaux

   Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est Logging.

2. Sous la section Métriques définies par l'utilisateur, sélectionnez la métrique que vous avez créée dans la section précédente.

3. Cliquez sur Plus more_vert, puis sur Créer une alerte à partir de la métrique.

   La boîte de dialogue Nouvelle condition s'affiche, avec les options de métrique et de transformation de données préremplies.

4. Cliquez sur Suivant.
   1. Vérifiez les paramètres préremplis. Vous voudrez peut-être modifier le champ Valeur du seuil.
   2. Cliquez sur Nom de la condition, puis saisissez un nom pour la condition.
5. Cliquez sur Suivant.

6. Pour ajouter des notifications à votre règle d'alerte, cliquez sur Canaux de notification. Dans la boîte de dialogue, sélectionnez un ou plusieurs canaux de notification dans le menu, puis cliquez sur OK.

   Pour recevoir une notification en cas d'ouverture et de fermeture d'un incident, cochez la case Notifier en cas de fermeture des incidents. Par défaut, les notifications ne sont envoyées que lorsque des incidents sont ouverts.

7. (Facultatif) Mettez à jour la durée de fermeture automatique de l'incident. Ce champ détermine à quel moment Monitoring ferme les incidents en l'absence de données de métriques.
8. Facultatif : Cliquez sur Documentation, puis ajoutez les informations à inclure dans le message de notification.
9. Cliquez sur Nom de l'alerte et saisissez un nom pour la règle d'alerte.
10. Cliquez sur Créer une règle.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

Bucket logging disabled

Nom de la catégorie dans l'API : BUCKET_LOGGING_DISABLED

La journalisation est désactivée dans un bucket de stockage.

Pour faciliter l'analyse des problèmes de sécurité et surveiller l'utilisation de l'espace de stockage, activez les journaux d'accès et les informations de stockage de vos buckets Cloud Storage. Les journaux d'accès fournissent des informations pour toutes les requêtes effectuées sur un bucket spécifié. Les journaux de stockage fournissent des informations sur l'espace de stockage consommé par ce bucket.

Pour corriger ce résultat, configurez la journalisation pour le bucket indiqué par le résultat de Security Health Analytics en suivant le guide Journaux d'accès et journaux de stockage.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

Bucket policy only disabled

Nom de la catégorie dans l'API : BUCKET_POLICY_ONLY_DISABLED

L'accès uniforme au niveau du bucket, précédemment appelé "Stratégie du bucket seulement", n'est pas configuré.

L'accès uniforme au niveau du bucket simplifie le contrôle des accès au bucket en désactivant les autorisations au niveau des objets (LCA). Lorsque les autorisations Cloud IAM au niveau du bucket sont activées sur un bucket donné, elles seules définissent l'accès à ce bucket et aux objets qu'il contient. Pour en savoir plus, consultez la section Accès uniforme au niveau du bucket.

Pour corriger ce résultat, procédez comme suit :

1. Accédez à la page Navigateur Cloud Storage dans la consoleGoogle Cloud .

   Accéder au navigateur Cloud Storage

2. Dans la liste des buckets, cliquez sur le nom du bucket souhaité.

3. Cliquez sur l'onglet Configuration.

4. Sous Autorisations, sur la ligne Contrôle des accès, cliquez sur edit Modifier le modèle de contrôle des accès.

5. Dans la boîte de dialogue, sélectionnez Uniforme.

6. Cliquez sur Enregistrer.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

Cloud Asset API disabled

Nom de la catégorie dans l'API : CLOUD_ASSET_API_DISABLED

Le service inventaire des éléments cloud n'est pas activé pour le projet.

Pour corriger ce résultat, procédez comme suit :

1. Accédez à la page Bibliothèque d'API de la console Google Cloud .

   Accéder à la bibliothèque d'API

2. Recherchez Cloud Asset Inventory.

3. Sélectionnez le résultat correspondant au service API Cloud Asset.

4. Assurez-vous que API activée s'affiche.

Cluster logging disabled

Nom de la catégorie dans l'API : CLUSTER_LOGGING_DISABLED

La journalisation n'est pas activée pour un cluster GKE.

Pour faciliter l'analyse des problèmes de sécurité et surveiller l'utilisation, activez Cloud Logging sur vos clusters.

Selon la quantité d'informations, les coûts liés à Cloud Logging peuvent être importants. Pour comprendre votre utilisation du service et son coût, consultez les tarifs de Google Cloud Observability.

Pour corriger ce résultat, procédez comme suit :

1. Accédez à la page Clusters Kubernetes de la console Google Cloud .

   Accéder à la page "Clusters Kubernetes"

2. Sélectionnez le cluster répertorié dans le résultat de Security Health Analytics.

3. Cliquez sur edit Modifier.

   Si la configuration du cluster a récemment été modifiée, il est possible que le bouton "Modifier" ne soit pas disponible. Si vous ne pouvez pas modifier les paramètres du cluster, attendez quelques minutes, puis réessayez.

4. Dans la liste déroulante Ancien Stackdriver Logging ou Stackdriver Kubernetes Engine Monitoring, sélectionnez Activé.

   Ces options ne sont pas compatibles. Veillez à utiliser uniquement Stackdriver Kubernetes Engine Monitoring, ou à combiner les options Ancien Stackdriver Logging et Ancien Stackdriver Monitoring.

5. Cliquez sur Enregistrer.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

Cluster monitoring disabled

Nom de la catégorie dans l'API : CLUSTER_MONITORING_DISABLED

Monitoring est désactivé sur les clusters GKE.

Pour faciliter l'analyse des problèmes de sécurité et surveiller l'utilisation, activez Cloud Monitoring sur vos clusters.

Selon la quantité d'informations, les coûts liés à Cloud Monitoring peuvent être importants. Pour comprendre votre utilisation du service et son coût, consultez les tarifs de Google Cloud Observability.

Pour corriger ce résultat, procédez comme suit :

1. Accédez à la page Clusters Kubernetes de la console Google Cloud .

   Accéder à la page "Clusters Kubernetes"

2. Sélectionnez le cluster répertorié dans le résultat de Security Health Analytics.

3. Cliquez sur edit Modifier.

   Si la configuration du cluster a récemment été modifiée, il est possible que le bouton "Modifier" ne soit pas disponible. Si vous ne pouvez pas modifier les paramètres du cluster, attendez quelques minutes, puis réessayez.

4. Dans la liste déroulante Ancien Legacy Stackdriver Monitoring ou Stackdriver Kubernetes Engine Monitoring, sélectionnez Activé.

   Ces options ne sont pas compatibles. Veillez à utiliser uniquement Stackdriver Kubernetes Engine Monitoring, ou à combiner les options Ancien Stackdriver Monitoring et Ancien Stackdriver Logging.

5. Cliquez sur Enregistrer.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

Cluster private Google access disabled

Nom de la catégorie dans l'API : CLUSTER_PRIVATE_GOOGLE_ACCESS_DISABLED

Les hôtes de cluster ne sont pas configurés pour utiliser uniquement des adresses IP internes privées afin d'accéder aux API Google.

L'accès privé à Google permet aux instances de machine virtuelle (VM) disposant uniquement d'adresses IP internes privées d'accéder aux adresses IP publiques des API et services Google. Pour plus d'informations, consultez la section Configurer l'accès privé à Google.

Pour les activations du niveau Premium de Security Command Center au niveau des projets, ce résultat n'est disponible que si le niveau Standard est activé dans l'organisation parente.

Pour corriger ce résultat, procédez comme suit :

1. Accédez à la page Réseaux de cloud privés virtuel dans la Google Cloud console.

   Accéder aux réseaux VPC

2. Dans la liste des réseaux, cliquez sur le nom du réseau souhaité.

3. Sur la page Détails du réseau VPC, cliquez sur l'onglet Sous-réseaux.

4. Dans la liste des sous-réseaux, cliquez sur le nom du sous-réseau associé au cluster Kubernetes dans le résultat.

5. Sur la page Détails du sous-réseau, cliquez sur edit Modifier.

6. Dans le champ Accès privé à Google, sélectionnez Activé.

7. Cliquez sur Enregistrer.

8. Pour supprimer les adresses IP publiques (externes) des instances de VM dont le seul trafic externe est destiné aux API Google, consultez la section Annuler l'attribution d'une adresse IP externe statique.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

Cluster secrets encryption disabled

Nom de la catégorie dans l'API : CLUSTER_SECRETS_ENCRYPTION_DISABLED

Le chiffrement des secrets au niveau de la couche d'application est désactivé sur un cluster GKE.

Le chiffrement des secrets au niveau de la couche d'application garantit que les secrets GKE sont chiffrés à l'aide de clés Cloud KMS. Cette fonctionnalité fournit une couche de sécurité supplémentaire pour les données sensibles, telles que les secrets définis par l'utilisateur et les secrets requis pour le fonctionnement du cluster, par exemple les clés de compte de service, qui sont toutes stockées dans etcd.

Pour corriger ce résultat, procédez comme suit :

1. Accédez à la page Clés Cloud KMS de la console Google Cloud .

   Accéder à la page Clés Cloud KMS

2. Examinez vos clés d'application ou créez une clé de chiffrement de base de données (DEK). Pour en savoir plus, consultez la page Créer une clé Cloud KMS.

3. Accédez à la page des clusters Kubernetes.

   Accéder à la page "Clusters Kubernetes"

4. Sélectionnez le cluster dans le résultat.

5. Sous Sécurité, dans le champ Chiffrement des secrets au niveau de la couche d'application, cliquez sur edit Modifier le chiffrement des secrets au niveau de la couche d'application.

6. Sélectionnez la case à cocher Activer le chiffrement des secrets au niveau de la couche d'application, puis choisissez la DEK que vous avez créée.

7. Cliquez sur Enregistrer les modifications.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

Cluster shielded nodes disabled

Nom de la catégorie dans l'API : CLUSTER_SHIELDED_NODES_DISABLED

Les nœuds GKE protégés ne sont pas activés pour un cluster.

Sans les nœuds GKE protégés, les pirates informatiques peuvent exploiter une faille d'un pod pour exfiltrer les identifiants d'amorçage et usurper l'identité des nœuds de votre cluster. Cette faille peut donner aux pirates informatiques l'accès aux secrets du cluster.

Pour corriger ce résultat, procédez comme suit :

1. Accédez à la page Clusters Kubernetes de la console Google Cloud .

   Accéder à la page "Clusters Kubernetes"

2. Sélectionnez le cluster dans le résultat.

3. Sous Sécurité, dans le champ Nœuds GKE protégés, cliquez sur edit Modifier les nœuds GKE protégés.

4. Cochez la case Activer les nœuds GKE protégés.

5. Cliquez sur Enregistrer les modifications.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

Compute project wide SSH keys allowed

Nom de la catégorie dans l'API : COMPUTE_PROJECT_WIDE_SSH_KEYS_ALLOWED

Les clés SSH à l'échelle du projet permettent de se connecter à toutes les instances du projet.

L'utilisation de clés SSH à l'échelle du projet facilite la gestion des clés SSH. En revanche, si elle est compromise, elle présente un risque pour la sécurité, qui peut avoir une incidence sur toutes les instances d'un projet. Vous devez utiliser des clés SSH spécifiques à l'instance, qui limitent la surface d'attaque si les clés SSH sont compromises. Pour en savoir plus, consultez la page Gérer des clés SSH dans les métadonnées.

Pour corriger ce résultat, procédez comme suit :

1. Accédez à la page Instances de VM dans la console Google Cloud .

   Accéder à la page Instances de VM

2. Dans la liste des instances, cliquez sur le nom de l'instance dans le résultat.

3. Sur la page Informations sur l'instance de VM, cliquez sur edit Modifier.

4. Sous Clés SSH, sélectionnez Bloquer les clés SSH à l'échelle du projet.

5. Cliquez sur Enregistrer.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

Compute Secure Boot disabled

Nom de la catégorie dans l'API : COMPUTE_SECURE_BOOT_DISABLED

Le démarrage sécurisé n'est pas activé pour cette VM protégée.

Le démarrage sécurisé permet de protéger vos machines virtuelles contre les rootkits et les bootkits. Compute Engine n'active pas le démarrage sécurisé par défaut, car certains pilotes non signés et logiciels de bas niveau ne sont pas compatibles. Si votre VM n'utilise pas de logiciel incompatible et qu'elle démarre avec le démarrage sécurisé activé, Google recommande l'utilisation de cette fonctionnalité. Si vous utilisez des modules tiers avec des pilotes NVIDIA, assurez-vous qu'ils sont compatibles avec le démarrage sécurisé avant de l'activer.

Pour plus d'informations, consultez la section Démarrage sécurisé.

Pour corriger ce résultat, procédez comme suit :

1. Accédez à la page Instances de VM dans la console Google Cloud .

   Accéder à la page Instances de VM

2. Dans la liste des instances, cliquez sur le nom de l'instance dans le résultat.

3. Sur la page Informations sur l'instance de VM, cliquez sur stop Arrêter.

4. Une fois l'instance arrêtée, cliquez sur edit Modifier.

5. Sous VM protégée, sélectionnez Activer le démarrage sécurisé.

6. Cliquez sur Enregistrer.

7. Cliquez sur play_arrow Démarrer pour démarrer l'instance.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

Compute serial ports enabled

Nom de la catégorie dans l'API : COMPUTE_SERIAL_PORTS_ENABLED

Les ports série sont activés pour une instance, ce qui permet de se connecter à la console série de l'instance.

Si vous activez l'accès interactif à la console série sur une instance, les clients peuvent tenter de se connecter à cette instance depuis n'importe quelle adresse IP. Par conséquent, l'accès interactif à la console série doit être désactivé. Pour en savoir plus, consultez la section Activer l'accès pour un projet.

Pour corriger ce résultat, procédez comme suit :

1. Accédez à la page Instances de VM dans la console Google Cloud .

   Accéder à la page Instances de VM

2. Dans la liste des instances, cliquez sur le nom de l'instance dans le résultat.

3. Sur la page Informations sur l'instance de VM, cliquez sur edit Modifier.

4. Dans la section Accès à distance, cochez la case Activer la connexion aux ports série.

5. Cliquez sur Enregistrer.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

Confidential Computing disabled

Nom de la catégorie dans l'API : CONFIDENTIAL_COMPUTING_DISABLED

L'informatique confidentielle n'est pas activée sur une instance Compute Engine.

L'informatique confidentielle ajoute un troisième pilier à la story sur le chiffrement de bout en bout en chiffrant les données pendant qu'ellees sont utilisées. Grâce aux environnements d'exécution confidentiels fournis par l'informatique confidentielle et AMD SEV (Secure Encrypted Virtualization), Google Cloud maintient chiffrés en mémoire le code sensible et les autres données lors de leur traitement.

L'informatique confidentielle ne peut être activée qu'à la création d'une instance. Vous devez donc supprimer l'instance actuelle et en créer une autre.

Pour en savoir plus, consultez Confidential VMs et Compute Engine.

Pour corriger ce résultat, procédez comme suit :

1. Accédez à la page Instances de VM dans la console Google Cloud .

   Accéder à la page Instances de VM

2. Dans la liste des instances, cliquez sur le nom de l'instance dans le résultat.

3. Sur la page Informations sur l'instance de VM, cliquez sur delete Supprimer.

4. Créer une Confidential VM à l'aide de la console Google Cloud .

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

COS not used

Nom de la catégorie dans l'API : COS_NOT_USED

Les VM Compute Engine n'utilisent pas le système d'exploitation optimisé par conteneur, conçu pour exécuter des conteneurs Docker sur Google Cloud en toute sécurité.

Container-Optimized OS est l'OS recommandé par Google pour héberger et exécuter des conteneurs sur Google Cloud. Le faible encombrement de l'OS minimise les risques liés à la sécurité, et les mises à jour automatiques corrigent les failles au plus vite. Pour en savoir plus, consultez la présentation de Container-Optimized OS.

Pour corriger ce résultat, procédez comme suit :

1. Accédez à la page Clusters Kubernetes de la console Google Cloud .

   Accéder à la page "Clusters Kubernetes"

2. Dans la liste des clusters, cliquez sur le nom du cluster dans le résultat.

3. Cliquez sur l'onglet Nœuds.

4. Pour chaque pool de nœuds :

   1. Cliquez sur le nom du pool de nœuds pour accéder à sa page d'informations.
   2. Cliquez sur edit Modifier .
   3. Sous Nœuds -> Type d'image, cliquez sur Modifier.
   4. Sélectionnez Système d'exploitation optimisé par conteneur, puis cliquez sur Modifier.
   5. Cliquez sur Enregistrer.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

Custom role not monitored

Nom de la catégorie dans l'API : CUSTOM_ROLE_NOT_MONITORED

Les métriques et les alertes de journal ne sont pas configurées pour surveiller les modifications apportées au rôle personnalisé.

IAM fournit des rôles prédéfinis et personnalisés qui accordent l'accès à des ressources Google Cloud spécifiques. En surveillant les activités de création, de suppression et de mise à jour des rôles, vous pouvez identifier les rôles bénéficiant de droits trop élevés à un stade précoce. Pour en savoir plus, consultez la présentation des métriques basées sur les journaux.

Selon la quantité d'informations, les coûts liés à Cloud Monitoring peuvent être importants. Pour comprendre votre utilisation du service et son coût, consultez les tarifs de Google Cloud Observability.

Pour les activations du niveau Premium de Security Command Center au niveau des projets, ce résultat n'est disponible que si le niveau Standard est activé dans l'organisation parente.

Pour corriger ce résultat, procédez comme suit :

Créer une métrique

1. Accédez à la page Métriques basées sur les journaux de la console Google Cloud .

   Accéder aux métriques basées sur les journaux

2. Cliquez sur Créer la métrique.

3. Sous Type de métrique, sélectionnez Compteur.

4. Sous Détails :

   1. Définissez un nom de métrique de journal.
   2. Ajoutez une description.
   3. Définissez le champ Unités sur 1.

5. Sous Sélection du filtre, copiez et collez le texte suivant dans la zone Créer un filtre, en remplaçant le texte existant si nécessaire :

     resource.type="iam_role"
     AND (protoPayload.methodName="google.iam.admin.v1.CreateRole"
     OR protoPayload.methodName="google.iam.admin.v1.DeleteRole"
     OR protoPayload.methodName="google.iam.admin.v1.UpdateRole")

6. Cliquez sur Créer la métrique. Un message de confirmation s'affiche.

Créer une règle d'alerte

1. Dans la console Google Cloud , accédez à la page Métriques basées sur les journaux :

   Accéder à la page Métriques basées sur les journaux

   Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est Logging.

2. Sous la section Métriques définies par l'utilisateur, sélectionnez la métrique que vous avez créée dans la section précédente.

3. Cliquez sur Plus more_vert, puis sur Créer une alerte à partir de la métrique.

   La boîte de dialogue Nouvelle condition s'affiche, avec les options de métrique et de transformation de données préremplies.

4. Cliquez sur Suivant.
   1. Vérifiez les paramètres préremplis. Vous voudrez peut-être modifier le champ Valeur du seuil.
   2. Cliquez sur Nom de la condition, puis saisissez un nom pour la condition.
5. Cliquez sur Suivant.

6. Pour ajouter des notifications à votre règle d'alerte, cliquez sur Canaux de notification. Dans la boîte de dialogue, sélectionnez un ou plusieurs canaux de notification dans le menu, puis cliquez sur OK.

   Pour recevoir une notification en cas d'ouverture et de fermeture d'un incident, cochez la case Notifier en cas de fermeture des incidents. Par défaut, les notifications ne sont envoyées que lorsque des incidents sont ouverts.

7. (Facultatif) Mettez à jour la durée de fermeture automatique de l'incident. Ce champ détermine à quel moment Monitoring ferme les incidents en l'absence de données de métriques.
8. Facultatif : Cliquez sur Documentation, puis ajoutez les informations à inclure dans le message de notification.
9. Cliquez sur Nom de l'alerte et saisissez un nom pour la règle d'alerte.
10. Cliquez sur Créer une règle.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

Dataproc CMEK disabled

Nom de la catégorie dans l'API : DATAPROC_CMEK_DISABLED

Un cluster Dataproc a été créé sans CMEK de configuration du chiffrement. Avec CMEK, les clés que vous créez et gérez dans Cloud Key Management Service encapsulent les clés utilisées par Google Cloud pour chiffrer vos données, ce qui vous permet de mieux contrôler l'accès à vos données.

Pour corriger ce résultat, procédez comme suit :

1. Accédez à la page Cluster Dataproc dans la console Google Cloud .

   Accéder aux clusters Dataproc

2. Sélectionnez votre projet, puis cliquez sur Créer un cluster.

3. Dans la section Gérer la sécurité, cliquez sur Chiffrement, puis sélectionnez Clé gérée par le client.

4. Sélectionnez une clé gérée par le client dans la liste.

   Si vous n'avez pas de clé gérée par le client, vous devez en créer une pour l'utiliser. Pour en savoir plus, consultez Clés de chiffrement gérées par le client.

5. Assurez-vous que le rôle Chiffreur/Déchiffreur de CryptoKeys Cloud KMS est attribué au compte de service du cluster Dataproc pour la clé KMS sélectionnée ("serviceAccount:[email protected]").

6. Une fois le cluster créé, migrez toutes vos charges de travail de l'ancien cluster vers le nouveau.

7. Accédez aux clusters Dataproc et sélectionnez votre projet.

8. Sélectionnez l'ancien cluster, puis cliquez sur delete Supprimer.

9. Répétez toutes les étapes ci-dessus pour les autres clusters Dataproc disponibles dans le projet sélectionné.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

Dataproc image outdated

Nom de la catégorie dans l'API : DATAPROC_IMAGE_OUTDATED

Un cluster Dataproc a été créé en utilisant une version d'image Dataproc affectée par les failles de sécurité de l'utilitaire Apache Log4j 2 (CVE-2021-44228 et CVE-2021-45046).

Ce détecteur découvre les failles en vérifiant si le champ softwareConfig.imageVersion de la propriété config d'un objet Cluster comporte l'une des versions concernées suivantes :

• Versions d'image antérieures à 1.3.95.
• Versions d'images mineures antérieures à 1.4.77, 1.5.53 et 2.0.27.

Le numéro de version d'une image Dataproc personnalisée peut être remplacé manuellement. Étudions les cas de figure suivants :

• Vous pouvez modifier la version d'une image personnalisée affectée pour qu'elle semble ne pas être affectée. Dans ce cas, le détecteur ne fournit aucun résultat.
• Vous pouvez remplacer le numéro de version d'une image personnalisée non affectée par celui d'une version connue pour présenter la faille. Dans ce cas, ce détecteur fournit un faux positif. Pour supprimer de tels faux positifs, vous pouvez les ignorer.

Pour corriger ce résultat, recréez et mettez à jour le cluster concerné.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

Dataset CMEK disabled

Nom de la catégorie dans l'API : DATASET_CMEK_DISABLED

Un ensemble de données BigQuery n'est pas configuré pour utiliser une clé de chiffrement gérée par le client par défaut (CMEK).

Avec CMEK, les clés que vous créez et gérez dans Cloud KMS encapsulent les clés utilisées par Google Cloud pour chiffrer vos données, ce qui vous permet de mieux contrôler l'accès à vos données. Pour en savoir plus, consultez Protéger des données avec des clés Cloud KMS.

Pour corriger ce résultat, procédez comme suit :

Vous ne pouvez pas basculer une table en place entre les chiffrements par défaut et le chiffrement CMEK. Pour définir une clé CMEK par défaut avec laquelle chiffrer toutes les nouvelles tables de l'ensemble de données, suivez les instructions de la section Définir une clé par défaut de l'ensemble de données.

Définir une clé par défaut ne rechiffre pas rétroactivement les tables actuelles de l'ensemble de données avec une nouvelle clé. Pour utiliser CMEK pour les données existantes, procédez comme suit :

1. Créez un ensemble de données.
2. Définissez une clé CMEK par défaut sur l'ensemble de données que vous avez créé.
3. Pour copier des tables dans l'ensemble de données compatible avec CMEK, suivez les instructions de la section Copier une table.
4. Une fois les données copiées, supprimer les ensembles de données d'origine.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

Default network

Nom de la catégorie dans l'API : DEFAULT_NETWORK

Le réseau par défaut existe dans un projet.

Les réseaux par défaut créent automatiquement des règles de pare-feu et des configurations réseau qui peuvent ne pas être sécurisées. Pour en savoir plus, consultez la section Réseau par défaut.

Pour les activations du niveau Premium de Security Command Center au niveau des projets, ce résultat n'est disponible que si le niveau Standard est activé dans l'organisation parente.

Pour corriger ce résultat, procédez comme suit :

1. Accédez à la page Réseaux VPC dans la console Google Cloud .

   Accéder aux réseaux VPC

2. Dans la liste des réseaux, cliquez sur le nom du réseau par défaut.

3. Sur la page Détails du réseau VPC, cliquez sur delete Supprimer le réseau VPC.

4. Pour créer un réseau avec des règles de pare-feu personnalisées, consultez la page Créer des réseaux.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

Default service account used

Nom de la catégorie dans l'API : DEFAULT_SERVICE_ACCOUNT_USED

Une instance Compute Engine est configurée pour utiliser le compte de service par défaut.

Le compte de service Compute Engine par défaut dispose du rôle d'éditeur sur le projet, ce qui permet un accès en lecture et en écriture à la plupart des services Google Cloud . Pour vous protéger des élévations de privilèges et des accès non autorisés, n'utilisez pas le compte de service Compute Engine par défaut. À la place, créez un compte de service et ne lui accorder que les autorisations requises par votre instance. Pour plus d'informations sur les rôles et les autorisations, consultez Contrôle des accès.

Pour corriger ce résultat, procédez comme suit :

1. Accédez à la page Instances de VM dans la console Google Cloud .

   Accéder à la page Instances de VM

2. Sélectionnez l'instance associée au résultat de Security Health Analytics.

3. Sur la page Détails de l'instance page qui s'affiche, cliquez sur stop Arrêter.

4. Une fois l'instance arrêtée, cliquez sur edit Modifier.

5. Dans la section Compte de service, sélectionnez un compte de service différent du compte de service Compute Engine par défaut. Vous devrez peut-être d'abord créer un nouveau compte de service. Pour plus d'informations sur les rôles et les autorisations IAM, consultez la page Contrôle des accès.

6. Cliquez sur Enregistrer. La nouvelle configuration s'affiche sur la page Détails de l'instance.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

Disk CMEK disabled

Nom de la catégorie dans l'API : DISK_CMEK_DISABLED

Les disques de cette VM ne sont pas chiffrés avec des clés de chiffrement gérées par le client.

Avec CMEK, les clés que vous créez et gérez dans Cloud KMS encapsulent les clés utilisées par Google Cloud pour chiffrer vos données, ce qui vous permet de mieux contrôler l'accès à vos données. Pour en savoir plus, consultez Protéger des ressources avec des clés Cloud KMS.

Pour corriger ce résultat, procédez comme suit :

1. Accédez à la page Disques Compute Engine dans la consoleGoogle Cloud .

   Accéder à la page Disques Compute Engine

2. Dans la liste des disques, cliquez sur le nom du disque indiqué dans le résultat.

3. Sur la page Gérer le disque, cliquez sur delete Supprimer.

4. Pour créer un disque avec CMEK activé, consultez la section Chiffrer un nouveau disque persistant avec vos propres clés. CMEK entraîne des coûts supplémentaires liés à Cloud KMS.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

Disk CSEK disabled

Nom de la catégorie dans l'API : DISK_CSEK_DISABLED

Les disques de cette VM ne sont pas chiffrés avec des clés de chiffrement fournies par le client (CSEK). Les disques des VM critiques doivent être chiffrés avec des clés CSEK.

Dans ce cas, Compute Engine utilisera votre clé afin de protéger les clés générées par Google pour chiffrer et déchiffrer vos données. Pour en savoir plus, consultez la page Clés de chiffrement fournies par le client. CSEK engendre des coûts supplémentaires liés à Cloud KMS.

Pour corriger ce résultat, procédez comme suit :

Supprimer et créer un disque

Vous pouvez chiffrer les nouveaux disques persistants avec votre propre clé, mais pas les disques persistants existants.

1. Accédez à la page Disques Compute Engine dans la consoleGoogle Cloud .

   Accéder à la page Disques Compute Engine

2. Dans la liste des disques, cliquez sur le nom du disque indiqué dans le résultat.

3. Sur la page Gérer le disque, cliquez sur delete Supprimer.

4. Pour créer un disque avec CSEK activé, consultez la section Chiffrer des disques avec des clés de chiffrement fournies par le client.

5. Suivez le reste de la procédure pour activer le détecteur.

Activer le détecteur

1. Accédez à la page Éléments de Security Command Center dans la consoleGoogle Cloud .

   Accéder

2. Dans la section Type de ressource du panneau Filtres rapides, sélectionnez compute.Disk.

   Si vous ne voyez pas compute.Disk, cliquez sur Afficher plus, saisissez Disk dans le champ de recherche, puis cliquez sur Appliquer.

   Le panneau Résultats est mis à jour pour n'afficher que les instances du type de ressource compute.Disk.

3. Dans la colonne Nom à afficher, cochez la case à côté du nom du disque que vous souhaitez utiliser avec CSEK, puis cliquez sur Définir les marques de sécurité.

4. Dans la boîte de dialogue, cliquez sur Ajouter une marque.

5. Dans le champ key, saisissez enforce_customer_supplied_disk_encryption_keys et, dans le champ valeur, saisissez true.

6. Cliquez sur Enregistrer.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

DNS logging disabled

Nom de la catégorie dans l'API : DNS_LOGGING_DISABLED

La surveillance des journaux Cloud DNS offre une visibilité sur les noms DNS demandés par les clients dans le réseau VPC. Ces journaux peuvent être surveillés pour détecter les anomalies de noms de domaine et évalués selon les renseignements sur les menaces. Nous vous recommandons d'activer la journalisation DNS pour les réseaux VPC.

Selon la quantité d'informations, les coûts de journalisation liés à Cloud DNS peuvent être importants. Pour comprendre votre utilisation du service et son coût, consultez la page Tarifs de Google Cloud Observability : Cloud Logging.

Pour les activations du niveau Premium de Security Command Center au niveau des projets, ce résultat n'est disponible que si le niveau Standard est activé dans l'organisation parente.

Pour corriger ce résultat, procédez comme suit :

1. Accédez à la page Réseaux VPC dans la console Google Cloud .

   Accéder aux réseaux VPC

2. Dans la liste des réseaux, cliquez sur le nom du réseau VPC.

3. Créez une règle de serveur (s'il n'en existe pas) ou modifiez une règle existante :

   • Si le réseau ne dispose pas de règle de serveur DNS, procédez comme suit :

     1. Cliquez sur edit Modifier.
     2. Dans le champ Règle de serveur DNS, cliquez sur Créer une règle de serveur.
     3. Indiquez le nom de la nouvelle règle du serveur.
     4. Définissez Journaux sur Activé.
     5. Cliquez sur Enregistrer.

   • Si le réseau dispose d'une règle de serveur DNS, procédez comme suit :

     1. Dans le champ Règle de serveur DNS, cliquez sur le nom de la règle DNS.
     2. Cliquez sur edit Modifier la règle.
     3. Définissez Journaux sur Activé.
     4. Cliquez sur Enregistrer.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

DNSSEC disabled

Nom de la catégorie dans l'API : DNSSEC_DISABLED

Les extensions de sécurité du système de noms de domaine (DNSSEC, Domain Name System Security Extensions) sont désactivées pour les zones Cloud DNS.

DNSSEC valide les réponses DNS et atténue les risques, tels que le piratage DNS et les attaques de type "MITM" (Man-in-the-middle), en signant de manière cryptographique les enregistrements DNS. Vous devez activer DNSSEC. Pour en savoir plus, consultez la page Présentation des extensions de sécurité DNS (DNSSEC).

Pour corriger ce résultat, procédez comme suit :

1. Accédez à la page Cloud DNS dans la console Google Cloud .

   Accéder aux réseaux Cloud DNS

2. Recherchez la ligne contenant la zone DNS indiquée dans le résultat.

3. Cliquez sur le paramètre DNSSEC sur la ligne puis, sous DNSSEC, sélectionnez Activée.

4. Lisez la boîte de dialogue qui s'affiche. Si vous êtes satisfait, cliquez sur Activer.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

Effectively Anonymous Users Granted GKE Cluster Access

Nom de la catégorie dans l'API : GKE_PRIVILEGE_ESCALATION_DEFAULT_USERS_GROUPS

Une personne a créé une liaison RBAC qui fait référence à l'un des utilisateurs ou groupes suivants :

• system:anonymous
• system:authenticated
• system:unauthenticated

Ces utilisateurs et groupes sont effectivement anonymes et ne doivent pas être utilisés dans les RoleBindings ni les ClusterRoleBindings. Pour en savoir plus, consultez Éviter les rôles et les groupes par défaut.

Pour corriger ce résultat, procédez comme suit pour les ressources concernées :

1. Ouvrez le fichier manifeste de chaque ClusterRoleBinding ou RoleBinding concerné.
2. Définissez les champs restreints suivants sur l'une des valeurs autorisées.

Champs restreints

• subjects[*].name

Valeurs autorisées

• Tous les groupes, utilisateurs ou comptes de service, à l'exception de system:anonymous, system:authenticated ou system:unauthenticated.

Egress deny rule not set

Nom de la catégorie dans l'API : EGRESS_DENY_RULE_NOT_SET

Une règle de refus du trafic sortant n'est pas définie sur un pare-feu.

Un pare-feu qui refuse tout trafic réseau de sortie empêche toutes les connexions réseau sortantes indésirables, à l'exception des connexions explicitement autorisées. Pour plus d'informations, consultez la section Cas de sortie.

Pour les activations du niveau Premium de Security Command Center au niveau des projets, ce résultat n'est disponible que si le niveau Standard est activé dans l'organisation parente.

Pour corriger ce résultat, procédez comme suit :

1. Accédez à la page Pare-feu dans la console Google Cloud .

   Accéder à la page Pare-feu

2. Cliquez sur Create Firewall Rule (Créer une règle de pare-feu).

3. Attribuez un nom et, éventuellement, une description au pare-feu.

4. Pour le champ Sens du trafic, sélectionnez Sortie.

5. Sous Action en cas de correspondance, sélectionnez Refuser.

6. Dans le menu déroulant Cibles, sélectionnez Toutes les instances du réseau.

7. Dans le menu déroulant Filtre de destination, sélectionnez Plages d'adresses IP, puis saisissez 0.0.0.0/0 dans la zone Plages d'adresses IP de destination.

8. Sous Protocoles et ports, sélectionnez Tout refuser.

9. Cliquez sur Désactiver la règle puis, sous Application, sélectionnez Activée.

10. Cliquez sur Créer.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

Essential contacts not configured

Nom de la catégorie dans l'API : ESSENTIAL_CONTACTS_NOT_CONFIGURED

Votre organisation n'a pas désigné de personne ni de groupe pour recevoir les notifications de Google Cloud concernant les événements importants tels que les attaques, les failles et les incidents de données au sein de votre organisation Google Cloud . Nous vous recommandons de désigner comme contact essentiel une ou plusieurs personnes ou groupes de votre organisation.

Pour corriger ce résultat, procédez comme suit :

1. Accédez à la page Contacts essentiels dans la console Google Cloud .

   Accéder aux contacts essentiels

2. Assurez-vous que l'organisation apparaît dans le sélecteur de ressources en haut de la page. Le sélecteur de ressources vous indique pour quel projet, dossier ou organisation vous gérez actuellement les contacts.

3. Cliquez sur + Ajouter un contact. Le panneau Ajouter un contact s'ouvre.

4. Dans les champs Adresse e-mail et Confirmer l'adresse e-mail, saisissez l'adresse e-mail du contact.

5. Dans la section Catégories de notifications, sélectionnez les catégories de notifications pour lesquelles vous souhaitez que le contact reçoive des communications. Assurez-vous que les adresses e-mail appropriées sont configurées pour chacune des catégories de notification suivantes :

   1. Juridique
   2. Sécurité
   3. Suspension
   4. Technique

6. Cliquez sur Enregistrer.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

Firewall not monitored

Nom de la catégorie dans l'API : FIREWALL_NOT_MONITORED

Les statistiques et les alertes de journal ne sont pas configurées pour surveiller les modifications apportées aux règles de pare-feu de réseau VPC.

La surveillance des événements de création et de mise à jour des règles de pare-feu vous donne le détail des modifications d'accès au réseau, et vous permet de détecter rapidement les activités suspectes. Pour en savoir plus, consultez la présentation des métriques basées sur les journaux.

Selon la quantité d'informations, les coûts liés à Cloud Monitoring peuvent être importants. Pour comprendre votre utilisation du service et son coût, consultez les tarifs de Google Cloud Observability.

Pour les activations du niveau Premium de Security Command Center au niveau des projets, ce résultat n'est disponible que si le niveau Standard est activé dans l'organisation parente.

Pour corriger ce résultat, procédez comme suit :

Créer une métrique

1. Accédez à la page Métriques basées sur les journaux de la console Google Cloud .

   Accéder aux métriques basées sur les journaux

2. Cliquez sur Créer la métrique.

3. Sous Type de métrique, sélectionnez Compteur.

4. Sous Détails :

   1. Définissez un nom de métrique de journal.
   2. Ajoutez une description.
   3. Définissez le champ Unités sur 1.

5. Sous Sélection du filtre, copiez et collez le texte suivant dans la zone Créer un filtre, en remplaçant le texte existant si nécessaire :

     resource.type="gce_firewall_rule"
     AND (protoPayload.methodName:"compute.firewalls.insert"
     OR protoPayload.methodName:"compute.firewalls.patch"
     OR protoPayload.methodName:"compute.firewalls.delete")

6. Cliquez sur Créer la métrique. Un message de confirmation s'affiche.

Créer une règle d'alerte

1. Dans la console Google Cloud , accédez à la page Métriques basées sur les journaux :

   Accéder à la page Métriques basées sur les journaux

   Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est Logging.

2. Sous la section Métriques définies par l'utilisateur, sélectionnez la métrique que vous avez créée dans la section précédente.

3. Cliquez sur Plus more_vert, puis sur Créer une alerte à partir de la métrique.

   La boîte de dialogue Nouvelle condition s'affiche, avec les options de métrique et de transformation de données préremplies.

4. Cliquez sur Suivant.
   1. Vérifiez les paramètres préremplis. Vous voudrez peut-être modifier le champ Valeur du seuil.
   2. Cliquez sur Nom de la condition, puis saisissez un nom pour la condition.
5. Cliquez sur Suivant.

6. Pour ajouter des notifications à votre règle d'alerte, cliquez sur Canaux de notification. Dans la boîte de dialogue, sélectionnez un ou plusieurs canaux de notification dans le menu, puis cliquez sur OK.

   Pour recevoir une notification en cas d'ouverture et de fermeture d'un incident, cochez la case Notifier en cas de fermeture des incidents. Par défaut, les notifications ne sont envoyées que lorsque des incidents sont ouverts.

7. (Facultatif) Mettez à jour la durée de fermeture automatique de l'incident. Ce champ détermine à quel moment Monitoring ferme les incidents en l'absence de données de métriques.
8. Facultatif : Cliquez sur Documentation, puis ajoutez les informations à inclure dans le message de notification.
9. Cliquez sur Nom de l'alerte et saisissez un nom pour la règle d'alerte.
10. Cliquez sur Créer une règle.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

Firewall rule logging disabled

Nom de la catégorie dans l'API : FIREWALL_RULE_LOGGING_DISABLED

La journalisation des règles de pare-feu est désactivée.

La journalisation des règles de pare-feu vous permet de réaliser des audits, des vérifications et des analyses sur les effets de vos règles de pare-feu. Cela peut vous être utile pour auditer l'accès au réseau ou pour identifier le plus tôt possible les cas d'utilisation non approuvée du réseau. Le coût des journaux peut être important. Pour en savoir plus sur la journalisation des règles de pare-feu et son coût, consultez la page Utiliser la journalisation des règles de pare-feu.

Pour corriger ce résultat, procédez comme suit :

1. Accédez à la page Pare-feu dans la console Google Cloud .

   Accéder à la page "Pare-feu"

2. Dans la liste des règles de pare-feu, cliquez sur le nom de la règle de pare-feu souhaitée.

3. Cliquez sur edit Modifier.

4. Sous Journaux, sélectionnez Activé.

5. Cliquez sur Enregistrer.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

Flow logs disabled

Nom de la catégorie dans l'API : FLOW_LOGS_DISABLED

Les journaux de flux sont désactivés dans un sous-réseau VPC.

Les journaux de flux VPC enregistrent un échantillon des flux réseau envoyés et reçus par les instances de VM. Ces journaux peuvent être utilisés pour la surveillance et l'investigation des réseaux, l'analyse de la sécurité en temps réel et l'optimisation des dépenses. Pour en savoir plus sur les journaux de flux et leur coût, consultez la page Utiliser des journaux de flux VPC.

Pour corriger ce résultat, procédez comme suit :

1. Accédez à la page Réseaux VPC dans la consoleGoogle Cloud .

   Accéder aux réseaux VPC

2. Dans la liste des réseaux, cliquez sur le nom du réseau souhaité.

3. Sur la page Détails du réseau VPC, cliquez sur l'onglet Sous-réseaux.

4. Dans la liste des sous-réseaux, cliquez sur le nom du sous-réseau indiqué dans le résultat.

5. Sur la page Détails du sous-réseau, cliquez sur edit Modifier.

6. Sous Journaux de flux, sélectionnez Activé.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

Flow logs settings not recommended

Nom de la catégorie dans l'API : VPC_FLOW_LOGS_SETTINGS_NOT_RECOMMENDED

Dans la configuration d'un sous-réseau de réseau VPC, le service de journaux de flux VPC est désactivé ou n'est pas configuré conformément aux recommandations tirées des benchmarks CIS 1.3. Les journaux de flux VPC enregistrent un échantillon des flux réseau envoyés et reçus par les instances de VM, lequel peut être utilisé pour détecter des menaces.

Pour en savoir plus sur les journaux de flux VPC et leur coût, consultez la page Utiliser des journaux de flux VPC.

Pour corriger ce résultat, procédez comme suit :

1. Accédez à la page Réseaux VPC dans la consoleGoogle Cloud .

   Accéder aux réseaux VPC

2. Dans la liste des réseaux, cliquez sur le nom du réseau.

3. Sur la page Détails du réseau VPC, cliquez sur l'onglet Sous-réseaux.

4. Dans la liste des sous-réseaux, cliquez sur le nom du sous-réseau indiqué dans le résultat.

5. Sur la page Détails du sous-réseau, cliquez sur edit Modifier.

6. Sous Journaux de flux, sélectionnez Activé.

   1. Vous pouvez aussi modifier la configuration des journaux en cliquant sur le bouton Configurer les journaux, qui permet de développer l'onglet. Les benchmarks CIS recommandent les paramètres suivants :
      1. Définissez l'intervalle d'agrégation sur 5 secondes.
      2. Dans la case Champs supplémentaires, sélectionnez l'option Inclure les métadonnées.
      3. Définissez le taux d'échantillonnage sur 100 %.
      4. Cliquez sur le bouton ENREGISTRER.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

Full API access

Nom de la catégorie dans l'API : FULL_API_ACCESS

Une instance Compute Engine est configurée pour utiliser le compte de service par défaut avec un accès complet à toutes les API Google Cloud .

Une instance configurée avec le compte de service par défaut et le niveau d'accès à l'API défini sur Autoriser l'accès complet à l'ensemble des API Cloud peut permettre aux utilisateurs d'effectuer des opérations ou des appels d'API pour lesquels ils ne disposent pas d'autorisations IAM. Pour plus d'informations, consultez la section Compte de service Compute Engine par défaut.

Pour corriger ce résultat, procédez comme suit :

1. Accédez à la page Instances de VM dans la console Google Cloud .

   Accéder à la page Instances de VM

2. Dans la liste des instances, cliquez sur le nom de l'instance dans le résultat.

3. Si l'instance est en cours d'exécution, cliquez sur stop Arrêter.

4. Lorsque l'instance est arrêtée, cliquez sur edit Modifier.

5. Dans la section Sécurité et accès, sous Comptes de service, sélectionnez Compte de service Compute Engine par défaut.

6. Sous Champs d'application de l'accès, sélectionnez Autoriser l'accès par défaut ou Définir l'accès pour chaque API. Cela limite les API auxquelles tout processus ou charge de travail utilisant le compte de service de VM par défaut peut accéder.

7. Si vous avez sélectionné Définir l'accès pour chaque API, procédez comme suit :

   • Désactivez Cloud Platform en le définissant sur Aucun.
   • Activez les API spécifiques auxquelles le compte de service de la VM par défaut doit avoir accès.

8. Cliquez sur Enregistrer.

9. Cliquez sur play_arrow Démarrer pour démarrer l'instance.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

HTTP load balancer

Nom de la catégorie dans l'API : HTTP_LOAD_BALANCER

Une instance utilise un équilibreur de charge configuré pour utiliser un proxy HTTP au lieu d'un proxy HTTPS comme cible.

Pour protéger l'intégrité de vos données et empêcher des intrus de falsifier vos communications, configurez vos équilibreurs de charge HTTP(S) de manière à autoriser uniquement le trafic HTTPS. Pour plus d'informations, consultez la page Présentation de l'équilibrage de charge HTTP(S) externe.

Pour les activations du niveau Premium de Security Command Center au niveau des projets, ce résultat n'est disponible que si le niveau Standard est activé dans l'organisation parente.

Pour corriger ce résultat, procédez comme suit :

1. Accédez à la page Proxys cibles de la console Google Cloud .

   Accéder aux proxys cibles

2. Dans la liste des proxys cibles, cliquez sur le nom du proxy cible dans le résultat.

3. Cliquez sur le lien dans la section Mappage d'URL.

4. Cliquez sur edit Modifier.

5. Cliquez sur Frontend configuration (Configuration du frontend).

6. Supprimez toutes les configurations IP frontend et de port qui autorisent le trafic HTTP et créez-en de nouvelles qui autorisent le trafic HTTPS.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

Instance OS login disabled

Nom de la catégorie dans l'API : INSTANCE_OS_LOGIN_DISABLED

OS Login est désactivé sur cette instance Compute Engine.

OS Login active la gestion centralisée des clés SSH avec IAM et désactive les configurations de clés SSH basées sur les métadonnées dans toutes les instances d'un projet. Découvrez comment Configurer OS Login.

Pour les activations du niveau Premium de Security Command Center au niveau des projets, ce résultat n'est disponible que si le niveau Standard est activé dans l'organisation parente.

Pour corriger ce résultat, procédez comme suit :

1. Accédez à la page Instances de VM dans la console Google Cloud .

   Accéder à la page Instances de VM

2. Dans la liste des instances, cliquez sur le nom de l'instance dans le résultat.

3. Sur la page Détails de l'instance qui s'affiche, cliquez sur stop Arrêter.

4. Une fois l'instance arrêtée, cliquez sur edit Modifier.

5. Dans la section Métadonnées personnalisées, assurez-vous que l'élément comportant la clé enable-oslogin a la valeur TRUE.

6. Cliquez sur Enregistrer.

7. Cliquez sur play_arrow Démarrer pour démarrer l'instance.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

Integrity monitoring disabled

Nom de la catégorie dans l'API : INTEGRITY_MONITORING_DISABLED

La surveillance de l'intégrité est désactivée sur un cluster GKE.

La surveillance de l'intégrité vous permet de contrôler et de valider l'intégrité, au démarrage de l'environnement d'exécution, de vos nœuds protégés avec Cloud Monitoring. Vous pouvez ainsi réagir aux échecs d'intégrité et empêcher le déploiement de nœuds compromis dans le cluster.

Pour corriger ce résultat, procédez comme suit :

Une fois qu'un nœud est provisionné, il ne peut pas être mis à jour pour activer la surveillance de l'intégrité. Vous devez créer un pool de nœuds dans lequel la surveillance de l'intégrité est activée.

1. Accédez à la page Clusters Kubernetes de la console Google Cloud .

   Accéder à la page "Clusters Kubernetes"

2. Cliquez sur le nom du cluster dans le résultat.

3. Cliquez sur Aouter un pool de nœuds.

4. Dans l'onglet Sécurité, assurez-vous que l'option Activer la surveillance de l'intégrité est activée.

5. Cliquez sur Create (Créer).

6. Pour migrer vos charges de travail des pools de nœuds non conformes existants vers les nouveaux pools de nœuds, consultez la page Migrer des charges de travail vers différents types de machines.

7. Une fois les charges de travail déplacées, supprimez le pool de nœuds non conforme d'origine.

   1. Sur la page du cluster Kubernetes, dans le menu Pools de nœuds, cliquez sur le nom du pool que vous voulez supprimer.
   2. Cliquez sur Supprimer le pool de nœuds.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

Intranode visibility disabled

Nom de la catégorie dans l'API : INTRANODE_VISIBILITY_DISABLED

La visibilité intranœud est désactivée pour un cluster GKE.

L'activation de la visibilité intranœud rend le trafic intranœud entre pods visible par la structure de mise en réseau. Grâce à cette fonctionnalité, vous pouvez utiliser la journalisation de flux VPC ou d'autres fonctionnalités de VPC pour surveiller ou contrôler le trafic intranœud. Pour obtenir les journaux, vous devez activer les journaux de flux VPC dans le sous-réseau sélectionné. Pour plus d'informations, consultez la page Utiliser des journaux de flux VPC.

Pour corriger ce résultat, procédez comme suit :

Une fois qu'un nœud est provisionné, il ne peut pas être mis à jour pour activer la surveillance de l'intégrité. Vous devez créer un pool de nœuds dans lequel la surveillance de l'intégrité est activée.

1. Accédez à la page Clusters Kubernetes de la console Google Cloud .

   Accéder à la page "Clusters Kubernetes"

2. Dans la section Mise en réseau, cliquez sur edit Modifier la visibilité intranœud dans la ligne Visibilité intranœud.

   Si la configuration du cluster a récemment été modifiée, il est possible que le bouton "Modifier" ne soit pas disponible. Si vous ne pouvez pas modifier les paramètres du cluster, attendez quelques minutes, puis réessayez.

3. Dans la boîte de dialogue, sélectionnez Activer la visibilité intranœud.

4. Cliquez sur Enregistrer les modifications.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

IP alias disabled

Nom de la catégorie dans l'API : IP_ALIAS_DISABLED

Un cluster GKE a été créé avec des plages d'adresses IP d'alias désactivées.

Lorsque vous activez les plages d'adresses IP d'alias, les clusters GKE allouent des adresses IP provenant d'un bloc CIDR connu, pour que votre cluster soit évolutif et interagisse plus facilement avec les produits et entités Google Cloud . Pour en savoir plus, consultez la page Présentation des plages d'adresses IP d'alias.

Pour corriger ce résultat, procédez comme suit :

Il n'est pas possible de migrer un cluster existant pour qu'il utilise des adresses IP d'alias. Pour créer un nouveau cluster avec les adresses IP d'alias activées, procédez comme suit :

1. Accédez à la page Clusters Kubernetes de la console Google Cloud .

   Accéder à la page "Clusters Kubernetes"

2. Cliquez sur Create (Créer).

3. Dans le volet de navigation, sous Cluster, cliquez sur Réseau.

4. Sous Options de mise en réseau avancées, sélectionnez Activer le routage du trafic de VPC natif (utilisation d'une adresse IP d'alias).

5. Cliquez sur Create (Créer).

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

IP forwarding enabled

Nom de la catégorie dans l'API : IP_FORWARDING_ENABLED

Le transfert IP est activé sur les instances Compute Engine.

Évitez les pertes de données et la divulgation d'informations en désactivant le transfert IP des paquets de données pour vos VM.

Pour corriger ce résultat, procédez comme suit :

1. Accédez à la page Instances de VM dans la console Google Cloud .

   Accéder à la page Instances de VM

2. Dans la liste des instances, cochez la case située à côté du nom de l'instance dans le résultat.

3. Cliquez sur delete Supprimer.

4. Sélectionnez Créer une instance pour créer une instance afin de remplacer celle que vous avez supprimée.

5. Pour vous assurer que le transfert IP est désactivé, cliquez sur Gestion, disques, réseau, clés SSH, puis sur Réseau.

6. Sous Interfaces réseau, cliquez sur edit Modifier.

7. Sous Transfert IP, dans le menu déroulant, assurez-vous que l'option Désactivé est sélectionnée.

8. Renseignez les autres paramètres d'instance, puis cliquez sur Créer. Pour en savoir plus, consultez la page Créer et démarrer une instance de VM.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

KMS key not rotated

Nom de la catégorie dans l'API : KMS_KEY_NOT_ROTATED

La rotation n'est pas configurée sur une clé de chiffrement Cloud KMS.

La rotation de vos clés de chiffrement offre régulièrement une protection en cas de compromission d'une clé et limite le nombre de messages chiffrés disponibles à la cryptanalyse pour une version de clé spécifique. Pour en savoir plus, consultez la page Rotation des clés.

Pour corriger ce résultat, procédez comme suit :

1. Accédez à la page Clés Cloud KMS de la console Google Cloud .

   Accéder à la page Clés Cloud KMS

2. Cliquez sur le nom du trousseau de clés indiqué dans le résultat.

3. Cliquez sur le nom de la clé indiquée dans le résultat.

4. Cliquez sur Modifier la période de rotation.

5. Définissez la période de rotation sur 90 jours au maximum.

6. Cliquez sur Enregistrer.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

KMS project has owner

Nom de la catégorie dans l'API : KMS_PROJECT_HAS_OWNER

Un utilisateur dispose des autorisations roles/Owner sur un projet disposant de clés cryptographiques. Pour en savoir plus, consultez la section Autorisations et rôles.

Pour les activations du niveau Premium de Security Command Center au niveau des projets, ce résultat n'est disponible que si le niveau Standard est activé dans l'organisation parente.

Pour corriger ce résultat, procédez comme suit :

1. Accédez à la page IAM dans la console Google Cloud .

   Accéder à la page IAM

2. Si nécessaire, sélectionnez le projet dans les résultats.

3. Pour chaque compte principal auquel le rôle Propriétaire a été attribué :

   1. Cliquez sur edit Modifier.
   2. Dans le panneau Modifier les autorisations, à côté du rôle Propriétaire, cliquez sur delete Supprimer.
   3. Cliquez sur Enregistrer.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

KMS public key

Nom de la catégorie dans l'API : KMS_PUBLIC_KEY

Une clé Cryptokey Cloud KMS ou un trousseau de clés Cloud KMS est public et accessible à tous les internautes. Pour en savoir plus, consultez la page Utiliser IAM avec Cloud KMS.

Pour corriger ce résultat, s'il est lié à une clé Cryptokey :

1. Accédez à la page Clés de chiffrement dans la console Google Cloud .

   Cryptographic Keys

2. Sous Nom, sélectionnez le trousseau de clés contenant la clé cryptographique associée au résultat de Security Health Analytics.

3. Sur la page Informations sur le trousseau qui s'affiche, cochez la case en regard de la clé cryptographique.

4. Si le PANNEAU D'INFORMATIONS n'apparaît pas, cliquez sur le bouton AFFICHER LE PANNEAU D'INFORMATIONS.

5. Utilisez la zone de filtre précédant Rôle / Compte principal pour rechercher les comptes principaux pour allUsers et allAuthenticatedUsers, puis cliquez sur delete Supprimer pour supprimer l'accès de ces comptes principaux.

Pour corriger ce résultat, s'il est lié à un trousseau de clés :

1. Accédez à la page Clés de chiffrement dans la console Google Cloud .

   Cryptographic Keys

2. Recherchez la ligne contenant le trousseau de clés dans le résultat, puis cochez la case correspondante.

3. Si le PANNEAU D'INFORMATIONS n'apparaît pas, cliquez sur le bouton AFFICHER LE PANNEAU D'INFORMATIONS.

4. Utilisez la zone de filtre précédant Rôle / Compte principal pour rechercher les comptes principaux pour allUsers et allAuthenticatedUsers, puis cliquez sur delete Supprimer pour supprimer l'accès de ces comptes principaux.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

KMS role separation

Nom de la catégorie dans l'API : KMS_ROLE_SEPARATION

Ce résultat n'est pas disponible pour les activations au niveau du projet.

Plusieurs autorisations Cloud KMS sont attribuées à un ou plusieurs comptes principaux. Nous vous recommandons de ne pas attribuer simultanément l'autorisation Administrateur Cloud KMS avec d'autres autorisations Cloud KMS. Pour en savoir plus, consultez la section Autorisations et rôles.

Pour corriger ce résultat, procédez comme suit :

1. Accédez à la page IAM dans la console Google Cloud .

   Accéder à IAM

2. Pour chaque compte principal répertorié dans le résultat, procédez comme suit :

   1. Pour vérifier si le rôle a été hérité d'un dossier ou d'une ressource d'organisation, consultez la colonne Héritage. Si la colonne contient un lien vers une ressource parente, cliquez sur ce lien pour accéder à la page IAM de la ressource parente.
   2. Cliquez sur edit Modifier à côté d'un compte principal.
   3. Pour supprimer les autorisations, cliquez sur delete Supprimer à côté de Administrateur Cloud KMS. Si vous souhaitez supprimer toutes les autorisations du compte principal, cliquez sur Supprimer à côté de toutes les autres autorisations.

3. Cliquez sur Enregistrer.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

Legacy authorization enabled

Nom de la catégorie dans l'API : LEGACY_AUTHORIZATION_ENABLED

L'ancienne autorisation est activée sur les clusters GKE.

Dans Kubernetes, le contrôle des accès basé sur les rôles permet de définir des rôles avec des règles contenant un ensemble d'autorisations, et d'accorder des autorisations au niveau du cluster et de l'espace de noms. Ce mécanisme renforce la sécurité en garantissant que les utilisateurs n'ont accès qu'à des ressources spécifiques. Envisagez de désactiver l'ancien contrôle des accès basé sur les attributs (ABAC).

Pour corriger ce résultat, procédez comme suit :

1. Accédez à la page Clusters Kubernetes de la console Google Cloud .

   Accéder à la page "Clusters Kubernetes"

2. Sélectionnez le cluster répertorié dans le résultat de Security Health Analytics.

3. Cliquez sur edit Modifier.

   Si la configuration du cluster a récemment été modifiée, il est possible que le bouton "Modifier" ne soit pas disponible. Si vous ne pouvez pas modifier les paramètres du cluster, attendez quelques minutes, puis réessayez.

4. Dans la liste déroulante Ancienne autorisation, sélectionnez Désactivée.

5. Cliquez sur Enregistrer.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

Legacy metadata enabled

Nom de la catégorie dans l'API : LEGACY_METADATA_ENABLED

Les anciennes métadonnées sont activées sur les clusters GKE.

Le serveur de métadonnées d'instance de Compute Engine expose les anciens points de terminaison /0.1/ et /v1beta1/ qui n'appliquent pas les en-têtes de requête de métadonnées. Il s'agit d'une fonctionnalité des API /v1/ qui rend plus difficile la récupération de métadonnées d'instance par un éventuel pirate informatique. Sauf indication contraire, nous vous recommandons de désactiver ces anciennes API /0.1/ et /v1beta1/.

Pour en savoir plus, consultez la section Désactiver les anciennes API de métadonnées et effectuer une migration.

Pour corriger ce résultat, procédez comme suit :

Vous ne pouvez désactiver les anciennes API de métadonnées que lorsque vous créez un cluster ou lorsque vous ajoutez un nouveau pool de nœuds à un cluster existant. Pour mettre à jour un cluster existant afin de désactiver les anciennes API de métadonnées, consultez la section Migrer des charges de travail vers différents types de machines.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

Legacy network

Nom de la catégorie dans l'API : LEGACY_NETWORK

Un ancien réseau existe dans un projet.

Les anciens réseaux ne sont pas recommandés, car de nombreuses nouvelles fonctionnalités de sécurité Google Cloud ne sont pas compatibles avec les anciens réseaux. Utilisez plutôt les réseaux VPC. Pour en savoir plus, consultez la section Anciens réseaux.

Pour les activations du niveau Premium de Security Command Center au niveau des projets, ce résultat n'est disponible que si le niveau Standard est activé dans l'organisation parente.

Pour corriger ce résultat, procédez comme suit :

1. Accédez à la page Réseaux VPC dans la consoleGoogle Cloud .

   Accéder aux réseaux VPC

2. Pour créer un réseau non hérité, cliquez sur Créer un réseau.

3. Revenez à la page VPC networks (Réseaux VPC).

4. Dans la liste des réseaux, cliquez sur legacy_network.

5. Sur la page Détails du réseau VPC, cliquez sur delete Supprimer le réseau VPC.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

Load balancer logging disabled

Nom de la catégorie dans l'API : LOAD_BALANCER_LOGGING_DISABLED

La journalisation est désactivée pour le service de backend d'un équilibreur de charge.

L'activation de la journalisation pour un équilibreur de charge vous permet d'afficher le trafic réseau HTTP(S) pour vos applications Web. Pour en savoir plus, consultez Équilibreur de charge.

Pour corriger ce résultat, procédez comme suit :

1. Accédez à la page Équilibrage de charge Cloud dans la consoleGoogle Cloud .

   Accéder à Cloud Load Balancing

2. Cliquez sur le nom de votre équilibreur de charge.

3. Cliquez sur edit Modifier.

4. Cliquez sur Configuration du backend.

5. Sur la page Configuration du backend, cliquez sur edit Modifier.

6. Dans la section Journalisation, sélectionnez Activer la journalisation et choisissez le meilleur taux d'échantillonnage pour votre projet.

7. Pour terminer la modification du service de backend, cliquez sur Mettre à jour.

8. Pour terminer la modification de l'équilibreur de charge, cliquez sur Mettre à jour.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

Locked retention policy not set

Nom de la catégorie dans l'API : LOCKED_RETENTION_POLICY_NOT_SET

Une règle de conservation verrouillée n'est pas définie pour les journaux.

Une règle de conservation verrouillée empêche d'écraser des journaux et de supprimer le bucket de journaux. Pour en savoir plus, consultez Verrouillage des buckets.

Pour les activations du niveau Premium de Security Command Center au niveau des projets, ce résultat n'est disponible que si le niveau Standard est activé dans l'organisation parente.

Pour corriger ce résultat, procédez comme suit :

1. Accédez à la page Navigateur de stockage de la console Google Cloud .

   Accéder au navigateur Cloud Storage

2. Sélectionnez le bucket répertorié dans le résultat de Security Health Analytics.

3. Sur la page Informations sur le bucket, cliquez sur l'onglet Autorisations.

4. Si aucune règle de conservation n'a été définie, cliquez sur Définir une règle de conservation.

5. Indiquez une durée de conservation.

6. Cliquez sur Enregistrer. La règle de conservation s'affiche dans l'onglet Conservation.

7. Cliquez sur Verrouiller pour vous assurer que la durée de conservation n'est pas raccourcie ni supprimée.

read_more En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.

Log not exported

Nom de la catégorie dans l'API : LOG_NOT_EXPORTED

Aucun récepteur de journaux approprié n'est configuré pour une ressource.

Cloud Logging vous aide à trouver rapidement la cause des problèmes dans votre système et vos applications. Toutefois, la plupart des journaux ne sont conservés par défaut que pendant 30 jours. Exportez des copies de toutes les entrées de journal pour prolonger la période de stockage. Pour en savoir plus, consultez la section