Protege un almacén de datos de BigQuery que almacena datos confidenciales

Muchas organizaciones implementan almacenes de datos que almacenan información confidencial para que puedan analizarlos con una variedad de fines comerciales. Este documento está dirigido a ingenieros de datos y administradores de seguridad que implementan y protegen almacenes de datos mediante BigQuery. Es parte de un plano de seguridad que consta de los siguientes elementos:

  • Un repositorio de GitHub que contiene un conjunto de parámetros de configuración y secuencias de comandos de Terraform. La configuración de Terraform establece un entorno en Google Cloud que admite un almacén de datos que almacena datos confidenciales.

  • Una guía sobre los controles de seguridad, arquitectura y diseño que usas para implementar este plano (este documento).

  • Una explicación que implementa un entorno de muestra.

En este documento, se analizan los siguientes temas:

  • La arquitectura y los servicios de Google Cloud que puedes usar para proteger un almacén de datos en un entorno de producción

  • Prácticas recomendadas para la administración de datos cuando se crea, implementa y opera un almacén de datos en Google Cloud, incluida la desidentificación de datos, el control diferencial de datos confidenciales, y controles de acceso a nivel de la columna.

En este documento, suponemos que ya configuraste un conjunto básico de controles de seguridad, como se describe en Bases de seguridad para Google Cloud. Te ayuda a disponer por capas controles adicionales a tus controles de seguridad existentes para proteger los datos confidenciales de un almacén de datos.

Descripción general

Los almacenes de datos como BigQuery permiten que las empresas analicen sus datos empresariales para obtener estadísticas. Los analistas acceden a los datos de la empresa que se almacenan en los almacenes de datos para crear estadísticas. Si tu almacén de datos incluye datos confidenciales, debes tomar medidas para preservar la seguridad, la confidencialidad, la integridad y la disponibilidad de los datos de la empresa mientras están almacenados, en tránsito o en análisis. En este plano, harás lo siguiente:

  • Configurar controles que ayuden a proteger el acceso a los datos confidenciales.
  • Configurar controles que ayuden a proteger la canalización de datos.
  • Configurar una separación adecuada de obligaciones para diferentes personas.
  • Configurar plantillas para buscar y desidentificar datos confidenciales.
  • Configurar controles y registros de seguridad adecuados para proteger los datos confidenciales.
  • Usar la clasificación de datos y las etiquetas de política para restringir el acceso a columnas específicas en el almacén de datos.

Arquitectura

Para crear un almacén de datos confidencial, debes clasificar los datos como confidenciales y no confidenciales y, luego, almacenarlos en perímetros separados. En la siguiente imagen, se muestra cómo se clasifican, desidentifican y almacenan los datos transferidos. También se muestra cómo puedes reidentificar datos confidenciales bajo demanda para su análisis.

Arquitectura del almacén de datos confidenciales

