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 ningún servicio de API protegido por el perímetro de servicio, lo que permite ejecutar consultas en conjuntos de datos públicos y guardar los resultados en una tabla del 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 simula una configuración en la que los datos se pueden almacenar en un proyecto, pero se debe acceder a ellos con otro proyecto.

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

• Comprende cómo corregir los incumplimientos de entrada y salida con las reglas de entrada y salida, respectivamente.
• Comprender por qué se produjo un incumplimiento específico
• Analiza el alcance de la corrección del incumplimiento aplicada.
• Modifica la corrección (regla de entrada o salida) para cambiar su alcance aprovechando la opción para 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:

• Los conceptos básicos para ejecutar una consulta de BigQuery: Puedes consultar este codelab para aprender a consultar el 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 a 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 incumplimientos de políticas de seguridad en los registros

Configuración

Nuestra configuración inicial se diseñó de la siguiente manera:

Si completaste el Tutorial básico de Controles del servicio de VPC, puedes volver a usar los mismos proyectos, la misma carpeta y el mismo perímetro de servicio.

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

Para los fines de este codelab, puedes otorgarte los siguientes roles predefinidos: Administrador de carpetas y Creador de proyectos (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). De esta manera, tendrás los roles necesarios para configurar los recursos que se necesitan para todo el codelab.

Crea un perímetro de servicio normal

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

• Crea un perímetro regular, 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 y cuando 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 Cloud. Te recomendamos que cierres los recursos que usaste para evitar que se te facture más allá de este codelab. Los usuarios nuevos de Google Cloud son aptos para participar en el programa de prueba gratuita de USD 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, el perímetro 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 (sin salir de project-2), haz lo siguiente:

1. Haz clic en Guardar los 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. Asigna el nombre codelab_dataset al conjunto de datos. (Selecciona CREAR CONJUNTO DE DATOS NUEVO, a menos que uses un conjunto de datos existente).
4. Asigna 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.

Conjunto de datos de la consulta guardado en project-1 desde project-2

Mientras permaneces en project-2 BigQuery Studio, ejecuta la siguiente consulta para seleccionar datos de:

• 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 tienen restricciones para usar BigQuery. Se permite el acceso a BigQuery desde cualquier lugar y hacia cualquier lugar, siempre y cuando el usuario tenga los permisos de IAM adecuados.

En este diagrama, se ilustra el proceso cuando 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, recuperar datos. El acceso de la principal se demuestra desde una instancia de Compute Engine y desde Internet, mientras se realizan consultas desde un conjunto de datos públicos y desde un proyecto de Google Cloud independiente. El proceso para consultar los datos (GetData) se realiza correctamente, sin que los Controles del servicio de VPC lo bloqueen.

4. Protege la API de BigQuery en el proyecto del 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

Desde 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 los Controles del servicio de VPC RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER

El registro de auditoría del incumplimiento se ubicará en project-1, ya que allí se produjo el incumplimiento que cruzó 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 búsqueda]
• callerIp: [La dirección IP del usuario-agente que ejecuta la búsqueda]

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

5. Cómo corregir 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 la forma en que 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 ilustra el momento en que una entidad 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 del conjunto de datos (project-1) en el proyecto desde el que se ejecuta la consulta (project-2), falla con un incumplimiento 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 establecido, no se puede iniciar ninguna solicitud a la API de BigQuery desde project-1 hacia fuera del perímetro ni desde fuera del perímetro hacia el proyecto protegido, a menos que lo permitan las configuraciones del perímetro de servicio.

Para corregir un incumplimiento de salida, crea una regla de salida basada en lo siguiente:

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

Para corregir el incumplimiento de salida observado, crea una regla de salida que permita el tráfico hacia el targetResource (project-2) por parte de 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:

• FROM | Identities: Solo se debe permitir que la identidad especificada [e-mail] cruce el límite del perímetro.
• TO | projects: La identidad especificada solo puede cruzar los límites del perímetro si el destino es el proyecto especificado project-2.
• TO | Servicios: La identidad especificada puede iniciar 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 intentan usar un servicio diferente protegido por el perímetro de servicio, la operación se bloqueará porque no se permiten otros servicios.

Prueba la corrección: regla de salida

Una vez que la regla de salida esté en su lugar, 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 ingreso de NO_MATCHING_ACCESS_LEVEL. El incumplimiento nuevo es diferente del primero en términos de proyecto objetivo y método.

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

La nueva infracción es una infracción de entrada con

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

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 intentar obtener datos de la tabla de BigQuery.

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

6. Cómo corregir el incumplimiento para obtener datos de la tabla de BigQuery

Una regla de entrada corrige un incumplimiento de entrada y, al mismo tiempo, 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 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:

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

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

