Prácticas recomendadas de seguridad para las estadísticas incorporadas

Con las estadísticas incorporadas de Looker, puedes permitir que tus usuarios y clientes exploren los datos incorporados en un iframe en cualquier página web, portal o aplicación en formato HTML. El iframe ejecuta toda la aplicación Looker y solicita solo los datos necesarios para mostrar tu consulta. De forma predeterminada, un iframe no tiene permiso para leer ni escribir datos de tu sitio web o aplicación externos.

A veces, la inserción de datos puede generar inquietudes sobre la privacidad o la seguridad. Para mitigar estas inquietudes, sugerimos que los administradores de Looker sigan estas prácticas recomendadas:

  • Si incorporas contenido de Looker a los clientes, configúralo en una instancia de Looker separada de la que usas para las estadísticas internas.
  • Conecta solo los datos a la instancia incorporada de Looker a la que deberían acceder los usuarios incorporados, que pueden ser el público.
  • Protege los tokens aleatorios dentro de las URLs de incorporación públicas como si fueran credenciales de usuario y, si no se usan, inhabilita las URLs públicas.
  • Un valor external_user_id asignado debe ser único para cada conjunto determinado de permisos, atributos de usuario y modelos. Asegúrate de no usar el mismo external_user_id en diferentes sesiones de incorporación para distintos usuarios interactivos, y de no usar el mismo external_user_id para un solo usuario que tenga permisos, valores de atributos de usuario o acceso al modelo diferentes.
  • Habilita un sistema cerrado.
  • Protege el secreto de incorporación firmada como si fueran credenciales de administrador de tu instancia de Looker incorporada y mantén inhabilitada la incorporación firmada si no la usas.
  • Usa una autenticación sólida para tus instancias incorporadas de Looker (incorporación firmada, SAML, OAuth de Google, 2FA).
  • Si usas la incorporación sin cookies, protege el token de referencia de la sesión para que solo se pueda acceder a él en el servidor host de la aplicación de incorporación. El token de referencia de sesión nunca debe exponerse en el navegador.
  • Si usas la incorporación sin cookies y configuras el dominio de incorporación permitido cuando adquieres la sesión sin cookies, nunca confíes en el origen del navegador del usuario de incorporación. Mantén siempre una asignación del usuario de incorporación al origen de confianza del usuario de incorporación en el servidor de aplicaciones de incorporación.

Looker ofrece diferentes tipos de métodos de incorporación, según el nivel de autenticación que se requiera para los usuarios que accedan a tus datos: públicos, privados e incorporaciones firmadas. Con cualquiera de estos métodos, puedes interactuar con el iframe mediante JavaScript.

Incorporación pública

Si habilitas la opción Acceso público de una vista,puedes incorporar una visualización o tabla de datos en un sitio web externo usando una etiqueta HTML iframe. También puedes compartir públicamente la URL de vista o importar datos en aplicaciones de hojas de cálculo de Google o Excel.

La URL y la URL incorporada de la etiqueta iframe contienen un token aleatorio y no se puede adivinar, pero cualquier persona que tenga la URL incorporada puede acceder a los datos y no se aplican filtros ni restricciones adicionales. Te recomendamos que consideres las implicaciones de seguridad de crear y compartir una URL pública para una vista determinada antes de habilitar las URLs públicas.

Las URLs públicas y las de incorporación pública no tienen vencimiento y no se pueden revocar. Cuando compartes una URL pública, compartes la consulta, no los datos.

Incorporación privada

Si no quieres permitir el acceso público a tu vista, también puedes incorporar una vista, una exploración o un panel, de forma privada en un iframe, de modo que se requiera un acceso a Looker para ver el contenido.

Los usuarios autenticados solo pueden acceder al contenido que determinen sus permisos de Looker asignados. Si cambias sus permisos en Looker, la URL incorporada no cambia, pero lo que puede ver el usuario cuando accede a ella puede cambiar.

Si el usuario no está autenticado, puedes mostrar un error o una pantalla de acceso en el iframe. Sin embargo, habilitar una pantalla de acceso en el iframe no es compatible con las protecciones del mismo origen de Looker.

Las URLs de incorporación privada nunca vencen y no se pueden revocar. Sin embargo, dado que el vínculo solo funciona para alguien que tiene acceso a tu instancia de Looker y esos datos, enviar un vínculo no debería causar problemas de seguridad.

Incorporación firmada

Comunícate con un especialista en ventas de Google Cloud para actualizar tu licencia de esta función.

La incorporación firmada lleva la incorporación privada un paso más allá. La incorporación firmada no requiere que los usuarios se autentiquen con una cuenta de usuario de Looker. En su lugar, se pueden autenticar a través de tu propia aplicación mediante la URL en un iframe. La autenticación crea una nueva sesión del navegador y emite una cookie al navegador.

