Ce document décrit les implémentations de niveau d'accès et fournit recommandations pour lancer l'application du périmètre de service en fonction et listes d'autorisation.
Lorsque vous exécutez une simulation des charges de travail, vous identifiez la liste des adresses IP et des identités à 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 mettre en œuvre 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. Puisque cette méthode permet à tous protégées de cette plage d'adresses IP, l'environnement derrière ces adresses IP doit être fiables et contrôlées. Un scénario d'utilisation typique de cette liste d'autorisations 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 cette utilisation
une passerelle Cloud NAT
est requise dans le projet source.
Cloud NAT
dispose d'une intégration avec l'accès privé à Google.
qui active automatiquement l'accès privé à Google
sur le sous-réseau de la ressource,
et maintient le trafic vers les API et services Google en interne, au lieu de router
à Internet à l'aide de l'adresse IP externe
de la passerelle Cloud NAT.
Comme le trafic est acheminé à l'intérieur du réseau Google interne,
Le champ RequestMetadata.caller_ip de l'objet AuditLog est masqué
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 en fonction de l'adresse IP source externe.
Accorder un accès en fonction de l'identité de l'appelant
Pour mettre en œuvre 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 clés de génération 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'autorisations (les groupes ne peuvent pas être ajoutés à une liste d'autorisations) sur un périmètre.
Les ressources du périmètre sont accessibles via des VM au sein du depuis des réseaux sur site de confiance ou des appareils vérifié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.
Faire certifier l'accès en fonction des attributs des appareils appartenant à 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 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.
Voici les conditions liées aux appareils nécessaires 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 de niveau 1 recommandée.
L'option Exiger l'approbation de l'administrateur pour accéder aux appareils permet aux administrateurs Cloud Identity d'approuver chaque appareil avant toute autorisation d'accès. Par défaut, les appareils sont approuvés automatiquement s'ils disposent d'un utilisateur valide de l'organisation. 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 qui récupère le numéro de série du système d'exploitation, qui provient généralement du 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 simuler le numéro de série. Nous vous recommandons de n'utiliser cette condition que pour une 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 la page Modèle d'intégration de VPC Service Controls – liste d'autorisation (PDF).
Lancer l'application
Une fois que vous avez conçu la liste d'autorisations et mis à jour les niveaux d'accès, nous vous recommandons de réexécuter les charges de travail pour vérifier qu'il n'y a pas de non-respect. Si les charges de travail s'exécutent sans non-respect, vous pouvez lancer VPC Service Controls sans affecter les applications.
Lorsque vous prévoyez l'application, incluez les éléments suivants :
- Choisissez une date d'application forcée et communiquez cette date à toutes les équipes pertinentes.
- Assurez-vous que les équipes chargées des opérations de sécurité et de la gestion des incidents sont informées du déploiement. Assurez-vous également que les personnes disposant des autorisations appropriées inspectent les journaux et approuvent des listes d'autorisations supplémentaires, si nécessaire.
- Assurez-vous que l'équipe de gestion de la situation peut ouvrir un compte Google Cloud une demande d'assistance en 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 du périmètre de simulation vers le périmètre actif. Veillez à laisser le temps à l'application de s'exécuter correctement pendant que vous observez les journaux de non-respects. Répétez le processus pour les charges de travail restantes une par une.
Pour identifier les cas de non-respect bloqués, configurez un récepteur de journaux agrégés qui envoie à BigQuery les journaux d'audit de tous les projets du périmètre. 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
Étape suivante
- Découvrez comment autoriser l'accès aux ressources protégées depuis l'extérieur du périmètre.
- Découvrez comment répertorier, mettre à jour et supprimer des périmètres de service.