Corriger les résultats de l'analyse de l'état de la sécurité

Cette page fournit une liste de guides de référence et de techniques permettant de corriger les résultats de l'analyse de l'état de la sécurité à 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'accès dans le tableau de bord Security Command Center, demandez de l'aide à votre administrateur. Pour en savoir plus sur les rôles, consultez la page Contrôle des accès. Pour résoudre les erreurs de ressources, consultez la documentation des produits concernés.

Correction de l'analyse de l'état de la sécurité

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

ADMIN_SERVICE_ACCOUNT

Un compte de service au sein de votre organisation 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 stratégie IAM de Cloud Console.

    Accéder à la stratégie IAM

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

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

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

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 Cloud Console.

    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.

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

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 plus d'informations, consultez la section Utiliser des clés API.

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

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

    Accéder aux Clés API

  2. Pour chaque clé API :

    1. Cliquez sur Modifier .
    2. Sous Restrictions des API, cliquez sur Restreindre la clé.
    3. Dans la liste déroulante Sélectionner des API, choisissez les API que vous souhaitez autoriser.
    4. Cliquez sur Enregistrer. L'application des paramètres peut prendre jusqu'à cinq minutes.

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

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 la section Ajouter des restrictions d'application.

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

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

    Accéder aux Clés API

  2. Pour chaque clé API :

    1. Cliquez sur Modifier .
    2. Sous Restrictions des applications, sélectionnez une catégorie de restriction. Vous pouvez définir une restriction d'application par clé.
    3. Cliquez sur Ajouter un élément pour ajouter des restrictions en fonction des besoins de votre application.
    4. Une fois les éléments ajoutés, cliquez sur Terminé.
    5. Cliquez sur Enregistrer.

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

API_KEY_EXISTS

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

Les clés API ne sont pas sécurisées, car il s'agit de chaînes simples chiffrées qui peuvent être facilement découvertes et utilisées par d'autres utilisateurs. Elles sont récupérables sur des appareils qui les stockeront ou les rendront visibles au public, 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. Utilisez plutôt un flux d'authentification standard. Pour en savoir plus, consultez la section S'authentifier en tant qu'utilisateur final.

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 Cloud Console.

    Accéder aux identifiants de l'API

  3. Dans la section Clés API, cliquez sur Supprimer à côté de chaque clé API.

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

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 régénérant 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 plus d'informations, consultez la page Sécuriser une clé API.

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

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

    Accéder aux Clés API

  2. Pour chaque clé API :

    1. Vérifiez la date sous l'intitulé Date de création.
    2. Si la clé a plus de 90 jours, cliquez sur le nom de la clé ou sur Modifier.
    3. En haut de la page, cliquez sur Régénérer la clé.
    4. Cliquez sur Remplacer la clé.
    5. Pour vous assurer que vos applications continuent à fonctionner sans interruption, mettez-les à jour afin qu'elles utilisent la nouvelle clé API. L'ancienne clé API fonctionne pendant 24 heures avant d'être définitivement désactivée.

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

AUDIT_CONFIG_NOT_MONITORED

Les statistiques 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 la page Optimisation des coûts pour la suite Google Cloud Operations.

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 Cloud Console.

    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. Accédez à la page Métriques basées sur les journaux de Cloud Console.

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

  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 , puis sur Créer une alerte à partir de la métrique. Si vous êtes invité à ajouter votre projet à un espace de travail, effectuez cette démarche.

  4. Sur la page qui s'affiche, cliquez sur Alertes dans le menu de navigation.

  5. Sous Que voulez-vous surveiller ?, cliquez sur Ajouter une condition, puis renseignez la boîte de dialogue pour définir les ressources surveillées et les conditions de déclenchement des alertes. Pour plus d'informations sur les champs d'une condition, consultez la page Spécifier des conditions.

  6. Lorsque vous avez terminé, cliquez sur Ajouter, puis sur Suivant.

  7. Sous Qui doit être informé ?, cliquez sur la liste déroulante Canaux de notification, puis sélectionnez le mode de notification souhaité. Pour plus d'informations, consultez la page Gérer les canaux de notification.

  8. Cliquez sur OK, puis sur Suivant.

  9. Sous Quelles sont les étapes pour résoudre le problème ?, définissez un nom d'alerte.

  10. Cliquez sur Enregistrer.

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

AUDIT_LOGGING_DISABLED

Les journaux d'audit ont été désactivés pour cette ressource.

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 la page Optimisation des coûts pour la suite Google Cloud Operations.

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

  1. Accédez à la page Configuration de l'audit par défaut dans Cloud Console.

    Accéder à la configuration de l'audit par défaut

  2. Sous l'onglet Type de journal, sélectionnez Lecture administrateur, Lecture de données et Écriture de données.

  3. Cliquez sur Enregistrer.

  4. Dans l'onglet Utilisateurs exemptés, supprimez tous les utilisateurs répertoriés en cliquant sur Supprimer à côté de chaque nom.

  5. Cliquez sur Enregistrer.

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

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. Accédez à la page Sauvegardes d'instances SQL dans Cloud Console.

    Accéder aux sauvegardes d'instance SQL

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

  3. Cochez la case Automatiser les sauvegardes.

  4. Dans le menu déroulant, choisissez une période de temps pour la sauvegarde automatique de vos données.

  5. Cliquez sur Enregistrer.

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

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 Cloud Console.

    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 Modifier .
    3. Dans la section Gestion, sélectionnez Activer la réparation automatique.
    4. Cliquez sur Enregistrer.

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

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 Cloud Console.

    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 Modifier .
    3. Sous Gestion, sélectionnez Activer la mise à niveau automatique.
    4. Cliquez sur Enregistrer.

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

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 Cloud Console.

    Accéder à la page "Clusters Kubernetes"

  2. Dans la section Sécurité, cliquez sur l'icône de modification () 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.

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

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.

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

BUCKET_IAM_NOT_MONITORED

Les statistiques 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 la page Optimisation des coûts pour la suite Google Cloud Operations.

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 Cloud Console.

    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. Accédez à la page Métriques basées sur les journaux de Cloud Console.

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

  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 , puis sur Créer une alerte à partir de la métrique. Si vous êtes invité à ajouter votre projet à un espace de travail, effectuez cette démarche.

  4. Sur la page qui s'affiche, cliquez sur Alertes dans le menu de navigation.

  5. Sous Que voulez-vous surveiller ?, cliquez sur Ajouter une condition, puis renseignez la boîte de dialogue pour définir les ressources surveillées et les conditions de déclenchement des alertes. Pour plus d'informations sur les champs d'une condition, consultez la page Spécifier des conditions.

  6. Lorsque vous avez terminé, cliquez sur Ajouter, puis sur Suivant.

  7. Sous Qui doit être informé ?, cliquez sur la liste déroulante Canaux de notification, puis sélectionnez le mode de notification souhaité. Pour plus d'informations, consultez la page Gérer les canaux de notification.

  8. Cliquez sur OK, puis sur Suivant.

  9. Sous Quelles sont les étapes pour résoudre le problème ?, définissez un nom d'alerte.

  10. Cliquez sur Enregistrer.

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

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 l'analyse de l'état de la sécurité en suivant le guide Journaux d'accès et journaux de stockage.

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

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 du navigateur Cloud Storage dans Cloud Console.

    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 l'icône Modifier ().

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

  6. Cliquez sur Enregistrer.

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

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 la page Optimisation des coûts pour la suite Google Cloud Operations.

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

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

    Accéder à la page "Clusters Kubernetes"

  2. Sélectionnez le cluster répertorié dans le résultat de l'analyse de l'état de la sécurité.

  3. Cliquez sur 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.

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

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 la page Optimisation des coûts pour la suite Google Cloud Operations.

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

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

    Accéder à la page "Clusters Kubernetes"

  2. Sélectionnez le cluster répertorié dans le résultat de l'analyse de l'état de la sécurité.

  3. Cliquez sur 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.

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

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 corriger ce résultat, procédez comme suit :

  1. Accédez à la page Réseaux de cloud privés virtuel dans 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 des détails du sous-réseau, cliquez sur 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.

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

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 Cloud Console.

    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 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 Save Changes (Enregistrer les modifications).

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

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 Cloud Console.

    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  Modifier les nœuds GKE protégés.

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

  5. Cliquez sur Save Changes (Enregistrer les modifications).

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

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 de Cloud Console.

    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 Modifier.

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

  5. Cliquez sur Enregistrer.

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

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 de Cloud Console.

    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 Arrêter.

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

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

  6. Cliquez sur Enregistrer.

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

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

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 de Cloud Console.

    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 Modifier.

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

  5. Cliquez sur Enregistrer.

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

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 page Présentation du système d'exploitation optimisé par conteneur.

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

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

    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 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.

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

CUSTOM_ROLE_NOT_MONITORED

Les statistiques 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 la page Optimisation des coûts pour la suite Google Cloud Operations.

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 Cloud Console.

    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. Accédez à la page Métriques basées sur les journaux de Cloud Console.

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

  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 , puis sur Créer une alerte à partir de la métrique. Si vous êtes invité à ajouter votre projet à un espace de travail, effectuez cette démarche.

  4. Sur la page qui s'affiche, cliquez sur Alertes dans le menu de navigation.

  5. Sous Que voulez-vous surveiller ?, cliquez sur Ajouter une condition, puis renseignez la boîte de dialogue pour définir les ressources surveillées et les conditions de déclenchement des alertes. Pour plus d'informations sur les champs d'une condition, consultez la page Spécifier des conditions.

  6. Lorsque vous avez terminé, cliquez sur Ajouter, puis sur Suivant.

  7. Sous Qui doit être informé ?, cliquez sur la liste déroulante Canaux de notification, puis sélectionnez le mode de notification souhaité. Pour plus d'informations, consultez la page Gérer les canaux de notification.

  8. Cliquez sur OK, puis sur Suivant.

  9. Sous Quelles sont les étapes pour résoudre le problème ?, définissez un nom d'alerte.

  10. Cliquez sur Enregistrer.

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

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 la page 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.

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

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 corriger ce résultat, procédez comme suit :

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

    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 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.

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

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 IAM, consultez la page Contrôle des accès.

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

  1. Accédez à la page Instances de VM de Cloud Console.

    Accéder à la page "Instances de VM"

  2. Sélectionnez l'instance associée au résultat de l'analyse de l'état de la sécurité.

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

  4. Une fois l'instance arrêtée, cliquez sur 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.

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

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 la page 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 Cloud Console.

    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 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.

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

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 le 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 Cloud Console.

    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 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 Cloud Console.

    Accéder

  2. À côté de Afficher par, cliquez sur Type de ressource.

  3. Dans la liste des ressources, sélectionnez Disque. La table est renseignée avec la liste de vos disques.

  4. Sous resourceProperties.name, cochez la case correspondant au nom du disque que vous souhaitez utiliser avec CSEK, puis cliquez sur Définir les marques de sécurité.

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

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

  7. Cliquez sur Enregistrer.

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

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 Cloud Console.

    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.

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

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 corriger ce résultat, procédez comme suit :

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

    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 Create (Créer).

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

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 la page Optimisation des coûts pour la suite Google Cloud Operations.

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 Cloud Console.

    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.patch"
      OR protoPayload.methodName="compute.firewalls.insert"
    

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

