Controles del servicio de VPC: Codelab I de protección de BigQuery

1. Introducción

En este codelab, aprenderás a proteger la API de BigQuery con los Controles del servicio de VPC. El codelab comienza sin un servicio de API protegido por el perímetro de servicio, lo que permite que las consultas se ejecuten en conjuntos de datos públicos y que los resultados se guarden en una tabla de proyecto. La consulta se ejecuta en un proyecto y la tabla (en la que se guardan los resultados) se crea en otro proyecto, lo que imita una configuración en la que los datos se pueden almacenar en un proyecto, pero se debe acceder a ellos desde uno diferente.

A continuación, presentaremos un perímetro de servicio para proteger el proyecto de datos. Aprenderás a corregir los incumplimientos observados con las reglas de entrada y salida y, más adelante, a agregar un nivel de acceso para restringir el acceso con direcciones IP internas. Los objetivos de este codelab son los siguientes:

• Comprende cómo corregir las infracciones de entrada y salida con las reglas de entrada y salida, respectivamente.
• Comprende por qué se produjo un incumplimiento específico.
• Analiza el alcance de la corrección de incumplimiento aplicada.
• Modifica la corrección (regla de entrada / salida) para cambiar su permiso. Para ello, aprovecha la opción de permitir el tráfico desde direcciones IP internas en una red de VPC con niveles de acceso.

2. Configuración y requisitos de los recursos

Antes de comenzar

En este codelab, suponemos que ya sabes lo siguiente:

• Conceptos básicos para ejecutar una consulta en BigQuery: Puedes revisar este codelab para aprender a consultar un conjunto de datos de Wikipedia en BigQuery.
• Cómo crear y administrar una carpeta
• Cómo crear un proyecto en una carpeta o mover un proyecto existente en una carpeta
• Cómo crear una política de acceso con alcance
• Cómo crear y configurar un perímetro de servicio
• Cómo encontrar los incumplimientos de la política de seguridad en los registros

Configuración

Nuestra configuración inicial está diseñada de la siguiente manera:

Si completaste el instructivo básico de los Controles del servicio de VPC, puedes volver a usar los mismos proyectos, carpetas y perímetro de servicio.

• Una organización de Google Cloud
• Una carpeta dentro de la organización En este codelab, la llamaremos codelab-folder.
• Dos proyectos de Google Cloud ubicados en la misma carpeta, codelab-folder. En este codelab, los llamamos project-1 y project-2
  • Si aún no tienes la carpeta y los proyectos creados, en la consola de Google Cloud, crea una carpeta en la organización y crea dos proyectos nuevos en ella.
• Los permisos necesarios:
  • Roles de IAM para administrar carpetas: Se asignan a nivel de carpeta.
  • Roles de IAM para administrar proyectos: Se asignan a nivel de proyecto.
  • Roles de IAM necesarios para configurar los Controles del servicio de VPC: asignados a nivel de la organización
  • Roles de IAM para administrar BigQuery: Se asignan a nivel de proyecto
  • Roles de IAM para administrar instancias de Compute Engine: Se asignan a nivel de proyecto.
• Cuenta de facturación para ambos proyectos, project-2 y project-1.

Para este propósito del codelab, puedes otorgarte los siguientes roles predefinidos: Administrador de carpetas y Creador del proyecto (a nivel de la carpeta), Propietario (a nivel del proyecto), Administrador de BigQuery (a nivel del proyecto) y Administrador de Access Context Manager (a nivel de la organización). y tendrás los roles necesarios para configurar los recursos necesarios para todo este codelab.

Crea un perímetro de servicio regular

En este codelab, usaremos un perímetro de servicio normal que protege project-1.

• Crea un perímetro normal, perimeter-1, y agrega el project-1.

En el perímetro, aún no restrinjas ningún servicio. Lo haremos más tarde.

Crea una VM de Compute Engine

En este codelab, usaremos 1 instancia de Compute Engine en project-2, ubicada en us-central1, y con la red de VPC predeterminada llamada default.

• Puedes consultar la documentación como guía para crear una instancia de Compute Engine a partir de una imagen pública.

En este codelab, usaremos la red de VPC predeterminada, llamada default. También puedes usar cualquier otra red, siempre que la red tenga al menos 1 subred.

Costo

Debes habilitar la facturación en la consola de Google Cloud para usar las APIs o los recursos de la nube. Te recomendamos cerrar los recursos usados para evitar incurrir en facturación más allá de este codelab. Los usuarios nuevos de Google Cloud son aptos para participar en el programa de prueba gratuita de $300.

