Prácticas recomendadas de seguridad para las analíticas insertadas

Con las analíticas insertadas de Looker, tus usuarios y clientes podrán descubrir datos insertados en un iframe de cualquier página web, portal o aplicación con formato HTML. El iframe ejecuta toda la aplicación Looker y solo solicita los datos necesarios para mostrar la consulta. Por diseño, los iframes no pueden leer ni escribir datos de aplicaciones o sitios web externos.

A veces, insertar datos puede suponer un problema de privacidad o seguridad. Para mitigar estas preocupaciones, recomendamos a los administradores de Looker que sigan estas prácticas recomendadas:

  • Si insertas contenido de Looker para los clientes, configura el contenido de los clientes en una instancia de Looker independiente de la que usas para las analíticas internas.
  • Solo conecte datos a la instancia de Looker insertada a la que deberían tener acceso los usuarios de la inserción, que pueden ser públicos.
  • Protege los tokens aleatorios de las URLs de inserción públicas como si fueran credenciales de usuario y deshabilita las URLs públicas si no se utilizan.
  • El valor de external_user_id asignado debe ser único para cada conjunto de permisos, atributos de usuario y modelos. Asegúrate de no usar el mismo external_user_id en diferentes sesiones de inserción para distintos usuarios interactivos, y de no usar el mismo external_user_id para un solo usuario que tenga diferentes permisos, valores de atributos de usuario o acceso al modelo.
  • Habilita un sistema cerrado.
  • Protege el secreto de la inserción firmada como si fueran credenciales de administrador de tu instancia de Looker insertada y mantén inhabilitada la inserción firmada si no la utilizas.
  • Usa una autenticación segura para tus instancias de Looker insertadas (inserción firmada, SAML, OAuth de Google y autenticación de dos factores).
  • Si utilizas la inserció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 insertada. El token de referencia de sesión nunca debe exponerse en el navegador.
  • Si usas la inserción sin cookies y defines el dominio de inserción permitido al adquirir la sesión sin cookies, nunca confíes en el origen del navegador del usuario de inserción. Mantén siempre una asignación del usuario insertado al origen de confianza del usuario insertado en el servidor de aplicaciones insertadas.

Looker ofrece diferentes tipos de métodos de inserción en función del nivel de autenticación que se requiera de los usuarios que accedan a tus datos: público, privado e inserción firmada. Con cualquiera de estos métodos, puedes interactuar con el iframe mediante JavaScript.

Incrustación pública

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

La URL y la URL insertada de la etiqueta iframe contienen un token aleatorio y no se pueden adivinar, pero cualquier persona que tenga la URL insertada puede acceder a los datos y no se aplican filtros ni restricciones adicionales. Te recomendamos que tengas en cuenta las implicaciones de seguridad de crear y compartir una URL pública de un look determinado antes de habilitar las URLs públicas.

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

Inserción privada

Si no quieres permitir el acceso público a tu Look, también puedes insertar un Look (o una Exploración o un panel de control) de forma privada en un iframe, de modo que se requiera iniciar sesión en Looker para ver el contenido.

Los usuarios autenticados solo pueden acceder al contenido que dictan los permisos de Looker que tienen asignados. Si cambias sus permisos en Looker, la URL insertada no cambiará, pero sí lo que el usuario podrá ver cuando acceda a la URL.

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

Las URLs de inserción privadas no caducan nunca y no se pueden revocar. Sin embargo, como el enlace solo funciona para los usuarios que tienen acceso a tu instancia de Looker y a esos datos, enviar un enlace no debería suponer un problema de seguridad.

Inserción firmada

Ponte en contacto con un especialista de Ventas de Google Cloud para actualizar tu licencia de esta función.

La inserción firmada va un paso más allá de la inserción privada. La inserció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 de un iframe. La autenticación crea una nueva sesión del navegador y emite una cookie en el navegador.

Los permisos, los identificadores y los atributos de usuario se transfieren como parámetros en la URL, que se firma con una clave secreta. Cualquier usuario que tenga 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 y con cualquier permiso. Consulta nuestro código de ejemplo para saber cómo generar URLs firmadas.