Créer une règle d'alerte

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

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

  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 , puis sur Créer une alerte à partir de la métrique. Si vous êtes invité à ajouter votre projet à un espace de travail, effectuez cette démarche.

  4. Sur la page qui s'affiche, cliquez sur Alertes dans le menu de navigation.

  5. Sous Que voulez-vous surveiller ?, cliquez sur Ajouter une condition, puis renseignez la boîte de dialogue pour définir les ressources surveillées et les conditions de déclenchement des alertes. Pour plus d'informations sur les champs d'une condition, consultez la page Spécifier des conditions.

  6. Lorsque vous avez terminé, cliquez sur Ajouter, puis sur Suivant.

  7. Sous Qui doit être informé ?, cliquez sur la liste déroulante Canaux de notification, puis sélectionnez le mode de notification souhaité. Pour plus d'informations, consultez la page Gérer les canaux de notification.

  8. Cliquez sur OK, puis sur Suivant.

  9. Sous Quelles sont les étapes pour résoudre le problème ?, définissez un nom d'alerte.

  10. Cliquez sur Enregistrer.

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

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 Cloud Console.

    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 Modifier.

  4. Sous Journaux, sélectionnez Activé.

  5. Cliquez sur Enregistrer.

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

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 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 indiqué dans le résultat.

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

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

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

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 niveau d'accès du compte de service par défaut, Autoriser l'accès complet à l'ensemble des API Cloud, peut permettre à un utilisateur d'effectuer des opérations ou des appels d'API pour lesquels il ne dispose 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 de Cloud Console.

    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. Cliquez sur Arrêter si l'instance est en cours d'exécution.

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

  5. Sous Compte de service, dans le menu déroulant, sélectionnez Compte de service Compute Engine par défaut.

  6. Dans la section Niveaux d'accès, assurez-vous que l'option Autoriser l'accès complet à l'ensemble des API Cloud n'est pas sélectionnée.

  7. Cliquez sur Enregistrer.

  8. Cliquez sur Démarrer pour démarrer l'instance.

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

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 corriger ce résultat, procédez comme suit :

  1. Accédez à la page "Pools cibles" de Cloud Console.

    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 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.

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

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 Cloud Console.

    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.

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

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 Cloud Console.

    Accéder à la page "Clusters Kubernetes"

  2. Dans la section Mise en réseau, cliquez sur l'icône de modification () correspondant à 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 Save Changes (Enregistrer les modifications).

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

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 plus d'informations, 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 Cloud Console.

    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).

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

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 de Cloud Console.

    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 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 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.

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

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 Cloud Console.

    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.

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

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 corriger ce résultat, procédez comme suit :

  1. Accédez à la page "IAM" de Cloud Console.

    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 Modifier.
    2. Dans le panneau Modifier les autorisations, à côté du rôle Propriétaire, cliquez sur Supprimer.
    3. Cliquez sur Enregistrer.

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

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 Cloud Console.

    Clés cryptographiques

  2. Sous Nom, sélectionnez le trousseau de clés contenant la clé cryptographique associée au résultat de l'analyse de l'état de la sécurité.

  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 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 Cloud Console.

    Clés cryptographiques

  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 Supprimer pour supprimer l'accès de ces comptes principaux.

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

KMS_ROLE_SEPARATION

Plusieurs autorisations Cloud KMS sont attribuées à un ou plusieurs comptes principaux. Il est recommandé de ne pas attribuer simultanément le rôle 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" de Cloud Console.

    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 Modifier à côté d'un compte principal.
    3. Pour supprimer les autorisations, cliquez sur Supprimer à côté de l'option Administrateur Cloud KMS. Si vous souhaitez supprimer toutes les autorisations du membre, cliquez sur Supprimer à côté de toutes les autres autorisations.
  3. Cliquez sur Enregistrer.

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

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 Cloud Console.

    Accéder à la page "Clusters Kubernetes"

  2. Sélectionnez le cluster répertorié dans le résultat de l'analyse de l'état de la sécurité.

  3. Cliquez sur 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.

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

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.

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

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 corriger ce résultat, procédez comme suit :

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

    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 Supprimer le réseau VPC.

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

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 la section Règles de conservation et verrouillages de règles de conservation.

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

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

    Accéder au navigateur Cloud Storage

  2. Sélectionnez le bucket répertorié dans le résultat de l'analyse de l'état de la sécurité.

  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.

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

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 Présentation des exportations de journaux.

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

  1. Accédez à la page Routeur de journaux de Cloud Console.

    Accéder au Routeur de journaux

  2. Cliquez sur Create Sink (Créer un récepteur).

  3. Remplissez les champs nécessaires. Les filtres d'inclusion et d'exclusion vous permettent de choisir les journaux à exporter. Pour exporter tous les journaux, laissez les filtres d'inclusion et d'exclusion vides.

  4. Cliquez sur Create Sink (Créer un récepteur).

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

MASTER_AUTHORIZED_NETWORKS_DISABLED

Les réseaux autorisés du plan de contrôle ne sont pas activés sur les clusters GKE.

Les réseaux autorisés du plan de contrôle améliorent la sécurité de votre cluster de conteneurs en empêchant des adresses IP spécifiées d'accéder au plan de contrôle du cluster. Pour en savoir plus, consultez la section Ajouter des réseaux autorisés pour l'accès au plan de contrôle.

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

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

    Accéder à la page "Clusters Kubernetes"

  2. Sélectionnez le cluster répertorié dans le résultat de l'analyse de l'état de la sécurité.

  3. Cliquez sur 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 Réseaux autorisés pour le plan de contrôle, sélectionnez Activés.

  5. Cliquez sur Add authorized network (Ajouter un réseau autorisé).

  6. Spécifiez les réseaux autorisés que vous souhaitez utiliser.

  7. Cliquez sur Enregistrer.

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

MFA_NOT_ENFORCED

L'authentification multifacteur, plus précisément la validation en deux étapes, est désactivée pour certains utilisateurs de votre organisation.

Vous pouvez utiliser l'authentification multifacteur pour protéger les comptes contre les accès non autorisés. C'est l'outil le plus important pour protéger votre organisation en cas d'identifiants de connexion compromis. Pour en savoir plus, consultez la page Protéger votre entreprise avec la validation en deux étapes.

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

  1. Accédez à la page Console d'administration de Cloud Console.

    Accéder à la console d'administration

  2. Appliquez la validation en deux étapes pour toutes les unités organisationnelles.

Utiliser des marques de sécurité

Vous pouvez ajouter des marques de sécurité dédiées aux éléments afin que les détecteurs ne créent pas de résultats de sécurité pour ces éléments.

  • Pour empêcher la réactivation de ce résultat, ajoutez la marque de sécurité allow_mfa_not_enforced avec la valeur true à l'élément.
  • Pour ignorer les violations potentielles pour des unités organisationnelles spécifiques, ajoutez la marque de sécurité excluded_orgunits à l'élément avec une liste de chemins d'accès des unités organisationnelles séparés par des virgules dans le champ valeur. Exemple : excluded_orgunits:/people/vendors/vendorA,/people/contractors/contractorA.

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

NETWORK_NOT_MONITORED

Les statistiques et les alertes de journal ne sont pas configurées pour surveiller les modifications apportées au réseau VPC.

Pour détecter les modifications incorrectes ou non autorisées apportées à la configuration réseau, surveillez les modifications du réseau VPC. 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 la page Optimisation des coûts pour la suite Google Cloud Operations.

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 Cloud Console.

    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_network AND protoPayload.methodName="compute.networks.insert"
      OR protoPayload.methodName="compute.networks.patch"
      OR protoPayload.methodName="compute.networks.delete"
      OR protoPayload.methodName="compute.networks.removePeering"
      OR protoPayload.methodName="compute.networks.addPeering"
    

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

Créer une règle d'alerte

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

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

  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 , puis sur Créer une alerte à partir de la métrique. Si vous êtes invité à ajouter votre projet à un espace de travail, effectuez cette démarche.

  4. Sur la page qui s'affiche, cliquez sur Alertes dans le menu de navigation.

  5. Sous Que voulez-vous surveiller ?, cliquez sur Ajouter une condition, puis renseignez la boîte de dialogue pour définir les ressources surveillées et les conditions de déclenchement des alertes. Pour plus d'informations sur les champs d'une condition, consultez la page Spécifier des conditions.

  6. Lorsque vous avez terminé, cliquez sur Ajouter, puis sur Suivant.

  7. Sous Qui doit être informé ?, cliquez sur la liste déroulante Canaux de notification, puis sélectionnez le mode de notification souhaité. Pour plus d'informations, consultez la page Gérer les canaux de notification.

  8. Cliquez sur OK, puis sur Suivant.

  9. Sous Quelles sont les étapes pour résoudre le problème ?, définissez un nom d'alerte.

  10. Cliquez sur Enregistrer.

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

NETWORK_POLICY_DISABLED

La stratégie de réseau est désactivée sur les clusters GKE.

La communication entre les pods est ouverte par défaut. Une communication ouverte permet aux pods de se connecter directement aux nœuds, avec ou sans traduction d'adresse réseau. Une ressource NetworkPolicy est semblable à un pare-feu au niveau du pod qui restreint les connexions entre les pods, sauf si la ressource NetworkPolicy autorise explicitement la connexion. Découvrez comment définir une règle de réseau.

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

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

    Accéder à la page "Clusters Kubernetes"

  2. Cliquez sur le nom du cluster répertorié dans le résultat de l'analyse de l'état de la sécurité.

  3. Sous Mise en réseau, sur la ligne Règle de réseau, cliquez sur 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 boîte de dialogue, sélectionnez Activer la règle de réseau pour le plan de contrôle et Activer la règle de réseau pour les nœuds.

  5. Cliquez sur Save Changes (Enregistrer les modifications).

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

NODEPOOL_BOOT_CMEK_DISABLED

Les disques de démarrage de ce pool de nœuds ne sont pas chiffrés avec des clés de chiffrement gérées par le client (CMEK). La fonctionnalité CMEK permet à l'utilisateur de configurer les clés de chiffrement par défaut pour les disques de démarrage d'un pool de nœuds.

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

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

    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 default-pool, cliquez sur Supprimer .

  5. Lorsque vous êtes invité à confirmer votre choix, cliquez sur Supprimer.

  6. Pour créer des pools de nœuds à l'aide de CMEK, consultez la page Utiliser des clés de chiffrement gérées par le client (CMEK). CMEK entraîne des coûts supplémentaires liés à Cloud KMS.

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

NODEPOOL_SECURE_BOOT_DISABLED

Le démarrage sécurisé est désactivé pour un cluster GKE.

Activez le démarrage sécurisé pour les nœuds GKE protégés afin de valider les signatures numériques des composants de démarrage des nœuds. Pour plus d'informations, consultez la section Démarrage sécurisé.

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

