Cette page fournit une liste de guides de référence et de techniques permettant de corriger les résultats de Security Health Analytics à l'aide de Security Command Center.
Vous devez disposer des rôles IAM (Identity and Access Management) appropriés pour afficher ou modifier les résultats, et pour accéder aux ressources Google Cloud ou les modifier. Si vous rencontrez des erreurs d'autorisation lorsque vous accédez à Security Command Center dans la consoleGoogle Cloud , demandez de l'aide à votre administrateur. Pour en savoir plus sur les rôles, consultez Contrôle des accès. Pour résoudre les erreurs de ressources, consultez la documentation des produits concernés.
Correction de Security Health Analytics
Cette section inclut des instructions correctives pour tous les résultats d'analyses de l'état de sécurité.
Pour les types de résultats mappés aux benchmarks CIS, les conseils de correction proviennent du Center for Internet Security (CIS), sauf indication contraire. Pour en savoir plus, consultez Détecteurs et conformité.
Désactivation automatique des résultats
Une fois que vous avez corrigé une faille ou une erreur de configuration, Security Health Analytics définit automatiquement l'état du résultat sur INACTIVE lors de la prochaine analyse. Si vous désactivez un détecteur dans Security Health Analytics, l'état de tous les résultats générés par ce détecteur est défini sur INACTIVE. Le temps nécessaire à Security Health Analytics pour définir un résultat corrigé sur INACTIVE dépend du moment où le résultat est corrigé et du calendrier de l'analyse qui le détecte.
Security Health Analytics définit également l'état d'un résultat sur INACTIVE lorsqu'une analyse détecte que la ressource concernée par le résultat a été supprimée. Si vous souhaitez supprimer un résultat pour une ressource supprimée de votre affichage en attendant que Security Health Analytics détecte que la ressource a été supprimée, vous pouvez le désactiver. Pour masquer un résultat, consultez Masquer des résultats dans Security Command Center.
N'utilisez pas la fonctionnalité de mise en sourdine pour masquer les résultats corrigés des ressources existantes.
Si le problème se reproduit et que Security Health Analytics restaure l'état ACTIVE du résultat, il est possible que vous ne voyiez pas le résultat réactivé, car les résultats mis en sourdine sont exclus de toute requête de résultat spécifiant NOT mute="MUTED", comme la requête de résultat par défaut.
Pour en savoir plus sur les intervalles d'analyse, consultez Types d'analyse Security Health Analytics.
Access Transparency disabled
Nom de la catégorie dans l'API : ACCESS_TRANSPARENCY_DISABLED
Les journaux Access Transparency enregistrent les actions des employés Google Cloud lorsqu'ils accèdent aux projets de votre organisation pour vous fournir une assistance. Activez Access Transparency pour enregistrer qui, au sein de Google Cloud , accède à vos informations, quand et pourquoi. Pour en savoir plus, consultez Access Transparency.
Pour activer Access Transparency sur un projet, celui-ci doit être associé à un compte de facturation.
Rôles requis
Pour obtenir les autorisations nécessaires pour effectuer cette tâche, demandez à votre administrateur de vous accorder le rôle IAM Administrateur de transparence des accès (roles/axt.admin) au niveau de l'organisation. Pour en savoir plus sur l'attribution de rôles, consultez la section Gérer les accès.
Ce rôle prédéfini contient les autorisations axt.labels.get et axt.labels.set, qui sont nécessaires pour effectuer cette tâche. Vous pouvez également obtenir ces autorisations avec un rôle personnalisé ou d'autres rôles prédéfinis.
Étapes de résolution
Pour corriger ce résultat, procédez comme suit :
Vérifiez les autorisations au niveau de votre organisation :
Accédez à la page Identity and Access Management de la consoleGoogle Cloud .
Si vous y êtes invité, sélectionnez l'organisation Google Cloud dans le menu de sélection.
Sélectionnez un projet Google Cloud au sein de l'organisation à l'aide du menu de sélection.
La fonctionnalité Access Transparency est configurée sur une page de Google Cloud projet, mais elle est activée pour l'ensemble de l'organisation.
Accédez à la page IAM et administration > Paramètres.
Cliquez sur Activer Access Transparency.
En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.
AlloyDB auto backup disabled
Nom de la catégorie dans l'API : ALLOYDB_AUTO_BACKUP_DISABLED
Les sauvegardes automatiques ne sont pas activées pour un cluster AlloyDB pour PostgreSQL.
Afin d'éviter de perdre des données, activez les sauvegardes automatiques pour votre cluster. Pour en savoir plus, consultez Configurer des sauvegardes automatiques supplémentaires.
Pour corriger ce résultat, procédez comme suit :
Accédez à la page des clusters AlloyDB pour PostgreSQL dans la consoleGoogle Cloud .
Cliquez sur un cluster dans la colonne Nom de la ressource.
Cliquez sur Protection des données.
Sous la section Règle de sauvegarde automatique, cliquez sur Modifier à la ligne Sauvegardes automatiques.
Cochez la case Automatiser les sauvegardes.
Cliquez sur Mettre à jour.
En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.
AlloyDB backups disabled
Nom de la catégorie dans l'API : ALLOYDB_BACKUPS_DISABLED
Les sauvegardes automatiques et continues ne sont pas activées pour un cluster AlloyDB pour PostgreSQL.
Afin d'éviter de perdre des données, activez les sauvegardes automatiques ou continues pour votre cluster. Pour en savoir plus, consultez Configurer des sauvegardes supplémentaires.
Pour corriger ce résultat, procédez comme suit :
Accédez à la page des clusters AlloyDB pour PostgreSQL dans la consoleGoogle Cloud .
Dans la colonne Nom de la ressource, cliquez sur le nom du cluster identifié dans le résultat.
Cliquez sur Protection des données.
Configurez une stratégie de sauvegarde.
En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.
AlloyDB CMEK disabled
Nom de la catégorie dans l'API : ALLOYDB_CMEK_DISABLED
Un cluster AlloyDB n'utilise pas de clés de chiffrement gérées par le client (CMEK).
Avec CMEK, les clés que vous créez et gérez dans Cloud KMS encapsulent les clés que Google utilise pour chiffrer vos données, vous permettant ainsi de mieux contrôler vos accès. Pour en savoir plus, consultez À propos de CMEK. CMEK entraîne des coûts supplémentaires liés à Cloud KMS.
Pour corriger ce résultat, procédez comme suit :
Accédez à la page des clusters AlloyDB pour PostgreSQL dans la consoleGoogle Cloud .
Dans la colonne Nom de la ressource, cliquez sur le nom du cluster identifié dans le résultat.
Cliquez sur Créer une sauvegarde. Définissez un ID de secours.
Cliquez sur Créer.
Dans la section Sauvegarder/Restaurer, cliquez sur Restaurer à côté de l'entrée ID de sauvegarde de votre choix.
Définissez un nouvel ID de cluster et un nouveau réseau.
Cliquez sur Options de chiffrement avancées. Sélectionnez la clé CMEK avec laquelle vous souhaitez chiffrer le nouveau cluster.
Cliquez sur Restaurer.
En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.
AlloyDB log min error statement severity
Nom de la catégorie dans l'API : ALLOYDB_LOG_MIN_ERROR_STATEMENT_SEVERITY
L'option de base de données log_min_error_statement n'est pas définie sur error ni sur une autre valeur recommandée pour une instance AlloyDB pour PostgreSQL.
L'option log_min_error_statement détermine si les instructions SQL provoquant des conditions d'erreur sont enregistrées dans les journaux du serveur. Les instructions SQL présentant un niveau de gravité supérieur ou égal à celui spécifié sont consignées. Plus le niveau de gravité est élevé, moins le nombre de messages enregistrés est important. Si elle est définie sur un niveau de gravité trop élevé, il se peut que les messages d'erreur ne soient pas consignés.
Pour en savoir plus, consultez la page Configurer des indicateurs de base de données.
Pour corriger ce résultat, procédez comme suit :
Accédez à la page des clusters AlloyDB pour PostgreSQL dans la consoleGoogle Cloud .
Cliquez sur le cluster dans la colonne Nom de la ressource.
Dans la section Instances de votre cluster, cliquez sur Modifier pour l'instance.
Cliquez sur Options de configuration avancées.
Dans la section Options, définissez l'option de base de données
log_min_error_statementsur l'une des valeurs recommandées suivantes, en fonction de la stratégie de journalisation de votre organisation.debug5debug4debug3debug2debug1infonoticewarningerror
Cliquez sur Mettre à jour l'instance.
En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.
AlloyDB log min messages
Nom de la catégorie dans l'API : ALLOYDB_LOG_MIN_MESSAGES
L'option de base de données log_min_messages d'une instance AlloyDB pour PostgreSQL n'est pas définie sur warning au minimum.
L'option log_min_messages contrôle les niveaux de message enregistrés dans les journaux du serveur. Plus le niveau de gravité est élevé, moins le nombre de messages enregistrés est important. Si vous définissez un seuil trop bas, la taille et la longueur des journaux stockés peuvent augmenter, ce qui risque de compliquer la recherche d'erreurs réelles.
Pour en savoir plus, consultez la page Configurer des indicateurs de base de données.
Pour corriger ce résultat, procédez comme suit :
Accédez à la page des clusters AlloyDB pour PostgreSQL dans la consoleGoogle Cloud .
Cliquez sur le cluster dans la colonne Nom de la ressource.
Dans la section Instances de votre cluster, cliquez sur Modifier pour l'instance.
Cliquez sur Options de configuration avancées.
Dans la section Options, définissez l'option de base de données
log_min_messagessur l'une des valeurs recommandées suivantes, en fonction de la stratégie de journalisation de votre organisation.debug5debug4debug3debug2debug1infonoticewarning
Cliquez sur Mettre à jour l'instance.
En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.
AlloyDB log error verbosity
Nom de la catégorie dans l'API : ALLOYDB_LOG_ERROR_VERBOSITY
L'option de base de données log_error_verbosity d'une instance AlloyDB pour PostgreSQL n'est pas définie sur default ou une autre valeur moins restrictive.
L'option log_error_verbosity contrôle la quantité de détails des messages consignés. Plus la verbosité est élevée, plus les messages enregistrés contiennent de détails.
Nous vous recommandons de définir cette option sur default ou sur une autre valeur moins restrictive.
Pour en savoir plus, consultez la page Configurer des indicateurs de base de données.
Pour corriger ce résultat, procédez comme suit :
Accédez à la page des clusters AlloyDB pour PostgreSQL dans la consoleGoogle Cloud .
Cliquez sur le cluster dans la colonne Nom de la ressource.
Dans la section Instances de votre cluster, cliquez sur Modifier pour l'instance.
Cliquez sur Options de configuration avancées.
Dans la section Options, définissez l'option de base de données
log_error_verbositysur l'une des valeurs recommandées suivantes, en fonction de la stratégie de journalisation de votre organisation.defaultverbose
Cliquez sur Mettre à jour l'instance.
En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.
AlloyDB Public IP
Nom de la catégorie dans l'API : ALLOYDB_PUBLIC_IP
Une instance de base de données AlloyDB pour PostgreSQL possède une adresse IP publique.
Pour réduire la surface d'attaque de votre organisation, utilisez des adresses IP privées plutôt que publiques. Les adresses IP privées offrent une sécurité réseau améliorée et une latence réduite pour votre application.
Pour corriger ce résultat, procédez comme suit :
Accédez à la page des clusters AlloyDB pour PostgreSQL dans la consoleGoogle Cloud .
Dans la colonne Nom de la ressource, cliquez sur le nom du cluster identifié dans le résultat.
Dans la section Instances de votre cluster, cliquez sur Modifier pour l'instance.
Dans la section Connectivité, décochez la case Activer les adresses IP publiques.
Cliquez sur Mettre à jour l'instance.
En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.
AlloyDB SSL not enforced
Nom de la catégorie dans l'API : ALLOYDB_SSL_NOT_ENFORCED
Une instance de base de données AlloyDB pour PostgreSQL ne nécessite pas que toutes les connexions entrantes utilisent SSL.
Pour éviter la fuite de données sensibles pendant leur transit via des communications non chiffrées, toutes les connexions entrantes à votre instance de base de données AlloyDB doivent utiliser le protocole SSL. Apprenez-en plus sur la configuration de SSL/TLS.
Pour corriger ce résultat, procédez comme suit :
Accédez à la page des clusters AlloyDB pour PostgreSQL dans la consoleGoogle Cloud .
Dans la colonne Nom de la ressource, cliquez sur le nom du cluster identifié dans le résultat.
Dans la section Instances de votre cluster, cliquez sur Modifier pour l'instance.
Sous la section Sécurité réseau, cochez la case Chiffrement SSL requis.
Cliquez sur Mettre à jour l'instance.
En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.
Admin service account
Nom de la catégorie dans l'API : ADMIN_SERVICE_ACCOUNT
Un compte de service au sein de votre organisation ou de votre projet bénéficie des droits d'administrateur, de propriétaire ou d'éditeur. Ces rôles disposent d'autorisations étendues et ne doivent pas être attribués à des comptes de service. Pour en savoir plus sur les comptes de service et les rôles disponibles, consultez la page Comptes de service.
Pour corriger ce résultat, procédez comme suit :
Accédez à la page de la stratégie IAM de la console Google Cloud .
Pour chaque compte principal identifié dans le résultat :
- Cliquez sur Modifier le compte principal à côté du compte principal.
- Pour supprimer des autorisations, cliquez sur Supprimer le rôle à côté du rôle.
- 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
Nom de la catégorie dans l'API : ALPHA_CLUSTER_ENABLED
Les fonctionnalités de cluster alpha sont activées pour un cluster Google Kubernetes Engine (GKE).
Les clusters alpha permettent aux utilisateurs de la première heure de tester des charges de travail exploitant de nouvelles fonctionnalités avant leur lancement public. Toutes les fonctionnalités de l'API GKE sont activées sur les clusters alpha, mais ceux-ci ne sont pas couverts par le contrat de niveau de service GKE. Ils ne reçoivent pas de mises à jour de sécurité. Les fonctionnalités de mise à niveau et de réparation automatiques des nœuds y sont désactivées, et ils ne peuvent pas être mis à niveau. Ils sont aussi automatiquement supprimés au bout de 30 jours.
Pour corriger ce résultat, procédez comme suit :
Les clusters alpha ne peuvent pas être désactivés. Vous devez créer un cluster avec les fonctionnalités alpha désactivées.
Accédez à la page Clusters Kubernetes de la console Google Cloud .
Cliquez sur Create (Créer).
Sélectionnez Configurer à côté du type de cluster que vous souhaitez créer.
Sous l'onglet Fonctionnalités, assurez-vous que l'option Activer les fonctionnalités alpha Kubernetes dans ce cluster est désactivée.
Cliquez sur Create (Créer).
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.
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
Nom de la catégorie dans l'API : API_KEY_APIS_UNRESTRICTED
Certaines clés API sont utilisées à trop grande échelle.
Les clés API sans restriction ne sont pas sécurisées, car elles peuvent être récupérées à partir d'appareils sur lesquels elles sont stockées ou visibles publiquement, par exemple à partir d'un navigateur. Conformément au principe du moindre privilège, configurez les clés API pour n'appeler que les API requises par l'application. Pour en savoir plus, consultez Appliquer des restrictions de clé API.
Pour corriger ce résultat, procédez comme suit :
Accédez à la page Clés API dans la console Google Cloud .
Pour chaque clé API :
- Dans la section Clés API, sur la ligne correspondant à chaque clé API pour laquelle vous devez restreindre des API, cliquez sur Actions.
- Dans le menu Actions, cliquez sur Modifier la clé API. La page Modifier la clé API s'affiche.
- Dans la section Restrictions relatives aux API, sélectionnez Restreindre des API. Le menu déroulant Sélectionner des API s'affiche.
- Dans la liste déroulante Sélectionner des API, choisissez les API que vous souhaitez autoriser.
- 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
Nom de la catégorie dans l'API : API_KEY_APPS_UNRESTRICTED
Des clés API sont utilisées de manière non restreinte, autorisant une utilisation par n'importe quelle application non approuvée.
Les clés API sans restriction ne sont pas sécurisées, car elles peuvent être récupérées sur des appareils qui les stockeront ou les rendront visibles au public, par exemple depuis un navigateur. Conformément au principe du moindre privilège, limitez l'utilisation des clés API aux hôtes, référents HTTP et applications de confiance. Pour en savoir plus, consultez Appliquer des restrictions de clé API.
Pour corriger ce résultat, procédez comme suit :
Accédez à la page Clés API dans la console Google Cloud .
Pour chaque clé API :
- Dans la section Clés API, sur la ligne correspondant à chaque clé API pour laquelle vous devez restreindre des applications, cliquez sur Actions.
- Dans le menu Actions, cliquez sur Modifier la clé API. La page Modifier la clé API s'affiche.
- Sur la page Modifier la clé API, sous Restrictions liées aux applications, sélectionnez une catégorie de restriction. Vous pouvez définir une restriction de ce type par clé.
- Dans le champ Ajouter un élément, qui s'affiche lorsque vous sélectionnez une restriction, cliquez sur Ajouter un élément pour ajouter des restrictions en fonction des besoins de votre application.
- Une fois les éléments ajoutés, cliquez sur Terminé.
- 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
Nom de la catégorie dans l'API : API_KEY_EXISTS
Un projet utilise des clés API au lieu de l'authentification standard.
Les clés API sont moins sécurisées que les autres méthodes d'authentification, car il s'agit de chaînes simples chiffrées qui peuvent être facilement découvertes et utilisées par d'autres utilisateurs. Elles peuvent être récupérées sur des appareils qui les stockeront ou les rendront visibles de tous, par exemple dans un navigateur. De plus, les clés API n'identifient pas de manière unique les utilisateurs ou les applications qui effectuent des requêtes. Vous pouvez également utiliser un flux d'authentification standard avec des comptes de service ou des comptes utilisateur.
Pour corriger ce résultat, procédez comme suit :
- Assurez-vous que vos applications sont configurées avec une autre forme d'authentification.
Accédez à la page Identifiants de l'API dans la console Google Cloud .
Dans la section Clés API de la ligne correspondant à chaque clé API que vous souhaitez supprimer, cliquez sur Actions.
Dans le menu Actions, cliquez sur Supprimer la 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
Nom de la catégorie dans l'API : API_KEY_NOT_ROTATED
Une clé API n'a pas subi de rotation depuis plus de 90 jours.
Les clés API n'ont pas de date d'expiration. En cas de vol, la clé peut être utilisée indéfiniment, à moins que le propriétaire du projet ne décide de la révoquer ou d'alterner les clés. En renouvelant fréquemment vos clés API, vous réduisez la durée pendant laquelle une clé API volée pourrait être utilisée pour accéder à des données depuis un compte compromis ou résilié. Effectuez une rotation des clés API au moins tous les 90 jours. Pour en savoir plus, consultez la section Bonnes pratiques pour gérer les clés API.
Pour corriger ce résultat, procédez comme suit :
Accédez à la page Clés API dans la console Google Cloud .
Pour chaque clé API :
- Dans la section Clés API, sur la ligne correspondant à chaque clé API que vous souhaitez faire pivoter, cliquez sur Actions.
- Dans le menu Actions, cliquez sur Modifier la clé API. La page Modifier la clé API s'affiche.
- Sur la page Modifier la clé API, si la date figurant dans le champ Date de création date de plus de 90 jours, cliquez sur Faire tourner la clé. Une clé est générée.
- Vous pouvez également modifier le nom de la clé API.
- Cliquez sur Créer.
- Mettez à jour vos applications afin qu'elles utilisent la nouvelle clé.
- Une fois vos applications mises à jour, revenez à la page Modifier la clé API et cliquez sur Supprimer la clé précédente pour supprimer l'ancienne clé. L'ancienne clé ne sera pas supprimée automatiquement.
En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.
Audit config not monitored
Nom de la catégorie dans l'API : AUDIT_CONFIG_NOT_MONITORED
Les métriques et les alertes de journal ne sont pas configurées pour surveiller les modifications apportées à la configuration d'audit.
Cloud Audit Logging génère des journaux sur l'activité des administrateurs et les accès aux données, qui permettent d'effectuer des analyses de sécurité, le suivi des modifications des ressources et des audits de conformité. En surveillant les modifications apportées à la configuration d'audit, vous vous assurez que toutes les activités de votre projet peuvent être auditées à tout moment. Pour en savoir plus, consultez la présentation des métriques basées sur les journaux.
Selon la quantité d'informations, les coûts liés à Cloud Monitoring peuvent être importants. Pour comprendre votre utilisation du service et son coût, consultez les tarifs de Google Cloud Observability.
Pour les activations du niveau Premium de Security Command Center au niveau des projets, ce résultat n'est disponible que si le niveau Standard est activé dans l'organisation parente.
Pour corriger ce résultat, créez des métriques, si nécessaire, et des règles d'alerte :
Créer une métrique
Accédez à la page Métriques basées sur les journaux de la console Google Cloud .
Cliquez sur Créer la métrique.
Sous Type de métrique, sélectionnez Compteur.
Sous Détails :
- Définissez un nom de métrique de journal.
- Ajoutez une description.
- Définissez le champ Unités sur 1.
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:*
Cliquez sur Créer la métrique. Un message de confirmation s'affiche.
Créer une règle d'alerte
-
Dans la console Google Cloud , accédez à la page Métriques basées sur les journaux :
Accéder à la page Métriques basées sur les journaux
Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est Logging.
- 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.
-
Cliquez sur Plus , puis sur Créer une alerte à partir de la métrique.
La boîte de dialogue Nouvelle condition s'affiche, avec les options de métrique et de transformation de données préremplies.
- Cliquez sur Suivant.
- Vérifiez les paramètres préremplis. Vous voudrez peut-être modifier le champ Valeur du seuil.
- Cliquez sur Nom de la condition, puis saisissez un nom pour la condition.
- Cliquez sur Suivant.
Pour ajouter des notifications à votre règle d'alerte, cliquez sur Canaux de notification. Dans la boîte de dialogue, sélectionnez un ou plusieurs canaux de notification dans le menu, puis cliquez sur OK.
Pour recevoir une notification en cas d'ouverture et de fermeture d'un incident, cochez la case Notifier en cas de fermeture des incidents. Par défaut, les notifications ne sont envoyées que lorsque des incidents sont ouverts.
- (Facultatif) Mettez à jour la durée de fermeture automatique de l'incident. Ce champ détermine à quel moment Monitoring ferme les incidents en l'absence de données de métriques.
- Facultatif : Cliquez sur Documentation, puis ajoutez les informations à inclure dans le message de notification.
- Cliquez sur Nom de l'alerte et saisissez un nom pour la règle d'alerte.
- Cliquez sur Créer une règle.
En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.
Audit logging disabled
Nom de la catégorie dans l'API : AUDIT_LOGGING_DISABLED
Ce résultat n'est pas disponible pour les activations au niveau du projet.
La journalisation d'audit est désactivée pour un ou plusieurs services Google Cloud , ou un ou plusieurs comptes principaux sont exemptés de la journalisation d'audit de l'accès aux données.
Activez Cloud Logging pour tous les services afin de suivre l'ensemble des activités d'administration, ainsi que des accès en lecture et en écriture aux données utilisateur. Selon la quantité d'informations, les coûts liés à Cloud Logging peuvent être importants. Pour comprendre votre utilisation du service et son coût, consultez les tarifs de Google Cloud Observability.
Si des comptes principaux sont exemptés de la journalisation d'audit des accès aux données dans la configuration par défaut ou dans les configurations de journalisation de services individuels, supprimez l'exemption.
Pour corriger ce résultat, procédez comme suit :
Accédez à la page Configuration par défaut des journaux d'audit des accès aux données dans la consoleGoogle Cloud .
Dans l'onglet Types de journaux, activez la journalisation des audits d'accès aux données dans la configuration par défaut :
- Sélectionnez Lecture administrateur, Lecture de données et Écriture de données.
- Cliquez sur Enregistrer.
Dans l'onglet Comptes principaux exemptés, supprimez tous les utilisateurs exemptés de la configuration par défaut :
- Supprimez chaque compte principal listé en cliquant sur Supprimer à côté de chaque nom.
- Cliquez sur Enregistrer.
Accédez à la page Journaux d'audit.
Supprimez tous les comptes principaux exemptés des configurations de journaux d'audit des accès aux données des services individuels.
- Sous Configuration des journaux d'audit des accès aux données, cliquez sur chaque service pour lequel un compte principal exempté est affiché. Un panneau de configuration des journaux d'audit s'ouvre pour le service.
- Dans l'onglet Comptes principaux exemptés, supprimez tous les comptes principaux exemptés en cliquant sur Supprimer à côté de chaque nom.
- 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
Nom de la catégorie dans l'API : AUTO_BACKUP_DISABLED
Les sauvegardes automatiques ne sont pas activées pour une base de données Cloud SQL.
Pour éviter toute perte de données, activez les sauvegardes automatiques pour vos instances SQL. Pour plus d'informations, consultez la section Créer et gérer des sauvegardes à la demande et automatiques.
Pour corriger ce résultat, procédez comme suit :
Dans la console Google Cloud , accédez à la page Instances Cloud SQL.
Cliquez sur le nom de l'instance.
Cliquez sur Sauvegardes.
À côté de Paramètres, cliquez sur Modifier.
Cochez la case Sauvegardes quotidiennes automatiques.
Facultatif : Dans la zone Nombre de jours, saisissez le nombre de jours de sauvegarde que vous souhaitez conserver.
Facultatif : Dans la liste Intervalle de sauvegarde, sélectionnez l'intervalle de temps pendant lequel effectuer les sauvegardes.
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
Nom de la catégorie dans l'API : AUTO_REPAIR_DISABLED
La fonctionnalité de réparation automatique d'un cluster Google Kubernetes Engine (GKE), qui permet de maintenir les nœuds dans un état sain et d'exécution, est désactivée.
Lorsque cette fonction est activée, GKE vérifie périodiquement l'état de chaque nœud de votre cluster. Si les vérifications d'état réalisées sur un nœud échouent de manière consécutive sur une période prolongée, GKE déclenche un processus de réparation pour ce nœud. Pour en savoir plus, consultez la section Réparer automatiquement des nœuds.
Pour corriger ce résultat, procédez comme suit :
Accédez à la page Clusters Kubernetes de la console Google Cloud .
Cliquez sur l'onglet Nœuds.
Pour chaque pool de nœuds :
- Cliquez sur le nom du pool de nœuds pour accéder à sa page d'informations.
- Cliquez sur Modifier.
- Dans la section Gestion, sélectionnez Activer la réparation automatique.
- 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
Nom de la catégorie dans l'API : AUTO_UPGRADE_DISABLED
La fonctionnalité de mise à niveau automatique des clusters GKE, qui conserve les clusters et les pools de nœuds sur la dernière version stable de Kubernetes, est désactivée.
Pour en savoir plus, consultez la page Mettre à niveau automatiquement des nœuds.
Pour corriger ce résultat, procédez comme suit :
Accédez à la page Clusters Kubernetes de la console Google Cloud .
Dans la liste des clusters, cliquez sur le nom du cluster.
Cliquez sur l'onglet Nœuds.
Pour chaque pool de nœuds :
- Cliquez sur le nom du pool de nœuds pour accéder à sa page d'informations.
- Cliquez sur Modifier.
- Sous Gestion, sélectionnez Activer la mise à niveau automatique.
- Cliquez sur Enregistrer.
En savoir plus sur les éléments et les paramètres d'analyse compatibles de ce type de résultat.
BigQuery table CMEK disabled
Nom de la catégorie dans l'API : BIGQUERY_TABLE_CMEK_DISABLED
Une table BigQuery n'est pas configurée pour utiliser une clé de chiffrement gérée par le client (CMEK).
Avec CMEK, les clés que vous créez et gérez dans Cloud KMS encapsulent les clés utilisées par Google Cloud pour chiffrer vos données, ce qui vous permet de mieux contrôler l'accès à vos données. Pour en savoir plus, consultez Protéger des données avec des clés Cloud KMS.
Pour corriger ce résultat, procédez comme suit :