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 lors de l'accès à Security Command Center dans la console Google Cloud, 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 Security Health Analytics
Cette section inclut des instructions correctives pour tous les résultats d'analyses de l'état de sécurité.
Désactivation des résultats après correction
Une fois que vous avez corrigé une faille ou un résultat d'erreur de configuration, Security Health Analytics définit automatiquement l'état du résultat sur INACTIVE
la prochaine fois qu'il analyse ce résultat.
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 affectée par le résultat est supprimée. Si vous souhaitez supprimer de votre écran un résultat pour une ressource supprimée en attendant que Security Health Analytics détecte la suppression de la ressource, vous pouvez ignorer le résultat. Pour ignorer un résultat, consultez la section Ignorer des résultats dans Security Command Center.
N'utilisez pas le mode silencieux pour masquer les résultats corrigés pour les ressources existantes.
Si le problème se reproduit et que Security Health Analytics restaure l'état ACTIVE
du résultat, il est possible que le résultat ne soit pas réactivé, car les résultats ignorés sont exclus de toute requête de résultat spécifiant NOT mute="MUTED"
, telle que la requête de résultat par défaut.
Pour en savoir plus sur les intervalles d'analyse, consultez la page Types d'analyses de Security Health Analytics.
Access Transparency disabled
Nom de la catégorie dans l'API : ACCESS_TRANSPARENCY_DISABLED
Les journaux Access Transparency sont générés par les employés de Google Cloud qui accèdent aux projets de votre organisation pour fournir une assistance. Activez Access Transparency pour consigner qui accède à vos informations depuis Google Cloud, quand et pourquoi. Pour en savoir plus, consultez la page 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 attribuer le rôle IAM Administrateur Access Transparency (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 console Google 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.
Même si la configuration d'Access Transparency s'effectue sur une page de projet Google Cloud, la fonctionnalité est activée pour l'ensemble de l'organisation.
Accédez à la page IAM et administration > Paramètres.
Cliquez sur Activer Access Transparency.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesAlloyDB auto backup disabled
Nom de la catégorie dans l'API : ALLOYDB_AUTO_BACKUP_DISABLED
Les sauvegardes automatiques ne sont pas activées sur un cluster AlloyDB pour PostgreSQL.
Pour éviter toute perte de données, activez les sauvegardes automatiques pour votre cluster. Pour en savoir plus, consultez la section 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 console Google Cloud.
Cliquez sur un cluster dans la colonne Nom de la ressource.
Cliquez sur Protection des données.
Dans la section Règle de sauvegarde automatique, cliquez sur Modifier sur la ligne Sauvegardes automatiques.
Cochez la case Automatiser les sauvegardes.
Cliquez sur Update (Mettre à jour).
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesAlloyDB log min error statement severity
Nom de la catégorie dans l'API : ALLOYDB_LOG_MIN_ERROR_STATEMENT_SEVERITY
Dans une instance AlloyDB pour PostgreSQL, l'option de base de données log_min_error_statement
n'est pas définie sur error
ou sur une autre valeur recommandée.
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. S'il est défini sur un niveau de gravité trop élevé, il est possible 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 console Google Cloud.
Cliquez sur le cluster dans la colonne Nom de la ressource.
Dans la section Instances de votre cluster, cliquez sur Modifier à côté de l'instance concernée.
Cliquez sur Options de configuration avancées.
Dans la section Options, définissez l'option de base de données
log_min_error_statement
avec l'une des valeurs recommandées suivantes, en fonction de la règle de journalisation de votre organisation.debug5
debug4
debug3
debug2
debug1
info
notice
warning
error
Cliquez sur Mettre à jour l'instance.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesAlloyDB log min messages
Nom de la catégorie dans l'API : ALLOYDB_LOG_MIN_MESSAGES
Dans une instance AlloyDB pour PostgreSQL, l'option de base de données log_min_messages
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 complique 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 console Google Cloud.
Cliquez sur le cluster dans la colonne Nom de la ressource.
Dans la section Instances de votre cluster, cliquez sur Modifier à côté de l'instance concernée.
Cliquez sur Options de configuration avancées.
Dans la section Options, définissez l'option de base de données
log_min_messages
avec l'une des valeurs recommandées suivantes, en fonction de la règle de journalisation de votre organisation.debug5
debug4
debug3
debug2
debug1
info
notice
warning
Cliquez sur Mettre à jour l'instance.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesAlloyDB log error verbosity
Nom de la catégorie dans l'API : ALLOYDB_LOG_ERROR_VERBOSITY
Dans une instance AlloyDB pour PostgreSQL, l'option de base de données log_error_verbosity
n'est pas définie sur default
ou sur 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 console Google Cloud.
Cliquez sur le cluster dans la colonne Nom de la ressource.
Dans la section Instances de votre cluster, cliquez sur Modifier à côté de l'instance concernée.
Cliquez sur Options de configuration avancées.
Dans la section Options, définissez l'option de base de données
log_error_verbosity
avec l'une des valeurs recommandées suivantes, en fonction de la règle de journalisation de votre organisation.default
verbose
Cliquez sur Mettre à jour l'instance.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesAdmin service account
Nom de la catégorie dans l'API : ADMIN_SERVICE_ACCOUNT
Un compte de service de votre organisation ou de votre projet dispose 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 IAM de la console Google Cloud.
Pour chaque compte principal identifié dans le résultat :
- Cliquez sur Modifier edit à côté du compte principal.
- Pour supprimer des autorisations, cliquez sur Supprimer delete à côté du rôle fautif.
- Cliquez sur Enregistrer.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesAlpha 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 des Clusters Kubernetes GKE dans la console Google Cloud.
Cliquez sur 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 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.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesAPI 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és API.
Pour corriger ce résultat, procédez comme suit :
Accédez à la page Clés API de 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, affichez le menu Actions en cliquant sur l'icône .
- 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.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesAPI 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és API.
Pour corriger ce résultat, procédez comme suit :
Accédez à la page Clés API de 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, affichez le menu Actions en cliquant sur l'icône .
- 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.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesAPI 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 chiffrées simples que les autres utilisateurs peuvent découvrir et utiliser facilement. 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 des identifiants d'API dans la console Google Cloud.
Dans la section Clés API de la ligne correspondant à chaque clé API que vous souhaitez supprimer, affichez le menu Actions en cliquant sur l'icône
.Dans le menu Actions, cliquez sur Supprimer la clé API.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesAPI 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 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 en savoir plus, consultez Sécuriser une clé API.
Pour corriger ce résultat, procédez comme suit :
Accédez à la page Clés API de la console Google Cloud.
Pour chaque clé API :
- Dans la section Clés API de la ligne correspondant à chaque clé API que vous souhaitez faire pivoter, affichez le menu Actions en cliquant sur l'icône .
- 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, remplacez la clé en cliquant sur Générer la clé à nouveau en haut de la page. Une clé de remplacement est générée.
- Cliquez sur Enregistrer.
- 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.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesAudit config not monitored
Nom de la catégorie dans l'API : 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 ses coûts, consultez la page Optimisation des coûts pour l'observabilité Google Cloud.
Pour les activations du niveau Premium de Security Command Center au niveau du projet, 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 le panneau de navigation de la console Google Cloud, sélectionnez Logging, puis Métriques basées sur les journaux :
- 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 lorsque des incidents sont ouverts ou fermés, cochez Notifier en cas de fermeture d'incident. 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.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesAudit 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.
Les journaux d'audit sont désactivés pour un ou plusieurs services Google Cloud, ou un ou plusieurs comptes principaux sont exemptés de la journalisation d'audit des 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 la page Optimisation des coûts pour l'observabilité Google Cloud.
Si des comptes principaux sont exemptés de la journalisation d'audit des accès aux données pour la configuration de journalisation d'audit des accès aux données par défaut ou pour les configurations de journalisation d'un service individuel, supprimez l'exception.
Pour corriger ce résultat, procédez comme suit :
Accédez à la page Configuration par défaut des journaux d'audit pour l'accès aux données dans la console Google Cloud.
Dans l'onglet Types de journaux, activez les journaux d'audit des accès aux données dans la configuration par défaut:
- Sélectionnez Admin Read (Lecture administrateur), Data Read (Lecture de données) et Data Write (É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 répertorié en cliquant sur Supprimer delete à 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 journal d'audit des accès aux données de chaque service.
- Sous Configuration des journaux d'audit des accès aux données, cliquez sur chaque service qui affiche un compte principal exempté. Un panneau de configuration de journal 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 delete à côté de chaque nom.
- Cliquez sur Enregistrer.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesAuto 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 :
Accédez à la page Sauvegardes d'instances SQL dans la console Google Cloud.
À côté de Paramètres, cliquez sur Modifier edit.
Cochez la case Automatiser les sauvegardes.
Dans le menu déroulant, choisissez une période de temps pour la sauvegarde automatique de vos données.
Cliquez sur Enregistrer.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesAuto 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 des Clusters Kubernetes GKE dans 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 edit.
- Dans la section Gestion, sélectionnez Activer la réparation automatique.
- Cliquez sur Enregistrer.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesAuto 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 des Clusters Kubernetes GKE dans 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 edit.
- Sous Gestion, sélectionnez Activer la mise à niveau automatique.
- Cliquez sur Enregistrer.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesBigQuery 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 la page Protéger des données avec des clés Cloud KMS.
Pour corriger ce résultat, procédez comme suit :
- Créez une table protégée par Cloud Key Management Service.
- Copiez votre table dans la nouvelle table compatible avec les CMEK.
- Supprimez la table d'origine.
Pour définir une clé CMEK par défaut qui chiffre toutes les nouvelles tables d'un ensemble de données, consultez la page Définir une clé par défaut de l'ensemble de données.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesBinary authorization disabled
Nom de la catégorie dans l'API : BINARY_AUTHORIZATION_DISABLED
L'autorisation binaire est désactivée sur un cluster GKE.
L'autorisation binaire inclut une fonctionnalité facultative qui protège la sécurité de la chaîne d'approvisionnement en n'autorisant que le déploiement des images de conteneurs signées par des autorités de confiance lors du processus de développement dans le cluster. Grâce au déploiement basé sur la signature, vous contrôlez mieux votre environnement de conteneurs, en vous assurant que seules les images validées peuvent être déployées.
Pour corriger ce résultat, procédez comme suit :
Accédez à la page des Clusters Kubernetes GKE dans la console Google Cloud.
Dans la section Sécurité, cliquez sur l'icône de modification (edit) 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.
Dans la boîte de dialogue, sélectionnez Activer l'autorisation binaire.
Cliquez sur Enregistrer les modifications.
Accédez à la page de configuration de l'autorisation binaire.
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.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesBucket CMEK disabled
Nom de la catégorie dans l'API : BUCKET_CMEK_DISABLED
Un bucket n'est pas chiffré avec des clés de chiffrement gérées par le client (CMEK).
La définition d'une clé CMEK par défaut sur un bucket vous permet de mieux contrôler l'accès à vos données. Pour en savoir plus, consultez la page Clés de chiffrement gérées par le client.
Pour corriger ce résultat, utilisez CMEK avec un bucket en suivant la procédure Utiliser des clés de chiffrement gérées par le client. CMEK entraîne des coûts supplémentaires liés à Cloud KMS.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesBucket IAM not monitored
Nom de la catégorie dans l'API : 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 ses coûts, consultez la page Optimisation des coûts pour l'observabilité Google Cloud.
Pour les activations du niveau Premium de Security Command Center au niveau du projet, ce résultat n'est disponible que si le niveau Standard est activé dans l'organisation parente.
Pour corriger ce résultat, procédez comme suit :
Créer une métrique
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:
resource.type=gcs_bucket AND protoPayload.methodName="storage.setIamPermissions"
Cliquez sur Créer la métrique. Un message de confirmation s'affiche.
Créer une règle d'alerte
-
Dans le panneau de navigation de la console Google Cloud, sélectionnez Logging, puis Métriques basées sur les journaux :
- 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 lorsque des incidents sont ouverts ou fermés, cochez Notifier en cas de fermeture d'incident. 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.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesBucket logging disabled
Nom de la catégorie dans l'API : BUCKET_LOGGING_DISABLED
La journalisation est désactivée dans un bucket de stockage.
Pour faciliter l'analyse des problèmes de sécurité et surveiller l'utilisation de l'espace de stockage, activez les journaux d'accès et les informations de stockage de vos buckets Cloud Storage. Les journaux d'accès fournissent des informations pour toutes les requêtes effectuées sur un bucket spécifié. Les journaux de stockage fournissent des informations sur l'espace de stockage consommé par ce bucket.
Pour corriger ce résultat, configurez la journalisation pour le bucket indiqué par le résultat de Security Health Analytics en suivant le guide Journaux d'accès et journaux de stockage.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesBucket policy only disabled
Nom de la catégorie dans l'API : BUCKET_POLICY_ONLY_DISABLED
L'accès uniforme au niveau du bucket, précédemment appelé "Stratégie du bucket seulement", n'est pas configuré.
L'accès uniforme au niveau du bucket simplifie le contrôle des accès au bucket en désactivant les autorisations au niveau des objets (LCA). Lorsque les autorisations Cloud IAM au niveau du bucket sont activées sur un bucket donné, elles seules définissent l'accès à ce bucket et aux objets qu'il contient. Pour en savoir plus, consultez la section Accès uniforme au niveau du bucket.
Pour corriger ce résultat, procédez comme suit :
Accédez à la page du navigateur Cloud Storage dans la console Google Cloud.
Dans la liste des buckets, cliquez sur le nom du bucket souhaité.
Cliquez sur l'onglet Configuration.
Sous Autorisations, sur la ligne Contrôle des accès, cliquez sur l'icône Modifier (edit).
Dans la boîte de dialogue, sélectionnez Uniforme.
Cliquez sur Enregistrer.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesCloud Asset API disabled
Nom de la catégorie dans l'API : CLOUD_ASSET_API_DISABLED
Le service inventaire des éléments cloud n'est pas activé pour le projet.
Pour corriger ce résultat, procédez comme suit :
Accédez à la page Bibliothèque d'API de la console Google Cloud.
Recherchez
Cloud Asset Inventory
.Sélectionnez le résultat pour le service API Cloud Asset.
Vérifiez que API activée s'affiche.
Cluster logging disabled
Nom de la catégorie dans l'API : CLUSTER_LOGGING_DISABLED
La journalisation n'est pas activée pour un cluster GKE.
Pour faciliter l'analyse des problèmes de sécurité et surveiller l'utilisation, activez Cloud Logging sur vos clusters.
Selon la quantité d'informations, les coûts liés à Cloud Logging peuvent être importants. Pour comprendre votre utilisation du service et son coût, consultez la page Optimisation des coûts pour l'observabilité Google Cloud.
Pour corriger ce résultat, procédez comme suit :
Accédez à la page des Clusters Kubernetes GKE dans la console Google Cloud.
Sélectionnez le cluster répertorié dans le résultat de Security Health Analytics.
Cliquez sur edit Modifier.
Si la configuration du cluster a récemment été modifiée, il est possible que le bouton "Modifier" ne soit pas disponible. Si vous ne pouvez pas modifier les paramètres du cluster, attendez quelques minutes, puis réessayez.
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.
Cliquez sur Enregistrer.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesCluster monitoring disabled
Nom de la catégorie dans l'API : CLUSTER_MONITORING_DISABLED
Monitoring est désactivé sur les clusters GKE.
Pour faciliter l'analyse des problèmes de sécurité et surveiller l'utilisation, activez Cloud Monitoring sur vos clusters.
Selon la quantité d'informations, les coûts liés à Cloud Monitoring peuvent être importants. Pour comprendre votre utilisation du service et ses coûts, consultez la page Optimisation des coûts pour l'observabilité Google Cloud.
Pour corriger ce résultat, procédez comme suit :
Accédez à la page des Clusters Kubernetes GKE dans la console Google Cloud.
Sélectionnez le cluster répertorié dans le résultat de Security Health Analytics.
Cliquez sur edit Modifier.
Si la configuration du cluster a récemment été modifiée, il est possible que le bouton "Modifier" ne soit pas disponible. Si vous ne pouvez pas modifier les paramètres du cluster, attendez quelques minutes, puis réessayez.
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.
Cliquez sur Enregistrer.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesCluster private Google access disabled
Nom de la catégorie dans l'API : CLUSTER_PRIVATE_GOOGLE_ACCESS_DISABLED
Les hôtes de cluster ne sont pas configurés pour utiliser uniquement des adresses IP internes privées afin d'accéder aux API Google.
L'accès privé à Google permet aux instances de machine virtuelle (VM) disposant uniquement d'adresses IP internes privées d'accéder aux adresses IP publiques des API et services Google. Pour plus d'informations, consultez la section Configurer l'accès privé à Google.
Pour les activations du niveau Premium de Security Command Center au niveau du projet, ce résultat n'est disponible que si le niveau Standard est activé dans l'organisation parente.
Pour corriger ce résultat, procédez comme suit :
Accédez à la page Réseaux de cloud privés virtuel dans la console Google Cloud.
Dans la liste des réseaux, cliquez sur le nom du réseau souhaité.
Sur la page Détails du réseau VPC, cliquez sur l'onglet Sous-réseaux.
Dans la liste des sous-réseaux, cliquez sur le nom du sous-réseau associé au cluster Kubernetes dans le résultat.
Sur la page des détails du sous-réseau, cliquez sur Modifier edit.
Dans le champ Accès privé à Google, sélectionnez Activé.
Cliquez sur Enregistrer.
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.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesCluster secrets encryption disabled
Nom de la catégorie dans l'API : CLUSTER_SECRETS_ENCRYPTION_DISABLED
Le chiffrement des secrets au niveau de la couche d'application est désactivé sur un cluster GKE.
Le chiffrement des secrets au niveau de la couche d'application garantit que les secrets GKE sont chiffrés à l'aide de clés Cloud KMS. Cette fonctionnalité fournit une couche de sécurité supplémentaire pour les données sensibles, telles que les secrets définis par l'utilisateur et les secrets requis pour le fonctionnement du cluster, par exemple les clés de compte de service, qui sont toutes stockées dans etcd.
Pour corriger ce résultat, procédez comme suit :
Accédez à la page Clés Cloud KMS de la console Google Cloud.
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.
Accédez à la page des clusters Kubernetes.
Sélectionnez le cluster dans le résultat.
Sous Sécurité, dans le champ Chiffrement des secrets au niveau de la couche d'application, cliquez sur edit Modifier le chiffrement des secrets au niveau de la couche d'application.
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.
Cliquez sur Save Changes (Enregistrer les modifications).
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesCluster shielded nodes disabled
Nom de la catégorie dans l'API : CLUSTER_SHIELDED_NODES_DISABLED
Les nœuds GKE protégés ne sont pas activés pour un cluster.
Sans les nœuds GKE protégés, les pirates informatiques peuvent exploiter une faille d'un pod pour exfiltrer les identifiants d'amorçage et usurper l'identité des nœuds de votre cluster. Cette faille peut donner aux pirates informatiques l'accès aux secrets du cluster.
Pour corriger ce résultat, procédez comme suit :
Accédez à la page des Clusters Kubernetes GKE dans la console Google Cloud.
Sélectionnez le cluster dans le résultat.
Sous Sécurité, dans le champ Nœuds GKE protégés, cliquez sur edit Modifier les nœuds GKE protégés.
Cochez la case Activer les nœuds GKE protégés.
Cliquez sur Save Changes (Enregistrer les modifications).
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesCompute project wide SSH keys allowed
Nom de la catégorie dans l'API : COMPUTE_PROJECT_WIDE_SSH_KEYS_ALLOWED
Les clés SSH à l'échelle du projet permettent de se connecter à toutes les instances du projet.
L'utilisation de clés SSH à l'échelle du projet facilite la gestion des clés SSH. En revanche, si elle est compromise, elle présente un risque pour la sécurité, qui peut avoir une incidence sur toutes les instances d'un projet. Vous devez utiliser des clés SSH spécifiques à l'instance, qui limitent la surface d'attaque si les clés SSH sont compromises. Pour en savoir plus, consultez la page Gérer des clés SSH dans les métadonnées.
Pour corriger ce résultat, procédez comme suit :
Accédez à la page Instances de VM de la console Google Cloud.
Dans la liste des instances, cliquez sur le nom de l'instance dans le résultat.
Sur la page Informations sur l'instance de VM, cliquez sur edit Modifier.
Sous Clés SSH, sélectionnez Bloquer les clés SSH à l'échelle du projet.
Cliquez sur Enregistrer.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesCompute Secure Boot disabled
Nom de la catégorie dans l'API : COMPUTE_SECURE_BOOT_DISABLED
Le démarrage sécurisé n'est pas activé pour cette VM protégée.
Le démarrage sécurisé permet de protéger vos machines virtuelles contre les rootkits et les bootkits. Compute Engine n'active pas le démarrage sécurisé par défaut, car certains pilotes non signés et logiciels de bas niveau ne sont pas compatibles. Si votre VM n'utilise pas de logiciel incompatible et qu'elle démarre avec le démarrage sécurisé activé, Google recommande l'utilisation de cette fonctionnalité. Si vous utilisez des modules tiers avec des pilotes NVIDIA, assurez-vous qu'ils sont compatibles avec le démarrage sécurisé avant de l'activer.
Pour plus d'informations, consultez la section Démarrage sécurisé.
Pour corriger ce résultat, procédez comme suit :
Accédez à la page Instances de VM de la console Google Cloud.
Dans la liste des instances, cliquez sur le nom de l'instance dans le résultat.
Sur la page Informations sur l'instance de VM, cliquez sur
Arrêter.Une fois l'instance arrêtée, cliquez sur edit Modifier.
Sous VM protégée, sélectionnez Activer le démarrage sécurisé.
Cliquez sur Enregistrer.
Cliquez sur
Démarrer pour démarrer l'instance.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesCompute serial ports enabled
Nom de la catégorie dans l'API : COMPUTE_SERIAL_PORTS_ENABLED
Les ports série sont activés pour une instance, ce qui permet de se connecter à la console série de l'instance.
Si vous activez l'accès interactif à la console série sur une instance, les clients peuvent tenter de se connecter à cette instance depuis n'importe quelle adresse IP. Par conséquent, l'accès interactif à la console série doit être désactivé. Pour en savoir plus, consultez la section Activer l'accès pour un projet.
Pour corriger ce résultat, procédez comme suit :
Accédez à la page Instances de VM de la console Google Cloud.
Dans la liste des instances, cliquez sur le nom de l'instance dans le résultat.
Sur la page Informations sur l'instance de VM, cliquez sur edit Modifier.
Dans la section Accès à distance, cochez la case Activer la connexion aux ports série.
Cliquez sur Enregistrer.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesConfidential Computing disabled
Nom de la catégorie dans l'API : CONFIDENTIAL_COMPUTING_DISABLED
L'informatique confidentielle n'est pas activée sur une instance Compute Engine.
L'informatique confidentielle ajoute un troisième pilier à la story sur le chiffrement de bout en bout en chiffrant les données pendant qu'ellees sont utilisées. Grâce aux environnements d'exécution confidentiels fournis par l'informatique confidentielle et AMD SEV (Secure Encrypted Virtualization), Google Cloud maintient chiffrés en mémoire le code sensible et les autres données lors de leur traitement.
L'informatique confidentielle ne peut être activée qu'à la création d'une instance. Vous devez donc supprimer l'instance actuelle et en créer une autre.
Pour en savoir plus, consultez Confidential VMs et Compute Engine.
Pour corriger ce résultat, procédez comme suit :
Accédez à la page Instances de VM de la console Google Cloud.
Dans la liste des instances, cliquez sur le nom de l'instance dans le résultat.
Sur la page Informations sur l'instance de VM, cliquez sur delete Supprimer.
Créez une Confidential VM à l'aide de la console Google Cloud.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesCOS not used
Nom de la catégorie dans l'API : COS_NOT_USED
Les VM Compute Engine n'utilisent pas le système d'exploitation optimisé par conteneur, conçu pour exécuter des conteneurs Docker sur Google Cloud en toute sécurité.
Container-Optimized OS est l'OS recommandé par Google pour héberger et exécuter des conteneurs sur Google Cloud. Le faible encombrement de l'OS minimise les risques liés à la sécurité, et les mises à jour automatiques corrigent les failles au plus vite. Pour en savoir plus, consultez la page Présentation du système d'exploitation optimisé par conteneur.
Pour corriger ce résultat, procédez comme suit :
Accédez à la page des Clusters Kubernetes GKE dans la console Google Cloud.
Dans la liste des clusters, cliquez sur le nom du cluster dans le résultat.
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 edit.
- Sous Nœuds -> Type d'image, cliquez sur Modifier.
- Sélectionnez Système d'exploitation optimisé par conteneur, puis cliquez sur Modifier.
- Cliquez sur Enregistrer.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesCustom role not monitored
Nom de la catégorie dans l'API : 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 ses coûts, consultez la page Optimisation des coûts pour l'observabilité Google Cloud.
Pour les activations du niveau Premium de Security Command Center au niveau du projet, ce résultat n'est disponible que si le niveau Standard est activé dans l'organisation parente.
Pour corriger ce résultat, procédez comme suit :
Créer une métrique
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:
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")
Cliquez sur Créer la métrique. Un message de confirmation s'affiche.
Créer une règle d'alerte
-
Dans le panneau de navigation de la console Google Cloud, sélectionnez Logging, puis Métriques basées sur les journaux :
- 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 lorsque des incidents sont ouverts ou fermés, cochez Notifier en cas de fermeture d'incident. 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.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesDataproc CMEK disabled
Nom de la catégorie dans l'API : DATAPROC_CMEK_DISABLED
Un cluster Dataproc a été créé sans clé CMEK de configuration du chiffrement. Avec les CMEK, les clés que vous créez et gérez dans Cloud Key Management Service encapsulent les clés utilisées par Google Cloud pour chiffrer vos données, ce qui vous donne plus de contrôle sur l'accès à vos données.
Pour corriger ce résultat, procédez comme suit :
Accédez à la page Cluster Dataproc dans la console Google Cloud.
Sélectionnez votre projet et cliquez sur Créer un cluster.
Dans la section Gérer la sécurité, cliquez sur Chiffrement, puis sélectionnez Clé gérée par le client.
Sélectionnez une clé gérée par le client dans la liste.
Si vous ne possédez pas de clé gérée par le client, vous devez en créer une à utiliser. Pour en savoir plus, consultez la page Clés de chiffrement gérées par le client.
Assurez-vous que le rôle Chiffreur/Déchiffreur de CryptoKeys Cloud KMS est attribué à la clé KMS sélectionnée au compte de service du cluster Dataproc ("serviceAccount:service-project_number@compute-system.iam.gserviceaccount.com").
Une fois le cluster créé, migrez toutes vos charges de travail de l'ancien cluster vers le nouveau.
Accédez à "Clusters Dataproc" et sélectionnez votre projet.
Sélectionnez l'ancien cluster, puis cliquez sur delete Supprimer le cluster.
Répétez toutes les étapes ci-dessus pour les autres clusters Dataproc disponibles dans le projet sélectionné.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesDataproc image outdated
Nom de la catégorie dans l'API : DATAPROC_IMAGE_OUTDATED
Un cluster Dataproc a été créé en utilisant une version d'image Dataproc affectée par les failles de sécurité de l'utilitaire Apache Log4j 2 (CVE-2021-44228 et CVE-2021-45046).
Ce détecteur découvre les failles en vérifiant si le champ softwareConfig.imageVersion
de la propriété config
d'un objet
Cluster
comporte l'une des versions concernées suivantes :
- Versions d'image antérieures à 1.3.95.
- Versions d'images mineures antérieures à 1.4.77, 1.5.53 et 2.0.27.
Le numéro de version d'une image Dataproc personnalisée peut être remplacé manuellement. Étudions les cas de figure suivants :
- Vous pouvez modifier la version d'une image personnalisée affectée pour qu'elle semble ne pas être affectée. Dans ce cas, le détecteur ne fournit aucun résultat.
- Vous pouvez remplacer le numéro de version d'une image personnalisée non affectée par celui d'une version connue pour présenter la faille. Dans ce cas, ce détecteur fournit un faux positif. Pour supprimer de tels faux positifs, vous pouvez les ignorer.
Pour corriger ce résultat, recréez et mettez à jour le cluster concerné.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesDataset CMEK disabled
Nom de la catégorie dans l'API : DATASET_CMEK_DISABLED
Un ensemble de données BigQuery n'est pas configuré pour utiliser une clé de chiffrement gérée par le client par défaut (CMEK).
Avec CMEK, les clés que vous créez et gérez dans Cloud KMS encapsulent les clés utilisées par Google Cloud pour chiffrer vos données, ce qui vous permet de mieux contrôler l'accès à vos données. Pour en savoir plus, consultez 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 :
- Créez un ensemble de données.
- Définissez une clé CMEK par défaut sur l'ensemble de données que vous avez créé.
- Pour copier des tables dans l'ensemble de données compatible avec CMEK, suivez les instructions de la section Copier une table.
- Une fois les données copiées, supprimer les ensembles de données d'origine.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesDefault network
Nom de la catégorie dans l'API : DEFAULT_NETWORK
Le réseau par défaut existe dans un projet.
Les réseaux par défaut créent automatiquement des règles de pare-feu et des configurations réseau qui peuvent ne pas être sécurisées. Pour en savoir plus, consultez la section Réseau par défaut.
Pour les activations du niveau Premium de Security Command Center au niveau du projet, ce résultat n'est disponible que si le niveau Standard est activé dans l'organisation parente.
Pour corriger ce résultat, procédez comme suit :
Accédez à la page Réseaux VPC de Google Cloud Console.
Dans la liste des réseaux, cliquez sur le nom du réseau par défaut.
Sur la page Détails du réseau VPC, cliquez sur delete Supprimer le réseau VPC.
Pour créer un réseau avec des règles de pare-feu personnalisées, consultez la page Créer des réseaux.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesDefault service account used
Nom de la catégorie dans l'API : DEFAULT_SERVICE_ACCOUNT_USED
Une instance Compute Engine est configurée pour utiliser le compte de service par défaut.
Le compte de service Compute Engine par défaut dispose du rôle d'éditeur sur le projet, ce qui permet un accès en lecture et en écriture à la plupart des services Google Cloud. Pour vous protéger des élévations de privilèges et des accès non autorisés, n'utilisez pas le compte de service Compute Engine par défaut. À la place, créez un compte de service et ne lui accorder que les autorisations requises par votre instance. Pour plus d'informations sur les rôles et les autorisations IAM, consultez la page Contrôle des accès.
Pour corriger ce résultat, procédez comme suit :
Accédez à la page Instances de VM de la console Google Cloud.
Sélectionnez l'instance associée au résultat de Security Health Analytics.
Sur la page Détails de l'instance page qui s'affiche, cliquez sur
Arrêter.Une fois l'instance arrêtée, cliquez sur edit Modifier.
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.
Cliquez sur Enregistrer. La nouvelle configuration s'affiche sur la page Détails de l'instance.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesDisk CMEK disabled
Nom de la catégorie dans l'API : DISK_CMEK_DISABLED
Les disques de cette VM ne sont pas chiffrés avec des clés de chiffrement gérées par le client.
Avec CMEK, les clés que vous créez et gérez dans Cloud KMS encapsulent les clés utilisées par Google Cloud pour chiffrer vos données, ce qui vous permet de mieux contrôler l'accès à vos données. Pour en savoir plus, consultez la page Protéger des ressources avec des clés Cloud KMS.
Pour corriger ce résultat, procédez comme suit :
Accédez à la page Disques Compute Engine dans la console Google Cloud.
Dans la liste des disques, cliquez sur le nom du disque indiqué dans le résultat.
Sur la page Gérer le disque, cliquez sur delete Supprimer.
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.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesDisk CSEK disabled
Nom de la catégorie dans l'API : DISK_CSEK_DISABLED
Les disques de cette VM ne sont pas chiffrés avec des clés de chiffrement fournies par le client (CSEK). Les disques des VM critiques doivent être chiffrés avec des clés CSEK.
Dans ce cas, Compute Engine utilisera votre clé afin de protéger les clés générées par Google pour chiffrer et déchiffrer vos données. Pour en savoir plus, consultez la page Clés de chiffrement fournies par le client. CSEK engendre des coûts supplémentaires liés à Cloud KMS.
Pour corriger ce résultat, procédez comme suit :
Supprimer et créer un disque
Vous pouvez chiffrer les nouveaux disques persistants avec votre propre clé, mais pas les disques persistants existants.
Accédez à la page Disques Compute Engine dans la console Google Cloud.
Dans la liste des disques, cliquez sur le nom du disque indiqué dans le résultat.
Sur la page Gérer le disque, cliquez sur delete Supprimer.
Pour créer un disque avec CSEK activé, consultez la section Chiffrer des disques avec des clés de chiffrement fournies par le client.
Suivez le reste de la procédure pour activer le détecteur.
Activer le détecteur
Accédez à la page Éléments de Security Command Center dans la console Google Cloud.
Dans la section Type de ressource du panneau Filtres rapides, sélectionnez compute.Disk.
Si vous ne voyez pas compute.Disk, cliquez sur View more (Afficher plus), saisissez
Disk
dans le champ de recherche, puis cliquez sur Apply (Appliquer).Le panneau Results (Résultats) se met à jour pour n'afficher que les instances du type de ressource
compute.Disk
.Dans la colonne Nom à afficher, cochez la case à côté du nom du disque que vous souhaitez utiliser avec la CSEK, puis cliquez sur Définir des marques de sécurité.
Dans la boîte de dialogue, cliquez sur Ajouter une marque.
Dans le champ key, saisissez
enforce_customer_supplied_disk_encryption_keys
et, dans le champ valeur, saisisseztrue
.Cliquez sur Enregistrer.
éléments et paramètres d'analyse compatibles avec ce type de résultat.
Découvrez lesDNS logging disabled
Nom de la catégorie dans l'API : DNS_LOGGING_DISABLED
La surveillance des journaux Cloud DNS offre une visibilité sur les noms DNS demandés par les clients dans le réseau VPC. Ces journaux peuvent être surveillés pour détecter les anomalies de noms de domaine et évalués selon les renseignements sur les menaces. Nous vous recommandons d'activer la journalisation DNS pour les réseaux VPC.
Selon la quantité d'informations, les coûts de journalisation liés à Cloud DNS peuvent être importants. Pour comprendre votre utilisation du service et son coût, consultez la page Tarifs de l'observabilité Google Cloud: Cloud Logging.
Pour les activations du niveau Premium de Security Command Center au niveau du projet, ce résultat n'est disponible que si le niveau Standard est activé dans l'organisation parente.
Pour corriger ce résultat, procédez comme suit :
Accédez à la page Réseaux VPC de la console Google Cloud.
Dans la liste des réseaux, cliquez sur le nom du réseau VPC.
Créez une règle de serveur (s'il n'en existe pas) ou modifiez une règle existante :
Si le réseau ne dispose pas de règle de serveur DNS, procédez comme suit :
- Cliquez sur edit Modifier.
- Dans le champ Règle de serveur DNS, cliquez sur Créer une règle de serveur.
- Indiquez le nom de la nouvelle règle du serveur.
- Définissez Journaux sur Activé.
- Cliquez sur Enregistrer.
Si le réseau dispose d'une règle de serveur DNS, procédez comme suit :
- Dans le champ Règle de serveur DNS, cliquez sur le nom de la règle DNS.
- Cliquez sur edit Modifier la règle.
- Définissez Journaux sur Activé.
- Cliquez sur Enregistrer.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesDNSSEC disabled
Nom de la catégorie dans l'API : DNSSEC_DISABLED
Les extensions de sécurité du système de noms de domaine (DNSSEC, Domain Name System Security Extensions) sont désactivées pour les zones Cloud DNS.
DNSSEC valide les réponses DNS et atténue les risques, tels que le piratage DNS et les attaques de type "MITM" (Man-in-the-middle), en signant de manière cryptographique les enregistrements DNS. Vous devez activer DNSSEC. Pour en savoir plus, consultez la page Présentation des extensions de sécurité DNS (DNSSEC).
Pour corriger ce résultat, procédez comme suit :
Accédez à la page Cloud DNS dans la console Google Cloud.
Recherchez la ligne contenant la zone DNS indiquée dans le résultat.
Cliquez sur le paramètre DNSSEC sur la ligne puis, sous DNSSEC, sélectionnez Activée.
Lisez la boîte de dialogue qui s'affiche. Si vous êtes satisfait, cliquez sur Activer.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesEgress deny rule not set
Nom de la catégorie dans l'API : EGRESS_DENY_RULE_NOT_SET
Une règle de refus du trafic sortant n'est pas définie sur un pare-feu.
Un pare-feu qui refuse tout trafic réseau de sortie empêche toutes les connexions réseau sortantes indésirables, à l'exception des connexions explicitement autorisées. Pour plus d'informations, consultez la section Cas de sortie.
Pour les activations du niveau Premium de Security Command Center au niveau du projet, ce résultat n'est disponible que si le niveau Standard est activé dans l'organisation parente.
Pour corriger ce résultat, procédez comme suit :
Accédez à la page Pare-feu de la console Google Cloud.
Cliquez sur Create Firewall Rule (Créer une règle de pare-feu).
Attribuez un nom et, éventuellement, une description au pare-feu.
Pour le champ Sens du trafic, sélectionnez Sortie.
Sous Action en cas de correspondance, sélectionnez Refuser.
Dans le menu déroulant Cibles, sélectionnez Toutes les instances du réseau.
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.Sous Protocoles et ports, sélectionnez Tout refuser.
Cliquez sur Désactiver la règle puis, sous Application, sélectionnez Activée.
Cliquez sur Créer.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesEssential contacts not configured
Nom de la catégorie dans l'API : ESSENTIAL_CONTACTS_NOT_CONFIGURED
Votre organisation n'a désigné aucune personne ni aucun groupe pour recevoir des notifications de Google Cloud concernant des événements importants tels que des attaques, des failles et des incidents liés aux données au sein de votre organisation Google Cloud. Nous vous recommandons de désigner comme contact essentiel une ou plusieurs personnes ou groupes de votre organisation.
Pour corriger ce résultat, procédez comme suit :
Accédez à la page Contacts essentiels de la console Google Cloud.
Assurez-vous que l'organisation apparaît dans le sélecteur de ressources en haut de la page. Le sélecteur de ressources vous indique pour quel projet, dossier ou organisation vous gérez actuellement les contacts.
Cliquez sur +Ajouter un contact. Le panneau Ajouter un contact s'ouvre.
Dans les champs Email (Adresse e-mail) et Confirm Email (Confirmer l'adresse e-mail), saisissez l'adresse e-mail du contact.
Dans la section Catégories de notifications, sélectionnez les catégories de notifications pour lesquelles vous souhaitez que le contact reçoive des communications. Assurez-vous que les adresses e-mail appropriées sont configurées pour chacune des catégories de notification suivantes:
- Legal
- Sécurité
- Suspension
- Technique
Cliquez sur Enregistrer. paramètres d'éléments et d'analyse compatibles avec ce type de résultat.
Découvrez les
Firewall not monitored
Nom de la catégorie dans l'API : FIREWALL_NOT_MONITORED
Les statistiques et les alertes de journal ne sont pas configurées pour surveiller les modifications apportées aux règles de pare-feu de réseau VPC.
La surveillance des événements de création et de mise à jour des règles de pare-feu vous donne le détail des modifications d'accès au réseau, et vous permet de détecter rapidement les activités suspectes. Pour en savoir plus, consultez la présentation des métriques basées sur les journaux.
Selon la quantité d'informations, les coûts liés à Cloud Monitoring peuvent être importants. Pour comprendre votre utilisation du service et ses coûts, consultez la page Optimisation des coûts pour l'observabilité Google Cloud.
Pour les activations du niveau Premium de Security Command Center au niveau du projet, ce résultat n'est disponible que si le niveau Standard est activé dans l'organisation parente.
Pour corriger ce résultat, procédez comme suit :
Créer une métrique
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:
resource.type="gce_firewall_rule" AND (protoPayload.methodName:"compute.firewalls.insert" OR protoPayload.methodName:"compute.firewalls.patch" OR protoPayload.methodName:"compute.firewalls.delete")
Cliquez sur Créer la métrique. Un message de confirmation s'affiche.
Créer une règle d'alerte
-
Dans le panneau de navigation de la console Google Cloud, sélectionnez Logging, puis Métriques basées sur les journaux :
- 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 lorsque des incidents sont ouverts ou fermés, cochez Notifier en cas de fermeture d'incident. 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.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesFirewall rule logging disabled
Nom de la catégorie dans l'API : FIREWALL_RULE_LOGGING_DISABLED
La journalisation des règles de pare-feu est désactivée.
La journalisation des règles de pare-feu vous permet de réaliser des audits, des vérifications et des analyses sur les effets de vos règles de pare-feu. Cela peut vous être utile pour auditer l'accès au réseau ou pour identifier le plus tôt possible les cas d'utilisation non approuvée du réseau. Le coût des journaux peut être important. Pour en savoir plus sur la journalisation des règles de pare-feu et son coût, consultez la page Utiliser la journalisation des règles de pare-feu.
Pour corriger ce résultat, procédez comme suit :
Accédez à la page Pare-feu de la console Google Cloud.
Dans la liste des règles de pare-feu, cliquez sur le nom de la règle de pare-feu souhaitée.
Cliquez sur edit Modifier.
Sous Journaux, sélectionnez Activé.
Cliquez sur Enregistrer.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesFlow logs disabled
Nom de la catégorie dans l'API : FLOW_LOGS_DISABLED
Les journaux de flux sont désactivés dans un sous-réseau VPC.
Les journaux de flux VPC enregistrent un échantillon des flux réseau envoyés et reçus par les instances de VM. Ces journaux peuvent être utilisés pour la surveillance et l'investigation des réseaux, l'analyse de la sécurité en temps réel et l'optimisation des dépenses. Pour en savoir plus sur les journaux de flux et leur coût, consultez la page Utiliser des journaux de flux VPC.
Pour corriger ce résultat, procédez comme suit :
Accédez à la page Réseaux VPC dans Google Cloud Console.
Dans la liste des réseaux, cliquez sur le nom du réseau souhaité.
Sur la page Détails du réseau VPC, cliquez sur l'onglet Sous-réseaux.
Dans la liste des sous-réseaux, cliquez sur le nom du sous-réseau indiqué dans le résultat.
Sur la page Détails du sous-réseau, cliquez sur edit Modifier.
Sous Journaux de flux, sélectionnez Activé.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesFlow logs settings not recommended
Nom de la catégorie dans l'API : VPC_FLOW_LOGS_SETTINGS_NOT_RECOMMENDED
Dans la configuration d'un sous-réseau dans un réseau VPC, le service de journaux de flux VPC est désactivé ou n'est pas configuré conformément aux recommandations du benchmark CIS 1.3. Les journaux de flux VPC enregistrent un échantillon des flux réseau envoyés et reçus par les instances de VM, lequel peut être utilisé pour détecter des menaces.
Pour en savoir plus sur les journaux de flux VPC et leur coût, consultez la page Utiliser des journaux de flux VPC.
Pour corriger ce résultat, procédez comme suit :
Accédez à la page Réseaux VPC dans Google Cloud Console.
Dans la liste des réseaux, cliquez sur le nom du réseau.
Sur la page Détails du réseau VPC, cliquez sur l'onglet Sous-réseaux.
Dans la liste des sous-réseaux, cliquez sur le nom du sous-réseau indiqué dans le résultat.
Sur la page Détails du sous-réseau, cliquez sur edit Modifier.
Sous Journaux de flux, sélectionnez Activé.
- Si vous le souhaitez, modifiez la configuration des journaux en cliquant sur le bouton Configurer les journaux pour développer l'onglet. Les benchmarks CIS recommandent les paramètres suivants :
- Définissez l'intervalle d'agrégation sur 5 secondes.
- Dans la case Champs supplémentaires, sélectionnez l'option Inclure les métadonnées.
- Définissez le taux d'échantillonnage sur 100%.
- Cliquez sur le bouton ENREGISTRER.
- Si vous le souhaitez, modifiez la configuration des journaux en cliquant sur le bouton Configurer les journaux pour développer l'onglet. Les benchmarks CIS recommandent les paramètres suivants :
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesFull API access
Nom de la catégorie dans l'API : FULL_API_ACCESS
Une instance Compute Engine est configurée pour utiliser le compte de service par défaut avec un accès complet à toutes les API Google Cloud.
Une instance configurée avec le 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 :
Accédez à la page Instances de VM de la console Google Cloud.
Dans la liste des instances, cliquez sur le nom de l'instance dans le résultat.
Cliquez sur
Arrêter si l'instance est en cours d'exécution.Une fois l'instance arrêtée, cliquez sur edit Modifier.
Sous Compte de service, dans le menu déroulant, sélectionnez Compte de service Compute Engine par défaut.
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.
Cliquez sur Enregistrer.
Cliquez sur
Démarrer pour démarrer l'instance.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesHTTP load balancer
Nom de la catégorie dans l'API : HTTP_LOAD_BALANCER
Une instance utilise un équilibreur de charge configuré pour utiliser un proxy HTTP au lieu d'un proxy HTTPS comme cible.
Pour protéger l'intégrité de vos données et empêcher des intrus de falsifier vos communications, configurez vos équilibreurs de charge HTTP(S) de manière à autoriser uniquement le trafic HTTPS. Pour plus d'informations, consultez la page Présentation de l'équilibrage de charge HTTP(S) externe.
Pour les activations du niveau Premium de Security Command Center au niveau du projet, ce résultat n'est disponible que si le niveau Standard est activé dans l'organisation parente.
Pour corriger ce résultat, procédez comme suit :
Accédez à la page Proxies cibles de la console Google Cloud.
Dans la liste des proxys cibles, cliquez sur le nom du proxy cible dans le résultat.
Cliquez sur le lien dans la section Mappage d'URL.
Cliquez sur edit Modifier.
Cliquez sur Configuration de l'interface.
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.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesInstance OS login disabled
Nom de la catégorie dans l'API : INSTANCE_OS_LOGIN_DISABLED
OS Login est désactivé sur cette instance Compute Engine.
OS Login active la gestion centralisée des clés SSH avec IAM et désactive les configurations de clés SSH basées sur les métadonnées dans toutes les instances d'un projet. Découvrez comment Configurer OS Login.
Pour les activations du niveau Premium de Security Command Center au niveau du projet, ce résultat n'est disponible que si le niveau Standard est activé dans l'organisation parente.
Pour corriger ce résultat, procédez comme suit :
Accédez à la page Instances de VM de la console Google Cloud.
Dans la liste des instances, cliquez sur le nom de l'instance dans le résultat.
Sur la page Détails de l'instance qui s'affiche, cliquez sur
Arrêter.Une fois l'instance arrêtée, cliquez sur edit Modifier.
Dans la section Métadonnées personnalisées, assurez-vous que l'élément comportant la clé enable-oslogin a la valeur TRUE.
Cliquez sur Enregistrer.
Cliquez sur
Démarrer pour démarrer l'instance.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesIntegrity monitoring disabled
Nom de la catégorie dans l'API : INTEGRITY_MONITORING_DISABLED
La surveillance de l'intégrité est désactivée sur un cluster GKE.
La surveillance de l'intégrité vous permet de contrôler et de valider l'intégrité, au démarrage de l'environnement d'exécution, de vos nœuds protégés avec Cloud Monitoring. Vous pouvez ainsi réagir aux échecs d'intégrité et empêcher le déploiement de nœuds compromis dans le cluster.
Pour corriger ce résultat, procédez comme suit :
Une fois qu'un nœud est provisionné, il ne peut pas être mis à jour pour activer la surveillance de l'intégrité. Vous devez créer un pool de nœuds dans lequel la surveillance de l'intégrité est activée.
Accédez à la page des Clusters Kubernetes GKE dans la console Google Cloud.
Cliquez sur le nom du cluster dans le résultat.
Cliquez sur Aouter un pool de nœuds.
Dans l'onglet Sécurité, assurez-vous que l'option Activer la surveillance de l'intégrité est activée.
Cliquez sur Créer.
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.
Une fois les charges de travail déplacées, supprimez le pool de nœuds non conforme d'origine.
- Sur la page du cluster Kubernetes, dans le menu Pools de nœuds, cliquez sur le nom du pool que vous voulez supprimer.
- Cliquez sur Supprimer le pool de nœuds.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesIntranode visibility disabled
Nom de la catégorie dans l'API : INTRANODE_VISIBILITY_DISABLED
La visibilité intranœud est désactivée pour un cluster GKE.
L'activation de la visibilité intranœud rend le trafic intranœud entre pods visible par la structure de mise en réseau. Grâce à cette fonctionnalité, vous pouvez utiliser la journalisation de flux VPC ou d'autres fonctionnalités de VPC pour surveiller ou contrôler le trafic intranœud. Pour obtenir les journaux, vous devez activer les journaux de flux VPC dans le sous-réseau sélectionné. Pour plus d'informations, consultez la page Utiliser des journaux de flux VPC.
Pour corriger ce résultat, procédez comme suit :
Une fois qu'un nœud est provisionné, il ne peut pas être mis à jour pour activer la surveillance de l'intégrité. Vous devez créer un pool de nœuds dans lequel la surveillance de l'intégrité est activée.
Accédez à la page des Clusters Kubernetes GKE dans la console Google Cloud.
Dans la section Mise en réseau, cliquez sur l'icône de modification (edit) 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.
Dans la boîte de dialogue, sélectionnez Activer la visibilité intranœud.
Cliquez sur Save Changes (Enregistrer les modifications).
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesIP alias disabled
Nom de la catégorie dans l'API : IP_ALIAS_DISABLED
Un cluster GKE a été créé avec des plages d'adresses IP d'alias désactivées.
Lorsque vous activez les plages d'adresses IP d'alias, les clusters GKE allouent des adresses IP provenant d'un bloc CIDR connu, pour que votre cluster soit évolutif et interagisse plus facilement avec les produits et entités Google Cloud. Pour 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 :
Accédez à la page des Clusters Kubernetes GKE dans la console Google Cloud.
Cliquez sur Créer.
Dans le volet de navigation, sous Cluster, cliquez sur Réseau.
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).
Cliquez sur Créer.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesIP forwarding enabled
Nom de la catégorie dans l'API : IP_FORWARDING_ENABLED
Le transfert IP est activé sur les instances Compute Engine.
Évitez les pertes de données et la divulgation d'informations en désactivant le transfert IP des paquets de données pour vos VM.
Pour corriger ce résultat, procédez comme suit :
Accédez à la page Instances de VM de la console Google Cloud.
Dans la liste des instances, cochez la case située à côté du nom de l'instance dans le résultat.
Cliquez sur delete Supprimer.
Sélectionnez Créer une instance pour créer une instance afin de remplacer celle que vous avez supprimée.
Pour vous assurer que le transfert IP est désactivé, cliquez sur Gestion, disques, réseau, clés SSH, puis sur Réseau.
Sous Interfaces réseau, cliquez sur edit Modifier.
Sous Transfert IP, dans le menu déroulant, assurez-vous que l'option Désactivé est sélectionnée.
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.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesKMS key not rotated
Nom de la catégorie dans l'API : KMS_KEY_NOT_ROTATED
La rotation n'est pas configurée sur une clé de chiffrement Cloud KMS.
La rotation de vos clés de chiffrement offre régulièrement une protection en cas de compromission d'une clé et limite le nombre de messages chiffrés disponibles à la cryptanalyse pour une version de clé spécifique. Pour en savoir plus, consultez la page Rotation des clés.
Pour corriger ce résultat, procédez comme suit :
Accédez à la page Clés Cloud KMS de la console Google Cloud.
Cliquez sur le nom du trousseau de clés indiqué dans le résultat.
Cliquez sur le nom de la clé indiquée dans le résultat.
Cliquez sur Modifier la période de rotation.
Définissez la période de rotation sur 90 jours au maximum.
Cliquez sur Enregistrer.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesKMS project has owner
Nom de la catégorie dans l'API : KMS_PROJECT_HAS_OWNER
Un utilisateur dispose des autorisations roles/Owner
sur un projet disposant de clés cryptographiques.
Pour en savoir plus, consultez la section Autorisations et rôles.
Pour les activations du niveau Premium de Security Command Center au niveau du projet, ce résultat n'est disponible que si le niveau Standard est activé dans l'organisation parente.
Pour corriger ce résultat, procédez comme suit :
Accédez à la page "IAM" de Google Cloud Console.
Si nécessaire, sélectionnez le projet dans les résultats.
Pour chaque compte principal auquel le rôle Propriétaire a été attribué :
- Cliquez sur edit Modifier.
- Dans le panneau Modifier les autorisations, à côté du rôle Propriétaire, cliquez sur delete Supprimer.
- Cliquez sur Enregistrer.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesKMS public key
Nom de la catégorie dans l'API : KMS_PUBLIC_KEY
Une clé Cryptokey Cloud KMS ou un trousseau de clés Cloud KMS est public et accessible à tous les internautes. Pour en savoir plus, consultez la page Utiliser IAM avec Cloud KMS.
Pour corriger ce résultat, s'il est lié à une clé Cryptokey :
Accédez à la page des clés de chiffrement dans la console Google Cloud.
Sous Nom, sélectionnez le trousseau de clés contenant la clé cryptographique associée au résultat de Security Health Analytics.
Sur la page Informations sur le trousseau qui s'affiche, cochez la case en regard de la clé cryptographique.
Si le PANNEAU D'INFORMATIONS n'apparaît pas, cliquez sur le bouton AFFICHER LE PANNEAU D'INFORMATIONS.
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 delete pour supprimer l'accès de ces comptes principaux.
Pour corriger ce résultat, s'il est lié à un trousseau de clés :
Accédez à la page des clés de chiffrement dans la console Google Cloud.
Recherchez la ligne contenant le trousseau de clés dans le résultat, puis cochez la case correspondante.
Si le PANNEAU D'INFORMATIONS n'apparaît pas, cliquez sur le bouton AFFICHER LE PANNEAU D'INFORMATIONS.
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 delete pour supprimer l'accès de ces comptes principaux.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesKMS role separation
Nom de la catégorie dans l'API : KMS_ROLE_SEPARATION
Ce résultat n'est pas disponible pour les activations au niveau du projet.
Plusieurs autorisations Cloud KMS sont attribuées à un ou plusieurs comptes principaux. Nous vous recommandons de ne pas attribuer simultanément l'autorisation Administrateur Cloud KMS avec d'autres autorisations Cloud KMS. Pour en savoir plus, consultez la section Autorisations et rôles.
Pour corriger ce résultat, procédez comme suit :
Accédez à la page "IAM" de Google Cloud Console.
Pour chaque compte principal répertorié dans le résultat, procédez comme suit :
- 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.
- Cliquez sur Modifier edit à côté d'un compte principal.
- Pour supprimer les autorisations, cliquez sur Supprimer delete à 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.
Cliquez sur Enregistrer.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesLegacy authorization enabled
Nom de la catégorie dans l'API : LEGACY_AUTHORIZATION_ENABLED
L'ancienne autorisation est activée sur les clusters GKE.
Dans Kubernetes, le contrôle des accès basé sur les rôles permet de définir des rôles avec des règles contenant un ensemble d'autorisations, et d'accorder des autorisations au niveau du cluster et de l'espace de noms. Ce mécanisme renforce la sécurité en garantissant que les utilisateurs n'ont accès qu'à des ressources spécifiques. Envisagez de désactiver l'ancien contrôle des accès basé sur les attributs (ABAC).
Pour corriger ce résultat, procédez comme suit :
Accédez à la page des Clusters Kubernetes GKE dans la console Google Cloud.
Sélectionnez le cluster répertorié dans le résultat de Security Health Analytics.
Cliquez sur edit Modifier.
Si la configuration du cluster a récemment été modifiée, il est possible que le bouton "Modifier" ne soit pas disponible. Si vous ne pouvez pas modifier les paramètres du cluster, attendez quelques minutes, puis réessayez.
Dans la liste déroulante Ancienne autorisation, sélectionnez Désactivée.
Cliquez sur Enregistrer.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesLegacy metadata enabled
Nom de la catégorie dans l'API : LEGACY_METADATA_ENABLED
Les anciennes métadonnées sont activées sur les clusters GKE.
Le serveur de métadonnées d'instance de Compute Engine expose les anciens points de terminaison /0.1/
et /v1beta1/
qui n'appliquent pas les en-têtes de requête de métadonnées. Il s'agit d'une fonctionnalité des API /v1/
qui rend plus difficile la récupération de métadonnées d'instance par un éventuel pirate informatique. Sauf indication contraire, nous vous recommandons de désactiver ces anciennes API /0.1/
et /v1beta1/
.
Pour en savoir plus, consultez la section Désactiver les anciennes API de métadonnées et effectuer une migration.
Pour corriger ce résultat, procédez comme suit :
Vous ne pouvez désactiver les anciennes API de métadonnées que lorsque vous créez un cluster ou lorsque vous ajoutez un nouveau pool de nœuds à un cluster existant. Pour mettre à jour un cluster existant afin de désactiver les anciennes API de métadonnées, consultez la section Migrer des charges de travail vers différents types de machines.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesLegacy network
Nom de la catégorie dans l'API : LEGACY_NETWORK
Un ancien réseau existe dans un projet.
Les anciens réseaux ne sont pas recommandés, car de nombreuses nouvelles fonctionnalités de sécurité Google Cloud ne sont pas compatibles avec les anciens réseaux. Utilisez plutôt les réseaux VPC. Pour en savoir plus, consultez la section Anciens réseaux.
Pour les activations du niveau Premium de Security Command Center au niveau du projet, ce résultat n'est disponible que si le niveau Standard est activé dans l'organisation parente.
Pour corriger ce résultat, procédez comme suit :
Accédez à la page Réseaux VPC dans Google Cloud Console.
Pour créer un réseau non hérité, cliquez sur Créer un réseau.
Revenez à la page VPC networks (Réseaux VPC).
Dans la liste des réseaux, cliquez sur legacy_network.
Sur la page Détails du réseau VPC, cliquez sur delete Supprimer le réseau VPC.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesLoad balancer logging disabled
Nom de la catégorie dans l'API : LOAD_BALANCER_LOGGING_DISABLED
La journalisation est désactivée pour le service de backend dans un équilibreur de charge.
L'activation de la journalisation pour un équilibreur de charge vous permet d'afficher le trafic réseau HTTP(S) pour vos applications Web. Pour en savoir plus, consultez la page Équilibreur de charge.
Pour corriger ce résultat, procédez comme suit :
Accédez à la page Cloud Load Balancing dans la console Google Cloud.
Cliquez sur le nom de votre équilibreur de charge.
Cliquez sur Modifier edit.
Cliquez sur Configuration du backend.
Sur la page Configuration du backend, cliquez sur edit.
Dans la section Journalisation, sélectionnez Activer la journalisation et choisissez le meilleur taux d'échantillonnage pour votre projet.
Pour terminer la modification du service de backend, cliquez sur Mettre à jour.
Pour terminer la modification de l'équilibreur de charge, cliquez sur Mettre à jour.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesLocked retention policy not set
Nom de la catégorie dans l'API : LOCKED_RETENTION_POLICY_NOT_SET
Une règle de conservation verrouillée n'est pas définie pour les journaux.
Une règle de conservation verrouillée empêche d'écraser des journaux et de supprimer le bucket de journaux. Pour en savoir plus, consultez la page Verrou de bucket.
Pour les activations du niveau Premium de Security Command Center au niveau du projet, ce résultat n'est disponible que si le niveau Standard est activé dans l'organisation parente.
Pour corriger ce résultat, procédez comme suit :
Accédez à la page Navigateur de stockage de la console Google Cloud.
Sélectionnez le bucket répertorié dans le résultat de Security Health Analytics.
Sur la page Informations sur le bucket, cliquez sur l'onglet Autorisations.
Si aucune règle de conservation n'a été définie, cliquez sur Définir une règle de conservation.
Indiquez une durée de conservation.
Cliquez sur Enregistrer. La règle de conservation s'affiche dans l'onglet Conservation.
Cliquez sur Verrouiller pour vous assurer que la durée de conservation n'est pas raccourcie ni supprimée.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesLog not exported
Nom de la catégorie dans l'API : LOG_NOT_EXPORTED
Aucun récepteur de journaux approprié n'est configuré pour une ressource.
Cloud Logging vous aide à trouver rapidement la cause des problèmes dans votre système et vos applications. Toutefois, la plupart des journaux ne sont conservés par défaut que pendant 30 jours. Exportez des copies de toutes les entrées de journal pour prolonger la période de stockage. Pour en savoir plus, consultez la section Présentation des exportations de journaux.
Pour les activations du niveau Premium de Security Command Center au niveau du projet, ce résultat n'est disponible que si le niveau Standard est activé dans l'organisation parente.
Pour corriger ce résultat, procédez comme suit :
Accédez à la page Routeur de journaux de la console Google Cloud.
Cliquez sur Créer un récepteur.
Pour exporter tous les journaux, laissez les filtres d'inclusion et d'exclusion vides.
Cliquez sur Créer un récepteur.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesMaster authorized networks disabled
Nom de la catégorie dans l'API : 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 :
Accédez à la page des Clusters Kubernetes GKE dans la console Google Cloud.
Sélectionnez le cluster répertorié dans le résultat de Security Health Analytics.
Cliquez sur edit Modifier.
Si la configuration du cluster a récemment été modifiée, il est possible que le bouton "Modifier" ne soit pas disponible. Si vous ne pouvez pas modifier les paramètres du cluster, attendez quelques minutes, puis réessayez.
Dans la liste déroulante Réseaux autorisés pour le plan de contrôle, sélectionnez Activés.
Cliquez sur Add authorized network (Ajouter un réseau autorisé).
Spécifiez les réseaux autorisés que vous souhaitez utiliser.
Cliquez sur Enregistrer.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesMFA not enforced
Nom de la catégorie dans l'API : MFA_NOT_ENFORCED
Ce résultat n'est pas disponible pour les activations au niveau du projet.
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 :
Accédez à la page Console d'administration de la console Google Cloud.
Appliquez la validation en deux étapes pour toutes les unités organisationnelles.
Supprimer les résultats de ce type
Pour supprimer les résultats de ce type, définissez une règle Ignorer qui annule automatiquement les futurs résultats de ce type. Pour en savoir plus, consultez la section Ignorer des résultats dans Security Command Center.
Bien qu'il ne s'agisse pas d'une méthode recommandée pour supprimer des résultats, vous pouvez également ajouter des marques de sécurité dédiées aux éléments afin que les détecteurs Security Health Analytics 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 valeurtrue
à 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
.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesNetwork not monitored
Nom de la catégorie dans l'API : 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 ses coûts, consultez la page Optimisation des coûts pour l'observabilité Google Cloud.
Pour les activations du niveau Premium de Security Command Center au niveau du projet, ce résultat n'est disponible que si le niveau Standard est activé dans l'organisation parente.
Pour corriger ce résultat, procédez comme suit :
Créer une métrique
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:
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")
Cliquez sur Créer la métrique. Un message de confirmation s'affiche.
Créer une règle d'alerte
-
Dans le panneau de navigation de la console Google Cloud, sélectionnez Logging, puis Métriques basées sur les journaux :
- 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 lorsque des incidents sont ouverts ou fermés, cochez Notifier en cas de fermeture d'incident. 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.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesNetwork policy disabled
Nom de la catégorie dans l'API : 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 :
Accédez à la page des Clusters Kubernetes GKE dans la console Google Cloud.
Cliquez sur le nom du cluster répertorié dans le résultat de Security Health Analytics.
Sous Mise en réseau, sur la ligne Règle de réseau Kubernetes pour Calico, cliquez sur edit Modifier.
Si la configuration du cluster a récemment été modifiée, il est possible que le bouton "Modifier" ne soit pas disponible. Si vous ne pouvez pas modifier les paramètres du cluster, attendez quelques minutes, puis réessayez.
Dans la boîte de dialogue, sélectionnez Activer la règle de réseau Kubernetes pour Calico pour le plan de contrôle et Activer la règle de réseau Kubernetes pour Calico pour les nœuds.
Cliquez sur Save Changes (Enregistrer les modifications).
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesNodepool boot CMEK disabled
Nom de la catégorie dans l'API : 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 :
Accédez à la page des Clusters Kubernetes GKE dans la console Google Cloud.
Dans la liste des clusters, cliquez sur le nom du cluster dans le résultat.
Cliquez sur l'onglet Nœuds.
Pour chaque pool de nœuds default-pool, cliquez sur Supprimer delete.
Lorsque vous êtes invité à confirmer votre choix, cliquez sur Supprimer.
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.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesNodepool secure boot disabled
Nom de la catégorie dans l'API : 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é.
Accédez à la page des Clusters Kubernetes GKE dans la console Google Cloud.
Cliquez sur le nom du cluster dans le résultat.
Cliquez sur Aouter un pool de nœuds.
Dans le menu Pools de nœuds, procédez comme suit :
- Cliquez sur le nom du nouveau pool de nœuds pour développer l'onglet.
- Sélectionnez Sécurité puis, sous Options protégées, sélectionnez Activer le démarrage sécurisé.
- Cliquez sur Créer.
- 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.
- Une fois les charges de travail déplacées, supprimez le pool de nœuds non conforme d'origine.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesNon org IAM member
Nom de la catégorie dans l'API : NON_ORG_IAM_MEMBER
Un utilisateur extérieur à votre organisation ou à votre projet dispose d'autorisations IAM pour un projet ou une organisation. Découvrez les autorisations IAM.
Pour corriger ce résultat, procédez comme suit :
Accédez à la page "IAM" de Google Cloud Console.
Cochez la case à côté des utilisateurs externes à votre organisation ou à votre projet.
Cliquez sur Supprimer.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesObject versioning disabled
Nom de la catégorie dans l'API : 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 les activations du niveau Premium de Security Command Center au niveau du projet, ce résultat n'est disponible que si le niveau Standard est activé dans l'organisation parente.
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é.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesOpen Cassandra port
Nom de la catégorie dans l'API : 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 :
Accédez à la page Pare-feu de la console Google Cloud.
Dans la liste des règles de pare-feu, cliquez sur le nom de la règle de pare-feu dans le résultat.
Cliquez sur edit Modifier.
Sous Plages d'adresses IP sources, supprimez
0.0.0.0/0
.Ajoutez des adresses IP ou des plages d'adresses IP spécifiques pour permettre les connexions à l'instance à partir de ces adresses
Ajoutez les protocoles et ports spécifiques que vous souhaitez ouvrir sur votre instance.
Cliquez sur Enregistrer.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesOpen ciscosecure websm port
Nom de la catégorie dans l'API : 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 :
Accédez à la page Pare-feu de la console Google Cloud.
Dans la liste des règles de pare-feu, cliquez sur le nom de la règle de pare-feu dans le résultat.
Cliquez sur edit Modifier.
Sous Plages d'adresses IP sources, supprimez
0.0.0.0/0
.Ajoutez des adresses IP ou des plages d'adresses IP spécifiques pour permettre les connexions à l'instance à partir de ces adresses
Ajoutez les protocoles et ports spécifiques que vous souhaitez ouvrir sur votre instance.
Cliquez sur Enregistrer.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesOpen directory services port
Nom de la catégorie dans l'API : 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 :
Accédez à la page Pare-feu de la console Google Cloud.
Dans la liste des règles de pare-feu, cliquez sur le nom de la règle de pare-feu dans le résultat.
Cliquez sur edit Modifier.
Sous Plages d'adresses IP sources, supprimez
0.0.0.0/0
.Ajoutez des adresses IP ou des plages d'adresses IP spécifiques pour permettre les connexions à l'instance à partir de ces adresses
Ajoutez les protocoles et ports spécifiques que vous souhaitez ouvrir sur votre instance.
Cliquez sur Enregistrer.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesOpen DNS port
Nom de la catégorie dans l'API : 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 :
Accédez à la page Pare-feu de la console Google Cloud.
Dans la liste des règles de pare-feu, cliquez sur le nom de la règle de pare-feu dans le résultat.
Cliquez sur edit Modifier.
Sous Plages d'adresses IP sources, supprimez
0.0.0.0/0
.Ajoutez des adresses IP ou des plages d'adresses IP spécifiques pour permettre les connexions à l'instance à partir de ces adresses
Ajoutez les protocoles et ports spécifiques que vous souhaitez ouvrir sur votre instance.
Cliquez sur Enregistrer.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesOpen Elasticsearch port
Nom de la catégorie dans l'API : 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 :
Accédez à la page Pare-feu de la console Google Cloud.
Dans la liste des règles de pare-feu, cliquez sur le nom de la règle de pare-feu dans le résultat.
Cliquez sur edit Modifier.
Sous Plages d'adresses IP sources, supprimez
0.0.0.0/0
.Ajoutez des adresses IP ou des plages d'adresses IP spécifiques pour permettre les connexions à l'instance à partir de ces adresses
Ajoutez les protocoles et ports spécifiques que vous souhaitez ouvrir sur votre instance.
Cliquez sur Enregistrer.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesOpen firewall
Nom de la catégorie dans l'API : 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 :
Accédez à la page Règles de pare-feu de la console Google Cloud.
Cliquez sur la règle de pare-feu répertoriée dans le résultat de Security Health Analytics, puis sur edit Modifier.
Sous Plages d'adresses IP sources, modifiez les valeurs de d'adresse IP pour restreindre la plage d'adresses IP autorisées.
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.
Cliquez sur Enregistrer.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesOpen FTP port
Nom de la catégorie dans l'API : 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 :
Accédez à la page Pare-feu de la console Google Cloud.
Dans la liste des règles de pare-feu, cliquez sur le nom de la règle de pare-feu dans le résultat.
Cliquez sur edit Modifier.
Sous Plages d'adresses IP sources, supprimez
0.0.0.0/0
.Ajoutez des adresses IP ou des plages d'adresses IP spécifiques pour permettre les connexions à l'instance à partir de ces adresses
Ajoutez les protocoles et ports spécifiques que vous souhaitez ouvrir sur votre instance.
Cliquez sur Enregistrer.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesOpen group IAM member
Nom de la catégorie dans l'API : OPEN_GROUP_IAM_MEMBER
Un ou plusieurs comptes principaux ayant accès à une organisation, un projet ou un dossier sont des comptes Google Groupes pouvant être associés sans approbation.
Les clients Google Cloud peuvent utiliser des groupes Google pour gérer les rôles et les autorisations des membres de leur organisation, ou appliquer des règles d'accès à des groupes d'utilisateurs. Au lieu d'attribuer des rôles directement aux membres, les administrateurs peuvent attribuer des rôles et des autorisations à des groupes Google, puis ajouter des membres à des groupes spécifiques. Les membres du groupe héritent de l'ensemble des rôles et des autorisations de ce groupe, ce qui leur permet d'accéder à des ressources et à des services spécifiques.
Si un compte Google Groupes ouvert est utilisé comme compte principal dans une liaison IAM, n'importe qui peut hériter du rôle associé en rejoignant le groupe directement ou indirectement (via un sous-groupe). Nous vous recommandons de révoquer les rôles des groupes ouverts ou de limiter l'accès à ces groupes.
Pour corriger ce problème, effectuez l'une des procédures suivantes.
Supprimer le groupe de la stratégie IAM
Accédez à la page "IAM" de Google Cloud Console.
Si nécessaire, sélectionnez le projet, le dossier ou l'organisation dans le résultat.
Révoquez le rôle de chaque groupe ouvert identifié dans le résultat.
Limiter l'accès aux groupes ouverts
- Connectez-vous à Google Groupes.
- Mettez à jour les paramètres de chaque groupe ouvert et des sous-groupes associés pour spécifier qui peut rejoindre le groupe et qui doit approuver les demandes.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesOpen HTTP port
Nom de la catégorie dans l'API : 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 :
Accédez à la page Pare-feu de la console Google Cloud.
Dans la liste des règles de pare-feu, cliquez sur le nom de la règle de pare-feu dans le résultat.
Cliquez sur edit Modifier.
Sous Plages d'adresses IP sources, supprimez
0.0.0.0/0
.Ajoutez des adresses IP ou des plages d'adresses IP spécifiques pour permettre les connexions à l'instance à partir de ces adresses
Ajoutez les protocoles et ports spécifiques que vous souhaitez ouvrir sur votre instance.
Cliquez sur Enregistrer.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesOpen LDAP port
Nom de la catégorie dans l'API : 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 :
Accédez à la page Pare-feu de la console Google Cloud.
Dans la liste des règles de pare-feu, cliquez sur le nom de la règle de pare-feu dans le résultat.
Cliquez sur edit Modifier.
Sous Plages d'adresses IP sources, supprimez
0.0.0.0/0
.Ajoutez des adresses IP ou des plages d'adresses IP spécifiques pour permettre les connexions à l'instance à partir de ces adresses
Ajoutez les protocoles et ports spécifiques que vous souhaitez ouvrir sur votre instance.
Cliquez sur Enregistrer.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesOpen Memcached port
Nom de la catégorie dans l'API : 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 :
Accédez à la page Pare-feu de la console Google Cloud.
Dans la liste des règles de pare-feu, cliquez sur le nom de la règle de pare-feu dans le résultat.
Cliquez sur edit Modifier.
Sous Plages d'adresses IP sources, supprimez
0.0.0.0/0
.Ajoutez des adresses IP ou des plages d'adresses IP spécifiques pour permettre les connexions à l'instance à partir de ces adresses
Ajoutez les protocoles et ports spécifiques que vous souhaitez ouvrir sur votre instance.
Cliquez sur Enregistrer.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesOpen MongoDB port
Nom de la catégorie dans l'API : 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 :
Accédez à la page Pare-feu de la console Google Cloud.
Dans la liste des règles de pare-feu, cliquez sur le nom de la règle de pare-feu dans le résultat.
Cliquez sur edit Modifier.
Sous Plages d'adresses IP sources, supprimez
0.0.0.0/0
.Ajoutez des adresses IP ou des plages d'adresses IP spécifiques pour permettre les connexions à l'instance à partir de ces adresses
Ajoutez les protocoles et ports spécifiques que vous souhaitez ouvrir sur votre instance.
Cliquez sur Enregistrer.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesOpen MySQL port
Nom de la catégorie dans l'API : 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 :
Accédez à la page Pare-feu de la console Google Cloud.
Dans la liste des règles de pare-feu, cliquez sur le nom de la règle de pare-feu dans le résultat.
Cliquez sur edit Modifier.
Sous Plages d'adresses IP sources, supprimez
0.0.0.0/0
.Ajoutez des adresses IP ou des plages d'adresses IP spécifiques pour permettre les connexions à l'instance à partir de ces adresses
Ajoutez les protocoles et ports spécifiques que vous souhaitez ouvrir sur votre instance.
Cliquez sur Enregistrer.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesOpen NetBIOS port
Nom de la catégorie dans l'API : `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 :
Accédez à la page Pare-feu de la console Google Cloud.
Dans la liste des règles de pare-feu, cliquez sur le nom de la règle de pare-feu dans le résultat.
Cliquez sur edit Modifier.
Sous Plages d'adresses IP sources, supprimez
0.0.0.0/0
.Ajoutez des adresses IP ou des plages d'adresses IP spécifiques pour permettre les connexions à l'instance à partir de ces adresses
Ajoutez les protocoles et ports spécifiques que vous souhaitez ouvrir sur votre instance.
Cliquez sur Enregistrer.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesOpen OracleDB port
Nom de la catégorie dans l'API : 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 :
Accédez à la page Pare-feu de la console Google Cloud.
Dans la liste des règles de pare-feu, cliquez sur le nom de la règle de pare-feu dans le résultat.
Cliquez sur edit Modifier.
Sous Plages d'adresses IP sources, supprimez
0.0.0.0/0
.Ajoutez des adresses IP ou des plages d'adresses IP spécifiques pour permettre les connexions à l'instance à partir de ces adresses
Ajoutez les protocoles et ports spécifiques que vous souhaitez ouvrir sur votre instance.
Cliquez sur Enregistrer.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesOpen POP3 port
Nom de la catégorie dans l'API : 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 :
Accédez à la page Pare-feu de la console Google Cloud.
Dans la liste des règles de pare-feu, cliquez sur le nom de la règle de pare-feu dans le résultat.
Cliquez sur edit Modifier.
Sous Plages d'adresses IP sources, supprimez
0.0.0.0/0
.Ajoutez des adresses IP ou des plages d'adresses IP spécifiques pour permettre les connexions à l'instance à partir de ces adresses
Ajoutez les protocoles et ports spécifiques que vous souhaitez ouvrir sur votre instance.
Cliquez sur Enregistrer.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesOpen PostgreSQL port
Nom de la catégorie dans l'API : 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 :
Accédez à la page Pare-feu de la console Google Cloud.
Dans la liste des règles de pare-feu, cliquez sur le nom de la règle de pare-feu dans le résultat.
Cliquez sur edit Modifier.
Sous Plages d'adresses IP sources, supprimez
0.0.0.0/0
.Ajoutez des adresses IP ou des plages d'adresses IP spécifiques pour permettre les connexions à l'instance à partir de ces adresses
Ajoutez les protocoles et ports spécifiques que vous souhaitez ouvrir sur votre instance.
Cliquez sur Enregistrer.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesOpen RDP port
Nom de la catégorie dans l'API : 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 :
Accédez à la page Pare-feu de la console Google Cloud.
Dans la liste des règles de pare-feu, cliquez sur le nom de la règle de pare-feu dans le résultat.
Cliquez sur edit Modifier.
Sous Plages d'adresses IP sources, supprimez
0.0.0.0/0
.Ajoutez des adresses IP ou des plages d'adresses IP spécifiques pour permettre les connexions à l'instance à partir de ces adresses
Ajoutez les protocoles et ports spécifiques que vous souhaitez ouvrir sur votre instance.
Cliquez sur Enregistrer.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesOpen Redis port
Nom de la catégorie dans l'API : 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 :
Accédez à la page Pare-feu de la console Google Cloud.
Dans la liste des règles de pare-feu, cliquez sur le nom de la règle de pare-feu dans le résultat.
Cliquez sur edit Modifier.
Sous Plages d'adresses IP sources, supprimez
0.0.0.0/0
.Ajoutez des adresses IP ou des plages d'adresses IP spécifiques pour permettre les connexions à l'instance à partir de ces adresses
Ajoutez les protocoles et ports spécifiques que vous souhaitez ouvrir sur votre instance.
Cliquez sur Enregistrer.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesOpen SMTP port
Nom de la catégorie dans l'API : 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 :
Accédez à la page Pare-feu de la console Google Cloud.
Dans la liste des règles de pare-feu, cliquez sur le nom de la règle de pare-feu dans le résultat.
Cliquez sur edit Modifier.
Sous Plages d'adresses IP sources, supprimez
0.0.0.0/0
.Ajoutez des adresses IP ou des plages d'adresses IP spécifiques pour permettre les connexions à l'instance à partir de ces adresses
Ajoutez les protocoles et ports spécifiques que vous souhaitez ouvrir sur votre instance.
Cliquez sur Enregistrer.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesOpen SSH port
Nom de la catégorie dans l'API : 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 :
Accédez à la page Pare-feu de la console Google Cloud.
Dans la liste des règles de pare-feu, cliquez sur le nom de la règle de pare-feu dans le résultat.
Cliquez sur edit Modifier.
Sous Plages d'adresses IP sources, supprimez
0.0.0.0/0
.Ajoutez des adresses IP ou des plages d'adresses IP spécifiques pour permettre les connexions à l'instance à partir de ces adresses
Ajoutez les protocoles et ports spécifiques que vous souhaitez ouvrir sur votre instance.
Cliquez sur Enregistrer.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesOpen Telnet port
Nom de la catégorie dans l'API : 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 :
Accédez à la page Pare-feu de la console Google Cloud.
Dans la liste des règles de pare-feu, cliquez sur le nom de la règle de pare-feu dans le résultat.
Cliquez sur edit Modifier.
Sous Plages d'adresses IP sources, supprimez
0.0.0.0/0
.Ajoutez des adresses IP ou des plages d'adresses IP spécifiques pour permettre les connexions à l'instance à partir de ces adresses
Ajoutez les protocoles et ports spécifiques que vous souhaitez ouvrir sur votre instance.
Cliquez sur Enregistrer.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesOrg policy Confidential VM policy
Nom de la catégorie dans l'API : 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 les activations du niveau Premium de Security Command Center au niveau du projet, ce résultat n'est disponible que si le niveau Standard est activé dans l'organisation parente.
Pour corriger ce résultat, procédez comme suit :
Accédez à la page Instances de VM de la console Google Cloud.
Dans la liste des instances, cliquez sur le nom de l'instance dans le résultat.
Si la VM ne nécessite pas le service Confidential VM, déplacez-la dans un nouveau dossier ou un nouveau projet.
Si la VM requiert Confidential VM, cliquez sur delete Supprimer.
Pour créer une instance avec Confidential VM activée, consultez la page Démarrage rapide : créer une instance de Confidential VM.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesOrg policy location restriction
Nom de la catégorie dans l'API : 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 les activations du niveau Premium de Security Command Center au niveau du projet, ce résultat n'est disponible que si le niveau Standard est activé dans l'organisation parente.
Pour corriger ce résultat, procédez comme suit :
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 :
- 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.
- 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
Lorsque vous corrigez ce résultat, tenez compte des éléments suivants.
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.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesOS login disabled
Nom de la catégorie dans l'API : OS_LOGIN_DISABLED
OS Login est désactivé sur cette instance Compute Engine.
OS Login active la gestion centralisée des clés SSH avec IAM et désactive les configurations de clés SSH basées sur les métadonnées dans toutes les instances d'un projet. Découvrez comment Configurer OS Login.
Pour les activations du niveau Premium de Security Command Center au niveau du projet, ce résultat n'est disponible que si le niveau Standard est activé dans l'organisation parente.
Pour corriger ce résultat, procédez comme suit :
Accédez à la page Métadonnées de la console Google Cloud.
Cliquez sur Modifier, puis sur Ajouter un élément.
Ajoutez un élément comportant la clé enable-oslogin et la valeur TRUE.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesOver privileged account
Nom de la catégorie dans l'API : 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.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesOver privileged scopes
Nom de la catégorie dans l'API : 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.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesOver privileged service account user
Nom de la catégorie dans l'API : 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 :
Accédez à la page "IAM" de Google Cloud Console.
Si nécessaire, sélectionnez le projet, le dossier ou l'organisation dans le résultat.
Pour chaque compte principal auquel on a attribué
roles/iam.serviceAccountUser
ouroles/iam.serviceAccountTokenCreator
, procédez comme suit :- Cliquez sur edit Modifier.
- Dans le panneau Modifier les autorisations, à côté des rôles, cliquez sur delete Supprimer.
- Cliquez sur Enregistrer.
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.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesOwner not monitored
Nom de la catégorie dans l'API : 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 ses coûts, consultez la page Optimisation des coûts pour l'observabilité Google Cloud.
Pour les activations du niveau Premium de Security Command Center au niveau du projet, ce résultat n'est disponible que si le niveau Standard est activé dans l'organisation parente.
Pour corriger ce résultat, procédez comme suit :
Créer une métrique
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.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")
Cliquez sur Créer la métrique. Un message de confirmation s'affiche.
Créer une règle d'alerte
-
Dans le panneau de navigation de la console Google Cloud, sélectionnez Logging, puis Métriques basées sur les journaux :
- 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 lorsque des incidents sont ouverts ou fermés, cochez Notifier en cas de fermeture d'incident. 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.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesPod security policy disabled
Nom de la catégorie dans l'API : 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 les activations du niveau Premium de Security Command Center au niveau du projet, ce résultat n'est disponible que si le niveau Standard est activé dans l'organisation parente.
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
.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesPrimitive roles used
Nom de la catégorie dans l'API : 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 :
Accédez à la page IAM de la console Google Cloud.
Pour chaque utilisateur attribué à un rôle primitif, envisagez plutôt d'utiliser des rôles plus précis.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesPrivate cluster disabled
Nom de la catégorie dans l'API : 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é :
Accédez à la page des Clusters Kubernetes GKE dans la console Google Cloud.
Cliquez sur Create Cluster (Créer le cluster).
Dans le menu de navigation, sous Cluster, sélectionnez Networking (Mise en réseau).
Sélectionnez la case d'option Private cluster (Cluster privé).
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).
Cliquez sur Créer.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesPrivate Google access disabled
Nom de la catégorie dans l'API : 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 :
Accédez à la page Réseaux VPC dans Google Cloud Console.
Dans la liste des réseaux, cliquez sur le nom du réseau souhaité.
Sur la page Détails du réseau VPC, cliquez sur l'onglet Sous-réseaux.
Dans la liste des sous-réseaux, cliquez sur le nom du sous-réseau associé au cluster Kubernetes dans le résultat.
Sur la page des détails du sous-réseau, cliquez sur Modifier edit.
Dans le champ Accès privé à Google, sélectionnez Activé.
Cliquez sur Enregistrer.
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.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesPublic bucket ACL
Nom de la catégorie dans l'API : 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 :
Accédez à la page Navigateur de stockage de la console Google Cloud.
Sélectionnez le bucket répertorié dans le résultat de Security Health Analytics.
Sur la page Informations sur le bucket, cliquez sur l'onglet Autorisations.
À côté de Afficher par, cliquez sur Rôles.
Dans le champ Filtre, recherchez allUsers et allAuthenticatedUsers.
Cliquez sur Supprimer delete pour supprimer toutes les autorisations IAM accordées à allUsers et allAuthenticatedUsers.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesPublic Compute image
Nom de la catégorie dans l'API : 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 :
Accédez à la page Images Compute Engine dans la console Google Cloud.
Cochez la case à côté de l'image public-image (Image publique), puis cliquez sur Afficher le panneau d'informations.
Dans la zone Filtre, recherchez les membres allUsers et allAuthenticatedUsers.
Développez le rôle au sein duquel vous souhaitez supprimer des utilisateurs.
Cliquez sur delete Supprimer pour retirer un membre de ce rôle.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesPublic dataset
Nom de la catégorie dans l'API : 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 :
Accédez à la page Explorateur de la console Google Cloud.
Dans la liste des ensembles de données, cliquez sur le nom de celui identifié dans le résultat. Le panneau Informations sur l'ensemble de données s'affiche.
En haut du panneau Informations sur l'ensemble de données, cliquez sur PARTAGE.
Dans le menu déroulant, cliquez sur Autorisations.
Dans le panneau Autorisations d'ensemble de données, saisissez allUsers et allAuthenticatedUsers, puis supprimez l'accès pour ces comptes principaux.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesPublic IP address
Nom de la catégorie dans l'API : 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 :
Accédez à la page Instances de VM de la console Google Cloud.
Dans la liste des instances, cochez la case située à côté du nom de l'instance dans le résultat.
Cliquez sur edit Modifier.
Pour chaque interface sous Interfaces réseau, cliquez sur edit Modifier et définissez Adresse IP externe sur Aucun.
Cliquez sur OK, puis sur Enregistrer.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesPublic log bucket
Nom de la catégorie dans l'API : PUBLIC_LOG_BUCKET
Ce résultat n'est pas disponible pour les activations au niveau du projet.
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 :
Accédez à la page du navigateur Cloud Storage dans la console Google Cloud.
Dans la liste des buckets, cliquez sur le nom du bucket indiqué dans le résultat.
Cliquez sur l'onglet Autorisations.
Supprimez allUsers et allAuthenticatedUsers de la liste des comptes principaux.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesPublic SQL instance
Nom de la catégorie dans l'API : 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 :
Accédez à la page Instances Cloud SQL dans la console Google Cloud.
Sélectionnez l'instance répertoriée dans le résultat de Security Health Analytics.
Cliquez sur edit Modifier.
Dans le panneau de navigation, cliquez sur Connexions.
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.Cliquez sur OK, puis sur Enregistrer.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesPubsub CMEK disabled
Nom de la catégorie dans l'API : 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 :
Accédez à la page Sujets de Pub/Sub dans la console Google Cloud.
Si nécessaire, sélectionnez le projet contenant le sujet Pub/Sub.
Cochez la case située à côté du sujet répertorié dans le résultat, puis cliquez sur delete Supprimer.
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.
Publiez les résultats ou d'autres données dans le sujet PubPub/Sub compatible avec CMEK.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesRoute not monitored
Nom de la catégorie dans l'API : 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 ses coûts, consultez la page Optimisation des coûts pour l'observabilité Google Cloud.
Pour les activations du niveau Premium de Security Command Center au niveau du projet, ce résultat n'est disponible que si le niveau Standard est activé dans l'organisation parente.
Pour corriger ce résultat, procédez comme suit :
Créer une métrique
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:
resource.type="gce_route" AND (protoPayload.methodName:"compute.routes.delete" OR protoPayload.methodName:"compute.routes.insert")
Cliquez sur Créer la métrique. Un message de confirmation s'affiche.
Créer une règle d'alerte
-
Dans le panneau de navigation de la console Google Cloud, sélectionnez Logging, puis Métriques basées sur les journaux :
- 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 lorsque des incidents sont ouverts ou fermés, cochez Notifier en cas de fermeture d'incident. 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.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesRedis role used on org
Nom de la catégorie dans l'API : REDIS_ROLE_USED_ON_ORG
Ce résultat n'est pas disponible pour les activations au niveau du projet.
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 :
Accédez à la page IAM de la console Google Cloud.
Supprimez les rôles IAM Redis indiqués dans le résultat et ajoutez-les à chaque projet.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesRelease channel disabled
Nom de la catégorie dans l'API : 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 :
Accédez à la page des Clusters Kubernetes GKE dans la console Google Cloud.
Dans la section Paramètres de base du cluster, cliquez sur l'icône de modification (edit) 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.
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.
Cliquez sur Save Changes (Enregistrer les modifications).
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesRSASHA1 for signing
Nom de la catégorie dans l'API : 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.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesService account key not rotated
Nom de la catégorie dans l'API : SERVICE_ACCOUNT_KEY_NOT_ROTATED
Ce résultat n'est pas disponible pour les activations au niveau du projet.
La clé d'un compte de service géré par l'utilisateur n'a pas subi de rotation depuis plus de 90 jours.
En général, les clés de compte de service gérées par l'utilisateur doivent être alternées au moins tous les 90 jours pour garantir que les données ne sont pas accessibles avec une ancienne clé qui aurait été perdue, compromise ou volée. Pour en savoir plus, consultez la page Effectuer une rotation des clés de compte de service pour réduire le risque de sécurité causé par les clés piratées.
Si vous avez généré vous-même la paire de clés publique/privée, stocké la clé privée dans un module de sécurité matérielle (HSM) et importé la clé publique dans Google, vous n'aurez peut-être pas besoin pour effectuer une rotation de la clé tous les 90 jours. Au lieu de cela, vous pouvez alterner la clé si vous pensez qu'elle a peut-être été compromise.
Pour corriger ce résultat, procédez comme suit :
Accédez à la page Comptes de service dans la console Google Cloud.
Si nécessaire, sélectionnez le projet indiqué dans le résultat.
Dans la liste des comptes de service, recherchez celui qui figure dans le résultat, puis cliquez sur delete Supprimer. Avant de continuer, réfléchissez à l'impact qu'une suppression de compte de service pourrait avoir sur vos ressources de production.
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.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesService account role separation
Nom de la catégorie dans l'API : SERVICE_ACCOUNT_ROLE_SEPARATION
Ce résultat n'est pas disponible pour les activations au niveau du projet.
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 :
Accédez à la page IAM de la console Google Cloud.
Pour chaque compte principal répertorié dans le résultat, procédez comme suit :
- 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.
- Cliquez sur Modifier edit à côté d'un compte principal.
- Pour supprimer des autorisations, cliquez sur Supprimer delete à 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.
Cliquez sur Enregistrer.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesShielded VM disabled
Nom de la catégorie dans l'API : 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 :
Accédez à la page Instances de VM de la console Google Cloud.
Sélectionnez l'instance associée au résultat de Security Health Analytics.
Sur la page Détails de l'instance page qui s'affiche, cliquez sur
Arrêter.Une fois l'instance arrêtée, cliquez sur edit Modifier.
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.
Si vous n'utilisez aucun pilote personnalisé ou non signé, vous pouvez également activer le démarrage sécurisé.
Cliquez sur Enregistrer. La nouvelle configuration s'affiche sur la page Détails de l'instance.
Cliquez sur
Démarrer pour démarrer l'instance.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesSQL CMEK disabled
Nom de la catégorie dans l'API : 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 :
Accédez à la page Instances Cloud SQL de la console Google Cloud.
Sélectionnez l'instance répertoriée dans le résultat de Security Health Analytics.
Cliquez sur delete Supprimer.
Pour créer une instance sur laquelle CMEK est activé, suivez les instructions permettant de configurer CMEK pour votre produit :
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesSQL contained database authentication
Nom de la catégorie dans l'API : 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 :
Accédez à la page Instances Cloud SQL de la console Google Cloud.
Sélectionnez l'instance répertoriée dans le résultat de Security Health Analytics.
Cliquez sur edit Modifier.
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é.
Cliquez sur Enregistrer. La nouvelle configuration apparaît sur la page Présentation de l'instance.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesSQL cross DB ownership chaining
Nom de la catégorie dans l'API : 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 :
Accédez à la page Instances Cloud SQL de la console Google Cloud.
Sélectionnez l'instance répertoriée dans le résultat de Security Health Analytics.
Cliquez sur edit Modifier.
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é.
Cliquez sur Enregistrer. La nouvelle configuration apparaît sur la page Présentation de l'instance.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesSQL external scripts enabled
Nom de la catégorie dans l'API : SQL_EXTERNAL_SCRIPTS_ENABLED
L'indicateur de base de données Scripts externes activés n'est pas défini sur Off pour une instance de base de données Cloud SQL pour SQL Server.
Lorsqu'il est activé, ce paramètre permet d'exécuter des scripts avec certaines extensions de langage distant. Étant donné que cette fonctionnalité peut avoir un impact négatif sur la sécurité du système, nous vous recommandons de la 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 :
Accédez à la page Instances Cloud SQL de la console Google Cloud.
Sélectionnez l'instance répertoriée dans le résultat de Security Health Analytics.
Cliquez sur edit Modifier.
Dans la section Indicateurs de base de données, définissez l'indicateur de base de données scripts externes activés avec la valeur Off.
Cliquez sur Enregistrer. La nouvelle configuration apparaît sur la page Présentation de l'instance.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesSQL instance not monitored
Nom de la catégorie dans l'API : SQL_INSTANCE_NOT_MONITORED
Ce résultat n'est pas disponible pour les activations au niveau du projet.
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 ses coûts, consultez la page Optimisation des coûts pour l'observabilité Google Cloud.
Pour les activations du niveau Premium de Security Command Center au niveau du projet, ce résultat n'est disponible que si le niveau Standard est activé dans l'organisation parente.
Pour corriger ce résultat, procédez comme suit :
Créer une métrique
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="cloudsql.instances.update" OR protoPayload.methodName="cloudsql.instances.create" OR protoPayload.methodName="cloudsql.instances.delete"
Cliquez sur Créer la métrique. Un message de confirmation s'affiche.
Créer une règle d'alerte
-
Dans le panneau de navigation de la console Google Cloud, sélectionnez Logging, puis Métriques basées sur les journaux :
- 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 lorsque des incidents sont ouverts ou fermés, cochez Notifier en cas de fermeture d'incident. 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.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesSQL local infile
Nom de la catégorie dans l'API : 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 :
Accédez à la page Instances Cloud SQL de la console Google Cloud.
Sélectionnez l'instance répertoriée dans le résultat de Security Health Analytics.
Cliquez sur edit Modifier.
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é.
Cliquez sur Enregistrer. La nouvelle configuration apparaît sur la page Présentation de l'instance.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesSQL log checkpoints disabled
Nom de la catégorie dans l'API : SQL_LOG_CHECKPOINTS_DISABLED
L'option log_checkpoints de la base de données n'est pas définie sur log_checkpoints 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 :
Accédez à la page Instances Cloud SQL de la console Google Cloud.
Sélectionnez l'instance répertoriée dans le résultat de Security Health Analytics.
Cliquez sur edit Modifier.
Dans la section Options de base de données, définissez l'option de base de données log_checkpoints avec la valeur Activé.
Cliquez sur Enregistrer. La nouvelle configuration apparaît sur la page Présentation de l'instance.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesSQL log connections disabled
Nom de la catégorie dans l'API : SQL_LOG_CONNECTIONS_DISABLED
L'option log_connections de la base de données n'est pas définie sur log_connections 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 :
Accédez à la page Instances Cloud SQL de la console Google Cloud.
Sélectionnez l'instance répertoriée dans le résultat de Security Health Analytics.
Cliquez sur edit Modifier.
Dans la section Options de base de données, définissez l'option de base de données log_connections avec la valeur Activé.
Cliquez sur Enregistrer. La nouvelle configuration apparaît sur la page Présentation de l'instance.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesSQL log disconnections disabled
Nom de la catégorie dans l'API : 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 :
Accédez à la page Instances Cloud SQL de la console Google Cloud.
Sélectionnez l'instance répertoriée dans le résultat de Security Health Analytics.
Cliquez sur edit Modifier.
Dans la section Options de base de données, définissez l'option de base de données log_disconnections avec la valeur Activé.
Cliquez sur Enregistrer. La nouvelle configuration apparaît sur la page Présentation de l'instance.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesSQL log duration disabled
Nom de la catégorie dans l'API : SQL_LOG_DURATION_DISABLED
L'option log_duration de la base de données Cloud SQL pour PostgreSQL n'est pas définie sur Activé.
Lorsque log_duration est activé, ce paramètre entraîne la journalisation de l'heure et de la durée d'exécution de chaque instruction terminée à consigner. Surveiller le temps que prend l'exécution des requêtes peut s'avérer crucial pour identifier les requêtes lentes et résoudre les problèmes de base de donné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 :
Accédez à la page Instances Cloud SQL de la console Google Cloud.
Sélectionnez l'instance répertoriée dans le résultat de Security Health Analytics.
Cliquez sur edit Modifier.
Dans la section Options de base de données, définissez l'option de base de données log_duration sur Activée.
Cliquez sur Enregistrer. La nouvelle configuration apparaît sur la page Présentation de l'instance.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesSQL log error verbosity
Nom de la catégorie dans l'API : SQL_LOG_ERROR_VERBOSITY
L'option de base de données log_error_verbosity d'une instance de base de données Cloud SQL pour PostgreSQL n'est pas définie sur default ou verbose.
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 cet indicateur sur default (par défaut) ou sur verbose.
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 Instances Cloud SQL de la console Google Cloud.
Sélectionnez l'instance répertoriée dans le résultat de Security Health Analytics.
Cliquez sur edit Modifier.
Dans la section Options de base de données, définissez l'option de base de données log_error_verbosity sur default ou verbose.
Cliquez sur Enregistrer. La nouvelle configuration apparaît sur la page Présentation de l'instance.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesSQL log lock waits disabled
Nom de la catégorie dans l'API : 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 :
Accédez à la page Instances Cloud SQL de la console Google Cloud.
Sélectionnez l'instance répertoriée dans le résultat de Security Health Analytics.
Cliquez sur edit Modifier.
Dans la section Options de base de données, définissez l'option de base de données log_lock_waits sur Activé.
Cliquez sur Enregistrer. La nouvelle configuration apparaît sur la page Présentation de l'instance.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesSQL log min duration statement enabled
Nom de la catégorie dans l'API : 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 :
Accédez à la page Instances Cloud SQL de la console Google Cloud.
Sélectionnez l'instance répertoriée dans le résultat de Security Health Analytics.
Cliquez sur edit Modifier.
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.
Cliquez sur Enregistrer. La nouvelle configuration apparaît sur la page Présentation de l'instance.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesSQL log min error statement
Nom de la catégorie dans l'API : SQL_LOG_MIN_ERROR_STATEMENT
L'option log_min_error_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 :
Accédez à la page Instances Cloud SQL de la console Google Cloud.
Sélectionnez l'instance répertoriée dans le résultat de Security Health Analytics.
Cliquez sur edit Modifier.
Dans la section Options de base de données, définissez l'option de base de données log_min_error_statement sur l'une des valeurs recommandées suivantes, en fonction de la stratégie de journalisation de votre organisation.
debug5
debug4
debug3
debug2
debug1
info
notice
warning
error
Cliquez sur Enregistrer. La nouvelle configuration apparaît sur la page Présentation de l'instance.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesSQL log min error statement severity
Nom de la catégorie dans l'API : SQL_LOG_MIN_ERROR_STATEMENT_SEVERITY
L'option log_min_error_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é égal à celui spécifié ou plus strifct sont consignées avec les messages associés aux instructions en état d'erreur. Plus le niveau de gravité est strict, 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. Un niveau de gravité trop élevé (trop strict) peut empêcher la consignation des messages d'erreur pour des erreurs réelles.
Nous vous recommandons de définir cette option sur error ou plus strict.
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 Instances Cloud SQL de la console Google Cloud.
Sélectionnez l'instance répertoriée dans le résultat de Security Health Analytics.
Cliquez sur edit Modifier.
Dans la section Options de base de données, définissez l'option de base de données log_min_error_statement sur l'une des valeurs recommandées suivantes, en fonction de la stratégie de journalisation de votre organisation.
error
log
fatal
panic
Cliquez sur Enregistrer. La nouvelle configuration apparaît sur la page Présentation de l'instance.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesSQL log min messages
Nom de la catégorie dans l'API : SQL_LOG_MIN_MESSAGES
Dans une instance de base de données Cloud SQL pour PostgreSQL, l'option de base de données log_min_messages n'est pas définie au minimum sur warning (mise en garde).
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 complique 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 Instances Cloud SQL de la console Google Cloud.
Sélectionnez l'instance répertoriée dans le résultat de Security Health Analytics.
Cliquez sur edit Modifier.
Dans la section Options de base de données, définissez l'option de base de données log_min_messages sur l'une des valeurs recommandées suivantes, en fonction de la règle de journalisation de votre organisation.
debug5
debug4
debug3
debug2
debug1
info
notice
warning
Cliquez sur Enregistrer. La nouvelle configuration apparaît sur la page Présentation de l'instance.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesSQL log executor stats enabled
Nom de la catégorie dans l'API : SQL_LOG_EXECUTOR_STATS_ENABLED
L'option de base de données log_executor_stats n'est pas définie sur Désactivé pour une instance de base de données Cloud SQL pour PostgreSQL.
Lorsque l'option log_executor_stats est activée, les statistiques de performances de l'exécuteur sont incluses dans les journaux PostgreSQL pour chaque requête. Ce réglage peut s'avérer utile pour le dépannage, mais peut aussi augmenter considérablement la quantité de journaux et altérer les 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 :
Accédez à la page Instances Cloud SQL dans la console Google Cloud.
Sélectionnez l'instance répertoriée dans le résultat de Security Health Analytics.
Cliquez sur edit Modifier.
Dans la section Options de base de données, définissez l'option de base de données log_executor_stats sur Désactivé.
Cliquez sur Enregistrer. La nouvelle configuration apparaît sur la page Présentation de l'instance.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesSQL log hostname enabled
Nom de la catégorie dans l'API : `SQL_LOG_HOSTNAME_ENABLED
L'indicateur de base de données log_hostname n'est pas défini sur 0 pour une instance de base de données Cloud SQL pour PostgreSQL.
Lorsque l'indicateur log_hostname est activé, le nom de l'hôte connecté est enregistré. Par défaut, les messages de journal de connexion n'affichent que l'adresse IP. Ce paramètre peut s'avérer utile pour le dépannage. Toutefois, cela peut avoir une incidence sur les performances du serveur. En effet, pour chaque instruction consignée, une résolution DNS est requise pour convertir une adresse IP en nom d'hôte.
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 Instances Cloud SQL dans la console Google Cloud.
Sélectionnez l'instance répertoriée dans le résultat de Security Health Analytics.
Cliquez sur edit Modifier.
Dans la section Options de base de données, définissez l'option de base de données log_hostname sur Off.
Cliquez sur Enregistrer. La nouvelle configuration apparaît sur la page Présentation de l'instance.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesSQL log parser stats enabled
Nom de la catégorie dans l'API : SQL_LOG_PARSER_STATS_ENABLED
L'indicateur de base de données log_parser_stats n'est pas défini sur Off pour une instance de base de données Cloud SQL pour PostgreSQL.
Lorsque l'option log_parser_stats est activée, les statistiques de performances de l'analyseur sont incluses dans les journaux PostgreSQL pour chaque requête. Ce réglage peut s'avérer utile pour le dépannage, mais peut aussi augmenter considérablement la quantité de journaux et altérer les 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 :
Accédez à la page Instances Cloud SQL dans la console Google Cloud.
Sélectionnez l'instance répertoriée dans le résultat de Security Health Analytics.
Cliquez sur edit Modifier.
Dans la section Options de base de données, définissez l'option de base de données log_parser_stats sur Off (Désactivée).
Cliquez sur Enregistrer. La nouvelle configuration apparaît sur la page Présentation de l'instance.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesSQL log planner stats enabled
Nom de la catégorie dans l'API : SQL_LOG_PLANNER_STATS_ENABLED
L'indicateur de base de données log_planner_stats n'est pas défini sur Off pour une instance de base de données Cloud SQL pour PostgreSQL.
Lorsque l'option log_planner_stats est activée, une méthode de profilage brut permettant de consigner les statistiques de performances du planificateur PostgreSQL est utilisée. Ce réglage peut s'avérer utile pour le dépannage, mais peut aussi augmenter considérablement la quantité de journaux et altérer les 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 :
Accédez à la page Instances Cloud SQL dans la console Google Cloud.
Sélectionnez l'instance répertoriée dans le résultat de Security Health Analytics.
Cliquez sur edit Modifier.
Dans la section Options de base de données, définissez l'option de base de données log_planner_stats sur Off.
Cliquez sur Enregistrer. La nouvelle configuration apparaît sur la page Présentation de l'instance.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesSQL log statement
Nom de la catégorie dans l'API : SQL_LOG_STATEMENT
L'option de base de données log_statement n'est pas définie sur ddl
dans une instance de base de données Cloud SQL pour PostgreSQL.
La valeur de cette option contrôle quelles sont les instructions SQL qui sont consignées dans les journaux. La journalisation permet de résoudre les problèmes opérationnels et d'effectuer des analyses forensiques. Si cette option n'est pas définie sur la bonne valeur, des informations pertinentes peuvent être ignorées ou perdues dans un trop grand nombre de messages. Une valeur de ddl
(toutes les instructions de définition de données) est recommandée, sauf indication contraire dans la stratégie de journalisation de votre organisation.
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 Instances Cloud SQL dans la console Google Cloud.
Sélectionnez l'instance répertoriée dans le résultat de Security Health Analytics.
Cliquez sur edit Modifier.
Dans la section Options de base de données, définissez l'option de base de données log_statement sur
ddl
.Cliquez sur Enregistrer. La nouvelle configuration apparaît sur la page Présentation de l'instance.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesSQL log statement stats enabled
Nom de la catégorie dans l'API : SQL_LOG_STATEMENT_STATS_ENABLED
L'indicateur de base de données log_statement_stats n'est pas défini sur Off pour une instance de base de données Cloud SQL pour PostgreSQL.
Lorsque l'option log_statement_stats est activé, des statistiques de performance de bout en bout sont incluses dans les journaux PostgreSQL pour chaque requête. Ce réglage peut s'avérer utile pour le dépannage, mais peut aussi augmenter considérablement la quantité de journaux et altérer les 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 :
Accédez à la page Instances Cloud SQL dans la console Google Cloud.
Sélectionnez l'instance répertoriée dans le résultat de Security Health Analytics.
Cliquez sur edit Modifier.
Dans la section Indicateurs de base de données, définissez l'option de base de données log_statement_stats sur Off.
Cliquez sur Enregistrer. La nouvelle configuration apparaît sur la page Présentation de l'instance.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesSQL log temp files
Nom de la catégorie dans l'API : 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 :
Accédez à la page Instances Cloud SQL dans la console Google Cloud.
Sélectionnez l'instance répertoriée dans le résultat de Security Health Analytics.
Cliquez sur edit Modifier.
Dans la section Options de base de données, définissez l'option de base de données log_temp_files sur 0.
Cliquez sur Enregistrer. La nouvelle configuration apparaît sur la page Présentation de l'instance.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesSQL no root password
Nom de la catégorie dans l'API : 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 :
Accédez à la page Instances Cloud SQL de la console Google Cloud.
Sélectionnez l'instance répertoriée dans le résultat de Security Health Analytics.
Sur la page Détails de l'instance qui s'affiche, sélectionnez l'onglet Utilisateurs.
À côté de l'utilisateur
root
, cliquez sur Plus , puis sélectionnez Modifier le mot de passe.Saisissez un nouveau mot de passe sécurisé, puis cliquez sur OK.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesSQL public IP
Nom de la catégorie dans l'API : 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 :
Accédez à la page Instances Cloud SQL dans la console Google Cloud.
Sélectionnez l'instance répertoriée dans le résultat de Security Health Analytics.
Dans le menu de gauche, cliquez sur Connexions.
Cliquez sur l'onglet Mise en réseau et décochez la case Adresse IP publique.
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.
Cliquez sur Enregistrer.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesSQL remote access enabled
Nom de la catégorie dans l'API : SQL_REMOTE_ACCESS_ENABLED
L'indicateur de base de données remote access n'est pas défini sur Off pour une instance de base de données Cloud SQL pour SQL Server.
Lorsqu'il est activé, ce paramètre permet d'exécuter des procédures stockées localement à partir de serveurs distants ou des procédures stockées à distance à partir d'un serveur local. Cette fonctionnalité peut être utilisée de manière abusive pour lancer une attaque par déni de service (DoS) sur les serveurs distants en redirigeant le traitement des requêtes vers une cible. Pour éviter les abus, nous vous recommandons de désactiver ce paramètre.
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 Instances Cloud SQL de la console Google Cloud.
Sélectionnez l'instance répertoriée dans le résultat de Security Health Analytics.
Cliquez sur edit Modifier.
Dans la section Options, définissez remote access sur Off.
Cliquez sur Enregistrer. La nouvelle configuration apparaît sur la page Présentation de l'instance.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesSQL skip show database disabled
Nom de la catégorie dans l'API : SQL_SKIP_SHOW_DATABASE_DISABLED
L'option skip_show_database de la base de données Cloud SQL pour MySQL n'est pas définie sur Activée.
Lorsqu'elle est activée, cette option empêche les utilisateurs d'employer l'instruction SHOW DATABASES s'ils ne disposent pas du droit SHOW DATABASES. Avec ce paramètre, les utilisateurs sans autorisation explicite ne peuvent pas voir les bases de données appartenant à d'autres utilisateurs. Nous vous recommandons d'activer cette option.
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 Instances Cloud SQL de la console Google Cloud.
Sélectionnez l'instance répertoriée dans le résultat de Security Health Analytics.
Cliquez sur edit Modifier.
Dans la section Options, définissez skip_show_database sur On.
Cliquez sur Enregistrer. La nouvelle configuration apparaît sur la page Présentation de l'instance.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesSQL trace flag 3625
Nom de la catégorie dans l'API : SQL_TRACE_FLAG_3625
L'indicateur de base de données 3625 (trace flag) (Activé) est défini sur On pour une instance de base de données Cloud SQL pour SQL Server.
Cette option limite la quantité d'informations renvoyées aux utilisateurs qui ne sont pas membres du rôle serveur fixe sysadmin, en masquant les paramètres de certains messages d'erreur à l'aide d'astérisques (******
). Pour éviter la divulgation d'informations sensibles, nous vous recommandons d'activer cette option.
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 Instances Cloud SQL de la console Google Cloud.
Sélectionnez l'instance répertoriée dans le résultat de Security Health Analytics.
Cliquez sur edit Modifier.
Dans la section Indicateurs de base de données, définissez 3625 sur On.
Cliquez sur Enregistrer. La nouvelle configuration apparaît sur la page Présentation de l'instance.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesSQL user connections configured
Nom de la catégorie dans l'API : SQL_USER_CONNECTIONS_CONFIGURED
L'option de base de données user connections est configurée sur une instance de base de données Cloud SQL pour SQL Server.
L'option Connexions utilisateur spécifie le nombre maximal de connexions utilisateur simultanées autorisé sur une instance de SQL Server. Comme il s'agit d'une option dynamique (auto-configuration), SQL Server ajuste automatiquement le nombre maximal de connexions utilisateur jusqu'à atteindre la valeur maximale autorisée. La valeur par défaut est 0, ce qui signifie que jusqu'à 32 767 connexions utilisateur sont autorisées. Pour cette raison, nous vous déconseillons de configurer l'option de base de données user connections.
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 Instances Cloud SQL de la console Google Cloud.
Sélectionnez l'instance répertoriée dans le résultat de Security Health Analytics.
Cliquez sur edit Modifier.
Dans la section Indicateurs de base de données, cliquez sur delete Supprimer à côté de user connections.
Cliquez sur Enregistrer. La nouvelle configuration apparaît sur la page Présentation de l'instance.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesSQL user options configured
Nom de la catégorie dans l'API : SQL_USER_OPTIONS_CONFIGURED
L'option de base de données user options est configurée sur une instance de base de données Cloud SQL pour SQL Server.
Ce paramètre remplace les valeurs globales par défaut des options SET pour tous les utilisateurs. Étant donné que les utilisateurs et les applications peuvent supposer que les options SET par défaut de la base de données sont en cours d'utilisation, modifier ces options peut entraîner des résultats inattendus. Pour cette raison, nous vous déconseillons de configurer l'option de base de données user options.
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 Instances Cloud SQL de la console Google Cloud.
Sélectionnez l'instance répertoriée dans le résultat de Security Health Analytics.
Cliquez sur edit Modifier.
Dans la section Indicateurs de base de données, cliquez sur delete Supprimer à côté de user options.
Cliquez sur Enregistrer. La nouvelle configuration apparaît sur la page Présentation de l'instance.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesSQL weak root password
Nom de la catégorie dans l'API : 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 :
Accédez à la page Instances Cloud SQL dans la console Google Cloud.
Sélectionnez l'instance répertoriée dans le résultat de Security Health Analytics.
Sur la page Détails de l'instance qui s'affiche, sélectionnez l'onglet Utilisateurs.
À côté de l'utilisateur
root
, cliquez sur Plus , puis sélectionnez Modifier le mot de passe.Saisissez un nouveau mot de passe sécurisé, puis cliquez sur OK.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesSSL not enforced
Nom de la catégorie dans l'API : 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 :
Accédez à la page Instances Cloud SQL dans la console Google Cloud.
Sélectionnez l'instance répertoriée dans le résultat de Security Health Analytics.
Dans l'onglet Connexions, cliquez sur Autoriser uniquement les connexions SSL ou Exiger des certificats client de confiance. Pour en savoir plus, consultez la section Appliquer le chiffrement SSL/TLS.
Si vous avez choisi Exiger des certificats client de confiance, créez un certificat client. Pour en savoir plus, consultez la section Créer un certificat client.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesToo many KMS users
Nom de la catégorie dans l'API : 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 les activations du niveau Premium de Security Command Center au niveau du projet, ce résultat n'est disponible que si le niveau Standard est activé dans l'organisation parente.
Pour corriger ce résultat, procédez comme suit :
Accédez à la page Clés Cloud KMS de la console Google Cloud.
Cliquez sur le nom du trousseau de clés indiqué dans le résultat.
Cliquez sur le nom de la clé indiquée dans le résultat.
Cochez la case à côté de la version principale, puis cliquez sur Afficher le panneau d'informations.
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 delete à côté de chaque compte principal.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesUser managed service account key
Nom de la catégorie dans l'API : USER_MANAGED_SERVICE_ACCOUNT_KEY
Un utilisateur gère une clé de compte de service. Les clés de compte de service constituent un risque pour la sécurité si elles ne sont pas gérées correctement. Dans la mesure du possible, vous devez choisir une alternative plus sécurisée aux clés de compte de service. Si vous devez vous authentifier avec une clé de compte de service, vous êtes responsable de la sécurité de la clé privée et des autres opérations décrites sur la page Bonnes pratiques pour gérer les clés de compte de service. Si vous ne parvenez pas à créer une clé de compte de service, il se peut que la création de clés de compte de service soit désactivée pour votre organisation. Pour en savoir plus, consultez la page Gérer les ressources d'organisation sécurisées par défaut.
Pour corriger ce résultat, procédez comme suit :
Accédez à la page Comptes de service dans la console Google Cloud.
Si nécessaire, sélectionnez le projet indiqué dans le résultat.
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.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesWeak SSL policy
Nom de la catégorie dans l'API : WEAK_SSL_POLICY
Une instance Compute Engine a une règle SSL faible ou utilise la règle SSL par défaut de Google Cloud avec une version de TLS antérieure à 1.2.
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.
Pour les activations du niveau Premium de Security Command Center au niveau du projet, ce résultat n'est disponible que si le niveau Standard est activé dans l'organisation parente.
Les étapes de résolution pour ce résultat diffèrent selon que ce résultat a été déclenché par l'utilisation d'une règle SSL Google Cloud par défaut ou d'une règle SSL qui autorise une suite de chiffrement faible ou une version TLS minimale inférieure à 1.2. Suivez la procédure ci-dessous qui correspond au déclencheur du résultat.
Correction des règles SSL Google Cloud par défaut
Accédez à la page Proxies cibles de la console Google Cloud.
Recherchez le proxy cible indiqué dans le résultat et notez les règles de transfert dans la colonne Utilisée par.
Pour créer une règle SSL, 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.
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
Appliquez la règle SSL à chaque règle de transfert que vous avez notée précédemment.
Correction autorisée de la suite de chiffrement faible ou de la version TLS de niveau inférieur
Dans la console Google Cloud, accédez à la page Règles SSL .
Recherchez l'équilibreur de charge indiqué dans la colonne Utilisé par.
Cliquez sous le nom de la règle.
Cliquez sur edit Modifier.
Définissez la version TLS minimale sur TLS 1.2 et le profil sur "Moderne" ou "Limité".
Pour utiliser un profil Custom, 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
Cliquez sur Enregistrer.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesWeb UI enabled
Nom de la catégorie dans l'API : 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à la console Google Cloud, 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 :
Accédez à la page des Clusters Kubernetes GKE dans la console Google Cloud.
Cliquez sur le nom du cluster répertorié dans le résultat de Security Health Analytics.
Cliquez sur edit Modifier.
Si la configuration du cluster a récemment été modifiée, il est possible que le bouton "Modifier" ne soit pas disponible. Si vous ne pouvez pas modifier les paramètres du cluster, attendez quelques minutes, puis réessayez.
Cliquez sur Modules complémentaires. La section se développe pour afficher les modules complémentaires disponibles.
Dans la liste déroulante Tableau de bord Kubernetes, sélectionnez Désactivé.
Cliquez sur Enregistrer.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesWorkload Identity disabled
Nom de la catégorie dans l'API : 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.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesCorriger les erreurs de configuration AWS
AWS Cloud Shell Full Access Restricted
Nom de la catégorie dans l'API : ACCESS_AWSCLOUDSHELLFULLACCESS_RESTRICTED
AWS CloudShell est un moyen pratique d'exécuter des commandes CLI sur les services AWS. Une stratégie IAM gérée ("AWSCloudShellFullAccess") offre un accès complet à Cloud Shell et permet d'importer et de télécharger des fichiers entre le système local d'un utilisateur et l'environnement CloudShell. Dans l'environnement CloudShell, un utilisateur dispose d'autorisations sudo et peut accéder à Internet. Vous pouvez ainsi installer un logiciel de transfert de fichiers (par exemple) et déplacer des données de Cloud Shell vers des serveurs Internet externes.
Recommandation : Assurez-vous que l'accès à AWSCloudShellFullAccess est limité
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesAccess Keys Rotated Every 90 Days or Less
Nom de la catégorie dans l'API : ACCESS_KEYS_ROTATED_90_DAYS_LESS
Les clés d'accès se composent d'un ID de clé d'accès et d'une clé d'accès secrète, qui permettent de signer les requêtes programmatiques que vous envoyez à AWS. Les utilisateurs AWS ont besoin de leurs propres clés d'accès pour effectuer des appels programmatiques vers AWS à partir de l'interface de ligne de commande AWS (CLI AWS), d'Tools for Windows PowerShell, des SDK AWS ou d'appels HTTP directs à l'aide des API pour des services AWS individuels. Il est recommandé d'alterner régulièrement toutes les clés d'accès.
Recommandation : Assurez-vous que les clés d'accès sont alternées tous les 90 jours au maximum
Pour corriger ce résultat, procédez comme suit :
Console AWS
- Accédez à la console de gestion (https://console.aws.amazon.com/iam).
- Cliquez sur
Users
. - Cliquez sur
Security Credentials
. - En tant qu'administrateur
- Cliquez sur
Make Inactive
pour les clés qui n'ont pas été alternées depuis90
jours
- Cliquez sur
- En tant qu'utilisateur IAM :
- Cliquez sur
Make Inactive
ouDelete
pour les clés qui n'ont pas été alternées ni utilisées depuis90
jours.
- Cliquez sur
- Cliquez sur
Create Access Key
. - Mettre à jour l'appel programmatique avec de nouveaux identifiants pour la clé d'accès
CLI AWS
- Tant que la première clé d'accès est toujours active, créez-en une deuxième, qui est active par défaut. Exécutez la commande ci-dessous.
aws iam create-access-key
À ce stade, l'utilisateur dispose de deux clés d'accès actives.
- Mettez à jour l'ensemble des applications et outils de sorte qu'ils utilisent la nouvelle clé d'accès.
- Déterminez si la première clé d'accès est toujours utilisée à l'aide de la commande suivante:
aws iam get-access-key-last-used
- Une approche consiste à attendre plusieurs jours, puis à vérifier si l'ancienne clé d'accès est utilisée avant de continuer.
Même si l'étape 3 indique que l'ancienne clé n'est pas utilisée, nous vous recommandons de ne pas supprimer immédiatement la première clé d'accès. Définissez plutôt l'état de la première clé d'accès sur "Inactif" à l'aide de la commande suivante:
aws iam update-access-key
Utilisez uniquement la nouvelle clé d'accès pour vérifier que vos applications fonctionnent. À ce stade, tous les outils et applications qui utilisent encore la clé d'accès d'origine cesseront de fonctionner, car ils n'ont plus accès aux ressources AWS. Si vous trouvez une application ou un outil de ce type, vous pouvez rétablir son état sur "Actif" afin de réactiver la première clé d'accès. Revenez ensuite à l'étape 2 et mettez à jour cette application pour qu'elle utilise la nouvelle clé.
Après avoir attendu un certain temps pour vous assurer que toutes les applications et tous les outils ont été mis à jour, vous pouvez supprimer la première clé d'accès à l'aide de la commande suivante:
aws iam delete-access-key
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesAll Expired Ssl Tls Certificates Stored Aws Iam Removed
Nom de la catégorie dans l'API : ALL_EXPIRED_SSL_TLS_CERTIFICATES_STORED_AWS_IAM_REMOVED
Pour activer les connexions HTTPS à votre site Web ou application dans AWS, vous avez besoin d'un certificat de serveur SSL/TLS. Vous pouvez utiliser ACM ou IAM pour stocker et déployer des certificats de serveur. N'utilisez IAM comme gestionnaire de certificats que lorsque vous devez accepter les connexions HTTPS dans une région non compatible avec ACM. IAM chiffre vos clés privées de manière sécurisée et stocke la version chiffrée dans un espace de stockage de certificats SSL IAM. IAM permet de déployer des certificats de serveur dans toutes les régions. Toutefois, vous devez obtenir votre certificat auprès d'un fournisseur externe pour pouvoir l'utiliser avec AWS. Vous ne pouvez pas importer de certificat ACM dans IAM. De plus, vous ne pouvez pas gérer vos certificats depuis la console IAM.
Recommandation : Assurez-vous que tous les certificats SSL/TLS expirés stockés dans AWS IAM sont supprimés
Pour corriger ce résultat, procédez comme suit :
Console AWS
Il n'est actuellement pas possible de supprimer des certificats expirés via AWS Management Console. Pour supprimer des certificats SSL/TLS stockés dans IAM via l'API AWS, utilisez l'interface de ligne de commande (CLI).
CLI AWS
Pour supprimer un certificat expiré, exécutez la commande suivante en remplaçant CERTIFICATE_NAME
par le nom du certificat à supprimer:
aws iam delete-server-certificate --server-certificate-name <CERTIFICATE_NAME>
Lorsque la commande précédente aboutit, elle ne renvoie aucun résultat.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesAutoscaling Group Elb Healthcheck Required
Nom de la catégorie dans l'API : AUTOSCALING_GROUP_ELB_HEALTHCHECK_REQUIRED
Cela permet de vérifier si vos groupes Auto Scaling associés à un équilibreur de charge utilisent les vérifications d'état d'Elastic Load Balancing.
Cela permet au groupe de déterminer l'état d'une instance en fonction de tests supplémentaires fournis par l'équilibreur de charge. Les vérifications d'état d'Elastic Load Balancing permettent de garantir la disponibilité des applications qui utilisent des groupes d'autoscaling EC2.
Recommandation : Vérifie que tous les groupes d'autoscaling associés à un équilibreur de charge utilisent des vérifications d'état.
Pour corriger ce résultat, procédez comme suit :
Console AWS
Pour activer les vérifications d'état d'Elastic Load Balancing :
- Ouvrez la console Amazon EC2 à l'adresse https://console.aws.amazon.com/ec2/.
- Dans le volet de navigation, sous "Auto Scaling", sélectionnez "Groupes d'autoscaling automatique".
- Cochez la case correspondant à votre groupe.
- Sélectionnez "Modifier".
- Sous "Vérifications d'état", sélectionnez ELB dans "Type de vérification d'état".
- Dans le champ "Délai de grâce pour la vérification de l'état", saisissez 300.
- En bas de la page, sélectionnez "Mettre à jour".
Pour en savoir plus sur l'utilisation d'un équilibreur de charge avec un groupe Auto Scaling, consultez le Guide de l'utilisateur AWS Auto Scaling.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesAuto Minor Version Upgrade Feature Enabled Rds Instances
Nom de la catégorie dans l'API : AUTO_MINOR_VERSION_UPGRADE_FEATURE_ENABLED_RDS_INSTANCES
Assurez-vous que l'option "Mise à niveau automatique de version mineure" est activée sur les instances de base de données RDS afin de recevoir automatiquement les mises à niveau mineures du moteur pendant l'intervalle de maintenance spécifié. Ainsi, les instances RDS peuvent bénéficier des nouvelles fonctionnalités, corrections de bugs et correctifs de sécurité de leurs moteurs de base de données.
Recommandation : Assurez-vous que la fonctionnalité de mise à niveau automatique des versions mineures est activée pour les instances RDS
Pour corriger ce résultat, procédez comme suit :
Console AWS
- Connectez-vous à la console de gestion AWS et accédez au tableau de bord RDS à l'adresse https://console.aws.amazon.com/rds/.
- Dans le panneau de navigation de gauche, cliquez sur
Databases
. - Sélectionnez l'instance RDS à mettre à jour.
- Cliquez sur le bouton
Modify
situé en haut à droite. - Sur la page
Modify DB Instance: <instance identifier>
, dans la sectionMaintenance
, sélectionnezAuto minor version upgrade
, puis cliquez sur la case d'optionYes
. - En bas de la page, cliquez sur
Continue
, cochez la case "Apply Imediately" (Appliquer immédiatement) pour appliquer immédiatement les modifications, ou sélectionnezApply during the next scheduled maintenance window
(pour éviter tout temps d'arrêt). - Examinez les modifications, puis cliquez sur
Modify DB Instance
. L'état de l'instance doit passer de "Disponible" à "En cours de modification", puis à "Disponible". Une fois la fonctionnalité activée, l'étatAuto Minor Version Upgrade
doit passer àYes
.
CLI AWS
- Exécutez la commande
describe-db-instances
pour obtenir la liste de tous les noms d'instances de base de données RDS disponibles dans la région AWS sélectionnée:
aws rds describe-db-instances --region <regionName> --query 'DBInstances[*].DBInstanceIdentifier'
- Le résultat de la commande doit renvoyer les identifiants de chaque instance de base de données.
- Exécutez la commande
modify-db-instance
pour modifier la configuration de l'instance RDS sélectionnée. Cette commande appliquera les changements immédiatement. Supprimez--apply-immediately
pour appliquer les modifications lors du prochain intervalle de maintenance planifié et éviter tout temps d'arrêt:
aws rds modify-db-instance --region <regionName> --db-instance-identifier <dbInstanceIdentifier> --auto-minor-version-upgrade --apply-immediately
- Le résultat de la commande doit révéler les nouvelles métadonnées de configuration pour l'instance RDS et vérifier la valeur du paramètre
AutoMinorVersionUpgrade
. - Exécutez la commande
describe-db-instances
pour vérifier si la fonctionnalité de mise à niveau automatique des versions mineures a bien été activée:
aws rds describe-db-instances --region <regionName> --db-instance-identifier <dbInstanceIdentifier> --query 'DBInstances[*].AutoMinorVersionUpgrade'
- Le résultat de la commande doit renvoyer l'état actuel de la fonctionnalité défini sur
true
, la fonctionnalité estenabled
et les mises à niveau mineures du moteur seront appliquées à l'instance RDS sélectionnée.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesAws Config Enabled All Regions
Nom de la catégorie dans l'API : AWS_CONFIG_ENABLED_ALL_REGIONS
AWS Config est un service Web qui gère la configuration des ressources AWS compatibles dans votre compte et vous fournit des fichiers journaux. Les informations enregistrées incluent l'élément de configuration (ressource AWS), les relations entre les éléments de configuration (ressources AWS) et les modifications de configuration entre les ressources. Nous vous recommandons d'activer AWS Config dans toutes les régions.
Recommandation : Assurez-vous que la configuration AWS est activée dans toutes les régions
Pour corriger ce résultat, procédez comme suit :
Console AWS
- Sélectionnez la région qui vous intéresse en haut à droite de la console.
- Cliquez sur "Services".
- Configuration du clic
- Si un enregistreur de configuration est activé dans cette région, vous devez accéder à la page "Settings" (Paramètres) à partir du menu de navigation de gauche. Si aucun enregistreur de configuration n'est encore activé dans cette région, vous devez sélectionner "Commencer".
- Sélectionnez "Enregistrer toutes les ressources compatibles dans cette région".
- Choisissez d'inclure des ressources globales (ressources IAM)
- Spécifier un bucket S3 dans le même compte ou dans un autre compte AWS géré
- Créer un sujet SNS à partir du même compte AWS ou d'un autre compte AWS géré
CLI AWS
- Assurez-vous de disposer d'un bucket S3, d'un sujet SNS et d'un rôle IAM appropriés conformément aux conditions préalables d'AWS Config Service.
- Exécutez la commande suivante pour créer un enregistreur de configuration:
aws configservice put-configuration-recorder --configuration-recorder name=default,roleARN=arn:aws:iam::012345678912:role/myConfigRole --recording-group allSupported=true,includeGlobalResourceTypes=true
- Créez localement un fichier de configuration du canal de distribution spécifiant les attributs du canal en fonction des prérequis définis précédemment:
{
"name": "default",
"s3BucketName": "my-config-bucket",
"snsTopicARN": "arn:aws:sns:us-east-1:012345678912:my-config-notice",
"configSnapshotDeliveryProperties": {
"deliveryFrequency": "Twelve_Hours"
}
}
- Exécutez la commande suivante pour créer un canal de diffusion en vous reportant au fichier de configuration json créé à l'étape précédente:
aws configservice put-delivery-channel --delivery-channel file://deliveryChannel.json
- Lancez l'enregistreur de configuration en exécutant la commande suivante:
aws configservice start-configuration-recorder --configuration-recorder-name default
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesAws Security Hub Enabled
Nom de la catégorie dans l'API : AWS_SECURITY_HUB_ENABLED
Le Centre de sécurité collecte les données de sécurité de l'ensemble des comptes et services AWS, ainsi que des produits partenaires tiers compatibles. Il vous aide à analyser les tendances en matière de sécurité et à identifier les problèmes de sécurité les plus prioritaires. Lorsque vous activez le Centre de sécurité, il commence à utiliser, agréger, organiser et hiérarchiser les résultats des services AWS que vous avez activés, tels qu'Amazon GuardDuty, Amazon Inspector et Amazon Macie. Vous pouvez également activer les intégrations avec les produits de sécurité partenaires AWS.
Recommandation : Assurez-vous qu'AWS Security Hub est activé
Pour corriger ce résultat, procédez comme suit :
Console AWS
- Utilisez les identifiants de l'identité IAM pour vous connecter à la console du Centre de sécurité.
- Lorsque vous ouvrez la console du Centre de sécurité pour la première fois, sélectionnez "Activer le Centre de sécurité AWS".
- Sur la page d'accueil, les normes de sécurité affichent les normes de sécurité compatibles avec le Centre de sécurité.
- Sélectionnez "Activer le centre de sécurité".
CLI AWS
Exécutez la commande enable-security-hub. Pour activer les normes par défaut, incluez
--enable-default-standards
.aws securityhub enable-security-hub --enable-default-standards
Pour activer le centre de sécurité sans les normes par défaut, incluez
--no-enable-default-standards
.aws securityhub enable-security-hub --no-enable-default-standards
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesCloudtrail Logs Encrypted Rest Using Kms Cmks
Nom de la catégorie dans l'API : CLOUDTRAIL_LOGS_ENCRYPTED_REST_USING_KMS_CMKS
AWS CloudTrail est un service Web qui enregistre les appels d'API AWS pour un compte et met ces journaux à la disposition des utilisateurs et des ressources conformément aux stratégies IAM. AWS Key Management Service (KMS) est un service géré qui permet de créer et de contrôler les clés de chiffrement utilisées pour chiffrer les données de compte. Il utilise des modules de sécurité matériels (HSM) pour protéger la sécurité des clés de chiffrement. Les journaux CloudTrail peuvent être configurés pour exploiter le chiffrement côté serveur (SSE) et les clés principales créées par le client (CMK) KMS afin de mieux protéger les journaux CloudTrail. Il est recommandé de configurer CloudTrail de façon à utiliser SSE-KMS.
Recommandation : S'assurer que les journaux CloudTrail sont chiffrés au repos à l'aide de clés CMK KMS
Pour corriger ce résultat, procédez comme suit :
Console AWS
- Connectez-vous à la console de gestion AWS et ouvrez la console CloudTrail à l'adresse https://console.aws.amazon.com/cloudtrail.
- Dans le volet de navigation de gauche, sélectionnez
Trails
. - Cliquez sur une piste
- Dans la section
S3
, cliquez sur le bouton "Edit" (Modifier) (icône en forme de crayon). - Cliquez sur
Advanced
. - Sélectionnez une clé CMK existante dans le menu déroulant
KMS key Id
.- Remarque: Assurez-vous que la clé CMK se trouve dans la même région que le bucket S3.
- Remarque: Vous devez appliquer une règle de clé KMS à la clé CMK sélectionnée afin que CloudTrail en tant que service puisse chiffrer et déchiffrer des fichiers journaux à l'aide de la clé CMK fournie. Pour modifier les règles sélectionnées pour les clés CMK, cliquez ici pour découvrir la procédure à suivre
- Cliquez sur
Save
. - Un message de notification vous indique que vous devez disposer d'autorisations de déchiffrement sur la clé KMS spécifiée pour déchiffrer les fichiers journaux.
- Cliquez sur
Yes
.
CLI AWS
aws cloudtrail update-trail --name <trail_name> --kms-id <cloudtrail_kms_key>
aws kms put-key-policy --key-id <cloudtrail_kms_key> --policy <cloudtrail_kms_key_policy>
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesCloudtrail Log File Validation Enabled
Nom de la catégorie dans l'API : CLOUDTRAIL_LOG_FILE_VALIDATION_ENABLED
La validation du fichier journal CloudTrail crée un fichier condensé signé numériquement contenant un hachage de chaque journal que CloudTrail écrit sur S3. Ces fichiers récapitulatifs peuvent être utilisés pour déterminer si un fichier journal a été modifié, supprimé ou non modifié après l'envoi du journal par CloudTrail. Il est recommandé d'activer la validation des fichiers sur tous les CloudTrails.
Recommandation : Assurez-vous que la validation du fichier journal CloudTrail est activée
Pour corriger ce résultat, procédez comme suit :
Console AWS
- Connectez-vous à la console de gestion AWS et ouvrez la console IAM à l'adresse https://console.aws.amazon.com/cloudtrail.
- Cliquez sur
Trails
dans le volet de navigation de gauche. - Cliquez sur le sentier cible.
- Dans la section
General details
, cliquez suredit
. - Dans la section
Advanced settings
- Cochez la case d'activation sous
Log file validation
. - Cliquez sur
Save changes
.
CLI AWS
aws cloudtrail update-trail --name <trail_name> --enable-log-file-validation
Notez que la validation périodique des journaux à l'aide de ces condensés peut être effectuée en exécutant la commande suivante:
aws cloudtrail validate-logs --trail-arn <trail_arn> --start-time <start_time> --end-time <end_time>
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesCloudtrail Trails Integrated Cloudwatch Logs
Nom de la catégorie dans l'API : CLOUDTRAIL_TRAILS_INTEGRATED_CLOUDWATCH_LOGS
AWS CloudTrail est un service Web qui enregistre les appels d'API AWS effectués dans un compte AWS donné. Les informations enregistrées incluent l'identité de l'appelant de l'API, l'heure de l'appel d'API, l'adresse IP source de l'appelant, les paramètres de requête et les éléments de réponse renvoyés par le service AWS. CloudTrail utilise Amazon S3 pour le stockage et la diffusion des fichiers journaux. Ils sont ainsi stockés de manière durable. En plus de capturer les journaux CloudTrail dans un bucket S3 spécifié pour une analyse à long terme, vous pouvez effectuer une analyse en temps réel en configurant CloudTrail pour qu'il envoie des journaux aux journaux CloudWatch. Pour un test activé dans toutes les régions d'un compte, CloudTrail envoie les fichiers journaux de toutes ces régions à un groupe de journaux CloudWatch Logs. Il est recommandé d'envoyer les journaux CloudTrail aux journaux CloudWatch.
Recommandation : S'assurer que les pistes CloudTrail sont intégrées aux journaux CloudWatch
Pour corriger ce résultat, procédez comme suit :
Console AWS
- Connectez-vous à la console CloudTrail à l'adresse
https://console.aws.amazon.com/cloudtrail/
. - Sélectionnez le
Trail
à mettre à jour. - Faites défiler l'écran vers le bas jusqu'à
CloudWatch Logs
. - Cliquez sur
Edit
. - Sous
CloudWatch Logs
, cochez la caseEnabled
. - Sous
Log Group
, choisissez un nouveau groupe de journaux ou sélectionnez-en un existant. - Modifiez le
Log group name
pour qu'il corresponde au CloudTrail ou sélectionnez le groupe CloudWatch existant. - Sous
IAM Role
, choisissez un nouvel élément ou sélectionnez un élément existant. - Modifiez le
Role name
en fonction de CloudTrail ou choisissez le rôle IAM existant. - Cliquez sur "Enregistrer les modifications".
CLI AWS
aws cloudtrail update-trail --name <trail_name> --cloudwatch-logs-log-group-arn <cloudtrail_log_group_arn> --cloudwatch-logs-role-arn <cloudtrail_cloudwatchLogs_role_arn>
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesCloudwatch Alarm Action Check
Nom de la catégorie dans l'API : CLOUDWATCH_ALARM_ACTION_CHECK
Cela permet de vérifier si des actions sont définies sur Amazon Cloudwatch lorsqu'une alarme passe des états "OK", "ALARM" et "INSUFFICIENT_DATA".
Il est très important de configurer des actions pour l'état ALARM des alarmes Amazon CloudWatch afin de déclencher une réponse immédiate lorsque les métriques surveillées ne respectent pas les seuils. Elle garantit une résolution rapide des problèmes, réduit les temps d'arrêt et permet d'automatiser la résolution des problèmes, de préserver l'état du système et d'éviter les pannes.
Les alarmes comportent au moins une action. Les alarmes ont au moins une action lorsqu'elles passent à l'état "INSUFFICIENT_DATA" depuis tout autre état. (Facultatif) Les alarmes ont au moins une action lorsqu'elles passent à l'état "OK" à partir de tout autre état.
Recommandation : Vérifie si les alarmes CloudWatch ont au moins une action d'alarme, une action INSUFFICIENT_DATA ou une action OK activée.
Pour corriger ce résultat, procédez comme suit :
Console AWS
Pour configurer les actions ALARM de vos alarmes Amazon CloudWatch, procédez comme suit.
- Ouvrez la console Amazon CloudWatch à l'adresse https://console.aws.amazon.com/cloudwatch/.
- Dans le volet de navigation, sous "Alarmes", sélectionnez "Toutes les alarmes".
- Choisissez l’alarme Amazon CloudWatch que vous souhaitez modifier, choisissez « Actions » et sélectionnez « Modifier ».
- Sur la gauche, sélectionnez "Étape 2 : Configurer les actions (facultatif)".
- Pour "Déclencheur d'état de l'alarme", sélectionnez l'option "En alarme" pour configurer une action basée sur une ALARME.
- Pour envoyer une notification à un sujet SNS nouvellement créé, sélectionnez « Créer un sujet ».
- Dans le champ "Créer un sujet...", spécifiez un nom de sujet SNS unique.
- Dans le champ "Points de terminaison de messagerie qui recevront la notification...", spécifiez une ou plusieurs adresses e-mail.
- Sélectionnez ensuite "Create Topic" (Créer un sujet) pour créer le sujet Amazon SNS requis.
- En bas à droite, sélectionnez "Suivant", "Suivant", puis choisissez "Mettre à jour l'alarme" pour appliquer les modifications.
- Ouvrez votre client de messagerie et, dans l'e-mail de Notifications AWS, cliquez sur le lien pour confirmer votre abonnement au sujet SNS en question.
- Répétez les étapes 4 à 11 et à l'étape 5, en sélectionnant "OK" et "Données insuffisantes" pour le "déclencheur d'état de l'alarme" afin de configurer les actions pour ces deux états.
- Répétez la procédure pour toutes les autres alarmes CloudWatch de la même région AWS.
- Répétez la procédure pour toutes les autres alarmes CloudWatch dans toutes les autres régions AWS.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesCloudwatch Log Group Encrypted
Nom de la catégorie dans l'API : CLOUDWATCH_LOG_GROUP_ENCRYPTED
Cette vérification permet de s'assurer que les journaux CloudWatch sont configurés avec KMS.
Les données d'un groupe de journaux sont toujours chiffrées dans les journaux CloudWatch. Par défaut, les journaux CloudWatch utilisent le chiffrement côté serveur pour les données de journal au repos. Vous pouvez également utiliser AWS Key Management Service pour ce chiffrement. Dans ce cas, le chiffrement est effectué à l'aide d'une clé KMS AWS. Le chiffrement à l'aide d'AWS KMS est activé au niveau du groupe de journaux, en associant une clé KMS à un groupe de journaux, soit lors de la création du groupe de journaux, soit par la suite.
Recommandation : Vérifie que tous les groupes de journaux dans Amazon CloudWatch Logs sont chiffrés avec KMS
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesCloudTrail CloudWatch Logs Enabled
Nom de la catégorie dans l'API : CLOUD_TRAIL_CLOUD_WATCH_LOGS_ENABLED
Cette commande vérifie si les pistes CloudTrail sont configurées pour envoyer des journaux aux journaux CloudWatch. Le contrôle échoue si la propriété CloudWatchLogsLogGroupArn du suivi est vide.
CloudTrail enregistre les appels d'API AWS effectués dans un compte donné. Les informations enregistrées comprennent les éléments suivants:
- Identité de l'appelant de l'API
- Heure de l'appel d'API
- Adresse IP source de l'appelant de l'API
- Paramètres de la requête
- Éléments de réponse renvoyés par le service AWS
CloudTrail utilise Amazon S3 pour le stockage et la diffusion des fichiers journaux. Vous pouvez capturer les journaux CloudTrail dans un bucket S3 spécifié pour une analyse à long terme. Pour effectuer une analyse en temps réel, vous pouvez configurer CloudTrail pour qu'il envoie les journaux aux journaux CloudWatch.
Pour un test activé dans toutes les régions d'un compte, CloudTrail envoie les fichiers journaux de toutes ces régions à un groupe de journaux CloudWatch Logs.
Le Centre de sécurité vous recommande d'envoyer les journaux CloudTrail aux journaux CloudWatch. Notez que cette recommandation vise à garantir que l'activité du compte est capturée, surveillée et correctement alertée. Vous pouvez utiliser les journaux CloudWatch pour effectuer cette configuration avec vos services AWS. Cette recommandation n'empêche pas l'utilisation d'une autre solution.
L'envoi de journaux CloudTrail aux journaux CloudWatch facilite la journalisation des activités historiques et en temps réel en fonction de l'utilisateur, de l'API, de la ressource et de l'adresse IP. Vous pouvez utiliser cette approche pour définir des alarmes et des notifications en cas d'activité anormale ou sensible sur votre compte.
Recommandation : Vérifie que toutes les pistes CloudTrail sont configurées pour envoyer des journaux à AWS CloudWatch
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesNo AWS Credentials in CodeBuild Project Environment Variables
Nom de la catégorie dans l'API : CODEBUILD_PROJECT_ENVVAR_AWSCRED_CHECK
Cela permet de vérifier si le projet contient les variables d'environnement AWS_ACCESS_KEY_ID
et AWS_SECRET_ACCESS_KEY
.
Les identifiants d'authentification AWS_ACCESS_KEY_ID
et AWS_SECRET_ACCESS_KEY
ne doivent jamais être stockés en texte clair, car cela pourrait entraîner une exposition involontaire des données et un accès non autorisé.
Recommandation : Vérifie que tous les projets contenant les variables d'environnement AWS_ACCESS_KEY_ID et AWS_SECRET_ACCESS_KEY ne sont pas en texte brut
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesCodebuild Project Source Repo Url Check
Nom de la catégorie dans l'API : CODEBUILD_PROJECT_SOURCE_REPO_URL_CHECK
Cela permet de vérifier si l'URL du dépôt source Bitbucket du projet AWS CodeBuild contient des jetons d'accès personnels ou un nom d'utilisateur et un mot de passe. Le contrôle échoue si l'URL du dépôt source Bitbucket contient des jetons d'accès personnels ou un nom d'utilisateur et un mot de passe.
Les identifiants de connexion ne doivent pas être stockés ni transmis en texte clair, ni apparaître dans l'URL du dépôt source. Au lieu de jetons d'accès personnels ou d'identifiants de connexion, vous devez accéder à votre fournisseur source dans CodeBuild et modifier l'URL du dépôt source pour qu'elle ne contienne que le chemin d'accès à l'emplacement du dépôt Bitbucket. L'utilisation de jetons d'accès personnels ou d'identifiants de connexion peut entraîner une exposition involontaire des données ou un accès non autorisé.
Recommandation : Vérifie que tous les projets utilisant github ou bitbucket comme source utilisent oauth
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesCredentials Unused 45 Days Greater Disabled
Nom de la catégorie dans l'API : CREDENTIALS_UNUSED_45_DAYS_GREATER_DISABLED
Les utilisateurs IAM AWS peuvent accéder aux ressources AWS à l'aide de différents types d'identifiants, tels que des mots de passe ou des clés d'accès. Nous vous recommandons de désactiver ou de supprimer tous les identifiants inutilisés depuis au moins 45 jours.
Recommandation : Assurez-vous que les identifiants non utilisés pendant au moins 45 jours sont désactivés
Pour corriger ce résultat, procédez comme suit :
Console AWS
Procédez comme suit pour gérer les mots de passe inutilisés (accès à la console utilisateur IAM)
- Connectez-vous à la console de gestion AWS:
- Cliquez sur
Services
. - Cliquez sur
IAM
. - Cliquez sur
Users
. - Cliquez sur
Security Credentials
. - Sélectionner l'utilisateur dont la date de début (
Console last sign-in
) est supérieure à 45 jours - Cliquez sur
Security credentials
. - Dans la section
Sign-in credentials
,Console password
cliquez surManage
. - Sous "Console Access" (Accès à la console), sélectionnez
Disable
. 10. Cliquez surApply
.
Pour désactiver les clés d'accès, procédez comme suit:
- Connectez-vous à la console de gestion AWS:
- Cliquez sur
Services
. - Cliquez sur
IAM
. - Cliquez sur
Users
. - Cliquez sur
Security Credentials
. - Sélectionnez les clés d'accès qui ont été utilisées depuis plus de 45 jours et qui ont été utilisées.
- Cliquez sur
Make Inactive
.
- Cliquez sur
- Sélectionnez les clés d'accès qui n'ont pas été utilisées depuis plus de 45 jours, puis
- Cliquez sur le X pour
Delete
- Cliquez sur le X pour
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesDefault Security Group Vpc Restricts All Traffic
Nom de la catégorie dans l'API : DEFAULT_SECURITY_GROUP_VPC_RESTRICTS_ALL_TRAFFIC
Un VPC est fourni avec un groupe de sécurité par défaut dont les paramètres initiaux refusent tout le trafic entrant, autorisent tout le trafic sortant et autorisent tout le trafic entre les instances attribuées au groupe de sécurité. Si vous ne spécifiez pas de groupe de sécurité lorsque vous lancez une instance, celle-ci est automatiquement attribuée à ce groupe de sécurité par défaut. Les groupes de sécurité permettent un filtrage avec état du trafic réseau entrant/sortant vers les ressources AWS. Il est recommandé d'utiliser le groupe de sécurité par défaut pour restreindre l'ensemble du trafic.
Le groupe de sécurité par défaut du VPC par défaut de chaque région doit être mis à jour pour être conforme. Tous les VPC nouvellement créés contiennent automatiquement un groupe de sécurité par défaut qui devra être corrigé pour se conformer à cette recommandation.
REMARQUE:Lors de la mise en œuvre de cette recommandation, la journalisation de flux VPC est inestimable pour déterminer l'accès au port du moindre privilège requis par les systèmes pour fonctionner correctement, car elle peut consigner toutes les acceptations et tous les rejets de paquets qui se produisent dans les groupes de sécurité actuels. Cela réduit considérablement l'obstacle principal à l'ingénierie du moindre privilège, qui consiste à identifier le nombre minimal de ports requis par les systèmes de l'environnement. Même si la recommandation concernant la journalisation de flux VPC de ce benchmark n'est pas adoptée comme mesure de sécurité permanente, elle doit être utilisée pendant toute période de découverte et d'ingénierie pour les groupes de sécurité les moins privilégiés.
Recommandation : Assurez-vous que le groupe de sécurité par défaut de chaque VPC limite tout le trafic
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesDms Replication Not Public
Nom de la catégorie dans l'API : DMS_REPLICATION_NOT_PUBLIC
Vérifie si les instances de réplication AWS DMS sont publiques. Pour ce faire, il examine la valeur du champ PubliclyAccessible
.
Une instance de réplication privée possède une adresse IP privée à laquelle vous ne pouvez pas accéder en dehors du réseau de réplication. Une instance de réplication doit disposer d'une adresse IP privée lorsque les bases de données source et cible se trouvent sur le même réseau. Le réseau doit également être connecté au VPC de l'instance de réplication à l'aide d'un VPN, d'AWS Direct Connect ou d'un appairage de VPC. Pour en savoir plus sur les instances de réplication publiques et privées, consultez la section Instances de réplication publiques et privées du guide de l'utilisateur d'AWS Database Migration Service.
Vous devez également vous assurer que l'accès à la configuration de votre instance AWS DMS est limité aux seuls utilisateurs autorisés. Pour ce faire, limitez les autorisations IAM des utilisateurs à la modification des paramètres et des ressources AWS DMS.
Recommandation : Vérifie si les instances de réplication AWS Database Migration Service sont publiques
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesDo Setup Access Keys During Initial User Setup All Iam Users Console
Nom de la catégorie dans l'API : DO_SETUP_ACCESS_KEYS_DURING_INITIAL_USER_SETUP_ALL_IAM_USERS_CONSOLE
Par défaut, aucune case de la console AWS n'est cochée lors de la création d'un utilisateur IAM. Lorsque vous créez les identifiants utilisateur IAM, vous devez déterminer le type d'accès dont ils ont besoin.
Accès programmatique: l'utilisateur IAM devra peut-être effectuer des appels d'API, utiliser la CLI AWS ou les outils pour Windows PowerShell. Dans ce cas, créez une clé d'accès (ID de clé d'accès et clé d'accès secrète) pour cet utilisateur.
Accès à la console de gestion AWS: si l'utilisateur a besoin d'accéder à la console AWS Management Console, créez un mot de passe pour l'utilisateur.
Recommandation : Ne configurez pas de clés d'accès lors de la configuration initiale de l'utilisateur pour tous les utilisateurs IAM disposant d'un mot de passe de console
Pour corriger ce résultat, procédez comme suit :
Console AWS
- Connectez-vous à la console de gestion AWS:
- Cliquez sur
Services
. - Cliquez sur
IAM
. - Cliquez sur
Users
. - Cliquez sur
Security Credentials
. - En tant qu'administrateur
- Cliquez sur la croix (X)
(Delete)
pour les clés qui ont été créées en même temps que le profil utilisateur, mais qui n'ont pas été utilisées.
- Cliquez sur la croix (X)
- En tant qu'utilisateur IAM :
- Cliquez sur la croix (X)
(Delete)
pour les clés qui ont été créées en même temps que le profil utilisateur, mais qui n'ont pas été utilisées.
- Cliquez sur la croix (X)
CLI AWS
aws iam delete-access-key --access-key-id <access-key-id-listed> --user-name <users-name>
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesDynamodb Autoscaling Enabled
Nom de la catégorie dans l'API : DYNAMODB_AUTOSCALING_ENABLED
Cela permet de vérifier si une table Amazon DynamoDB peut adapter sa capacité de lecture et d'écriture en fonction des besoins. Cette commande réussit si la table utilise le mode de capacité à la demande ou le mode provisionné avec l'autoscaling configuré. Le scaling de la capacité en fonction de la demande évite les exceptions de limitation, ce qui permet de maintenir la disponibilité de vos applications.
Les tables DynamoDB en mode capacité à la demande ne sont limitées que par les quotas de tables par défaut du débit DynamoDB. Pour augmenter ces quotas, vous pouvez envoyer une demande d'assistance via l'assistance AWS.
Les tables DynamoDB en mode provisionné avec autoscaling ajustent la capacité de débit provisionnée de manière dynamique en fonction des tendances du trafic. Pour en savoir plus sur la limitation des requêtes DynamoDB, consultez "Request throttling and burst capacité" (Limitation des requêtes et capacité d'utilisation intensive) dans le guide du développeur Amazon DynamoDB.
Recommandation : Les tables DynamoDB doivent automatiquement adapter leur capacité en fonction de la demande
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesDynamodb In Backup Plan
Nom de la catégorie dans l'API : DYNAMODB_IN_BACKUP_PLAN
Cette commande évalue si une table DynamoDB est couverte par un plan de sauvegarde. Le contrôle échoue si une table DynamoDB n'est pas couverte par un plan de sauvegarde. Cette commande n'évalue que les tables DynamoDB à l'état ACTIVE.
Les sauvegardes vous aident à récupérer plus rapidement après un incident de sécurité. Ils renforcent également la résilience de vos systèmes. Inclure des tables DynamoDB dans un plan de sauvegarde vous aide à protéger vos données contre les pertes ou les suppressions accidentelles.
Recommandation : Les tables DynamoDB doivent être couvertes par un plan de sauvegarde
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesDynamodb Pitr Enabled
Nom de la catégorie dans l'API : DYNAMODB_PITR_ENABLED
La récupération à un moment précis est l'un des mécanismes de sauvegarde des tables DynamoDB.
La sauvegarde à un moment précis est conservée pendant 35 jours. Si vous avez besoin d'une durée de conservation plus longue, consultez Configurer des sauvegardes planifiées pour Amazon DynamoDB à l'aide de la sauvegarde AWS dans la documentation AWS.
Recommandation : Vérifie que la récupération à un moment précis (PITR) est activée pour toutes les tables AWS DynamoDB
Pour corriger ce résultat, procédez comme suit :
Terraform
Afin de définir la récupération à un moment précis pour les tables DynamoDB, définissez le bloc point_in_time_recovery
:
resource "aws_dynamodb_table" "example" {
# ... other configuration ...
point_in_time_recovery {
enabled = true
}
}
Console AWS
Activer la récupération à un moment précis DynamoDB pour une table existante
- Ouvrez la console DynamoDB à l'adresse https://console.aws.amazon.com/dynamodb/.
- Choisissez la table que vous souhaitez utiliser, puis sélectionnez "Sauvegardes".
- Dans la section "Récupération à un moment précis", sous "État", sélectionnez "Activer".
- Sélectionnez à nouveau "Activer" pour confirmer la modification.
CLI AWS
aws dynamodb update-continuous-backups \
--table-name "GameScoresOnDemand" \
--point-in-time-recovery-specification "PointInTimeRecoveryEnabled=true"
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesDynamodb Table Encrypted Kms
Nom de la catégorie dans l'API : DYNAMODB_TABLE_ENCRYPTED_KMS
Vérifie si toutes les tables DynamoDB sont chiffrées avec une clé KMS gérée par le client (autre que celle par défaut).
Recommandation : Vérifie que toutes les tables DynamoDB sont chiffrées avec AWS Key Management Service (KMS)
Pour corriger ce résultat, procédez comme suit :
Terraform
Pour remédier à ce problème, créez une clé KMS AWS et utilisez-la pour chiffrer la ressource DynamoDB non conforme.
resource "aws_kms_key" "dynamodb_encryption" {
description = "Used for DynamoDB encryption configuration"
enable_key_rotation = true
}
resource "aws_dynamodb_table" "example" {
# ... other configuration ...
server_side_encryption {
enabled = true
kms_key_arn = aws_kms_key.dynamodb_encryption.arn
}
}
Console AWS
En supposant qu'une clé KMS AWS existante soit disponible pour chiffrer DynamoDB.
Pour remplacer le chiffrement d'une table DynamoDB par une clé KMS gérée et détenue par le client :
- Ouvrez la console DynamoDB à l'adresse https://console.aws.amazon.com/dynamodb/.
- Choisissez le tableau que vous souhaitez utiliser, puis sélectionnez "Paramètres supplémentaires".
- Sous Chiffrement, sélectionnez Gérer le chiffrement.
- Pour "Chiffrement au repos", choisissez "Stocké dans votre compte", et vous en êtes le propriétaire et l'administrateur.
- Sélectionnez la clé AWS à utiliser. Enregistrez les modifications.
CLI AWS
aws dynamodb update-table \
--table-name <value> \
--sse-specification "Enabled=true,SSEType=KMS,KMSMasterKeyId=<kms_key_arn>"
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesEbs Optimized Instance
Nom de la catégorie dans l'API : EBS_OPTIMIZED_INSTANCE
Vérifie si l'optimisation EBS est activée pour vos instances EC2 pouvant être optimisées pour EBS
Recommandation : Vérifie que l'optimisation EBS est activée pour toutes les instances compatibles avec l'optimisation EBS
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesEbs Snapshot Public Restorable Check
Nom de la catégorie dans l'API : EBS_SNAPSHOT_PUBLIC_RESTORABLE_CHECK
Vérifie si les instantanés Amazon Elastic Block Store ne sont pas publics. Le contrôle échoue si quelqu'un peut restaurer des instantanés Amazon EBS.
Les instantanés EBS sont utilisés pour sauvegarder les données de vos volumes EBS dans Amazon S3 à un moment précis. Vous pouvez utiliser les instantanés pour restaurer les états précédents des volumes EBS. Il est rarement acceptable de partager un instantané avec le public. En général, la décision de partager publiquement un instantané a été prise par erreur ou sans une compréhension complète des implications. Cette vérification permet de s'assurer que ces partages ont été entièrement planifiés et intentionnels.
Recommandation : Les instantanés Amazon EBS ne devraient pas être restaurés publiquement
Pour corriger ce résultat, procédez comme suit :
Console AWS
Pour résoudre ce problème, mettez à jour votre instantané EBS afin de le rendre privé plutôt que public.
Pour rendre privé un instantané EBS public:
- Ouvrez la console Amazon EC2 à l'adresse https://console.aws.amazon.com/ec2/.
- Dans le volet de navigation, sous "Elastic Block Store", sélectionnez le menu Snapshots (Instantanés), puis votre instantané public.
- Dans "Actions", sélectionnez "Modifier les autorisations".
- Sélectionnez Privé.
- (Facultatif) Ajoutez les numéros de compte AWS des comptes autorisés avec lesquels partager votre instantané et sélectionnez "Ajouter une autorisation".
- Sélectionnez "Enregistrer".
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesEbs Volume Encryption Enabled All Regions
Nom de la catégorie dans l'API : EBS_VOLUME_ENCRYPTION_ENABLED_ALL_REGIONS
Elastic Compute Cloud (EC2) est compatible avec le chiffrement au repos lors de l'utilisation du service Elastic Block Store (EBS). Bien que désactivé par défaut, il est possible de forcer le chiffrement lors de la création d'un volume EBS.
Recommandation : Assurez-vous que le chiffrement de volume EBS est activé dans toutes les régions
Pour corriger ce résultat, procédez comme suit :
Console AWS
- Connectez-vous à AWS Management Console et ouvrez la console Amazon EC2 à l'adresse https://console.aws.amazon.com/ec2/.
- Sous
Account attributes
, cliquez surEBS encryption
. - Cliquez sur
Manage
. - Cochez la case
Enable
. - Cliquez sur
Update EBS encryption
. - Répétez l'opération pour chaque région devant être modifiée.
Remarque:Le chiffrement de volume EBS est configuré par région.
CLI AWS
- Exécutez
aws --region <region> ec2 enable-ebs-encryption-by-default
. - Vérifiez que
"EbsEncryptionByDefault": true
s'affiche. - Répétez chaque région devant être modifiée.
Remarque:Le chiffrement de volume EBS est configuré par région.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesEc2 Instances In Vpc
Nom de la catégorie dans l'API : EC2_INSTANCES_IN_VPC
Amazon VPC offre plus de fonctionnalités de sécurité qu'EC2 Classic. Il est recommandé que tous les nœuds appartiennent à un réseau VPC Amazon.
Recommandation : Assurez-vous que toutes les instances appartiennent à un VPC
Pour corriger ce résultat, procédez comme suit :
Terraform
Si des instances EC2 classiques sont définies dans Terraform, vous pouvez modifier vos ressources pour qu'elles fassent partie d'un VPC. Cette migration dépend de l'architecture adaptée à vos besoins. Voici un exemple Terraform simple qui illustre une instance EC2 publique dans un VPC.
resource "aws_vpc" "example_vpc" {
cidr_block = "10.0.0.0/16"
}
resource "aws_subnet" "example_public_subnet" {
vpc_id = aws_vpc.example_vpc.id
cidr_block = "10.0.1.0/24"
availability_zone = "1a"
}
resource "aws_internet_gateway" "example_igw" {
vpc_id = aws_vpc.example_vpc.id
}
resource "aws_key_pair" "example_key" {
key_name = "web-instance-key"
public_key = "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQD3F6tyPEFEzV0LX3X8BsXdMsQz1x2cEikKDEY0aIj41qgxMCP/iteneqXSIFZBp5vizPvaoIR3Um9xK7PGoW8giupGn+EPuxIA4cDM4vzOqOkiMPhz5XK0whEjkVzTo4+S0puvDZuwIsdiW9mxhJc7tgBNL0cYlWSYVkz4G/fslNfRPW5mYAM49f4fhtxPb5ok4Q2Lg9dPKVHO/Bgeu5woMc7RY0p1ej6D4CKFE6lymSDJpW0YHX/wqE9+cfEauh7xZcG0q9t2ta6F6fmX0agvpFyZo8aFbXeUBr7osSCJNgvavWbM/06niWrOvYX2xwWdhXmXSrbX8ZbabVohBK41 email@example.com"
}
resource "aws_security_group" "web_sg" {
name = "http and ssh"
vpc_id = aws_vpc.some_custom_vpc.id
ingress {
from_port = 80
to_port = 80
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
}
ingress {
from_port = 22
to_port = 22
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
}
egress {
from_port = 0
to_port = 0
protocol = -1
cidr_blocks = ["0.0.0.0/0"]
}
}
resource "aws_instance" "web" {
ami = <ami_id>
instance_type = <instance_flavor>
key_name = aws_key_pair.example_key.name
monitoring = true
subnet_id = aws_subnet.example_public_subnet.id
vpc_security_group_ids = [aws_security_group.web_sg.id]
metadata_options {
http_tokens = "required"
}
}
Console AWS
Pour migrer EC2 Classic vers un VPC, consultez Migrer EC2 Classic vers un VPC
CLI AWS
Cet exemple de CLI AWS illustre la même infrastructure définie avec Terraform. Il s'agit d'un exemple simple d'instance EC2 exposée dans un VPC
Créer un VPC
aws ec2 create-vpc \
--cidr-block 10.0.0.0/16
Créer un sous-réseau public
aws ec2 create-subnet \
--availability-zone 1a \
--cidr-block 10.0.1.0/24 \
--vpc-id <id_from_create-vpc_command>
Créer une passerelle Internet
aws ec2 create-internet-gateway
Associer la passerelle Internet au VPC
aws ec2 attach-internet-gateway \
--internet-gateway-id <id_from_create-internet-gateway_command> \
--vpc-id <id_from_create-vpc_command>
Créer une paire de clés : votre clé privée sera enregistrée dans /.ssh/web-instance-key.pem
aws ec2 create-key-pair \
--key-name web-instance-key \
--query "KeyMaterial" \
--output text > ~/.ssh/web-instance-key.pem && \
chmod 400 ~/.ssh/web-instance-key.pem
Créer un groupe de sécurité
aws ec2 create-security-group \
--group-name "http and ssh" \
--vpc-id <id_from_create-vpc_command>
Créer des règles de groupe de sécurité : pour restreindre l'accès, définissez un CIDR plus restreint pour SSH sur le port 22.
aws ec2 authorize-security-group-ingress \
--group-id <id_from_create-security-group_command>
--protocol tcp \
--port 80 \
--cidr 0.0.0.0/0
aws ec2 authorize-security-group-ingress \
--group-id <id_from_create-security-group_command>
--protocol tcp \
--port 22 \
--cidr 0.0.0.0/0
aws ec2 authorize-security-group-egress \
--group-id <id_from_create-security-group_command>
--protocol -1 \
--port 0 \
--cidr 0.0.0.0/0
Créer une instance EC2
aws ec2 run-instances \
--image-id <ami_id> \
--instance-type <instance_flavor> \
--metadata-options "HttpEndpoint=enabled,HttpTokens=required" \
--monitoring true \
--key-name web-instance-key \
--subnet-id <id_from_create-subnet_command> \
--security-group-ids <id_from_create-security-group_command>
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesEc2 Instance No Public Ip
Nom de la catégorie dans l'API : EC2_INSTANCE_NO_PUBLIC_IP
Les instances EC2 qui ont une adresse IP publique présentent un risque accru de piratage. Il est recommandé de ne pas configurer les instances EC2 avec une adresse IP publique.
Recommandation : Assurez-vous qu'aucune instance n'a d'adresse IP publique
Pour corriger ce résultat, procédez comme suit :
Terraform
Utilisez l'argument associate_public_ip_address = false
avec la ressource aws_instance
pour vous assurer que les instances EC2 sont provisionnées sans adresse IP publique.
resource "aws_instance" "no_public_ip" {
...
associate_public_ip_address = false
}
Console AWS
Par défaut, l'attribut d'adressage public IPv4 est défini sur "false" pour les sous-réseaux autres que ceux par défaut, tandis que cet attribut est défini sur "true" pour les sous-réseaux par défaut. Les sous-réseaux autres que ceux par défaut créés par l'assistant de lancement d'instance Amazon EC2 constituent une exception. L'assistant définit l'attribut sur "true". Vous pouvez modifier cet attribut à l'aide de la console Amazon VPC.
Pour modifier le comportement de l'adressage IPv4 public de votre sous-réseau :
- Ouvrez la console Amazon VPC à l'adresse https://console.aws.amazon.com/vpc/.
- Dans le volet de navigation, sélectionnez Sous-réseaux.
- Sélectionnez votre sous-réseau, puis cliquez sur Actions, Modifier les paramètres du sous-réseau.
- La case Activer l'attribution automatique des adresses IPv4 publiques, si elle est cochée, demande une adresse IPv4 publique pour toutes les instances lancées dans le sous-réseau sélectionné. Cochez ou décochez la case selon vos besoins, puis sélectionnez Enregistrer.
CLI AWS
La commande suivante permet d'exécuter une instance EC2 dans un sous-réseau par défaut sans lui associer d'adresse IP publique.
aws ec2 run-instances \
--image-id <ami_id> \
--instance-type <instance_flavor> \
--no-associate-public-ip-address \
--key-name MyKeyPair
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesEc2 Managedinstance Association Compliance Status Check
Nom de la catégorie dans l'API : EC2_MANAGEDINSTANCE_ASSOCIATION_COMPLIANCE_STATUS_CHECK
Une association de gestionnaire d'états est une configuration attribuée à vos instances gérées. La configuration définit l'état que vous souhaitez maintenir sur vos instances. Par exemple, une association peut spécifier qu'un logiciel antivirus doit être installé et exécuté sur vos instances, ou que certains ports doivent être fermés. Les instances EC2 associées à AWS Systems Manager sont gérées par Systems Manager, ce qui facilite l'application de correctifs, la correction des erreurs de configuration et la réponse aux événements de sécurité.
Recommandation : Vérifie l'état de conformité associé au gestionnaire de systèmes AWS
Pour corriger ce résultat, procédez comme suit :
Terraform
L'exemple suivant montre comment créer une instance EC2 simple, un document AWS Systems Manager (SSM) et une association entre SSM et l'instance EC2. Les documents acceptés sont de type Command
et Policy
.
resource "aws_instance" "web" {
ami = "<iam_id>"
instance_type = "<instance_flavor>"
}
resource "aws_ssm_document" "check_ip" {
name = "check-ip-config"
document_type = "Command"
content = <<DOC
{
"schemaVersion": "1.2",
"description": "Check ip configuration of a Linux instance.",
"parameters": {
},
"runtimeConfig": {
"aws:runShellScript": {
"properties": [
{
"id": "0.aws:runShellScript",
"runCommand": ["ifconfig"]
}
]
}
}
}
DOC
}
resource "aws_ssm_association" "check_ip_association" {
name = aws_ssm_document.check_ip.name
targets {
key = "InstanceIds"
values = [aws_instance.web.id]
}
}
Console AWS
Pour savoir comment configurer des associations avec AWS Systems Manager à l'aide de la console, consultez la section Créer des associations dans la documentation AWS Systems Manager.
CLI AWS
Créer un document SSM
aws ssm create-document \
--name <document_name> \
--content file://path/to-file/document.json \
--document-type "Command"
Créer une association SSM
aws ssm create-association \
--name <association_name> \
--targets "Key=InstanceIds,Values=<instance-id-1>,<instance-id-2>"
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesEc2 Managedinstance Patch Compliance Status Check
Nom de la catégorie dans l'API : EC2_MANAGEDINSTANCE_PATCH_COMPLIANCE_STATUS_CHECK
Cette commande vérifie si l'état de conformité de l'association AWS Systems Manager est COMPLIANT ou NON_COMPLIANT après l'exécution de l'association sur une instance. Le contrôle échoue si l'état de conformité de l'association est NON_COMPLIANT.
Une association de gestionnaire d'états est une configuration attribuée à vos instances gérées. La configuration définit l'état que vous souhaitez maintenir sur vos instances. Par exemple, une association peut spécifier qu'un logiciel antivirus doit être installé et exécuté sur vos instances ou que certains ports doivent être fermés.
Une fois que vous avez créé une ou plusieurs associations de gestionnaires d'état, les informations sur l'état de conformité sont immédiatement disponibles. Vous pouvez afficher l'état de conformité dans la console ou en réponse aux commandes de la CLI AWS ou aux actions correspondantes de l'API Systems Manager. Pour les associations, la colonne "Conformité de la configuration" indique l'état de conformité ("Conforme" ou "Non conforme"). Il indique également le niveau de gravité attribué à l'association, par exemple Critique ou Moyen.
Pour en savoir plus sur la conformité des associations avec le gestionnaire d'état, consultez la section À propos de la conformité des associations du gestionnaire d'état dans le guide de l'utilisateur d'AWS Systems Manager.
Recommandation : Vérifie l'état de la conformité des correctifs AWS Systems Manager
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesEc2 Metadata Service Allows Imdsv2
Nom de la catégorie dans l'API : EC2_METADATA_SERVICE_ALLOWS_IMDSV2
Lors de l'activation du service de métadonnées sur des instances AWS EC2, les utilisateurs ont le choix entre utiliser soit la version 1 du service de métadonnées d'instance (IMDSv1, méthode requête/réponse), soit la version 2 du service de métadonnées d'instance (IMDSv2, une méthode orientée session).
Recommandation : Assurez-vous que le service de métadonnées EC2 n'autorise que IMDSv2
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesEc2 Volume Inuse Check
Nom de la catégorie dans l'API : EC2_VOLUME_INUSE_CHECK
Identifiez et supprimez les volumes EBS (Elastic Block Store) non associés (non associés) dans votre compte AWS afin de réduire le coût de votre facture AWS mensuelle. La suppression des volumes EBS inutilisés réduit également le risque que des données sensibles/confidentielles quittent votre site. En outre, cette commande vérifie également si les instances EC2 archivées et configurées pour supprimer des volumes à l'arrêt.
Par défaut, les instances EC2 sont configurées pour supprimer les données de tous les volumes EBS associés à l'instance et pour supprimer le volume EBS racine de l'instance. Toutefois, tous les volumes EBS non racines associés à l'instance, au lancement ou pendant l'exécution, sont conservés par défaut après l'arrêt.
Recommandation : Vérifie si les volumes EBS sont associés à des instances EC2 et configurés pour être supprimés à l'arrêt de l'instance
Pour corriger ce résultat, procédez comme suit :
Terraform
Pour éviter ce scénario en utilisant Terraform, créez des instances EC2 avec des blocs EBS intégrés. Cela garantit que tous les blocs EBS associés à l'instance (pas seulement à la racine) seront supprimés lors de l'arrêt de l'instance si l'attribut ebs_block_device.delete_on_termination
est défini par défaut sur true
.
resource "aws_instance" "web" {
ami = <ami_id>
instance_type = <instance_flavor>
ebs_block_device {
delete_on_termination = true # Default
device_name = "/dev/sdh"
}
Console AWS
Supprimer un volume EBS à l'aide de la console
- Ouvrez la console Amazon EC2 à l'adresse https://console.aws.amazon.com/ec2/.
- Dans le volet de navigation, sélectionnez Volumes.
- Sélectionnez le volume à supprimer, puis cliquez sur Actions, Supprimer le volume.
- Remarque: Si l'option "Supprimer le volume" est grisée, cela signifie que le volume est associé à une instance. Vous devez dissocier le volume de l'instance pour pouvoir la supprimer.
- Dans la boîte de dialogue de confirmation, sélectionnez Supprimer.
CLI AWS
Cet exemple de commande supprime un volume disponible dont l'ID de volume est vol-049df61146c4d7901. Si la commande aboutit, aucun résultat n'est renvoyé.
aws ec2 delete-volume --volume-id vol-049df61146c4d7901
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesEfs Encrypted Check
Nom de la catégorie dans l'API : EFS_ENCRYPTED_CHECK
Amazon EFS accepte deux formes de chiffrement pour les systèmes de fichiers : le chiffrement des données en transit et le chiffrement au repos. Cette opération permet de vérifier que tous les systèmes de fichiers EFS sont configurés avec le chiffrement au repos dans toutes les régions activées du compte.
Recommandation : Vérifie si EFS est configuré pour chiffrer les données de fichiers à l'aide de KMS
Pour corriger ce résultat, procédez comme suit :
Terraform
L'extrait de code suivant peut être utilisé pour créer un EFS chiffré par KMS. (Remarque: l'attribut kms_key_id
est facultatif. Une clé est créée si aucun ID de clé kms n'est transmis.)
resource "aws_efs_file_system" "encrypted-efs" {
creation_token = "my-kms-encrypted-efs"
encrypted = true
kms_key_id = "arn:aws:kms:us-west-2:12344375555:key/16393ebd-3348-483f-b162-99b6648azz23"
tags = {
Name = "MyProduct"
}
}
Console AWS
Pour configurer le chiffrement EFS à l'aide de la console AWS, consultez la page Chiffrer un système de fichiers au repos à l'aide de la console.
CLI AWS
Il est important de noter que si la création d'EFS à partir de la console active le chiffrement au repos par défaut, ce n'est pas le cas pour les EFS créés à l'aide de la CLI, de l'API ou du SDK. L'exemple suivant vous permet de créer un système de fichiers chiffrés dans votre infrastructure.
aws efs create-file-system \
--backup \
--encrypted \
--region us-east-1 \
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesEfs In Backup Plan
Nom de la catégorie dans l'API : EFS_IN_BACKUP_PLAN
Les bonnes pratiques d'Amazon recommandent de configurer des sauvegardes pour votre Elastic File Systems (EFS). Cette opération permet de vérifier si les sauvegardes sont activées dans tous les EFS de chaque région activée de votre compte AWS.
Recommandation : Vérifie si les systèmes de fichiers EFS sont inclus dans les plans de sauvegarde AWS
Pour corriger ce résultat, procédez comme suit :
Terraform
Utilisez la ressource aws_efs_backup_policy
pour configurer une stratégie de sauvegarde pour les systèmes de fichiers EFS.
resource "aws_efs_file_system" "encrypted-efs" {
creation_token = "my-encrypted-efs"
encrypted = true
tags = merge({
Name = "${local.resource_prefix.value}-efs"
}, {
git_file = "terraform/aws/efs.tf"
git_org = "your_git_org"
git_repo = "your_git_repo"
})
}
resource "aws_efs_backup_policy" "policy" {
file_system_id = aws_efs_file_system.encrypted-efs.id
backup_policy {
status = "ENABLED"
}
}
Console AWS
Deux options sont disponibles pour la sauvegarde EFS: le service de sauvegarde AWS et la solution de sauvegarde EFS vers EFS. Pour corriger un EFS qui n'a pas été sauvegardé à l'aide de la console, consultez les pages suivantes:
CLI AWS
Plusieurs options permettent de créer des systèmes de fichiers EFS conformes à l'aide de la CLI:
- Créez un EFS avec la sauvegarde automatique activée (par défaut pour le stockage One Zone et sous réserve de la disponibilité de la sauvegarde dans la région AWS)
- Créer un EFS et placer une stratégie de sauvegarde
Toutefois, en supposant que la correction doit se produire dans un EFS existant, la meilleure option consiste à créer une stratégie de sauvegarde et à l'associer à votre EFS non conforme. Vous aurez besoin d'une commande pour chaque EFS de votre infrastructure.
arr=( $(aws efs describe-file-systems | jq -r '.FileSystems[].FileSystemId') )
for efs in "${arr[@]}"
do
aws efs put-backup-policy \
--file-system-id "${efs}" \
--backup-policy "Status=ENABLED"
done
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesElb Acm Certificate Required
Nom de la catégorie dans l'API : ELB_ACM_CERTIFICATE_REQUIRED
Vérifie si l'équilibreur de charge classique utilise des certificats HTTPS/SSL fournis par le gestionnaire de certificats AWS (ACM). Le contrôle échoue si l'équilibreur de charge classique configuré avec l'écouteur HTTPS/SSL n'utilise pas de certificat fourni par ACM.
Pour créer un certificat, vous pouvez utiliser ACM ou un outil compatible avec les protocoles SSL et TLS, comme OpenSSL. Le Centre de sécurité vous recommande d'utiliser ACM pour créer ou importer des certificats pour votre équilibreur de charge.
ACM s'intègre aux équilibreurs de charge classiques afin que vous puissiez déployer le certificat sur votre équilibreur de charge. Vous devez également renouveler automatiquement ces certificats.
Recommandation : Vérifie que tous les équilibreurs de charge classiques utilisent des certificats SSL fournis par le gestionnaire de certificats AWS
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesElb Deletion Protection Enabled
Nom de la catégorie dans l'API : ELB_DELETION_PROTECTION_ENABLED
Vérifie si la protection contre la suppression est activée pour un équilibreur de charge d'application. Le contrôle échoue si la protection contre la suppression n'est pas configurée.
Activez la protection contre la suppression pour protéger votre équilibreur de charge d'application contre la suppression.
Recommandation : La protection contre la suppression de l'équilibreur de charge d'application doit être activée
Pour corriger ce résultat, procédez comme suit :
Console AWS
Pour éviter toute suppression accidentelle de votre équilibreur de charge, vous pouvez activer la protection contre la suppression. Par défaut, la protection contre la suppression est désactivée pour votre équilibreur de charge.
Si vous activez la protection contre la suppression pour votre équilibreur de charge, vous devez la désactiver avant de pouvoir supprimer l'équilibreur de charge.
Pour activer la protection contre la suppression depuis la console.
- Ouvrez la console Amazon EC2 à l'adresse https://console.aws.amazon.com/ec2/.
- Dans le volet de navigation, sous ÉQUILIBRAGE DE CHARGE, sélectionnez Équilibreurs de charge.
- Choisissez l'équilibreur de charge.
- Dans l'onglet Description, sélectionnez Modifier les attributs.
- Sur la page Modifier les attributs de l'équilibreur de charge, sélectionnez Activer la protection contre la suppression, puis Enregistrer.
- Sélectionnez Enregistrer.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesElb Logging Enabled
Nom de la catégorie dans l'API : ELB_LOGGING_ENABLED
Cela permet de vérifier si la journalisation est activée sur l'équilibreur de charge d'application et l'équilibreur de charge classique. Le contrôle échoue si access_logs.s3.enabled est défini sur "false".
Elastic Load Balancing fournit des journaux d'accès qui capturent des informations détaillées sur les requêtes envoyées à votre équilibreur de charge. Chaque journal contient des informations telles que l'heure de réception de la requête, l'adresse IP du client, les latences, les chemins des requêtes et les réponses du serveur. Vous pouvez utiliser ces journaux d'accès pour analyser les modèles de trafic et résoudre les problèmes.
Pour en savoir plus, consultez la section Accéder aux journaux de votre équilibreur de charge classique du guide de l'utilisateur pour les équilibreurs de charge classiques.
Recommandation : Vérifie si la journalisation est activée pour les équilibreurs de charge classiques et d'application
Pour corriger ce résultat, procédez comme suit :
Console AWS
Pour résoudre ce problème, mettez à jour vos équilibreurs de charge afin d'activer la journalisation.
Pour activer les journaux d'accès :
- Ouvrez la console Amazon EC2 à l'adresse https://console.aws.amazon.com/ec2/.
- Dans le volet de navigation, sélectionnez Équilibreurs de charge.
- Choisissez un équilibreur de charge d'application ou un équilibreur de charge classique.
- Dans Actions, sélectionnez Modifier les attributs.
- Sous Journaux d'accès, sélectionnez Activer.
- Indiquez l'emplacement de votre S3. Cet établissement peut exister ou être créé pour vous. Si vous ne spécifiez pas de préfixe, les journaux d'accès sont stockés à la racine du bucket S3.
- Sélectionnez Enregistrer.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesElb Tls Https Listeners Only
Nom de la catégorie dans l'API : ELB_TLS_HTTPS_LISTENERS_ONLY
Cette vérification permet de s'assurer que tous les équilibreurs de charge classiques sont configurés pour utiliser une communication sécurisée.
Un écouteur est un processus qui vérifie l'existence de requêtes de connexion. Elle est configurée avec un protocole et un port pour les connexions d'interface (client vers équilibreur de charge), ainsi qu'un protocole et un port pour les connexions backend (équilibreur de charge vers instance). Pour en savoir plus sur les ports, les protocoles et les configurations d'écouteur compatibles avec Elastic Load Balancing, consultez la page Écouteurs de votre équilibreur de charge classique.
Recommandation : Vérifie que tous les équilibreurs de charge classiques sont configurés avec des écouteurs SSL ou HTTPS
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesEncrypted Volumes
Nom de la catégorie dans l'API : ENCRYPTED_VOLUMES
Vérifie si les volumes EBS qui sont associés sont chiffrés. Pour réussir cette vérification, les volumes EBS doivent être utilisés et chiffrés. Si le volume EBS n'est pas associé, il n'est pas soumis à cette vérification.
Pour renforcer la sécurité de vos données sensibles dans les volumes EBS, vous devez activer le chiffrement EBS au repos. Le chiffrement Amazon EBS offre une solution simple pour vos ressources EBS. Vous n'avez donc pas besoin de créer, de gérer ni de sécuriser votre propre infrastructure de gestion de clés. Il utilise des clés KMS lors de la création de volumes chiffrés et d'instantanés.
Pour en savoir plus sur le chiffrement Amazon EBS, consultez la section sur le chiffrement Amazon EBS dans le guide de l'utilisateur Amazon EC2 pour les instances Linux.
Recommandation : Les volumes Amazon EBS associés doivent être chiffrés au repos
Pour corriger ce résultat, procédez comme suit :
Console AWS
Il n'existe aucun moyen direct de chiffrer un volume ou un instantané non chiffré existant. Vous ne pouvez chiffrer un nouveau volume ou un nouvel instantané que lorsque vous le créez.
Si vous avez activé le chiffrement par défaut, Amazon EBS chiffre le nouveau volume ou l'instantané obtenu à l'aide de votre clé par défaut pour le chiffrement Amazon EBS. Même si vous n'avez pas activé le chiffrement par défaut, vous pouvez l'activer lorsque vous créez un volume ou un instantané individuel. Dans les deux cas, vous pouvez remplacer la clé par défaut pour le chiffrement Amazon EBS et choisir une clé symétrique gérée par le client.
Pour en savoir plus, consultez les pages Créer un volume Amazon EBS et Copier un instantané Amazon EBS dans le guide de l'utilisateur Amazon EC2 pour les instances Linux.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesEncryption At Rest Enabled Rds Instances
Nom de la catégorie dans l'API : ENCRYPTION_AT_REST_ENABLED_RDS_INSTANCES
Les instances de base de données chiffrées Amazon RDS utilisent l'algorithme de chiffrement AES-256, standard dans l'industrie, pour chiffrer vos données sur le serveur qui héberge vos instances de base de données Amazon RDS. Une fois vos données chiffrées, Amazon RDS gère l'authentification de l'accès et le déchiffrement de vos données de manière transparente, avec un impact minimal sur les performances.
Recommandation : Assurez-vous que le chiffrement au repos est activé pour les instances RDS
Pour corriger ce résultat, procédez comme suit :
Console AWS
- Connectez-vous à la console de gestion AWS et ouvrez le tableau de bord RDS à l'adresse https://console.aws.amazon.com/rds/.
- Dans le panneau de navigation de gauche, cliquez sur
Databases
. - Sélectionnez l'instance de base de données à chiffrer.
- Cliquez sur le bouton
Actions
situé en haut à droite et sélectionnezTake Snapshot
. - Sur la page "Prendre un instantané", saisissez le nom de la base de données dont vous souhaitez prendre un instantané dans le champ
Snapshot Name
, puis cliquez surTake Snapshot
. - Sélectionnez l'instantané que vous venez de créer, cliquez sur le bouton
Action
situé en haut à droite, puis sélectionnezCopy snapshot
dans le menu "Action". - Sur la page Créer une copie de l'instantané de base de données, procédez comme suit:
- Dans le champ "Nouvel identifiant d'instantané de base de données", saisissez un nom pour
new snapshot
. - Cochez
Copy Tags
. Le nouvel instantané doit comporter les mêmes tags que l'instantané source. - Sélectionnez
Yes
dans la liste déroulanteEnable Encryption
pour activer le chiffrement. Vous pouvez choisir d'utiliser la clé de chiffrement AWS par défaut ou la clé personnalisée dans la liste déroulante "Clé principale".
- Cliquez sur
Copy Snapshot
pour créer une copie chiffrée de l'instantané d'instance sélectionné. - Sélectionnez la nouvelle copie chiffrée de l'instantané, cliquez sur le bouton
Action
en haut à droite, puis sélectionnez le boutonRestore Snapshot
dans le menu "Action". Cela restaurera l'instantané chiffré dans une nouvelle instance de base de données. - Sur la page Restaurer l'instance de base de données, saisissez un nom unique pour la nouvelle instance de base de données dans le champ Identifiant d'instance de base de données.
- Vérifiez les détails de la configuration de l'instance, puis cliquez sur
Restore DB Instance
. - Lorsque le nouveau processus de provisionnement d'instance est terminé, vous pouvez mettre à jour la configuration de l'application pour qu'elle fasse référence au point de terminaison de la nouvelle instance de base de données chiffrée. Une fois le point de terminaison de base de données modifié au niveau de l'application, vous pouvez supprimer l'instance non chiffrée.
CLI AWS
- Exécutez la commande
describe-db-instances
pour lister tous les noms de base de données RDS disponibles dans la région AWS sélectionnée. Le résultat de la commande doit renvoyer l'identifiant de l'instance de base de données.aws rds describe-db-instances --region <region-name> --query 'DBInstances[*].DBInstanceIdentifier'
- Exécutez la commande
create-db-snapshot
afin de créer un instantané pour l'instance de base de données sélectionnée. Le résultat de la commande renvoienew snapshot
nommé "DB Snapshot Name".aws rds create-db-snapshot --region <region-name> --db-snapshot-identifier <DB-Snapshot-Name> --db-instance-identifier <DB-Name>
- À présent, exécutez la commande
list-aliases
pour lister les alias de clés KMS disponibles dans une région spécifiée. Le résultat de la commande doit renvoyer chaque valeurkey alias currently available
. Pour notre processus d'activation du chiffrement RDS, localisez l'ID de la clé KMS par défaut d'AWS.aws kms list-aliases --region <region-name>
- Exécutez la commande
copy-db-snapshot
à l'aide de l'ID de clé KMS par défaut pour les instances RDS renvoyées précédemment afin de créer une copie chiffrée de l'instantané de l'instance de base de données. Le résultat de la commande renvoieencrypted instance snapshot configuration
.aws rds copy-db-snapshot --region <region-name> --source-db-snapshot-identifier <DB-Snapshot-Name> --target-db-snapshot-identifier <DB-Snapshot-Name-Encrypted> --copy-tags --kms-key-id <KMS-ID-For-RDS>
- Exécutez la commande
restore-db-instance-from-db-snapshot
pour restaurer l'instantané chiffré créé à l'étape précédente sur une nouvelle instance de base de données. Si l'opération réussit, le résultat de la commande doit renvoyer la nouvelle configuration d'instance de base de données chiffrée.aws rds restore-db-instance-from-db-snapshot --region <region-name> --db-instance-identifier <DB-Name-Encrypted> --db-snapshot-identifier <DB-Snapshot-Name-Encrypted>
- Exécutez la commande
describe-db-instances
pour lister tous les noms de base de données RDS disponibles dans la région AWS sélectionnée. Le résultat affichera le nom d'identifiant de l'instance de base de données. Sélectionnez le nom de la base de données chiffrée que nous venons de créer.aws rds describe-db-instances --region <region-name> --query 'DBInstances[*].DBInstanceIdentifier'
- Exécutez à nouveau la commande
describe-db-instances
à l'aide de l'identifiant d'instance RDS renvoyé précédemment. Pour déterminer si l'instance de base de données sélectionnée est chiffrée, le résultat de la commande doit renvoyer l'état de chiffrementTrue
.aws rds describe-db-instances --region <region-name> --db-instance-identifier <DB-Name-Encrypted> --query 'DBInstances[*].StorageEncrypted'
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesEncryption Enabled Efs File Systems
Nom de la catégorie dans l'API : ENCRYPTION_ENABLED_EFS_FILE_SYSTEMS
Les données EFS doivent être chiffrées au repos à l'aide d'AWS KMS (Key Management Service).
Recommandation : Assurez-vous que le chiffrement est activé pour les systèmes de fichiers EFS
Pour corriger ce résultat, procédez comme suit :
Console AWS
- Connectez-vous à AWS Management Console et accédez au tableau de bord
Elastic File System (EFS)
. - Sélectionnez
File Systems
dans le panneau de navigation de gauche. - Cliquez sur le bouton
Create File System
dans le menu supérieur du tableau de bord pour lancer le processus de configuration du système de fichiers. - Sur la page de configuration
Configure file system access
, effectuez les actions suivantes. - Sélectionnez le VPC approprié dans la liste déroulante des VPC.
- Dans la section "Créer des cibles d'installation", cochez les cases de toutes les zones de disponibilité du VPC sélectionné. Il s'agit de vos cibles d'installation.
Cliquez sur
Next step
pour continuer.Procédez comme suit sur la page
Configure optional settings
.Créez
tags
pour décrire votre nouveau système de fichiers.Choisissez
performance mode
selon vos besoins.Cochez la case
Enable encryption
et choisissezaws/elasticfilesystem
dans la liste déroulante "Sélectionner une clé principale KMS" pour activer le chiffrement pour le nouveau système de fichiers à l'aide de la clé principale par défaut fournie et gérée par AWS KMS.Cliquez sur
Next step
pour continuer.Examinez les détails de la configuration du système de fichiers sur la page
review and create
, puis cliquez surCreate File System
pour créer le système de fichiers AWS EFS.Copiez les données de l'ancien système de fichiers EFS non chiffrés dans le nouveau système de fichiers chiffrés.
Supprimez le système de fichiers non chiffrés dès que la migration de vos données vers le système de fichiers chiffrés que vous venez de créer est terminée.
Modifiez la région AWS à partir de la barre de navigation et répétez l'ensemble du processus pour les autres régions AWS.
À partir de la CLI:1. Exécutez la commande describe-file-systems pour décrire les informations de configuration disponibles pour le système de fichiers (non chiffré) sélectionné (consultez la section "Audit" pour identifier la ressource appropriée):
aws efs describe-file-systems --region <region> --file-system-id <file-system-id from audit section step 2 output>
- Le résultat de la commande doit renvoyer les informations de configuration demandées.
- Pour provisionner un nouveau système de fichiers AWS EFS, vous devez générer un identifiant unique universel (UUID) afin de créer le jeton requis par la commande create-file-system. Pour créer le jeton requis, vous pouvez utiliser un UUID généré de manière aléatoire à partir de "https://www.uuidgenerator.net".
- Exécutez la commande create-file-system en utilisant le jeton unique créé à l'étape précédente.
aws efs create-file-system --region <region> --creation-token <Token (randomly generated UUID from step 3)> --performance-mode generalPurpose --encrypted
- Le résultat de la commande doit renvoyer les nouvelles métadonnées de configuration du système de fichiers.
- Exécutez la commande create-mount-target en utilisant l'ID de système de fichiers EFS nouvellement créé renvoyé à l'étape précédente en tant qu'identifiant et l'ID de la zone de disponibilité (AZ) qui représentera la cible d'installation:
aws efs create-mount-target --region <region> --file-system-id <file-system-id> --subnet-id <subnet-id>
- Le résultat de la commande doit renvoyer les métadonnées de la nouvelle cible d'installation.
- Vous pouvez maintenant installer votre système de fichiers à partir d'une instance EC2.
- Copiez les données de l'ancien système de fichiers EFS non chiffrés dans le nouveau système de fichiers chiffrés.
- Supprimez le système de fichiers non chiffré dès que la migration de vos données vers le système de fichiers chiffrés que vous venez de créer est terminée.
aws efs delete-file-system --region <region> --file-system-id <unencrypted-file-system-id>
- Modifiez la région AWS en mettant à jour l'option --region et répétez l'ensemble du processus pour les autres régions aws.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesIam Password Policy
Nom de la catégorie dans l'API : IAM_PASSWORD_POLICY
AWS propose des stratégies de mots de passe personnalisées sur votre compte AWS afin de spécifier des exigences de complexité et des périodes de rotation obligatoires pour les mots de passe de vos utilisateurs IAM. Si vous ne définissez pas de stratégie de mots de passe personnalisée, les mots de passe utilisateur IAM doivent respecter la stratégie de mots de passe AWS par défaut. Les bonnes pratiques de sécurité AWS recommandent les exigences de complexité des mots de passe suivantes:
- Exiger au moins un caractère majuscule dans le mot de passe.
- Exiger au moins une lettre minuscule dans les mots de passe
- Exiger au moins un symbole dans les mots de passe.
- Exiger au moins un chiffre dans les mots de passe.
- Le mot de passe doit comporter au moins 14 caractères.
- Exigez au moins 24 mots de passe avant de pouvoir les réutiliser.
- Exiger au moins 90 caractères avant l'expiration du mot de passe
Ce contrôle permet de vérifier toutes les exigences de la stratégie de mot de passe spécifiées.
Recommandation : Vérifie si la stratégie de mots de passe du compte pour les utilisateurs IAM répond aux exigences spécifiées
Pour corriger ce résultat, procédez comme suit :
Terraform
resource "aws_iam_account_password_policy" "strict" {
allow_users_to_change_password = true
require_uppercase_characters = true
require_lowercase_characters = true
require_symbols = true
require_numbers = true
minimum_password_length = 14
password_reuse_prevention = 24
max_password_age = 90
}
Console AWS
Pour créer une règle de mots de passe personnalisée
- Connectez-vous à la console de gestion AWS et ouvrez la console IAM sur la page https://console.aws.amazon.com/iam/.
- Dans le volet de navigation, sélectionnez "Paramètres du compte".
- Dans la section Règles relatives aux mots de passe, sélectionnez Modifier la règle relative aux mots de passe.
- Sélectionnez les options que vous souhaitez appliquer à votre stratégie de mot de passe et cliquez sur Enregistrer les modifications.
Modifier une règle de mots de passe personnalisée
- Connectez-vous à la console de gestion AWS et ouvrez la console IAM sur la page https://console.aws.amazon.com/iam/.
- Dans le volet de navigation, sélectionnez "Paramètres du compte".
- Dans la section Stratégie de mot de passe, choisissez Modifier.
- Sélectionnez les options que vous souhaitez appliquer à votre stratégie de mot de passe et cliquez sur Enregistrer les modifications.
CLI AWS
aws iam update-account-password-policy \
--allow-users-to-change-password \
--require-uppercase-characters \
--require-lowercase-characters \
--require-symbols \
--require-numbers \
--minimum-password-length 14 \
--password-reuse-prevention 24 \
--max-password-age 90
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesIam Password Policy Prevents Password Reuse
Nom de la catégorie dans l'API : IAM_PASSWORD_POLICY_PREVENTS_PASSWORD_REUSE
Les stratégies IAM relatives aux mots de passe peuvent empêcher la réutilisation d'un mot de passe donné par un même utilisateur. Il est recommandé d'empêcher la réutilisation des mots de passe dans les règles relatives aux mots de passe.
Recommandation : Assurez-vous que les stratégies IAM relatives aux mots de passe empêchent la réutilisation des mots de passe
Pour corriger ce résultat, procédez comme suit :
Console AWS
- Se connecter à la console AWS (avec les autorisations appropriées pour afficher les paramètres du compte de gestion des accès et des identités)
- Accéder au service IAM dans la console AWS
- Cliquez sur Paramètres du compte dans le volet de gauche.
- Cochez la case "Empêcher la réutilisation des mots de passe"
- Définir le nombre de mots de passe à mémoriser sur
24
CLI AWS
aws iam update-account-password-policy --password-reuse-prevention 24
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesIam Password Policy Requires Minimum Length 14 Greater
Nom de la catégorie dans l'API : IAM_PASSWORD_POLICY_REQUIRES_MINIMUM_LENGTH_14_GREATER
Les règles de mots de passe sont en partie utilisées pour renforcer les exigences de complexité des mots de passe. Les stratégies IAM de mots de passe permettent de s'assurer que le mot de passe est d'au moins une longueur donnée. Il est recommandé d'exiger une longueur minimale de 14 mots de passe dans la politique de mot de passe.
Recommandation : Assurez-vous que la stratégie de mots de passe IAM nécessite au moins 14 caractères
Pour corriger ce résultat, procédez comme suit :
Console AWS
- Se connecter à la console AWS (avec les autorisations appropriées pour afficher les paramètres du compte de gestion des accès et des identités)
- Accéder au service IAM dans la console AWS
- Cliquez sur Paramètres du compte dans le volet de gauche.
- Définissez la longueur minimale du mot de passe sur
14
. - Cliquez sur "Appliquer les règles relatives aux mots de passe".
CLI AWS
aws iam update-account-password-policy --minimum-password-length 14
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesIam Policies Allow Full Administrative Privileges Attached
Nom de la catégorie dans l'API : IAM_POLICIES_ALLOW_FULL_ADMINISTRATIVE_PRIVILEGES_ATTACHED
Les stratégies IAM sont le moyen d'accorder des droits à des utilisateurs, des groupes ou des rôles. Il est recommandé (et considéré comme un conseil de sécurité standard) d'accorder le moindre privilège, c'est-à-dire d'accorder uniquement les autorisations nécessaires pour effectuer une tâche. Déterminez ce que les utilisateurs doivent faire, puis élaborez des stratégies qui leur permettent d'effectuer uniquement ces tâches, au lieu de leur accorder des droits d'administrateur complets.
Recommandation : Assurez-vous que des stratégies IAM accordant les droits d'administrateur complets ":" ne sont pas associées
Pour corriger ce résultat, procédez comme suit :
Console AWS
Procédez comme suit pour dissocier la stratégie disposant de tous les droits d'administrateur:
- Connectez-vous à la console de gestion AWS et ouvrez la console IAM à l'adresse https://console.aws.amazon.com/iam/.
- Dans le volet de navigation, cliquez sur "Règles", puis recherchez le nom de la règle qui a été trouvée lors de l'étape d'audit.
- Sélectionnez la règle à supprimer.
- Dans le menu d'actions des règles, sélectionnez d'abord
Detach
- Sélectionnez tous les utilisateurs, groupes ou rôles auxquels cette stratégie est associée
- Cliquez sur
Detach Policy
. - Dans le menu d'actions des règles, sélectionnez
Detach
.
CLI AWS
Procédez comme suit pour dissocier la stratégie disposant des droits d'administrateur complets, comme indiqué à l'étape d'audit:
- Répertorie tous les utilisateurs, groupes et rôles IAM auxquels la stratégie gérée spécifiée est associée.
aws iam list-entities-for-policy --policy-arn <policy_arn>
- Dissociez la stratégie de tous les utilisateurs IAM:
aws iam detach-user-policy --user-name <iam_user> --policy-arn <policy_arn>
- Dissociez la stratégie de tous les groupes IAM:
aws iam detach-group-policy --group-name <iam_group> --policy-arn <policy_arn>
- Dissociez la stratégie de tous les rôles IAM:
aws iam detach-role-policy --role-name <iam_role> --policy-arn <policy_arn>
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesIam Users Receive Permissions Groups
Nom de la catégorie dans l'API : IAM_USERS_RECEIVE_PERMISSIONS_GROUPS
Les utilisateurs IAM ont accès aux services, aux fonctions et aux données via des stratégies IAM. Il existe quatre façons de définir des stratégies pour un utilisateur: 1) modifier la stratégie utilisateur directement (également appelée stratégie "inline"), 2) associer une stratégie directement à un utilisateur ; 3) ajouter l'utilisateur à un groupe IAM auquel une stratégie est associée ; 4) ajouter l'utilisateur à un groupe IAM doté d'une stratégie intégrée.
Seule la troisième implémentation est recommandée.
Recommandation : Assurez-vous que les utilisateurs IAM ne reçoivent des autorisations que via des groupes
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesIam User Group Membership Check
Nom de la catégorie dans l'API : IAM_USER_GROUP_MEMBERSHIP_CHECK
Les utilisateurs IAM doivent toujours faire partie d'un groupe IAM afin de respecter les bonnes pratiques de sécurité IAM.
Ajouter des utilisateurs à un groupe permet de partager des règles entre différents types d'utilisateurs.
Recommandation : Vérifie si les utilisateurs IAM sont membres d'au moins un groupe IAM
Pour corriger ce résultat, procédez comme suit :
Terraform
resource "aws_iam_user" "example" {
name = "test-iam-user"
path = "/users/dev/"
}
resource "aws_iam_group" "example" {
name = "Developers"
path = "/users/dev/"
}
resource "aws_iam_user_group_membership" "example" {
user = aws_iam_user.example.name
groups = [aws_iam_group.example.name]
}
Console AWS
Lorsque vous supprimez un utilisateur IAM à l'aide de la console AWS Management Console, IAM supprime automatiquement les informations suivantes:
- L'utilisateur
- Toutes les appartenances à des groupes d'utilisateurs, c'est-à-dire que l'utilisateur est supprimé de tous les groupes d'utilisateurs IAM dont il était membre
- Tout mot de passe associé à l'utilisateur
- Toute clé d'accès appartenant à l'utilisateur
- Toutes les règles intégrées intégrées à l'utilisateur (les règles appliquées à un utilisateur via des autorisations de groupe d'utilisateurs ne sont pas affectées)
Pour supprimer un utilisateur IAM:
- Connectez-vous à la console de gestion AWS et ouvrez la console IAM sur la page https://console.aws.amazon.com/iam/.
- Dans le volet de navigation, choisissez Utilisateurs, puis cochez la case à côté du nom d'utilisateur que vous souhaitez supprimer.
- En haut de la page, sélectionnez "Supprimer".
- Dans la boîte de dialogue de confirmation, saisissez le nom d'utilisateur dans le champ de saisie de texte pour confirmer la suppression de l'utilisateur.
- Sélectionnez Supprimer.
Pour ajouter un utilisateur à un groupe d'utilisateurs IAM:
- Connectez-vous à la console de gestion AWS et ouvrez la console IAM sur la page https://console.aws.amazon.com/iam/.
- Dans le volet de navigation, sélectionnez "Groupes d'utilisateurs", puis le nom du groupe.
- Sélectionnez l'onglet "Utilisateurs", puis "Ajouter des utilisateurs". Cochez la case à côté des utilisateurs que vous souhaitez ajouter.
- Sélectionnez "Ajouter des utilisateurs".
CLI AWS
Contrairement à la console de gestion Amazon Web Services, lorsque vous supprimez un utilisateur par programmation, vous devez supprimer manuellement les éléments qui lui sont associés. Sinon, la suppression échoue.
Avant d'essayer de supprimer un utilisateur, supprimez les éléments suivants:
- Mot de passe ( DeleteLoginProfile )
- Touches d'accès ( DeleteAccessKey )
- Certificat de signature ( DeleteSigningCertificate )
- Clé publique SSH ( DeleteSSHPublicKey)
- Identifiants Git ( DeleteServiceSpecificCredential )
- Appareil d'authentification multifacteur (MFA) ( DisableMFADevice , DeleteVirtualMFADevice )
- Règles intégrées ( DeleteUserPolicy )
- Règles gérées associées ( DetachUserPolicy)
- Adhésions aux groupes ( RemoveUserFromGroup)
Pour supprimer un utilisateur après avoir supprimé tous les éléments qui lui sont associés:
aws iam delete-user \
--user-name "test-user"
Pour ajouter un utilisateur IAM à un groupe IAM:
aws iam add-user-to-group \
--group-name "test-group"
--user-name "test-user"
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesIam User Mfa Enabled
Nom de la catégorie dans l'API : IAM_USER_MFA_ENABLED
L'authentification multifacteur (MFA) est une bonne pratique qui ajoute une couche de protection supplémentaire aux noms d'utilisateur et aux mots de passe. Avec la MFA, lorsqu'un utilisateur se connecte à la console de gestion AWS, il doit fournir un code d'authentification sensible au facteur temps, fourni par un appareil virtuel ou physique enregistré.
Recommandation : Vérifie si l'authentification multifacteur (MFA) est activée pour les utilisateurs IAM AWS
Pour corriger ce résultat, procédez comme suit :
Terraform
Dans Terraform, plusieurs options permettent de remédier à l'absence d'appareils MFA. Vous disposez probablement déjà d'une structure logique pour organiser vos utilisateurs en groupes et en règles restrictives.
L'exemple suivant montre comment:
- Créer des utilisateurs
- Créez des profils de connexion utilisateur avec une clé publique PGP.
- Créer une stratégie de groupe et de groupe permettant l'autogestion des profils IAM
- Associez des utilisateurs au groupe.
- Créez des appareils MFA virtuels pour vos utilisateurs.
- Fournissez à chaque utilisateur le code QR et le mot de passe de sortie.
variable "users" {
type = set(string)
default = [
"test@example.com",
"test2@example.com"
]
}
resource "aws_iam_user" "test_users" {
for_each = toset(var.users)
name = each.key
}
resource "aws_iam_user_login_profile" "test_users_profile" {
for_each = var.users
user = each.key
# Key pair created using GnuPG, this is the public key
pgp_key = file("path/to/gpg_pub_key_base64.pem")
password_reset_required = true
lifecycle {
ignore_changes = [
password_length,
password_reset_required,
pgp_key,
]
}
}
resource "aws_iam_virtual_mfa_device" "test_mfa" {
for_each = toset(var.users)
virtual_mfa_device_name = each.key
}
resource "aws_iam_group" "enforce_mfa_group" {
name = "EnforceMFAGroup"
}
resource "aws_iam_group_membership" "enforce_mfa_group_membership" {
name = "EnforceMFAGroupMembership"
group = aws_iam_group.enforce_mfa_group.name
users = [for k in aws_iam_user.test_users : k.name]
}
resource "aws_iam_group_policy" "enforce_mfa_policy" {
name = "EnforceMFAGroupPolicy"
group = aws_iam_group.enforce_mfa_group.id
policy = <<POLICY
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowViewAccountInfo",
"Effect": "Allow",
"Action": [
"iam:GetAccountPasswordPolicy",
"iam:ListVirtualMFADevices"
],
"Resource": "*"
},
{
"Sid": "AllowManageOwnPasswords",
"Effect": "Allow",
"Action": [
"iam:ChangePassword",
"iam:GetUser"
],
"Resource": "arn:aws:iam::*:user/$${aws:username}"
},
{
"Sid": "AllowManageOwnAccessKeys",
"Effect": "Allow",
"Action": [
"iam:CreateAccessKey",
"iam:DeleteAccessKey",
"iam:ListAccessKeys",
"iam:UpdateAccessKey"
],
"Resource": "arn:aws:iam::*:user/$${aws:username}"
},
{
"Sid": "AllowManageOwnSigningCertificates",
"Effect": "Allow",
"Action": [
"iam:DeleteSigningCertificate",
"iam:ListSigningCertificates",
"iam:UpdateSigningCertificate",
"iam:UploadSigningCertificate"
],
"Resource": "arn:aws:iam::*:user/$${aws:username}"
},
{
"Sid": "AllowManageOwnSSHPublicKeys",
"Effect": "Allow",
"Action": [
"iam:DeleteSSHPublicKey",
"iam:GetSSHPublicKey",
"iam:ListSSHPublicKeys",
"iam:UpdateSSHPublicKey",
"iam:UploadSSHPublicKey"
],
"Resource": "arn:aws:iam::*:user/$${aws:username}"
},
{
"Sid": "AllowManageOwnGitCredentials",
"Effect": "Allow",
"Action": [
"iam:CreateServiceSpecificCredential",
"iam:DeleteServiceSpecificCredential",
"iam:ListServiceSpecificCredentials",
"iam:ResetServiceSpecificCredential",
"iam:UpdateServiceSpecificCredential"
],
"Resource": "arn:aws:iam::*:user/$${aws:username}"
},
{
"Sid": "AllowManageOwnVirtualMFADevice",
"Effect": "Allow",
"Action": [
"iam:CreateVirtualMFADevice",
"iam:DeleteVirtualMFADevice"
],
"Resource": "arn:aws:iam::*:mfa/$${aws:username}"
},
{
"Sid": "AllowManageOwnUserMFA",
"Effect": "Allow",
"Action": [
"iam:DeactivateMFADevice",
"iam:EnableMFADevice",
"iam:ListMFADevices",
"iam:ResyncMFADevice"
],
"Resource": "arn:aws:iam::*:user/$${aws:username}"
},
{
"Sid": "DenyAllExceptListedIfNoMFA",
"Effect": "Deny",
"NotAction": [
"iam:CreateVirtualMFADevice",
"iam:EnableMFADevice",
"iam:GetUser",
"iam:ListMFADevices",
"iam:ListVirtualMFADevices",
"iam:ResyncMFADevice",
"sts:GetSessionToken"
],
"Resource": "*",
"Condition": {
"BoolIfExists": {
"aws:MultiFactorAuthPresent": "false"
}
}
}
]
}
POLICY
}
output "user_password_map" {
# Outputs a map in the format {"test@example.com": <PGPEncryptedPassword>, "test2@example.com": <PGPEncryptedPassword>}
value = { for k, v in aws_iam_user_login_profile.test_users_profile : k => v.password }
}
output "user_qr_map" {
# Outputs a map in the format {"test@example.com": <QRCode>, "test2@example.com": <QRCode>}
value = { for k, v in aws_iam_virtual_mfa_device.test_mfa : k => v.qr_code_png }
}
Console AWS
Pour activer la MFA pour tous les comptes utilisateur ayant accès à la console AWS, consultez la section Activer un appareil d'authentification multifacteur virtuel (console) dans la documentation AWS.
**
CLI AWS
Créer un appareil MFA
aws iam create-virtual-mfa-device \
--virtual-mfa-device-name "test@example.com" \
--outfile ./QRCode.png \
--bootstrap-method QRCodePNG
Activer l'appareil MFA pour l'utilisateur existant
aws iam enable-mfa-device \
--user-name "test@example.com" \
--serial-number "arn:aws:iam::123456976749:mfa/test@example.com" \
--authentication-code1 123456 \
--authentication-code2 654321
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesIam User Unused Credentials Check
Nom de la catégorie dans l'API : IAM_USER_UNUSED_CREDENTIALS_CHECK
Cette opération recherche les mots de passe IAM ou les clés d'accès actives qui n'ont pas été utilisés au cours des 90 derniers jours.
Nous vous recommandons de supprimer, de désactiver ou d'alterner tous les identifiants inutilisés pendant au moins 90 jours. Cela réduit les possibilités d'utilisation des identifiants associés à un compte compromis ou abandonné.
Recommandation : Vérifie que tous les utilisateurs AWS IAM disposent de mots de passe ou de clés d'accès actives qui n'ont pas été utilisés depuis le nombre de jours maxCredentialUsageAge (90 par défaut)
Pour corriger ce résultat, procédez comme suit :
Terraform
Pour supprimer les clés d'accès expirées créées via Terraform, supprimez la ressource aws_iam_access_key
de votre module et appliquez la modification.
Pour réinitialiser le mot de passe de connexion d'un utilisateur IAM, utilisez -replace
lorsque vous exécutez terraform apply
.
Supposons le profil de connexion utilisateur suivant :
resource "aws_iam_user" "example" {
name = "test@example.com"
path = "/users/"
force_destroy = true
}
resource "aws_iam_user_login_profile" "example" {
user = aws_iam_user.example.name
pgp_key = "keybase:some_person_that_exists"
}
Exécutez la commande suivante pour réinitialiser le mot de passe du profil de connexion de l'utilisateur :
terraform apply -replace="aws_iam_user_login_profile.example"
Console AWS
Pour désactiver les identifiants pour les comptes inactifs:
- Ouvrez la console IAM à l'adresse https://console.aws.amazon.com/iam/.
- Sélectionnez "Utilisateurs".
- Choisissez le nom de l'utilisateur dont les identifiants datent de plus de 90 jours/d'utilisation.
- Choisissez "Security credentials" (Identifiants de sécurité).
- Pour chaque identifiant de connexion et clé d'accès qui n'ont pas été utilisés depuis au moins 90 jours, sélectionnez "Rendre inactif".
Pour demander un nouveau mot de passe aux utilisateurs de la console à la prochaine connexion:
- Ouvrez la console IAM à l'adresse https://console.aws.amazon.com/iam/.
- Sélectionnez "Utilisateurs".
- Choisissez le nom de l'utilisateur dont les identifiants datent de plus de 90 jours/d'utilisation.
- Choisissez "Security credentials" (Identifiants de sécurité).
- Sous Identifiants de connexion et mot de passe de la console, sélectionnez "Gérer".
- Définissez un nouveau mot de passe (généré automatiquement ou personnalisé).
- Cochez la case Exiger la réinitialisation du mot de passe.
- Sélectionnez "Appliquer".
CLI AWS
Pour rendre les clés d'accès inactives
aws iam update-access-key \
--access-key-id <value> \
--status "Inactive"
Pour supprimer des clés d'accès
aws iam delete-access-key \
--access-key-id <value>
Pour réinitialiser le mot de passe d'un profil de connexion utilisateur
aws iam update-login-profile \
--user-name "test@example.com" \
--password <temporary_password> \
--password-reset-required
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesKms Cmk Not Scheduled For Deletion
Nom de la catégorie dans l'API : KMS_CMK_NOT_SCHEDULED_FOR_DELETION
Cette commande vérifie si la suppression des clés KMS est planifiée. Le contrôle échoue si la suppression d'une clé KMS est programmée.
Une fois supprimées, les clés KMS ne peuvent pas être récupérées. De plus, les données chiffrées à l'aide d'une clé KMS sont définitivement irrécupérables si la clé KMS est supprimée. Si des données significatives ont été chiffrées avec une clé KMS dont la suppression est planifiée, envisagez de les déchiffrer ou de les chiffrer à nouveau avec une nouvelle clé KMS, sauf si vous effectuez intentionnellement un effacement cryptographique.
Lorsque la suppression d'une clé KMS est programmée, un délai d'attente obligatoire est appliqué pour laisser le temps d'annuler la suppression en cas d'erreur. Le délai d'attente par défaut est de 30 jours, mais il peut être réduit à sept jours lorsque la suppression de la clé KMS est planifiée. Pendant ce délai, vous pouvez annuler la suppression programmée et la clé KMS ne sera pas supprimée.
Pour en savoir plus sur la suppression de clés KMS, consultez la section Supprimer des clés KMS du guide du développeur d'AWS Key Management Service.
Recommandation : Vérifie que la suppression de toutes les clés CMK n'est pas planifiée
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesLambda Concurrency Check
Nom de la catégorie dans l'API : LAMBDA_CONCURRENCY_CHECK
Vérifie si la fonction Lambda est configurée avec une limite d'exécution simultanée au niveau de la fonction. La règle est NON_COMPLIANT si la fonction Lambda n'est pas configurée avec une limite d'exécution simultanée au niveau de la fonction.
Recommandation : Vérifie si les fonctions Lambda sont configurées avec une limite d'exécution simultanée au niveau de la fonction
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesLambda Dlq Check
Nom de la catégorie dans l'API : LAMBDA_DLQ_CHECK
Vérifie si une fonction Lambda est configurée avec une file d'attente de lettres mortes. La règle est NON_COMPLIANT si la fonction Lambda n'est pas configurée avec une file d'attente de lettres mortes.
Recommandation : Vérifie si les fonctions Lambda sont configurées avec une file d'attente de lettres mortes
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesLambda Function Public Access Prohibited
Nom de la catégorie dans l'API : LAMBDA_FUNCTION_PUBLIC_ACCESS_PROHIBITED
Les bonnes pratiques d'AWS recommandent de ne pas exposer publiquement la fonction Lambda. Cette règle vérifie toutes les fonctions Lambda déployées dans toutes les régions activées de votre compte et échouera si elles sont configurées pour autoriser l'accès public.
Recommandation : Vérifie si la règle associée à la fonction Lambda interdit l'accès public
Pour corriger ce résultat, procédez comme suit :
Terraform
L'exemple suivant fournit un exemple d'utilisation de Terraform pour provisionner un rôle IAM limitant l'accès à une fonction Lambda et rattachant ce rôle à la fonction Lambda
resource "aws_iam_role" "iam_for_lambda" {
name = "iam_for_lambda"
assume_role_policy = <<EOF
{
"Version": "2012-10-17",
"Statement": [
{
"Action": "sts:AssumeRole",
"Principal": {
"Service": "lambda.amazonaws.com"
},
"Effect": "Allow",
"Sid": ""
}
]
}
EOF
}
resource "aws_lambda_function" "test_lambda" {
filename = "lambda_function_payload.zip"
function_name = "lambda_function_name"
role = aws_iam_role.iam_for_lambda.arn
handler = "index.test"
source_code_hash = filebase64sha256("lambda_function_payload.zip")
runtime = "nodejs12.x"
}
Console AWS
Si une fonction Lambda échoue à ce contrôle, cela signifie que l'instruction de stratégie basée sur les ressources pour la fonction Lambda autorise l'accès public.
Pour résoudre le problème, vous devez mettre à jour la stratégie afin de supprimer les autorisations ou d'ajouter la condition AWS:SourceAccount
. Vous ne pouvez mettre à jour la règle basée sur les ressources qu'à partir de l'API Lambda.
Les instructions suivantes utilisent la console pour examiner la stratégie et l'interface de ligne de commande AWS pour supprimer les autorisations.
Afficher la stratégie basée sur les ressources pour une fonction Lambda
- Ouvrez la console AWS Lambda à l'adresse https://console.aws.amazon.com/lambda/.
- Dans le volet de navigation, sélectionnez "Functions" (Fonctions).
- Sélectionnez la fonction.
- Sélectionnez "Autorisations". La stratégie basée sur les ressources affiche les autorisations appliquées lorsqu'un autre compte ou service AWS tente d'accéder à la fonction.
- Examinez la règle basée sur les ressources.
- Identifiez la déclaration de règle dont les valeurs du champ "Principal" rendent la règle publique. Par exemple, autoriser
"*"
ou{ "AWS": "*" }
.
Vous ne pouvez pas modifier la règle dans la console. Pour supprimer les autorisations de la fonction, utilisez la commande remove-permission à partir de la CLI AWS.
Notez la valeur de l'identifiant d'instruction (Sid) de l'instruction que vous souhaitez supprimer.
CLI AWS
Pour utiliser la CLI afin de supprimer les autorisations d'une fonction Lambda, exécutez la commande remove-permission
comme suit.
aws lambda remove-permission \
--function-name <value> \
--statement-id <value>
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesLambda Inside Vpc
Nom de la catégorie dans l'API : LAMBDA_INSIDE_VPC
Vérifie si une fonction Lambda se trouve dans un VPC. Vous verrez peut-être des résultats ayant échoué pour les ressources Lambda@Edge.
Elle n'évalue pas la configuration de routage du sous-réseau VPC pour déterminer la joignabilité publique.
Recommandation : Vérifie si les fonctions Lambda existent dans un VPC
Pour corriger ce résultat, procédez comme suit :
Console AWS
Pour configurer une fonction afin qu'elle se connecte à des sous-réseaux privés dans un cloud privé virtuel (VPC) de votre compte, procédez comme suit:
- Ouvrez la console AWS Lambda à l'adresse https://console.aws.amazon.com/lambda/.
- Accédez à "Functions" (Fonctions), puis sélectionnez votre fonction Lambda.
- Faites défiler la page jusqu'à "Réseau", puis sélectionnez un VPC répondant aux exigences de connectivité de la fonction.
- Pour exécuter vos fonctions en mode haute disponibilité, le Centre de sécurité vous recommande de choisir au moins deux sous-réseaux.
- Choisissez au moins un groupe de sécurité présentant les exigences de connectivité de la fonction.
- Sélectionnez "Enregistrer".
Pour en savoir plus, consultez la section sur la configuration d'une fonction Lambda pour accéder aux ressources d'un VPC dans le guide du développeur AWS Lambda.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesMfa Delete Enabled S3 Buckets
Nom de la catégorie dans l'API : MFA_DELETE_ENABLED_S3_BUCKETS
Une fois la suppression MFA activée sur votre bucket S3 classé et sensible, l'utilisateur doit avoir deux formes d'authentification.
Recommandation : Assurez-vous que la suppression MFA est activée sur les buckets S3
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesMfa Enabled Root User Account
Nom de la catégorie dans l'API : MFA_ENABLED_ROOT_USER_ACCOUNT
Le compte utilisateur "root" est l'utilisateur avec le plus de privilèges dans un compte AWS. L'authentification multifacteur (MFA) ajoute un niveau de protection supplémentaire en plus du nom d'utilisateur et du mot de passe. Lorsque la MFA est activée, lorsqu'un utilisateur se connecte à un site Web AWS, il est invité à saisir son nom d'utilisateur et son mot de passe, ainsi qu'un code d'authentification provenant de son appareil AWS MFA.
Remarque:Lorsque la MFA virtuelle est utilisée pour des comptes "root", il est recommandé de ne pas utiliser un appareil personnel, mais plutôt un appareil mobile dédié (tablette ou téléphone) dont la batterie reste chargée et sécurisée indépendamment de tout appareil personnel. ("MFA virtuel non personnel") Cela réduit le risque de perdre l'accès à la MFA en raison de la perte d'un appareil, d'un échange d'appareil ou si la personne qui possède l'appareil n'est plus employée dans l'entreprise.
Recommandation : Assurez-vous que la MFA est activée pour le compte utilisateur "racine"
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesMulti Factor Authentication Mfa Enabled All Iam Users Console
Nom de la catégorie dans l'API : MULTI_FACTOR_AUTHENTICATION_MFA_ENABLED_ALL_IAM_USERS_CONSOLE
L’authentification multifacteur (MFA) ajoute une couche supplémentaire de garantie d’authentification au-delà des informations d’identification traditionnelles. Lorsque la MFA est activée, lorsqu'un utilisateur se connecte à la console AWS, il sera invité à saisir son nom d'utilisateur et son mot de passe, ainsi qu'un code d'authentification à partir de son jeton MFA physique ou virtuel. Il est recommandé d'activer l'authentification MFA pour tous les comptes qui disposent d'un mot de passe de console.
Recommandation : Assurez-vous que l'authentification multifacteur (MFA) est activée pour tous les utilisateurs IAM disposant d'un mot de passe de console
Pour corriger ce résultat, procédez comme suit :
Console AWS
- Connectez-vous à la console de gestion AWS et ouvrez la console IAM à l'adresse https://console.aws.amazon.com/iam/.
- Dans le volet de gauche, sélectionnez
Users
. - Dans la liste
User Name
, choisissez le nom de l'utilisateur MFA prévu. - Sélectionnez l'onglet
Security Credentials
, puisManage MFA Device
. Dans
Manage MFA Device wizard
, sélectionnez l'appareilVirtual MFA
, puisContinue
.IAM génère et affiche les informations de configuration de l'appareil MFA virtuel, y compris un code QR. L'image est une représentation de la "clé de configuration secrète" qui peut être saisie manuellement sur les appareils non compatibles avec les codes QR.
Ouvrez votre application MFA virtuelle. (Pour obtenir la liste des applications que vous pouvez utiliser pour héberger des appareils MFA virtuels, consultez la documentation sur les applications MFA virtuelles à l'adresse https://aws.amazon.com/iam/details/mfa/#Virtual_MFA_Applications). Si l’application MFA virtuelle prend en charge plusieurs comptes (plusieurs appareils MFA virtuels), choisissez l’option permettant de créer un nouveau compte (nouvel appareil MFA virtuel).
Déterminez si l'application MFA est compatible avec les codes QR, puis effectuez l'une des opérations suivantes:
- Scannez le code QR avec l'application. Par exemple, vous pouvez sélectionner l'icône de l'appareil photo ou une option semblable à "Scanner le code", puis utiliser l'appareil photo de l'appareil pour scanner le code.
- Dans l'assistant Gérer un appareil MFA, choisissez Afficher la clé secrète pour la configuration manuelle, puis saisissez la clé de configuration secrète dans votre application MFA.
Lorsque vous avez terminé, l'appareil virtuel MFA commence à générer des mots de passe à usage unique.
Dans
Manage MFA Device wizard
, dansMFA Code 1 box
, saisissez leone-time password
qui apparaît actuellement dans l'appareil MFA virtuel. Patientez jusqu'à 30 secondes, le temps que l'appareil génère un nouveau mot de passe à usage unique. Saisissez ensuite le deuxièmeone-time password
dansMFA Code 2 box
.Cliquez sur
Assign MFA
.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesNo Network Acls Allow Ingress 0 0 0 0 Remote Server Administration
Nom de la catégorie dans l'API : NO_NETWORK_ACLS_ALLOW_INGRESS_0_0_0_0_REMOTE_SERVER_ADMINISTRATION
La fonction Network Access Control List (NACL) permet un filtrage sans état du trafic réseau entrant et sortant vers les ressources AWS. Il est recommandé qu'aucune NACL n'autorise un accès d'entrée non restreint aux ports d'administration du serveur distant, tels que SSH vers le port 22
et RDP au port 3389
, à l'aide des protocoles TDP (6), UDP (17) ou TOUS (-1)
Recommandation : Assurez-vous qu'aucune LCA réseau n'autorise le trafic d'entrée provenant de la plage 0.0.0.0/0 vers les ports d'administration du serveur distant
Pour corriger ce résultat, procédez comme suit :
Console AWS
Procédez comme suit:
- Connectez-vous à la console de gestion AWS à l'adresse https://console.aws.amazon.com/vpc/home.
- Dans le volet de gauche, cliquez sur
Network ACLs
. - Pour corriger chaque LCA réseau à corriger, procédez comme suit :
- Sélectionner la LCA du réseau
- Cliquez sur l'onglet
Inbound Rules
. - Cliquez sur
Edit inbound rules
. - Vous pouvez soit A) mettre à jour le champ "Source" en choisissant une plage autre que 0.0.0.0/0, ou B) cliquer sur
Delete
pour supprimer la règle entrante qui pose problème. - Cliquez sur
Save
.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesNo Root User Account Access Key Exists
Nom de la catégorie dans l'API : NO_ROOT_USER_ACCOUNT_ACCESS_KEY_EXISTS
Le compte utilisateur "root" est l'utilisateur avec le plus de privilèges dans un compte AWS. Les clés d'accès AWS fournissent un accès programmatique à un compte AWS donné. Il est recommandé de supprimer toutes les clés d'accès associées au compte utilisateur "root".
Recommandation : Assurez-vous qu'aucune clé d'accès n'existe pour le compte utilisateur "root"
Pour corriger ce résultat, procédez comme suit :
Console AWS
- Connectez-vous à la console de gestion AWS en tant que "root" et ouvrez la console IAM à l'adresse https://console.aws.amazon.com/iam/.
- Cliquez sur
<root_account>
en haut à droite et sélectionnezMy Security Credentials
dans la liste déroulante. - Dans la fenêtre externe, cliquez sur
Continue to Security Credentials
. - Cliquez sur
Access Keys
(ID de clé d'accès et clé d'accès secrète). - Dans la colonne
Status
(si des clés sont actives). - Cliquez sur
Delete
(Remarque: les clés supprimées ne peuvent pas être récupérées).
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesNo Security Groups Allow Ingress 0 0 0 0 Remote Server Administration
Nom de la catégorie dans l'API : NO_SECURITY_GROUPS_ALLOW_INGRESS_0_0_0_0_REMOTE_SERVER_ADMINISTRATION
Les groupes de sécurité permettent un filtrage avec état du trafic réseau entrant et sortant vers les ressources AWS. Il est recommandé qu'aucun groupe de sécurité n'autorise un accès non restreint aux ports d'administration du serveur distant, tels que SSH pour le port 22
et RDP au port 3389
, à l'aide des protocoles TDP (6), UDP (17) ou TOUS (-1).
Recommandation : Assurez-vous qu'aucun groupe de sécurité n'autorise le trafic d'entrée provenant de la plage 0.0.0.0/0 vers les ports d'administration du serveur distant
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesNo Security Groups Allow Ingress 0 Remote Server Administration
Nom de la catégorie dans l'API : NO_SECURITY_GROUPS_ALLOW_INGRESS_0_REMOTE_SERVER_ADMINISTRATION
Les groupes de sécurité permettent un filtrage avec état du trafic réseau entrant et sortant vers les ressources AWS. Il est recommandé qu'aucun groupe de sécurité n'autorise l'accès non restreint aux ports d'administration du serveur distant, tels que SSH vers le port 22
et RDP au port 3389
.
Recommandation : Assurez-vous qu'aucun groupe de sécurité n'autorise le trafic d'entrée provenant de la plage ::/0 vers les ports d'administration du serveur distant
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesOne Active Access Key Available Any Single Iam User
Nom de la catégorie dans l'API : ONE_ACTIVE_ACCESS_KEY_AVAILABLE_ANY_SINGLE_IAM_USER
Les clés d'accès sont des identifiants à long terme associés à un utilisateur IAM ou à l'utilisateur "racine" du compte AWS. Vous pouvez utiliser des clés d'accès pour signer des requêtes programmatiques vers la CLI AWS ou l'API AWS (directement ou à l'aide du SDK AWS)
Recommandation : Assurez-vous qu'une seule clé d'accès active est disponible par utilisateur IAM
Pour corriger ce résultat, procédez comme suit :
Console AWS
- Connectez-vous à AWS Management Console et accédez au tableau de bord IAM à l'adresse
https://console.aws.amazon.com/iam/
. - Dans le panneau de navigation de gauche, sélectionnez
Users
. - Cliquez sur le nom d'utilisateur IAM que vous souhaitez examiner.
- Sur la page de configuration de l'utilisateur IAM, sélectionnez l'onglet
Security Credentials
. - Dans la section
Access Keys
, choisissez une clé d'accès datant de moins de 90 jours. Il doit s'agir de la seule clé active utilisée par cet utilisateur IAM pour accéder aux ressources AWS de manière automatisée. Testez vos applications pour vous assurer que la clé d'accès choisie fonctionne. - Dans la même section
Access Keys
, identifiez vos clés d'accès non opérationnelles (autres que celle choisie) et désactivez-les en cliquant sur le lienMake Inactive
. - Si la boîte de dialogue de confirmation
Change Key Status
s'affiche, cliquez surDeactivate
pour désactiver la clé sélectionnée. - Répétez les étapes 3 à 7 pour chaque utilisateur IAM de votre compte AWS.
CLI AWS
À l'aide des informations IAM concernant l'utilisateur et la clé d'accès fournies dans le
Audit CLI
, choisissez une clé qui date de moins de 90 jours. Il doit s'agir de la seule clé active utilisée par cet utilisateur IAM pour accéder aux ressources AWS de manière automatisée. Testez vos applications pour vous assurer que la clé d'accès choisie fonctionne.Exécutez la commande
update-access-key
ci-dessous à l'aide du nom d'utilisateur IAM et des ID de clé d'accès non opérationnel pour désactiver la ou les clés inutiles. Reportez-vous à la section "Audit" pour identifier l'ID de clé d'accès inutile pour l'utilisateur IAM sélectionné.
Remarque : La commande ne renvoie aucun résultat :
aws iam update-access-key --access-key-id <access-key-id> --status Inactive --user-name <user-name>
- Pour vérifier que la paire de clés d'accès sélectionnée a bien été
deactivated
, exécutez à nouveau la commande d'auditlist-access-keys
pour cet utilisateur IAM:
aws iam list-access-keys --user-name <user-name>
- Le résultat de la commande doit exposer les métadonnées de chaque clé d'accès associée à l'utilisateur IAM. Si la ou les paires de clés non opérationnelles
Status
sont définies surInactive
, la clé a bien été désactivée et la configuration de l'accès utilisateur IAM respecte désormais cette recommandation.
- Répétez les étapes 1 à 3 pour chaque utilisateur IAM de votre compte AWS.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesPublic Access Given Rds Instance
Nom de la catégorie dans l'API : PUBLIC_ACCESS_GIVEN_RDS_INSTANCE
Assurez-vous que les instances de base de données RDS provisionnées dans votre compte AWS limitent les accès non autorisés afin de minimiser les risques de sécurité. Pour restreindre l'accès à toute instance de base de données RDS accessible publiquement, vous devez désactiver l'option "Accès public à la base de données" et mettre à jour le groupe de sécurité VPC associé à l'instance.
Recommandation : Assurez-vous qu'aucun accès public n'est accordé à l'instance RDS
Pour corriger ce résultat, procédez comme suit :
Console AWS
- Connectez-vous à la console de gestion AWS et accédez au tableau de bord RDS à l'adresse https://console.aws.amazon.com/rds/.
- Dans le panneau de navigation, dans le tableau de bord RDS, cliquez sur
Databases
. - Sélectionnez l'instance RDS que vous souhaitez mettre à jour.
- Cliquez sur
Modify
dans le menu supérieur du tableau de bord. - Dans le panneau "Modifier l'instance de base de données", sous la section
Connectivity
, cliquez surAdditional connectivity configuration
, puis définissez la valeur dePublicly Accessible
sur "Non accessible publiquement" afin de limiter l'accès public. Suivez les étapes ci-dessous pour mettre à jour les configurations de sous-réseaux: - Sélectionnez l'onglet
Connectivity and security
, puis cliquez sur la valeur de l'attribut VPC dans la sectionNetworking
. - Sélectionnez l'onglet
Details
dans le panneau inférieur du tableau de bord VPC, puis cliquez sur la valeur de l'attribut de configuration de la table de routage. - Sur la page d'informations de la table Route, sélectionnez l'onglet Routes dans le panneau inférieur du tableau de bord et cliquez sur
Edit routes
. - Sur la page "Modifier les routes", mettez à jour la destination de la cible définie sur
igw-xxxxx
, puis cliquez surSave
routes. - Dans le panneau "Modifier une instance de base de données", cliquez sur
Continue
. Dans la section "Planification des modifications", effectuez l'une des actions suivantes en fonction de vos besoins: - Sélectionnez "Appliquer" lors du prochain intervalle de maintenance planifié pour appliquer automatiquement les modifications lors de la prochaine période de maintenance planifiée.
- Sélectionnez "Appliquer immédiatement" pour appliquer immédiatement les modifications. Avec cette option, toutes les modifications en attente seront appliquées de manière asynchrone dès que possible, quel que soit l'intervalle de maintenance défini pour cette instance de base de données RDS. Notez que toute modification disponible dans la file d'attente des modifications s'applique également. Si l'une des modifications en attente nécessite un temps d'arrêt, le choix de cette option peut provoquer un temps d'arrêt inattendu pour l'application.
- Répétez les étapes 3 à 6 pour chaque instance RDS disponible dans la région actuelle.
- Modifiez la région AWS dans la barre de navigation pour répéter le processus pour d'autres régions.
CLI AWS
- Exécutez la commande
describe-db-instances
pour lister tous les identifiants de noms de base de données RDS disponibles dans la région AWS sélectionnée:
aws rds describe-db-instances --region <region-name> --query 'DBInstances[*].DBInstanceIdentifier'
- Le résultat de la commande doit renvoyer les identifiants de chaque instance de base de données.
- Exécutez la commande
modify-db-instance
pour modifier la configuration de l'instance RDS sélectionnée. Exécutez ensuite la commande suivante pour désactiver l'optionPublicly Accessible
pour les instances RDS sélectionnées. Cette commande utilise l'option "apply-immediately". Si vous voulez utiliserto avoid any downtime --no-apply-immediately flag can be used
:
aws rds modify-db-instance --region <region-name> --db-instance-identifier <db-name> --no-publicly-accessible --apply-immediately
- Le résultat de la commande doit afficher la configuration
PubliclyAccessible
sous les valeurs en attente et doit être appliquée au moment spécifié. - Il n'est actuellement pas possible de mettre à jour la destination de la passerelle Internet via la CLI AWS. Pour mettre à jour les informations sur la passerelle Internet, suivez la procédure de la console AWS.
- Répétez les étapes 1 à 5 pour chaque instance RDS provisionnée dans la région actuelle.
- Modifiez la région AWS à l'aide du filtre --region afin de répéter le processus pour d'autres régions.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesRds Enhanced Monitoring Enabled
Nom de la catégorie dans l'API : RDS_ENHANCED_MONITORING_ENABLED
La surveillance améliorée fournit des métriques en temps réel sur le système d'exploitation sur lequel l'instance RDS s'exécute, via un agent installé dans l'instance.
Pour en savoir plus, consultez Surveiller des métriques de l'OS avec la surveillance améliorée.
Recommandation : Vérifie si la surveillance améliorée est activée pour toutes les instances de base de données RDS
Pour corriger ce résultat, procédez comme suit :
Terraform
Pour remédier à ce problème, activez la surveillance améliorée sur vos instances RDS comme suit:
Créez un rôle IAM pour RDS:
resource "aws_iam_role" "rds_logging" {
name = "CustomRoleForRDSMonitoring"
assume_role_policy = jsonencode({
Version = "2012-10-17"
Statement = [
{
Action = "sts:AssumeRole"
Effect = "Allow"
Sid = "CustomRoleForRDSLogging"
Principal = {
Service = "monitoring.rds.amazonaws.com"
}
},
]
})
}
Récupérez la stratégie gérée AWS pour la surveillance RDS améliorée:
data "aws_iam_policy" "rds_logging" {
name = "AmazonRDSEnhancedMonitoringRole"
}
Associez la stratégie au rôle:
resource "aws_iam_policy_attachment" "rds_logging" {
name = "AttachRdsLogging"
roles = [aws_iam_role.rds_logging.name]
policy_arn = data.aws_iam_policy.rds_logging.arn
}
Définissez un intervalle de surveillance et un rôle de surveillance pour l'instance RDS non conforme afin d'activer la surveillance améliorée:
resource "aws_db_instance" "default" {
identifier = "test-rds"
allocated_storage = 10
engine = "mysql"
engine_version = "5.7"
instance_class = "db.t3.micro"
db_name = "mydb"
username = "foo"
password = "foobarbaz"
parameter_group_name = "default.mysql5.7"
skip_final_snapshot = true
monitoring_interval = 60
monitoring_role_arn = aws_iam_role.rds_logging.arn
}
Console AWS
Vous pouvez activer la surveillance améliorée lorsque vous créez une instance de base de données, un cluster de bases de données multi-AZ ou une instance répliquée avec accès en lecture, ou lorsque vous modifiez une instance de base de données ou un cluster de bases de données multi-AZ. Si vous modifiez une instance de base de données pour activer la surveillance améliorée, vous n'avez pas besoin de la redémarrer pour que la modification soit prise en compte.
Vous pouvez activer la surveillance améliorée dans la console RDS en effectuant l'une des actions suivantes sur la page "Bases de données" :
- Créer une instance de base de données ou un cluster de bases de données multi-AZ – Sélectionnez "Créer une base de données".
- Créer une instance répliquée avec accès en lecture – Sélectionnez "Actions", puis "Créer une instance répliquée avec accès en lecture".
- Modifier une instance de base de données ou un cluster de bases de données multi-AZ : sélectionnez "Modifier".
Activer ou désactiver la surveillance améliorée dans la console RDS
- Faites défiler la page jusqu'à "Configuration supplémentaire".
- Dans Monitoring, sélectionnez "Activer la surveillance améliorée" pour votre instance de base de données ou votre instance répliquée avec accès en lecture. Pour désactiver la surveillance améliorée, choisissez "Désactiver la surveillance améliorée".
- Définissez la propriété "Rôle Monitoring" sur le rôle IAM que vous avez créé pour permettre à Amazon RDS de communiquer avec Amazon CloudWatch Logs à votre place, ou sélectionnez "Par défaut" pour que RDS crée pour vous un rôle nommé "rds-monitoring-role".
- Définissez la propriété de précision sur l'intervalle, en secondes, entre les points où des métriques sont collectées pour votre instance de base de données ou votre instance répliquée avec accès en lecture. La propriété de précision peut être définie sur l'une des valeurs suivantes: 1, 5, 10, 15, 30 ou 60. L'actualisation la plus rapide de la console RDS est de 5 secondes. Si vous définissez le niveau de précision sur 1 seconde dans la console RDS, les métriques ne sont mises à jour que toutes les 5 secondes. Vous pouvez récupérer les mises à jour des métriques en une seconde à l'aide des journaux CloudWatch.
CLI AWS
Créez le rôle IAM RDS:
aws iam create-role \
--role-name "CustomRoleForRDSMonitoring" \
--assume-role-policy-document file://rds-assume-role.json
Associez la stratégie AmazonRDSEnhancedMonitoringRole
au rôle:
aws iam attach-role-policy \
--role-name "CustomRoleForRDSMonitoring"\
--policy-arn "arn:aws:iam::aws:policy/service-role/AmazonRDSEnhancedMonitoringRole"
Modifiez l'instance RDS pour activer la surveillance améliorée, en définissant --monitoring-interval
et --monitoring-role-arn
:
aws rds modify-db-instance \
--db-instance-identifier "test-rds" \
--monitoring-interval 30 \
--monitoring-role-arn "arn:aws:iam::<account_id>:role/CustomRoleForRDSMonitoring"
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesRds Instance Deletion Protection Enabled
Nom de la catégorie dans l'API : RDS_INSTANCE_DELETION_PROTECTION_ENABLED
L'activation de la protection contre la suppression d'instances offre un niveau de protection supplémentaire contre la suppression accidentelle de bases de données ou par une entité non autorisée.
Lorsque la protection contre la suppression est activée, une instance de base de données RDS ne peut pas être supprimée. Pour qu'une demande de suppression aboutisse, la protection contre la suppression doit être désactivée.
Recommandation : Vérifie si la protection contre la suppression est activée pour toutes les instances RDS
Pour corriger ce résultat, procédez comme suit :
Terraform
Pour corriger ce problème, définissez deletion_protection
sur true
dans la ressource aws_db_instance
.
resource "aws_db_instance" "example" {
# ... other configuration ...
deletion_protection = true
}
Console AWS
Pour activer la protection contre la suppression pour une instance de base de données RDS :
- Ouvrez la console Amazon RDS à l'adresse https://console.aws.amazon.com/rds/.
- Dans le volet de navigation, choisissez Bases de données, puis choisissez l'instance de base de données que vous souhaitez modifier.
- Sélectionnez "Modifier".
- Sous "Protection contre la suppression", sélectionnez "Activer la protection contre la suppression".
- Sélectionnez "Continuer".
- Sous "Planification des modifications", indiquez quand appliquer les modifications. Les options disponibles sont "Appliquer" lors de la prochaine période de maintenance planifiée ou "Appliquer immédiatement".
- Choisissez Modifier l'instance de base de données.
CLI AWS
Il en va de même pour la CLI AWS. Définissez --deletion-protection
comme ci-dessous.
aws rds modify-db-instance \
--db-instance-identifier = "test-rds" \
--deletion-protection
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesRds In Backup Plan
Nom de la catégorie dans l'API : RDS_IN_BACKUP_PLAN
Cette vérification permet d'évaluer si les instances de base de données Amazon RDS sont couvertes par un plan de sauvegarde. Ce contrôle échoue si une instance de base de données RDS n'est pas couverte par un plan de sauvegarde.
AWS Backup est un service de sauvegarde entièrement géré qui centralise et automatise la sauvegarde des données sur les services AWS. Avec la sauvegarde AWS, vous pouvez créer des stratégies de sauvegarde appelées "plans de sauvegarde". Vous pouvez utiliser ces plans pour définir vos exigences de sauvegarde, telles que la fréquence de sauvegarde de vos données et la durée de conservation de ces sauvegardes. L'inclusion d'instances de base de données RDS dans un plan de sauvegarde vous aide à protéger vos données contre les pertes ou les suppressions involontaires.
Recommandation : Les instances de base de données RDS doivent être couvertes par un plan de sauvegarde
Pour corriger ce résultat, procédez comme suit :
Terraform
Pour corriger ce problème, définissez backup_retention_period
sur une valeur supérieure à 7
dans la ressource aws_db_instance
.
resource "aws_db_instance" "example" {
# ... other Configuration ...
backup_retention_period = 7
}
Console AWS
Pour activer immédiatement les sauvegardes automatiques
- Ouvrez la console Amazon RDS à l'adresse https://console.aws.amazon.com/rds/.
- Dans le volet de navigation, choisissez Bases de données, puis choisissez l'instance de base de données que vous souhaitez modifier.
- Choisissez Modifier pour ouvrir la page Modifier une instance de base de données.
- Sous Durée de conservation des sauvegardes, choisissez une valeur positive non nulle (30 jours, par exemple), puis sélectionnez "Continuer".
- Sélectionnez la section "Planification des modifications" et indiquez quand appliquer les modifications. Vous pouvez choisir "Appliquer" lors de la prochaine période de maintenance planifiée ou "Appliquer immédiatement".
- Ensuite, sur la page de confirmation, choisissez Modifier une instance de base de données pour enregistrer vos modifications et activer les sauvegardes automatiques.
CLI AWS
Il en va de même pour la CLI AWS. Pour activer les sauvegardes automatiques, définissez backup-retention-period
sur une valeur supérieure à 0
(par défaut).
aws rds modify-db-instance --db-instance-identifier "test-rds" --backup-retention-period 7
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesRds Logging Enabled
Nom de la catégorie dans l'API : RDS_LOGGING_ENABLED
Cela permet de vérifier si les journaux suivants d'Amazon RDS sont activés et envoyés à CloudWatch.
Les journaux pertinents doivent être activés pour les bases de données RDS. La journalisation de la base de données fournit des dossiers détaillés des requêtes adressées à RDS. Les journaux de base de données peuvent vous aider à effectuer des audits de sécurité et d'accès, et à diagnostiquer les problèmes de disponibilité.
Recommandation : Vérifie si les journaux exportés sont activés pour toutes les instances de base de données RDS
Pour corriger ce résultat, procédez comme suit :
Terraform
resource "aws_db_instance" "example" {
# ... other configuration for MySQL ...
enabled_cloudwatch_logs_exports = ["audit", "error", "general", "slowquery"]
parameter_group_name = aws_db_parameter_group.example.name
}
resource "aws_db_parameter_group" "example" {
name = "${aws_db_instance.example.dbInstanceIdentifier}-parameter-group"
family = "mysql5.7"
parameter {
name = "general_log"
value = 1
}
parameter {
name = "slow_query_log"
value = 1
}
parameter {
name = "log_output"
value = "FILE"
}
}
Pour MariaDB, créez également un groupe d'options personnalisé et définissez option_group_name
dans la ressource aws_db_instance
.
resource "aws_db_instance" "example" {
# ... other configuration for MariaDB ...
enabled_cloudwatch_logs_exports = ["audit", "error", "general", "slowquery"]
parameter_group_name = aws_db_parameter_group.example.name
option_group_name = aws_db_option_group.example.name
}
resource "aws_db_option_group" "example" {
name = "mariadb-option-group-for-logs"
option_group_description = "MariaDB Option Group for Logs"
engine_name = "mariadb"
option {
option_name = "MARIADB_AUDIT_PLUGIN"
option_settings {
name = "SERVER_AUDIT_EVENTS"
value = "CONNECT,QUERY,TABLE,QUERY_DDL,QUERY_DML,QUERY_DCL"
}
}
}
Console AWS
Pour créer un groupe de paramètres de base de données personnalisé
- Ouvrez la console Amazon RDS à l'adresse https://console.aws.amazon.com/rds/.
- Dans le volet de navigation, sélectionnez "Groupes de paramètres".
- Sélectionnez "Créer un groupe de paramètres".
- Dans la liste "Famille de groupes de paramètres", choisissez une famille de groupes de paramètres de base de données.
- Dans la liste Type, sélectionnez DB Parameter Group.
- Dans "Nom du groupe", saisissez le nom du nouveau groupe de paramètres de base de données.
- Dans "Description", saisissez une description pour le nouveau groupe de paramètres de base de données.
- Sélectionnez "Créer".
Créer un groupe d'options pour la journalisation MariaDB à l'aide de la console
- Ouvrez la console Amazon RDS à l'adresse https://console.aws.amazon.com/rds/.
- Dans le volet de navigation, sélectionnez "Groupes d'options".
- Sélectionnez "Créer un groupe".
- Dans la fenêtre "Créer un groupe d'options", fournissez les informations suivantes:
- Le nom doit être unique dans votre compte AWS. Seuls les lettres, les chiffres et les traits d'union sont acceptés.
- Description: utilisée uniquement à des fins d'affichage.
- Moteur: sélectionnez votre moteur de base de données.
- Version majeure du moteur: sélectionnez la version majeure de votre moteur de base de données.
- Sélectionnez "Créer".
- Choisissez le nom du groupe d'options que vous venez de créer.
- Sélectionnez une option "Ajouter".
- Sélectionnez MARIADB_AUDIT_PLUGIN dans la liste des noms d'options.
- Définissez SERVER_AUDIT_Events sur CONNECT, QUERY, TABLE, QUERY_DDL, QUERY_DML et QUERY_DCL.
- Sélectionnez une option "Ajouter".
Pour publier des journaux de base de données SQL Server, Oracle DB ou PostgreSQL dans les journaux CloudWatch à partir de la console de gestion AWS
- Ouvrez la console Amazon RDS à l'adresse https://console.aws.amazon.com/rds/.
- Dans le volet de navigation, choisissez Bases de données.
- Choisissez l'instance de base de données que vous souhaitez modifier.
- Sélectionnez "Modifier".
- Sous "Exportations de journaux", choisissez tous les fichiers journaux pour commencer à publier dans les journaux CloudWatch.
- Les exportations de journaux ne sont disponibles que pour les versions de moteur de base de données compatibles avec la publication dans les journaux CloudWatch.
- Sélectionnez "Continuer". Ensuite, sur la page de résumé, choisissez Modifier une instance de base de données.
Pour appliquer un nouveau groupe de paramètres de base de données ou un nouveau groupe d'options de base de données à une instance de base de données RDS
- Ouvrez la console Amazon RDS à l'adresse https://console.aws.amazon.com/rds/.
- Dans le volet de navigation, choisissez Bases de données.
- Choisissez l'instance de base de données que vous souhaitez modifier.
- Sélectionnez "Modifier".
- Sous Options de base de données, modifiez le groupe de paramètres de base de données et le groupe d'options de base de données selon vos besoins.
- Une fois les modifications effectuées, cliquez sur "Continuer". Vérifiez le récapitulatif des modifications.
- Choisissez Modifier l'instance de base de données pour enregistrer vos modifications.
CLI AWS
Récupérez les familles de moteurs et choisissez celle qui correspond au moteur et à la version de l'instance de base de données.
aws rds describe-db-engine-versions \
--query "DBEngineVersions[].DBParameterGroupFamily" \
--engine "mysql"
Créez un groupe de paramètres en fonction du moteur et de la version.
aws rds create-db-parameter-group \
--db-parameter-group-name "rds-mysql-parameter-group" \
--db-parameter-group-family "mysql5.7" \
--description "Example parameter group for logs"
Créez un fichier rds-parameters.json
contenant les paramètres nécessaires selon le moteur de base de données. Cet exemple utilise MySQL5.7.
[
{
"ParameterName": "general_log",
"ParameterValue": "1",
"ApplyMethod": "immediate"
},
{
"ParameterName": "slow_query_log",
"ParameterValue": "1",
"ApplyMethod": "immediate"
},
{
"ParameterName": "log_output",
"ParameterValue": "FILE",
"ApplyMethod": "immediate"
}
]
Modifiez le groupe de paramètres pour ajouter les paramètres en fonction du moteur de base de données. Cet exemple utilise MySQL 5.7
aws rds modify-db-parameter-group \
--db-parameter-group-name "rds-mysql-parameter-group" \
--parameters file://rds-parameters.json
Modifiez l'instance de base de données pour associer le groupe de paramètres.
aws rds modify-db-instance \
--db-instance-identifier "test-rds" \
--db-parameter-group-name "rds-mysql-parameter-group"
De plus, pour MariaDB, créez un groupe d'options comme suit.
aws rds create-option-group \
--option-group-name "rds-mariadb-option-group" \
--engine-name "mariadb" \
--major-engine-version "10.6" \
--option-group-description "Option group for MariaDB logs"
Créez un fichier rds-mariadb-options.json
comme suit.
{
"OptionName": "MARIADB_AUDIT_PLUGIN",
"OptionSettings": [
{
"Name": "SERVER_AUDIT_EVENTS",
"Value": "CONNECT,QUERY,TABLE,QUERY_DDL,QUERY_DML,QUERY_DCL"
}
]
}
Ajoutez l'option au groupe d'options.
aws rds add-option-to-option-group \
--option-group-name "rds-mariadb-option-group" \
--options file://rds-mariadb-options.json
Associez le groupe d'options à l'instance de base de données en modifiant l'instance MariaDB.
aws rds modify-db-instance \
--db-instance-identifier "rds-test-mariadb" \
--option-group-name "rds-mariadb-option-group"
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesRds Multi Az Support
Nom de la catégorie dans l'API : RDS_MULTI_AZ_SUPPORT
Les instances de base de données RDS doivent être configurées pour plusieurs zones de disponibilité. Cela garantit la disponibilité des données stockées. Les déploiements avec plusieurs zones de disponibilité permettent un basculement automatisé en cas de problème de disponibilité dans la zone de disponibilité et lors de la maintenance régulière des services RDS.
Recommandation : Vérifie si la haute disponibilité est activée pour toutes les instances de base de données RDS
Pour corriger ce résultat, procédez comme suit :
Terraform
Pour corriger ce problème, définissez multi_az
sur "true" dans la ressource aws_db_instance
.
resource "aws_db_instance" "example" {
# ... other configuration ...
multi_az = true
}
Console AWS
Pour activer plusieurs zones de disponibilité pour une instance de base de données
- Ouvrez la console Amazon RDS à l'adresse https://console.aws.amazon.com/rds/.
- Dans le volet de navigation, choisissez Bases de données, puis choisissez l'instance de base de données que vous souhaitez modifier.
- Sélectionnez "Modifier". La page Modifier une instance de base de données s'affiche.
- Sous "Spécifications de l'instance", définissez le déploiement multi-AZ sur "Oui".
- Choisissez Continuer , puis vérifiez le récapitulatif des modifications.
- (Facultatif) Sélectionnez "Appliquer immédiatement" pour appliquer immédiatement les modifications. Choisir cette option peut provoquer une indisponibilité dans certains cas. Pour plus d'informations, consultez l'article Utilisation du paramètre "Appliquer immédiatement" du guide de l'utilisateur d'Amazon RDS.
- Sur la page de confirmation, examinez vos modifications. Si elles sont correctes, cliquez sur Modifier l'instance de base de données pour enregistrer vos modifications.
CLI AWS
Il en va de même pour la CLI AWS. Activez la prise en charge de plusieurs Az en fournissant l'option --multi-az
.
modify-db-instance
--db-instance-identifier "test-rds" \
--multi-az
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesRedshift Cluster Configuration Check
Nom de la catégorie dans l'API : REDSHIFT_CLUSTER_CONFIGURATION_CHECK
Cela permet de vérifier les éléments essentiels d'un cluster Redshift: le chiffrement au repos, la journalisation et le type de nœud.
Ces éléments de configuration sont importants pour la maintenance d'un cluster Redshift observable et sécurisé.
Recommandation : Vérifie que tous les clusters Redshift utilisent le chiffrement au repos, la journalisation et le type de nœud.
Pour corriger ce résultat, procédez comme suit :
Terraform
resource "aws_kms_key" "redshift_encryption" {
description = "Used for Redshift encryption configuration"
enable_key_rotation = true
}
resource "aws_redshift_cluster" "example" {
# ... other configuration ...
encrypted = true
kms_key_id = aws_kms_key.redshift_encryption.id
logging {
enable = true
log_destination_type = "cloudwatch"
log_exports = ["connectionlog", "userlog", "useractivitylog"]
}
}
Console AWS
Pour activer la journalisation d'audit du cluster :
- Ouvrez la console Amazon Redshift à l'adresse https://console.aws.amazon.com/redshift/.
- Dans le menu de navigation, choisissez Clusters, puis choisissez le nom du cluster à modifier.
- Sélectionnez "Propriétés".
- Sélectionnez "Modifier et modifier les journaux d'audit".
- Définissez "Configurer les journaux d'audit" sur "Activer", définissez le type d'exportation de journaux sur CloudWatch (recommandé) et choisissez les journaux à exporter.
Pour utiliser AWS S3 afin de gérer les journaux d'audit Redshift, consultez la page Redshift – Database audit logging (Journalisation d'audit de base de données) dans la documentation AWS.
- Sélectionnez "Enregistrer les modifications".
Pour modifier le chiffrement d'une base de données sur un cluster
- Connectez-vous à la console de gestion AWS et ouvrez la console Amazon Redshift à l'adresse https://console.aws.amazon.com/redshift/.
- Dans le menu de navigation, sélectionnez Clusters, puis le cluster dont vous souhaitez modifier le chiffrement.
- Sélectionnez "Propriétés".
- Sélectionnez "Modifier" et "Modifier le chiffrement".
Choisissez le chiffrement à utiliser (KMS ou HSM) et indiquez:
- Pour KMS: clé à utiliser
- Pour HSM: connexion et certificat client
CLI AWS
- Créer une clé KMS et récupérer l'ID de clé
aws kms create-key \
--description "Key to encrypt Redshift Clusters"
- Modifier le cluster
aws redshift modify-cluster \
--cluster-identifiers "test-redshift-cluster" \
--encrypted \
--kms-key-id <value>
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesRedshift Cluster Maintenancesettings Check
Nom de la catégorie dans l'API : REDSHIFT_CLUSTER_MAINTENANCESETTINGS_CHECK
Les mises à niveau automatiques des versions majeures ont lieu en fonction de l'intervalle de maintenance
Recommandation : Vérifie que allowVersionUpgrade est activé sur tous les clusters Redshift et que les paramètres PreferredMaintenanceWindow et AutomaticSnapshottenantPeriod sont définis.
Pour corriger ce résultat, procédez comme suit :
Terraform
Cette vérification est conforme à toutes les valeurs par défaut fournies par Terraform. En cas d'échec d'un cluster Redshift, examinez les exigences et supprimez les forçages par défaut pour les attributs suivants de la ressource aws_redshift_cluster
.
resource "aws_redshift_cluster" "example" {
# ...other configuration ...
# The following values are compliant and set by default if omitted.
allow_version_upgrade = true
preferred_maintenance_window = "sat:10:00-sat:10:30"
automated_snapshot_retention_period = 1
}
Console AWS
Lors de la création d'un cluster Redshift via la console AWS, les valeurs par défaut sont déjà conformes à cette commande.
Pour en savoir plus, consultez la page Gérer des clusters à l'aide de la console.
CLI AWS
Pour corriger ce contrôle à l'aide de la CLI AWS, procédez comme suit:
aws redshift modify-cluster \
--cluster-identifier "test-redshift-cluster" \
--allow-version-upgrade
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesRedshift Cluster Public Access Check
Nom de la catégorie dans l'API : REDSHIFT_CLUSTER_PUBLIC_ACCESS_CHECK
L'attribut "PubliclyAccessible" (Accès public) de la configuration du cluster Amazon Redshift indique si le cluster est accessible publiquement. Lorsque le cluster est configuré avec PubliclyAccessible défini sur "true", il s'agit d'une instance Web dont le nom DNS peut être résolu publiquement et qui est associé à une adresse IP publique.
Lorsque le cluster n'est pas accessible publiquement, il s'agit d'une instance interne dont le nom DNS résout une adresse IP privée. À moins que vous n'ayez l'intention de rendre votre cluster accessible publiquement, ne le configurez pas en définissant PubliclyAccessible sur "true".
Recommandation : Vérifie si les clusters Redshift sont accessibles publiquement
Pour corriger ce résultat, procédez comme suit :
Terraform
Pour corriger ce contrôle, vous devez modifier la ressource de cluster de décalage rouge et définir publicly_accessible
sur false
. La valeur par défaut est true
.
resource "aws_redshift_cluster" "example" {
# ... other configuration ...
publicly_accessible = false
}
Console AWS
Pour désactiver l'accès public à un cluster Amazon Redshift
- Ouvrez la console Amazon Redshift à l'adresse https://console.aws.amazon.com/redshift/.
- Dans le menu de navigation, choisissez "Clusters", puis choisissez le nom du cluster avec le groupe de sécurité à modifier.
- Sélectionnez "Actions", puis "Modifier le paramètre d'accès public".
- Sous "Autoriser les instances et les appareils en dehors du VPC à se connecter à votre base de données via le point de terminaison du cluster", sélectionnez "Non".
- Sélectionnez "Confirmer".
CLI AWS
Exécutez la commande modify-cluster
pour définir --no-publicly-accessible
.
aws redshift modify-cluster \
--cluster-identifier "test-redshift-cluster" \
--no-publicly-accessible
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesRestricted Common Ports
Nom de la catégorie dans l'API : RESTRICTED_COMMON_PORTS
Cela permet de vérifier si le trafic entrant sans restriction pour les groupes de sécurité est accessible aux ports spécifiés qui présentent le risque le plus élevé. Ce contrôle échoue si l'une des règles d'un groupe de sécurité autorise le trafic entrant provenant de "0.0.0.0/0" ou "::/0" pour ces ports.
L’accès non restreint (0.0.0.0/0) augmente les possibilités d’activités malveillantes, telles que le piratage, les attaques par déni de service et la perte de données.
Les groupes de sécurité permettent un filtrage avec état du trafic réseau entrant et sortant vers les ressources AWS. Aucun groupe de sécurité ne doit autoriser un accès d'entrée non restreint aux ports suivants:
- 20, 21 (FTP)
- 22 (SSH)
- 23 (Telnet)
- 25 (SMTP)
- 110 (POP3)
- 135 (RPC)
- 143 (IMAP)
- 445 (CIFS)
- 1433, 1434 (MSSQL)
- 3000 (frameworks de développement Web Go, Node.js et Ruby)
- 3306 (mySQL)
- 3389 (RDP)
- 4333 (APS)
- 5000 (frameworks de développement Web Python)
- 5432 (postgresql)
- 5500 (fcp-addr-srvr1)
- 5601 (Tableaux de bord OpenSearch)
- 8080 (proxy)
- 8088 (ancien port HTTP)
- 8888 (port HTTP alternatif)
- 9200 ou 9300 (OpenSearch)
Recommandation : Les groupes de sécurité ne doivent pas autoriser un accès sans restriction aux ports présentant un risque élevé
Pour corriger ce résultat, procédez comme suit :
Console AWS
Pour supprimer une règle de groupe de sécurité:
- Ouvrez la console Amazon EC2 à l'adresse https://console.aws.amazon.com/ec2/.
- Dans le volet de navigation, sélectionnez "Groupes de sécurité".
- Sélectionnez le groupe de sécurité à mettre à jour, choisissez "Actions", puis "Modifier les règles entrantes" pour supprimer une règle entrante ou "Modifier les règles sortantes" pour supprimer une règle sortante.
- Cliquez sur le bouton Supprimer à droite de la règle à supprimer.
- Choisissez "Prévisualiser les modifications", puis "Confirmer".
Pour savoir comment supprimer des règles d'un groupe de sécurité, consultez Supprimer les règles d'un groupe de sécurité dans le guide de l'utilisateur Amazon EC2 pour les instances Linux.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesRestricted Ssh
Nom de la catégorie dans l'API : RESTRICTED_SSH
Les groupes de sécurité permettent un filtrage avec état du trafic réseau entrant et sortant vers les ressources AWS.
Le CIS recommande qu'aucun groupe de sécurité n'autorise l'accès d'entrée non restreint au port 22. La suppression d'une connectivité sans entrave aux services de console à distance, tels que SSH, réduit l'exposition d'un serveur aux risques.
Recommandation : Les groupes de sécurité ne doivent pas autoriser le trafic d'entrée provenant de 0.0.0.0/0 vers le port 22
Pour corriger ce résultat, procédez comme suit :
Console AWS
Procédez comme suit pour chaque groupe de sécurité associé à un VPC.
Ouvrez la console Amazon VPC à l'adresse https://console.aws.amazon.com/vpc/.
- Dans le volet de gauche, sélectionnez Groupes de sécurité.
- Sélectionnez un groupe de sécurité.
- Dans la section inférieure de la page, sélectionnez l'onglet Règles entrantes.
- Sélectionnez Modifier les règles.
- Identifiez la règle qui autorise l'accès via le port 22, puis cliquez sur X pour la supprimer.
- Sélectionnez Enregistrer les règles.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesRotation Customer Created Cmks Enabled
Nom de la catégorie dans l'API : ROTATION_CUSTOMER_CREATED_CMKS_ENABLED
Vérifie si la rotation automatique des clés est activée pour chaque clé et correspond à l'ID de clé de la clé KMS AWS créée par le client. La règle est NON_COMPLIANT si le rôle "Enregistreur" d'AWS Config associé à une ressource ne dispose pas de l'autorisation kms:describeKey.
Recommandation : Assurez-vous que la rotation des clés CMK créées par le client est activée
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesRotation Customer Created Symmetric Cmks Enabled
Nom de la catégorie dans l'API : ROTATION_CUSTOMER_CREATED_SYMMETRIC_CMKS_ENABLED
AWS Key Management Service (KMS) permet aux clients d'alterner la clé de support, qui est le matériel de clé stocké dans le service de gestion des clés et qui est lié à l'ID de clé de la clé principale (CMK, Customer Created Customer) créée par le client). Il s'agit de la clé de support utilisée pour effectuer des opérations cryptographiques telles que le chiffrement et le déchiffrement. Actuellement, la rotation automatique des clés permet de conserver toutes les clés de support antérieures afin que le déchiffrement des données chiffrées ait lieu de manière transparente. Il est recommandé d'activer la rotation des clés CMK pour les clés symétriques. La rotation des clés ne peut pas être activée pour les clés CMK asymétriques.
Recommandation : S'assurer que la rotation des clés CMK symétriques créées par le client est activée
Pour corriger ce résultat, procédez comme suit :
Console AWS
- Connectez-vous à la console de gestion AWS et ouvrez la console IAM à l'adresse https://console.aws.amazon.com/iam.
- Dans le volet de navigation de gauche, sélectionnez
Customer managed keys
. - Sélectionnez une clé CMK gérée par le client pour laquelle
Key spec = SYMMETRIC_DEFAULT
- Sous le panneau "Configuration générale", ouvrez l'onglet "Rotation des clés".
- Cochez la case "Alterner automatiquement cette clé KMS tous les ans".
CLI AWS
- Exécutez la commande suivante pour activer la rotation des clés:
aws kms enable-key-rotation --key-id <kms_key_id>
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesRouting Tables Vpc Peering Are Least Access
Nom de la catégorie dans l'API : ROUTING_TABLES_VPC_PEERING_ARE_LEAST_ACCESS
Vérifie si les tables de routage pour l'appairage de VPC sont configurées avec le compte principal ayant le moindre privilège.
Recommandation : Assurez-vous que les tables de routage pour l'appairage de VPC offrent le niveau d'accès le moins élevé
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesS3 Account Level Public Access Blocks
Nom de la catégorie dans l'API : S3_ACCOUNT_LEVEL_PUBLIC_ACCESS_BLOCKS
Amazon S3 Block Public Access fournit des paramètres pour les points d'accès, les buckets et les comptes afin de vous aider à gérer l'accès public aux ressources Amazon S3. Par défaut, les nouveaux buckets, points d'accès et objets n'autorisent pas l'accès public.
Recommandation : Vérifie si les paramètres de blocage de l'accès public S3 requis sont configurés au niveau du compte
Pour corriger ce résultat, procédez comme suit :
Terraform
La ressource Terraform suivante configure l'accès au niveau du compte S3.
resource "aws_s3_account_public_access_block" "s3_control" {
block_public_acls = true
block_public_policy = true
ignore_public_acls = true
restrict_public_buckets = true
}
Console AWS
Permet de modifier les paramètres de blocage de l'accès public pour tous les buckets S3 d'un compte AWS.
- Connectez-vous à la console de gestion AWS et ouvrez la console Amazon S3 à l'adresse https://console.aws.amazon.com/s3/.
- Sélectionnez les paramètres de blocage de l'accès public pour ce compte.
- Sélectionnez "Edit" (Modifier) pour modifier les paramètres de blocage de l'accès public pour tous les buckets de votre compte AWS.
- Choisissez les paramètres que vous souhaitez modifier, puis cliquez sur "Enregistrer les modifications".
- Lorsque vous êtes invité à confirmer l'opération, saisissez "confirm" (confirmer). Sélectionnez ensuite "Confirmer" pour enregistrer les modifications.
CLI AWS
aws s3control put-public-access-block \
--account-id <value> \
--public-access-block-configuration '{"BlockPublicAcls": true, "BlockPublicPolicy": true, "IgnorePublicAcls": true, "RestrictPublicBuckets": true}'
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesS3 Bucket Logging Enabled
Nom de la catégorie dans l'API : S3_BUCKET_LOGGING_ENABLED
La fonctionnalité de journalisation de l'accès au serveur AWS S3 enregistre les requêtes d'accès aux buckets de stockage, ce qui est utile pour les audits de sécurité. Par défaut, la journalisation de l'accès au serveur n'est pas activée pour les buckets S3.
Recommandation : Vérifie si la journalisation est activée sur tous les buckets S3
Pour corriger ce résultat, procédez comme suit :
Terraform
L'exemple suivant montre comment créer deux buckets:
- Un bucket de journalisation
- Un bucket conforme
variable "bucket_acl_map" {
type = map(any)
default = {
"logging-bucket" = "log-delivery-write"
"compliant-bucket" = "private"
}
}
resource "aws_s3_bucket" "all" {
for_each = var.bucket_acl_map
bucket = each.key
object_lock_enabled = true
tags = {
"Pwd" = "s3"
}
}
resource "aws_s3_bucket_acl" "private" {
for_each = var.bucket_acl_map
bucket = each.key
acl = each.value
}
resource "aws_s3_bucket_versioning" "enabled" {
for_each = var.bucket_acl_map
bucket = each.key
versioning_configuration {
status = "Enabled"
}
}
resource "aws_s3_bucket_logging" "enabled" {
for_each = var.bucket_acl_map
bucket = each.key
target_bucket = aws_s3_bucket.all["logging-bucket"].id
target_prefix = "log/"
}
resource "aws_s3_bucket_server_side_encryption_configuration" "example" {
for_each = var.bucket_acl_map
bucket = each.key
rule {
apply_server_side_encryption_by_default {
sse_algorithm = "aws:kms"
}
}
}
Console AWS
Pour en savoir plus sur l'activation de la journalisation des accès S3 via la console AWS, consultez la section Activer la journalisation des accès au serveur Amazon S3 dans la documentation AWS.
CLI AWS
L'exemple suivant montre comment:
- Créez une règle de bucket pour accorder au compte principal du service de journalisation l'autorisation
PutObject
dans votre bucket de journalisation.
policy.json
javascript
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "S3ServerAccessLogsPolicy",
"Effect": "Allow",
"Principal": {"Service": "logging.s3.amazonaws.com"},
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::MyBucket/Logs/*",
"Condition": {
"ArnLike": {"aws:SourceARN": "arn:aws:s3:::SOURCE-BUCKET-NAME"},
"StringEquals": {"aws:SourceAccount": "SOURCE-AWS-ACCOUNT-ID"}
}
}
]
}
aws s3api put-bucket-policy \
--bucket my-bucket
--policy file://policy.json
- Appliquer la règle à votre bucket de journaux
logging.json
javascript
{
"LoggingEnabled": {
"TargetBucket": "MyBucket",
"TargetPrefix": "Logs/"
}
}
aws s3api put-bucket-logging \
--bucket MyBucket \
--bucket-logging-status file://logging.json
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesS3 Bucket Policy Set Deny Http Requests
Nom de la catégorie dans l'API : S3_BUCKET_POLICY_SET_DENY_HTTP_REQUESTS
Au niveau du bucket Amazon S3, vous pouvez configurer des autorisations via une stratégie de bucket qui rend les objets accessibles uniquement via HTTPS.
Recommandation : Assurez-vous que la stratégie de bucket S3 est définie pour refuser les requêtes HTTP
Pour corriger ce résultat, procédez comme suit :
Console AWS
- Connectez-vous à AWS Management Console et ouvrez la console Amazon S3 à l'adresse https://console.aws.amazon.com/s3/.
- Cochez la case à côté du bucket.
- Cliquez sur "Autorisations".
- Cliquez sur "Stratégie du bucket".
- Ajoutez cet élément au règlement existant en renseignant les informations requises
{ "Sid": <optional>", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "arn:aws:s3:::<bucket_name>/*", "Condition": { "Bool": { "aws:SecureTransport": "false" } } }
- Enregistrer
- Répétez l'opération pour tous les buckets de votre compte AWS qui contiennent des données sensibles.
Depuis la console
à l'aide de AWS Policy Generator:
- Répétez les étapes 1 à 4 ci-dessus.
- Cliquez sur
Policy Generator
en bas de l'éditeur de stratégie de bucket. - Sélectionnez le type de règle
S3 Bucket Policy
. - Ajouter des instructions
Effect
= RefuserPrincipal
= *AWS Service
= Amazon S3Actions
= *Amazon Resource Name
=- Générer une règle
- Copiez le texte et ajoutez-le à la stratégie de bucket.
CLI AWS
Exportez la stratégie du bucket vers un fichier JSON.
aws s3api get-bucket-policy --bucket <bucket_name> --query Policy --output text > policy.json
Modifiez le fichier policy.json en ajoutant cette instruction:
{
"Sid": <optional>",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": "arn:aws:s3:::<bucket_name>/*",
"Condition": {
"Bool": {
"aws:SecureTransport": "false"
}
}
}
- Appliquez cette stratégie modifiée au bucket S3:
aws s3api put-bucket-policy --bucket <bucket_name> --policy file://policy.json
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesS3 Bucket Replication Enabled
Nom de la catégorie dans l'API : S3_BUCKET_REPLICATION_ENABLED
Cette commande vérifie si la réplication interrégionale est activée sur un bucket Amazon S3. Le contrôle échoue si la réplication interrégionale n'est pas activée sur le bucket ou si la réplication dans la même région est également activée.
La réplication est la copie automatique et asynchrone d'objets entre des buckets situés dans la même région AWS ou dans des régions différentes. La réplication copie les objets nouvellement créés et les mises à jour d'objets d'un bucket source vers un ou plusieurs buckets de destination. Les bonnes pratiques d'AWS recommandent la réplication pour les buckets sources et de destination qui appartiennent au même compte AWS. En plus de la disponibilité, vous devez envisager d'autres paramètres de renforcement du système.
Recommandation : Vérifie si la réplication interrégionale est activée sur les buckets S3
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesS3 Bucket Server Side Encryption Enabled
Nom de la catégorie dans l'API : S3_BUCKET_SERVER_SIDE_ENCRYPTION_ENABLED
Cela permet de vérifier que le chiffrement par défaut Amazon S3 est activé sur votre bucket S3, ou que la stratégie de bucket S3 refuse explicitement les requêtes d'objet put-object sans chiffrement côté serveur.
Recommandation : Assurez-vous que tous les buckets S3 utilisent le chiffrement au repos
Pour corriger ce résultat, procédez comme suit :
Terraform
resource "aws_s3_bucket_server_side_encryption_configuration" "enable" {
bucket = "my-bucket"
rule {
apply_server_side_encryption_by_default {
sse_algorithm = "AES256"
}
}
}
Console AWS
Activer le chiffrement par défaut sur un bucket S3
- Ouvrez la console Amazon S3 à l'adresse https://console.aws.amazon.com/s3/.
- Dans le volet de navigation de gauche, sélectionnez "Buckets".
- Sélectionnez le bucket S3 dans la liste.
- Sélectionnez "Propriétés".
- Sélectionnez Chiffrement par défaut.
- Pour le chiffrement, choisissez AES-256 ou AWS-KMS.
- Choisissez AES-256 pour utiliser des clés gérées par Amazon S3 comme chiffrement par défaut. Pour en savoir plus sur le chiffrement des données à l'aide d'Amazon S3 côté serveur, consultez le Guide de l'utilisateur d'Amazon Simple Storage Service.
- Choisissez AWS-KMS pour utiliser des clés gérées par AWS KMS pour le chiffrement par défaut. Ensuite, sélectionnez une clé principale dans la liste des clés principales AWS KMS que vous avez créées.
- Saisissez le nom de ressource Amazon (ARN) de la clé KMS AWS à utiliser. Vous trouverez l'ARN de votre clé KMS AWS dans la console IAM, sous "Clés de chiffrement". Vous pouvez également choisir un nom de clé dans la liste déroulante.
- Important: Si vous utilisez l'option AWS KMS pour votre configuration de chiffrement par défaut, vous êtes soumis aux quotas RPS (requêtes par seconde) d'AWS KMS. Pour en savoir plus sur les quotas AWS KMS et sur la procédure à suivre pour demander une augmentation de quota, consultez le guide du développeur d'AWS Key Management Service.
- Sélectionnez "Enregistrer".
Pour en savoir plus sur la création d'une clé KMS AWS, consultez le guide du développeur d'AWS Key Management Service.
Pour en savoir plus sur l'utilisation d'AWS KMS avec Amazon S3, consultez le guide de l'utilisateur d'Amazon Simple Storage Service.
Lorsque vous activez le chiffrement par défaut, vous devrez peut-être mettre à jour la stratégie de votre bucket. Pour en savoir plus sur le passage des règles de bucket au chiffrement par défaut, consultez le guide de l'utilisateur d'Amazon Simple Storage Service.
CLI AWS
aws s3api put-bucket-encryption \
--bucket my-bucket \
--server-side-encryption-configuration '{"Rules": [{"ApplyServerSideEncryptionByDefault": {"SSEAlgorithm": "AES256"}}]}'
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesS3 Bucket Versioning Enabled
Nom de la catégorie dans l'API : S3_BUCKET_VERSIONING_ENABLED
Amazon S3 vous permet de conserver plusieurs variantes d'un objet dans le même bucket et peut vous aider à récupérer plus facilement les actions involontaires des utilisateurs et les échecs d'application.
Recommandation : Vérifie que la gestion des versions est activée pour tous les buckets S3
Pour corriger ce résultat, procédez comme suit :
Terraform
resource "aws_s3_bucket" "my_bucket" {
bucket = "my-bucket"
versioning {
enabled = true
}
}
Console AWS
Pour activer ou désactiver la gestion des versions sur un bucket S3
- Connectez-vous à la console de gestion AWS et ouvrez la console Amazon S3 à l'adresse https://console.aws.amazon.com/s3/.
- Dans la liste Buckets, choisissez le nom du bucket pour lequel vous souhaitez activer la gestion des versions.
- Sélectionnez "Propriétés".
- Sous "Gestion des versions du bucket", sélectionnez "Modifier".
- Sélectionnez "Suspendre" ou "Activer", puis "Enregistrer les modifications".
CLI AWS
aws s3control put-bucket-versioning \
--bucket <bucket_name> \
--versioning-configuration Status=Enabled
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesS3 Default Encryption Kms
Nom de la catégorie dans l'API : S3_DEFAULT_ENCRYPTION_KMS
Vérifie si les buckets Amazon S3 sont chiffrés avec AWS Key Management Service (AWS KMS)
Recommandation : Vérifie que tous les buckets sont chiffrés avec KMS
Pour corriger ce résultat, procédez comme suit :
Terraform
resource "aws_kms_key" "s3_encryption" {
description = "Used for S3 Bucket encryption configuration"
enable_key_rotation = true
}
resource "aws_s3_bucket_server_side_encryption_configuration" "enable" {
bucket = "my-bucket"
rule {
apply_server_side_encryption_by_default {
kms_master_key_id = aws_kms_key.s3_encryption.arn
sse_algorithm = "aws:kms"
}
}
}
Console AWS
Activer le chiffrement par défaut sur un bucket S3
- Ouvrez la console Amazon S3 à l'adresse https://console.aws.amazon.com/s3/.
- Dans le volet de navigation de gauche, sélectionnez "Buckets".
- Sélectionnez le bucket S3 dans la liste.
- Sélectionnez "Propriétés".
- Sélectionnez Chiffrement par défaut.
- Pour le chiffrement, choisissez AWS-KMS.
- Choisissez AWS-KMS pour utiliser des clés gérées par AWS KMS pour le chiffrement par défaut. Ensuite, sélectionnez une clé principale dans la liste des clés principales AWS KMS que vous avez créées. Pour en savoir plus sur la création de clés KMS, consultez la documentation AWS – Créer des clés.
- Saisissez le nom de ressource Amazon (ARN) de la clé KMS AWS à utiliser. Vous trouverez l'ARN de votre clé KMS AWS dans la console IAM, sous "Clés de chiffrement". Vous pouvez également choisir un nom de clé dans la liste déroulante.
- Important: Cette solution est soumise aux quotas RPS (requêtes par seconde) du service AWS KMS. Pour en savoir plus sur les quotas AWS KMS et sur la procédure à suivre pour demander une augmentation de quota, consultez le guide du développeur d'AWS Key Management Service.
- Sélectionnez "Enregistrer".
Pour en savoir plus sur l'utilisation d'AWS KMS avec Amazon S3, consultez le guide de l'utilisateur d'Amazon Simple Storage Service.
Lorsque vous activez le chiffrement par défaut, vous devrez peut-être mettre à jour la stratégie de votre bucket. Pour en savoir plus sur le passage des règles de bucket au chiffrement par défaut, consultez le guide de l'utilisateur d'Amazon Simple Storage Service.
CLI AWS
Créer une clé KMS
aws kms create-key \
--description "Key to encrypt S3 buckets"
Activer la rotation des clés
aws kms enable-key-rotation \
--key-id <key_id_from_previous_command>
Mettre à jour le bucket
aws s3api put-bucket-encryption \
--bucket my-bucket \
--server-side-encryption-configuration '{"Rules": [{"ApplyServerSideEncryptionByDefault": {"KMSMasterKeyID": "<id_from_key>", "SSEAlgorithm": "AES256"}}]}'
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesSagemaker Notebook Instance Kms Key Configured
Nom de la catégorie dans l'API : SAGEMAKER_NOTEBOOK_INSTANCE_KMS_KEY_CONFIGURED
Vérifie si une clé AWS Key Management Service (AWS KMS) est configurée pour une instance de notebook Amazon SageMaker. La règle est NON_COMPLIANT si "KmsKeyId" n'est pas spécifié pour l'instance de notebook SageMaker.
Recommandation : Vérifie que toutes les instances de notebook SageMaker sont configurées pour utiliser KMS
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesSagemaker Notebook No Direct Internet Access
Nom de la catégorie dans l'API : SAGEMAKER_NOTEBOOK_NO_DIRECT_INTERNET_ACCESS
Vérifie si l'accès direct à Internet est désactivé pour une instance de notebook SageMaker. Pour ce faire, il vérifie si le champ DirectInternetAccess est désactivé pour l'instance de notebook.
Si vous configurez votre instance SageMaker sans VPC, l'accès Internet direct est activé par défaut sur votre instance. Vous devez configurer votre instance avec un VPC et définir le paramètre par défaut sur "Désactiver" : accéder à Internet via un VPC.
Pour entraîner ou héberger des modèles à partir d'un notebook, vous avez besoin d'un accès à Internet. Pour activer l'accès à Internet, assurez-vous que votre VPC dispose d'une passerelle NAT et que votre groupe de sécurité autorise les connexions sortantes. Pour en savoir plus sur la connexion d'une instance de notebook aux ressources d'un VPC, consultez la section "Connecter une instance de notebook à des ressources d'un VPC" dans le guide du développeur Amazon SageMaker.
Vous devez également vous assurer que l'accès à votre configuration SageMaker est limité aux seuls utilisateurs autorisés. Restreignez les autorisations IAM des utilisateurs pour modifier les paramètres et les ressources de SageMaker.
Recommandation : Vérifie si l'accès direct à Internet est désactivé pour toutes les instances de notebook Amazon SageMaker
Pour corriger ce résultat, procédez comme suit :
Console AWS
Notez qu'une fois une instance de notebook créée, vous ne pouvez plus modifier le paramètre d'accès à Internet. Il doit être arrêté, supprimé et recréé.
Pour configurer une instance de notebook SageMaker afin de refuser l'accès direct à Internet:
- Ouvrez la console SageMaker à l'adresse https://console.aws.amazon.com/sagemaker/.
- Accédez aux instances de notebook.
- Supprimez l'instance pour laquelle l'accès direct à Internet est activé. Choisissez l'instance, sélectionnez "Actions", puis choisissez "Arrêter".
- Une fois l'instance arrêtée, sélectionnez "Actions", puis "Supprimer".
- Sélectionnez "Créer une instance de notebook". Indiquez les détails de la configuration.
- Développez la section "Réseau", puis sélectionnez un VPC, un sous-réseau et un groupe de sécurité. Sous Accès direct à Internet, sélectionnez Désactiver – Accéder à Internet via un VPC.
- Sélectionnez "Créer une instance de notebook".
Pour en savoir plus, consultez la section "Connecter une instance de notebook aux ressources d'un VPC" dans le guide du développeur Amazon SageMaker.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesSecretsmanager Rotation Enabled Check
Nom de la catégorie dans l'API : SECRETSMANAGER_ROTATION_ENABLED_CHECK
Vérifie si un secret stocké dans AWS Secrets Manager est configuré avec la rotation automatique. Le contrôle échoue si la rotation automatique n'est pas configurée pour le secret. Si vous fournissez une valeur personnalisée pour le paramètre maximumAllowedRotationFrequency
, le contrôle n'est transmis que si la rotation automatique du secret s'effectue dans le délai spécifié.
Secrets Manager vous aide à améliorer la stratégie de sécurité de votre organisation. Les secrets incluent les identifiants de base de données, les mots de passe et les clés API tierces. Secrets Manager vous permet de stocker les secrets de manière centralisée, de les chiffrer automatiquement, de contrôler l'accès aux secrets et d'effectuer une rotation automatique et sécurisée des secrets.
Secrets Manager peut alterner les secrets. Vous pouvez utiliser la rotation pour remplacer les secrets à long terme par des secrets à court terme. La rotation de vos secrets limite la durée pendant laquelle un utilisateur non autorisé peut utiliser un secret compromis. C'est pourquoi vous devez fréquemment alterner vos secrets. Pour en savoir plus sur la rotation, consultez la section "Effectuer une rotation de vos secrets AWS Secrets Manager" dans le guide de l'utilisateur d'AWS Secrets Manager.
Recommandation : Vérifie que la rotation est activée pour tous les secrets AWS Secrets Manager
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesSns Encrypted Kms
Nom de la catégorie dans l'API : SNS_ENCRYPTED_KMS
Vérifie si un sujet SNS est chiffré au repos à l'aide d'AWS KMS. Les contrôles échouent si un sujet SNS n'utilise pas de clé KMS pour le chiffrement côté serveur (SSE).
Le chiffrement des données au repos réduit le risque d'accès aux données stockées sur le disque par un utilisateur non authentifié auprès d'AWS. Elle ajoute également un autre ensemble de contrôles d'accès pour limiter la capacité des utilisateurs non autorisés à accéder aux données. Par exemple, des autorisations d'API sont nécessaires pour déchiffrer les données avant de pouvoir les lire. Les sujets SNS doivent être chiffrés au repos pour renforcer la sécurité.
Recommandation : Vérifie que tous les sujets SNS sont chiffrés avec KMS
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesVpc Default Security Group Closed
Nom de la catégorie dans l'API : VPC_DEFAULT_SECURITY_GROUP_CLOSED
Cette commande vérifie si le groupe de sécurité par défaut d'un VPC autorise le trafic entrant ou sortant. Le contrôle échoue si le groupe de sécurité autorise le trafic entrant ou sortant.
Les règles du groupe de sécurité par défaut autorisent tout le trafic sortant et entrant en provenance des interfaces réseau (et de leurs instances associées) affectées au même groupe de sécurité. Nous vous recommandons de ne pas utiliser le groupe de sécurité par défaut. Étant donné que le groupe de sécurité par défaut ne peut pas être supprimé, vous devez modifier le paramètre des règles de groupe de sécurité par défaut afin de limiter le trafic entrant et sortant. Cela permet d'éviter tout trafic imprévu si le groupe de sécurité par défaut est configuré accidentellement pour des ressources telles que des instances EC2.
Recommandation : Assurez-vous que le groupe de sécurité par défaut de chaque VPC limite tout le trafic
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesVpc Flow Logging Enabled All Vpcs
Nom de la catégorie dans l'API : VPC_FLOW_LOGGING_ENABLED_ALL_VPCS
Les journaux de flux VPC sont une fonctionnalité qui vous permet de recueillir des informations sur le trafic IP entre les différentes interfaces réseau de votre VPC. Après avoir créé un journal de flux, vous pouvez afficher et récupérer ses données dans les journaux Amazon CloudWatch. Il est recommandé d'activer les journaux de flux VPC pour les paquets "Rejetés" des VPC.
Recommandation : Assurez-vous que la journalisation de flux VPC est activée dans tous les VPC
Pour corriger ce résultat, procédez comme suit :
Console AWS
- Se connecter à la console de gestion
- Sélectionnez
Services
, puisVPC
- Dans le volet de navigation de gauche, sélectionnez
Your VPCs
. - Sélectionner un VPC
- Dans le volet de droite, sélectionnez l'onglet
Flow Logs
. - S'il n'existe aucun journal de flux, cliquez sur
Create Flow Log
. - Dans "Filtre", sélectionnez
Reject
. - Saisissez un
Role
et unDestination Log Group
- Cliquez sur
Create Log Flow
. - Cliquez sur
CloudWatch Logs Group
.
Remarque:Définir le filtre sur "Refuser" réduit considérablement l'accumulation de données de journalisation pour cette recommandation et fournit suffisamment d'informations pour la détection des violations, la recherche et la correction. Toutefois, lors des phases d'ingénierie du groupe de sécurité selon le principe du moindre privilège, définir ce filtre sur "Tous" peut s'avérer très utile pour identifier les flux de trafic existants nécessaires au bon fonctionnement d'un environnement déjà en cours d'exécution.
CLI AWS
- Créez un document de stratégie, nommez-le
role_policy_document.json
et collez le contenu suivant:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "test",
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
- Créez un autre document de stratégie, nommez-le
iam_policy.json
et collez le contenu suivant:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action":[
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:DescribeLogGroups",
"logs:DescribeLogStreams",
"logs:PutLogEvents",
"logs:GetLogEvents",
"logs:FilterLogEvents"
],
"Resource": "*"
}
]
}
- Exécutez la commande ci-dessous pour créer un rôle IAM:
aws iam create-role --role-name <aws_support_iam_role> --assume-role-policy-document file://<file-path>role_policy_document.json
- Exécutez la commande ci-dessous pour créer une stratégie IAM:
aws iam create-policy --policy-name <ami-policy-name> --policy-document file://<file-path>iam-policy.json
- Exécutez la commande
attach-group-policy
à l'aide de l'ARN de la stratégie IAM renvoyé à l'étape précédente pour associer la stratégie au rôle IAM (si la commande aboutit, aucun résultat n'est renvoyé):
aws iam attach-group-policy --policy-arn arn:aws:iam::<aws-account-id>:policy/<iam-policy-name> --group-name <group-name>
- Exécutez
describe-vpcs
pour obtenir le VpcId disponible dans la région sélectionnée:
aws ec2 describe-vpcs --region <region>
- Le résultat de la commande doit renvoyer l'ID de VPC disponible dans la région sélectionnée.
- Exécutez
create-flow-logs
pour créer un journal de flux pour le VPC:
aws ec2 create-flow-logs --resource-type VPC --resource-ids <vpc-id> --traffic-type REJECT --log-group-name <log-group-name> --deliver-logs-permission-arn <iam-role-arn>
- Répétez l'étape 8 pour les autres VPC disponibles dans la région sélectionnée.
- Modifiez la région en mettant à jour --region et répétez la procédure de correction pour les autres VPC.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesVpc Sg Open Only To Authorized Ports
Nom de la catégorie dans l'API : VPC_SG_OPEN_ONLY_TO_AUTHORIZED_PORTS
Ce contrôle vérifie si un groupe de sécurité Amazon EC2 autorise le trafic entrant sans restriction provenant de ports non autorisés. L'état de la commande est déterminé comme suit:
Si vous utilisez la valeur par défaut pour "allowedTcpPorts", le contrôle échoue si le groupe de sécurité autorise le trafic entrant sans restriction en provenance de tout port autre que les ports 80 et 443.
Si vous spécifiez des valeurs personnalisées pour les objets "AuthorizedTcpPort" ou "AuthorizedUdpPorts", le contrôle échoue si le groupe de sécurité autorise le trafic entrant non restreint à partir de n'importe quel port non répertorié.
Si aucun paramètre n'est utilisé, le contrôle échoue pour tous les groupes de sécurité qui disposent d'une règle de trafic entrant non restreint.
Les groupes de sécurité permettent un filtrage avec état du trafic réseau entrant et sortant vers AWS. Les règles de groupe de sécurité doivent respecter le principe du moindre privilège. L'accès non restreint (adresse IP portant le suffixe /0) augmente le risque d'activités malveillantes telles que le piratage, les attaques par déni de service et la perte de données. À moins qu'un port ne soit spécifiquement autorisé, il doit refuser l'accès non restreint.
Recommandation : Vérifie que tous les groupes de sécurité avec 0.0.0.0/0 d'un VPC n'autorisent que du trafic TCP/UDP entrant spécifique
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur lesBoth VPC VPN Tunnels Up
Nom de la catégorie dans l'API : VPC_VPN_2_TUNNELS_UP
Un tunnel VPN est un lien chiffré via lequel les données peuvent circuler depuis ou vers AWS via une connexion VPN Site-to-Site AWS. Chaque connexion VPN comprend deux tunnels VPN que vous pouvez utiliser simultanément pour une haute disponibilité. Vous devez vous assurer que les deux tunnels VPN sont opérationnels pour une connexion VPN afin de confirmer une connexion sécurisée et à disponibilité élevée entre un VPC AWS et votre réseau distant.
Cette commande vérifie que les deux tunnels VPN fournis par AWS Site-to-Site VPN sont à l'état UP. Le contrôle échoue si l'un des tunnels ou les deux sont à l'état DOWN.
Recommandation : Vérifie que les deux tunnels VPN AWS fournis par AWS de site à site sont à l'état UP.
éléments et les paramètres d'analyse compatibles de ce type de résultat.
En savoir plus sur les