Une fois un pool de nœuds provisionné, il ne peut plus être mis à jour pour activer le démarrage sécurisé. Vous devez créer un pool de nœuds avec le démarrage sécurisé activé.

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

    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 le menu Pools de nœuds, procédez comme suit :

    1. Cliquez sur le nom du nouveau pool de nœuds pour développer l'onglet.
    2. Sélectionnez Sécurité puis, sous Options protégées, sélectionnez Activer le démarrage sécurisé.
    3. Cliquez sur Create (Créer).
    4. 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.
    5. Une fois les charges de travail déplacées, supprimez le pool de nœuds non conforme d'origine.

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

NON_ORG_IAM_MEMBER

Un utilisateur hors de votre organisation dispose d'autorisations IAM sur un projet ou une organisation. Découvrez les autorisations IAM.

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

  1. Accédez à la page "IAM" de Cloud Console.

    Accéder à IAM

  2. Cochez la case à côté des utilisateurs externes à votre organisation.

  3. Cliquez sur Supprimer.

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

OBJECT_VERSIONING_DISABLED

La gestion des versions d'objets n'est pas activée sur un bucket de stockage dans lequel les récepteurs sont configurés.

Pour permettre la récupération des objets supprimés ou écrasés, Cloud Storage propose la fonctionnalité de gestion des versions d'objets. Activez la gestion des versions d'objets pour éviter que vos données Cloud Storage ne soient accidentellement écrasées ou supprimées. Découvrez comment Activer la gestion des versions d'objets.

Pour corriger ce résultat, utilisez la commande gsutil versioning set on avec la valeur appropriée :

    gsutil versioning set on gs://finding.assetDisplayName

Remplacez finding.assetDisplayName par le nom du bucket concerné.

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

OPEN_CASSANDRA_PORT

Les règles de pare-feu autorisant toute adresse IP à se connecter aux ports Cassandra peuvent exposer vos services Cassandra aux attaques. Pour en savoir plus, consultez la page Présentation des règles de pare-feu VPC.

Les ports de service Cassandra sont les suivants :

  • TCP - 7000, 7001, 7199, 8888, 9042, 9160, 61620, 61621

Ce résultat est généré pour les règles de pare-feu vulnérables, même si vous désactivez intentionnellement les règles. Les résultats actifs des règles de pare-feu désactivées vous avertissent des configurations non sécurisées qui autoriseront le trafic indésirable si elles sont activées.

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

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

    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 dans le résultat.

  3. Cliquez sur Modifier.

  4. Sous Plages d'adresses IP sources, supprimez 0.0.0.0/0.

  5. Ajoutez des adresses IP ou des plages d'adresses IP spécifiques pour permettre les connexions à l'instance à partir de ces adresses

  6. Ajoutez les protocoles et ports spécifiques que vous souhaitez ouvrir sur votre instance.

  7. Cliquez sur Enregistrer.

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

OPEN_CISCOSECURE_WEBSM_PORT

Les règles de pare-feu autorisant toute adresse IP à se connecter aux ports CiscoSecure/WebSM peuvent exposer vos services CiscoSecure/WebSM à des pirates informatiques. Pour en savoir plus, consultez la page Présentation des règles de pare-feu VPC.

Les ports de service CiscoSecure/WebSM sont les suivants :

  • TCP - 9090

Ce résultat est généré pour les règles de pare-feu vulnérables, même si vous désactivez intentionnellement les règles. Les résultats actifs des règles de pare-feu désactivées vous avertissent des configurations non sécurisées qui autoriseront le trafic indésirable si elles sont activées.

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

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

    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 dans le résultat.

  3. Cliquez sur Modifier.

  4. Sous Plages d'adresses IP sources, supprimez 0.0.0.0/0.

  5. Ajoutez des adresses IP ou des plages d'adresses IP spécifiques pour permettre les connexions à l'instance à partir de ces adresses

  6. Ajoutez les protocoles et ports spécifiques que vous souhaitez ouvrir sur votre instance.

  7. Cliquez sur Enregistrer.

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

OPEN_DIRECTORY_SERVICES_PORT

Les règles de pare-feu autorisant toute adresse IP à se connecter aux ports d'annuaire risquent d'exposer vos services d'annuaire aux attaques. Pour en savoir plus, consultez la page Présentation des règles de pare-feu VPC.

Les ports du service d'annuaire sont les suivants :

  • TCP - 445
  • UDP - 445

Ce résultat est généré pour les règles de pare-feu vulnérables, même si vous désactivez intentionnellement les règles. Les résultats actifs des règles de pare-feu désactivées vous avertissent des configurations non sécurisées qui autoriseront le trafic indésirable si elles sont activées.

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

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

    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 dans le résultat.

  3. Cliquez sur Modifier.

  4. Sous Plages d'adresses IP sources, supprimez 0.0.0.0/0.

  5. Ajoutez des adresses IP ou des plages d'adresses IP spécifiques pour permettre les connexions à l'instance à partir de ces adresses

  6. Ajoutez les protocoles et ports spécifiques que vous souhaitez ouvrir sur votre instance.

  7. Cliquez sur Enregistrer.

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

OPEN_DNS_PORT

Les règles de pare-feu autorisant toute adresse IP à se connecter aux ports DNS peuvent exposer vos services DNS aux attaques. Pour en savoir plus, consultez la page Présentation des règles de pare-feu VPC.

Les ports de service DNS sont les suivants :

  • TCP - 53
  • UDP - 53

Ce résultat est généré pour les règles de pare-feu vulnérables, même si vous désactivez intentionnellement les règles. Les résultats actifs des règles de pare-feu désactivées vous avertissent des configurations non sécurisées qui autoriseront le trafic indésirable si elles sont activées.

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

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

    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 dans le résultat.

  3. Cliquez sur Modifier.

  4. Sous Plages d'adresses IP sources, supprimez 0.0.0.0/0.

  5. Ajoutez des adresses IP ou des plages d'adresses IP spécifiques pour permettre les connexions à l'instance à partir de ces adresses

  6. Ajoutez les protocoles et ports spécifiques que vous souhaitez ouvrir sur votre instance.

  7. Cliquez sur Enregistrer.

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

OPEN_ELASTICSEARCH_PORT

Les règles de pare-feu autorisant toute adresse IP à se connecter aux ports Elasticsearch peuvent exposer vos services Elasticsearch aux attaques. Pour en savoir plus, consultez la page Présentation des règles de pare-feu VPC.

Les ports du service Elasticsearch sont les suivants :

  • TCP - 9200, 9300

Ce résultat est généré pour les règles de pare-feu vulnérables, même si vous désactivez intentionnellement les règles. Les résultats actifs des règles de pare-feu désactivées vous avertissent des configurations non sécurisées qui autoriseront le trafic indésirable si elles sont activées.

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

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

    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 dans le résultat.

  3. Cliquez sur Modifier.

  4. Sous Plages d'adresses IP sources, supprimez 0.0.0.0/0.

  5. Ajoutez des adresses IP ou des plages d'adresses IP spécifiques pour permettre les connexions à l'instance à partir de ces adresses

  6. Ajoutez les protocoles et ports spécifiques que vous souhaitez ouvrir sur votre instance.

  7. Cliquez sur Enregistrer.

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

OPEN_FIREWALL

Les règles de pare-feu qui autorisent les connexions à partir de toutes les adresses IP (telles que 0.0.0.0/0) ou de tous les ports peuvent exposer inutilement les ressources à des attaques d'origine imprévue. Ces règles doivent être supprimées ou appliquées de façon explicite aux plages d'adresses IP sources ou aux ports prévus. Par exemple, dans les applications destinées à être publiques, envisagez de limiter les ports autorisés à ceux nécessaires à l'application, comme 80 et 443. Si votre application doit autoriser les connexions à partir de tous les ports ou adresses IP, vous pouvez ajouter l'élément à une liste d'autorisation. En savoir plus sur la mise à jour des règles de pare-feu.

Ce résultat est généré pour les règles de pare-feu vulnérables, même si vous désactivez intentionnellement les règles. Les résultats actifs des règles de pare-feu désactivées vous avertissent des configurations non sécurisées qui autoriseront le trafic indésirable si elles sont activées.

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

  1. Accédez à la page Règles de pare-feu de Cloud Console.

    Accéder aux règles de pare-feu

  2. Cliquez sur la règle de pare-feu répertoriée dans le résultat de l'analyse de l'état de la sécurité, puis sur Modifier.

  3. Sous Plages d'adresses IP sources, modifiez les valeurs de d'adresse IP pour restreindre la plage d'adresses IP autorisées.

  4. Dans la section Protocoles et ports, sélectionnez Protocoles et ports spécifiés, sélectionnez les protocoles autorisés et saisissez les ports autorisés.

  5. Cliquez sur Enregistrer.

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

OPEN_FTP_PORT

Les règles de pare-feu autorisant toute adresse IP à se connecter aux ports FTP peuvent exposer vos services FTP aux attaques. Pour en savoir plus, consultez la page Présentation des règles de pare-feu VPC.

Les ports de service FTP sont les suivants :

  • TCP - 21

Ce résultat est généré pour les règles de pare-feu vulnérables, même si vous désactivez intentionnellement les règles. Les résultats actifs des règles de pare-feu désactivées vous avertissent des configurations non sécurisées qui autoriseront le trafic indésirable si elles sont activées.

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

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

    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 dans le résultat.

  3. Cliquez sur Modifier.

  4. Sous Plages d'adresses IP sources, supprimez 0.0.0.0/0.

  5. Ajoutez des adresses IP ou des plages d'adresses IP spécifiques pour permettre les connexions à l'instance à partir de ces adresses

  6. Ajoutez les protocoles et ports spécifiques que vous souhaitez ouvrir sur votre instance.

  7. Cliquez sur Enregistrer.

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

OPEN_HTTP_PORT

Les règles de pare-feu autorisant toute adresse IP à se connecter aux ports HTTP peuvent exposer vos services HTTP aux attaques. Pour en savoir plus, consultez la page Présentation des règles de pare-feu VPC.

Les ports de service HTTP sont les suivants :

  • TCP - 80

Ce résultat est généré pour les règles de pare-feu vulnérables, même si vous désactivez intentionnellement les règles. Les résultats actifs des règles de pare-feu désactivées vous avertissent des configurations non sécurisées qui autoriseront le trafic indésirable si elles sont activées.

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

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

    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 dans le résultat.

  3. Cliquez sur Modifier.

  4. Sous Plages d'adresses IP sources, supprimez 0.0.0.0/0.

  5. Ajoutez des adresses IP ou des plages d'adresses IP spécifiques pour permettre les connexions à l'instance à partir de ces adresses

  6. Ajoutez les protocoles et ports spécifiques que vous souhaitez ouvrir sur votre instance.

  7. Cliquez sur Enregistrer.

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

OPEN_LDAP_PORT

Les règles de pare-feu autorisant toute adresse IP à se connecter aux ports LDAP peuvent exposer vos services LDAP à des pirates informatiques. Pour en savoir plus, consultez la page Présentation des règles de pare-feu VPC.

Les ports de service LDAP sont les suivants :

  • TCP - 389, 636
  • UDP - 389

