Blog de Amazon Web Services (AWS)
Inserte tableros de multiclientes en aplicaciones SaaS con Amazon QuickSight sin aprovisionar ni administrar usuarios
Por Raji Sivasubramaniam, Arquitecto de Soluciones en AWS,
Srikanth Baheti, Arquitecto de Soluciones en AWS y
Kareem Syed-Mohammed, Arquitecto de Soluciones en AWS
Amazon QuickSight es un servicio de inteligencia empresarial (BI) nativo de la nube y totalmente administrado que facilita la conexión a sus datos, crea tableros interactivos y los comparte con decenas de miles de usuarios, ya sea dentro de QuickSight o embebido en aplicaciones de software como servicio (SaaS).
QuickSight Enterprise Edition agregó recientemente seguridad a nivel de fila (RLS, por las siglas en inglés de Row Level Security) mediante etiquetas, una nueva característica que permite a los desarrolladores compartir un solo tablero con decenas de miles de usuarios, al tiempo que garantiza que cada usuario solo pueda ver y tener acceso a datos particulares. Esto significa que cuando un proveedor de software independiente (ISV) agrega un tablero embebido de QuickSight en su aplicación, no tiene que aprovisionar a sus usuarios finales en QuickSight y simplemente puede configurar etiquetas para filtrar los datos en función de quién tiene permisos al tablero. Por ejemplo, si un ISV quisiera configurar un tablero que está siendo compartido a 20,000 usuarios a través de 100 clientes de una aplicación, con todos los usuarios dentro de un cliente teniendo acceso a datos idénticos, esta nueva función le permite compartir un solo tablero para todos los usuarios, sin tener que configurar o administrar los 20,000 usuarios en QuickSight.
El RLS aplicado mediante etiquetas garantiza que cada usuario final solo vea los datos que son relevantes para ellos, mientras que QuickSight se escala automáticamente para cumplir con la concurrencia del usuario para garantizar que cada usuario final vea un rendimiento rápido y constante. En esta publicación, veremos cómo se puede implementar.
Resumen de la solución
Para insertar tableros sin aprovisionamiento de usuarios, utilizamos la API GenerateEmbedURLForAnonymousUser, que se cobra con base en los precios de capacidad de sesión de Quicksight. Con esta API, el servidor donde se embeberá tableros (lógica en la aplicación SaaS) determina y administra la identidad del usuario al que se muestra el tablero (en contraposición a que esta identidad se aprovisione y administre dentro de QuickSight).
El siguiente diagrama muestra un flujo de trabajo de ejemplo de tableros embebidos que protege los datos en función de quién accede a la aplicación mediante RLS con etiquetas.
En este caso, un ISV tiene una aplicación SaaS a la que acceden dos usuarios finales. Uno es gerente y el otro es supervisor de sitio. Ambos usuarios acceden a la misma aplicación y al mismo tablero de QuickSight embebido en la aplicación y no están aprovisionados en QuickSight. Cuando el supervisor del sitio accede al tablero, solo ve datos pertenecientes a su sitio, y cuando el administrador accede al tablero, ve datos pertenecientes a todos los sitios que administra.
Para lograr este comportamiento, utilizamos una nueva función que permite configurar la seguridad a nivel de fila mediante etiquetas. Este método de proteger los datos en los tableros embebidos solo funciona cuando los tableros están integrados sin el aprovisionamiento de usuarios (también llamado incrustación anónima). El proceso incluye dos pasos:
- Configurar etiquetas llave en las columnas de los conjuntos de datos utilizados para crear el tablero.
- Establecer valores para las llaves de las etiquetas en tiempo de ejecución al insertar el tablero de forma anónima.
Configurar etiquetas llave en columnas en los conjuntos de datos que se utilizan para crear el tablero
Los ISV o desarrolladores pueden establecer columnas en los conjuntos de datos mediante las API CreateDataset o UpdateDataset de la siguiente manera:
create-data-set
--aws-account-id
--data-set-id
--name
--physical-table-map
[--logical-table-map ]
--import-mode
[--column-groups ]
[--field-folders ]
[--permissions ]
[--row-level-permission-data-set ]
[--column-level-permission-rules ]
[--tags ]
[--cli-input-json ]
[--generate-cli-skeleton ]
[--row-level-permission-tag-configuration //upto 50 tagkeys can be added at this time
'{
"Status": "ENABLED",
"TagRules":
[
{
"TagKey": "tag_name_1", //upto 128 characters
"ColumnName": "column_name_1",
"TagMultiValueDelimiter": ",",
"MatchAllValue": "*"
},
{
"TagKey": "tag_name_2", //upto 128 characters
"ColumnName": "column_name_2"
}
]
}'
]update-data-set
--aws-account-id <value>
--data-set-id <value>
--name <value>
--physical-table-map <value>
[--logical-table-map <value>]
--import-mode <value>
[--column-groups <value>]
[--field-folders <value>]
[--row-level-permission-data-set <value>]
[--column-level-permission-rules <value>]
[--cli-input-json <value>]
[--generate-cli-skeleton <value>]
[--row-level-permission-tag-configuration //upto 50 tagkeys can be added at this time
'{
"Status": "ENABLED",
"TagRules":
[
{
"TagKey": "tag_name_1", //upto 128 characters
"ColumnName": "column_name_1",
"TagMultiValueDelimiter": ",",
"MatchAllValue": "*"
},
{
"TagKey": "tag_name_2", //upto 128 characters
"ColumnName": "column_name_2",
"MatchAllValue": "*"
},
{
"TagKey": "tag_name_3", //upto 128 characters
"ColumnName": "column_name_3"
}
]
}'
]En el código anterior, la configuración de row-level-permission-tag-configuration es el elemento que puede usar para definir etiquetas llave en las columnas de un conjunto de datos. Para cada etiqueta, puede definir los siguientes elementos opcionales:
- TagMultiValueDelimiter –cuando se utiliza esta opción cuando se establece en una columna le permite pasar más de un valor a la etiqueta en tiempo de ejecución, y los valores están delimitados por el string establecido para esta opción. En este ejemplo, se establece una coma como caracter delimitador.
- MatchAllValue –cuando se utiliza esta opción en una columna puede pasar todos los valores de una columna en tiempo de ejecución, y los valores son representados por el string establecido para esta opción. En este ejemplo, se establece un asterisco, implicando que aceptará cualquier cadena que se le pase.
Después de definir nuestras etiquetas, podemos habilitar o deshabilitar estas reglas usando el elemento Status de la API. En este caso, el valor se establece en ENABLED. Para deshabilitar las reglas, el valor es DISABLED. Una vez habilitadas las etiquetas, podemos pasar valores a las etiquetas en tiempo de ejecución para proteger los datos que se muestran en función de quién accede al tablero.
Cada conjunto de datos puede tener hasta 50 etiquetas llave.
Recibimos la siguiente respuesta para la API CreateDataset o UpdateDataset:
{
"Status": 201,
“Arn”: “string”, //ARN of the dataset
“DataSetId”: “string”, //ID of the dataset
“RequestId”: “string”
}
Permitir que los autores accedan a datos protegidos por llaves de etiquetas al autorizar análisis
Una vez que se establecen y habilitan las etiquetas llave en el conjunto de datos, está protegido. Los autores, cuando utilizan este conjunto de datos para crear un tablero, no ven ningún dato. Deben tener permisos para ver los datos del conjunto de datos al crear un panel. Para dar permiso a los autores de QuickSight para ver datos en el conjunto de datos, cree un archivo de permisos o un conjunto de datos de reglas. Para obtener más información, consulte Creación de reglas de conjuntos de datos para seguridad a nivel de fila. El siguiente es un ejemplo de conjunto de datos de reglas.
| UserName | column_name_1 | column_name_2 | column_name_3 |
| admin/sampleauthor |
En este conjunto de datos de muestra, tenemos el nombre de usuario del autor en la columna UserName. Las otras tres columnas son las columnas del conjunto de datos en el que configuramos las etiquetas llave. Los valores se dejan vacíos para estas columnas para el autor agregado a esta tabla. Esto permite al autor ver todos los datos en estas columnas sin ninguna restricción cuando está creando análisis.
Establecer valores para las etiquetas llave en tiempo de ejecución al embeber el tablero
Una vez que se establecen las etiquetas llave para las columnas de los conjuntos de datos, los desarrolladores establecen valores en las llaves en tiempo de ejecución al embeber el tablero. Los desarrolladores llaman a la API GenerateDashboardEmbedURLForAnonymousUser para embeber el tablero y pasar valores a las etiquetas llave en el elemento SessionTags, como se muestra en el siguiente código:
POST /accounts//embed-url/anonymous-user HTTP/1.1
Content-type: application/json
{
"AwsAccountId": "string",
"SessionLifetimeInMinutes": integer,
"Namespace": "string",
"SessionTags":
[
{
"Key": "tag_name_1", // Length: [1-128]
"Value": "value1, value2" // Length: [0-256]
}
{
"Key": "tag_name_2", // Length: [1-128]
"Value": "*" // Length: [0-256]
}
{
"Key": "tag_name_3", // Length: [1-128]
"Value": "value3" // Length: [0-256]
}
],
"AuthorizedResourceArns":
[
// Length: [1-25]
// Dashboard ARNs in the same AWS Account
"string"
],
"ExperienceConfiguration":
{
"Dashboard":
{
"InitialDashboardId": "string"
}
}
}
}
Debido a que esta función protege los datos para los usuarios no aprovisionados en QuickSight, la llamada a la API es solo para AnonymousUser y, por lo tanto, esta función solo funciona con la API GenerateDashboardEmbedURLForAnonymousUser.
El código del ejemplo anterior tiene los siguientes componentes:
- Para
tag_name_1, establece dos valores (value1yvalue2) usando elTagMultiValueDelimiterdefinido al configurar las etiquetas llave (en este caso, una coma). - Para
tag_name_2, establece un valor como un asterisco. Esto permite que esta llave de etiqueta tenga todos los valores asignados para esa columna porque definimos un asterisco comoMatchAllValueal configurar una etiqueta llave en la columna previamente. - Para
tag_name_3, estableces un valor (value3).
Definición de respuesta de API
La respuesta de la API tiene EmbedURL, Status y RequestID. Puede embeber esta URL en su página HTML. Los datos de este tablero se protegen en función de los valores que se pasan a las etiquetas llave al llamar a la API de incrustación GenerateDashboardEmbedURLForAnonymousUser:
- EmbedUrl (string) –una URL de un solo uso que puede colocar en su página web del lado del servidor para incrustar su tablero. Esta URL es válida por 5 minutos. La operación de la API proporciona a la URL un valor
auth_codeque permite un inicio de sesión (y solo uno) en una sesión de usuario que es válida por hasta 10 horas. Esta URL muestra el tablero con las reglas de RLS aplicadas en función de los valores establecidos para las etiquetas llave de RLS. - Status (entero) – el estado HTTP de la solicitud.
- RequestId (string) –el ID de solicitud de AWS para esta operación.
Control de acceso granular
Puede lograr un control de acceso granular mediante la generación dinámica de políticas de AWS Identity and Access Management (AWS IAM). Para obtener más información, consulte Aislando clientes SaaS con políticas de IAM generadas dinámicamente. Cuando use la API GenerateEmbedUrlForAnonymousUser para embeber, debe mencionar dos tipos de recursos en la política de IAM: los ARN de espacio de nombres (en inglés namespace) a los que pertenecen virtualmente sus usuarios anónimos y los ARN del tablero que se pueden usar en el valor del parámetro de entrada AuthorizedResourceArns. Las sesiones generadas con esta API pueden acceder a los recursos autorizados y a los tableros compartidos con el espacio de nombres.
Dado que los usuarios anónimos forman parte de un espacio de nombres, pueden acceder a los paneles compartidos con el espacio de nombres, independientemente de si se pasan explícitamente a través del parámetro AuthorizedResourceArns.
Para permitir que la identidad de la persona que llama genere una URL para cualquier usuario y cualquier tablero, el bloque Resource de la política se puede establecer en *. Para permitir que la identidad de la persona que llama genere una URL para cualquier usuario anónimo en un espacio de nombres específico (como Tenant1), la parte Resource de la política se puede configurar en arn:aws:quicksight:us-east-1:<YOUR_AWS_ACCOUNT_ID>:namespace/Tenant1. Esto es lo mismo para el ID del tablero. Para la generación dinámica de políticas, también puede utilizar marcadores de posición (en inglés placeholders) para el espacio de nombres y los usuarios.
El siguiente código es un ejemplo de política de IAM:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "QuickSightEmbeddingRole",
"Effect": "Allow",
"Action": [
"quicksight:GenerateEmbedUrlForAnonymousUser"
],
"Resource": [
"arn:aws:quicksight:us-east-1::namespace/tenant1",
"arn:aws:quicksight:us-east-1::dashboard/dashboard-id-123"
// You can add specific Namespace IDs (tenant IDs), or namespace prefixes here
// e.g. "arn:aws:quicksight:us-east-1::namespace/{{tenant-id}}" will allow the role to
// generate embedding URL for namespace dynamically substituted
// into the placeholder {{tenant-id}}
// or "arn:aws:quicksight:us-east-1::namespace/MyTenantIdPrefix*" will allow the role to
// generate embedding URL for namespaces having prefix MyTenantIdPrefix.
// You can add specific Dashboard IDs, or ID prefixes here
// e.g. "arn:aws:quicksight:us-east-1::dashboard/{{dashboard-id}}" will allow the role to
// generate embedding URL for dashboard dynamically substituted
// into the placeholder {{dashboard-id}}
// or "arn:aws:quicksight:us-east-1::dashboard/MyDashboardIdPrefix*" will allow the role to
// generate embedding URL for namespaces having prefix MyDashboardIdPrefix.
]
}
]
}
Caso de uso
OkTank es un ISV en el espacio del área de salud. Tienen una aplicación SaaS que utilizan diferentes hospitales en diferentes regiones del país para administrar sus ingresos. OkTank tiene miles de empleados de atención médica que acceden a su aplicación y ha incorporado operaciones relacionadas con su negocio en un tablero de QuickSight en su aplicación. OkTank no quiere administrar a sus usuarios en QuickSight por separado y desea proteger los datos en función de qué usuario desde qué hospital accede a su aplicación. OkTank está asegurando los datos en los tableros en tiempo de ejecución usando seguridad a nivel de fila y etiquetas.
OkTank tiene hospitales (North Hospital, South Hospital y Downtown Hospital) en las regiones del centro, este, sur y oeste.
En este ejemplo, los siguientes usuarios acceden a la aplicación de OkTank y al tablero embebido. Cada usuario tiene un cierto nivel de reglas de restricción que definen a qué datos pueden acceder en los tableros. PowerUser es un superusuario que puede ver los datos de todos los hospitales y regiones.
| OkTank’s application’s user | Hospital | Region |
| NorthUser | North Hospital | Central and East |
| NorthAdmin | North Hospital | All regions |
| SouthUser | South Hospital | South |
| SouthAdmin | South Hospital | All regions |
| PowerUser | All hospitals | All regions |
Ninguno de estos usuarios ha sido aprovisionado en QuickSight. OkTank gestiona a estos usuarios en su propia aplicación y, por lo tanto, sabe a qué región y hospital pertenece cada usuario. Cuando cualquiera de estos usuarios accede al tablero de QuickSight embebido en la aplicación, OkTank debe proteger los datos en el panel para que los usuarios solo puedan ver los datos de su región y hospital.
Primero, OkTank creó etiquetas llave en el conjunto de datos que están usando para impulsar el tablero. En su llamada a la API UpdateDataset, el elemento RowLevelPermissionTagConfiguration en el conjunto de datos es el siguiente:
En segundo lugar, en el tiempo de ejecución, al embeber el tablero a través de la API GenerateDashboardEmbedURLForAnonymousUser, establecen SessionTags para cada usuario.
SessionTags para NorthUser en la llamada API GenerateDashboardEmbedURLForAnonymousUser son las siguientes:
"SessionTags":
[
{
"Key": "customer_hospital",
"Value": "North Hospital"
},
{
"Key": " customer_region",
"Value": "Central, East"
}
]
SessionTags para NorthUser son las siguientes:
"SessionTags":
[
{
"Key": " customer_hospital",
"Value": "North Hospital"
},
{
"Key": " customer_region",
"Value": "*"
}
]SessionTags para SouthUser son las siguientes:
"SessionTags":
[
{
"Key": " customer_hospital",
"Value": "South Hospital"
},
{
"Key": " customer_region",
"Value": "South"
}
]
SessionTags para SouthAdmin son las siguientes:
"SessionTags":
[
{
"Key": " customer_hospital",
"Value": "South Hospital"
},
{
"Key": " customer_region",
"Value": "*"
}
]
SessionTags para PowerUser son las siguientes:
"SessionTags":
[
{
"Key": " customer_hospital",
"Value": "*"
},
{
"Key": " customer_region",
"Value": "*"
}
]La siguiente captura de pantalla muestra lo que SouthUser ve en relación con South Hospital en la región sur.
La siguiente captura de pantalla muestra lo que SouthAdmin ve en relación con South Hospital en la todas las regiones.
La siguiente captura de pantalla muestra lo que PowerUser ve en relación con todos los hospitales en la todas las regiones.
Según las etiquetas de sesión, OkTank ha protegido los datos en los tableros embebidos de modo que cada usuario solo ve datos específicos en función de su acceso. Puede acceder al tablero como uno de los usuarios (cambiando el usuario en el menú desplegable en la parte superior derecha) y ver cómo cambian los datos según el usuario seleccionado.
En general, con la seguridad a nivel de fila mediante etiquetas, OkTank puede brindar una experiencia de análisis convincente dentro de su aplicación SaaS, al tiempo que se asegura de que cada usuario solo vea los datos apropiados sin tener que aprovisionar y administrar usuarios en QuickSight. QuickSight proporciona una opción de análisis segura y altamente escalable que puede configurar e implementar a producción en días, en lugar de semanas o meses.
Conclusión
La combinación de integrar tableros para usuarios no aprovisionados en QuickSight y seguridad a nivel de fila mediante etiquetas permite a los desarrolladores e ISV’s configurar de manera rápida y sencilla análisis sofisticados y personalizados para los usuarios de sus aplicaciones, todo sin ninguna configuración o administración de infraestructura mientras se escala a millones de usuarios. Para obtener más actualizaciones de los análisis embebidos de QuickSight, consulte la sección de What’s New en la guía del usuario de Amazon QuickSight.
Este artículo fue traducido del Blog de AWS en Inglés .
Sobre los autores
Raji Sivasubramaniam es un arquitecto de soluciones especializado en AWS y se especializa en análisis. Raji tiene 20 años de experiencia en la arquitectura de soluciones integrales de gestión de datos empresariales, inteligencia empresarial y análisis para empresas Fortune 500 y Fortune 100 en todo el mundo. Tiene una amplia experiencia en análisis y datos médicos integrados con una amplia variedad de conjuntos de datos de atención médica, incluido el mercado administrado, la selección de médicos y el análisis de pacientes. En su tiempo libre, a Raji le gusta el senderismo, el yoga y la jardinería.
Srikanth Baheti es un arquitecto de soluciones senior especializado globalmente para Amazon QuickSight. Comenzó su carrera como consultor y trabajó para múltiples organizaciones privadas y gubernamentales. Posteriormente trabajó para PerkinElmer Health and Sciences & eResearch Technology Inc, donde fue responsable del diseño y desarrollo de aplicaciones web con alto tráfico, canalizaciones de datos altamente escalables y fáciles de mantener para plataformas de informes que utilizan servicios de AWS y computación serverless.
Kareem Syed-Mohammed es gerente de producto (en inglés product manager y por sus siglas PM) en Amazon QuickSight. Se centra en análisis integrados, API y en la experiencia del desarrollador. Antes de QuickSight, trabajó en AWS Marketplace y Amazon Retail como PM. Kareem comenzó su carrera como desarrollador y luego como PM de tecnologías de centros de llamadas, Local Expert y Ads para Expedia. Trabajó como consultor con McKinsey and Company durante un tiempo.
Sobre la traductora
Fabiana Serangelli es Arquitecta de Soluciones de AWS.
Sobre los revisores
Rodrigo Cabrera es Arquitecto de Soluciones de AWS.
Servio Reyes es Arquitecto de Soluciones de AWS.