La arquitectura usa una combinación de los siguientes servicios y funciones de Google Cloud:

  • Identity and Access Management (IAM) y Resource Manager restringen el acceso y segmentan los recursos. Los controles de acceso y la jerarquía de recursos siguen el principio de privilegio mínimo.

  • Los Controles del servicio de VPC crean perímetros de seguridad que aíslan los servicios y los recursos mediante la configuración de la autorización, los controles de acceso y el intercambio de datos seguro. Los perímetros son los siguientes:

    • Un perímetro de transferencia de datos que acepta datos entrantes (en lotes o transmisión) y los desidentifica. Una zona de destino independiente que ayuda a proteger el resto de tus cargas de trabajo de los datos entrantes.

    • Un perímetro de datos confidencial que puede reidentificar los datos confidenciales y almacenarlos en un área restringida.

    • Un perímetro de administración que almacena las claves de encriptación y define lo que se considera datos confidenciales.

    Estos perímetros están diseñados para proteger el contenido entrante, aislar datos confidenciales mediante la configuración de controles y supervisión de acceso adicionales, y separar tu administración de los datos reales en el almacén. La administración incluye la administración de claves, la administración del catálogo de datos y el registro.

  • Cloud Storage y Pub/Sub reciben los datos siguientes:

    • Cloud Storage: recibe y almacena datos por lotes antes de la desidentificación. Cloud Storage usa TLS para encriptar datos en tránsito y encriptar datos en almacenamiento de forma predeterminada. La clave de encriptación es una clave de encriptación administrada por el cliente (CMEK). Puedes ayudar a proteger el acceso a los buckets de Cloud Storage mediante controles de seguridad como Identity and Access Management, las listas de control de acceso (LCA) y los documentos de políticas. Para obtener más información sobre los controles de acceso compatibles, consulta Descripción general del control de acceso.

    • Pub/Sub: Recibe y almacena datos de transmisión antes de la desidentificación. Pub/Sub usa la autenticación, los controles de acceso y la encriptación a nivel de mensaje con una CMEK para proteger tus datos.

  • Dos canalizaciones de Dataflow desidentifican y reidentifican datos confidenciales de la siguiente manera:

    • La primera canalización desidentifica los datos confidenciales mediante la seudonimización.
    • La segunda canalización reidentifica los datos confidenciales cuando los usuarios autorizados requieren acceso.

    A fin de proteger los datos, Dataflow usa una cuenta de servicio única y una clave de encriptación para cada canalización y controles de acceso. Para ayudar a proteger la ejecución de la canalización mediante su traslado al servicio de backend, Dataflow usa Streaming Engine. Para obtener más información, consulta Seguridad y permisos de Dataflow.

  • Cloud Data Loss Prevention (Cloud DLP) desidentifica datos confidenciales durante la transferencia.

    Cloud DLP desidentifica los datos estructurados y no estructurados según los Infotipos o registros que se detectan.

  • Cloud HSM aloja la clave de encriptación de claves (KEK). Cloud HSM es un servicio de Módulo de seguridad de hardware (HSM) basado en la nube.

  • Data Catalog clasifica de forma automática los datos confidenciales con metadatos, también conocidos como etiquetas de política, durante la transferencia. Data Catalog también usa metadatos para administrar el acceso a datos confidenciales. Para obtener más información, consulta Descripción general de Data Catalog. Para controlar el acceso a los datos dentro del almacén de datos, aplica etiquetas de política a las columnas que incluyen datos confidenciales.

  • BigQuery almacena los datos confidenciales en el perímetro de datos confidenciales.

    BigQuery usa varios controles de seguridad para proteger el contenido, incluidos los controles de acceso, la seguridad a nivel de columna para datos confidenciales y encriptación de datos.

  • Security Command Center supervisa y revisa los resultados de seguridad de todo tu entorno de Google Cloud en una ubicación central.

Estructura de la organización

Agrupa los recursos de tu organización para poder administrarlos y separar los entornos de prueba del entorno de producción. Resource Manager te permite agrupar recursos de forma lógica por proyecto, carpeta y organización.

En el siguiente diagrama, se muestra una jerarquía de recursos con carpetas que representan diferentes entornos, como arranque, común, producción, no producción (o etapa de pruebas) y desarrollo. Implementa la mayoría de los proyectos del plano en la carpeta de producción, y el proyecto de administración de datos en la carpeta común que se usa para la administración.

La jerarquía de recursos para un almacén de datos confidencial.

Carpetas

Usa carpetas para aislar tu entorno de producción y los servicios de administración de tus entornos de prueba y no producción. En la siguiente tabla, se describen las carpetas del plano de las bases de seguridad que usa este plano.

Carpeta Descripción
Prod. Contiene proyectos que tienen recursos en la nube y que se probaron y están listos para usar.
Uso Contiene servicios centralizados para la organización, como el proyecto de administración.

Puedes cambiar los nombres de estas carpetas para que se alineen con la estructura de carpetas de tu organización, pero te recomendamos que mantengas una estructura similar. Para obtener más información, consulta el plano de bases de seguridad de Google Cloud.

Proyectos

Puedes aislar partes de tu entorno mediante proyectos. En la siguiente tabla, se describen los proyectos que se necesitan dentro de la organización. Crea estos proyectos cuando ejecutes el código de Terraform. Puedes cambiar los nombres de estos proyectos, pero te recomendamos que mantengas una estructura de proyecto similar.

