Tutoriel de base sur VPC Service Controls II – Résoudre les problèmes de sortie

1. Introduction

VPC Service Controls (VPC-SC) est un contrôle de sécurité au niveau de l'organisation dans Google Cloud qui permet aux entreprises clientes de limiter les risques d'exfiltration de données. VPC Service Controls permet de mettre en place des accès "zéro confiance" aux services mutualisés en permettant aux clients de limiter l'accès aux adresses IP autorisées, au contexte du client et aux paramètres de l'appareil tout en se connectant aux services mutualisés depuis Internet ou d'autres services. Cela permet de réduire les pertes intentionnelles et non intentionnelles. Comme nous l'avons vu dans le tutoriel de base I sur VPC Service Controls, vous pouvez utiliser VPC Service Controls pour créer des périmètres qui protègent les ressources et les données des services que vous spécifiez explicitement.

Les objectifs de ce tutoriel sont les suivants :

Comprendre les principes de base de VPC Service Controls.
Mettre à jour un périmètre de service et le tester en mode dry run.
Protéger deux services avec VPC Service Controls.
Résoudre un problème de non-respect des règles de sortie VPC Service Controls lors de la liste d'un objet à partir de Cloud Storage.

2. Préparation

Pour ce tutoriel, nous avons besoin des prérequis suivants :

Organisation GCP.
Un dossier dans l'organisation.
Deux projets GCP dans la même organisation placés sous le dossier.
Les autorisations requises au niveau de l'organisation.
Un compte de facturation pour les deux projets.
Configuration de VPC Service Controls et d'Access Context Manager pour le tutoriel de base I sur VPC Service Controls.

Configuration des ressources

Configurez les ressources comme décrit dans la section "Configuration des ressources" du tutoriel de base I sur VPC Service Controls.
Vérifiez que vous disposez des autorisations requises pour administrer Cloud Storage.
Pour ce tutoriel, nous allons commencer à utiliser la CLI au lieu de la console Cloud. Dans l'un des environnements de développement, configurez la gcloud CLI :

Cloud Shell : pour utiliser un terminal en ligne avec la gcloud CLI déjà configurée, activez Cloud Shell.

Activez Cloud Shell en cliquant sur l'icône en haut à droite de votre console Cloud. L'initialisation de la session peut prendre quelques secondes. Pour en savoir plus, consultez le guide Cloud Shell.

Shell local : pour utiliser un environnement de développement local, installez et initialisez la gcloud CLI.

Coût

Vous devez activer la facturation dans la console Cloud pour utiliser les ressources/API Cloud. L'exécution de cet atelier de programmation est très peu coûteuse, voire sans frais. Pour désactiver les ressources et éviter ainsi que des frais ne vous soient facturés après ce tutoriel, vous pouvez supprimer le projet ou les ressources que vous avez créées. Les nouveaux utilisateurs de Google Cloud peuvent bénéficier du programme d'essai sans frais de 300 $USD.

Les seuls ressources qui généreront des coûts sont l'instance de VM et l'objet Cloud Storage. Vous trouverez une estimation du coût de l'instance de VM dans le calculateur de prix. Vous trouverez une estimation du coût de Cloud Storage dans cette liste de prix.

3. Créer un bucket et un objet de stockage

Comme mentionné précédemment, nous allons réutiliser les ressources créées dans le tutoriel précédent. Nous allons donc continuer à créer le bucket Cloud Storage. Pour ce tutoriel, nous allons commencer à utiliser la gcloud CLI au lieu de la console.

Dans la console Google, sélectionnez ProjectX. Dans ce projet, nous allons créer le bucket de stockage et l'objet.
Assurez-vous de configurer Cloud Shell pour qu'il utilise ProjectX en exécutant la commande suivante :

gcloud config set project PROJECT_ID

Dans votre environnement de développement, exécutez la commande suivante :

gcloud storage buckets create gs://BUCKET_NAME --location=us-central1

Créez un objet de stockage afin de pouvoir le lire à partir de l'instance de VM située dans ProjectZ. Nous allons créer un fichier .txt.

nano hello.txt