Ce résultat est généré pour les règles de pare-feu vulnérables, même si vous désactivez intentionnellement les règles. Les résultats actifs des règles de pare-feu désactivées vous avertissent des configurations non sécurisées qui autoriseront le trafic indésirable si elles sont activées.

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

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

    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 dans le résultat.

  3. Cliquez sur Modifier.

  4. Sous Plages d'adresses IP sources, supprimez 0.0.0.0/0.

  5. Ajoutez des adresses IP ou des plages d'adresses IP spécifiques pour permettre les connexions à l'instance à partir de ces adresses

  6. Ajoutez les protocoles et ports spécifiques que vous souhaitez ouvrir sur votre instance.

  7. Cliquez sur Enregistrer.

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

OPEN_MEMCACHED_PORT

Les règles de pare-feu autorisant toute adresse IP à se connecter aux ports Memcached peuvent exposer vos services Memcached aux attaques. Pour en savoir plus, consultez la page Présentation des règles de pare-feu VPC.

Les ports de service Memcached sont les suivants :

  • TCP - 11211, 11214, 11215
  • UDP - 11211, 11214, 11215

Ce résultat est généré pour les règles de pare-feu vulnérables, même si vous désactivez intentionnellement les règles. Les résultats actifs des règles de pare-feu désactivées vous avertissent des configurations non sécurisées qui autoriseront le trafic indésirable si elles sont activées.

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

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

    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 dans le résultat.

  3. Cliquez sur Modifier.

  4. Sous Plages d'adresses IP sources, supprimez 0.0.0.0/0.

  5. Ajoutez des adresses IP ou des plages d'adresses IP spécifiques pour permettre les connexions à l'instance à partir de ces adresses

  6. Ajoutez les protocoles et ports spécifiques que vous souhaitez ouvrir sur votre instance.

  7. Cliquez sur Enregistrer.

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

OPEN_MONGODB_PORT

Les règles de pare-feu autorisant toute adresse IP à se connecter aux ports MongoDB peuvent exposer vos services MongoDB aux attaques. Pour en savoir plus, consultez la page Présentation des règles de pare-feu VPC.

Les ports de service MongoDB sont les suivants :

  • TCP - 27017, 27018, 27019

Ce résultat est généré pour les règles de pare-feu vulnérables, même si vous désactivez intentionnellement les règles. Les résultats actifs des règles de pare-feu désactivées vous avertissent des configurations non sécurisées qui autoriseront le trafic indésirable si elles sont activées.

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

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

    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 dans le résultat.

  3. Cliquez sur Modifier.

  4. Sous Plages d'adresses IP sources, supprimez 0.0.0.0/0.

  5. Ajoutez des adresses IP ou des plages d'adresses IP spécifiques pour permettre les connexions à l'instance à partir de ces adresses

  6. Ajoutez les protocoles et ports spécifiques que vous souhaitez ouvrir sur votre instance.

  7. Cliquez sur Enregistrer.

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

OPEN_MYSQL_PORT

Les règles de pare-feu autorisant toute adresse IP à se connecter aux ports MySQL peuvent exposer vos services MySQL aux attaques. Pour en savoir plus, consultez la page Présentation des règles de pare-feu VPC.

Les ports de service MySQL sont les suivants :

  • TCP - 3306

Ce résultat est généré pour les règles de pare-feu vulnérables, même si vous désactivez intentionnellement les règles. Les résultats actifs des règles de pare-feu désactivées vous avertissent des configurations non sécurisées qui autoriseront le trafic indésirable si elles sont activées.

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

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

    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 dans le résultat.

  3. Cliquez sur Modifier.

  4. Sous Plages d'adresses IP sources, supprimez 0.0.0.0/0.

  5. Ajoutez des adresses IP ou des plages d'adresses IP spécifiques pour permettre les connexions à l'instance à partir de ces adresses

  6. Ajoutez les protocoles et ports spécifiques que vous souhaitez ouvrir sur votre instance.

  7. Cliquez sur Enregistrer.

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

OPEN_NETBIOS_PORT

Les règles de pare-feu autorisant toute adresse IP à se connecter aux ports NetBIOS peuvent exposer vos services NetBIOS aux attaques. Pour en savoir plus, consultez la page Présentation des règles de pare-feu VPC.

Les ports du service NetBIOS sont les suivants :

  • TCP - 137, 138, 139
  • UDP - 137, 138, 139

Ce résultat est généré pour les règles de pare-feu vulnérables, même si vous désactivez intentionnellement les règles. Les résultats actifs des règles de pare-feu désactivées vous avertissent des configurations non sécurisées qui autoriseront le trafic indésirable si elles sont activées.

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

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

    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 dans le résultat.

  3. Cliquez sur Modifier.

  4. Sous Plages d'adresses IP sources, supprimez 0.0.0.0/0.

  5. Ajoutez des adresses IP ou des plages d'adresses IP spécifiques pour permettre les connexions à l'instance à partir de ces adresses

  6. Ajoutez les protocoles et ports spécifiques que vous souhaitez ouvrir sur votre instance.

  7. Cliquez sur Enregistrer.

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

OPEN_ORACLEDB_PORT

Les règles de pare-feu autorisant toute adresse IP à se connecter aux ports OracleDB peuvent exposer vos services OracleDB aux attaques. Pour en savoir plus, consultez la page Présentation des règles de pare-feu VPC.

Les ports de service OracleDB sont les suivants :

  • TCP - 1521, 2483, 2484
  • UDP - 2483, 2484

Ce résultat est généré pour les règles de pare-feu vulnérables, même si vous désactivez intentionnellement les règles. Les résultats actifs des règles de pare-feu désactivées vous avertissent des configurations non sécurisées qui autoriseront le trafic indésirable si elles sont activées.

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

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

    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 dans le résultat.

  3. Cliquez sur Modifier.

  4. Sous Plages d'adresses IP sources, supprimez 0.0.0.0/0.

  5. Ajoutez des adresses IP ou des plages d'adresses IP spécifiques pour permettre les connexions à l'instance à partir de ces adresses

  6. Ajoutez les protocoles et ports spécifiques que vous souhaitez ouvrir sur votre instance.

  7. Cliquez sur Enregistrer.

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

OPEN_POP3_PORT

Les règles de pare-feu autorisant toute adresse IP à se connecter aux ports POP3 peuvent exposer vos services POP3 aux attaques. Pour en savoir plus, consultez la page Présentation des règles de pare-feu VPC.

Les ports de service POP3 sont les suivants :

  • TCP - 110

Ce résultat est généré pour les règles de pare-feu vulnérables, même si vous désactivez intentionnellement les règles. Les résultats actifs des règles de pare-feu désactivées vous avertissent des configurations non sécurisées qui autoriseront le trafic indésirable si elles sont activées.

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

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

    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 dans le résultat.

  3. Cliquez sur Modifier.

  4. Sous Plages d'adresses IP sources, supprimez 0.0.0.0/0.

  5. Ajoutez des adresses IP ou des plages d'adresses IP spécifiques pour permettre les connexions à l'instance à partir de ces adresses

  6. Ajoutez les protocoles et ports spécifiques que vous souhaitez ouvrir sur votre instance.

  7. Cliquez sur Enregistrer.

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

OPEN_POSTGRESQL_PORT

Les règles de pare-feu autorisant toute adresse IP à se connecter aux ports PostgreSQL peuvent exposer vos services PostgreSQL aux attaques. Pour en savoir plus, consultez la page Présentation des règles de pare-feu VPC.

Les ports de service PostgreSQL sont les suivants :

  • TCP - 5432
  • UDP - 5432

Ce résultat est généré pour les règles de pare-feu vulnérables, même si vous désactivez intentionnellement les règles. Les résultats actifs des règles de pare-feu désactivées vous avertissent des configurations non sécurisées qui autoriseront le trafic indésirable si elles sont activées.

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

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

    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 dans le résultat.

  3. Cliquez sur Modifier.

  4. Sous Plages d'adresses IP sources, supprimez 0.0.0.0/0.

  5. Ajoutez des adresses IP ou des plages d'adresses IP spécifiques pour permettre les connexions à l'instance à partir de ces adresses

  6. Ajoutez les protocoles et ports spécifiques que vous souhaitez ouvrir sur votre instance.

  7. Cliquez sur Enregistrer.

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

OPEN_RDP_PORT

Les règles de pare-feu autorisant toute adresse IP à se connecter aux ports RDP peuvent exposer vos services RDP aux attaques. Pour en savoir plus, consultez la page Présentation des règles de pare-feu VPC.

Les ports de service RDP sont les suivants :

  • TCP - 3389
  • UDP - 3389

Ce résultat est généré pour les règles de pare-feu vulnérables, même si vous désactivez intentionnellement les règles. Les résultats actifs des règles de pare-feu désactivées vous avertissent des configurations non sécurisées qui autoriseront le trafic indésirable si elles sont activées.

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

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

    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 dans le résultat.

  3. Cliquez sur Modifier.

  4. Sous Plages d'adresses IP sources, supprimez 0.0.0.0/0.

  5. Ajoutez des adresses IP ou des plages d'adresses IP spécifiques pour permettre les connexions à l'instance à partir de ces adresses

  6. Ajoutez les protocoles et ports spécifiques que vous souhaitez ouvrir sur votre instance.

  7. Cliquez sur Enregistrer.

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

OPEN_REDIS_PORT

Les règles de pare-feu autorisant toute adresse IP à se connecter aux ports Redis peuvent exposer vos services Redis aux attaques. Pour en savoir plus, consultez la page Présentation des règles de pare-feu VPC.

Les ports de service Redis sont les suivants :

  • TCP - 6379

Ce résultat est généré pour les règles de pare-feu vulnérables, même si vous désactivez intentionnellement les règles. Les résultats actifs des règles de pare-feu désactivées vous avertissent des configurations non sécurisées qui autoriseront le trafic indésirable si elles sont activées.

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

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

    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 dans le résultat.

  3. Cliquez sur Modifier.

  4. Sous Plages d'adresses IP sources, supprimez 0.0.0.0/0.

  5. Ajoutez des adresses IP ou des plages d'adresses IP spécifiques pour permettre les connexions à l'instance à partir de ces adresses

  6. Ajoutez les protocoles et ports spécifiques que vous souhaitez ouvrir sur votre instance.

  7. Cliquez sur Enregistrer.

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

OPEN_SMTP_PORT

Les règles de pare-feu autorisant toute adresse IP à se connecter aux ports SMTP peuvent exposer vos services SMTP aux pirates informatiques. Pour en savoir plus, consultez la page Présentation des règles de pare-feu VPC.

Les ports de service SMTP sont les suivants :

  • TCP - 25

Ce résultat est généré pour les règles de pare-feu vulnérables, même si vous désactivez intentionnellement les règles. Les résultats actifs des règles de pare-feu désactivées vous avertissent des configurations non sécurisées qui autoriseront le trafic indésirable si elles sont activées.

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

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

    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 dans le résultat.

  3. Cliquez sur Modifier.

  4. Sous Plages d'adresses IP sources, supprimez 0.0.0.0/0.

  5. Ajoutez des adresses IP ou des plages d'adresses IP spécifiques pour permettre les connexions à l'instance à partir de ces adresses

  6. Ajoutez les protocoles et ports spécifiques que vous souhaitez ouvrir sur votre instance.

  7. Cliquez sur Enregistrer.

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

OPEN_SSH_PORT

