Soluciona problemas de control de acceso

En este documento, se muestra cómo solucionar problemas de seguridad con los permisos de Identity and Access Management (IAM), el control de acceso a nivel de columna y las claves de encriptación administradas por el cliente (CMEK) en BigQuery. Los problemas de permisos de IAM suelen generar errores Access Denied como los siguientes:

  • Access Denied: Project PROJECT_ID: User does not have bigquery.jobs.create permission in project PROJECT_ID.
  • Access Denied: Project PROJECT_ID: User does not have bigquery.datasets.get permission on dataset DATASET.
  • User does not have permission to query table PROJECT_ID:DATASET.TABLE.
  • Access Denied: Table PROJECT_ID:DATASET.TABLE: User does not have permission to query table PROJECT_ID:DATASET.TABLE, or perhaps it does not exist.
  • Access Denied: User PRINCIPAL does not have permission to perform bigquery.tables.getData on resource 'projects/PROJECT_ID/datasets/DATASET/tables/TABLE'.

Antes de comenzar

  • Para solucionar problemas de acceso de una principal a un recurso de BigQuery, asegúrate de tener los permisos de IAM necesarios.

Recopila información sobre el problema

El primer paso para solucionar problemas de acceso a un recurso es determinar el permiso que falta, la principal de IAM a la que se le denegó el acceso y el recurso al que la principal intentaba acceder.

Obtén información del historial de errores o trabajos

Para obtener información sobre el principal, el recurso y los permisos, examina el resultado de la herramienta de línea de comandos de bq, la respuesta de la API o BigQuery en la consola de Cloud de Confiance .

Por ejemplo, si intentas ejecutar una consulta con permisos insuficientes, verás un error como el siguiente en la pestaña Información del trabajo en la sección Resultados de la consulta de la consola de Cloud de Confiance .

Un error de acceso denegado en la pestaña Información del trabajo de la sección Resultados de la consulta

Examina el error para determinar el principal, el recurso y los permisos.

En algunos casos, es posible que puedas solicitar los permisos faltantes directamente desde el mensaje de error. Para obtener más información, consulta Mensajes de error de permisos en la documentación de IAM.

Obtén información de los Registros de auditoría de Cloud

Si el mensaje de error es genérico, falta información o si la acción falló en un proceso en segundo plano, usa el Explorador de registros de los Registros de auditoría de Cloud para obtener información sobre el error.

  1. En la consola de Cloud de Confiance , accede a la página Explorador de registros.

    Ve al Explorador de registros

    Como alternativa, en el menú de navegación, elige Monitoring > Explorador de registros.

  2. En el Explorador de registros, en el ámbito de registros, elige Registros del proyecto.

  3. En la ventana de consulta, ingresa la siguiente consulta para obtener errores relacionados con los permisos de los registros de acceso a los datos de BigQuery:

    resource.type="bigquery_resource" AND
logName="projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fdata_access" AND
protoPayload.status.message:"Access Denied" OR
protoPayload.status.message:"Permission denied" OR
protoPayload.status.code=7

    Reemplaza PROJECT_ID con el ID del proyecto.

  4. En los resultados de la consulta, expande la entrada de registro que corresponda a la operación con errores.

  5. En la sección protoPayload, expande el array authorizationInfo y, luego, cada nodo del array authorizationInfo.

    El array authorizationInfo muestra cada verificación de permisos que se realizó durante la llamada a la API.

  6. Para ver la causa del error, busca la entrada granted: false. La entrada granted: false muestra la siguiente información:

    • permission: Es la cadena de permisos de IAM que se verificó. Por ejemplo, bigquery.tables.getData
    • resource: Es el nombre completamente calificado del recurso al que el principal intentó acceder. Por ejemplo, projects/myproject/datasets/mydataset/tables/mytable.
    • principalEmail (si está disponible): Se hace referencia en protoPayload.authenticationInfo, esta es la principal que intentó la acción.

    La sección authorizationInfo del protoPayload que muestra el permiso, el recurso y el principalEmail.

Usa el Analizador de políticas para las políticas de permisos

El Analizador de políticas para las políticas de permisos te permite descubrir qué principales de IAM tienen qué tipo de acceso a cuáles recursos de BigQuery en función de tus políticas de permisos de IAM.