Proyecto Descripción
Transferencia de datos Contiene los servicios que se requieren para recibir datos y desidentificar datos confidenciales.
Administración Contiene servicios que proporcionan funciones de administración de claves, registro y catalogación de datos.
Datos no confidenciales Contiene los servicios que se requieren para almacenar datos que se desidentificaron.
Datos confidenciales Contiene los servicios que se requieren para almacenar y reidentificar datos confidenciales.

Además de estos proyectos, tu entorno también debe incluir un proyecto que aloje un trabajo de plantilla de Flex de Dataflow. El trabajo de plantilla de Flex es necesario para la canalización de transmisión de datos.

Asigna roles y grupos a proyectos

Debes otorgar a diferentes grupos de usuarios en tu organización acceso a los proyectos que conforman el almacén de datos confidencial. En las siguientes secciones, se describen las recomendaciones del plano para los grupos de usuarios y las asignaciones de roles en los proyectos que creas. Puedes personalizar los grupos para que se adapten a la estructura existente de tu organización, pero te recomendamos que mantengas una división de tareas y una asignación de roles similares.

Grupo de analistas de datos

Los analistas de datos analizan los datos en el almacén. Este grupo necesita roles en diferentes proyectos, como se describe en la siguiente tabla.

Asignación de proyectos Funciones
Transferencia de datos

Rol adicional para los analistas de datos que requieren acceso a datos confidenciales:

Datos confidenciales
  • roles/bigquery.dataViewer
  • roles/bigquery.jobUser
  • roles/bigquery.user
  • roles/dataflow.viewer
  • roles/dataflow.developer
  • roles/logging.viewer
Datos no confidenciales
  • roles/bigquery.dataViewer
  • roles/bigquery.jobUser
  • roles/bigquery.user
  • roles/logging.viewer

Grupo de ingenieros de datos

Los ingenieros de datos configuran y mantienen el almacén y la canalización de datos. Este grupo necesita roles en diferentes proyectos, como se describe en la siguiente tabla.

Asignación de proyectos Funciones
Transferencia de datos
Datos confidenciales
  • roles/bigquery.dataEditor
  • roles/bigquery.jobUser
  • roles/cloudbuild.builds.editor
  • roles/cloudkms.viewer
  • roles/compute.networkUser
  • roles/dataflow.admin
  • roles/logging.viewer
Datos no confidenciales
  • roles/bigquery.dataEditor
  • roles/bigquery.jobUser
  • roles/cloudkms.viewer
  • roles/logging.viewer

Grupo de administradores de redes

Los administradores de redes configuran la red. Por lo general, son miembros del equipo de redes.

Los administradores de red requieren los siguientes roles a nivel de la organización:

Grupo de administradores de seguridad

Los administradores de seguridad administran los controles de seguridad como el acceso, las claves, las reglas de firewall, Controles del servicio de VPC y Security Command Center.

Los administradores de seguridad requieren los siguientes roles a nivel de la organización:

Grupo de analistas de seguridad

Los analistas de seguridad supervisan y responden a los incidentes de seguridad y los resultados de Cloud DLP.

Los analistas de seguridad requieren los siguientes roles a nivel de la organización:

Información sobre los controles de seguridad que necesitas

En esta sección, se analizan los controles de seguridad dentro de Google Cloud que usas para proteger tu almacén de datos. Los principios clave de seguridad que debes considerar son los siguientes:

  • Protege el acceso mediante la adopción de principios de privilegios mínimos.

  • Protege las conexiones de red a través del diseño y las políticas de segmentación.

  • Protege la configuración de cada uno de los servicios

  • Clasifica y protege datos según su nivel de riesgo.

  • Comprende los requisitos de seguridad para el entorno que aloja el almacén de datos

  • Configura la supervisión y el registro suficientes para la detección, investigación y respuesta.

Controles de seguridad para la transferencia de datos

Para crear tu almacén de datos, debes transferir datos de otra fuente de Google Cloud (por ejemplo, un data lake). Puedes usar una de las siguientes opciones para transferir tus datos al almacén de datos en BigQuery:

  • Un trabajo por lotes que usa Cloud Storage.

  • Un trabajo de transmisión que use Pub/Sub. Para proteger los datos durante la transferencia, puedes usar reglas de firewall, políticas de acceso y encriptación.