Les règles de pare-feu autorisant toute adresse IP à se connecter aux ports SSH peuvent exposer vos services SSH aux attaques. Pour en savoir plus, consultez la page Présentation des règles de pare-feu VPC.

Les ports de service SSH sont les suivants :

  • SCTP - 22
  • TCP - 22

Ce résultat est généré pour les règles de pare-feu vulnérables, même si vous désactivez intentionnellement les règles. Les résultats actifs des règles de pare-feu désactivées vous avertissent des configurations non sécurisées qui autoriseront le trafic indésirable si elles sont activées.

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

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

    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 dans le résultat.

  3. Cliquez sur Modifier.

  4. Sous Plages d'adresses IP sources, supprimez 0.0.0.0/0.

  5. Ajoutez des adresses IP ou des plages d'adresses IP spécifiques pour permettre les connexions à l'instance à partir de ces adresses

  6. Ajoutez les protocoles et ports spécifiques que vous souhaitez ouvrir sur votre instance.

  7. Cliquez sur Enregistrer.

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

OPEN_TELNET_PORT

Les règles de pare-feu autorisant toute adresse IP à se connecter aux ports Telnet peuvent exposer vos services Telnet aux attaques. Pour en savoir plus, consultez la page Présentation des règles de pare-feu VPC.

Les ports de service Telnet sont les suivants :

  • TCP - 23

Ce résultat est généré pour les règles de pare-feu vulnérables, même si vous désactivez intentionnellement les règles. Les résultats actifs des règles de pare-feu désactivées vous avertissent des configurations non sécurisées qui autoriseront le trafic indésirable si elles sont activées.

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

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

    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 dans le résultat.

  3. Cliquez sur Modifier.

  4. Sous Plages d'adresses IP sources, supprimez 0.0.0.0/0.

  5. Ajoutez des adresses IP ou des plages d'adresses IP spécifiques pour permettre les connexions à l'instance à partir de ces adresses

  6. Ajoutez les protocoles et ports spécifiques que vous souhaitez ouvrir sur votre instance.

  7. Cliquez sur Enregistrer.

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

ORG_POLICY_CONFIDENTIAL_VM_POLICY

Une ressource Compute Engine n'est pas conforme à la règle d'administration constraints/compute.restrictNonConfidentialComputing. Pour plus d'informations sur cette contrainte de règle d'administration, consultez la section Appliquer des contraintes de règle d'administration.

Le service Confidential VM doit être activé sur cette VM selon les règles définies par votre organisation. Les VM pour lesquelles ce service n'est pas activé n'utilisent pas le chiffrement de la mémoire d'exécution, ce qui les expose à des attaques ciblant cette section de mémoire.

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

  1. Accédez à la page Instances de VM de Cloud Console.

    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 la VM ne nécessite pas le service Confidential VM, déplacez-la dans un nouveau dossier ou un nouveau projet.

  4. Si la VM requiert Confidential VM, cliquez sur Supprimer.

  5. Pour créer une instance avec Confidential VM activée, consultez la page Démarrage rapide : créer une instance de Confidential VM.

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

ORG_POLICY_LOCATION_RESTRICTION

La contrainte de règle d'administration gcp.resourceLocations vous permet de limiter la création de ressources aux régions cloud que vous sélectionnez. Pour en savoir plus, consultez la section Restreindre les emplacements de ressources.

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

Le détecteur ORG_POLICY_LOCATION_RESTRICTION couvre de nombreux types de ressources et les instructions de correction sont différentes pour chaque ressource. L'approche générale pour corriger les violations de localisation est la suivante:

  1. Copiez, déplacez ou sauvegardez la ressource hors région ou ses données dans une ressource située dans la région. Lisez la documentation sur les services individuels pour obtenir des instructions sur le déplacement des ressources.
  2. Supprimez la ressource d'origine hors région ou ses données.

Cette approche n'est pas possible pour tous les types de ressources. Pour obtenir des conseils, consultez les recommandations personnalisées fournies dans le résultat.

Autres considérations

Ressources gérées

Le cycle de vie des ressources est parfois géré et contrôlé par d'autres ressources. Par exemple, un groupe d'instances Compute Engine géré crée et détruit des instances Compute Engine conformément à la règle d'autoscaling du groupe d'instances. Si les ressources gérées et de gestion sont couvertes par l'application des emplacements, les deux peuvent être signalées comme ne respectant pas la règle d'administration. La correction des résultats pour les ressources gérées doit être effectuée dans la gestion des ressources pour garantir la stabilité opérationnelle.

Ressources utilisées

Certaines ressources sont utilisées par d'autres ressources. Par exemple, un disque Compute Engine associé à une instance Compute Engine en cours d'exécution est considéré comme utilisé par l'instance. Si la ressource en cours d'utilisation enfreint la règle d'administration de l'emplacement, vous devez vous assurer qu'elle n'est pas utilisée avant de remédier à la violation de l'emplacement.

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

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 corriger ce résultat, procédez comme suit :

  1. Accédez à la page Métadonnées de Cloud Console.

    Accéder à la page "Métadonnées"

  2. Cliquez sur Modifier, puis sur Ajouter un élément.

  3. Ajoutez un élément comportant la clé enable-oslogin et la valeur TRUE.

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

OVER_PRIVILEGED_ACCOUNT

Ce nœud GKE utilise le nœud de service Compute Engine par défaut, qui dispose d'un accès étendu par défaut et potentiellement de privilèges trop élevés pour exécuter votre cluster GKE.

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

Suivez les instructions pour Utiliser le principe du moindre privilège pour les comptes de service Google.

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

OVER_PRIVILEGED_SCOPES

Un compte de service de nœud possède des niveaux d'accès étendus.

Les niveaux d'accès représentent l'ancienne méthode de spécification des autorisations associées à votre instance. Pour réduire le risque d'élévation des privilèges lors d'une attaque, vous devez créer et utiliser un compte de service doté de privilèges minimaux pour exécuter votre cluster GKE.

Pour corriger ce résultat, suivez les instructions de la section Utiliser le principe du moindre privilège pour les comptes de service Google.

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

OVER_PRIVILEGED_SERVICE_ACCOUNT_USER

Un utilisateur possède les rôles iam.serviceAccountUser ou iam.serviceAccountTokenCreator au niveau du projet, du dossier ou de l'organisation, et non pour un compte de service spécifique.

L'attribution de ces rôles à un utilisateur pour un projet, un dossier ou une organisation permet à cet utilisateur d'accéder à tous les comptes de service existants et futurs de ce champ d'application. Cela peut entraîner une élévation involontaire des privilèges. Pour en savoir plus, consultez la section Autorisations des comptes de service.

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

  1. Accédez à la page "IAM" de Cloud Console.

    Accéder à la page IAM

  2. Si nécessaire, sélectionnez le projet, le dossier ou l'organisation dans le résultat.

  3. Pour chaque compte principal auquel on a attribué roles/iam.serviceAccountUser ou roles/iam.serviceAccountTokenCreator, procédez comme suit :

    1. Cliquez sur Modifier.
    2. Dans le panneau Modifier les autorisations, à côté des rôles, cliquez sur Supprimer.
    3. Cliquez sur Enregistrer.
  4. Suivez ce guide pour autoriser des utilisateurs individuels à emprunter l'identité d'un seul compte de service. Vous devez suivre les instructions du guide pour chaque compte de service pour lequel vous souhaitez autoriser l'emprunt d'identité par les utilisateurs choisis.

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

OWNER_NOT_MONITORED

Les statistiques et les alertes de journal ne sont pas configurées pour surveiller les attributions ou les modifications de propriétaire de projet.

Le rôle de propriétaire Cloud IAM dispose du niveau de droits le plus élevé sur un projet. Pour sécuriser vos ressources, configurez des alertes afin d'être averti lorsque de nouveaux propriétaires sont ajoutés ou supprimés. 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 la page Optimisation des coûts pour la suite Google Cloud Operations.

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 Cloud Console.

    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.serviceName="cloudresourcemanager.googleapis.com")
      AND (ProjectOwnership OR projectOwnerInvitee)
      OR (protoPayload.serviceData.policyDelta.bindingDeltas.action="REMOVE"
      AND protoPayload.serviceData.policyDelta.bindingDeltas.role="roles/owner")
      OR (protoPayload.serviceData.policyDelta.bindingDeltas.action="ADD"
      AND protoPayload.serviceData.policyDelta.bindingDeltas.role="roles/owner")
    

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

Créer une règle d'alerte

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

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

  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 , puis sur Créer une alerte à partir de la métrique. Si vous êtes invité à ajouter votre projet à un espace de travail, effectuez cette démarche.

  4. Sur la page qui s'affiche, cliquez sur Alertes dans le menu de navigation.

  5. Sous Que voulez-vous surveiller ?, cliquez sur Ajouter une condition, puis renseignez la boîte de dialogue pour définir les ressources surveillées et les conditions de déclenchement des alertes. Pour plus d'informations sur les champs d'une condition, consultez la page Spécifier des conditions.

  6. Lorsque vous avez terminé, cliquez sur Ajouter, puis sur Suivant.

  7. Sous Qui doit être informé ?, cliquez sur la liste déroulante Canaux de notification, puis sélectionnez le mode de notification souhaité. Pour plus d'informations, consultez la page Gérer les canaux de notification.

  8. Cliquez sur OK, puis sur Suivant.

  9. Sous Quelles sont les étapes pour résoudre le problème ?, définissez un nom d'alerte.

  10. Cliquez sur Enregistrer.

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

POD_SECURITY_POLICY_DISABLED

Cet objet PodSecurityPolicy est désactivé sur un cluster GKE.

Une stratégie PodSecurityPolicy est une ressource de contrôleur d'admission qui valide les demandes de création et de mise à jour de pods sur un cluster. Les clusters n'acceptent pas les pods qui ne répondent pas aux conditions définies dans PodSecurityPolicy.

Pour corriger ce résultat, définissez et autorisez les règles PodSecurityPolicies, puis activez le contrôleur PodSecurityPolicy. Pour obtenir des instructions, consultez la page Utiliser PodSecurityPolicies.

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

PRIMITIVE_ROLES_USED

Un utilisateur possède l'un des rôles de base IAM suivants: roles/owner, roles/editor ou roles/viewer. Ces rôles sont trop permissifs et ne doivent pas être utilisés. Ils doivent plutôt être attribués par projet.

Pour en savoir plus, consultez la page Comprendre les rôles.

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

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

    Accéder à la stratégie IAM

  2. Pour chaque utilisateur attribué à un rôle primitif, envisagez plutôt d'utiliser des rôles plus précis.

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

PRIVATE_CLUSTER_DISABLED

Un cluster GKE possède un cluster privé désactivé.

Les nœuds de clusters privés ne peuvent utiliser que des adresses IP privées. Cette fonctionnalité limite l'accès Internet sortant pour les nœuds. Si un nœud de cluster ne dispose pas d'une adresse IP publique, il n'est pas visible ni exposé sur le réseau Internet public. Vous pouvez toutefois utiliser un équilibreur de charge interne pour acheminer le trafic vers ce nœud. Pour plus d'informations, consultez la section Clusters privés.

