Configurer un périmètre VPC Service Controls pour un réseau de cloud privé virtuel

Découvrez comment configurer un périmètre de service à l'aide de VPC Service Controls. Ce tutoriel utilise des paramètres réseau tels que les pare-feu, Private Service Connect et les configurations DNS, qui sont nécessaires pour utiliser efficacement un périmètre VPC Service Controls. Ce tutoriel explique ensuite comment les services sont autorisés ou refusés, et comment créer des exceptions précises pour une liste d'autorisation de services spécifiques.

Objectifs

  • Configurez un périmètre VPC Service Controls avec des contrôles réseau supplémentaires pour limiter les chemins d'exfiltration.
  • Autorisez ou refusez l'accès aux services situés à l'intérieur du périmètre à partir de requêtes provenant de l'intérieur ou de l'extérieur du périmètre.
  • Autorisez ou refusez l'accès aux services en dehors du périmètre à partir de requêtes provenant du périmètre.
  • Utilisez la règle d'administration de restriction d'utilisation des services de ressources et VPC Service Controls ensemble.

Coûts

Ce tutoriel utilise les composants facturables Google Cloud suivants :

Obtenez une estimation des coûts en fonction de votre utilisation prévue à l'aide du simulateur de coût.

Une fois que vous avez terminé ce tutoriel, évitez de continuer à payer des frais en supprimant les ressources que vous avez créées. Pour en savoir plus, consultez la section Effectuer un nettoyage.