Reglas de firewall y red

Las reglas de firewall de la nube privada virtual (VPC) controlan el flujo de datos en los perímetros. Puedes crear reglas de firewall que rechacen todas las salidas, excepto las conexiones específicas del puerto TCP 443 de los nombres de dominio especiales restricted.googleapis.com. El dominio restricted.googleapis.com tiene los siguientes beneficios:

  • Ayuda a reducir la superficie de ataque de la red usando el Acceso privado a Google cuando las cargas de trabajo se comunican con los servicios y las API de Google.
  • Garantiza que solo uses servicios que admitan los Controles del servicio de VPC.

Para obtener más información, consulta Configura el acceso privado a los servicios.

Debes configurar subredes independientes para cada trabajo de Dataflow. Las subredes separadas garantizan que los datos que se desidentifican se separen correctamente de los datos que se están reidentificando.

La canalización de datos requiere que abras puertos TCP en el firewall, como se define en el archivo dataflow_firewall.tf en el repositorio del módulo dwh-networking. Para obtener más información, consulta Configura el acceso a Internet y las reglas de firewall.

Para denegar a los recursos la capacidad de usar direcciones IP externas, la política de la organización compute.vmExternalIpAccess está configurada para rechazar todas.

Controles perimetrales

Como se muestra en el diagrama de arquitectura, debes colocar los recursos del almacén de datos confidencial en perímetros separados. Para permitir que los servicios en diferentes perímetros compartan datos, crea puentes perimetrales. Los puentes perimetrales permiten que los servicios protegidos realicen solicitudes de recursos fuera de su perímetro. Estos puentes realizan las siguientes conexiones:

  • Conectan el proyecto de transferencia de datos al proyecto de administración para que la desidentificación se pueda realizar durante la transferencia.

  • Conectan el proyecto de datos no confidenciales y el proyecto de datos confidenciales para que los datos confidenciales se puedan reidentificar cuando un analista de datos lo solicite.

  • Conectan el proyecto confidencial al proyecto de administración de datos para que se pueda reidentificar cuando un analista de datos lo solicite.

Además de los puentes perimetrales, debes usar reglas de salida para permitir que los recursos protegidos por los perímetros de servicio accedan a los recursos que están fuera del perímetro. En esta solución, configurarás reglas de salida para obtener los trabajos externos de la plantilla de Flex de Dataflow que se encuentran en Cloud Storage en un proyecto externo. Para obtener más información, consulta Accede a un recurso de Google Cloud fuera del perímetro.

Política de acceso

Para ayudar a garantizar que solo las identidades específicas (usuario o servicio) puedan acceder a los recursos y los datos, habilita los grupos y los roles de IAM.

A fin de garantizar que solo fuentes específicas puedan acceder a tus proyectos, habilita una política de acceso para tu organización de Google. Te recomendamos que crees una política de acceso que especifique el rango de direcciones IP permitido para las solicitudes y que solo permita solicitudes de cuentas de servicio o usuarios específicos. Para obtener más información, consulta Atributos de nivel de acceso.

Administración y encriptación de claves para la transferencia

Ambas opciones de transferencia usan Cloud HSM para administrar las CMEK. Usa las claves CMEK para proteger tus datos durante la transferencia. Cloud DLP protege aún más tus datos con la encriptación de datos confidenciales, mediante los detectores que configuras.

Para transferir datos, usa las siguientes claves de encriptación:

  • Una clave CMEK para el proceso de transferencia que también usa la canalización de Dataflow y el servicio de Pub/Sub. En ocasiones, el proceso de transferencia se conoce como proceso de extracción, transformación y carga (ETL).

  • La clave criptográfica unida por Cloud HSM para el proceso de desidentificación de datos con Cloud DLP.

  • Dos claves de CMEK, una para el almacén de BigQuery en el proyecto de datos no confidenciales y la otra para el almacén en el proyecto de datos confidenciales. Para obtener más información, consulta Administración de claves.

Debes especificar la ubicación de CMEK, que determina la ubicación geográfica en la que se almacena la clave y está disponible para acceder. Debes asegurarte de que tus CMEK estén en la misma ubicación que tus recursos. De forma predeterminada, las CMEK se rotan cada 30 días.

