VPC Service Controls : atelier de programmation I sur la protection BigQuery

1. Introduction

Dans cet atelier de programmation, vous allez apprendre à protéger l'API BigQuery à l'aide de VPC Service Controls. L'atelier de programmation commence sans aucun service d'API protégé par le périmètre de service, ce qui permet d'exécuter des requêtes sur des ensembles de données publics et d'enregistrer les résultats dans une table de projet. La requête s'exécute dans un projet et la table (où les résultats sont enregistrés) est créée dans un autre projet, ce qui imite une configuration dans laquelle les données peuvent être stockées dans un projet, mais doivent être accessibles à l'aide d'un autre projet.

Nous allons ensuite présenter un périmètre de service pour protéger le projet de données. Vous apprendrez à corriger les cas de non-respect observés à l'aide de règles d'entrée et de sortie, puis à ajouter un niveau d'accès pour restreindre l'accès à l'aide d'adresses IP internes. Les objectifs de cet atelier de programmation sont les suivants :

• Découvrez comment résoudre les cas de non-respect des règles d'entrée et de sortie à l'aide des règles d'entrée et de sortie, respectivement.
• comprendre pourquoi une infraction spécifique s'est produite ;
• Analysez le champ d'application de la correction appliquée.
• Modifiez le correctif (règle de trafic entrant / sortant) pour changer son champ d'application en utilisant l'option permettant d'autoriser le trafic provenant d'adresses IP internes dans un réseau VPC à l'aide de niveaux d'accès.

2. Configuration et exigences des ressources

Avant de commencer

Dans cet atelier de programmation, nous partons du principe que vous connaissez déjà les éléments suivants :

• Les principes de base pour exécuter une requête BigQuery : vous pouvez consulter cet atelier de programmation pour découvrir comment interroger l'ensemble de données Wikipédia dans BigQuery.
• Créer et gérer un dossier
• Créer un projet dans un dossier ou déplacer un projet existant dans un dossier
• Comment créer une règle d'accès limitée
• Créer et configurer un périmètre de service
• Trouver les cas de non-respect des règles de sécurité dans les journaux

Configuration

Notre configuration initiale est conçue comme suit :

Si vous avez suivi le tutoriel de base sur VPC Service Controls, vous pouvez réutiliser les mêmes projets, dossier et périmètre de service.

• Une organisation Google Cloud.
• Un dossier sous l'organisation. Pour cet atelier de programmation, nous l'appellerons codelab-folder.
• Deux projets Google Cloud placés dans le même dossier, codelab-folder. Pour cet atelier de programmation, nous les appelons project-1 et project-2
  .
  • Si vous n'avez pas encore créé le dossier et les projets, dans la console Google Cloud, créez un dossier sous l'organisation, puis créez deux projets dans ce dossier.
• Autorisations requises :
  • Rôles IAM pour gérer les dossiers : attribués au niveau du dossier
  • Rôles IAM pour gérer les projets : attribués au niveau du projet
  • Rôles IAM requis pour configurer VPC Service Controls : attribués au niveau de l'organisation
  • Rôles IAM pour gérer BigQuery : attribués au niveau du projet
  • Rôles IAM pour gérer les instances Compute Engine : attribués au niveau du projet
• Compte de facturation pour les deux projets, project-2 et project-1.