Ajoutez ce que vous voulez dans le fichier texte.

Importez l'objet dans le bucket.

gcloud storage cp /home/${USER}/hello.txt gs://BUCKET_NAME

Vérifiez que l'objet a bien été importé dans le bucket en le listant.

gcloud storage ls gs://BUCKET_NAME

Le fichier hello.txt doit s'afficher dans la console.

4. Protéger l'API Cloud Storage

Dans l'atelier de programmation précédent, nous avons créé un périmètre et protégé l'API Compute Engine. Dans cet atelier de programmation, nous allons modifier notre périmètre en mode dry run et ajouter Cloud Storage. Cela nous aidera à déterminer l'impact de la protection du périmètre en nous montrant les cas de non-respect des règles de VPC Service Controls dans les journaux d'audit. Toutefois, les ressources resteront accessibles tant que nous n'appliquerons pas le périmètre.

Dans la console Google, sélectionnez votre organisation, puis accédez à VPC Service Controls. Assurez-vous que vous êtes au niveau de l'organisation.
Ouvrez Cloud Shell et mettez à jour le périmètre en mode dry run "SuperProtection" créé dans l'atelier précédent :

gcloud access-context-manager perimeters dry-run update SuperProtection --policy=POLICY --add-restricted-services=storage.googleapis.com

Vérifiez que l'API Cloud Storage a été mise à jour en décrivant le périmètre.

gcloud access-context-manager perimeters dry-run describe SuperProtection --policy=POLICY

Dans la sortie, vous verrez que l'API Cloud Storage est listée sous les services restreints

avec l'API Compute Engine, mais avec un libellé "-vpcAccessibleServices: {}" :

5. Vérifier que l'API Cloud Storage a été protégée

En mode dry run, vérifiez que le périmètre "SuperProtection" nous montre le refus en listant l'objet de l'instance de VM créée dans ProjectZ vers ProjectX, qui héberge le bucket de stockage.

Dans la console Cloud, accédez au sélecteur de projet et sélectionnez ProjectZ, puis accédez à Compute Engine > Instances de VM.
Cliquez sur le bouton SSH pour vous connecter à l'instance de VM et accéder à sa ligne de commande.

Listez le fichier hello.txt que nous avons importé précédemment.

gcloud storage ls gs://BUCKET_NAME

Comme l'API Cloud Storage est protégée en mode dry run, vous devriez pouvoir lister les ressources, mais vous devez avoir un message d'erreur dans les journaux d'audit de ProjectZ.

Accédez à l'API de l'explorateur de journaux dans ProjectZ et recherchez le dernier message d'erreur de VPC Service Controls. Vous pouvez utiliser ce filtre pour obtenir le journal que nous recherchons :

protoPayload.status.details.violations.type="VPC_SERVICE_CONTROLS"
"(Dry Run Mode) Request is prohibited by organization's policy. vpcServiceControlsUniqueIdentifier:UNIQUE_ID"

Ce filtre nous montrera la dernière violation en mode dry run qui appartient à Cloud Storage. Voici un exemple de journal. Nous pouvons valider que la violation est une sortie lorsque nous essayons de lister le contenu du bucket situé dans ProjectX.

egressViolations: [
0: {
servicePerimeter: "accessPolicies/POLICY/servicePerimeters/SuperProtection"
source: "projects/PROJECTX_ID"
sourceType: "Network"
targetResource: "projects/PROJECTZ_ID"
}
]
resourceNames: [
0: "projects//buckets/BUCKET_NAME"
]
securityPolicyInfo: {
organizationId: "ORGANIZATION_ID"
servicePerimeterName: "accessPolicies/POLICY/servicePerimeters/SuperProtection"
}
violationReason: "NETWORK_NOT_IN_SAME_SERVICE_PERIMETER"
vpcServiceControlsUniqueId: "UNIQUE_ID"
}
methodName: "google.storage.objects.list"

Comme nous avons validé que l'appel d'API à Cloud Storage génère une violation de VPC Service Controls, nous allons appliquer le périmètre avec la nouvelle configuration. Ouvrez Cloud Shell et appliquez le périmètre en mode dry run :