Después de recopilar información sobre el error de permisos, puedes usar el Analizador de políticas para comprender por qué la principal no tiene el acceso necesario. Esta herramienta analiza todas las políticas pertinentes, las membresías en Grupos de Google y la herencia de recursos superiores, como un proyecto, una carpeta y tu organización.

Para usar el Analizador de políticas en las políticas de permisos, crea una consulta de análisis, especifica un permiso para el análisis y, luego, ejecuta la consulta.

  1. En la consola de Cloud de Confiance , ve a la página Analizador de políticas.

    Ir al Analizador de políticas

    Como alternativa, en el menú de navegación, elige IAM y administración > Analizador de políticas.

  2. Haz clic en Crear consulta personalizada.

  3. En la página Configura tu consulta, ingresa la información que recopilaste anteriormente:

    1. En la sección Selecciona el alcance, en el campo Selecciona el alcance de la consulta, verifica que aparezca tu proyecto actual o haz clic en Explorar para elegir otro recurso.

    2. En la sección Configura los parámetros de consulta, en Parámetro 1, elige Principal y, en el campo Principal, ingresa el correo electrónico del usuario, grupo o cuenta de servicio.

    3. Haz clic en Agregar parámetro.

    4. En Parámetro 2, elige Permiso y, en el campo Permiso, haz clic en Seleccionar, elige el permiso de BigQuery y, luego, haz clic en Agregar. Por ejemplo, selecciona bigquery.tables.getData.

    5. Haz clic en Agregar parámetro.

    6. En Parámetro 3, elige Recurso y, en el campo Recurso, ingresa el nombre del recurso completamente calificado. El nombre del recurso debe incluir el prefijo del servicio, como en los siguientes ejemplos:

      • Proyecto de BigQuery: //cloudresourcemanager.googleapis.com/projects/PROJECT_ID
      • Conjunto de datos de BigQuery: //bigquery.googleapis.com/projects/PROJECT_ID/datasets/DATASET
      • Tabla de BigQuery: //bigquery.googleapis.com/projects/PROJECT/datasets/DATASET/tables/TABLE

  4. En el panel Consulta personalizada, haz clic en Analizar > Ejecutar consulta.

  5. Examina los resultados de la consulta. El resultado puede ser uno de los siguientes:

    • Una lista vacía. Si no hay resultados, se confirma que la principal no tiene el permiso requerido. Deberás otorgarle un rol a la principal que proporcione los permisos correctos.
    • Uno o más resultados. Si el analizador encuentra una política de permisos, existe alguna forma de acceso. Haz clic en Ver vinculación en cada resultado para ver los roles que proporcionan acceso al recurso del que es miembro la principal. La vinculación de la política muestra si el acceso se otorga a través de la pertenencia al grupo o la herencia, o si una condición de IAM o una política de denegación de IAM rechazan el acceso.

Encontrar el rol de IAM correcto que otorga los permisos necesarios

Después de confirmar que la principal no tiene acceso suficiente, el siguiente paso es encontrar el rol de IAM predefinido o personalizado adecuado que otorgue los permisos necesarios. El rol que elijas debe cumplir con el principio de privilegio mínimo.

Si tu organización usa roles personalizados, puedes encontrar el rol correcto enumerando todos los roles personalizados creados en tu proyecto u organización. Por ejemplo, en la consola de Cloud de Confiance , en la página Roles, puedes filtrar la lista por Tipo:Personalizado para ver solo los roles personalizados.

Para encontrar el rol de IAM predefinido correcto, sigue estos pasos.

  1. Abre la sección de permisos de BigQuery de la página de roles y permisos de IAM de BigQuery.

  2. En la barra de búsqueda Ingresa un permiso, ingresa el permiso que recuperaste del mensaje de error, el historial de trabajos o los registros de auditoría. Por ejemplo, bigquery.tables.getData.

    En los resultados de la búsqueda, se muestran todos los roles predefinidos de BigQuery que otorgan el permiso.

  3. Aplica el principio de privilegio mínimo: en la lista de roles, elige el rol menos permisivo que otorgue los permisos necesarios. Por ejemplo, si buscaste bigquery.tables.getData para otorgar la capacidad de consultar datos de tablas, Visualizador de datos de BigQuery es el rol menos permisivo que otorga ese permiso.

  4. Otorga a la principal el rol adecuado. Para obtener información sobre cómo otorgar un rol de IAM a un recurso de BigQuery, consulta Controla el acceso a los recursos con IAM.

