Commandes de base sécurisées pour les entreprises

Utilisez la contrainte booléenne automaticIamGrantsForDefaultServiceAccounts pour désactiver l'attribution automatique de rôles lorsque les services Cloud de Confiance by S3NS créent automatiquement des comptes de service par défaut avec des rôles trop permissifs.

Par défaut, certains systèmes accordent des autorisations trop larges aux comptes automatisés, ce qui constitue un risque de sécurité potentiel. Par exemple, si vous n'appliquez pas cette contrainte et que vous créez un compte de service par défaut, le rôle Éditeur (roles/editor) lui est automatiquement attribué sur votre projet. Si un pirate informatique parvient à compromettre une seule partie du système, il peut prendre le contrôle de l'ensemble du projet. Cette contrainte désactive ces autorisations automatiques de haut niveau, ce qui impose une approche plus sécurisée et délibérée où seules les autorisations minimales nécessaires sont accordées.

Utilisez la contrainte booléenne iam.disableServiceAccountKeyCreation pour désactiver la création de clés de compte de service externes. Cette contrainte vous permet de contrôler l'utilisation des identifiants à long terme non gérés pour les comptes de service. Lorsque cette contrainte est définie, vous ne pouvez pas créer d'identifiants gérés par l'utilisateur pour les comptes de service dans les projets concernés.

Utilisez la contrainte booléenne iam.disableServiceAccountKeyUpload pour désactiver l'importation de clés publiques externes dans des comptes de service. Lorsque cette contrainte est définie, les utilisateurs ne peuvent pas importer de clés publiques dans les comptes de service de projets affectés par la contrainte.

Google recommande les clés de sécurité Titan pour la validation en deux étapes des comptes super-administrateur. Toutefois, pour les cas d'utilisation où cela n'est pas possible, nous vous recommandons d'utiliser une autre clé de sécurité.

Appliquez la validation en deux étapes (2SV) pour une unité organisationnelle (UO) spécifique ou pour l'ensemble de l'organisation. Nous vous recommandons de créer une UO pour les super-administrateurs et d'y appliquer la validation en deux étapes.

Vous n'avez pas de super-administrateur ni d'administrateur de l'organisation unique. Créez un ou plusieurs comptes administrateur de secours (20 au maximum). Si vous n'avez qu'un seul super-administrateur ou administrateur de l'organisation, vous risquez de ne plus pouvoir accéder à votre compte. Cette situation présente également un risque plus élevé, car une seule personne peut apporter des modifications à la plate-forme, potentiellement sans surveillance.

Utilisez Privileged Access Manager pour gérer les accès privilégiés. Pour tous les autres accès, utilisez des groupes d'accès, laissez les abonnements aux groupes expirer automatiquement et mettez en place un workflow d'approbation pour les abonnements aux groupes.

Le modèle du moindre privilège vous permet de n'accorder l'accès qu'aux ressources nécessaires, et uniquement lorsque cela est nécessaire. L'utilisation de rôles prédéfinis simplifie l'utilisation et réduit l'expansion causée par les rôles personnalisés. Vous n'avez donc pas à vous soucier de la gestion du cycle de vie des rôles.

Choisissez votre source de vérité pour le provisionnement des identités des utilisateurs gérés. Les modèles incluent la création d'identités utilisateur dans Cloud Identity, la synchronisation des identités à partir d'un fournisseur d'identité existant ou l'utilisation de la fédération d'identité de personnel.

Appliquez des mots de passe uniques et sécurisés pour tous les comptes utilisateur. Envisagez d'utiliser un gestionnaire de mots de passe. Les identifiants faibles ou inexistants sont un schéma courant que les utilisateurs malveillants peuvent facilement exploiter.

Utilisez des rôles IAM (Identity and Access Management) basés sur les fonctions professionnelles pour attribuer des autorisations aux utilisateurs. Les fonctions sont des rôles prédéfinis qui permettent aux administrateurs de fournir un ensemble d'autorisations limitées à une fonction, ce qui améliore la productivité et réduit les allers-retours pour demander des autorisations. Pour mieux répondre aux exigences de votre organisation, vous pouvez créer des rôles personnalisés à partir de rôles prédéfinis.

Définissez des règles à l'échelle de l'organisation pour empêcher l'ajout de membres externes à des groupes Google.

Par défaut, les comptes utilisateur externes peuvent être ajoutés aux groupes dans Cloud Identity. Nous vous recommandons de configurer les paramètres de partage afin que les propriétaires de groupe ne puissent pas ajouter de membres externes.

