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. Au début de l'atelier de programmation, aucun service d'API n'est 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, imitant une configuration dans laquelle les données peuvent être stockées dans un projet, mais doivent être accessibles à l'aide d'un autre projet.

Ensuite, nous introduirons un périmètre de service pour protéger le projet de données. Vous allez apprendre à 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 limiter 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 de règles d'entrée et de sortie, respectivement.
• Comprendre pourquoi un cas de non-respect spécifique s'est produit
• Analysez la portée de la correction du cas de non-conformité appliqué.
• Modifiez le correctif (règle d'entrée / de sortie) pour modifier 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 des ressources et conditions requises

Avant de commencer

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

• Principes de base pour exécuter une requête BigQuery: consultez cet atelier de programmation pour apprendre à interroger un 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
• Créer une règle d'accès délimitée
• Créer et configurer un périmètre de service
• Identifier 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, dossiers et périmètres 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, créez un dossier sous l'organisation dans la console Google Cloud, puis créez deux projets sous ce dossier.
• Autorisations requises:
  • Rôles IAM pour la gestion des dossiers: attribués au niveau du dossier
  • Rôles IAM pour la gestion de 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 la gestion de BigQuery: attribués au niveau du projet
  • Rôles IAM pour la gestion des instances Compute Engine: attribués au niveau du projet
• Compte de facturation pour les deux projets, project-2 et project-1.

Pour les besoins de cet atelier de programmation, vous pouvez vous attribuer les rôles prédéfinis suivants: Administrateur de dossier et Créateur de projet (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). et vous disposerez des rôles requis pour configurer les ressources nécessaires pour l'intégralité de cet atelier de programmation.

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, puis ajoutez le project-1.

Ne limitez pas encore de service dans le périmètre. Nous le ferons plus tard.

Créer une VM Compute Engine

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

• Vous pouvez vous reporter à la documentation pour savoir comment créer une instance Compute Engine à partir d'une image publique.

Pour cet atelier de programmation, nous utiliserons 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 que des frais ne vous soient facturés au-delà de cet atelier de programmation. Les nouveaux utilisateurs de Google Cloud peuvent participer au programme d'essai sans frais avec un crédit de 300 $.

Les ressources qui entraînent des frais sont BigQuery et les instances Compute Engine. Vous pouvez obtenir une estimation des coûts à l'aide du simulateur de coût BigQuery et du simulateur de coût Compute Engine.

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

Interroger l'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, celui-ci ne protège pour l'instant aucun service.
2. Depuis 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 et sélectionnez la table BigQuery. (reportez-vous à 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 la table codelab-table.
5. Cliquez sur Enregistrer.

Les données de l'ensemble de données public ont bien été stockées dans project-1 à la suite de l'exécution de la requête depuis 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 les 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 où, tant que l'utilisateur dispose des autorisations IAM appropriées.

Ce schéma illustre le processus appliqué lorsqu'un compte principal interroge un ensemble de données BigQuery. Chaque requête BigQuery lance un job BigQuery qui effectue ensuite l'opération réelle, dans ce scénario, qui consiste à récupérer les données. L'accès des comptes principaux est possible à partir d'une instance Compute Engine et d'Internet, tandis que les requêtes sont effectuées à partir d'un ensemble de données public et d'un projet Google Cloud distinct. Le processus d'interrogation des données (GetData) a abouti, mais n'est pas bloqué par VPC Service Controls.

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

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

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

Depuis 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 cas de non-respect RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER de VPC Service Controls se produira

Le journal d'audit des cas de non-conformité se trouvera dans project-1, car c'est là que s'est produite la violation qui doit traverser le périmètre. Les journaux peuvent être filtrés avec le 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*]"

Il s'agit d'une infraction egressViolations avec:

• principalEmail: [compte utilisateur exécutant la requête]
• callerIp: [adresse IP du user-agent qui exécute 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 la violation pour créer un job BigQuery

La violation VPC Service Controls dispose d'une autorisation cible bigquery.jobs.create en raison du fonctionnement de BigQuery. Lorsque vous gérez des données BigQuery à l'aide de la console Google Cloud (ou de l'outil de ligne de commande bq), BigQuery crée des jobs qui permettent ensuite d'effectuer les actions souhaitées. Pendant ce temps, le premier événement consiste à créer un job BigQuery.

Ce schéma montre comment un compte principal exécute une requête depuis project-2 sur un ensemble de données situé 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 avec une violation de sortie VPC Service Controls due au périmètre de service perimeter-1 protégeant l'API BigQuery. Une fois 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 en dehors du périmètre vers le projet protégé. sauf si les configurations du périmètre de service le permettent.

Vous pouvez résoudre un cas de non-respect des règles de sortie en créant 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, adresse IP de l'appelant, état de l'appareil, localisation, etc.)
• destination (TO): à savoir la ressource, le service, la méthode ou l'autorisation cibles.

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

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

• FROM | Identités: seule l'identité [e-mail] spécifiée doit être autorisée à traverser les limites du périmètre.
• À | projects: l'identité spécifiée ne peut dépasser les limites du périmètre que si la destination est le projet project-2 spécifié.
• À | Services: l'identité spécifiée ne peut lancer du trafic en dehors du périmètre vers le projet spécifié que si l'appel d'API concerne le service et la méthode spécifiés. Dans le cas contraire, 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 le correctif: 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 infraction va se produire, cette fois-ci une violation 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.

La résolution d'un cas de non-respect des règles VPC Service Controls ne signifie pas qu'aucun autre cas de non-respect des règles ne se produira. Un nouvel appel d'API dont le contexte est différent de ceux autorisés par une règle déjà configurée entraînera un cas de non-respect différent.

La nouvelle violation est une violation d'entrée avec

• principalEmail: [compte utilisateur exécutant la requête]
• callerIp: [adresse IP du user-agent qui exécute 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 lancé par la tâche BigQuery qui tente d'obtenir des données de la table BigQuery.

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

6. Corriger la violation pour obtenir les données de la table BigQuery

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

Une violation d'entrée est résolue par une règle d'entrée configurée comme suit:

• Source (FROM) : à savoir l'adresse e-mail de l'utilisateur et le contexte (par exemple, adresse IP de l'appelant, état de l'appareil, localisation, 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é pour 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é [e-mail] spécifiée doit être autorisée à traverser les limites du périmètre.
• À | projects: l'identité spécifiée ne peut dépasser les limites du périmètre que si la destination est le projet project-1 spécifié.
• À | Services: l'identité spécifiée ne peut initier du trafic à l'intérieur du périmètre que si l'appel d'API est destiné à l'API BigQuery et à la méthode bigquery.tables.getData spécifiée.

L'exécution d'une requête identique devrait donc désormais fonctionner de manière appropriée sans enfreindre 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 schéma montre comment deux comptes principaux différents tentent d'interroger le même ensemble de données. L'accès de [e-mail] (lignes pointillées bleues) 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 de [e-mail] (ligne continue verte) aboutit, car les configurations VPC Service Controls l'autorisent à effectuer des opérations depuis et vers project-1.

7. Limiter 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. n'importe où sur Internet, à condition qu'ils aient l'autorisation IAM d'interroger les données, et tant qu'ils utilisent leur compte. Du point de vue de la sécurité, cela implique que si le compte est compromis, toute personne qui y parvient peut accéder aux données BigQuery sans aucune restriction supplémentaire.

D'autres restrictions peuvent être mises en œuvre en utilisant le niveau d'accès dans les règles d'entrée et de sortie pour spécifier le contexte de l'utilisateur. Par exemple, vous pouvez autoriser l'accès basé sur l'adresse IP source conjointement avec une règle d'entrée précédemment configurée qui autorise l'accès par l'identité de l'appelant. L'accès par adresse IP source est possible pour les deux plages CIDR d'adresses IP publiques, à condition qu'une adresse IP publique soit attribuée au client utilisateur, 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 à l'adresse IP interne

Dans ce même dossier, 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 soit parcourir et trouver le réseau default, soit 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 appliqué à aucune règle de périmètre ni d'entrée/sortie.

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

Pour faire en sorte que l'utilisateur autorisé par la règle d'entrée soit également validé par rapport au niveau d'accès, vous devez 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 d'interrogation se trouve dans perimeter-1. Modifiez la règle d'entrée pour définir la source en tant que niveau d'accès codelab-al.

Tester de nouvelles configurations

Après l'ajout du niveau d'accès à la règle d'entrée, la même requête BigQuery échouera à moins qu'elle ne soit exécutée par le client du réseau VPC default pour le projet project-2. Pour vérifier ce comportement, exécutez la requête à partir de la console Google Cloud lorsque l'appareil du point de terminaison est connecté à Internet. La requête se termine sans succès, avec une indication de violation du trafic entrant.

Par défaut :

• Le niveau d'accès d'une instance Compute Engine est défini par défaut sur default access (accès par défaut), ce qui n'autorise pas l'accès à l'API BigQuery.
• Les instances Compute Engine sont associées au compte de service Compute Engine par défaut. En attendant, toutes les commandes exécutées à partir de la VM seront exécutées avec 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 depuis une instance Compute Engine située dans la région project-2 avec le 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]. Cependant, la VM utilise le compte de service Compute Engine par défaut.

Pour exécuter correctement la même commande à partir de l'instance Compute Engine dans project-2,vérifiez les points suivants:

• La VM dispose du niveau d'accès nécessaire pour utiliser l'API BigQuery. Pour ce faire, sélectionnez Allow full access to all Cloud APIs (Autoriser l'accès complet à l'ensemble des API Cloud) comme niveau d'accès à la VM.
• Le compte de service associé à la VM a besoin des autorisations IAM pour:
  • Créer des jobs BigQuery dans project-2
  • Récupérer 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 permettre l'obtention de données depuis la table BigQuery) et à la règle de sortie (pour autoriser la création de jobs BigQuery).

À partir d'une instance Compute Engine située dans la région project-2, sur le réseau VPC default, exécutez la commande bq query 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 n'aboutira que si:

• s'exécuter sur une VM à l'aide du réseau VPC par défaut dans la région project-2 ;
• situé dans la région us-central1 spécifiée (sous-réseau IP) ; et
• 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 la commande BigQuery échouera si elle est exécutée depuis n'importe quel autre emplacement, y compris:

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

Ce schéma illustre un accès initié par le même compte principal, [e-mail], à partir de 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 continues 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 qu'il n'y ait pas de frais distincts pour l'utilisation de VPC Service Controls lorsque le service n'est pas utilisé, il est recommandé de nettoyer la configuration utilisée dans ce laboratoire. Vous pouvez également supprimer l'instance de VM et les ensembles de données BigQuery, ou les projets Google Cloud, pour éviter que des frais ne vous soient facturés. 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 située à gauche du nom de l'instance de VM, 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 du champ d'application de la règle d'accès, au niveau du dossier dans le cas présent.
  • Sur la page VPC Service Controls, cliquez sur Supprimer dans la ligne du tableau correspondant au périmètre que vous souhaitez 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 IAM et Paramètres d'administration du projet que vous souhaitez supprimer.
  • Dans l'IAM et Paramètres de l'administrateur, 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 résolu les problèmes.

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 que le projet est 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 récupérer des données.

Licence

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