Los recursos que generan costos son BigQuery y la instancia de Compute Engine. Puedes estimar el costo con la calculadora de precios de BigQuery y la calculadora de precios de Compute Engine.

3. Acceso a BigQuery sin restricciones de los Controles del servicio de VPC

Consulta el conjunto de datos públicos y guarda los resultados en project-1

1. Accede a project-2 y project-1 para verificar si puedes acceder a la API de BigQuery en la página de BigQuery Studio. Deberías poder hacerlo porque, incluso si project-1 está en un perímetro de servicio, este aún no protege ningún servicio.
2. En project-2, ejecuta la siguiente consulta para consultar un conjunto de datos públicos.

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

Después de ejecutar la consulta en el conjunto de datos públicos (mientras permanece en project-2), haz lo siguiente:

1. Haz clic en Guardar resultados y selecciona la tabla de BigQuery. (consulta la captura de pantalla a continuación).
2. Selecciona project-1 como el proyecto de destino.
3. Asígnale el nombre codelab_dataset al conjunto de datos. (Selecciona CREAR CONJUNTO DE DATOS NUEVO, a menos que uses un conjunto de datos existente).
4. Asígnale el nombre codelab-table a la tabla.
5. Haz clic en Guardar.

Los datos del conjunto de datos públicos se almacenaron correctamente en project-1 como resultado de la ejecución de la consulta desde project-2.

Se guardó el conjunto de datos de consulta en project-1 de project-2

Mientras te queda en project-2 BigQuery Studio, ejecuta la siguiente consulta para seleccionar los datos:

• Proyecto: project-1
• Conjunto de datos: codelab_dataset
• Tabla: codelab-table

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

La consulta debería ejecutarse correctamente, ya que ni project-2 ni project-1 están restringidos a usar BigQuery. Se permite el acceso a BigQuery desde y hacia cualquier lugar, siempre y cuando el usuario tenga los permisos de IAM adecuados.

En este diagrama, se ilustra el proceso en el que una principal consulta un conjunto de datos de BigQuery. Cada consulta de BigQuery inicia un trabajo de BigQuery, que luego realiza la operación real, en este caso, la recuperación de datos. El acceso a la principal se demuestra desde una instancia de Compute Engine y desde Internet, mientras se realiza consultas desde un conjunto de datos públicos y desde un proyecto independiente de Google Cloud. El proceso para consultar los datos (GetData) se realiza correctamente, sin que los Controles del servicio de VPC los bloqueen.

4. Proteger la API de BigQuery en un proyecto de conjunto de datos de origen

Modifica la configuración del perímetro perimeter-1 y restringe el servicio de la API de BigQuery junto con el recurso protegido project-1.

Verifica la aplicación del Perímetro de Servicio

En project-2, ejecuta la siguiente consulta en BigQuery Studio, como en el paso anterior:

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

Se producirá un incumplimiento de RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER de los Controles del servicio de VPC

El registro de auditoría de incumplimientos se ubicará en project-1, ya que allí es donde ocurrió el incumplimiento para cruzar el perímetro. Los registros se pueden filtrar con el vpcServiceControlsUniqueId observado (reemplaza VPC_SC_DENIAL_UNIQUE_ID por el ID único observado).

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

El incumplimiento es un egressViolations con lo siguiente:

• principalEmail: [cuenta de usuario que ejecuta la consulta]
• callerIp: [La dirección IP del usuario-agente que ejecuta la consulta]

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

5. Soluciona el incumplimiento para crear un trabajo de BigQuery

El incumplimiento de los Controles del servicio de VPC tiene bigquery.jobs.create como permiso de destino debido a cómo funciona BigQuery. Cuando usas la consola de Google Cloud (o la herramienta de línea de comandos de bq) para administrar los datos de BigQuery, BigQuery crea trabajos que luego se usan para completar las acciones deseadas. Mientras tanto, el primer evento es crear un trabajo de BigQuery.

En este diagrama, se muestra cuándo una principal ejecuta una consulta desde project-2 para un conjunto de datos en project-1. La operación para crear un trabajo de BigQuery desde el proyecto de conjunto de datos (project-1) en el proyecto desde el que se ejecuta la consulta (project-2) falla con una infracción de salida de los Controles del servicio de VPC debido a que el perímetro de servicio perimeter-1 protege la API de BigQuery. Con el perímetro implementado, no se puede iniciar ninguna solicitud a la API de BigQuery desde project-1 hacia el exterior del perímetro ni hacia el proyecto protegido. a menos que lo permitan los parámetros de configuración del perímetro de servicio.