Notez que cette restriction ne s'applique pas au compte super-administrateur ni aux autres administrateurs délégués disposant d'autorisations d'administrateur Google Groupes. Étant donné que la fédération de votre fournisseur d'identité s'exécute avec des droits d'administrateur, les paramètres de partage de groupe ne s'appliquent pas à cette synchronisation de groupe. Nous vous recommandons de vérifier les contrôles du fournisseur d'identité et du mécanisme de synchronisation pour vous assurer que les membres externes au domaine ne sont pas ajoutés aux groupes ou pour appliquer des restrictions de groupe.

Définissez la durée de session pour les services Cloud de Confiance by S3NS afin qu'elle expire au moins une fois par jour. Laisser un compte connecté pendant une longue période présente un risque pour la sécurité. L'application d'une durée de session maximale met automatiquement fin à la session après un certain temps, ce qui oblige l'utilisateur à se reconnecter de manière sécurisée.

Cette pratique réduit les chances qu'un utilisateur malveillant utilise un mot de passe volé et garantit que l'accès est régulièrement revérifié.

Pour les nouveaux clients, une durée de session par défaut de 16 heures est automatiquement appliquée. Les clients qui ont créé leur organisation Cloud de Confiance by S3NS avant 2023 peuvent avoir une configuration par défaut qui ne nécessite jamais de réauthentification. Vérifiez ce paramètre pour vous assurer que vous disposez d'une règle de réauthentification avec une durée de session comprise entre 1 et 24 heures. La règle de réauthentification annule la validation du jeton d'actualisation et oblige l'utilisateur à se réauthentifier régulièrement sur gcloud CLI avec son mot de passe ou sa clé de sécurité.

La durée de session pour les services Cloud de Confiance by S3NS est un paramètre distinct de la durée de session pour les services Google, qui contrôle les sessions Web pour la connexion aux services Google Workspace, mais ne contrôle pas la réauthentification pour Cloud de Confiance by S3NS. Si vous utilisez les services Google Workspace, définissez également la durée de session pour ceux-ci.

N'autorisez pas les comptes personnels non gérés. Regroupez tous les comptes personnels non gérés et envisagez une solution pour empêcher la création d'autres comptes personnels non gérés avec votre domaine.

Les comptes personnels non gérés ne sont pas régis par vos processus JML (Joiner-Mover-Leaver). Ils présentent donc le risque qu'un employé ait toujours accès à vos ressources après avoir quitté son poste. Ces comptes sont également traités comme externes en ce qui concerne les contrôles tels que le partage restreint au domaine.

Assurez-vous que les comptes super-administrateur sont distincts des comptes utilisateur quotidiens. Les comptes super-administrateur doivent être des comptes dédiés qui ne sont utilisés que pour apporter des modifications importantes. Pour renforcer la sécurité, activez l'approbation multipartite pour les actions d'administration. Si vous activez l'approbation multipartite, les actions sensibles doivent être approuvées par deux administrateurs. Cela permet d'empêcher les pirates informatiques de compromettre un compte administrateur et de bloquer l'accès aux autres administrateurs.

Activez l'authentification multifacteur (MFA), également appelée validation en deux étapes (2SV), pour tous les comptes Google et utilisateurs Cloud Identity, et pas seulement pour les super-administrateurs. L'MFA pour les super-administrateurs est activée par défaut. L'MFA ajoute une couche de protection supplémentaire, car les mots de passe seuls ne constituent souvent pas une mesure de sécurité suffisamment efficace.

Supprimez les rôles de créateur de projet et de créateur de compte de facturation à l'échelle du domaine qui sont attribués par défaut à tous les membres d'une nouvelle organisation.

Les nouvelles organisations accordent les rôles de créateur de projet et de créateur de compte de facturation à toutes les identités utilisateur gérées du domaine. Bien que ces rôles soient utiles pour commencer, cette configuration n'est pas destinée aux environnements de production. La prolifération des comptes de facturation entraîne une augmentation des frais administratifs et a des conséquences techniques lorsque les services sont répartis sur plusieurs comptes de facturation. Si vous autorisez la création de projets en mode forme libre, vous risquez de créer des projets qui ne respectent pas vos conventions de gouvernance.

Supprimez plutôt ces rôles et établissez un processus de création de projets pour demander de nouveaux projets et les associer à la facturation.

Si vous devez utiliser des clés de compte de service, alternez-les au moins une fois tous les 90 jours.

Un intervalle de rotation limite la durée pendant laquelle un pirate informatique peut avoir accès au système. Sans intervalle de rotation, l'attaquant a un accès permanent. Si possible, envisagez d'utiliser la fédération d'identité de charge de travail au lieu des clés de compte de service.