Comportamiento esperado de la regla de entrada configurada:

• FROM | Identities: Solo se debe permitir que la identidad especificada [e-mail] cruce el límite del perímetro.
• TO | projects: La identidad especificada puede cruzar los límites del perímetro solo si el destino es el proyecto especificado project-1.
• TO | 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 especificado bigquery.tables.getData.

A partir de ahora, la ejecución de la consulta idéntica debería funcionar correctamente sin incumplimientos de los Controles del servicio de VPC.

Restringimos correctamente la API de BigQuery en project-1 para que solo la pueda usar [e-mail] y no [e-mail].

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 permite que ejecuten operaciones de BigQuery desde project-1 ni hacia él. El acceso de [e-mail] (línea continua verde) se realiza correctamente, ya que las configuraciones de los Controles del servicio de VPC le permiten realizar operaciones desde project-1 y hacia project-1.

7. Restringe el tráfico permitido por 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 le otorga permiso de IAM para consultar los datos y siempre que utilice su cuenta. Desde el punto de vista de la seguridad, esto implica que, si la cuenta se ve comprometida, cualquier persona que obtenga acceso a ella podrá acceder a los datos de BigQuery sin restricciones adicionales.

Se pueden implementar más restricciones utilizando el 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 autorice el acceso por identidad de la persona que llama. El acceso por IP de origen es factible para los rangos de CIDR de IP pública, siempre que el cliente del usuario tenga una IP pública asignada, o bien empleando una dirección IP interna si el cliente del usuario 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 la 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 CREATE ACCESS LEVEL.
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 buscar la red default o ingresar manualmente el nombre completo de la red en el formato //compute.googleapis.com/projects/project-2/global/networks/default.
   5. Haz clic en AGREGAR RED DE VPC.
   6. Haz clic en SELECCIONAR SUBREDES 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 aún no se aplica de forma obligatoria en ningún perímetro ni política de entrada o salida.

Agrega el nivel de acceso a la regla de entrada

Para aplicar 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 la fuente como el nivel de acceso codelab-al.

Prueba de configuraciones nuevas

Después de agregar el nivel de acceso en 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 mostrará una indicación de incumplimiento de ingreso.

De forma predeterminada, se establecen estos ajustes:

• Un permiso de acceso a la instancia de Compute Engine se establece de forma predeterminada en acceso predeterminado, que no permite el acceso a la API de BigQuery.
• Una instancia de Compute Engine tendrá adjunta 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 conectados 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 aún 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 un alcance de acceso para usar la API de BigQuery. Para ello, selecciona Permitir el acceso total a todas las APIs de Cloud como el permiso de acceso de la VM.
• La cuenta de servicio adjunta a la VM necesita los permisos de IAM para realizar las siguientes acciones:
  • Crea trabajos de BigQuery en project-2
  • Obtén datos de BigQuery de 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 en las reglas de entrada (para permitir la obtención de datos de la tabla de BigQuery) y en 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 de consulta de bq:

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 solo tendrá éxito si se cumplen las siguientes condiciones:

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

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

• Si se ejecuta en una VM que usa 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
• si el usuario [e-mail] lo ejecuta con un cliente de usuario en Internet.

En este diagrama, se ilustra el acceso iniciado por el mismo 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 punteadas azules), mientras que se permite el acceso desde una VM (líneas continuas verdes) cuando se suplanta la cuenta de servicio predeterminada de Compute Engine. El acceso permitido se debe a que el perímetro de servicio está configurado para permitir el acceso a recursos protegidos desde una dirección IP interna.

8. Limpieza

Si bien no se cobra por separado el uso de los Controles del servicio de VPC cuando el servicio no está en uso, se recomienda limpiar la configuración utilizada en este lab. 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 detendrá la facturación de todos los recursos que se usaron en él.

• 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 que se encuentra a la izquierda del nombre de la instancia de VM y, luego, selecciona Borrar y 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 se define el alcance de la política de acceso, en este caso, en el nivel de la carpeta.
  • En la página Controles del servicio de VPC, en la fila de la tabla correspondiente al perímetro que deseas 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 la página Configuración de IAM y administración del proyecto que deseas borrar.
  • En la página Configuración de IAM y administración, selecciona Cerrar.
  • Ingresa el ID del proyecto y selecciona Cerrar de todos modos.

9. ¡Felicitaciones!

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

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 el proyecto esté protegido por los Controles del servicio de VPC.
• Agrega project-2 en el mismo perímetro que project-1.
• Agrega project-2 en su propio perímetro y conserva project-1 en el perímetro actual.
• Ejecuta consultas para actualizar datos en la tabla, no solo para recuperarlos.

Licencia

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