gcloud access-context-manager perimeters dry-run enforce SuperProtection --policy=POLICY --async

Connectez-vous à l'instance de VM à l'aide de SSH et listez à nouveau le bucket de stockage pour vérifier que le périmètre en mode dry run a été correctement appliqué.

gcloud storage ls gs://BUCKET_NAME

Nous allons obtenir une violation de VPC Service Controls dans la CLI de la VM au lieu d'une liste des objets de stockage :

ERROR: (gcloud.storage.ls) User [PROJECT_NUMBER-compute@developer.gserviceaccount.com] does not have permission to access b instance [BUCKET_NAME] (or it may not exist): Request is prohibited by organization's policy. vpcServiceControlsUniqueIdentifier:"UNIQUE_ID"

Nous avons réussi à empêcher l'exfiltration de données en utilisant VPC Service Controls pour empêcher la lecture ou la copie de données vers une ressource en dehors du périmètre.

6. Résoudre le problème de refus de liste

Nous allons résoudre le problème de refus que nous avons rencontré dans la CLI de l'instance de VM. Vérifions les journaux d'audit et recherchons l'ID unique de VPC Service Controls.

Accédez au sélecteur de projet et sélectionnez ProjectZ.
Recherchez l'ID unique de VPC Service Controls dans les journaux d'audit à l'aide de la requête suivante dans l'explorateur de journaux :

resource.type="audited_resource"
protoPayload.metadata."@type"="type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"

Tous les journaux d'audit de VPC Service Controls s'affichent. Nous allons rechercher le dernier journal d'erreurs. Comme l'appel d'API a été effectué à partir de l'instance de VM, le principal doit être le compte de service Compute Engine "PROJECT_NUMBER-compute@developer.gserviceaccount.com"

Comme nous disposons déjà de l'ID unique de VPC Service Controls, nous pouvons l'utiliser pour obtenir directement le journal souhaité à l'aide de ce filtre :

protoPayload.metadata.vpcServiceControlsUniqueId="UNIQUE_ID"

Cliquez sur l'en-tête VPC Service Controls, puis sélectionnez "Résoudre le problème de refus". L'outil de dépannage de VPC Service Controls s'ouvre.

Cette API nous montre dans une interface utilisateur conviviale la raison de la violation et si elle concerne l'entrée ou la sortie, entre autres informations utiles.

Dans cet exercice, nous allons rechercher les éléments suivants :