Para corregir un incumplimiento de salida, debes crear una regla de salida que se base en los siguientes aspectos:

• source (FROM): es decir, la dirección de correo electrónico y el contexto del usuario (p.ej., la dirección IP del emisor, el estado del dispositivo, la ubicación, etcétera)
• destino (TO): es decir, el recurso, servicio y método o permiso objetivo.

Para corregir el incumplimiento de salida observado, crea una regla de salida que permita el tráfico hacia targetResource (project-2) desde la cuenta de usuario que ejecuta la consulta ([e-mail]) en el servicio de BigQuery y el método o permiso bigquery.jobs.create.

Comportamiento esperado de la regla de salida configurada:

• DESDE | Identidades: Solo se debe permitir que la identidad especificada [e-mail] cruce el límite del perímetro.
• HACIA | proyectos: la identidad especificada puede cruzar los límites del perímetro solo si el destino es el proyecto especificado project-2.
• HACIA | Servicios: la identidad especificada puede iniciar el tráfico fuera del perímetro, hacia el proyecto especificado, solo si la llamada a la API es para el servicio y el método especificados. De lo contrario, por ejemplo, si prueban un servicio diferente protegido por el perímetro de servicio, se bloqueará la operación porque no se permiten otros servicios.

Prueba la corrección: regla de salida

Una vez implementada la regla de salida, ejecuta la misma consulta.

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

Se producirá otro incumplimiento, esta vez un incumplimiento de entrada de NO_MATCHING_ACCESS_LEVEL. El nuevo incumplimiento es diferente del primero en términos de proyecto y método objetivo.

Corregir un incumplimiento de los Controles del servicio de VPC no significa que no se producirán otros incumplimientos. Una llamada a la API nueva con un contexto diferente de los permitidos por la política ya configurada causará un incumplimiento diferente.

El nuevo incumplimiento es una infracción de entrada con

• principalEmail: [cuenta de usuario que ejecuta la consulta]
• callerIp: [La dirección IP del usuario-agente que ejecuta la consulta]

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

El incumplimiento del método bigquery.tables.getData se debe a una llamada a la API que inició el trabajo de BigQuery para obtener datos de la tabla de BigQuery.

Es importante comprender cómo funciona un determinado servicio de API para anticipar los incumplimientos previstos.

6. Cómo corregir un incumplimiento para obtener datos de tablas de BigQuery

Una regla de entrada corrige un incumplimiento, a la vez que proporciona un control detallado sobre quién puede cruzar el límite del perímetro de servicio junto con el contexto del acceso permitido, como el proyecto de origen o de destino y el método de API al que puede acceder.

Un incumplimiento de entrada se corrige con una regla de entrada configurada con lo siguiente:

• source (FROM): es decir, la dirección de correo electrónico y el contexto del usuario (p.ej., la dirección IP del emisor, el estado del dispositivo, la ubicación, etcétera)
• destino (TO): es decir, el recurso, servicio y método o permiso objetivo.

La regla de entrada permitirá el tráfico hacia project-1 por parte del usuario especificado en el servicio y método especificados.

Comportamiento esperado de la regla de entrada configurada:

• DESDE | Identidades: Solo se debe permitir que la identidad especificada [e-mail] cruce el límite del perímetro.
• HACIA | Proyectos: la identidad especificada puede cruzar los límites del perímetro solo si el destino es el proyecto especificado project-1.
• HACIA | Servicios: La identidad especificada puede iniciar tráfico dentro del perímetro solo si la llamada a la API es para la API de BigQuery y el método bigquery.tables.getData especificado.

En adelante, la ejecución de la misma consulta debería funcionar de forma adecuada sin incumplimientos de los Controles del servicio de VPC.

Restringimos correctamente la API de BigQuery en project-1 para que solo [e-mail] y [e-mail] puedan usarla.

En este diagrama, se ilustra cómo dos principales diferentes intentan consultar el mismo conjunto de datos. Los Controles del servicio de VPC deniegan el acceso de [e-mail] (líneas azules punteadas), ya que la configuración del perímetro de servicio no les permite ejecutar operaciones de BigQuery desde o hacia project-1. El acceso de [e-mail] (línea continua verde) se realiza correctamente, ya que los parámetros de configuración de los Controles del servicio de VPC permiten realizar operaciones desde y hacia project-1.

