Compliance Manager inclut de nombreux contrôles cloud intégrés que vous pouvez ajouter à des frameworks et déployer dans votre environnement. Si nécessaire, vous pouvez créer et gérer vos propres contrôles cloud personnalisés, et mettre à jour les contrôles cloud intégrés.
Avant de commencer
Effectuez ces tâches avant de passer aux autres tâches de cette page.
Configurer les autorisations
-
Pour obtenir les autorisations nécessaires pour gérer les frameworks de contrôles cloud, demandez à votre administrateur de vous accorder les rôles IAM suivants sur votre organisation ou votre projet :
- Administrateur de Compliance Manager (
roles/cloudsecuritycompliance.admin) -
Pour créer ou modifier des contrôles cloud basés sur des règles d'administration#39;administration, vous devez disposer de l'un des rôles suivants :
- Administrateur des règles d'administration (
roles/orgpolicy.policyAdmin) - Administrateur Assured Workloads (
roles/assuredworkloads.admin) - Éditeur Assured Workloads (
roles/assuredworkloads.editor)
- Administrateur des règles d'administration (
- Pour créer ou modifier des contrôles cloud basés sur des règles de projet : Administrateur IAM de projet (
roles/resourcemanager.projectIamAdmin)
Pour en savoir plus sur l'attribution de rôles, consultez Gérer l'accès aux projets, aux dossiers et aux organisations.
Vous pouvez également obtenir les autorisations requises avec des rôles personnalisés ou d'autres rôles prédéfinis.
- Administrateur de Compliance Manager (
Configurer la Google Cloud CLI
Dans la console Google Cloud , activez Cloud Shell.
En bas de la console Google Cloud , une session Cloud Shell démarre et affiche une invite de ligne de commande. Cloud Shell est un environnement de shell dans lequel Google Cloud CLI est déjà installé, et dans lequel des valeurs sont déjà définies pour votre projet actuel. L'initialisation de la session peut prendre quelques secondes.
Pour configurer la gcloud CLI afin qu'elle utilise l'emprunt d'identité d'un compte de service pour s'authentifier auprès des Google APIs plutôt que d'utiliser vos identifiants utilisateur, exécutez la commande suivante :
gcloud config set auth/impersonate_service_account SERVICE_ACCT_EMAIL
Pour en savoir plus, consultez la section Emprunt d'identité d'un compte de service.
Afficher les contrôles cloud
Suivez les étapes ci-dessous pour afficher les contrôles cloud intégrés et les contrôles cloud personnalisés que vous avez déjà créés.
Console
Dans la console Google Cloud , accédez à la page Conformité.
Sélectionnez votre organisation ou votre projet.
Dans l'onglet Configurer, cliquez sur Contrôles cloud. Les commandes cloud disponibles s'affichent.
Le tableau de bord indique les frameworks qui incluent le contrôle cloud et le nombre de ressources (organisation, dossiers et projets) auxquelles le contrôle cloud est appliqué.
Pour afficher des informations sur un contrôle cloud, cliquez sur son nom.
CLI
Vous pouvez afficher des informations sur un contrôle cloud spécifique ou lister tous les contrôles cloud de votre organisation.
Afficher les détails d'un contrôle cloud
Pour afficher des informations sur un contrôle cloud spécifique, exécutez la commande gcloud
compliance-manager cloud-controls describe :
gcloud compliance-manager cloud-controls describe CLOUD_CONTROL \
--location=LOCATION \
--organization=ORGANIZATION \
[--major-revision-id=MAJOR_REVISION_ID]
Remplacez les valeurs suivantes :
CLOUD_CONTROL: nom du contrôle cloudORGANIZATION: ID de votre organisationLOCATION: région dans laquelle le contrôle du cloud est stockéMAJOR_REVISION_IDest un indicateur facultatif qui spécifie la version du contrôle cloud à afficher. Si vous n'incluez pas l'indicateur, la dernière version est renvoyée.
Par exemple, pour afficher un contrôle cloud portant le nom builtin-block-external-ip-addresses-for-vm-access et le numéro de révision majeur 1, exécutez la commande suivante :
gcloud compliance-manager cloud-controls describe \
builtin-block-external-ip-addresses-for-vm-access \
--organization=3589215982 \
--location=global \
--major-revision-id=1
Pour en savoir plus, consultez gcloud compliance-manager cloud-controls describe.
Obtenir la liste des contrôles cloud
Pour obtenir la liste des contrôles cloud de votre organisation, exécutez la commande gcloud
compliance-manager cloud-controls list :
gcloud compliance-manager cloud-controls list \
--location=LOCATION \
--organization=ORGANIZATION
Remplacez les valeurs suivantes :
ORGANIZATION: ID de votre organisationLOCATION: région dans laquelle les commandes cloud sont stockées
Par exemple, pour afficher tous les contrôles cloud de l'organisation 3589215982 stockés dans l'emplacement global, exécutez la commande suivante :
gcloud compliance-manager cloud-controls list \
--organization=3589215982 \
--location=global
Pour en savoir plus sur les options facultatives, consultez gcloud compliance-manager cloud-controls list.
Créer un contrôle cloud personnalisé
Lorsque vous créez un contrôle cloud personnalisé, vous appliquez une règle à n'importe quel type de ressource de l'inventaire des éléments cloud.
Console
Lorsque vous utilisez la console, vous pouvez créer des contrôles cloud personnalisés avec une règle qui s'applique à un type de ressource.
Dans la console Google Cloud , accédez à la page Conformité.
Sélectionnez votre organisation ou votre projet.
Dans l'onglet Configurer, cliquez sur Contrôles cloud. La liste des contrôles cloud disponibles s'affiche.
Créez un contrôle cloud avec Gemini ou manuellement :
Utiliser Gemini
Demandez à Gemini de générer un contrôle cloud pour vous. En fonction de votre requête, Gemini fournit un identifiant unique, un nom, une logique de détection associée et des mesures correctives possibles.
Examinez les recommandations et apportez les modifications nécessaires.
Enregistrez votre contrôle cloud personnalisé.
Créer manuellement
Dans ID du contrôle cloud, indiquez un identifiant unique pour votre contrôle.
Saisissez un nom et une description pour aider les utilisateurs de votre organisation à comprendre l'objectif du contrôle cloud personnalisé.
Facultatif : Sélectionnez les catégories du contrôle. Cliquez sur Continuer.
Sélectionnez un type de ressource disponible pour votre contrôle cloud personnalisé. Compliance Manager est compatible avec tous les types de ressources. Pour trouver le nom d'une ressource, consultez Types d'assets.
Fournissez la logique de détection pour votre contrôle cloud, au format CEL (Common Expression Language).
Les expressions CEL vous permettent de définir la manière dont vous souhaitez évaluer les propriétés d'une ressource. Pour en savoir plus et obtenir des exemples, consultez Écrire des règles pour les contrôles cloud personnalisés. Cliquez sur Continuer.
Si votre règle d'évaluation n'est pas valide, une erreur s'affiche.
Sélectionnez le niveau de gravité approprié pour les résultats.
Rédigez vos instructions de correction afin que les responsables de la gestion des incidents et les administrateurs de votre organisation puissent résoudre les problèmes liés au contrôle du cloud. Cliquez sur Continuer.
Vérifiez vos entrées, puis cliquez sur Créer.
CLI
Lorsque vous utilisez la gcloud CLI, vous pouvez créer un contrôle cloud personnalisé avec un maximum de trois règles. Chaque règle ne peut s'appliquer qu'à un seul type de ressource.
Pour créer un contrôle cloud personnalisé, exécutez la commande gcloud compliance-manager
cloud-controls create :
gcloud compliance-manager cloud-controls create CLOUD_CONTROL \
--location=LOCATION \
--organization=ORGANIZATION \
[--display-name=DISPLAY_NAME] \
[--description=DESCRIPTION] \
[--categories=[CATEGORIES,...]] \
[--finding-category=FINDING_CATEGORY] \
[--parameter-spec=[defaultValue=DEFAULTVALUE],[description=DESCRIPTION],[displayName=DISPLAYNAME],[isRequired=ISREQUIRED],[name=NAME],[substitutionRules=SUBSTITUTIONRULES],[validation=VALIDATION],[valueType=VALUETYPE]] \
[--remediation-steps=REMEDIATION_STEPS] \
[--rules=[celExpression=CELEXPRESSION],[description=DESCRIPTION],[ruleActionTypes=RULEACTIONTYPES]] \
[--severity=SEVERITY] \
[--supported-cloud-providers=[SUPPORTED_CLOUD_PROVIDERS,…]] \
[--supported-target-resource-types=[SUPPORTED_TARGET_RESOURCE_TYPES,…]]
Remplacez les valeurs suivantes :
CLOUD_CONTROL: nom alphanumérique unique pour le contrôle cloudORGANIZATION: ID de votre organisationLOCATION: région dans laquelle le contrôle du cloud est stockéDISPLAY_NAME: nom lisible du contrôle cloudDESCRIPTION: description facultative de l'objectif du contrôle cloudCATEGORIES,…: paramètre facultatif qui définit les catégories auxquelles appartient le contrôle cloud. Pour obtenir la liste des catégories autorisées, consultez gcloud compliance-manager cloud-controls create.FINDING_CATEGORY: valeur qui s'affiche dans le tableau de bord des résultats Security Command Center lorsque le contrôle cloud génère un résultat--parameter-spec=[defaultValue=DEFAULTVALUE], \ [description=DESCRIPTION], \ [displayName= DISPLAYNAME], \ [isRequired=ISREQUIRED], \ [name=NAME], \ [substitutionRules=SUBSTITUTIONRULES], \ [validation=VALIDATION], \ [valueType=VALUETYPE]...]
sont les informations sur les paramètres facultatifs pour le contrôle du cloud, au format suivant :
DEFAULTVALUE: données appliquées si un utilisateur ne personnalise pas le paramètre lors du déploiement d'un framework. Les types de valeurs acceptés sontboolValue,numberValue,stringListValueoustringValue.DESCRIPTION: description facultative du contrôleISREQUIRED:truesi le contrôle nécessite la définition d'un paramètreNAME: nom du paramètreSUBSTITUTIONRULES: indique comment et où le Gestionnaire de conformité injecte la valeur personnalisée du paramètre. Spécifiez le chemin ciblé dans la règle à l'aide d'une notation par points proto (par exemple,rules[0].org_policy_constraint...). Choisissez l'une des options suivantes :attributeSubstitutionRulelorsque vous souhaitez injecter la valeur du paramètre directement dans un champ structurel de votre règle (par exemple, pour remplir une liste de valeurs restreintes dans un modèle de règle de contrainte de règle relative aux règles de l'organisation).placeholderSubstitutionRulelorsque votre règle utilise une chaîne de texte (ou une expression CEL). La chaîne doit contenir une variable d'espace réservé préfixée par$(par exemple,$deniedServices). Cette règle indique au compilateur de mapper le paramètre à cet espace réservé.
L'exemple suivant crée un paramètre de liste nommé
deniedServicesavec le typeSTRINGLIST. Il utiliseattributeSubstitutionRulepour ajouter les noms de services fournis par l'utilisateur (tels quecompute.googleapis.com) directement dans une règle de règle d'administration personnalisée structurelle (denied_values) lors du déploiement :--parameter-spec='name=deniedServices,isRequired=true,valueType=STRINGLIST,substitutionRules=[{attributeSubstitutionRule={attribute="rules[0].org_policy_constraint.policy_rules[0].values.denied_values"}}]'VALIDATIONest l'ensemble des valeurs autorisées. Choisissez l'une des options suivantes :Utilisez
allowedValuespour appliquer une liste d'autorisation statique. Par exemple, limitez les paramètres de localisation à des champs de chaîne spécifiques :validation={allowedValues={values=[{stringValue=us-central1},{stringValue=us-west1}]}}Utilisez
intRangepour appliquer des limites numériques aux nombres entiers. Par exemple, définissez une période de conservation comprise entre 1 et 365 :validation={intRange={min=1,max=365}}Utilisez
regexpPatternpour appliquer la correspondance d'expression régulière sur le texte de la chaîne. Par exemple, pour exiger une dénomination alphanumérique stricte :validation={regexpPattern={pattern="^[a-z][-a-z0-9]*$"}}
VALUETYPE: type de données ou format de la valeur qu'un utilisateur fournit pour ce paramètre. Les types de valeurs acceptés sontSTRING,BOOLEAN,STRINGLIST,NUMBERetONEOF.
Vous pouvez également spécifier un fichier JSON ou YAML qui définit les paramètres. Par exemple,
--parameter-spec=path_to_file.(yaml|json). Développez la section suivante pour afficher des exemples de fichiers JSON et YAML.Exemple de fichier JSON
[ { "name": "deniedServices", "displayName": "Services Requiring CMEK", "description": "List of service names that must use Customer-Managed Encryption Keys.", "isRequired": true, "valueType": "STRINGLIST", "substitutionRules": [ { "attributeSubstitutionRule": { "attribute": "rules[0].org_policy_constraint.policy_rules[0].values.denied_values" } } ] } ]Exemple de fichier YAML
- name: deniedServices displayName: "Services Requiring CMEK" description: "List of service names that must use Customer-Managed Encryption Keys." isRequired: true valueType: STRINGLIST substitutionRules: - attributeSubstitutionRule: attribute: "rules[0].org_policy_constraint.policy_rules[0].values.denied_values"REMEDIATION_STEPS : étapes requises pour résoudre les problèmes détectés. Cette chaîne est limitée à 400 caractères.
--rules=[celExpression=CELEXPRESSION],[description=DESCRIPTION],[ruleActionTypes=RULEACTIONTYPES]correspond à la règle que vous souhaitez appliquer, au format suivant :CELEXPRESSION: expression CEL (Common Expression Language) de la règle. Pour savoir comment écrire des expressions CEL, consultez Écrire des règles pour les contrôles cloud personnalisés. Incluez les éléments suivants :expression: expression CEL, avec un maximum de 1 000 caractèresresourceTypesValues: nom des ressources, au formatSERVICE_NAME/type. Utilisez un tableauvaluespour lister tous les types de ressources auxquels vous souhaitez appliquer la règle (par exemple,values=[compute.googleapis.com/Instance]).
DESCRIPTION: description de la règleRULEACTIONTYPES: action effectuée par la règle. Les valeurs acceptées sontrule-action-type-detective,rule-action-type-preventiveetrule-action-type-audit.
Par exemple, pour vérifier la période de rotation des clés Cloud Key Management Service, saisissez la commande suivante :
--rules="[ { \"celExpression\": { \"expression\": \"has(resource.data.rotationPeriod) && resource.data.rotationPeriod < duration('60h')\", \"resourceTypesValues\": { \"values\": [ \"cloudkms.googleapis.com/CryptoKey\" ] } }, \"description\": \"Check KMS key rotation period\", \"ruleActionTypes\": [ \"rule-action-type-detective\" ] } ]"Vous pouvez également spécifier un fichier JSON ou YAML qui définit la règle. Par exemple,
--rules=path_to_file.(yaml|json). Développez la section suivante pour afficher des exemples de fichiers JSON et YAML.Exemple de fichier JSON
[ { "celExpression": { "expression": "has(resource.data.rotationPeriod) && resource.data.rotationPeriod < duration('60h')", "resourceTypesValues": { "values": [ "cloudkms.googleapis.com/CryptoKey" ] } }, "description": "Check KMS key rotation period to ensure it is under 60 hours.", "ruleActionTypes": [ "rule-action-type-detective" ] } ]Exemple de fichier YAML
- celExpression: expression: "has(resource.data.rotationPeriod) && resource.data.rotationPeriod < duration('60h')" resourceTypesValues: values: - cloudkms.googleapis.com/CryptoKey description: "Check KMS key rotation period to ensure it is under 60 hours." ruleActionTypes: - rule-action-type-detectiveSEVERITY: niveau de criticité du contrôle cloud. Les valeurs acceptées sontcritical,high,mediumetlow.SUPPORTED_CLOUD_PROVIDERS,…: fournisseurs de services cloud auxquels s'applique ce contrôle du cloud. La seule valeur acceptée estgcp.SUPPORTED_TARGET_RESOURCE_TYPES,…: types de ressources (organisation, dossier, projet ou dossier compatible avec les applications dans App Hub) compatibles avec le contrôle cloud. Les valeurs acceptées sonttarget-resource-crm-type-folder,target-resource-crm-type-org,target-resource-crm-type-projectettarget-resource-type-application.
Par exemple, pour créer un contrôle cloud qui applique les emplacements des ressources, exécutez la commande suivante :
gcloud compliance-manager cloud-controls create \
restrict-resource-locations \
--organization=3589215982 \
--location=global \
--display-name="Restrict Resource Locations" \
--description="Enforces checks to ensure resources are only deployed in approved cloud regions." \
--severity=high \
--finding-category="LOCATION_VIOLATION" \
--supported-cloud-providers="gcp" \
--supported-target-resource-types="target-resource-crm-type-project" \
--parameter-spec='name=allowedLocations,isRequired=true,valueType=STRINGLIST,substitutionRules=[{placeholderSubstitutionRule={attribute="rules[0].cel_expression.expression"}}]' \
--rules="[{\"celExpression\": {\"expression\": \"resource.location in \$allowedLocations\", \"resourceTypesValues\": {\"values\": [\"compute.googleapis.com/Instance\"]}}, \"description\": \"Check Compute Engine instance locations\", \"ruleActionTypes\": [\"rule-action-type-detective\"]}]"
Pour créer le même contrôle, mais utiliser des fichiers YAML pour définir les paramètres et les règles, exécutez la commande suivante :
gcloud compliance-manager cloud-controls create \
restrict-resource-locations \
--organization=3589215982 \
--location=global \
--display-name="Restrict Resource Locations" \
--description="Enforces checks to ensure resources are only deployed in approved cloud regions." \
--severity=high \
--finding-category="LOCATION_VIOLATION" \
--supported-cloud-providers="gcp" \
--supported-target-resource-types="target-resource-crm-type-project" \
--parameter-spec=parameters.yaml \
--rules=rules.yaml
Pour en savoir plus, consultez gcloud compliance-manager cloud-controls create.
Terraform
Lorsque vous utilisez Terraform, vous pouvez créer un contrôle cloud personnalisé avec un maximum de trois règles. Chaque règle ne peut s'appliquer qu'à un seul type de ressource.
L'exemple suivant montre comment créer un contrôle cloud personnalisé à l'aide de Terraform.
Modifier un contrôle cloud personnalisé
Une fois que vous avez créé un contrôle cloud, vous pouvez modifier son nom, sa description, ses règles, ses étapes de correction et son niveau de gravité. Vous ne pouvez pas modifier la catégorie de contrôle cloud.
Dans la console Google Cloud , accédez à la page Conformité.
Sélectionnez votre organisation ou votre projet.
Dans l'onglet Configurer, cliquez sur Contrôles cloud. La liste des commandes cloud disponibles s'affiche.
Cliquez sur le contrôle cloud que vous souhaitez modifier.
Sur la page Détails des contrôles cloud, vérifiez que le contrôle cloud n'est pas inclus dans un framework. Si nécessaire, modifiez le framework pour supprimer le contrôle cloud.
Cliquez sur Modifier.
Sur la page Modifier le contrôle cloud personnalisé, modifiez le nom et la description selon vos besoins. Cliquez sur Continuer.
Mettez à jour les règles, le niveau de gravité des résultats et les étapes de correction. Cliquez sur Continuer.
Vérifiez les modifications apportées, puis cliquez sur Enregistrer.
Mettre à jour un contrôle cloud intégré vers une version plus récente
Google publie régulièrement des mises à jour de ses contrôles cloud intégrés à mesure que les services déploient de nouvelles fonctionnalités ou que de nouvelles bonnes pratiques émergent. Les mises à jour peuvent inclure de nouvelles commandes ou des modifications apportées aux commandes existantes.
Vous pouvez afficher les versions des contrôles cloud intégrés dans le tableau de bord des contrôles cloud de l'onglet Configurer ou sur la page d'informations sur les contrôles cloud.
Google vous avertit dans les notes de version lorsque les éléments suivants sont mis à jour :
- Nom du contrôle cloud
- Catégorie de résultats
- Modification de la logique de détection ou de prévention dans une règle
- Logique sous-jacente d'une règle
Pour mettre à jour un contrôle cloud après avoir reçu une notification, vous devez dissocier et redéployer les frameworks qui incluent le contrôle cloud. Pour obtenir des instructions, consultez Mettre à jour un framework vers une version plus récente.
Supprimer un contrôle cloud personnalisé
Supprimez un contrôle cloud lorsqu'il n'est plus nécessaire. Vous ne pouvez supprimer que les contrôles cloud que vous créez. Vous ne pouvez pas supprimer les contrôles cloud intégrés.
Console
Dans la console Google Cloud , accédez à la page Conformité.
Sélectionnez votre organisation ou votre projet.
Dans l'onglet Configurer, cliquez sur Contrôles cloud. La liste des commandes cloud disponibles s'affiche.
Cliquez sur le contrôle cloud que vous souhaitez supprimer.
Sur la page Détails des contrôles cloud, vérifiez que le contrôle cloud n'est pas inclus dans un framework. Si nécessaire, modifiez le framework pour supprimer le contrôle cloud.
Cliquez sur Supprimer.
Dans la fenêtre Supprimer, lisez le message. Saisissez
Delete, puis cliquez sur Confirmer.
CLI
Pour supprimer un contrôle cloud personnalisé, exécutez la commande gcloud compliance-manager
cloud-controls delete :
gcloud compliance-manager cloud-controls delete CLOUD_CONTROL \
--location=LOCATION \
--organization=ORGANIZATION
Remplacez les valeurs suivantes :
CLOUD_CONTROL: nom du contrôle cloudORGANIZATION: ID de votre organisationLOCATION: région dans laquelle le contrôle du cloud est stocké
Par exemple, pour supprimer un contrôle cloud nommé restrict-resource-locations, exécutez la commande suivante :
gcloud compliance-manager cloud-controls delete \
restrict-resource-locations \
--organization=3589215982 \
--location=global
Pour en savoir plus, consultez gcloud compliance-manager cloud-controls delete.
Mappage des détecteurs Security Health Analytics aux contrôles cloud
Le tableau suivant montre comment les contrôles cloud Compliance Manager sont mappés aux détecteurs Security Health Analytics.
| Catégorie de résultat dans Security Health Analytics | Nom du contrôle cloud dans le Gestionnaire de conformité |
|---|---|
|
Activer Access Transparency |
|
Bloquer les rôles d'administrateur des comptes de service |
|
Configurer le paramètre "Paramètres d'entrée autorisés" pour la contrainte de règle d'administration Cloud Run |
|
Configurer la contrainte de règle d'administration "Paramètres de sortie VPC autorisés" pour Cloud Run |
|
Activer les sauvegardes automatiques AlloyDB sur un cluster |
|
Activer les sauvegardes AlloyDB sur un cluster |
|
Activer CMEK pour les clusters AlloyDB |
|
Définir l'option de verbosité des erreurs de journaux pour les instances AlloyDB |
|
Définir l'option "log_min_error_statement" pour les instances AlloyDB |
|
Définir le flag "Nombre minimal de messages de journaux" pour les instances AlloyDB |
|
Bloquer les adresses IP publiques pour les instances de cluster AlloyDB |
|
Désactiver les fonctionnalités alpha sur les clusters GKE |
|
Restreindre les clés API aux API requises uniquement |
|
Non disponible |
|
Exiger la rotation de la clé API |
|
Configurer des métriques de journal et des alertes pour les modifications apportées à Audit Logging |
|
Implémenter la journalisation des événements pour les services Google Cloud |
|
Activer les sauvegardes automatiques pour les bases de données Cloud SQL |
|
Activer la réparation automatique pour les clusters GKE |
|
Activer la mise à niveau automatique sur les clusters GKE |
|
Activer CMEK pour les tables BigQuery |
|
Exiger l'autorisation binaire sur un cluster |
|
Activer CMEK pour les buckets Cloud Storage |
|
Configurer des métriques et des alertes de journal pour les modifications apportées aux règles IAM Cloud Storage |
|
Exiger la journalisation des buckets Cloud Storage |
|
Activer l'accès uniforme au niveau du bucket sur les buckets Cloud Storage |
|
Activer le service d'inventaire des éléments cloud |
|
Activer Cloud Logging sur les clusters GKE |
|
Activer Cloud Monitoring sur les clusters GKE |
|
Activer l'accès privé à Google sur une instance |
|
Activer le chiffrement sur les clusters GKE |
|
Activer les nœuds GKE protégés sur un cluster |
|
Bloquer les clés SSH à l'échelle du projet sur les instances Compute Engine |
|
Activer le démarrage sécurisé sur les instances Compute Engine |
|
Bloquer les ports série pour les instances Compute Engine |
|
Activer l'informatique confidentielle pour les instances Compute Engine |
|
Exiger Container-Optimized OS pour un cluster GKE |
|
Non disponible |
|
Configurer des métriques de journal et des alertes pour les modifications apportées aux rôles personnalisés |
|
Exiger CMEK sur les clusters Dataproc |
|
Utiliser les dernières versions d'image sur les clusters Dataproc |
|
Activer CMEK pour les ensembles de données BigQuery |
|
Utiliser des réseaux avec des règles de pare-feu personnalisées |
|
Utiliser des comptes de service personnalisés pour les instances Compute Engine |
|
Configurer la règle d'administration "Désactiver l'utilisation d'IPv6 à l'extérieur du VPC" |
|
Configurer la règle d'administration "Désactiver l'utilisation d'IPv6 à l'extérieur du VPC" |
|
Configurer le règlement "Désactiver la journalisation du port série des VM sur Stackdriver" au niveau de l'organisation |
|
Activer CMEK sur les disques persistants Compute Engine |
|
Activer les clés de chiffrement fournies par le client sur les disques persistants Compute Engine |
|
Activer la surveillance des journaux Cloud DNS |
|
Activer DNSSEC pour Cloud DNS |
|
Appliquer la règle de pare-feu de sortie "Tout refuser" |
|
Définir les contacts essentiels |
|
Configurer des métriques de journal et des alertes pour les modifications apportées au pare-feu de réseau VPC |
|
Activer la journalisation des règles de pare-feu |
|
Activer les journaux de flux pour un sous-réseau VPC |
|
Restreindre l'accès aux API Google Cloud pour les instances Compute Engine |
|
Appliquer le trafic HTTPS uniquement |
|
Définir des périmètres de service dans VPC Service Controls |
|
Activer OS Login |
|
Activer la surveillance de l'intégrité sur les clusters GKE |
|
Activer la visibilité intranœud pour les clusters GKE |
|
Activer la plage d'alias d'adresse IP pour les clusters GKE |
|
Empêcher le transfert IP sur les instances Compute Engine |
|
Définir la période de rotation des clés Cloud KMS |
|
Non disponible |
|
Non disponible |
|
Appliquer la séparation des tâches |
|
Bloquer l'ancienne autorisation sur les clusters GKE |
|
Désactiver les anciens points de terminaison du serveur de métadonnées sur Compute Engine |
|
Ne pas utiliser les anciens réseaux |
|
Activer la journalisation de l'équilibreur de charge |
|
Verrouiller les règles de conservation des buckets de stockage |
|
Configurer des récepteurs de journaux |
|
Activer les réseaux autorisés pour le plan de contrôle sur les clusters GKE |
|
Non disponible |
|
Configurer les métriques de journal et les alertes pour les modifications apportées au réseau VPC |
|
Activer les règles de réseau sur les clusters GKE |
|
Activer CMEK sur les disques de démarrage des pools de nœuds GKE |
|
Activer le démarrage sécurisé pour les nœuds GKE protégés |
|
Non disponible |
|
Activer la gestion des versions d'objets sur les buckets |
|
Bloquer les connexions aux ports Cassandra depuis toutes les adresses IP |
|
Bloquer les connexions aux ports CiscoSecure/WebSM depuis toutes les adresses IP |
|
Bloquer les connexions aux ports des services d'annuaire depuis toutes les adresses IP |
|
Bloquer les connexions aux ports DNS depuis toutes les adresses IP |
|
Bloquer les connexions aux ports Elasticsearch à partir de toutes les adresses IP |
|
Non disponible |
|
Bloquer les connexions aux ports FTP depuis toutes les adresses IP |
|
Non disponible |
|
Bloquer les connexions aux ports HTTP à partir de toutes les adresses IP |
|
Bloquer les connexions aux ports LDAP depuis toutes les adresses IP |
|
Bloquer les connexions aux ports Memcached à partir de toutes les adresses IP |
|
Bloquer les connexions aux ports MongoDB à partir de toutes les adresses IP |
|
Bloquer les connexions aux ports MySQL depuis toutes les adresses IP |
|
Bloquer les connexions aux ports NetBIOS à partir de toutes les adresses IP |
|
Bloquer les connexions aux ports Oracle Database à partir de toutes les adresses IP |
|
Bloquer les connexions aux ports du serveur POP3 depuis toutes les adresses IP |
|
Bloquer les connexions aux ports du serveur PostgreSQL depuis toutes les adresses IP |
|
Bloquer l'accès au port RDP |
|
Bloquer les connexions aux ports du serveur Redis à partir de toutes les adresses IP |
|
Bloquer les connexions aux ports du serveur SMTP à partir de toutes les adresses IP |
|
Bloquer l'accès au port SSH |
|
Bloquer les connexions aux ports du serveur Telnet à partir de toutes les adresses IP |
|
Activer la contrainte de règle d'administration Confidential VM |
|
Activer OS Login pour toutes les instances au niveau du projet |
|
Utiliser des comptes de service avec le moins de privilèges pour les clusters GKE |
|
Créer des clusters GKE avec des niveaux d'accès limités au compte de service |
|
Bloquer les rôles d'administrateur des comptes de service |
|
Non disponible |
|
Non disponible |
|
Restreindre les anciens rôles IAM |
|
Activer les clusters privés pour GKE |
|
Activer l'accès privé à Google pour les sous-réseaux VPC |
|
Restreindre l'accès public aux buckets Cloud Storage |
|
Restreindre l'accès public aux images de calcul |
|
Restreindre l'accès public aux ensembles de données BigQuery |
|
Limiter les adresses IP publiques aux instances Compute Engine |
|
Restreindre l'accès public aux buckets Cloud Storage |
|
Limiter l'accès public aux instances de base de données Cloud SQL |
|
Chiffrer un sujet Pub/Sub avec CMEK |
|
Activer le flag "log_statement" pour PostgreSQL |
|
Non disponible |
|
Abonner un cluster GKE à un canal de publication |
|
Activer OS Login |
|
Définir la sortie du connecteur VPC pour les fonctions Cloud Run |
|
Activer la contrainte de règle d'administration "Limiter le nombre de réseaux autorisés sur les instances Cloud SQL" |
|
Configurer des métriques et des alertes de journal pour les modifications apportées aux routes VPC |
|
Éviter RSASHA1 pour la signature DNSSEC |
|
Non disponible |
|
Non disponible |
|
Exiger la rotation des clés de compte de service |
|
Appliquer la séparation des tâches |
|
Activer les VM protégées pour les instances Compute Engine |
|
Limiter la création de réseaux par défaut pour les instances Compute Engine |
|
Activer CMEK pour les bases de données Cloud SQL |
|
Désactiver le flag d'authentification de la base de données autonome pour SQL Server |
|
Désactiver l'indicateur de chaînage de propriété entre les bases de données pour SQL Server |
|
Désactiver l'option "Scripts externes activés" pour SQL Server |
|
Configurer des métriques et des alertes de journal pour les modifications de configuration Cloud SQL |
|
Désactiver le flag local_infile pour MySQL |
|
Activer le flag de points de contrôle des journaux pour PostgreSQL |
|
Activer le flag "Log Connections" pour PostgreSQL |
|
Activer le flag "Log Disconnections" pour PostgreSQL |
|
Activer le flag de durée du journal pour l'instance PostgreSQL |
|
Activer le flag de verbosité des erreurs de journal pour PostgreSQL |
|
Désactiver le flag de statistiques de l'exécuteur de journaux pour PostgreSQL |
|
Désactiver le flag de nom d'hôte de journaux pour PostgreSQL |
|
Activer le flag "Log Locks Wait" pour l'instance PostgreSQL |
|
Désactiver le flag d'instruction de durée minimale des journaux pour PostgreSQL |
|
Activer le flag "log_min_error_statement" pour PostgreSQL |
|
Non disponible |
|
Activer le flag "log_min_messages" pour PostgreSQL |
|
Désactiver le flag de statistiques de l'analyseur de journaux pour PostgreSQL |
|
Désactiver le flag de statistiques du planificateur de journaux pour PostgreSQL |
|
Activer le flag "log_statement" pour PostgreSQL |
|
Activer le flag "Log Temp Files" pour l'instance PostgreSQL |
|
Non disponible |
|
Bloquer les adresses IP publiques pour les instances Cloud SQL |
|
Désactiver le flag d'accès à distance pour SQL Server |
|
Activer le chiffrement SSL sur les instances AlloyDB |
|
Activer le flag "skip_show_database" pour MySQL |
|
Activer l'indicateur de trace de base de données 3625 pour SQL Server |
|
Ne pas utiliser le flag "user connections" pour SQL Server |
|
Ne pas utiliser le flag d'options utilisateur pour SQL Server |
|
Non disponible |
|
Appliquer SSL pour toutes les connexions entrantes à la base de données |
|
Limiter à trois le nombre d'utilisateurs de clés cryptographiques KMS |
|
Activer l'accès uniforme au niveau du bucket sur les buckets Cloud Storage |
|
Restreindre les clés de compte de service gérées par l'utilisateur |
|
Non disponible |
|
Restreindre les stratégies SSL non sécurisées pour les instances Compute Engine |
|
Ne pas utiliser l'interface utilisateur Web de Kubernetes |
|
Activer la fédération d'identité de charge de travail pour GKE sur les clusters |