authenticationInfo: {
principalEmail: "PROJECT_ID-compute@developer.gserviceaccount.com"
egressViolations: [
0: {
servicePerimeter: "accessPolicies/POLICY/servicePerimeters/SuperProtection"
source: "projects/PROJECTZ_ID"
sourceType: "Network"
targetResource: "projects/PROJECTX_ID"
}
violationReason: "NETWORK_NOT_IN_SAME_SERVICE_PERIMETER"

Ces informations nous suffisent pour savoir que nous devons créer une règle de sortie afin de permettre au compte de service Compute Engine d'accéder au bucket de stockage de ProjectZ à ProjectX. Nous pouvons également constater que le réseau ne se trouve pas dans le même périmètre. Nous devons donc autoriser la communication VPC aux services et partager des données entre les périmètres de service.

Activez Cloud Shell et créez un fichier .yaml avec la règle de sortie à l'aide d'un éditeur de texte.

nano egresstorage.yaml

- egressTo:
    operations:
    - serviceName: storage.googleapis.com
      methodSelectors:
      - method: \"*\"
    resources:
    - projects/PROJECTX_ID
 egressFrom:
    identities:
    - serviceAccount:PROJECT_ID-compute@developer.gserviceaccount.com

Mettez à jour la règle d'entrée qui protège ProjectZ.

gcloud access-context-manager perimeters update SuperProtection --set-egress-policies=egresstorage.yaml --policy=POLICY

Nous pouvons maintenant réessayer d'accéder au bucket à partir de l'instance de VM.

Dans la console Cloud, accédez au sélecteur de projet et sélectionnez ProjectZ, puis accédez à Compute Engine > Instances de VM.
Cliquez sur le bouton SSH pour vous connecter à l'instance de VM et accéder à sa ligne de commande.
Une fois dans la CLI de la VM, essayez de lister les objets du bucket de stockage.

gcloud storage ls gs://BUCKET_NAME/

Le message d'erreur suivant s'affiche :

ERROR: (gcloud.storage.ls) User [PROJECT_ID-compute@developer.gserviceaccount.com] does not have permission to access b instance [BUCKET_NAME] (or it may not exist): PROJECT_ID-compute@developer.gserviceaccount.com does not have storage.objects.list access to the Google Cloud Storage bucket. Permission 'storage.objects.list' denied on resource (or it may not exist).

Nous devons accorder une autorisation de lecteur d'objet au compte de service Compute Engine pour pouvoir lister les objets du bucket de stockage.

gcloud storage buckets add-iam-policy-binding gs://BUCKET_NAME --member=serviceAccount:PROJECT_ID-compute@developer.gserviceaccount.com --role=roles/storage.objectViewer

Essayons à nouveau de lister le fichier hello.txt à partir de la CLI de l'instance de VM .

gcloud storage ls gs://BUCKET_NAME/
.
.
gs://BUCKET_NAME/hello.txt

Nous pouvons maintenant lister l'objet sans violation d'autorisation VPC Service Controls. Mais qu'en est-il du téléchargement du fichier ? Essayons.

gcloud storage cp gs://BUCKET_NAME/hello.txt /home/${USER}

La sortie suivante s'affiche :

Copying gs://BUCKET_NAME/hello.txt to file:///home/${USER}
 Completed files 1/1 | 54.0B/54.0B

7. Nettoyage

Bien que l'utilisation de VPC Service Controls ne fasse pas l'objet d'une facturation distincte lorsque le service n'est pas utilisé, il est recommandé de nettoyer la configuration utilisée dans cet atelier. Vous pouvez également supprimer votre instance de VM et/ou vos projets Cloud pour éviter des frais. La suppression de votre projet Cloud arrête la facturation de toutes les ressources utilisées dans ce projet.

Pour supprimer votre instance de VM, cochez la case à gauche de son nom, puis cliquez sur Supprimer.

Pour supprimer le périmètre, procédez comme suit :

Dans la console Google Cloud, cliquez sur Sécurité, puis sur VPC Service Controls au niveau de l'organisation.
Sur la page VPC Service Controls, dans la ligne du tableau correspondant au périmètre que vous souhaitez supprimer, cliquez sur l'icône de suppression.

Pour supprimer le niveau d'accès, procédez comme suit :

Dans la console Google Cloud, ouvrez la page Access Context Manager au niveau du dossier.
Dans la grille, cliquez sur l'icône de suppression de la ligne correspondant au niveau d'accès que vous souhaitez supprimer, puis cliquez sur Supprimer.

Pour supprimer l'objet et le bucket de stockage, procédez comme suit :

Dans la console Google Cloud, ouvrez la page Buckets Cloud Storage .
Cochez la case à côté du bucket que vous avez créé.
Cliquez sur Supprimer.
Dans la fenêtre qui s'ouvre, confirmez que vous souhaitez supprimer le bucket.
Cliquez sur Supprimer.

Pour arrêter votre projet, procédez comme suit :

Dans la console Google Cloud, accédez à la page Paramètres de la section IAM et administration du projet que vous souhaitez supprimer.
Sur la page Paramètres de la section IAM et administration, cliquez sur Arrêter.
Saisissez l'ID du projet, puis cliquez sur Arrêter quand même.

8. Félicitations !

Dans cet atelier de programmation, vous avez mis à jour un périmètre en mode dry run de VPC Service Controls, l'avez appliqué et avez résolu les problèmes.

En savoir plus

Consultez la documentation de VPC Service Controls.
Consultez la documentation d'Access Context Manager.
Consultez la documentation de l'outil de dépannage de VPC-SC.
Consultez la documentation sur les règles d'entrée et de sortie.
Consultez la documentation sur le mode dry run.
Consultez la documentation de Cloud Storage.

Licence

Ce document est publié sous une licence Creative Commons Attribution 2.0 Generic.