7. Restringir el tráfico que permite el perímetro de servicio en función de la dirección IP interna

La configuración actual permite que el usuario designado ejecute consultas en BigQuery en project-1 desde cualquier ubicación. en cualquier lugar de Internet, si se les otorga permiso de IAM para consultar los datos, y siempre que usen su cuenta. Desde el punto de vista de la seguridad, esto implica que, si se vulnera la cuenta, cualquier persona que obtenga acceso a esta podrá acceder a los datos de BigQuery sin ninguna restricción adicional.

Se pueden implementar más restricciones mediante el uso del nivel de acceso en las reglas de entrada y salida para especificar el contexto del usuario. Por ejemplo, puedes permitir el acceso según la IP de origen junto con una regla de entrada configurada previamente que autoriza el acceso mediante la identidad del emisor. El acceso por IP de origen es posible para ambos rangos de IP de CIDR públicos, siempre que el cliente de usuario tenga una IP pública asignada, o bien con una dirección IP interna si el cliente opera desde un proyecto de Google Cloud.

Crea un nivel de acceso con una condición de acceso de dirección IP interna

En la misma carpeta de política de acceso con alcance, abre la página de Access Context Manager para crear un nivel de acceso.

1. En la página de Access Context Manager, selecciona CREAR NIVEL DE ACCESO.
2. En el panel Nuevo nivel de acceso, haz lo siguiente:
   1. Proporciona un título: Puedes usar codelab-al.
   2. En la sección Condiciones, haz clic en Subredes de IP.
   3. Selecciona la pestaña IP privada y haz clic en SELECCIONAR REDES DE VPC.
   4. En el panel Agregar redes de VPC, puedes explorar y encontrar la red default o ingresar de forma manual el nombre completo de la red en formato //compute.googleapis.com/projects/project-2/global/networks/default.
   5. Haz clic en AGREGAR red de VPC.
   6. Haz clic en SELECCIONAR SUBNETS DE IP.
   7. Selecciona la región en la que se encuentra la instancia de VM. En este codelab, es us-central1.
   8. Haz clic en GUARDAR.

Creamos un nivel de acceso que todavía no se aplica de manera forzosa en ningún perímetro ni política de entrada/salida.

Agrega un nivel de acceso a la regla de entrada

Para garantizar que el usuario permitido por la regla de entrada también se verifique con el nivel de acceso, es necesario configurar el nivel de acceso en la regla de entrada. La regla de entrada que autoriza el acceso a los datos de consulta se encuentra en perimeter-1. Modifica la regla de entrada para definir el origen como el nivel de acceso codelab-al.

Prueba configuraciones nuevas

Luego de agregar el nivel de acceso a la regla de entrada, la misma consulta de BigQuery fallará, a menos que se ejecute desde el cliente en la red de VPC default para el proyecto project-2. Para verificar este comportamiento, ejecuta la consulta desde la consola de Google Cloud mientras el dispositivo de extremo esté conectado a Internet. La consulta finalizará sin éxito y se indicará un incumplimiento de entrada.

De forma predeterminada, se establecen estos ajustes:

• El permiso de acceso a una instancia de Compute Engine tiene como valor predeterminado el acceso predeterminado, que no permite el acceso a la API de BigQuery.
• Una instancia de Compute Engine tendrá vinculada la cuenta de servicio predeterminada de Compute Engine. Mientras tanto, todos los comandos que se ejecuten desde la VM se ejecutarán como esta cuenta de servicio, que debe tener el formato [e-mail].
  Se pueden cambiar tanto el permiso de acceso como la cuenta de servicio conectada a la VM.

La misma consulta se puede ejecutar desde la red de VPC default, ubicada en project-2. Del mismo modo, la ejecución de la misma consulta de BigQuery desde una instancia de Compute Engine ubicada en project-2 con la red de VPC default también fallará. Esto se debe a que la regla de entrada todavía está configurada para permitir solo la principal [e-mail]. Sin embargo, la VM usa la cuenta de servicio predeterminada de Compute Engine.

Para ejecutar correctamente el mismo comando desde la instancia de Compute Engine en project-2,asegúrate de lo siguiente:

• La VM tiene permiso de acceso para usar la API de BigQuery. Para ello, selecciona Permitir el acceso total a todas las APIs de Cloud como permiso de acceso a la VM.
• La cuenta de servicio conectada a la VM necesita los permisos de IAM para lo siguiente:
  • Crear trabajos de BigQuery en project-2
  • Obtén datos de BigQuery desde la tabla de BigQuery ubicada en project-1
• La regla de entrada y salida debe permitir la cuenta de servicio predeterminada de Compute Engine.

Ahora debemos agregar la cuenta de servicio predeterminada de Compute Engine a las reglas de entrada (para permitir la obtención de datos de la tabla de BigQuery) y a la regla de salida (para permitir la creación de trabajos de BigQuery).

Desde una instancia de Compute Engine en project-2 en la red de VPC default, ejecuta el siguiente comando bq query:

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

Con la configuración actual, el comando de BigQuery tendrá éxito solo en los siguientes casos:

• Ejecutarse en una VM mediante la red de VPC predeterminada en project-2
• ubicado en la región us-central1 especificada (subred de IP)
• se ejecutará con la cuenta de servicio predeterminada de Compute Engine configurada en el perímetro de servicio.

La consulta del comando de BigQuery fallará si se ejecuta desde cualquier otro lugar, incluidos los siguientes:

• si se ejecuta en una VM con la red de VPC predeterminada en project-2, pero se encuentra en una región diferente a la subred agregada en el nivel de acceso, o
• si lo ejecuta el usuario [e-mail] con un cliente de usuario en Internet.

En este diagrama, se muestra el acceso que inició la misma principal, [e-mail], desde dos ubicaciones diferentes: Internet y una instancia de Compute Engine. Los Controles del servicio de VPC bloquean el acceso a BigQuery directamente desde Internet (líneas de puntos azules), mientras que se permite el acceso desde una VM (líneas continuas de color verde), mientras se hace pasar por la cuenta de servicio predeterminada de Compute Engine. El acceso permitido se debe a que el perímetro de servicio se está configurando para permitir el acceso a los recursos protegidos desde una dirección IP interna.

8. Limpieza

Si bien no se aplican cargos adicionales por usar los Controles del servicio de VPC cuando el servicio no se usa, se recomienda limpiar la configuración utilizada en este laboratorio. También puedes borrar la instancia de VM y los conjuntos de datos de BigQuery o los proyectos de Google Cloud para evitar que se generen cargos. Si borras el proyecto de Cloud, se dejan de facturar todos los recursos que usaste en ese proyecto.

• Para borrar la instancia de VM, completa los siguientes pasos:
  • En la consola de Google Cloud, ve a la página Instancias de VM.
  • Selecciona la casilla de verificación a la izquierda del nombre de la instancia de VM, haz clic en Borrar y, luego, vuelve a hacer clic en Borrar para confirmar.
• Para borrar el perímetro de servicio, completa los siguientes pasos:
  • En la consola de Google Cloud, selecciona Seguridad y, luego, Controles del servicio de VPC en el nivel en el que la política de acceso tiene permiso, en este caso, a nivel de la carpeta.
  • En la página Controles del servicio de VPC, en la fila de la tabla correspondiente al perímetro que quieres borrar, haz clic en Borrar.
• Para borrar el nivel de acceso, completa los siguientes pasos:
  • En la consola de Google Cloud, abre la página Access Context Manager en el permiso de la carpeta.
  • En la cuadrícula, identifica la fila del nivel de acceso que deseas borrar, selecciona el menú de tres puntos y, luego, Borrar.
• Para cerrar los proyectos, completa los siguientes pasos:
  • En la consola de Google Cloud, ve a IAM y Página Configuración del administrador del proyecto que quieres borrar.
  • En la página de IAM, Configuración del administrador, selecciona Apagar.
  • Ingresa el ID del proyecto y selecciona Cerrar de todas formas.

9. ¡Felicitaciones!

En este codelab, creaste un perímetro de Controles del servicio de VPC, lo aplicaste y solucionaste problemas.

Más información

También puedes explorar las siguientes situaciones:

• Ejecuta la misma consulta en el conjunto de datos públicos después de que los Controles del servicio de VPC protejan el proyecto.
• Agrega project-2 en el mismo perímetro que project-1.
• Agrega project-2 en su propio perímetro y mantén project-1 en el perímetro actual.
• Ejecuta consultas para actualizar los datos de la tabla, no solo para recuperar datos.

Licencia

Este trabajo cuenta con una licencia Atribución 2.0 Genérica de Creative Commons.