No se aceptaron las Condiciones del Servicio de BigQuery

Cadena del error: BigQuery Terms of Service have not been accepted

Este error de HTTP 403 Forbidden (reason: termsOfServiceNotAccepted) se produce cuando no se aceptaron las Condiciones del Servicio de BigQuery. El error no se debe a la falta de permisos de IAM. Se puede devolver para solicitudes como crear un conjunto de datos o cargar datos.

Para solucionar este problema, haz lo siguiente:

  1. En la consola de Cloud de Confiance , ve a la página BigQuery.

    Ir a BigQuery

  2. Si aparece la página de bienvenida, selecciona tu país, selecciona la casilla de verificación Condiciones del Servicio y, luego, haz clic en Aceptar y continuar. Para obtener más información, consulta Habilita la zona de pruebas de BigQuery.

Después de aceptar las Condiciones del Servicio, vuelve a intentar la solicitud.

Soluciona problemas de errores por incumplimiento de política

Cuando recibes un error de HTTP 403 PERMISSION_DENIED en BigQuery con el motivo de error policyViolation, indica una falla impulsada por políticas de la organización, perímetros de datos o Controles del servicio de VPC.

En las siguientes secciones, se describen los mensajes de error más comunes asociados con este motivo de error, qué los causa y cómo resolverlos.

La política de la organización prohíbe la solicitud

Cadena del error: VPC Service Controls: Request is prohibited by organization's policy. vpcServiceControlsUniqueIdentifier: VPC_SERVICE_CONTROLS_UNIQUE_IDENTIFIER

Diagnóstico

Tu solicitud se originó en una dirección de red o un cliente que está fuera del perímetro designado de los Controles del servicio de VPC, o bien la solicitud infringió las reglas de entrada y salida definidas para tu espacio de trabajo. Esto suele ocurrir cuando tu consulta abarca varios proyectos. Por ejemplo, el proyecto de facturación de la consulta está fuera del perímetro seguro del proyecto de datos.

Solución

  1. Busca el ID único. Recupera el vpcServiceControlsUniqueIdentifier incluido en el mensaje de error. Usa este ID para filtrar tu Explorador de registros de Cloud de Confiance by S3NS y encontrar el registro de los Controles del servicio de VPC correspondiente con los detalles del motivo:

    protoPayload.metadata.@type="type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"
protoPayload.metadata.vpcServiceControlsUniqueId="VPC_SERVICE_CONTROLS_UNIQUE_IDENTIFIER"

    Busca el valor violationReason en protoPayload.metadata.violationReason. Una vez identificados, estudia los detalles adicionales en la entrada de registro y sigue la guía de solución de problemas de los Controles del servicio de VPC existente. Además, considera usar el analizador de incumplimientos.

  2. Corrige la facturación entre proyectos. Para las consultas entre proyectos, asegúrate de que el proyecto de facturación que ejecuta la consulta resida en el mismo perímetro que los datos consultados dentro del perímetro. Si es necesario, especifica un proyecto de facturación que cumpla con los requisitos de forma manual con el selector de proyectos de la consola de Cloud de Confiance , la marca --project_id en la herramienta de línea de comandos de bq o tu solicitud de API o biblioteca cliente.

  3. Verifica los niveles de acceso. Asegúrate de que tu red de cliente, IP o cuenta de usuario estén permitidas con Access Context Manager. La consola deCloud de Confiance requiere reglas de entrada configuradas específicamente para permitir el acceso de los usuarios a los entornos protegidos.

La exportación a Google Drive está bloqueada para los proyectos que tienen habilitados los Controles del servicio de VPC

Cadena del error: Export to Google Drive is blocked for projects with VPC-SC enabled

Diagnóstico

Google Drive no admite los Controles del servicio de VPC. Debido a que Google Drive no puede aplicar el perímetro de seguridad, BigQuery inhabilita automáticamente la exportación de extractos de la API a Google Drive para cualquier solicitud que se origine dentro de un límite de los Controles del servicio de VPC para evitar el robo de datos.

Solución

En lugar de exportar directamente a Google Drive, extrae los resultados de tu consulta a un bucket de Cloud Storage ubicado dentro del mismo perímetro de los Controles del servicio de VPC o guarda los resultados como un archivo local.