Avant de commencer

  1. Pour suivre ce tutoriel, vous devez disposer d'un projet dans votre organisation. Si vous ne disposez pas déjà d'une organisation Google Cloud, consultez la page Créer et gérer une organisation.

  2. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  3. Make sure that billing is enabled for your Google Cloud project.

  4. Enable the Compute Engine, Access Context Manager, and Cloud DNS APIs.

    Enable the APIs

  5. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

  6. Make sure that you have the following role or roles on the organization: Access Context Manager Admin, Organization Policy Administrator

    Check for the roles

    1. In the Google Cloud console, go to the IAM page.

      Go to IAM
    2. Select the organization.
    3. In the Principal column, find all rows that identify you or a group that you're included in. To learn which groups you're included in, contact your administrator.

    4. For all rows that specify or include you, check the Role colunn to see whether the list of roles includes the required roles.

    Grant the roles

    1. In the Google Cloud console, go to the IAM page.

      Accéder à IAM
    2. Sélectionnez l'organisation.
    3. Cliquez sur Accorder l'accès.
    4. Dans le champ Nouveaux comptes principaux, saisissez votre identifiant utilisateur. Il s'agit généralement de l'adresse e-mail d'un compte Google.

    5. Dans la liste Sélectionner un rôle, sélectionnez un rôle.
    6. Pour attribuer des rôles supplémentaires, cliquez sur Ajouter un autre rôle et ajoutez chaque rôle supplémentaire.
    7. Cliquez sur Enregistrer.
    8. Make sure that you have the following role or roles on the project: Compute Admin, DNS Administrator, IAP-Secured Tunnel User, Service Account User, Service Directory Editor

      Check for the roles

      1. In the Google Cloud console, go to the IAM page.

        Go to IAM
      2. Select the project.
      3. In the Principal column, find all rows that identify you or a group that you're included in. To learn which groups you're included in, contact your administrator.

      4. For all rows that specify or include you, check the Role colunn to see whether the list of roles includes the required roles.

      Grant the roles

      1. In the Google Cloud console, go to the IAM page.

        Accéder à IAM
      2. Sélectionnez le projet.
      3. Cliquez sur Accorder l'accès.
      4. Dans le champ Nouveaux comptes principaux, saisissez votre identifiant utilisateur. Il s'agit généralement de l'adresse e-mail d'un compte Google.

      5. Dans la liste Sélectionner un rôle, sélectionnez un rôle.
      6. Pour attribuer des rôles supplémentaires, cliquez sur Ajouter un autre rôle et ajoutez chaque rôle supplémentaire.
      7. Cliquez sur Enregistrer.

      Configurer votre périmètre VPC Service Controls

      Pour implémenter un périmètre VPC Service Controls pour un réseau VPC, vous devez implémenter des contrôles réseau qui refusent le trafic vers les services externes. Les sections suivantes détaillent les configurations réseau que vous devez implémenter dans les réseaux VPC de votre périmètre, ainsi qu'un exemple de configuration de périmètre.

      Préparer votre réseau VPC

      Dans cette section, vous configurez une connectivité privée aux API et services Google pour votre réseau VPC afin de limiter un certain nombre de chemins de sortie réseau vers Internet.

      1. Dans Cloud Shell, définissez des variables:

        gcloud config set project PROJECT_ID
        gcloud config set compute/region REGION
        gcloud config set compute/zone ZONE

        Remplacez les éléments suivants :

        • PROJECT_ID: ID du projet dans lequel vous allez créer des ressources
        • REGION: région proche de votre emplacement (par exemple, us-central1)
        • ZONE: zone proche de votre emplacement (par exemple, us-central1-a)
      2. Créez un réseau VPC et un sous-réseau avec l'accès privé à Google activé :

        gcloud compute networks create restricted-vpc --subnet-mode=custom
        gcloud compute networks subnets create restricted-subnet \
        --range=10.0.0.0/24 \
        --network=restricted-vpc \
        --enable-private-ip-google-access
      3. Créez un point de terminaison Private Service Connect et une règle de transfert configurée pour utiliser le groupe vpc-sc:

        gcloud compute addresses create restricted-psc-endpoint \
        --global \
        --purpose=PRIVATE_SERVICE_CONNECT \
        --addresses=10.0.1.1 \
        --network=restricted-vpc
        
        gcloud compute forwarding-rules create restrictedpsc \
        --global \
        --network=restricted-vpc \
        --address=restricted-psc-endpoint \
        --target-google-apis-bundle=vpc-sc
      4. Configurez la règle de serveur Cloud DNS pour rediriger les requêtes des API Google Cloud vers votre point de terminaison Private Service Connect:

        gcloud dns managed-zones create restricted-dns-zone \
          --description="Private DNS Zone to map Google API queries to the Private Service Connect endpoint for Google APIs" \
          --dns-name="googleapis.com." \
          --networks=restricted-vpc \
          --visibility=private
        
        gcloud dns record-sets create googleapis.com  \
        --rrdatas=10.0.1.1 \
        --type=A \
        --ttl=300 \
        --zone=restricted-dns-zone
        
        gcloud dns record-sets create *.googleapis.com  \
        --rrdatas="googleapis.com." \
        --type=CNAME \
        --ttl=300 \
        --zone=restricted-dns-zone
      5. Configurez une règle de pare-feu avec une faible priorité pour refuser tout le trafic sortant:

        gcloud compute firewall-rules create deny-all-egress \
        --priority=65534 \
        --direction=egress \
        --network=restricted-vpc \
        --action=DENY \
        --rules=all \
        --destination-ranges=0.0.0.0/0
      6. Configurez une règle de pare-feu avec une priorité plus élevée pour autoriser le trafic à atteindre l'adresse IP utilisée par votre point de terminaison Private Service Connect:

        gcloud compute firewall-rules create allow-psc-for-google-apis \
        --priority=1000 \
        --direction=egress \
        --network=restricted-vpc \
        --action=ALLOW \
        --rules=tcp:443 \
        --destination-ranges=10.0.1.1

        Ces règles de pare-feu refusent la sortie de manière large, avant d'autoriser de manière sélective la sortie vers le point de terminaison Private Service Connect. Cette configuration refuse le trafic sortant vers les domaines par défaut normalement accessibles par défaut avec l'Accès privé à Google et les règles de pare-feu implicites.

      Créer un périmètre VPC Service Controls

      Dans cette section, vous allez créer un périmètre VPC Service Controls.

      1. Dans Cloud Shell, créez une règle d'accès comme condition préalable à la création d'un périmètre VPC Service Controls:

        gcloud access-context-manager policies create \
        --organization=ORGANIZATION_ID --title "Access policy at organization node"

        Le résultat ressemble à ce qui suit :

        "Create request issued
        Waiting for operation [operations/accessPolicies/123456789/create/123456789] to complete...done."
        

        Il ne peut y avoir qu'un seul conteneur de règles d'accès au niveau du nœud d'organisation. Si une règle a déjà été créée dans votre organisation, le résultat ressemble à ce qui suit:

        "ALREADY_EXISTS: Policy already exists with parent ContainerKey{containerId=organizations/123456789012, numericId=123456789012}"
        

        Si ce message s'affiche, passez à l'étape suivante.

      2. Créez un périmètre VPC Service Controls qui limite les services Cloud Storage et Compute Engine.

        export POLICY_ID=$(gcloud access-context-manager policies list \
        --organization=ORGANIZATION_ID \
        --format="value(name)")
        
        gcloud access-context-manager perimeters create demo_perimeter \
        --title="demo_perimeter" \
        --resources=projects/$(gcloud projects describe PROJECT_ID --format="value(projectNumber)") \
        --restricted-services="storage.googleapis.com,compute.googleapis.com" \
        --enable-vpc-accessible-services \
        --policy=$POLICY_ID \
        --vpc-allowed-services="RESTRICTED-SERVICES"

      Vérifier les services autorisés à partir du trafic en dehors de votre périmètre

      Les sections suivantes montrent comment le périmètre VPC Service Controls autorise ou refuse l'accès aux requêtes émises en dehors du périmètre, et comment vous pouvez autoriser de manière sélective l'entrée dans les services en configurant des niveaux d'accès et des règles d'entrée.

      Pour simuler le trafic en dehors de votre périmètre, vous pouvez exécuter des commandes dans Cloud Shell. Cloud Shell est une ressource en dehors de votre propre projet et périmètre. Le périmètre autorise ou refuse les requêtes, même si elles disposent d'autorisations IAM (Identity and Access Management) suffisantes pour aboutir.

      Ce tutoriel utilise les API Compute Engine, Cloud Storage et Cloud Resource Manager, mais les mêmes concepts s'appliquent également à d'autres services.

      Vérifier que le périmètre refuse le trafic externe vers les services restreints

      Dans cette section, vous allez vérifier que le périmètre refuse le trafic externe vers les services soumis à des restrictions.

      Schéma architectural illustrant comment un périmètre VPC Service Controls refuse l'accès aux services restreints

      Le schéma précédent montre comment l'accès d'un client autorisé aux services situés dans le périmètre que vous avez configuré comme restreint est refusé, mais que le client est autorisé à accéder aux services que vous n'avez pas configurés comme restreints.

      Dans les étapes suivantes, vous allez vérifier ce concept à l'aide de Cloud Shell pour tenter de créer une VM dans votre réseau VPC, ce qui échoue en raison de la configuration du périmètre VPC Service Controls.

      1. Dans Cloud Shell, exécutez la commande suivante pour créer une VM dans votre réseau VPC.

        gcloud compute instances create demo-vm \
            --machine-type=e2-micro \
            --subnet=restricted-subnet \
            --scopes=https://www.googleapis.com/auth/cloud-platform \
            --no-address

        Le résultat ressemble à ce qui suit :

        "ERROR: (gcloud.compute.instances.create) Could not fetch resource:
        - Request is prohibited by organization's policy."
        

        La requête échoue, car Cloud Shell se trouve en dehors de votre périmètre et que Compute Engine est configuré avec l'indicateur --restricted-services.

      2. Dans Cloud Shell, exécutez la commande suivante pour accéder au service Resource Manager, qui n'est pas configuré dans l'indicateur --restricted-services.

        gcloud projects describe PROJECT_ID

        Une réponse réussie renvoie les détails de votre projet. Cette réponse montre que votre périmètre autorise le trafic externe vers l'API Cloud Resource Manager.

        Vous avez démontré que le périmètre refuse le trafic externe vers les services configurés dans --restricted-services et autorise le trafic externe vers les services non configurés explicitement dans --restricted-services.

      Les sections suivantes présentent des modèles d'exception pour accéder aux services restreints dans le périmètre.

      Vérifier qu'un niveau d'accès autorise une exception au périmètre

      Dans cette section, vous allez vérifier qu'un niveau d'accès autorise une exception au périmètre. Un niveau d'accès est utile lorsque vous souhaitez créer une exception pour le trafic externe afin d'accéder à tous les services restreints à l'intérieur du périmètre et que vous n'avez pas besoin d'exceptions précises pour chaque service ou autre attribut.

      Schéma architectural illustrant comment un niveau d'accès accorde une exception à tous les services situés dans le périmètre VPC Service Controls

      Le schéma précédent montre comment un niveau d'accès permet à un client autorisé d'accéder à tous les services restreints dans le périmètre.

      Dans les étapes suivantes, vous allez vérifier ce concept en créant un niveau d'accès, puis en envoyant une requête réussie au service Compute Engine. Cette requête est autorisée même si vous avez configuré Compute Engine comme restreint.

      1. Dans Cloud Shell, créez un fichier YAML qui décrit la configuration d'un niveau d'accès et appliquez-le à votre périmètre. Cet exemple crée un niveau d'accès pour l'identité utilisateur que vous utilisez actuellement pour exécuter le tutoriel.

        export USERNAME=$(gcloud config list account --format "value(core.account)")
        
        cat <<EOF > user_spec.yaml
        - members:
          - user:$USERNAME
        EOF
        
        gcloud access-context-manager levels create single_user_level \
        --title="single-user access level" \
        --basic-level-spec=user_spec.yaml \
        --policy=$POLICY_ID
        
        gcloud access-context-manager perimeters update demo_perimeter \
        --add-access-levels=single_user_level \
        --policy=$POLICY_ID
      2. Dans Cloud Shell, exécutez à nouveau la commande suivante pour tenter de créer une VM:

        gcloud compute instances create demo-vm \
        --machine-type=e2-micro \
        --subnet=restricted-subnet \
        --scopes=https://www.googleapis.com/auth/cloud-platform \
        --no-address

        Cette fois, la requête fonctionne. Votre périmètre empêche le trafic externe d'utiliser les services restreints, mais le niveau d'accès que vous avez configuré permet une exception.

      Vérifier qu'une règle d'entrée autorise une exception précise au périmètre

      Dans cette section, vous allez vérifier qu'une règle d'entrée autorise une exception précise au périmètre. Par rapport au niveau d'accès à grain fin, une règle d'entrée à grain fin peut configurer des attributs supplémentaires sur la source de trafic et autoriser l'accès à des services ou méthodes individuels.

      Schéma architectural illustrant comment une règle d&#39;entrée permet à une exception précise d&#39;atteindre des services spécifiés dans le périmètre

      Le schéma précédent montre comment une règle d'entrée permet à un client autorisé d'accéder uniquement à un service spécifié dans le périmètre, sans autoriser l'accès à d'autres services restreints.

      Dans les étapes suivantes, vous allez vérifier ce concept en remplaçant le niveau d'accès par une stratégie d'entrée qui permet à un client autorisé d'accéder uniquement au service Compute Engine, mais pas aux autres services restreints.

      1. Dans l'onglet Cloud Shell, exécutez la commande suivante pour supprimer le niveau d'accès.

        gcloud access-context-manager perimeters update demo_perimeter \
        --policy=$POLICY_ID \
        --clear-access-levels
      2. Dans l'onglet Cloud Shell, créez une règle d'entrée qui autorise votre identité utilisateur à accéder au service Compute Engine uniquement, puis appliquez-la à votre périmètre.

        cat <<EOF > ingress_spec.yaml
        - ingressFrom:
            identities:
            - user:$USERNAME
            sources:
            - accessLevel: '*'
          ingressTo:
            operations:
            - methodSelectors:
              - method: '*'
              serviceName: compute.googleapis.com
            resources:
            - '*'
        EOF
        
        gcloud access-context-manager perimeters update demo_perimeter \
        --set-ingress-policies=ingress_spec.yaml \
        --policy=$POLICY_ID
      3. Dans l'onglet Cloud Shell, exécutez la commande suivante pour créer un bucket Cloud Storage dans le périmètre.

        gcloud storage buckets create gs://PROJECT_ID-01

        Le résultat ressemble à ce qui suit :

        "ERROR: (gcloud.storage.buckets.create) HTTPError 403: Request is prohibited by organization's policy."
        

        Cloud Shell est un client en dehors du périmètre. Le périmètre VPC Service Controls empêche donc Cloud Shell de communiquer avec les services restreints situés à l'intérieur du périmètre.

      4. Dans l'onglet Cloud Shell, exécutez la commande suivante pour envoyer une requête au service Compute Engine dans le périmètre.

        gcloud compute instances describe demo-vm --zone=ZONE

        Une réponse réussie renvoie les détails de demo-vm. Cette réponse montre que votre périmètre autorise le trafic externe qui répond aux conditions de votre stratégie d'entrée vers le service Compute Engine.

      Vérifier les services autorisés pour le trafic à l'intérieur de votre périmètre

      Les sections suivantes montrent comment le périmètre VPC Service Controls autorise ou refuse les requêtes adressées aux services à partir du périmètre, et comment vous pouvez autoriser de manière sélective la sortie vers des services externes à l'aide de règles de sortie.

      Pour illustrer la différence entre le trafic à l'intérieur et à l'extérieur du périmètre, les sections suivantes utilisent à la fois Cloud Shell en dehors du périmètre et une instance Compute Engine que vous créez à l'intérieur du périmètre. Les commandes que vous exécutez à partir de la session SSH sur l'instance Compute Engine à l'intérieur du périmètre utilisent l'identité du compte de service associé, tandis que les commandes exécutées à partir de Cloud Shell en dehors du périmètre utilisent votre propre identité. Lorsque vous suivez la configuration recommandée pour le tutoriel, le périmètre autorise ou refuse les requêtes, même si elles disposent d'autorisations IAM suffisantes pour réussir.

      Ce tutoriel utilise les API Compute Engine, Cloud Storage et Cloud Resource Manager, mais les mêmes concepts s'appliquent également à d'autres services.

      Vérifier que le périmètre autorise le trafic interne vers les services restreints situés dans le périmètre

      Dans cette section, vous vérifiez que le périmètre autorise le trafic provenant de points de terminaison du réseau dans votre périmètre si le service est également configuré dans les services accessibles par VPC.

      Schéma architectural illustrant comment la configuration de vpc-accessible-services permet d&#39;accéder aux services à partir de vos points de terminaison réseau internes

      Le schéma précédent montre comment un périmètre permet au trafic provenant des points de terminaison du réseau situés dans le périmètre d'atteindre les services restreints que vous avez également configurés en tant que services accessibles par VPC. Les services que vous n'avez pas configurés en tant que services accessibles par VPC ne sont pas accessibles à partir des points de terminaison du réseau situés dans le périmètre.

      Dans les étapes suivantes, vous allez vérifier ce concept en établissant une connexion SSH à l'instance Compute Engine à l'intérieur du périmètre, puis en envoyant des requêtes aux services.

      1. Dans Cloud Shell, créez une règle de pare-feu autorisant le trafic SSH vers votre réseau VPC en autorisant le trafic entrant provenant de la plage d'adresses IP 35.235.240.0/20 utilisée par le service IAP pour le transfert TCP:

        gcloud compute firewall-rules create demo-allow-ssh \
        --direction=INGRESS \
        --priority=1000 \
        --network=restricted-vpc \
        --action=ALLOW \
        --rules=tcp:22 \
        --source-ranges=35.235.240.0/20 
      2. Démarrez une session SSH sur cette instance :

        gcloud compute ssh demo-vm --zone=ZONE

        Vérifiez que vous êtes bien connecté à l'instance demo-vm en vérifiant que l'invite de ligne de commande a changé pour afficher le nom d'hôte de votre instance:

        username@demo-vm:~$
        

        Si la commande précédente échoue, un message d'erreur semblable à celui-ci peut s'afficher:

        "[/usr/bin/ssh] exited with return code [255]"
        

        Dans ce cas, il est possible que l'instance Compute Engine n'ait pas démarré. Patientez une minute, puis réessayez.

      3. Dans la session SSH de votre périmètre, vérifiez les services autorisés par votre périmètre en interne à l'aide d'un service Google Cloud configuré dans la liste d'autorisation des services accessibles par VPC. Par exemple, essayez n'importe quelle commande utilisant le service Compute Engine.

        gcloud compute instances describe demo-vm --zone=ZONE

        Une réponse réussie renvoie les détails de demo-vm. Cette réponse montre que votre périmètre autorise le trafic interne vers l'API Compute Engine.

      4. Dans la session SSH de votre périmètre, vérifiez que les services qui ne figurent pas dans la liste d'autorisation des services accessibles par VPC ne sont pas autorisés depuis votre VM. Par exemple, la commande suivante utilise le service Resource Manager, qui n'est pas configuré dans la liste d'autorisation des services accessibles par VPC.

        gcloud projects describe PROJECT_ID

        Le résultat ressemble à ce qui suit :

        "ERROR: (gcloud.projects.list) PERMISSION_DENIED: Request is prohibited by organization's policy."
        

        Votre instance Compute Engine et les autres points de terminaison réseau ne peuvent demander que les services configurés dans la liste d'autorisation des services accessibles par VPC. Toutefois, les ressources sans serveur ou le trafic de service provenant de l'extérieur de votre périmètre peuvent demander ce service. Si vous souhaitez empêcher l'utilisation d'un service dans votre projet, consultez la Règle sur l'utilisation des ressources de service limitées.

      Vérifier que le périmètre refuse le trafic interne vers les services restreints en dehors du périmètre

      Dans cette section, vous vérifiez que le périmètre bloque la communication des services situés à l'intérieur du périmètre avec les services Google Cloud situés en dehors du périmètre.

      Schéma architectural illustrant comment un périmètre VPC Service Controls interdit l&#39;accès du trafic situé à l&#39;intérieur du périmètre aux services restreints situés en dehors du périmètre

      Le schéma précédent montre comment le trafic interne ne peut pas communiquer avec les services restreints en dehors du périmètre.

      Dans les étapes suivantes, vous allez vérifier ce concept en essayant d'envoyer du trafic interne à un service restreint à l'intérieur du périmètre et à un service restreint en dehors du périmètre.

      1. Dans la session SSH de votre périmètre, exécutez la commande suivante pour créer un bucket de stockage dans votre périmètre. Cette commande fonctionne, car le service Cloud Storage est configuré à la fois dans restricted-services et accessible-services.

        gcloud storage buckets create gs://PROJECT_ID-02

        Une réponse réussie crée le bucket de stockage. Cette réponse montre que votre périmètre autorise le trafic interne vers le service Cloud Storage.

      2. Dans la session SSH à l'intérieur de votre périmètre, exécutez la commande suivante pour lire à partir d'un bucket situé en dehors de votre périmètre. Ce bucket public autorise l'autorisation en lecture seule à allUsers, mais le périmètre refuse le trafic provenant de votre périmètre vers un service restreint en dehors du périmètre.

        gcloud storage cat gs://solutions-public-assets/vpcsc-tutorial/helloworld.txt

        Le résultat ressemble à ce qui suit :

        "ERROR: (gcloud.storage.objects.describe) HTTPError 403: Request is prohibited
        by organization's policy."
        

        Cette réponse montre que vous pouvez utiliser des services restreints dans le périmètre, mais qu'une ressource dans le périmètre ne peut pas communiquer avec des services restreints en dehors du périmètre.

      Vérifier qu'une règle de sortie autorise une exception au périmètre

      Dans cette section, vous allez vérifier qu'une règle de sortie autorise une exception au périmètre.

      Schéma architectural illustrant comment une règle de sortie permet à des exceptions spécifiques d&#39;atteindre un service restreint en dehors du périmètre

      Le schéma précédent montre comment le trafic interne peut communiquer avec une ressource externe spécifique lorsque vous accordez une exception étroite avec la règle de sortie.

      Dans les étapes suivantes, vous allez vérifier ce concept en créant une règle de sortie, puis en accédant à un bucket Cloud Storage public en dehors du périmètre autorisé par la règle de sortie.

      1. Ouvrez une nouvelle session Cloud Shell en cliquant sur  Ouvrir un nouvel onglet dans Cloud Shell. Dans les étapes suivantes, vous allez basculer entre le premier onglet avec la session SSH à l'intérieur de votre périmètre et le deuxième onglet dans Cloud Shell en dehors de votre périmètre, où l'invite de ligne de commande commence par username@cloudshell.

      2. Dans l'onglet Cloud Shell, créez une stratégie de sortie qui autorise la sortie de l'identité du compte de service associé de demo-vm à l'aide de la méthode google.storage.objects.get vers un bucket public dans un projet externe. Mettez à jour le périmètre avec la règle de sortie.

        export POLICY_ID=$(gcloud access-context-manager policies list \
        --organization=ORGANIZATION_ID \
        --format="value(name)")
        
        export SERVICE_ACCOUNT_EMAIL=$(gcloud compute instances describe demo-vm \
        --zone=ZONE) \
        --format="value(serviceAccounts.email)"
        cat <<EOF > egress_spec.yaml
        - egressFrom:
            identities:
              - serviceAccount:$SERVICE_ACCOUNT_EMAIL
          egressTo:
            operations:
            - methodSelectors:
              - method: 'google.storage.objects.get'
              serviceName: storage.googleapis.com
            resources:
            - projects/950403849117
        EOF
        
        gcloud access-context-manager perimeters update demo_perimeter \
        --set-egress-policies=egress_spec.yaml \
        --policy=$POLICY_ID
      3. Revenez à l'onglet de la session SSH vers la VM dans votre périmètre, où l'invite de ligne de commande commence par username@demo-vm.

      4. Depuis la session SSH dans votre périmètre, effectuez une autre requête sur le bucket Cloud Storage et vérifiez qu'elle fonctionne.

        gcloud storage cat gs://solutions-public-assets/vpcsc-tutorial/helloworld.txt

        Le résultat ressemble à ce qui suit :

        "Hello world!
        This is a sample file in Cloud Storage that is viewable to allUsers."
        

        Cette réponse montre que votre stratégie de périmètre et de sortie autorise le trafic interne d'une identité spécifique vers un bucket Cloud Storage spécifique.

      5. À partir de la session SSH dans votre périmètre, vous pouvez également tester d'autres méthodes qui n'étaient pas explicitement autorisées par l'exception de la stratégie de sortie. Par exemple, la commande suivante nécessite l'autorisation google.storage.buckets.list, qui est refusée par votre périmètre.

        gcloud storage ls gs://solutions-public-assets/vpcsc-tutorial/*

        Le résultat ressemble à ce qui suit :

        "ERROR: (gcloud.storage.cp) Request is prohibited by organization's policy."
        

        Cette réponse montre que votre périmètre interdit au trafic interne de lister des objets dans le bucket externe, ce qui indique que la stratégie de sortie n'autorise que les méthodes explicitement spécifiées.

      Pour en savoir plus sur les modèles courants d'échange de données en dehors du périmètre de votre service, consultez la section Échange de données sécurisé à l'aide de règles d'entrée et de sortie.

      (Facultatif) Configurer la stratégie d'utilisation des ressources de service limitée

      Vous pouvez également avoir des exigences internes ou de conformité qui vous obligent à n'autoriser que les API approuvées individuellement dans votre environnement. Dans ce cas, vous pouvez également configurer le service de règles d'administration Utilisation des ressources de service limitée. En appliquant la règle d'administration à un projet, vous limitez les services pouvant être créés dans ce projet. Toutefois, la règle d'administration n'empêche pas les services de ce projet de communiquer avec les services d'autres projets. En comparaison, VPC Service Controls vous permet de définir un périmètre empêchant la communication avec des services en dehors du périmètre.

      Par exemple, si vous définissez une règle d'administration pour autoriser Compute Engine et interdire Cloud Storage dans votre projet, une VM de ce projet ne peut pas créer de bucket Cloud Storage dans le projet. Cependant, la VM peut envoyer des requêtes à un bucket Cloud Storage d'un autre projet. Par conséquent, l'exfiltration avec le service Cloud Storage est toujours possible. Les étapes suivantes montrent comment implémenter et tester ce scénario:

      1. Accédez à l'onglet Cloud Shell, où l'invite de ligne de commande commence par username@cloudshell.
      2. Dans l'onglet Cloud Shell, créez un fichier YAML décrivant le service de règles d'administration qui n'autorisera que l'utilisation du service Compute Engine et refusera tous les autres services, puis appliquez-le à votre projet.

        cat <<EOF > allowed_services_policy.yaml
        constraint: constraints/gcp.restrictServiceUsage
        listPolicy:
          allowedValues:
          - compute.googleapis.com
          inheritFromParent: true
        EOF
        
        gcloud resource-manager org-policies set-policy allowed_services_policy.yaml \
        --project=PROJECT_ID
      3. Revenez à l'onglet de la session SSH vers la VM dans votre périmètre, où l'invite de ligne de commande commence par username@demo-vm.

      4. Dans la session SSH de votre périmètre, exécutez la commande suivante pour afficher le même bucket de stockage que vous avez créé précédemment dans ce projet.

        gcloud storage buckets describe gs://PROJECT_ID

        Le résultat ressemble à ce qui suit :

        "ERROR: (gcloud.storage.buckets.create) HTTPError 403: Request is disallowed by organization's constraints/gcp.restrictServiceUsage constraint for 'projects/123456789' attempting to use service 'storage.googleapis.com'."
        

        Cette réponse montre que le service de règles d'administration de l'organisation refuse le service Cloud Storage dans votre projet, quelle que soit la configuration de votre périmètre.

      5. Dans la session SSH à l'intérieur de votre périmètre, exécutez la commande suivante pour afficher un bucket de stockage en dehors du périmètre autorisé par votre règle de sortie.

        gcloud storage cat gs://solutions-public-assets/vpcsc-tutorial/helloworld.txt

        Le résultat ressemble à ce qui suit :

        "Hello world!
        This is a sample file in Cloud Storage that is viewable to allUsers."
        

        Une réponse réussie renvoie le contenu de helloworld.txt dans le bucket de stockage externe. Cette réponse montre que votre périmètre et votre règle de sortie permettent au trafic interne d'atteindre un bucket de stockage externe dans certaines conditions limitées, mais que le service de stratégie de l'organisation refuse le service Cloud Storage dans votre projet, quelle que soit la configuration de votre périmètre. Les services en dehors de votre projet peuvent toujours être utilisés à des fins d'exfiltration s'ils sont autorisés par votre périmètre, quelle que soit la règle d'administration de restriction d'utilisation des services de ressources.

        Pour refuser la communication avec Cloud Storage ou d'autres services Google en dehors du périmètre, le service de règles d'administration Restricted Service Resource Usage (Utilisation limitée des ressources de service) n'est pas suffisant. Vous devez configurer un périmètre VPC Service Controls. VPC Service Controls atténue les chemins d'exfiltration des données, et l'utilisation restreinte des ressources de service est un contrôle de conformité qui empêche la création de services non approuvés dans votre environnement. Utilisez ces contrôles ensemble pour bloquer une plage de chemins d'exfiltration vers des services approuvés et autoriser de manière sélective leur utilisation interne dans votre environnement.

      Effectuer un nettoyage

      Delete a Google Cloud project:

      gcloud projects delete PROJECT_ID

      Bien que le périmètre VPC Service Controls ne génère aucun coût supplémentaire, il doit être nettoyé pour éviter l'encombrement et les ressources inutilisées de votre organisation.

      1. Dans le sélecteur de projet en haut de la console Google Cloud, sélectionnez l'organisation que vous avez utilisée dans ce tutoriel.
      2. Dans la console Google Cloud, accédez à la page VPC Service Controls.

        Accéder à VPC Service Controls

      3. Sous la liste des périmètres, sélectionnez celui que vous souhaitez supprimer, puis cliquez sur Supprimer.

      4. Dans la boîte de dialogue, cliquez à nouveau sur Supprimer pour confirmer la suppression.

      Étape suivante