Vous ne pouvez pas créer un cluster privé à partir d'un cluster existant. Pour corriger ce résultat, créez un cluster privé :

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

    Accéder à la page "Clusters Kubernetes"

  2. Cliquez sur Create Cluster (Créer le cluster).

  3. Dans le menu de navigation, sous Cluster, sélectionnez Networking (Mise en réseau).

  4. Sélectionnez la case d'option Private cluster (Cluster privé).

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

  6. Cliquez sur Create (Créer).

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

PRIVATE_GOOGLE_ACCESS_DISABLED

Il existe des sous-réseaux privés sans accès aux API publiques Google.

L'accès privé à Google permet aux instances de VM n'ayant que des adresses IP internes (privées) d'atteindre les adresses IP publiques des API et des services Google.

Pour plus d'informations, consultez la section Configurer l'accès privé à Google.

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

  1. Accédez à la page Réseaux VPC dans 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 des détails du sous-réseau, cliquez sur 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.

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

PUBLIC_BUCKET_ACL

Un bucket est public et accessible sur Internet par tous les internautes.

Pour en savoir plus, consultez la page Présentation du contrôle des accès.

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

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

    Accéder au navigateur Cloud Storage

  2. Sélectionnez le bucket répertorié dans le résultat de l'analyse de l'état de la sécurité.

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

  4. À côté de Afficher par, cliquez sur Rôles.

  5. Dans le champ Filtre, recherchez allUsers et allAuthenticatedUsers.

  6. Cliquez sur Supprimer pour supprimer toutes les autorisations IAM accordées à allUsers et allAuthenticatedUsers.

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

PUBLIC_COMPUTE_IMAGE

Une image Compute Engine est publique et tous les internautes peuvent y accéder. allUsers représente n'importe quel internaute, tandis que allAuthenticatedUsers représente toute personne authentifiée avec un compte Google. Aucune de ces personnes n'est limitée aux utilisateurs de votre organisation.

Les images Compute Engine peuvent contenir des informations sensibles telles que des clés de chiffrement ou des logiciels sous licence. Ces informations sensibles ne doivent pas être accessibles publiquement. Si vous souhaitez rendre cette image Compute publique, assurez-vous qu'elle ne contient aucune information sensible.

Pour en savoir plus, consultez la page Présentation du contrôle des accès.

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

  1. Accédez à la page Images Compute Engine dans Cloud Console.

    Accéder aux images Compute Engine

  2. Cochez la case à côté de l'image public-image (Image publique), puis cliquez sur Afficher le panneau d'informations.

  3. Dans la zone Filtre, recherchez les membres allUsers et allAuthenticatedUsers.

  4. Développez le rôle au sein duquel vous souhaitez supprimer des utilisateurs.

  5. Cliquez sur Supprimer pour retirer un membre de ce rôle.

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

PUBLIC_DATASET

Les ensembles de données BigQuery sont publics et accessibles à tous les internautes. Le membre IAM allUsers représente n'importe quel internaute, tandis qu'allAuthenticatedUsers représente toute personne connectée à un service Google. Aucun de ces membres ne se limite aux utilisateurs de votre organisation.

Pour en savoir plus, consultez la page Contrôler l'accès aux ensembles de données.

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

  1. Accédez à la page Ensemble de données BigQuery de Cloud Console.

    Accéder à la page "Ensemble de données BigQuery"

  2. Cliquez sur Partager l'ensemble de données.

  3. Dans le panneau Autorisations d'ensemble de données, utilisez le champ Rechercher des comptes principaux pour rechercher allUsers et allAuthenticatedUsers, puis supprimez l'accès de ces comptes principaux.

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

PUBLIC_IP_ADDRESS

Une instance Compute Engine possède une adresse IP publique.

Pour réduire la surface d'attaque de votre organisation, évitez d'attribuer des adresses IP publiques à vos VM. Il se peut que les instances arrêtées déclenchent tout de même un résultat de type "adresse IP publique", par exemple si les interfaces réseau sont configurées pour attribuer une adresse IP publique éphémère au démarrage. Assurez-vous que les configurations réseau pour les instances arrêtées n'incluent pas l'accès externe.

Pour en savoir plus, consultez la section Se connecter en toute sécurité aux instances de VM.

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

  1. Accédez à la page Instances de VM de Cloud Console.

    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 Modifier.

  4. Pour chaque interface sous Interfaces réseau, cliquez sur Modifier et définissez Adresse IP externe sur Aucun.

  5. Cliquez sur OK, puis sur Enregistrer.

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

PUBLIC_LOG_BUCKET

Un bucket de stockage est public et utilisé comme récepteur de journaux, ce qui signifie que n'importe qui sur Internet peut accéder aux journaux stockés dans ce bucket. allUsers représente n'importe quel utilisateur sur Internet, tandis que allAuthenticatedUsers représente toute personne connectée à un service Google. Aucun des deux ne se limite aux utilisateurs de votre organisation.

Pour en savoir plus, consultez la page Présentation du contrôle des accès.

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

  1. Accédez à la page du navigateur Cloud Storage dans Cloud Console.

    Accéder au navigateur Cloud Storage

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

  3. Cliquez sur l'onglet Autorisations.

  4. Supprimez allUsers et allAuthenticatedUsers de la liste des comptes principaux.

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

PUBLIC_SQL_INSTANCE

Votre instance SQL comprend 0.0.0.0/0 comme réseau autorisé. Cela signifie que des clients IPv4 peuvent traverser le pare-feu du réseau et tenter de se connecter à votre instance, y compris des clients que vous ne souhaitiez pas autoriser. Les clients ont toujours besoin d'identifiants valides pour se connecter à votre instance.

Pour plus d'informations, consultez la section Autoriser avec des réseaux autorisés.

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

  1. Accédez à la page Instances Cloud SQL dans Cloud Console.

    Accéder à la page Instances Cloud SQL

  2. Sélectionnez l'instance répertoriée dans le résultat de l'analyse de l'état de la sécurité.

  3. Cliquez sur Modifier.

  4. Dans le panneau de navigation, cliquez sur Connexions.

  5. Sous Réseaux autorisés, supprimez 0.0.0.0/0 et ajoutez des adresses IP ou des plages d'adresses IP spécifiques que vous souhaitez autoriser à se connecter à votre instance.

  6. Cliquez sur OK, puis sur Enregistrer.

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

PUBSUB_CMEK_DISABLED

Un sujet Pub/Sub n'est pas chiffré avec des 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 corriger ce résultat, supprimez le sujet existant et créez-en un autre :

  1. Accédez à la page Sujets de Pub/Sub dans Cloud Console.

    Accéder aux sujets

  2. Si nécessaire, sélectionnez le projet contenant le sujet Pub/Sub.

  3. Cochez la case située à côté du sujet répertorié dans le résultat, puis cliquez sur Supprimer.

  4. Pour créer un sujet Pub/Sub avec CMEK activé, consultez la page Utiliser des clés de chiffrement gérées par le client. CMEK entraîne des coûts supplémentaires liés à Cloud KMS.

  5. Publiez les résultats ou d'autres données dans le sujet PubPub/Sub compatible avec CMEK.

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

ROUTE_NOT_MONITORED

Les statistiques et les alertes de journal ne sont pas configurées pour surveiller les modifications apportées à la route de réseau VPC.

Les routes Google Cloud sont une série de destinations et de sauts qui définissent le chemin du trafic réseau entre une instance de VM et une adresse IP de destination. En surveillant les modifications apportées aux tables de routage, vous pouvez vous assurer que tout le trafic VPC transite par un chemin attendu.

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 la page Optimisation des coûts pour la suite Google Cloud Operations.

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 Cloud Console.

    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_route"
      AND protoPayload.methodName="compute.routes.delete"
      OR protoPayload.methodName="compute.routes.insert"
    

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

Créer une règle d'alerte

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

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

  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 , puis sur Créer une alerte à partir de la métrique. Si vous êtes invité à ajouter votre projet à un espace de travail, effectuez cette démarche.

  4. Sur la page qui s'affiche, cliquez sur Alertes dans le menu de navigation.

  5. Sous Que voulez-vous surveiller ?, cliquez sur Ajouter une condition, puis renseignez la boîte de dialogue pour définir les ressources surveillées et les conditions de déclenchement des alertes. Pour plus d'informations sur les champs d'une condition, consultez la page Spécifier des conditions.

  6. Lorsque vous avez terminé, cliquez sur Ajouter, puis sur Suivant.

  7. Sous Qui doit être informé ?, cliquez sur la liste déroulante Canaux de notification, puis sélectionnez le mode de notification souhaité. Pour plus d'informations, consultez la page Gérer les canaux de notification.

  8. Cliquez sur OK, puis sur Suivant.

  9. Sous Quelles sont les étapes pour résoudre le problème ?, définissez un nom d'alerte.

  10. Cliquez sur Enregistrer.

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

REDIS_ROLE_USED_ON_ORG

Un rôle IAM Redis est attribué au niveau de l'organisation ou du dossier.

Les rôles Redis IAM suivants ne doivent être attribués que par projet, et non au niveau de l'organisation ou du dossier :

  • roles/redis.admin
  • roles/redis.viewer
  • roles/redis.editor

Pour en savoir plus, consultez la page Contrôle des accès et autorisations.

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

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

    Accéder à la stratégie IAM

  2. Supprimez les rôles IAM Redis indiqués dans le résultat et ajoutez-les à chaque projet.

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

RELEASE_CHANNEL_DISABLED

Un cluster GKE n'est pas abonné à une version disponible.

Abonnez-vous à une version disponible pour automatiser les mises à niveau de version sur le cluster GKE. Ces fonctionnalités réduisent également la complexité de la gestion des versions en termes de nombre de fonctionnalités et de niveau de stabilité requis. Pour en savoir plus, consultez la page Versions disponibles.

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

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

    Accéder à la page "Clusters Kubernetes"

  2. Dans la section Paramètres de base du cluster, cliquez sur l'icône de modification () correspondant à la ligne Version disponible.

    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 Version disponible, puis la version disponible à laquelle vous souhaitez vous abonner.

    Si la version du plan de contrôle de votre cluster ne peut pas être mise à niveau vers une version disponible, cette version peut être désactivée.

  4. Cliquez sur Save Changes (Enregistrer les modifications).

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

RSASHA1_FOR_SIGNING

RSASHA1 est utilisé pour la signature de clé dans les zones Cloud DNS. L'algorithme utilisé pour la signature des clés ne doit pas être faible.

Pour corriger ce résultat, remplacez l'algorithme par un algorithme recommandé en suivant le guide Utiliser les options de signature avancées.

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

SERVICE_ACCOUNT_KEY_NOT_ROTATED

La clé d'un compte de service géré par l'utilisateur n'a pas subi de rotation depuis plus de 90 jours.

Vous devez alterner les clés de compte de service gérées par l'utilisateur tous les 90 jours pour vous assurer que l'accès aux données est impossible avec une ancienne clé qui aurait été perdue, compromise ou volée. Pour en savoir plus, consultez la page Gérer des clés de compte de service.

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

  1. Accédez à la page Comptes de service dans Cloud Console.

    Accéder à la page "Comptes de service"

  2. Si nécessaire, sélectionnez le projet indiqué dans le résultat.

  3. Dans la liste des comptes de service, recherchez celui qui figure dans le résultat, puis cliquez sur Supprimer. Avant de continuer, réfléchissez à l'impact qu'une suppression de compte de service pourrait avoir sur vos ressources de production.

  4. Créez une clé de compte de service pour remplacer la clé supprimée. Pour plus d'informations, consultez la page Créer des clés de compte de service.

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