Las tablas externas de Google Drive están bloqueadas para los proyectos que tienen habilitados los Controles del servicio de VPC

Cadena del error: Google Drive external tables are blocked for projects with VPC-SC enabled

Diagnóstico

De forma predeterminada, los Controles del servicio de VPC no bloquean las consultas de tablas externas de Google Drive (como las Hojas conectadas). Sin embargo, este error aparece porque tu organización de Cloud de Confiance by S3NS solicitó de forma explícita que Cloud de Confiance by S3NS aplique una configuración de bloqueo estricta para tu proyecto que anule el comportamiento permisivo predeterminado, lo que impide cualquier consulta entrante a los datos de Google Drive desde un perímetro de Controles del servicio de VPC.

Solución

Importa los datos del archivo de Hojas de cálculo de Google o Google Drive directamente a una tabla estándar de BigQuery dentro del perímetro de los Controles del servicio de VPC, en lugar de consultarlos de forma dinámica como una tabla federada externa. Como alternativa, comunícate con tu administrador de Cloud interno para analizar los límites de exportación de datos de tu organización.

La exportación a Google Drive está bloqueada para tu proyecto

Cadena del error: Export to Google Drive is blocked for your project.

Diagnóstico

Incluso sin un perímetro de Controles del servicio de VPC, tus administradores de Cloud de Confiance by S3NS solicitaron que se aplique una configuración organizacional estricta y específica a tu proyecto que rechace todas las capacidades de extracción de datos a Google Drive.

Solución

Elige un destino de extracción alternativo, como un bucket de Cloud Storage o un archivo local, o comunícate con tu administrador de Cloud interno para analizar los límites de exportación de datos de tu organización.

La ubicación incumple la restricción de la política de la organización

Cadena del error: LOCATION violates constraint CONSTRAINT_NAME on the resource projects/PROJECT_ID o LOCATION violates constraint CONSTRAINT_NAME on the resource projects/PROJECT_ID/datasets/DATASET_ID

Diagnóstico

Tu administrador de Cloud configuró una restricción de la política de la organización para restringir exactamente dónde se pueden crear o analizar los recursos. Este error suele aparecer en los siguientes casos:

  • Crear un conjunto de datos en una región geográfica no autorizada (por ejemplo, restringida por constraints/gcp.resourceLocations).
  • Intentar usar BigQuery Omni en nubes externas cuando no está permitido (por ejemplo, bloqueado por constraints/bigquery.disableBQOmniAWS o constraints/bigquery.disableBQOmniAzure).

Solución

  1. Verifica el CONSTRAINT_NAME exacto que se proporciona en el mensaje de error para comprender qué acción se está bloqueando.
  2. Selecciona una región diferente y desbloqueada para tus datos, o trabaja con el administrador de la organización deCloud de Confiance by S3NS para revisar la política de la organización a nivel de la carpeta o de la organización. Consulta Estructura y define las ubicaciones de los recursos para obtener más detalles.

Soluciona problemas del control de acceso a nivel de columna

En las siguientes secciones, se explica cómo solucionar problemas con el control de acceso a nivel de columna y las etiquetas de política de Data Catalog.

No puedo ver los roles de Data Catalog

Si no puedes ver roles como Lector detallado de Data Catalog, es posible que no hayas habilitado la API de Data Catalog en tu proyecto. Para obtener información sobre cómo habilitar la API de Data Catalog, consulta Antes de comenzar. Los roles de Data Catalog aparecen varios minutos después de que habilitas la API de Data Catalog.

No puedo ver la página Taxonomías

Necesitas permisos adicionales para ver la página Taxonomías de etiquetas de política en la consola deCloud de Confiance . Por ejemplo, el rol de administrador de etiquetas de política de Data Catalog tiene acceso a la página Taxonomías.

Apliqué las etiquetas de política, pero no funcionan.

Si aún recibes resultados de consultas para una cuenta que no debería tener acceso, es posible que la cuenta reciba resultados almacenados en caché. Específicamente, si ejecutaste la consulta de forma correcta y, luego, aplicaste etiquetas de política, es posible que obtengas resultados de la caché de resultados de la consulta. De forma predeterminada, los resultados de las consultas se almacenan en caché durante 24 horas. La consulta falla de inmediato si inhabilitas la caché de resultados. Para obtener más detalles sobre el almacenamiento en caché, consulta Impacto del control de acceso a nivel de columna.

