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 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.
• Autoriser ou refuser l'accès aux services à 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.
• Autoriser ou refuser l'accès aux services en dehors du périmètre à partir des requêtes provenant de l'intérieur du périmètre
• Utilisez la règle d'administration "Restreindre l'utilisation des services de ressources" et VPC Service Controls ensemble.

Coûts

Ce tutoriel utilise les composants facturables suivants de Google Cloud :

• Compute Engine
• Cloud Storage
• Private Service Connect

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 column 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 person_add 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 add Ajouter un autre rôle et ajoutez chaque rôle supplémentaire.
   7. Cliquez sur Enregistrer.

7. 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 column 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 person_add 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 add 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écrivent en détail 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 allez configurer la connectivité privée aux API et services Google pour votre réseau VPC afin d'atténuer un certain nombre de chemins de sortie réseau vers Internet.

   1. Dans Cloud Shell, définissez les 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 de 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 de l'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 pour le 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 effectuées depuis l'extérieur du périmètre, et comment vous pouvez autoriser sélectivement l'entrée aux services en configurant des niveaux d'accès et des règles d'entrée.

   Pour simuler le trafic provenant de l'extérieur de votre périmètre, vous pouvez exécuter des commandes dans Cloud Shell. Cloud Shell est une ressource située en dehors de votre projet et de votre périmètre. Le périmètre autorise ou refuse les requêtes, même si elles disposent des droits IAM (Identity and Access Management) suffisants 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 restreints.

   

   Le schéma précédent montre comment un client autorisé se voit refuser l'accès aux services situés dans le périmètre que vous avez configuré comme restreint, mais 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 en utilisant Cloud Shell pour tenter de créer une VM dans votre réseau VPC, ce qui échouera 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 refusait le trafic externe vers les services configurés dans --restricted-services et autorisait le trafic externe vers les services non explicitement configurés dans --restricted-services.

   Les sections suivantes présentent des modèles d'exception permettant d'accéder aux services restreints à l'intérieur du 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 d'autres attributs.

   

   Le schéma précédent illustre comment un niveau d'accès permet à un client autorisé d'accéder à tous les services restreints à l'intérieur du 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 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é autorise 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 à granularité large, une règle d'entrée à granularité fine peut configurer des attributs supplémentaires concernant la source du trafic et autoriser l'accès à des services ou méthodes individuels.

   

   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é à l'intérieur du 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 règle d'entrée qui autorise un client autorisé à 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 uniquement au service Compute Engine, puis appliquez la règle à 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 étant un client situé en dehors du périmètre, le périmètre VPC Service Controls l'empêche de communiquer avec les services restreints à 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 à l'intérieur du 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 règle d'entrée pour 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 depuis l'intérieur du périmètre, et comment vous pouvez autoriser sélectivement 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 de suffisamment de droits IAM 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 autorise le trafic interne vers les services restreints à l'intérieur du périmètre

   Dans cette section, vous allez vérifier que le périmètre autorise le trafic provenant des points de terminaison du réseau à l'intérieur de votre périmètre si le service est également configuré dans les services accessibles par VPC.

   

   Le schéma précédent illustre comment un périmètre permet au trafic provenant des points de terminaison du réseau à l'intérieur du périmètre d'atteindre les services restreints que vous avez également configurés comme services accessibles par VPC. Les services que vous n'avez pas configurés comme services accessibles par VPC ne sont pas accessibles à partir des points de terminaison du réseau à l'intérieur du 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 qui autorise 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 en interne par votre périmètre en utilisant un service Google Cloud configuré dans la liste d'autorisation des services accessibles par VPC. Par exemple, essayez n'importe quelle commande à l'aide du 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 indique que votre périmètre autorise le trafic interne vers l'API Compute Engine.

   4. À partir de la session SSH dans 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 à partir de 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 d'utilisation des ressources de service restreinte.

   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 allez vérifier que le périmètre bloque la communication entre les services situés à l'intérieur du périmètre et les services Google Cloud 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 tentant d'envoyer du trafic interne à un service restreint à l'intérieur du périmètre et à un service restreint à l'extérieur du périmètre.

   1. Dans la session SSH à l'intérieur de votre périmètre, exécutez la commande suivante pour créer un bucket de stockage à l'intérieur de 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. À partir de la session SSH à l'intérieur de votre périmètre, exécutez la commande suivante pour lire un bucket situé en dehors de votre périmètre. Ce bucket public autorise l'accès en lecture seule à allUsers, mais le périmètre refuse le trafic provenant de l'intérieur de votre périmètre vers un service restreint situé 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 à l'intérieur du périmètre, mais qu'une ressource à l'intérieur du périmètre ne peut pas communiquer avec des services restreints à l'extérieur 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.

   

   Le schéma précédent montre comment le trafic interne peut communiquer avec une ressource externe spécifique lorsque vous accordez une exception limitée 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 add Ouvrir un nouvel onglet dans Cloud Shell. Dans les étapes suivantes, vous allez passer du premier onglet avec la session SSH à l'intérieur de votre périmètre au 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 règle de sortie qui autorise la sortie à partir de l'identité du compte de service associé 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 contenant la session SSH vers la VM située dans votre périmètre, où l'invite de ligne de commande commence par username@demo-vm.

   4. Depuis la session SSH à l'intérieur de votre périmètre, envoyez une autre requête au 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 périmètre et votre règle de sortie autorisent le trafic interne d'une identité spécifique vers un bucket Cloud Storage spécifique.

   5. À partir de la session SSH à l'intérieur de votre périmètre, vous pouvez également tester d'autres méthodes qui n'ont pas été explicitement autorisées par l'exception de la règle 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 refuse le trafic interne provenant de la liste des objets dans le bucket externe, ce qui indique que la stratégie de sortie autorise précisément les méthodes spécifiées de manière explicite.

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

   (Facultatif) Configurer la règle "Utilisation restreinte des ressources de service"

   Vous pouvez également avoir des exigences internes ou de conformité qui vous obligent à n'autoriser que les API approuvées individuellement à être utilisées dans votre environnement. Dans ce cas, vous pouvez également configurer le service de règles d'administration Restreindre l'utilisation des services de ressources. 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 votre 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 de l'organisation 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 contenant la session SSH vers la VM située dans votre périmètre, où l'invite de ligne de commande commence par username@demo-vm.

   4. Dans la session SSH à l'intérieur 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 autorisent le trafic interne à atteindre un bucket de stockage externe dans certaines conditions limitées, mais que le service de règles relatives à l'organisation refuse le service Cloud Storage dans votre projet, quelle que soit la configuration de votre périmètre. Des services extérieurs à votre projet peuvent toujours être utilisés pour l'exfiltration s'ils sont autorisés par votre périmètre, quelle que soit la règle d'administration sur l'utilisation des services de ressources restreints.

      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 Restreindre l'utilisation des services de ressources seul ne suffit pas. Vous devez configurer un périmètre VPC Service Controls. VPC Service Controls atténue les chemins d'exfiltration de 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 non approuvés et autoriser de manière sélective les services approuvés pour un usage 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.

   Étapes suivantes

   • Découvrez les bonnes pratiques pour activer VPC Service Controls.
   • Découvrez quels services sont compatibles avec VPC Service Controls.
   • Découvrez comment activer les services accessibles par VPC.
   • Découvrez la configuration de Private Service Connect pour accéder aux API Google.

   • Pour découvrir d'autres architectures de référence, schémas, tutoriels et bonnes pratiques, consultez le Centre d'architecture cloud.