SERVICE_ACCOUNT_ROLE_SEPARATION

Plusieurs autorisations de compte de service ont été attribuées à un ou plusieurs comptes principaux de votre organisation. Aucun compte ne doit disposer simultanément de Administrateur de compte de service et d'autres autorisations de compte 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 IAM de Cloud Console.

    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 Modifier à côté d'un compte principal.
    3. Pour supprimer des autorisations, cliquez sur Supprimer à côté de l'option Administrateur de compte de service. Si vous souhaitez supprimer toutes les autorisations de compte de service, cliquez sur Supprimer à côté de toutes les autres autorisations.
  3. Cliquez sur Enregistrer.

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

SHIELDED_VM_DISABLED

La VM protégée est désactivée sur cette instance Compute Engine.

Les VM protégées sont des machines virtuelles (VM) hébergées sur Google Cloud Platform, renforcées par un ensemble de paramètres de sécurité conçus pour éliminer les rootkits et les bootkits. Les VM protégées permettent de garantir que le bootloader et le micrologiciel sont signés et validés. En savoir plus sur les VM protégées.

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

  1. Accédez à la page Instances de VM de Cloud Console.

    Accéder à la page "Instances de VM"

  2. Sélectionnez l'instance associée au résultat de l'analyse de l'état de la sécurité.

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

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

  5. Dans la section VM protégée, cochez les options Activer vTPM et Activer la surveillance de l'intégrité pour activer la VM protégée.

  6. Si vous n'utilisez aucun pilote personnalisé ou non signé, vous pouvez également activer le démarrage sécurisé.

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

  8. Cliquez sur Démarrer pour démarrer l'instance.

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

SQL_CMEK_DISABLED

Une instance de base de données SQL 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 la présentation des clés CMEK de votre produit : Cloud SQL pour MySQL, Cloud SQL pour PostgreSQL ou Cloud SQL pour SQL Server. 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 Instances Cloud SQL dans Cloud Console.

    Accéder à la page Instances Cloud SQL

  2. Sélectionnez l'instance répertoriée dans le résultat de l'analyse de l'état de la sécurité.

  3. Cliquez sur Supprimer.

  4. Pour créer une instance sur laquelle CMEK est activé, suivez les instructions permettant de configurer CMEK pour votre produit :

    1. Cloud SQL pour MySQL
    2. Cloud SQL pour PostgreSQL
    3. Cloud SQL pour SQL Server

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

SQL_CONTAINED_DATABASE_AUTHENTICATION

L'option de base de données contenant l'authentification de base de données n'est pas défini sur Désactivé pour une instance de base de données Cloud SQL pour SQL Server.

L'option contained database authentication (authentification de la base de données autonome) permet de créer ou d'associer des bases de données autonomes au moteur de base de données. Une base de données autonome contient tous les paramètres et métadonnées nécessaires à la définition de la base de données et ne possède aucune dépendance de configuration sur l'instance du moteur de base de données où elle est installée.

L'activation de cet indicateur n'est pas recommandée pour les raisons suivantes :

  • Les utilisateurs peuvent se connecter à la base de données sans authentification au niveau du moteur.
  • L'isolation de la base de données du moteur permet de déplacer la base de données vers une autre instance SQL Server.

Les bases de données autonomes sont confrontées à des menaces uniques qui doivent être comprises et contrées par les administrateurs de moteur de base de données SQL Server. La plupart des menaces résultent du processus d'authentification USER WITH PASSWORD (utilisateur avec mot de passe), ce qui déplace la limite d'authentification du moteur de base de données jusqu'à la base de données.

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

  1. Accédez à la page Instances Cloud SQL dans Cloud Console.

    Accéder à la page Instances Cloud SQL

  2. Sélectionnez l'instance répertoriée dans le résultat de l'analyse de l'état de la sécurité.

  3. Cliquez sur Modifier.

  4. Dans la section Options de base de données, définissez l'option de base de données contained database authentication (authentification de la base de données autonome) avec la valeur Désactivé.

  5. Cliquez sur Enregistrer. La nouvelle configuration apparaît sur la page Présentation de l'instance.

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

SQL_CROSS_DB_OWNERSHIP_CHAINING

L'indicateur de base de données cross dbproperty chainchaining n'est pas défini sur Désactivé pour une instance de base de données Cloud SQL pour SQL Server.

L'option cross db ownership chaining (chaînage de propriété entre les bases de données) vous permet de contrôler le chaînage de propriété entre les bases de données au niveau de la base de données, ou d'autoriser ce chaînage pour toutes les instructions de base de données.

Il n'est pas recommandé d'activer cette option, sauf si toutes les bases de données hébergées par l'instance SQL Server participent à un chaînage de propriété entre les bases de données et que vous connaissez les implications de ce paramètre sur la sécurité.

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 Instances Cloud SQL dans Cloud Console.

    Accéder à la page Instances Cloud SQL

  2. Sélectionnez l'instance répertoriée dans le résultat de l'analyse de l'état de la sécurité.

  3. Cliquez sur Modifier.

  4. Dans la section Options de base de données, définissez l'option de base de données cross db ownership chaining (chaînage de propriété entre les bases de données) avec la valeur Désactivé.

  5. Cliquez sur Enregistrer. La nouvelle configuration apparaît sur la page Présentation de l'instance.

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

SQL_INSTANCE_NOT_MONITORED

Les statistiques et les alertes de journal ne sont pas configurées pour surveiller les modifications apportées à l'instance Cloud SQL.

Une mauvaise configuration des options des instances SQL peut entraîner des risques de sécurité. La désactivation des options de sauvegarde automatique et de haute disponibilité peut avoir un impact sur la continuité de l'activité et ne pas limiter les réseaux autorisés peut augmenter l'exposition aux réseaux non approuvés. La surveillance des modifications apportées à la configuration de l'instance SQL vous permet de réduire le temps nécessaire à la détection et à la correction des erreurs de configuration.

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 la page Optimisation des coûts pour la suite Google Cloud Operations.

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 Cloud Console.

    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="cloudsql.instances.update"
    

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

Créer une règle d'alerte

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

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

  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 , puis sur Créer une alerte à partir de la métrique. Si vous êtes invité à ajouter votre projet à un espace de travail, effectuez cette démarche.

  4. Sur la page qui s'affiche, cliquez sur Alertes dans le menu de navigation.

  5. Sous Que voulez-vous surveiller ?, cliquez sur Ajouter une condition, puis renseignez la boîte de dialogue pour définir les ressources surveillées et les conditions de déclenchement des alertes. Pour plus d'informations sur les champs d'une condition, consultez la page Spécifier des conditions.

  6. Lorsque vous avez terminé, cliquez sur Ajouter, puis sur Suivant.

  7. Sous Qui doit être informé ?, cliquez sur la liste déroulante Canaux de notification, puis sélectionnez le mode de notification souhaité. Pour plus d'informations, consultez la page Gérer les canaux de notification.

  8. Cliquez sur OK, puis sur Suivant.

  9. Sous Quelles sont les étapes pour résoudre le problème ?, définissez un nom d'alerte.

  10. Cliquez sur Enregistrer.

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

SQL_LOCAL_INFILE

L'option de base de données local_infile n'est pas définie sur Désactivé pour une instance de base de données Cloud SQL pour MySQL. En raison de problèmes de sécurité associés à l'indicateur local_infile, vous devez le désactiver. 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 Instances Cloud SQL dans Cloud Console.

    Accéder à la page Instances Cloud SQL

  2. Sélectionnez l'instance répertoriée dans le résultat de l'analyse de l'état de la sécurité.

  3. Cliquez sur Modifier.

  4. Dans la section Options de base de données, définissez l'option de base de données local_infile avec la valeur Désactivé.

  5. Cliquez sur Enregistrer. La nouvelle configuration apparaît sur la page Présentation de l'instance.

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

SQL_LOG_CHECKPOINTS_DISABLED

L'option log_disconnections de la base de données n'est pas définie sur Activé pour une instance de base de données Cloud SQL pour PostgreSQL.

L'activation de log_checkpoints entraîne la journalisation des points de contrôle et des points de redémarrage dans le journal du serveur. Certaines statistiques sont incluses dans les messages de journal, par exemple le nombre de tampons écrits et le temps passé à les écrire.

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 Instances Cloud SQL dans Cloud Console.

    Accéder à la page Instances Cloud SQL

  2. Sélectionnez l'instance répertoriée dans le résultat de l'analyse de l'état de la sécurité.

  3. Cliquez sur Modifier.

  4. Dans la section Options de base de données, définissez l'option de base de données log_checkpoints avec la valeur Activé.

  5. Cliquez sur Enregistrer. La nouvelle configuration apparaît sur la page Présentation de l'instance.

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

SQL_LOG_CONNECTIONS_DISABLED

L'option log_disconnections de la base de données n'est pas définie sur Activé pour une instance de base de données Cloud SQL pour PostgreSQL.

L'activation du paramètre log_connections entraîne la journalisation des tentatives de connexions au serveur et des authentifications client réussies. Les journaux peuvent être utiles pour résoudre des problèmes et confirmer les tentatives de connexion au serveur inhabituelles.

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 Instances Cloud SQL dans Cloud Console.

    Accéder à la page Instances Cloud SQL

  2. Sélectionnez l'instance répertoriée dans le résultat de l'analyse de l'état de la sécurité.

  3. Cliquez sur Modifier.

  4. Dans la section Options de base de données, définissez l'option de base de données log_connections avec la valeur Activé.

  5. Cliquez sur Enregistrer. La nouvelle configuration apparaît sur la page Présentation de l'instance.

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

SQL_LOG_DISCONNECTIONS_DISABLED

L'option log_disconnections de la base de données Cloud SQL pour PostgreSQL n'est pas définie sur Activé.

L'activation du paramètre log_disconnections crée des entrées de journal à la fin de chaque session. Les journaux sont utiles pour résoudre les problèmes et confirmer une activité inhabituelle sur une période donnée. 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 Instances Cloud SQL dans Cloud Console.

    Accéder à la page Instances Cloud SQL

  2. Sélectionnez l'instance répertoriée dans le résultat de l'analyse de l'état de la sécurité.

  3. Cliquez sur Modifier.

  4. Dans la section Options de base de données, définissez l'option de base de données log_disconnections avec la valeur Activé.

  5. Cliquez sur Enregistrer. La nouvelle configuration apparaît sur la page Présentation de l'instance.

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

SQL_LOG_LOCK_WAITS_DISABLED

L'option de base de données log_lock_waits n'est pas définie sur Activé pour une instance de base de données Cloud SQL pour PostgreSQL.