Utilisez la fédération d'identité de charge de travail pour permettre aux systèmes CI/CD et aux charges de travail exécutées sur d'autres clouds de s'authentifier auprès de Cloud de Confiance by S3NS. La fédération d'identité de charge de travail permet aux charges de travail exécutées en dehors de Cloud de Confiance de s'authentifier sans avoir besoin d'une clé de compte de service. En évitant les clés de compte de service et les autres identifiants de longue durée, la fédération d'identité de charge de travail peut vous aider à réduire le risque de fuite d'identifiants.

Par défaut, l'autorécupération de compte super-administrateur est désactivée pour les nouveaux clients. Toutefois, il est possible que les clients existants aient activé ce paramètre. La désactivation de ce paramètre permet de limiter le risque qu'un téléphone compromis, une adresse e-mail compromise ou une attaque par ingénierie sociale puisse permettre à un pirate informatique d'obtenir des droits de super-administrateur sur votre environnement.

Planifiez un processus interne pour un super-administrateur afin de contacter un autre super-administrateur de votre organisation s'il a perdu l'accès à son compte, et assurez-vous que tous les super-administrateurs sont familiarisés avec le processus de récupération assistée.

Pour désactiver cette fonctionnalité, accédez aux paramètres de récupération de compte dans la console d'administration Google.

Définissez le délai avant expiration de la session sur 15 minutes pour les cas d'utilisation sensibles. Les pirates informatiques peuvent utiliser les sessions inactives pour voler des identifiants.

Si possible, fournissez des clés de sécurité matérielles aux super-administrateurs ou aux administrateurs de l'organisation comme deuxième facteur. Les comptes de super-administrateur sont les cibles les plus intéressantes pour les attaques sophistiquées. Les clés de sécurité matérielles offrent un niveau de protection élevé, car elles résistent à l'hameçonnage. Les clés de sécurité matérielles constituent la protection la plus efficace possible contre la prise de contrôle de compte pour vos administrateurs les plus importants. Elles s'appuient sur votre règle standard de MFA.

Si vous utilisez un fournisseur d'identité externe, configurez la validation post-authentification unique.

Activez un niveau de contrôle supplémentaire basé sur l'analyse des risques de connexion Google. Après l'application de ce paramètre, les utilisateurs peuvent voir des questions d'authentification en cas de risque de sécurité supplémentaires lors de la connexion, si Google estime qu'elle est suspecte.

Activez les stratégies de limites d'accès des principaux (PAB) pour limiter l'accès des principaux et vous protéger contre le hameçonnage et l'exfiltration de données. Activez une stratégie PAB pour l'organisation afin d'éviter les attaques par hameçonnage externes. Les PAB améliorent la sécurité en réduisant l'ampleur d'une attaque avec une identité compromise. Ils permettent également d'éviter les attaques d'hameçonnage externes et autres attaques d'exfiltration.

Les tags permettent de créer des annotations pour les ressources et, dans certains cas, d'autoriser ou de refuser des règles de manière conditionnelle selon qu'une ressource possède un tag spécifique ou non. Utilisez les tags et l'application conditionnelle de règles pour un contrôle ultraprécis de votre hiérarchie de ressources.

Utilisez Cloud Audit Logs pour surveiller les activités à haut risque, comme l'attribution de rôles à haut risque (administrateur de l'organisation ou super-administrateur, par exemple) à des comptes. Configurez des alertes pour ce type d'activité.

Pour éviter d'accorder un accès excessif à Cloud de Confiance by S3NS, bloquez l'accès à Cloud Shell pour les comptes utilisateur gérés Cloud Identity.