El clickjacking es un problema de seguridad del navegador que puede ocurrir cuando un código insertado o una secuencia de comandos ejecuta una función sin el conocimiento o el consentimiento del usuario, como un botón que parece hacer otra cosa. El clickjacking suele requerir una URL estática. La URL generada para una inserción firmada es secreta y solo debe tenerla el usuario que vea la inserción. El uso de la inserción firmada no aumenta el riesgo de clickjacking en el sitio web externo.

Parámetros de inserción firmados

Los parámetros incluidos en la URL del iframe son visibles para los usuarios insertados, pero no se pueden editar. Entre los factores que se tienen cuenta se incluyen los siguientes:

  • user_attributes: se usan para filtrar aún más los datos. Los user_attributes son potentes, así que piensa cómo pueden aplicarse a tu instancia de Looker.
  • session_length: mantén esta opción durante el tiempo mínimo necesario.

Algunos parámetros, como user_attributes, se pueden ocultar en la interfaz de usuario, pero seguirían codificándose en la URL de inserción. Esto puede ser un problema si, por ejemplo, una contraseña es un valor dentro de un user_attribute de un usuario. Una forma de evitarlo es crear un grupo temporal, definir la contraseña como un atributo a nivel de grupo y, a continuación, transferir el ID del grupo en la URL de inserción. Puedes eliminar el grupo después de la sesión de inserción para evitar que haya demasiados grupos caducados.

La parte firmada de la URL contiene una marca de tiempo. Una vez que se haya usado la URL para iniciar sesión, la hora debe ser de +/- 5 minutos con respecto a la hora actual. En session_length, puedes especificar la duración de la sesión insertada desde que se usa la URL para iniciar sesión.

Gestionar el acceso de inserción firmado

Cuando crees la URL de tu contenido insertado, ten en cuenta lo siguiente:

  • Usa el nivel de permisos más bajo que sea necesario.
  • 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 insertado controle el acceso a su carpeta de Looker.

API de Looker

Con la API de Looker, puedes habilitar el acceso al contenido insertado mediante una aplicación proxy o un servidor proxy inverso. En este caso, la autenticación se realiza mediante claves de API, que están vinculadas a un usuario concreto y tienen los mismos permisos que el usuario que las genera. Las claves de API están compuestas por un ID de cliente y una clave secreta de cliente.

Gestionar el acceso de inserción mediante la API

Cuando habilites el acceso al contenido insertado mediante la API de Looker, te recomendamos que hagas lo siguiente:

  • Crear cuentas de servicio específicas para el acceso a las APIs mediante programación con el conjunto mínimo de privilegios necesarios.
  • Proteger el ID de cliente y el secreto de cliente que componen la clave de API (si la autenticación se realiza con un SDK).

Los atributos de usuario definidos para los usuarios insertados mediante la API, pero que no se hayan especificado en la URL insertada firmada, se restablecerán a sus valores predeterminados la próxima vez que se acceda a la URL insertada firmada.

Eventos de JavaScript insertado

Una vez que hayas configurado el iframe insertado (de forma pública, privada, con inserción firmada o a través de la API), podrás interactuar con él mediante JavaScript. Para validar que la información con la que estás trabajando procede del iframe de Looker, puedes escuchar los eventos de JavaScript.

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

Si usa la función eval de JavaScript, asegúrese de que el valor de cadena del argumento eval proceda de una fuente fiable, como el servidor o la CDN de Looker, y que se transmita mediante HTTPS.

Los datos de los clientes nunca pasan por las CDNs de Looker. Solo los recursos estáticos de la aplicación web de Looker (código JavaScript, páginas HTML y estilos CSS) se sirven desde la CDN.

Implementaciones alojadas por el cliente

Alojar tu propia instancia de Looker puede parecer la forma más segura de restringir el acceso a los datos, especialmente al contenido insertado. Sin embargo, si tus usuarios necesitan acceder a la URL de inserción a través de Internet, no hay ninguna ventaja especial en alojar Looker por tu cuenta.

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

  • Tus usuarios no tienen que acceder a Looker a través de Internet.
  • Estás usando Looker como frontend y accedes al contenido insertado mediante la API.