L'activation du paramètre log_lock_waits crée des entrées de journal lorsque le temps nécessaire à l'acquisition d'un verrou par une session est supérieur au délai deadlock_timeout. Les journaux sont utiles pour déterminer si les temps de verrouillage causent de mauvaises performances.

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 Instances Cloud SQL dans Cloud Console.

    Accéder à la page Instances Cloud SQL

  2. Sélectionnez l'instance répertoriée dans le résultat de l'analyse de l'état de la sécurité.

  3. Cliquez sur Modifier.

  4. Dans la section Options de base de données, définissez l'option de base de données log_lock_waits sur Activé.

  5. Cliquez sur Enregistrer. La nouvelle configuration apparaît sur la page Présentation de l'instance.

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

SQL_LOG_MIN_DURATION_STATEMENT_ENABLED

L'indicateur de base de données log_min_duration_statement n'est pas défini sur -1 pour une instance de base de données Cloud SQL pour PostgreSQL.

L'option log_min_duration_statement entraîne la journalisation des instructions SQL dont la durée d'exécution dépasse un seuil spécifié. Envisagez de désactiver ce paramètre, car les instructions SQL peuvent contenir des informations sensibles qui ne doivent pas être consignées. 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 Instances Cloud SQL dans Cloud Console.

    Accéder à la page Instances Cloud SQL

  2. Sélectionnez l'instance répertoriée dans le résultat de l'analyse de l'état de la sécurité.

  3. Cliquez sur Modifier.

  4. Dans la section Options de base de données, définissez l'option de base de données log_min_duration_statement sur la valeur -1.

  5. Cliquez sur Enregistrer. La nouvelle configuration apparaît sur la page Présentation de l'instance.

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

SQL_LOG_MIN_ERROR_STATEMENT

L'option log_min_duration_statement n'est pas définie correctement pour une instance de base de données Cloud SQL 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 avec les messages associés aux instructions en état d'erreur. Plus le niveau de gravité est élevé, moins le nombre de messages enregistrés est important.

Si l'option log_min_error_statement n'est pas définie sur la valeur souhaitée, il est possible que certains messages ne soient pas classés comme messages d'erreur. Un niveau de gravité défini sur une valeur trop basse a pour effet d'augmenter le nombre de messages et de rendre plus difficile l'identification des erreurs réelles. Si un niveau de gravité est défini sur une valeur trop élevée, il est possible que les messages correspondant à des erreurs réelles 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 Instances Cloud SQL dans Cloud Console.

    Accéder à la page Instances Cloud SQL

  2. Sélectionnez l'instance répertoriée dans le résultat de l'analyse de l'état de la sécurité.

  3. Cliquez sur Modifier.

  4. Dans la section Options de base de données, définissez l'option de base de données log_min_duration_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
  5. Cliquez sur Enregistrer. La nouvelle configuration apparaît sur la page Présentation de l'instance.

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

SQL_LOG_TEMP_FILES

L'indicateur de base de données log_temp_files n'est pas défini sur 0 pour une instance de base de données Cloud SQL pour PostgreSQL.

Des fichiers temporaires peuvent être créés pour les tris, les hachages et les résultats de requête temporaires. Lorsque l'option log_temp_files est définie sur 0, tous les fichiers temporaires sont journalisés. Cela permet d'identifier d'éventuels problèmes de performances. 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 Instances Cloud SQL dans Cloud Console.

    Accéder à la page Instances Cloud SQL

  2. Sélectionnez l'instance répertoriée dans le résultat de l'analyse de l'état de la sécurité.

  3. Cliquez sur Modifier.

  4. Dans la section Options de base de données, définissez l'option de base de données log_temp_files sur 0.

  5. Cliquez sur Enregistrer. La nouvelle configuration apparaît sur la page Présentation de l'instance.

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

SQL_NO_ROOT_PASSWORD

Une instance de base de données MySQL ne possède pas de mot de passe défini pour le compte racine. Vous devez ajouter un mot de passe à l'instance de base de données MySQL. Pour en savoir plus, consultez la page Utilisateurs MySQL.

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

  1. Accédez à la page Instances Cloud SQL dans Cloud Console.

    Accéder à la page Instances Cloud SQL

  2. Sélectionnez l'instance répertoriée dans le résultat de l'analyse de l'état de la sécurité.

  3. Sur la page Détails de l'instance qui s'affiche, sélectionnez l'onglet Utilisateurs.

  4. À côté de l'utilisateur root, cliquez sur Plus , puis sélectionnez Modifier le mot de passe.

  5. Saisissez un nouveau mot de passe sécurisé, puis cliquez sur OK.

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

SQL_PUBLIC_IP

Une base de données Cloud SQL possède une adresse IP publique.

Pour réduire la surface d'attaque de votre organisation, les bases de données Cloud SQL ne doivent pas posséder d'adresses IP 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 "Instances Cloud SQL" dans Cloud Console.

    Accéder à la page Instances Cloud SQL

  2. Sélectionnez l'instance répertoriée dans le résultat de l'analyse de l'état de la sécurité.

  3. Dans l'onglet Connexions, décochez la case Adresse IP publique.

  4. Si l'instance n'est pas déjà configurée pour utiliser une adresse IP privée, consultez la page Configurer une adresse IP privée pour une instance existante.

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

SQL_WEAK_ROOT_PASSWORD

Une instance de base de données MySQL possède un mot de passe peu sécurisé défini pour le compte racine. Vous devez définir un mot de passe sécurisé pour l'instance. Pour en savoir plus, consultez la page Utilisateurs MySQL.

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

  1. Accédez à la page "Instances Cloud SQL" dans Cloud Console.

    Accéder à la page Instances Cloud SQL

  2. Sélectionnez l'instance répertoriée dans le résultat de l'analyse de l'état de la sécurité.

  3. Sur la page Détails de l'instance qui s'affiche, sélectionnez l'onglet Utilisateurs.

  4. À côté de l'utilisateur root, cliquez sur Plus , puis sélectionnez Modifier le mot de passe.

  5. Saisissez un nouveau mot de passe sécurisé, puis cliquez sur OK.

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

SSL_NOT_ENFORCED

Une instance de base de données Cloud SQL 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 SQL doivent utiliser le protocole SSL. Apprenez-en plus sur la configuration de SSL/TLS.

Pour corriger ce résultat, autorisez uniquement les connexions SSL pour vos instances SQL :

  1. Accédez à la page "Instances Cloud SQL" dans Cloud Console.

    Accéder à la page Instances Cloud SQL

  2. Sélectionnez l'instance répertoriée dans le résultat de l'analyse de l'état de la sécurité.

  3. Dans l'onglet Connexions, cliquez sur Autoriser uniquement les connexions SSL.

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

TOO_MANY_KMS_USERS

Limitez à trois le nombre d'utilisateurs principaux autorisés à utiliser des clés cryptographiques. Les rôles prédéfinis suivants accordent des autorisations permettant de chiffrer, déchiffrer ou signer des données à l'aide de clés cryptographiques :

  • roles/owner
  • roles/cloudkms.cryptoKeyEncrypterDecrypter
  • roles/cloudkms.cryptoKeyEncrypter
  • roles/cloudkms.cryptoKeyDecrypter
  • roles/cloudkms.signer
  • roles/cloudkms.signerVerifier

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 Clés Cloud KMS de Cloud Console.

    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. Cochez la case à côté de la version principale, puis cliquez sur Afficher le panneau d'informations.

  5. Réduisez à trois ou moins le nombre de comptes principaux autorisés à chiffrer, déchiffrer ou signer des données. Pour révoquer les autorisations, cliquez sur Supprimer à côté de chaque compte principal.

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

USER_MANAGED_SERVICE_ACCOUNT_KEY

Un utilisateur gère une clé de compte de service.

Les comptes de service ne doivent pas comporter de clés gérées par l'utilisateur, car elles peuvent facilement être divulguées. Pour en savoir plus, consultez la page Gérer des clés de compte de service.

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

  1. Accédez à la page Comptes de service dans Cloud Console.

    Accéder à la page "Comptes de service"

  2. Si nécessaire, sélectionnez le projet indiqué dans le résultat.

  3. Supprimez les clés de compte de service gérées par l'utilisateur indiquées dans le résultat, si elles ne sont pas utilisées par une application.

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

WEAK_SSL_POLICY

Une instance Compute Engine a une stratégie SSL peu sécurisée.

Les équilibreurs de charge HTTPS et SSL utilisent des règles SSL pour déterminer le protocole et les suites de chiffrement utilisés dans les connexions TLS établies entre les utilisateurs et Internet. Ces connexions chiffrent les données sensibles pour empêcher les personnes malveillantes d'y accéder. Une règle SSL faible permet aux clients utilisant des versions obsolètes de TLS de se connecter à une suite de chiffrement ou un protocole moins sécurisés. Pour obtenir la liste des suites de chiffrement recommandées et obsolètes, consultez la [page des paramètres TLS iana.org]. (https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4)

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

  1. Accédez à la page "Pools cibles" de Cloud Console.

    Accéder aux proxys cibles

  2. Recherchez le proxy cible indiqué dans le résultat et notez les règles de transfert dans la colonne Utilisée par.

  3. Pour créer ou mettre à jour une règle SSL existante, consultez la page Utiliser des règles SSL. La règle doit avoir une version TLS minimale de 1.2 et un profil moderne ou restreint.

  4. Pour utiliser un profil personnalisé, assurez-vous que les suites de chiffrement suivantes sont désactivées :

    • TLS_RSA_WITH_AES_128_GCM_SHA256
    • TLS_RSA_WITH_AES_256_GCM_SHA384
    • TLS_RSA_WITH_AES_128_CBC_SHA
    • TLS_RSA_WITH_AES_256_CBC_SHA
    • TLS_RSA_WITH_3DES_EDE_CBC_SHA
  5. Appliquez la règle SSL à chaque règle de transfert que vous avez notée précédemment.

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

WEB_UI_ENABLED

L'interface utilisateur Web de GKE (tableau de bord) est activée.

L'interface Web de Kubernetes est protégée par un compte de service Kubernetes hautement privilégié, qui peut être utilisé de manière abusive s'il est compromis. Si vous utilisez déjà Cloud Console, l'interface Web de Kubernetes étend inutilement votre surface d'attaque. Découvrez comment désactiver l'interface Web de Kubernetes.

Pour corriger ce résultat, désactivez l'interface Web de Kubernetes :

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

    Accéder à la page "Clusters Kubernetes"

  2. Cliquez sur le nom du cluster répertorié dans le résultat de l'analyse de l'état de la sécurité.

  3. Cliquez sur 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. Cliquez sur Modules complémentaires. La section se développe pour afficher les modules complémentaires disponibles.

  5. Dans la liste déroulante Tableau de bord Kubernetes, sélectionnez Désactivé.

  6. Cliquez sur Enregistrer.

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

WORKLOAD_IDENTITY_DISABLED

Workload Identity est désactivé sur un cluster GKE.

Workload Identity est la solution recommandée pour accéder aux services Google Cloud à partir de GKE, car elle propose des propriétés de sécurité renforcée et simplifie la gestion. Son activation permet de protéger certaines métadonnées système potentiellement sensibles contre les charges de travail d'utilisateur exécutées sur votre cluster. En savoir plus sur la Dissimulation de métadonnées.

Pour corriger ce résultat, suivez le guide Activer Workload Identity sur un cluster.

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