Grâce à l'accès contextuel, vous pouvez créer des règles de sécurité précises pour le contrôle des accès aux applications, sur la base d'attributs comme l'identité des utilisateurs, le lieu, le niveau de sécurité des appareils et l'adresse IP. Nous vous recommandons d'utiliser l'accès contextuel pour limiter l'accès à la console Cloud de Confiance (https://console.cloud.google.com/) et à la console d'administration Google (https://admin.cloud.google.com).

Cloud de Confiance est compatible avec plusieurs versions du protocole TLS. Pour répondre aux exigences de conformité, vous pouvez refuser les demandes de handshake des clients qui utilisent d'anciennes versions de TLS.

Pour configurer ce contrôle, utilisez la contrainte de règle d'administration Limiter les versions TLS (gcp.restrictTLSVersion). Vous pouvez appliquer cette contrainte aux organisations, aux dossiers ou aux projets de la hiérarchie des ressources. La contrainte Restreindre les versions TLS utilise une liste d'interdiction, qui refuse les valeurs explicites et autorise toutes les autres. Une erreur se produit si vous essayez d'utiliser une liste d'autorisation.

En raison du comportement de l'évaluation de la hiérarchie des règles d'administration, la restriction de version TLS s'applique au nœud de ressource spécifié et à tous ses dossiers et projets (enfants). Par exemple, si vous refusez la version 1.0 de TLS pour une organisation, elle est également refusée pour tous les enfants qui en dépendent.

Vous pouvez remplacer la restriction de version TLS héritée en modifiant la règle d'administration sur une ressource enfant. Par exemple, si votre règle d'administration refuse TLS 1.0 au niveau de l'organisation, vous pouvez supprimer la restriction pour un dossier enfant en définissant une règle d'administration distincte pour ce dossier. Si le dossier comporte des enfants, la règle du dossier sera également appliquée à chaque ressource enfant en raison de l'héritage des règles.

Pour limiter davantage la version TLS à TLS 1.3 uniquement, vous pouvez définir cette règle pour limiter également la version TLS 1.2. Vous devez implémenter ce contrôle sur les applications que vous hébergez dans Cloud de Confiance by S3NS. Par exemple, au niveau de l'organisation, définissez :

["TLS_VERSION_1","TLS_VERSION_1.1","TLS_VERSION_1.2"]

Assurez-vous que seules les identités de votre organisation sont autorisées dans votre environnement Cloud de Confiance by S3NS . Utilisez la contrainte de règle d'administration Partage restreint au domaine (iam.allowedPolicyMemberDomains) ou iam.managed.allowedPolicyMembers pour définir un ou plusieurs ID client Cloud Identity ou Google Workspace dont les comptes principaux peuvent être ajoutés aux stratégies Identity and Access Management (IAM).

Ces contraintes permettent d'empêcher les employés d'accorder l'accès à des comptes externes qui ne respectent pas vos règles de sécurité concernant l'authentification multifacteur (MFA) ou la gestion des mots de passe et qui ne sont pas contrôlés par votre organisation. Ce contrôle est essentiel pour empêcher les accès non autorisés et s'assurer que seules les identités d'entreprise gérées et fiables peuvent être utilisées.

La contrainte gcp.restrictServiceUsage garantit que seuls vos services Cloud de Confiance by S3NS approuvés sont utilisés aux bons endroits. Par exemple, un dossier de production ou très sensible comporte une petite liste de services Cloud de Confiance autorisés à stocker des données. Un dossier sandbox peut contenir une liste plus longue de services et de contrôles de sécurité des données associés pour empêcher l'exfiltration de données. La valeur est spécifique à vos systèmes et correspond à la liste approuvée de services et de dépendances pour des dossiers et projets spécifiques.

Cette contrainte permet à votre organisation de créer une liste d'autorisation des services approuvés, ce qui permet d'empêcher les employés d'utiliser des services non vérifiés.

La contrainte de restriction d'emplacement des ressources (gcp.resourceLocations) garantit que seules les régions Cloud de Confiance by S3NS approuvées sont utilisées pour stocker les données. La valeur est spécifique à vos systèmes et correspond à la liste des régions approuvées par votre organisation pour la résidence des données.

Cette contrainte permet à votre organisation de s'assurer que vos ressources et vos données ne sont créées et enregistrées que dans des régions géographiques spécifiques approuvées.

La contrainte booléenne compute.skipDefaultNetworkCreation permet d'ignorer la création du réseau par défaut et des ressources associées lors de la création de projets Cloud de Confiance by S3NS .

Le réseau par défaut est un réseau cloud privé virtuel (VPC) en mode automatique avec des règles de pare-feu IPv4 préremplies pour autoriser les chemins de communication internes. En règle générale, cette configuration n'est pas recommandée pour la sécurité des environnements de production.

Les extensions de sécurité DNS (DNSSEC, Domain Name System Security Extensions) sont une fonctionnalité du système DNS qui authentifie les réponses aux recherches de noms de domaine. Elle n'offre aucune protection de la confidentialité pour ces recherches, mais empêche les pirates informatiques de manipuler ou de contaminer les réponses aux requêtes DNS.

Dans Cloud DNS, activez DNSSEC aux emplacements suivants :

• Zone DNS
• Domaine de premier niveau (TLD)
• Résolution DNS

Activez l'accès privé à Google sur tous les sous-réseaux.

Activez l'accès aux services privés pour créer un réseau privé entre les services Cloud de Confiance by S3NS , tels que les anciens réseaux Google Cloud VMware Engine et les producteurs de services tels que Cloud SQL. L'accès privé aux services permet d'éviter d'exposer inutilement les connexions réseau des charges de travail à Internet.

Désactivez la création de sous-réseaux IPv6 externes, sauf si cela est spécifiquement requis. Pour réduire votre surface d'attaque, envisagez de désactiver IPv6 sur les systèmes et réseaux où il n'est pas géré activement ni requis. De nombreuses organisations disposent de contrôles et d'une surveillance de sécurité matures pour IPv4, mais leurs outils et règles ne s'étendent peut-être pas entièrement à IPv6, ce qui peut créer un angle mort important pour les menaces. L'exécution d'un réseau à double pile introduit également une complexité opérationnelle, nécessitant des configurations et une expertise spécifiques pour gérer et résoudre efficacement les problèmes. Par conséquent, si vous n'avez pas de raison commerciale claire d'utiliser IPv6, le désactiver peut simplifier votre environnement et garantir que tout le trafic est filtré de manière cohérente par votre posture de sécurité IPv4 établie.

Limitez l'accès aux sources externes, car par défaut, tous les accès sortants sont autorisés. Définissez des règles de pare-feu spécifiques pour les modèles de trafic sortant prévus.

Par défaut, les systèmes sont souvent autorisés à établir des connexions sortantes à Internet, ce qui peut être considéré comme un risque pour la sécurité. Une règle de refus par défaut bloque le trafic sortant et nécessite la création de règles spécifiques pour les destinations connues et nécessaires uniquement.

Dans la mesure du possible, limitez l'accès entrant à des ressources et des plages de ressources spécifiques uniquement. Si Identity-Aware Proxy (IAP) est configuré, définissez les règles de pare-feu SSH et RDP (Remote Desktop Protocol) entrants sur les plages d'adresses IP IAP en tant que sources.

Les règles de pare-feu SSH et RDP permissives permettent les attaques par force brute. Utilisez plutôt des proxys compatibles avec l'identité (comme IAP) pour SSH et RDP. Cloud de Confiance by S3NS

Activez VPC Service Controls comme couche de protection supplémentaire pour éviter toute perte de données potentielle.

VPC Service Controls peut vous aider à empêcher l'exfiltration de données en créant des périmètres d'isolation autour de vos ressources cloud, de vos données sensibles et de vos réseaux.

Le périmètre de service limite l'utilité des identifiants compromis, car il bloque les requêtes adressées à des services restreints provenant de points de terminaison contrôlés par le pirate informatique et extérieurs à votre environnement.

Pour les applications exposées derrière Cloud Load Balancing, utilisez les règles par défaut de Google Cloud Armor ou configurez vos propres règles pour ajouter une protection réseau de couche 3 à 7 pour les applications ou services externes. Les règles de sécurité Cloud Armor protègent votre application en fournissant un filtrage de couche 7. Ces règles examinent également les requêtes entrantes pour les attaques Web courantes ou d'autres attributs de couche 7 afin de bloquer potentiellement le trafic avant qu'il n'atteigne vos services de backend à équilibrage de charge ou vos buckets de backend. Chaque stratégie de sécurité est composée d'un ensemble de règles qui incluent des attributs des couches 3 à 7.

Pour chaque périmètre de service, vérifiez dans la console Cloud de Confiance que le type de périmètre est défini sur "Standard".

Pour chaque périmètre de service, utilisez Access Context Manager pour confirmer que le périmètre protège l'API.

La contrainte booléenne compute.setNewProjectDefaultToZonalDNSOnly vous permet de définir le paramètre DNS interne des nouveaux projets sur le DNS zonal uniquement. Utilisez le DNS zonal, car il offre une fiabilité supérieure à celle des zones individuelles, car il isole les défaillances de l'enregistrement DNS .

Si vous utilisez Cloud Identity, partagez les journaux d'audit de Cloud Identity avec Cloud de Confiance by S3NS.

En règle générale, les journaux d'audit pour les activités d'administration de Google Workspace ou Cloud Identity sont affichés et gérés dans la console d'administration Google, séparément de vos journaux dans votre environnement Cloud de Confiance . Ces journaux contiennent des informations pertinentes pour votre environnement Cloud de Confiance , telles que des événements de connexion utilisateur.

Nous vous recommandons de partager les journaux d'audit Cloud Identity avec votre environnement Cloud de Confiance pour gérer les journaux de manière centralisée à partir de toutes les sources.

Les servicesCloud de Confiance génèrent des entrées dans les journaux d'audit pour répondre à la question "qui a fait quoi, où et quand ?" avec les ressources Cloud de Confiance .

Activez la journalisation d'audit au niveau de l'organisation. Vous pouvez configurer la journalisation à l'aide du pipeline que vous utilisez pour configurer l'organisation Cloud de Confiance .

Les journaux de flux VPC enregistrent un échantillon des flux réseau envoyés et reçus par les instances de VM, y compris celles utilisées comme nœuds Google Kubernetes Engine (GKE). Il correspond généralement à 50% ou moins des flux du réseau VPC.

Lorsque vous activez les journaux de flux VPC, vous activez la journalisation pour toutes les VM d'un sous-réseau. Cependant, vous pouvez réduire la quantité d'informations écrites dans Logging.

Activez les journaux de flux VPC pour chaque sous-réseau VPC. Vous pouvez configurer la journalisation à l'aide d'un pipeline que vous utilisez pour créer un projet.

Par défaut, les règles de pare-feu n'écrivent pas automatiquement de journaux.La journalisation des règles de pare-feu vous permet d'auditer, de vérifier et d'analyser les effets de vos règles de pare-feu. Par exemple, vous pouvez déterminer si une règle de pare-feu conçue pour refuser le trafic fonctionne comme prévu. La journalisation est également utile si vous souhaitez déterminer le nombre de connexions affectées par une règle de pare-feu donnée.

Activez la journalisation pour chaque règle de pare-feu. Vous pouvez configurer la journalisation à l'aide d'un pipeline que vous utilisez pour créer un pare-feu.

Par défaut, Cloud de Confiance active l'audit des activités d'administration clés pour les comptes privilégiés et ne permet à personne de le désactiver.

Les journaux d'audit des activités d'administration contiennent des entrées relatives aux appels d'API et autres opérations qui modifient la configuration ou les métadonnées des ressources. Par exemple, ils enregistrent les actions de création d'instances de VM ou de modification des autorisations IAM.

Les journaux d'audit des activités d'administration contiennent des entrées de journal pour la création, la modification et la suppression des contraintes de règles de l'organisation au niveau d'une organisation, d'un dossier et d'un projet.

Les journaux d'audit des activités d'administration sont toujours écrits. Vous ne pouvez pas les configurer, ni les exclure, ni les désactiver. Même si vous désactivez l'API Cloud Logging, les journaux d'audit des activités d'administration sont toujours générés.

Nous recommandons à votre organisation de configurer des règles et des procédures pour surveiller ces alertes, et de générer des actions ou des alertes en fonction de vos règles d'accès à l'entreprise pour surveiller les activités des administrateurs.

Abonnez-vous aux notifications des bulletin de sécurité pour les services Cloud de Confiance by S3NS afin de recevoir des alertes sur les failles et les mesures d'atténuation.

Lorsque des bulletins de sécurité sont disponibles et concernent votre service Cloud de Confiance by S3NS (comme GKE), le service peut publier des notifications sur ces événements sous forme de messages dans les sujets Pub/Sub que vous configurez. Vous pouvez recevoir ces notifications sur un abonnement Pub/Sub, les intégrer à des services tiers et filtrer les types de notifications que vous souhaitez recevoir.

Configurez les contacts essentiels pour vous assurer qu'un alias de groupe ou une liste de diffusion surveillés reçoivent les notifications importantes.

L'utilisation d'une adresse e-mail de groupe surveillée permet de s'assurer que ces alertes urgentes sont envoyées à une équipe active qui peut réagir rapidement.

Utilisez la fonctionnalité d'anomalies de facturation dans Cloud Billing pour suivre les pics ou les écarts de dépenses par rapport aux prévisions.

Une augmentation soudaine et inattendue de la facture cloud est un indicateur principal de compromission de la sécurité. Des pics de facturation inattendus sont parfois causés par des pirates informatiques qui ont obtenu l'accès et utilisent des ressources pour des activités non autorisées.

L'activation de la détection des anomalies de facturation fournit un système d'alerte précoce essentiel qui vous permet de signaler automatiquement cette activité suspecte.

Créez un récepteur de journaux pour exporter les journaux de votre solution de surveillance de la sécurité et définissez la période de conservation en fonction de vos besoins.

Les périodes de conservation des journaux par défaut ne sont souvent pas assez longues pour répondre aux exigences de conformité (de 1 à 7 ans) imposées par des réglementations telles que PCI ou HIPAA.

La création d'un récepteur de journaux pour exporter les journaux vers un emplacement de stockage à long terme est essentielle pour répondre à certaines obligations légales et réglementaires. Les récepteurs de journaux vous permettent également d'envoyer des journaux à un système de surveillance de la sécurité centralisé pour une détection avancée des menaces.

Pour savoir qui a accédé aux données dans votre environnement Cloud de Confiance by S3NS , activez les journaux d'audit des accès aux données. Ces journaux enregistrent les appels d'API qui lisent, créent ou modifient les données utilisateur, ainsi que les appels d'API qui lisent les configurations de ressources.

Nous vous recommandons vivement d'activer les journaux d'audit d'accès aux données pour les modèles d'IA générative et les données sensibles afin de pouvoir vérifier qui a lu les informations. Pour utiliser les journaux d'audit pour l'accès aux données, vous devez configurer votre propre logique de détection personnalisée pour des activités spécifiques, comme les connexions de super-administrateurs.

Le volume des journaux d'audit pour l'accès aux données peut être important. Lorsque vous activez les journaux d'accès aux données, l'utilisation de journaux supplémentaires peut être facturée pour votre projet Cloud de Confiance .

Évitez les mauvaises surprises sur votre facture en créant des budgets Cloud Billing pour surveiller tous vos frais Cloud de Confiance by S3NS depuis un seul et même endroit. Une fois que vous avez fixé un montant pour votre budget, définissez les règles fixant des seuils d'alertes budgétaires pour chaque projet afin de déclencher des notifications par e-mail. Ces notifications vous aident à suivre vos dépenses par rapport à votre budget. Vous pouvez également utiliser les budgets Cloud Billing pour automatiser les réponses de contrôle des coûts.

Les journaux standards vous indiquent ce que font les utilisateurs de votre organisation, tandis que les journaux Access Transparency indiquent ce que fait le personnel de l'assistance Google lorsqu'il accède au compte. Cet accès n'est généralement accordé qu'en réponse à une demande d'assistance. Les journaux Access Transparency fournissent une piste d'audit complète et vérifiable de tous les accès, ce qui est essentiel pour répondre aux exigences strictes en termes de conformité et de gouvernance des données.

Vous pouvez activer Access Transparency au niveau de l'organisation.

Pour une analyse plus approfondie de la facturation, vous pouvez exporter Cloud de Confiance by S3NS les données de facturation vers BigQuery ou un fichier JSON. Par exemple, vous pouvez exporter automatiquement des données détaillées (comme l'utilisation, les estimations de coûts et les tarifs) tout au long de la journée vers un ensemble de données BigQuery que vous spécifiez. Vous pouvez ensuite accéder à vos données Cloud Billing depuis BigQuery pour une analyse détaillée ou utiliser un outil tel que Data Studio pour les visualiser.

Toutes les données de Cloud de Confiance sont chiffrées au repos par défaut à l'aide d'algorithmes approuvés par le NIST.

Assurez-vous que Cloud Key Management Service (Cloud KMS) n'utilise que des algorithmes approuvés par le NIST pour stocker les clés sensibles dans l'environnement. Ce contrôle garantit une utilisation sécurisée des clés en n'autorisant que les algorithmes et les mesures de sécurité approuvés par le NIST. Le champ CryptoKeyVersionAlgorithm est une liste d'autorisation fournie.

Supprimez les algorithmes qui ne respectent pas les règles de votre organisation.

Définissez l'objectif des clés Cloud KMS sur ENCRYPT_DECRYPT afin que les clés ne soient utilisées que pour chiffrer et déchiffrer les données. Ce contrôle bloque d'autres fonctions, telles que la signature, et garantit que les clés ne sont utilisées que pour l'objectif prévu. Si vous utilisez des clés pour d'autres fonctions, validez ces cas d'utilisation et envisagez de créer des clés supplémentaires.

Le niveau de protection indique comment sont effectuées les opérations de chiffrement. Une fois que vous avez créé une clé de chiffrement gérée par le client (CMEK), vous ne pouvez plus modifier le niveau de protection. Voici les niveaux de protection acceptés :

• LOGICIEL : les opérations de chiffrement sont effectuées dans le logiciel.
• HSM : les opérations de chiffrement sont effectuées dans un module de sécurité matériel (HSM).
• EXTERNAL : les opérations de chiffrement sont effectuées à l'aide d'une clé stockée dans un gestionnaire de clés externe connecté à Cloud de Confiance via Internet. Limité au chiffrement symétrique et à la signature asymétrique.
• EXTERNAL_VPC: : les opérations de chiffrement sont effectuées à l'aide d'une clé stockée dans un gestionnaire de clés externe connecté à Cloud de Confiance via un réseau de cloud privé virtuel (VPC). Limité au chiffrement symétrique et à la signature asymétrique.

Assurez-vous que la période de rotation de vos clés Cloud KMS est définie sur 90 jours. Une bonne pratique générale consiste à alterner régulièrement vos clés de sécurité. Cette commande applique la rotation des clés créées avec les services HSM.

Lorsque vous créez cette période de rotation, créez également des règles et des procédures appropriées pour gérer de manière sécurisée la création, la suppression et la modification du matériel de clé afin de protéger vos informations et d'assurer leur disponibilité. Assurez-vous que cette période respecte les règles de votre entreprise concernant la rotation des clés.

Créez une stratégie de gestion du chiffrement à l'aide de Cloud Key Management Service (Cloud KMS) avec Autokey, Cloud External Key Manager (Cloud EKM) ou les deux. Cette stratégie permet à votre organisation d'utiliser et de gérer ses propres clés de chiffrement pour répondre à vos besoins spécifiques. L'utilisation de vos propres clés de chiffrement vous permet de contrôler l'accès aux données de manière précise et auditable, y compris en bloquant immédiatement l'accès aux données en désactivant la clé.

Utilisez la contrainte de règle d'administration Limiter les projets susceptibles de fournir des CryptoKeys KMS pour CMEK (gcp.restrictCmekCryptoKeyProjects) pour définir les projets pouvant stocker des clés de chiffrement gérées par le client (CMEK). Cette contrainte vous permet de centraliser la gouvernance et la gestion des clés de chiffrement. Si une clé sélectionnée ne respecte pas cette contrainte, la création de la ressource échoue.

Pour modifier cette contrainte, les administrateurs ont besoin du rôle IAM Administrateur des règles d'administration (roles/orgpolicy.policyAdmin).

Si vous souhaitez ajouter une deuxième couche de protection, comme "Apportez votre propre clé", modifiez cette contrainte pour représenter les noms de clés de la clé CMEK activée.

Spécificités du produit :

• Dans Gemini Enterprise Agent Platform, vous stockez vos clés dans le projet PROJETS DE CLÉS.

Si vous avez besoin de davantage de contrôle sur les opérations de clé que ne le permet Google Cloud-powered encryption keys , vous pouvez utiliser les clés de chiffrement gérées par le client (CMEK). Ces clés sont créées et gérées à l'aide de Cloud KMS. Stockez les clés sous forme de clés logicielles, dans un cluster HSM ou dans un système de gestion de clés externe.

Les taux de chiffrement et de déchiffrement de Cloud KMS sont soumis à des quotas.

Spécificités de Cloud Storage

Dans Cloud Storage, utilisez des CMEK sur des objets individuels ou configurez vos buckets Cloud Storage pour qu'ils utilisent une CMEK par défaut sur tous les nouveaux objets ajoutés à un bucket. Lorsque vous utilisez une clé CMEK, un objet est chiffré avec la clé par Cloud Storage au moment de son stockage dans un bucket. L'objet est automatiquement déchiffré par Cloud Storage lorsqu'il est destiné aux demandeurs.

Les restrictions suivantes s'appliquent lorsque vous utilisez des clés CMEK avec Cloud Storage :

• Vous ne pouvez pas chiffrer un objet avec une clé CMEK en mettant à jour les métadonnées de cet objet. À la place, incluez la clé dans le cadre d'une réécriture de l'objet.
• Votre Cloud Storage utilise la commande d'actualisation des objets pour définir des clés de chiffrement sur les objets, mais la commande réécrit l'objet dans le cadre de la requête.
• Vous devez créer le trousseau de clés Cloud KMS au même emplacement que celui des données que vous souhaitez chiffrer. Par exemple, si votre bucket est situé dans us-east1, les trousseaux de clés utilisés pour chiffrer des objets dans ce bucket doivent également être créés dans us-east1.
• Pour la plupart des régions doubles, vous devez créer le trousseau de clés Cloud KMS dans la région multirégionale associée. Par exemple, si votre bucket est situé dans la paire us-east1, us-west1, tout trousseau de clés utilisé pour chiffrer des objets dans ce bucket doit être créé dans la multirégion des États-Unis.
• Pour les emplacements birégionaux prédéfinis asia1, eur4 et nam4, vous devez créer le trousseau de clés dans le même emplacement birégional prédéfini.
• La somme de contrôle CRC32C et le hachage MD5 des objets chiffrés avec des clés CMEK ne sont pas renvoyés lorsque vous listez des objets avec l'API JSON.
• L'utilisation d'outils tels que Cloud Storage pour effectuer des requêtes GET de métadonnées supplémentaires sur chaque objet de chiffrement afin de récupérer les informations CRC32C et MD5 peut réduire considérablement la durée de l'opération de listage. Cloud Storage ne peut pas utiliser la partie servant au déchiffrement des clés asymétriques stockées dans Cloud KMS pour déchiffrer automatiquement les objets concernés de la même manière que les CMEK.