En general, las actualizaciones de IAM tardan unos 30 segundos en propagarse. Los cambios en la jerarquía de etiquetas de política pueden demorar hasta 30 minutos en propagarse.

No tengo permiso para leer desde una tabla con seguridad a nivel de columnas

Necesitas el rol de lector detallado o el rol de lector enmascarado en diferentes niveles, como la organización, la carpeta, el proyecto y la etiqueta de política. El rol de lector detallado otorga acceso a los datos sin procesar, mientras que el rol de lector enmascarado otorga acceso a los datos enmascarados. Puedes usar el Solucionador de problemas de políticas de IAM para verificar este permiso a nivel de proyecto.

Configuré el control de acceso detallado en la taxonomía de etiqueta de política, pero los usuarios ven datos protegidos

Para solucionar este problema, confirma los siguientes detalles:

  • En la página Taxonomías de etiquetas de política del Centro de seguridad de BigQuery, confirma que el botón de activación Aplicar control de acceso esté en la posición Activado.

  • Asegúrate de que tus consultas no usen resultados de consultas almacenados en caché. Si usas la herramienta de línea de comandos de bq para probar tus consultas, usa la marca --nouse_cache para inhabilitar la caché de consultas. Por ejemplo:

    bq query --nouse_cache --use_legacy_sql=false "SELECT * EXCEPT (customer_pii) FROM my_table;"

Consideraciones sobre la migración de proyectos

Las etiquetas de política y las taxonomías se alojan en una organización de Cloud de Confiance by S3NS específica y no se vuelven a asociar automáticamente cuando se migra un proyecto a una organización nueva. Si migras un proyecto que usa etiquetas de política para el control de acceso a nivel de columna a una organización diferente, se producen los siguientes problemas:

  • Las etiquetas de política ya no se pueden administrar en la consola de Cloud de Confiance dentro del proyecto migrado.
  • No puedes aplicar estas etiquetas de política a las columnas nuevas del proyecto migrado.
  • Es posible que los controles de acceso a nivel de columna existentes sigan vigentes, pero el vínculo a la taxonomía de origen en la organización original se rompe con fines de administración.

Para resolver este problema, se requiere la intervención manual del equipo de asistencia de Cloud de Confiance para volver a asociar la taxonomía con la organización nueva. Si migraste un proyecto con etiquetas de política y tienes estos problemas, comunícate con Atención al cliente de Cloud.

Soluciona problemas de claves de encriptación administradas por el cliente

En la siguiente lista, se describen los errores comunes y las soluciones recomendadas cuando usas claves de encriptación administradas por el cliente (CMEK) con Cloud Key Management Service:

Error: Please grant Cloud KMS CryptoKey Encrypter/Decrypter role
Resolución: La cuenta de servicio de BigQuery asociada con tu proyecto no tiene suficientes permisos de IAM para operar en la clave de Cloud KMS especificada. Para otorgar el permiso de IAM necesario, sigue las instrucciones del mensaje de error o las de Otorga permisos de encriptación y desencriptación.
Error: Existing table encryption settings don't match encryption settings specified in the request
Resolución: Este error puede ocurrir cuando la tabla de destino tiene una configuración de encriptación que no coincide con la configuración de encriptación en tu solicitud. Para resolver este problema, usa la disposición de escritura TRUNCATE para reemplazar la tabla o especifica una tabla de destino diferente.
Error: This region is not supported
Resolución: La región de la clave de Cloud KMS no coincide con la región del conjunto de datos de BigQuery para la tabla de destino. Para resolver este problema, selecciona una clave en una región que coincida con tu conjunto de datos o carga datos en un conjunto de datos que coincida con la región de la clave.
Error: Your administrator requires that you specify an encryption key for queries in project PROJECT_ID.
Resolución: Una política de la organización impidió crear un recurso o ejecutar una consulta. Para obtener más información sobre esta política, consulta Requerir CMEK para todos los recursos.
Error: Your administrator prevents using KMS keys from project KMS_PROJECT_ID to protect resources in project PROJECT_ID.
Resolución: Una política de la organización impidió crear un recurso o ejecutar una consulta. Para obtener más información sobre esta política, consulta Restringe las claves de Cloud KMS de un proyecto de BigQuery.

¿Qué sigue?