Si las obligaciones de cumplimiento de tu organización requieren que administres tus propias claves de forma externa desde Google Cloud, puedes habilitar Cloud External Key Manager. Si usas claves externas, eres responsable de las actividades de administración de claves, incluida la rotación de claves.

Cuentas de servicio y controles de acceso

Las cuentas de servicio son identidades que Google Cloud puede usar para ejecutar solicitudes a la API en tu nombre. Las cuentas de servicio garantizan que las identidades de usuario no tengan acceso directo a los servicios. A fin de permitir la separación de obligaciones, crea cuentas de servicio con diferentes roles para propósitos específicos. Estas cuentas de servicio se definen en el módulo data-ingestion y en el módulo confidential-data. Las cuentas de servicio son las siguientes:

  • Una cuenta de servicio del controlador de Dataflow para la canalización de Dataflow que desidentifica los datos confidenciales.

  • Una cuenta de servicio del controlador de Dataflow para la canalización de Dataflow que reidentifica datos confidenciales.

  • Una cuenta de servicio de Cloud Storage para transferir datos de un archivo por lotes.

  • Una cuenta de servicio de Pub/Sub para transferir datos de un servicio de transmisión.

  • Una cuenta de servicio de Cloud Scheduler para ejecutar el trabajo por lotes de Dataflow que crea la canalización de Dataflow.

En la siguiente tabla, se enumeran los roles que se asignan a cada cuenta de servicio:

Cuenta de servicio Nombre Proyecto Funciones

Controlador de Dataflow

Esta cuenta se usa para la desidentificación.

sa-dataflow-controller Transferencia de datos

Controlador de Dataflow

Esta cuenta se usa para la reidentificación.

sa-dataflow-controller-reid Datos confidenciales
Cloud Storage sa-storage-writer Transferencia de datos
  • roles/storage.objectViewer
  • roles/storage.objectCreator
Si deseas obtener descripciones de estas funciones, consulta Funciones de IAM para Cloud Storage.
Pub/Sub sa-pubsub-writer Transferencia de datos
  • roles/pubsub.publisher
  • roles/pubsub.subscriber
Para obtener descripciones de estas funciones consulta Funciones de IAM para Pub/Sub.
Cloud Scheduler sa-scheduler-controller Transferencia de datos
  • roles/compute.viewer
  • roles/dataflow.developer

Desidentificación de datos

Usa Cloud DLP para desidentificar los datos estructurados y no estructurados durante la fase de transferencia. En el caso de los datos estructurados, debes usar transformaciones de registro basadas en campos para desidentificar datos. Para ver un ejemplo de este enfoque, consulta la carpeta /examples/de_identification_template/. En este ejemplo, se verifican los datos estructurados para cualquier número de tarjeta de crédito y PIN de tarjeta. En el caso de los datos no estructurados, debes usar tipos de información para desidentificar datos.

Si deseas desidentificar datos etiquetados como confidenciales, usa Cloud DLP y una canalización de Dataflow para asignarles tokens. Esta canalización toma datos de Cloud Storage, los procesa y, luego, los envía al almacén de datos de BigQuery.

Para obtener más información sobre el proceso de desidentificación de datos, consulta Administración de datos.

Controles de seguridad para el almacenamiento de datos

Configura los siguientes controles de seguridad para ayudar a proteger los datos en el almacén de BigQuery:

  • Controles de acceso a nivel de columna

  • Cuentas de servicio con roles limitados

  • Políticas de organización

  • Perímetros de los Controles del servicio de VPC entre el proyecto confidencial y el que no es confidencial, con puentes perimetrales adecuados

  • Encriptación y administración de claves

Controles de acceso a nivel de columna

A fin de proteger los datos confidenciales, usa controles de acceso para columnas específicas en el almacén de BigQuery. Para acceder a los datos de estas columnas, un analista de datos debe tener el rol Lector detallado.