Pour ce tutoriel, vous pouvez vous attribuer les rôles prédéfinis suivants : Administrateur de dossiers et Créateur de projets (au niveau du dossier), Propriétaire (au niveau du projet), Administrateur BigQuery (au niveau du projet) et Administrateur Access Context Manager (au niveau de l'organisation). Vous disposerez ainsi des rôles requis pour configurer les ressources nécessaires à l'ensemble de ce tutoriel.

Créer un périmètre de service standard

Dans cet atelier de programmation, nous utiliserons un périmètre de service standard protégeant project-1.

• Créez un périmètre standard, perimeter-1, et ajoutez project-1.

Dans le périmètre, ne restreignez aucun service pour le moment. Nous le ferons plus tard.

Créer une VM Compute Engine

Dans cet atelier de programmation, nous utiliserons une instance Compute Engine dans project-2, située dans us-central1 et utilisant le réseau VPC par défaut nommé default.

• Vous pouvez vous référer à la documentation pour créer une instance Compute Engine à partir d'une image publique.

Pour cet atelier de programmation, nous allons utiliser le réseau VPC par défaut, nommé default. Vous pouvez également utiliser n'importe quel autre réseau, à condition qu'il comporte au moins un sous-réseau.

Coût

Vous devez activer la facturation dans la console Google Cloud pour utiliser les ressources/API Cloud. Nous vous conseillons d'arrêter les ressources utilisées pour éviter qu'elles ne vous soient facturées au-delà de cet atelier de programmation. Les nouveaux utilisateurs de Google Cloud peuvent participer au programme d'essai sans frais pour bénéficier d'un crédit de 300 $.

Les ressources qui entraînent des coûts sont BigQuery et l'instance Compute Engine. Vous pouvez estimer le coût à l'aide du simulateur de coût BigQuery et du simulateur de coût Compute Engine.

3. Accès à BigQuery sans restrictions VPC Service Controls

Interroger un ensemble de données public et enregistrer les résultats dans project-1

1. Accédez à project-2 et project-1 pour vérifier si vous pouvez accéder à l'API BigQuery en accédant à la page BigQuery Studio. Vous devriez pouvoir le faire, car même si project-1 se trouve dans un périmètre de service, ce périmètre ne protège encore aucun service.
2. À partir de project-2, exécutez la requête suivante pour interroger un ensemble de données public.

SELECT  name, SUM(number) AS total
FROM  `bigquery-public-data.usa_names.usa_1910_2013`
GROUP BY   name
ORDER BY total DESC
LIMIT 10;

Après avoir exécuté la requête sur l'ensemble de données public (tout en restant dans project-2) :

1. Cliquez sur Enregistrer les résultats, puis sélectionnez Table BigQuery. (voir la capture d'écran ci-dessous).
2. Sélectionnez project-1 comme projet de destination.
3. Nommez l'ensemble de données codelab_dataset. (Sélectionnez CRÉER UN ENSEMBLE DE DONNÉES, sauf si vous utilisez un ensemble de données existant.)
4. Nommez le tableau : codelab-table.
5. Cliquez sur Enregistrer.

Les données de l'ensemble de données public ont été stockées dans project-1 après l'exécution de la requête à partir de project-2.

Ensemble de données de requête enregistré dans project-1 depuis project-2

Tout en restant dans project-2 BigQuery Studio, exécutez la requête suivante pour sélectionner des données :

• Projet : project-1
• Ensemble de données : codelab_dataset
• Table : codelab-table

SELECT name, total
FROM `project-1.codelab_dataset.codelab-table`
ORDER BY total DESC
LIMIT 10;

La requête devrait s'exécuter correctement, car ni project-2 ni project-1 ne sont limités à l'utilisation de BigQuery. L'accès à BigQuery est autorisé depuis et vers n'importe quel emplacement, à condition que l'utilisateur dispose des autorisations IAM appropriées.

 Ce diagramme illustre le processus lorsqu'un principal interroge un ensemble de données BigQuery. Chaque requête BigQuery lance un job BigQuery, qui effectue ensuite l'opération proprement dite (dans ce scénario, la récupération des données). L'accès principal est démontré à partir d'une instance Compute Engine et d'Internet, lors de l'interrogation d'un ensemble de données public et d'un projet Google Cloud distinct. Le processus d'interrogation des données (GetData) est réussi, sans être bloqué par VPC Service Controls.

4. Protéger l'API BigQuery dans le projet d'ensemble de données source

Modifiez la configuration du périmètre perimeter-1 et limitez le service API BigQuery avec la ressource protégée project-1.

Vérifier l'application du périmètre de service

À partir de project-2, exécutez la requête suivante dans BigQuery Studio, comme à l'étape précédente :

SELECT name, total
FROM `project-1.codelab_dataset.codelab-table`
ORDER BY total DESC
LIMIT 10;

Un non-respect de VPC Service Controls RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER se produit

Le journal d'audit des cas de non-respect se trouve dans project-1, car c'est là que la violation du périmètre s'est produite. Les journaux peuvent être filtrés avec l'vpcServiceControlsUniqueId observé (remplacez VPC_SC_DENIAL_UNIQUE_ID par l'ID unique observé).

severity=ERROR
resource.type="audited_resource"
protoPayload.metadata.@type="type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"
protoPayload.metadata.vpcServiceControlsUniqueId="[*VPC_SC_DENIAL_UNIQUE_ID*]"

La violation est une egressViolations avec :

• principalEmail : [compte utilisateur exécutant la requête]
• callerIp : [Adresse IP de l'user-agent exécutant la requête]

     "egressViolations": [
       {
         "targetResource": "projects/project-2",
         "sourceType": "Resource",
         "source": "projects/project-1",
         "servicePerimeter": "accessPolicies/REDACTED/servicePerimeters/perimeter-1",
         "targetResourcePermissions": [ "bigquery.jobs.create"]
       }      ],

5. Corriger le non-respect pour créer une tâche BigQuery

La permission cible de la non-respect de VPC Service Controls est bigquery.jobs.create en raison du fonctionnement de BigQuery. Lorsque vous utilisez la console Google Cloud (ou l'outil de ligne de commande bq) pour gérer les données BigQuery, BigQuery crée des jobs qui sont ensuite utilisés pour effectuer les actions souhaitées. Le premier événement consiste à créer une tâche BigQuery.

 Ce diagramme illustre le moment où un principal exécute une requête à partir de project-2 pour un ensemble de données dans project-1. L'opération de création d'un job BigQuery à partir du projet d'ensemble de données (project-1) dans le projet à partir duquel la requête est exécutée (project-2) échoue en raison d'un non-respect des règles de sortie de VPC Service Controls dû au périmètre de service perimeter-1 protégeant l'API BigQuery. Avec le périmètre en place, aucune requête API BigQuery ne peut être lancée depuis project-1 vers l'extérieur du périmètre ni depuis l'extérieur du périmètre vers le projet protégé, sauf si les configurations du périmètre de service l'autorisent.

Pour corriger un cas de non-respect des règles de sortie, vous pouvez créer une règle de sortie basée sur les éléments suivants :

• source (FROM), à savoir l'adresse e-mail de l'utilisateur et le contexte (par exemple, l'adresse IP de l'appelant, l'état de l'appareil, l'emplacement, etc.)
• destination (TO) : à savoir la ressource, le service, la méthode ou l'autorisation cibles.

Pour corriger la violation de sortie observée, créez une règle de sortie qui autorise le trafic vers le targetResource (project-2) par le compte utilisateur exécutant la requête ([e-mail]) sur le service BigQuery et la méthode/ autorisation bigquery.jobs.create.

Comportement attendu de la règle de sortie configurée :

• FROM | Identités : seule l'identité spécifiée [e-mail] doit être autorisée à franchir la limite du périmètre.
• TO | projects : l'identité spécifiée ne peut franchir les limites du périmètre que si la destination est le projet spécifié project-2.
• TO | Services : l'identité spécifiée peut initier du trafic en dehors du périmètre, vers le projet spécifié uniquement si l'appel d'API concerne le service et la méthode spécifiés. Sinon, par exemple s'il essaie un autre service protégé par le périmètre de service, l'opération sera bloquée, car les autres services ne sont pas autorisés.

Tester la correction : règle de sortie

Une fois la règle de sortie en place, exécutez la même requête.

SELECT name, total
FROM `project-1.codelab_dataset.codelab-table`
ORDER BY total DESC
LIMIT 10;

Une autre erreur se produit, cette fois-ci une erreur d'entrée NO_MATCHING_ACCESS_LEVEL. La nouvelle infraction est différente de la première en termes de projet cible et de méthode.

Corriger un cas de non-respect de VPC Service Controls ne signifie pas qu'aucun autre cas ne se produira. Un nouvel appel d'API avec un contexte différent de ceux autorisés par la règle déjà configurée entraînera un autre non-respect.

Le nouveau cas de non-respect concerne une entrée avec

• principalEmail : [compte utilisateur exécutant la requête]
• callerIp : [Adresse IP de l'user-agent exécutant la requête]

ingressViolations: [
0: {
 servicePerimeter: "accessPolicies/REDACTED/servicePerimeters/perimeter-1"
 targetResource: "projects/project-1"
 targetResourcePermissions: [0: "bigquery.tables.getData"]}
 ]

Le non-respect de la méthode bigquery.tables.getData est dû à un appel d'API initié par le job BigQuery qui tente d'obtenir des données à partir de la table BigQuery.

Il est important de comprendre le fonctionnement d'un service d'API donné pour anticiper les cas de non-respect attendus.

6. Corriger le non-respect pour obtenir les données de la table BigQuery

Une règle d'entrée corrige une violation d'entrée tout en offrant un contrôle précis sur les personnes autorisées à franchir la limite du périmètre de service, ainsi que sur le contexte de l'accès autorisé, comme le projet source/ cible et la méthode d'API à laquelle elles peuvent accéder.

Un cas de non-respect des règles d'entrée est corrigé par une règle d'entrée configurée avec :

• source (FROM), à savoir l'adresse e-mail de l'utilisateur et le contexte (par exemple, l'adresse IP de l'appelant, l'état de l'appareil, l'emplacement, etc.)
• destination (TO) : à savoir la ressource, le service, la méthode ou l'autorisation cibles.

La règle d'entrée autorisera le trafic vers project-1 par l'utilisateur spécifié sur le service et la méthode spécifiés.

Comportement attendu de la règle d'entrée configurée :

• FROM | Identités : seule l'identité spécifiée [e-mail] doit être autorisée à franchir la limite du périmètre.
• TO | projects : l'identité spécifiée ne peut franchir les limites du périmètre que si la destination est le projet spécifié project-1.
• TO : l'identité spécifiée ne peut initier le trafic à l'intérieur du périmètre que si l'appel d'API concerne l'API BigQuery et la méthode spécifiée bigquery.tables.getData.

L'exécution de la même requête devrait désormais fonctionner correctement, sans cas de non-respect de VPC Service Controls.

Nous avons réussi à restreindre l'API BigQuery dans project-1 afin qu'elle ne puisse être utilisée que par [e-mail] et non par [e-mail].

 Ce diagramme illustre la façon dont deux principaux différents tentent d'interroger le même ensemble de données. L'accès par [e-mail] (lignes bleues en pointillés) est refusé par VPC Service Controls, car il n'est pas autorisé à exécuter des opérations BigQuery depuis ou vers project-1 par la configuration du périmètre de service. L'accès par [e-mail] (ligne verte continue) est autorisé, car les configurations VPC Service Controls permettent d'effectuer des opérations depuis et vers project-1.

7. Restreindre le trafic autorisé par le périmètre de service en fonction de l'adresse IP interne

La configuration actuelle permet à l'utilisateur désigné d'exécuter des requêtes sur BigQuery dans project-1 depuis n'importe quel emplacement sur Internet, à condition qu'il dispose de l'autorisation IAM pour interroger les données et qu'il utilise son compte. Du point de vue de la sécurité, cela signifie que si le compte est piraté, toute personne qui y accède peut accéder aux données BigQuery sans aucune restriction supplémentaire.

Vous pouvez implémenter d'autres restrictions en utilisant le niveau d'accès dans les règles d'entrée et de sortie pour spécifier le contexte utilisateur. Par exemple, vous pouvez autoriser l'accès en fonction de l'adresse IP source en même temps qu'une règle d'entrée précédemment configurée qui autorise l'accès par identité de l'appelant. L'accès par adresse IP source est possible pour les plages CIDR d'adresses IP publiques, à condition que le client utilisateur dispose d'une adresse IP publique qui lui est attribuée, ou en utilisant une adresse IP interne si le client utilisateur fonctionne à partir d'un projet Google Cloud.

Créer un niveau d'accès avec une condition d'accès basée sur une adresse IP interne

Dans le même dossier de stratégie d'accès limitée, ouvrez la page Access Context Manager pour créer un niveau d'accès.

1. Sur la page Access Context Manager, sélectionnez CRÉER UN NIVEAU D'ACCÈS.
2. Dans le volet "Nouveau niveau d'accès" :
   1. Indiquez un titre : vous pouvez utiliser codelab-al.
   2. Dans la section "Conditions", cliquez sur Sous-réseaux IP.
   3. Sélectionnez l'onglet Adresse IP privée, puis cliquez sur SÉLECTIONNER DES RÉSEAUX VPC.
   4. Dans le volet Ajouter des réseaux VPC, vous pouvez parcourir et trouver le réseau default, ou saisir manuellement le nom complet du réseau au format //compute.googleapis.com/projects/project-2/global/networks/default.
   5. Cliquez sur AJOUTER UN RÉSEAU VPC.
   6. Cliquez sur SÉLECTIONNER DES SOUS-RÉSEAUX IP.
   7. Sélectionnez la région où se trouve l'instance de VM. Pour cet atelier de programmation, il s'agit de us-central1.
   8. Cliquez sur ENREGISTRER.

Nous avons créé un niveau d'accès, qui n'est toujours pas appliqué à un périmètre ni à une règle d'entrée/sortie.

Ajouter un niveau d'accès à la règle d'entrée

Pour s'assurer que l'utilisateur autorisé par la règle d'entrée est également validé par rapport au niveau d'accès, il est nécessaire de configurer le niveau d'accès dans la règle d'entrée. La règle d'entrée qui autorise l'accès aux données de requête se trouve dans perimeter-1. Modifiez la règle d'entrée pour définir la source comme niveau d'accès codelab-al.

Tester de nouvelles configurations

Après l'ajout du niveau d'accès dans la règle d'entrée, la même requête BigQuery échouera, sauf si elle est exécutée à partir du client dans le réseau VPC default pour le projet project-2. Pour vérifier ce comportement, exécutez la requête depuis la console Google Cloud lorsque l'appareil de point de terminaison est connecté à Internet. La requête se terminera sans succès, accompagnée d'une indication de non-respect des règles d'entrée.

Par défaut :

• Le niveau d'accès d'une instance Compute Engine est défini par défaut sur Accès par défaut, ce qui n'autorise pas l'accès à l'API BigQuery.
• Une instance Compute Engine sera associée au compte de service Compute Engine par défaut. Parallèlement, toutes les commandes exécutées à partir de la VM s'exécuteront en tant que ce compte de service, qui doit être au format [e-mail].
   Le niveau d'accès et le compte de service associés à la VM peuvent être modifiés.

La même requête peut être exécutée à partir du réseau VPC default, situé dans project-2. De même, l'exécution de la même requête BigQuery à partir d'une instance Compute Engine située dans project-2 à l'aide du réseau VPC default échouera également. En effet, la règle d'entrée est toujours configurée pour n'autoriser que le compte principal [e-mail]. Toutefois, la VM utilise le compte de service Compute Engine par défaut.

Pour exécuter la même commande à partir de l'instance Compute Engine dans project-2,assurez-vous que :

• La VM dispose d'un champ d'application pour utiliser l'API BigQuery. Pour ce faire, sélectionnez Autoriser l'accès complet à l'ensemble des API Cloud comme niveau d'accès à la VM.
• Le compte de service associé à la VM doit disposer des autorisations IAM suivantes :
  • Créer des jobs BigQuery dans project-2
  • Obtenez les données BigQuery à partir de la table BigQuery située dans project-1.
• Le compte de service Compute Engine par défaut doit être autorisé par la règle d'entrée et de sortie.

Nous devons maintenant ajouter le compte de service Compute Engine par défaut aux règles d'entrée (pour autoriser l'obtention de données à partir de la table BigQuery) et à la règle de sortie (pour autoriser la création de tâches BigQuery).

Depuis une instance Compute Engine dans project-2 sur le réseau VPC default, exécutez la commande de requête bq suivante :

bq query --nouse_legacy_sql \
'SELECT name, total
FROM `project-1.codelab_dataset.codelab-table`
ORDER BY total DESC
LIMIT 10;'

Avec la configuration actuelle, la commande BigQuery ne réussira que si :

• s'exécuter sur une VM à l'aide du réseau VPC par défaut dans project-2 ;
• situé dans la région us-central1 spécifiée (sous-réseau IP) ;
• s'exécuter à l'aide du compte de service Compute Engine par défaut configuré dans le périmètre de service.

La requête de commande BigQuery échouera si elle est exécutée ailleurs, y compris :

• si elle est exécutée sur une VM utilisant le réseau VPC par défaut dans project-2, mais située dans une région différente de celle du sous-réseau ajouté au niveau d'accès ;
• si l'utilisateur [e-mail] l'exécute avec un client utilisateur sur Internet.

 Ce schéma illustre l'accès initié par le même principal, [e-mail], depuis deux emplacements différents : Internet et une instance Compute Engine. L'accès à BigQuery directement depuis Internet (lignes pointillées bleues) est bloqué par VPC Service Controls, tandis que l'accès depuis une VM (lignes pleines vertes) est autorisé (tout en usurpant l'identité du compte de service Compute Engine par défaut). L'accès autorisé est dû au fait que le périmètre de service est configuré pour autoriser l'accès aux ressources protégées à partir d'une adresse IP interne.

8. 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 l'instance de VM, les ensembles de données BigQuery ou les projets Google Cloud pour éviter des frais. La suppression du projet Cloud arrête la facturation de toutes les ressources utilisées dans ce projet.

• Pour supprimer l'instance de VM, procédez comme suit :
  • Dans la console Google Cloud, accédez à la page Instances de VM.
  • Cochez la case à gauche du nom de l'instance de VM, puis sélectionnez Supprimer, puis cliquez à nouveau sur Supprimer pour confirmer.
• Pour supprimer le périmètre de service, procédez comme suit :
  • Dans la console Google Cloud, sélectionnez Sécurité, puis VPC Service Controls au niveau où la règle d'accès est définie (dans ce cas, au niveau du dossier).
  • Sur la page "VPC Service Controls", dans la ligne du tableau correspondant au périmètre que vous souhaitez supprimer, cliquez sur Supprimer.
• 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, identifiez la ligne correspondant au niveau d'accès que vous souhaitez supprimer, sélectionnez le menu à trois points, puis Supprimer.
• Pour arrêter les projets, procédez comme suit :
  • Dans la console Google Cloud, accédez à la page Paramètres IAM et administration du projet que vous souhaitez supprimer.
  • Sur la page "IAM et paramètres d'administration", sélectionnez Arrêter.
  • Saisissez l'ID du projet, puis sélectionnez Arrêter quand même.

9. Félicitations !

Dans cet atelier de programmation, vous avez créé un périmètre VPC Service Controls, l'avez appliqué et avez résolu les problèmes associés.

En savoir plus

Vous pouvez également explorer les scénarios suivants :

• Exécutez la même requête sur l'ensemble de données public, une fois le projet protégé par VPC Service Controls.
• Ajoutez project-2 dans le même périmètre que project-1.
• Ajoutez project-2 dans son propre périmètre et conservez project-1 dans le périmètre actuel.
• Exécutez des requêtes pour mettre à jour les données de la table, et pas seulement pour les récupérer.

Licence

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