Los permisos, identificadores y atributos del usuario se pasan como parámetros dentro de la URL, que se firma con una clave secreta. Cualquier persona con acceso a la clave secreta puede crear una URL para acceder a cualquier modelo al que esté conectada la instancia de Looker, como cualquier usuario, con cualquier permiso. Consulta nuestro código de ejemplo para aprender a generar URLs firmadas.

El captura de clic es un problema de seguridad del navegador que puede ocurrir cuando un código incorporado o una secuencia de comandos ejecutan una función sin el conocimiento o consentimiento del usuario, como un botón que parece realizar otra acción. El clickjacking suele requerir una URL estática. La URL generada para una incorporación firmada es secreta y solo debe tenerla el usuario que la ve. El uso de incorporaciones firmadas no aumenta el riesgo de clickjacking del sitio web externo.

Parámetros de incorporación firmados

Los parámetros incluidos en la URL del iframe son visibles para los usuarios incorporados, pero no se pueden editar. Estos pueden incluir:

  • user_attributes: Se usan para filtrar datos aún más. Las user_attributes son potentes, así que considera cómo podrían aplicarse a tu instancia de Looker.
  • session_length: Mantén esto en el tiempo mínimo necesario.

Algunos parámetros, como user_attributes, se pueden ocultar en la IU, pero se codificarán en la URL incorporada. Esto puede ser no deseado si, por ejemplo, una contraseña es un valor dentro del user_attribute de un usuario. Una forma de solucionar este problema es crear un grupo temporal, establecer la contraseña como un atributo de nivel de grupo y, luego, pasar el ID del grupo en la URL incorporada. Puedes borrar el grupo después de la sesión de incorporación para evitar un exceso de grupos inactivos.

La parte firmada de la URL contiene una marca de tiempo. Una vez que se usa la URL para acceder, ese tiempo debe ser de +/- 5 minutos a partir de la hora actual. En session_length, puedes especificar cuánto tiempo puede durar la sesión de incorporación desde que se usa la URL para acceder.

Cómo administrar el acceso a las incorporaciones firmadas

Cuando compilas la URL del contenido incorporado, ten en cuenta lo siguiente:

  • Usa el nivel más bajo de permisos necesarios.
  • Asigna acceso solo a los modelos específicos a los que el usuario debería poder acceder.
  • Usa group_ids para asignar un usuario a un grupo y permitir que el usuario incorporado controle el acceso a su carpeta de Looker.

API de Looker

Con la API de Looker, puedes habilitar el acceso a contenido incorporado mediante una aplicación de proxy o un servidor proxy inverso. En esta situación, la autenticación se realiza mediante claves de API, que están vinculadas a un usuario específico y tienen los mismos permisos que el usuario que las genera. Las claves de API constan de un ID de cliente y una clave secreto del cliente.

Administra el acceso de incorporación con la API

Cuando habilites el acceso a contenido incorporado con la API de Looker, te recomendamos lo siguiente:

  • Crear cuentas de servicios dedicadas para el acceso programático a la API con el conjunto mínimo de privilegios necesarios
  • Proteger el ID de cliente y el secreto del cliente que conforman la clave de API (si realizas la autenticación con un SDK)

Todos los atributos de usuario configurados para usuarios de incorporación que usen la API, pero que no se especifiquen en la URL de incorporación firmada, se restablecerán a sus valores predeterminados cuando se acceda a la URL de incorporación firmada.

Eventos de JavaScript incorporados

Una vez que hayas configurado el iframe de incorporación, ya sea de forma pública, privada, con la incorporación firmada o mediante la API, podrás interactuar con ese iframe mediante JavaScript. Para validar que la información con la que trabajas provenga realmente del iframe de Looker, puedes escuchar los eventos de JavaScript.

Cuando agregues dominios a la lista de entidades permitidas, usa el comodín para permitir que solo subdominios específicos accedan a tus eventos de JavaScript.

Si usas la función eval de JavaScript, asegúrate de que el valor de cadena en el argumento eval sea de una fuente confiable, como el servidor de Looker o CDN, y esté dentro del transporte HTTPS.

Ningún dato del cliente pasa por las CDN de Looker. Solo se entregan desde la CDN los recursos estáticos de la aplicación web de Looker (código JavaScript, páginas HTML y estilos CSS).

Implementaciones alojadas por el cliente

Alojar tu propia instancia de Looker puede parecer la forma segura de bloquear el acceso a los datos, en especial al contenido incorporado. Sin embargo, si tus usuarios necesitan acceder a la URL incorporada a través de Internet, no hay ventajas especiales para alojar Looker por tu cuenta.

Las implementaciones alojadas por el cliente pueden ser más adecuadas en los siguientes casos:

  • No es necesario que tus usuarios accedan a Looker a través de Internet.
  • Estás usando el frontend de Looker y estás accediendo a contenido incorporado mediante la API.