Para definir el acceso a las columnas en BigQuery, crea etiquetas de política. Por ejemplo, el archivo taxonomy.tf en el módulo de ejemplo bigquery-confidential-data crea las siguientes etiquetas:

  • Una etiqueta de política 3_Confidential para columnas que incluyen información muy sensible, como números de tarjetas de crédito. Los usuarios que tienen acceso a esta etiqueta también tienen acceso a las columnas que están etiquetadas con las etiquetas de política 2_Private o 1_Sensitive.

  • Una etiqueta de política 2_Private para columnas que incluyen información de identificación personal (PII) sensible, como el nombre de una persona. Los usuarios que tienen acceso a esta etiqueta también tienen acceso a las columnas que están etiquetadas con la etiqueta de política 1_Sensitive. Los usuarios no tienen acceso a las columnas que están etiquetadas con la etiqueta de política 3_Confidential.

  • Una etiqueta de política 1_Sensitive para columnas que incluyen datos que no se pueden hacer públicos, como el límite de crédito. Los usuarios que tienen acceso a esta etiqueta no tienen acceso a las columnas que están etiquetadas con las etiquetas de política 2_Private o 3_Confidential.

Todo lo que no esté etiquetado está disponible para todos los usuarios que tengan acceso al almacén de datos.

Estos controles de acceso garantizan que, incluso después de que los datos se reidentifiquen, los datos aún no se puedan leer hasta que se otorgue al usuario acceso de forma explícita.

Cuentas de servicio con roles limitados

Debes limitar el acceso al proyecto de datos confidenciales para que solo los usuarios autorizados puedan ver los datos confidenciales. Para hacerlo, crea una cuenta de servicio con el rol roles/iam.serviceAccountUser en cuyo nombre deben actuar los usuarios autorizados. Actuar en nombre de cuentas de servicio permite a los usuarios usar cuentas de servicio sin descargar las claves de las cuentas de servicio, lo que mejora la seguridad general de tu proyecto. Cuando se actúa en nombre de cuentas de servicio, se crea un token a corto plazo que pueden descargar los usuarios autorizados que tengan asignado el rol roles/iam.serviceAccountTokenCreator.

Políticas de organización

Este plano incluye las restricciones de la política de la organización que usa el plano de bases de seguridad y agrega restricciones adicionales. Para obtener más información sobre las restricciones que usa el plano de bases de seguridad, consulta “Configuración de política de la organización” en la guía de bases de seguridad.

En la siguiente tabla, se describen las restricciones adicionales de las políticas de la organización que se definen en el módulo org_policies:

Política Nombre de la restricción Valor recomendado
Restringe las implementaciones de recursos a ubicaciones físicas específicas. Para obtener valores adicionales, consulta Grupos de valores. gcp.resourceLocations
Uno de los siguientes:
in:us-locations
in:eu-locations
in:asia-locations
Inhabilita la creación de cuentas de servicio iam.disableServiceAccountCreation true
Habilita el Acceso al SO para las VM creadas en el proyecto. Para obtener más información, consulta Administra el Acceso al SO en una organización y Acceso al SO. compute.requireOsLogin true
Restringe las reglas de reenvío nuevas para que sean solo internas, según la dirección IP. compute.restrictProtocolForwardingCreationForTypes INTERNAL
Define el conjunto de subredes de VPC compartidas que los recursos de Compute Engine pueden usar. compute.restrictSharedVpcSubnetworks projects/PROJECT_ID/regions/REGION/s ubnetworks/SUBNETWORK-NAME.

Reemplaza SUBNETWORK-NAME por el ID de recurso de la subred privada que deseas que use el plano.
Inhabilita el registro de salida del puerto en serie en Cloud Logging. compute.disableSerialPortLogging true

Encriptación y administración de claves para el almacenamiento y la reidentificación

Administra claves de CMEK independientes para tus datos confidenciales de modo que puedas reidentificar los datos. Usa Cloud HSM para proteger tus claves. Para reidentificar los datos, usa las siguientes claves:

  • Una clave CMEK que la canalización de Dataflow usa para el proceso de reidentificación.

  • La clave criptográfica original que Cloud DLP usa para desidentificar tus datos.

  • Una clave CMEK para el almacén de BigQuery en el proyecto de datos confidenciales.

Como se mencionó antes en Administración y encriptación de claves para la transferencia, puedes especificar la ubicación de CMEK y los períodos de rotación. Puedes usar Cloud EKM si tu organización lo requiere.

