Ce document décrit les implémentations de niveau d'accès et fournit des recommandations pour lancer l'application forcée des périmètres de service en fonction des listes d'autorisation.
Lorsque vous effectuez une exécution dry run (test à blanc) des charges de travail, vous identifiez la liste des adresses IP et des identités que vous devez ajouter à une liste d'autorisation. Vous pouvez également constater que certaines charges de travail nécessitent une liste d'autorisation basée sur un appareil. Pour accorder un accès contrôlé aux ressources Google Cloud protégées, vous pouvez utiliser les niveaux d'accès de VPC Service Controls. Vous pouvez implémenter des niveaux d'accès en fonction de l'adresse IP, de l'identité ou de l'appareil.
Pour en savoir plus, consultez Accès contextuel avec des règles d'entrée.
Accorder un accès en fonction de l'adresse IP source
Vous ne pouvez utiliser que des plages CIDR d'adresses IP publiques dans les niveaux d'accès des listes d'autorisation basées sur l'adresse IP. Étant donné que cette méthode autorise toutes les API protégées de cette plage d'adresses IP, l'environnement derrière ces adresses IP doit être approuvé et contrôlé. Un scénario d'utilisation typique de cette liste d'autorisation consiste à autoriser l'accès au périmètre à partir de réseaux sur site. Le schéma suivant montre comment une liste d'autorisations basée sur les adresses IP bloque et autorise l'accès au périmètre :
Dans le schéma précédent, une identité valide tente d'accéder au périmètre. Les tentatives d'accès sont refusées si elles proviennent d'une adresse IP Internet. Cependant, l'accès est autorisé lorsqu'il provient des adresses IP publiques de l'entreprise.
Une variante de ce scénario se produit lorsque vous autorisez l'accès au périmètre à partir de ressources privées déployées dans un autre projet ou une autre organisation. Dans ce cas d'utilisation, une passerelle Cloud NAT est requise dans le projet source.
Cloud NAT est intégré à l'accès privé à Google, ce qui permet d'activer automatiquement l'accès privé à Google sur le sous-réseau de la ressource et de maintenir le trafic vers les API et services Google en interne, au lieu de l'acheminer vers Internet à l'aide de l'adresse IP externe de la passerelle Cloud NAT.
Comme le trafic est acheminé dans le réseau Google interne, le champ RequestMetadata.caller_ip de l'objet AuditLog est masqué et remplacé par gce-internal-ip. Pour autoriser l'accès au périmètre dans ce cas, vous devez configurer une règle d'entrée pour autoriser l'accès en fonction d'autres attributs tels que le projet ou le compte de service, au lieu de configurer un niveau d'accès basé sur l'adresse IP source externe.
Accorder un accès en fonction de l'identité de l'appelant
Pour implémenter une liste d'autorisation basée sur l'identité, vous ajoutez des comptes de service et des super-administrateurs d'organisation à une liste d'autorisation. Le périmètre est ouvert à ces identités à partir de n'importe quelle adresse IP. Vous devez donc vous assurer que les identités sont correctement protégées. Vous devez également veiller à éviter les générations de clés pour les comptes de service que vous avez ajoutés à une liste d'autorisation. Il est rare d'ajouter des identités d'utilisateur à une liste d'autorisation (les groupes ne peuvent pas être ajoutés à une liste d'autorisation) sur un périmètre.
Les ressources du périmètre sont accessibles via des VM au sein du périmètre, depuis des réseaux sur site approuvés ou depuis des appareils approuvés. Nous vous recommandons d'utiliser Cloud Workstations pour accéder aux ressources dans les périmètres, car VPC Service Controls n'est pas compatible avec Cloud Shell.
Conditionner l'accès en fonction des attributs de l'appareil de l'appelant
La confiance des appareils, également appelée point de terminaison de confiance, repose sur le fait qu'un utilisateur d'organisation valide soit connecté à un navigateur Chrome ou à un Chromebook. La confiance s'applique à la session connectée au système d'exploitation. Par exemple, un utilisateur Windows qui est connecté et exécute une session Chrome (le navigateur n'a pas besoin d'être ouvert) peut appeler les commandes de la gcloud CLI sur les API de périmètre protégées. Toutefois, une autre session utilisateur Windows sur la même machine ne peut pas appeler des commandes sur les API de périmètre protégées.
Les conditions relatives aux appareils suivantes sont utiles pour établir la confiance des appareils :
Chrome OS validé est une condition hautement sécurisée et cryptographique qui indique qu'un utilisateur d'organisation valide est connecté à un Chromebook démarré de manière sécurisée. Il s'agit d'une condition de confiance recommandée de niveau 1.
L'option Exiger l'approbation de l'administrateur pour l'accès de l'appareil permet aux administrateurs Cloud Identity d'approuver chaque appareil avant toute autorisation d'accès. Par défaut, les appareils sont approuvés automatiquement si un utilisateur valide de l'organisation est connecté. Toutefois, nous vous recommandons de désactiver l'option d'approbation automatique.
Exiger un appareil détenu par l'entreprise s'appuie sur l'agent Chrome et sa capacité à récupérer le numéro de série du système d'exploitation, généralement fourni par le BIOS. Ce numéro doit correspondre aux numéros de série existants que vous avez saisis dans Cloud Identity.
Comme le numéro de série ne fait pas autorité sur des appareils autres que Chrome OS, un utilisateur disposant de droits d'administrateur élevés peut éventuellement falsifier le numéro de série. Nous vous recommandons d'utiliser cette condition uniquement comme vérification de niveau 2.
Pour accéder à un exemple d'outil de suivi permettant d'accorder un accès contrôlé selon les conditions décrites dans la liste précédente, consultez Modèle d'intégration de VPC Service Controls – liste d'autorisation (PDF).
Lancer l'application forcée
Une fois que vous avez conçu la liste d'autorisation et mis à jour les niveaux d'accès, nous vous recommandons d'exécuter de nouveau les charges de travail pour vérifier l'absence de cas de non-respect. Si les charges de travail s'exécutent sans cas de non-respect, vous pouvez lancer l'application forcée de VPC Service Controls sans impacter les applications.
Lorsque vous planifiez une application forcée, incluez les éléments suivants :
- Choisissez une date d'application forcée et communiquez cette date à toutes les équipes concernées.
- Assurez-vous que les équipes chargées des opérations de sécurité et des réponses aux incidents sont informées du déploiement. Assurez-vous également que les personnes disposant des autorisations appropriées inspectent les journaux et approuvent les listes d'autorisation supplémentaires, si nécessaire.
- Assurez-vous que l'équipe de gestion des situations de crise peut ouvrir une demande d'assistance Google Clouden cas de question ou de problème.
- Créez ou modifiez les périmètres et les niveaux d'accès à l'aide d'outils d'automatisation tels que Terraform. Nous vous déconseillons d'effectuer ces tâches manuellement.
Lorsque vous lancez l'application forcée, commencez par déplacer les projets associés à une seule charge de travail depuis le périmètre de dry run vers le périmètre actif. Veillez à laisser le temps à l'application de s'exécuter correctement pendant que vous observez les journaux des cas de non-respect. Répétez le processus pour les charges de travail restantes une par une.
Pour mettre en évidence les cas de non-respect bloqués, configurez un récepteur de journaux agrégé qui envoie les journaux d'audit de tous les projets du périmètre à BigQuery. Exécutez ensuite la requête suivante :
SELECT
receiveTimestamp, #time of violation
Resource.labels.service, #protected Google Cloud service being blocked
protopayload_auditlog.methodName, #method name being called
resource.labels.project_id as PROJECT, #protected project blocking the call
protopayload_auditlog.authenticationInfo.principalEmail, #caller identity
protopayload_auditlog.requestMetadata.callerIp, #caller IP
JSON_EXTRACT(protopayload_auditlog.metadataJson, '$.dryRun') as DRYRUN, #dry-run indicator
JSON_EXTRACT(protopayload_auditlog.metadataJson, '$.violationReason') as REASON, #reason for violation
protopayload_auditlog.metadataJson, #raw violation entry
FROM `BQ_DATASOURCE_NAME.cloudaudit_googleapis_com_policy_*`
WHERE JSON_EXTRACT(protopayload_auditlog.metadataJson, '$.dryRun') is null #exclude logs from a dry-run perimeter
Étapes suivantes
- Découvrez comment autoriser l'accès aux ressources protégées depuis l'extérieur du périmètre.
- Découvrez comment lister, modifier et supprimer des périmètres de service.