Controles operativos

Puedes habilitar el registro y las funciones de nivel Premium de Security Command Center, como las estadísticas del estado de seguridad y la detección de amenazas. Estos controles te ayudan a hacer lo siguiente:

  • Supervisar quién accede a tus datos.

  • Asegurarse de que la auditoría sea la correcta.

  • Admitir la capacidad de los equipos de operaciones y administración de incidentes para responder a problemas que puedan ocurrir.

Transparencia de acceso

La Transparencia de acceso te proporciona notificaciones en tiempo real en caso de que el personal de Atención al cliente de Google requiera acceso a tus datos. Los registros de Transparencia de acceso se generan cada vez que un humano accede al contenido y solo el personal de Google que tiene justificaciones comerciales válidas (por ejemplo, un caso de ayuda) puede obtener acceso. Te recomendamos habilitar la Transparencia de acceso.

Logging

Para ayudarte a cumplir con los requisitos de auditoría y obtener estadísticas sobre tus proyectos, configura Google Cloud's operations suite con registros de datos para los servicios de los que deseas realizar un seguimiento. El módulo centralized-logging configura las siguientes prácticas recomendadas:

Para todos los servicios de los proyectos, los registros deben incluir información sobre operaciones de lectura y escritura de datos, e información sobre lo que leen los administradores. Para obtener prácticas recomendadas de registro adicionales, consulta la sección “Registro” de la guía de bases de seguridad.

Alertas y supervisión

Después de implementar el plano, puedes configurar alertas para notificar a tu centro de operaciones de seguridad (SOC) que puede estar ocurriendo un incidente de seguridad. Por ejemplo, puedes usar alertas para informar a tu analista de seguridad cuando cambie un permiso de IAM. Para obtener más información sobre cómo configurar alertas de Security Command Center, consulta Configura la búsqueda de notificaciones. Para las alertas adicionales que Security Command Center no publica, puedes configurar alertas con Cloud Monitoring.

Consideraciones de seguridad adicionales

Los controles de seguridad de este plano los revisó El equipo de Acción de seguridad cibernética de Google y un equipo de seguridad de terceros. Para solicitar acceso en virtud del NDA a un modelo de amenaza STRIDE y al informe de evaluación resumido, envía un correo electrónico a secured-dw-blueprint-support@google.com

Además de los controles de seguridad que se describen en esta solución, debes revisar y administrar la seguridad y el riesgo en áreas clave que se superponen e interactúan con el uso de esta solución. Se incluyen las siguientes:

  • El código que usas para configurar, implementar y ejecutar trabajos de Dataflow.

  • La taxonomía de clasificación de datos que usas con esta solución.

  • El contenido, la calidad y la seguridad de los conjuntos de datos que almacenas y analizas en el almacén de datos.

  • El entorno general en el que implementas la solución, que incluye lo siguiente:

    • El diseño, la segmentación y la seguridad de las redes que conectas a esta solución.
    • La seguridad y la administración de los controles de IAM de tu organización.
    • La configuración de autenticación y autorización de los actores a los que otorgas acceso a la infraestructura que forma parte de esta solución y que tienen acceso a los datos que se almacenan y administran en esa infraestructura.

Revisión general

Para implementar la arquitectura que se describe en este documento, haz lo siguiente:

  1. Determina si implementarás el plano con el plano de bases de seguridad básico o por tu cuenta. Si eliges no implementar el modelo del plano de bases de seguridad, asegúrate de que tu entorno tenga un modelo de referencia de seguridad similar implementado.

  2. Revisa el archivo readme del plano y asegúrate de cumplir con todos los requisitos.

  3. En tu entorno de pruebas, implementa la explicación para ver la solución en acción. Como parte de tu proceso de prueba, considera lo siguiente:

    1. Usa Security Command Center para analizar los proyectos recién creados según tus requisitos de cumplimiento.

    2. Agrega tus propios datos de muestra al almacén de BigQuery.

    3. Trabaja con un analista de datos en tu empresa para probar su acceso a los datos confidenciales y si puede interactuar con los datos desde BigQuery como esperarían.

  4. Implementa el plano en tu entorno de producción.

¿Qué sigue?