Reducción del rol de usuario en Amazon Quick

Gestionar los permisos de acceso de manera eficaz es un aspecto importante para mantener un entorno seguro y colaborativo en Amazon Quick. Quick admite versátiles opciones de administración de usuarios diseñadas para acomodar diversos tipos de identidades y necesidades organizacionales. Puede aprovisionar usuarios de forma nativa a través de Quick Identity o administrarlos mediante proveedores de identidad empresariales como AWS IAM Identity Center o Active Directory. Estos sistemas permiten asignar y agrupar roles de usuario, incluidos Admin, Author y Reader, según las funciones laborales y los requisitos de seguridad. A medida que los miembros del equipo se incorporan, cambian de rol o abandonan la organización, los administradores deben asegurarse de que las transiciones se realicen sin problemas, sin interrumpir los flujos de trabajo del negocio ni crear brechas de seguridad.

Las revisiones periódicas del acceso son importantes para mantener la seguridad en su entorno de Quick. Planifique auditorías mensuales o trimestrales de los roles de usuario para confirmar que todos tengan los permisos adecuados. Cuando cambien las responsabilidades de los miembros del equipo, transfiera proactivamente la propiedad de sus dashboards y análisis para evitar recursos huérfanos. Esta práctica, recomendada en el AWS Well-Architected Framework, ayuda a mantener la continuidad de las visualizaciones críticas para el negocio.

En esta publicación, nos centramos en una tarea específica pero importante del ciclo de vida del usuario: la reducción de roles de usuario.

¿Por qué reducir el rol?

El principio de mínimo privilegio se aplica de manera contundente a la administración de Quick. Los usuarios deben tener acceso únicamente a lo que necesitan para sus funciones laborales específicas. Reducir los roles de usuario es una parte clave para aplicar el mínimo privilegio. Cuando las responsabilidades de un usuario ya no requieren capacidades de creación o administración, reduzca su rol en consecuencia para minimizar la superficie de seguridad.

Los precios de Quick también dependen del rol: los Authors y Admins pagan una tarifa mensual fija por usuario, mientras que los Readers utilizan precios basados en sesiones. Las organizaciones con usuarios aprovisionados como Authors que solo consumen dashboards pueden reducir sustancialmente los costos al ajustarlos a roles de Reader. Para obtener detalles actualizados sobre precios, consulte la página de precios de Amazon Quick.

Para un control más granular más allá de los roles integrados en Amazon Quick, considere complementar las asignaciones de roles con Custom Permissions, que restringen capacidades específicas dentro de un nivel de rol. La integración de Amazon Quick con AWS Identity and Access Management (IAM) proporciona límites de permisos adicionales que complementan el sistema básico de roles.

Alcance de esta publicación

Aunque los pasos exactos dependen del tipo de identidad del usuario, esta publicación aborda principalmente a los usuarios de Amazon Quick Identity (también llamados usuarios administrados por Quick). Los usuarios autenticados mediante IAM Identity Center o Active Directory suelen tener los cambios de rol administrados a través de las asignaciones de grupos de su proveedor de identidad externo. Si su entorno usa IAM Identity Center, la reducción de rol se realiza moviendo al usuario de un grupo de IdC a otro (por ejemplo, de un grupo Quick-Admins a un grupo Quick-Readers). No se requiere una secuencia de reducción escalonada.

Aunque la consola de Amazon Quick no proporciona una ruta directa de reducción para todas las transiciones de rol (específicamente, no se puede degradar de Admin a Reader ni de Author a Reader directamente a través de la interfaz de la consola), existen dos soluciones confiables: un método manual de eliminación y recreación, y un enfoque que usa la AWS Command Line Interface (AWS CLI). Le mostramos ambas técnicas para ayudarle a mantener una gestión de acceso adecuada a medida que su equipo evoluciona.

Requisitos previos

Antes de comenzar, asegúrese de tener una cuenta de AWS activa con acceso de administrador a Amazon Quick. Si planea usar el método de la CLI, necesita AWS CLI instalada y configurada en su máquina. También es útil preparar una lista de los usuarios cuyos roles deban cambiarse.

Descripción de los roles de Amazon Quick

Amazon Quick ofrece dos niveles de suscripción con conjuntos de roles distintos:

La consola no ofrece una forma directa de cambiar de un nivel Author a un nivel Reader. La update-user API aplica esta misma restricción y rechaza las degradaciones directas con el error «You cannot downgrade a user role».

La siguiente captura de pantalla muestra la página de gestión de usuarios de Amazon Quick Suite, donde la consola no ofrece control directo para pasar a un usuario de un nivel Author a un nivel Reader. Esto ilustra por qué son necesarios los métodos de esta publicación.

Figura 1: Página de gestión de usuarios de Amazon Quick Suite

El método de degradación paso a paso de la CLI funciona de manera fiable para los roles legacy de solo BI (Admin, Author, Reader), siguiendo esta secuencia:

Admin > Author > Restricted Reader > Reader

Esta misma secuencia también funciona para los usuarios Pro, siempre que los pasos intermedios utilicen los roles legacy. Por ejemplo, Author Pro > Author > Restricted Reader > Reader Pro se completa con éxito.

Consideraciones importantes antes de realizar cambios

Al implementar cambios de roles mediante cualquiera de los métodos, hay varios factores importantes que tener en cuenta. Primero, verifique que todos los usuarios de su lista sean actualmente usuarios Admin o Author antes de realizar cambios. Intentar degradar usuarios que ya tienen permisos más bajos podría causar errores. Las preguntas sobre la propiedad de los recursos siguen aplicando incluso cuando se usa el método de la CLI. Los usuarios que sean degradados ya no podrán editar los recursos que poseían previamente. Para organizaciones más grandes que usan el método de la CLI, considere cargar las direcciones de correo electrónico de los usuarios desde un archivo CSV en lugar de codificarlas directamente. Si utiliza AWS CloudShell en lugar de una instalación local de la CLI, puede omitir la especificación de la Región de AWS porque AWS CloudShell usa automáticamente el contexto de Región de su consola actual.

Transferencia de la propiedad de los activos (haga esto primero)

Antes de eliminar a un usuario, es esencial asegurarse de que todos los activos que posee, como paneles, conjuntos de datos y análisis, sean reasignados correctamente. Esto evita interrupciones y deja recursos huérfanos. Si el usuario es un Author, verifique si posee algún conjunto de datos o panel, y siga los mismos pasos de reasignación de activos que se describen aquí. Hay tres formas principales de manejar las transferencias de propiedad de activos en Amazon Quick.

Opción 1: Transferir proactivamente la propiedad a otro administrador

El enfoque más controlado es reasignar manualmente la propiedad antes de eliminar al usuario. Para hacerlo, entre en cada activo en Quick, elija Sharey asigne a otro administrador como copropietario. Con este método, puede determinar exactamente quién se hace cargo de cada recurso, lo cual es especialmente útil para paneles o conjuntos de datos de alto impacto. Aunque esto puede llevar mucho tiempo en entornos grandes, le da la flexibilidad de distribuir los activos según la estructura y las responsabilidades de su equipo.

La siguiente captura de pantalla muestra el cuadro de diálogo Share de un activo, donde agrega a otro administrador como copropietario para que la propiedad se transfiera antes de que se elimine al usuario original.

Figura 2: Transferencia de la propiedad de un activo a otro usuario

Opción 2: Usar la transferencia masiva de activos de Amazon Quick en la página Admin

Si el usuario posee muchos activos, el método manual puede volverse ineficiente. En este caso, puede usar la función Manage assets disponible en la sección Admin de Quick. Con esta herramienta, los administradores pueden realizar transferencias de propiedad en bloque o actualizar los permisos de uso compartido de varios activos a la vez. Agiliza considerablemente el proceso de reasignación, especialmente cuando se da de baja a usuarios o se gestionan cambios organizacionales. Para obtener más detalles sobre cómo usar esta función, consulte la documentación oficial Managing assets in Amazon Quick .

Opción 3: Compartir activos con un grupo de usuarios de Quick

Otra estrategia eficaz es compartir activos con un grupo de usuarios. Para los usuarios de Quick Identity, puede crear un grupo de Quick, agregar a los miembros relevantes del equipo y compartir paneles o conjuntos de datos con el grupo en lugar de con usuarios individuales. Si su cuenta está integrada con IAM Identity Center o Active Directory, los grupos equivalentes se crean y administran en esos sistemas, y Quick usa esos grupos externos para el control de acceso en lugar de los grupos administrados por Quick. De esta manera, el acceso a los recursos compartidos permanece intacto incluso si se elimina a un usuario específico. Es un enfoque resiliente que reduce la necesidad de reasignar la propiedad en el futuro y ayuda a mantener un acceso consistente entre equipos dinámicos.

Método manual: Eliminar y volver a crear al usuario

Aunque no es el enfoque más eficiente, el método manual de eliminación y recreación es una opción para entornos donde el uso de la CLI no es factible. Este método consiste en eliminar por completo al usuario administrador y luego volver a crearlo con permisos de lector. Este mismo método manual también aplica cuando se degrada a un Author a Reader, aunque normalmente con menos complicaciones en cuanto a la propiedad de los activos.

Dado que este método requiere eliminar la cuenta del usuario antes de volver a crearla con un rol más bajo, una preparación cuidadosa es esencial para evitar perder recursos valiosos e interrumpir los flujos de trabajo. Asegúrese de haber completado la transferencia de la propiedad de los activos descrita en la sección anterior antes de continuar.

Paso 1: Eliminar al usuario administrador

Después de transferir la propiedad de todos los recursos, inicie sesión en la AWS Management Console y navegue hasta el servicio Amazon Quick. Desde allí, elija su icono de perfil y luego elija Manage Quick, seguido de Manage users. Cuando ubique al usuario administrador que desea degradar, elija el icono de eliminar junto a su nombre y confirme la eliminación cuando se le solicite. Esto elimina por completo su acceso actual al sistema.

Si no ha transferido todos los recursos de antemano, Quick presenta un cuadro de diálogo de transferencia de propiedad. Este cuadro de diálogo le pide que seleccione a otro administrador que recibirá la propiedad de todos los recursos del usuario. Seleccione un administrador apropiado de la lista y luego confirme la transferencia eligiendo Eliminar y transferir. Este mecanismo de transferencia integrado ayuda a evitar recursos huérfanos, pero transfiere todo a un solo administrador. Para un control más granular, utilice el enfoque proactivo mencionado anteriormente para distribuir los recursos estratégicamente entre diferentes miembros del equipo.

Si omitió la transferencia proactiva, el cuadro de diálogo de eliminación que se muestra en la siguiente figura le permite reasignar todos los recursos del usuario a un solo administrador antes de eliminar la cuenta.

Figura 3: Transferencia integrada de recursos durante la eliminación del usuario

Paso 2: Recrear el usuario con el rol de Reader

Tras eliminar correctamente al usuario, permanezca en la página Users y elija Invitar a usuarios. Introduzca la dirección de correo electrónico del usuario y seleccione la Lector rol de las opciones disponibles. Envía la invitación para permitir que el usuario vuelva a unirse a Quick con sus nuevos permisos, más restringidos.

Paso 3: Verificar el cambio de rol

Después de que el usuario acepte la invitación:

• Confirme que sus permisos se hayan actualizado a Lector.
• Verifique que solo puedan ver paneles e informes.
• Confirme que no pueden modificar ni crear contenido.

Método de CLI: transición de rol de escalado descendente (recomendado)

Si prefiere usar la AWS CLI o AWS CloudShell, puede cambiar el rol del usuario de manera programática. Dado que Quick requiere que los cambios de rol se realicen en una secuencia específica, no se puede pasar directamente de cualquier Admin a cualquier Reader. En cambio, debe pasar por roles intermedios.

Notas importantes

• Reemplazar <your-account-id> con su ID de cuenta de AWS.
• Reemplazar <user-name> con el nombre de usuario del usuario.
• Reemplazar <user-email> con la dirección de correo electrónico del usuario.
• Si estás usando la AWS CLI fuera de CloudShell, especifica el --region parámetro.
• El --role el valor debe coincidir exactamente con el nombre de rol de la API (consulte la tabla anterior).

Ejemplo: Ruta heredada (de Administrador a Lector)

Paso 1: Cambiar el rol de Admin a Author:

aws quicksight update-user \
  --aws-account-id <your-account-id> \
  --user-name <user-name> \
  --namespace default \
  --email <user-email> \
  --role AUTHOR

Paso 2: Actualizar el rol de Author a Restricted Reader:

aws quicksight update-user \
  --aws-account-id <your-account-id> \
  --user-name <user-name> \
  --namespace default \
  --email <user-email> \
  --role RESTRICTED_READER

Paso 3: Cambie el rol de Restricted Reader a Reader:

aws quicksight update-user \
  --aws-account-id <your-account-id> \
  --user-name <user-name> \
  --namespace default \
  --email <user-email> \
  --role READER

Tras la degradación: revise los perfiles de límites y los permisos personalizados

Los cambios de rol no ajustan automáticamente los Limit Profiles ni los perfiles de Custom Permissions. Ambos persisten de forma independiente del rol del usuario, y debes revisarlos después de cualquier degradación.

• Limit Profiles controlan los límites por usuario de recursos como el almacenamiento de índices y las horas de agente. Si al usuario degradado se le asignó un perfil adecuado para su rol anterior de Admin o Author, reasígnale un perfil de límites apropiado para Reader para evitar sobreasignar recursos. Consulta la documentación de Limit Profiles para más detalles.
• Custom Permissions restringen capacidades específicas dentro de un nivel de rol. Un perfil asignado a un Author podría no comportarse como se espera en un Reader. Puedes dejar de aplicarlo durante el paso final de la CLI (usando --unapply-custom-permissions) o asignar un perfil diseñado para el nivel Reader.

Script para actualizar varios usuarios

Usa el siguiente script para actualizar varios usuarios.

#!/bin/bash

# Define AWS account details
AWS_ACCOUNT_ID="<your-account-id>"
REGION="<your-region>"

# Load users from file (format: username,email per line)
# Lines starting with # are treated as comments
INPUT_FILE="users_to_downgrade.txt"

while IFS=',' read -r username email; do
  # Skip comments and empty lines
  [[ "$username" =~ ^#.*$ || -z "$username" ]] && continue

  echo "Processing user: $username"

  # Role transition stages
  for ROLE in AUTHOR RESTRICTED_READER READER; do
    RESULT=$(aws quicksight update-user \
      --aws-account-id "$AWS_ACCOUNT_ID" \
      --user-name "$username" \
      --namespace default \
      --email "$email" \
      --role "$ROLE" \
      --region "$REGION" 2>&1)

    if [ $? -ne 0 ]; then
      echo " ERROR at $ROLE: $RESULT"
      break
    fi

    echo " Transitioned to $ROLE"
    sleep 3
  done

  echo "Role update completed for $username."
done < "$INPUT_FILE"

echo "All user role updates processed!"

Funcionalidad del script

Este script realiza lo siguiente:

• Lee nombres de usuario y direcciones de correo electrónico desde un archivo externo (admite comentarios con #).
• Actualiza el rol en tres etapas: Admin > Author > Restricted Reader > Reader.
• El manejo de errores detiene la transición de un usuario si algún paso falla.
• Los comandos sleep permiten que transcurra tiempo para que los cambios surtan efecto.

Algunas cosas a tener en cuenta al ejecutar el script:

• Confirma que los usuarios sean actualmente usuarios Admin o Author antes de ejecutarlo.
• Use el nombre de usuario real de Quick, que puede diferir del prefijo del correo electrónico en entornos federados.
• No es necesario especificar la región en AWS CloudShell.
• Puede modificar el script para cargar los usuarios desde una exportación CSV de list-users.

Mejores prácticas para la gestión del acceso de usuarios

Para mantener su entorno de Quick seguro y bien organizado, siga estas mejores prácticas:

• Revise los roles de usuario con regularidad (auditorías mensuales o trimestrales).
• Transfiera la propiedad de los recursos antes de cambiar los roles.
• Siga el principio de mínimo privilegio.
• Use los perfiles de Custom Permissions para un control detallado dentro de un nivel de rol.
• Comparta recursos con grupos en lugar de con individuos para mayor resiliencia.
• Use AWS Identity and Access Management para establecer límites de permisos adicionales.

Limpieza

Después de completar los cambios de roles de usuario:

• Elimine los usuarios de prueba.
• Verifique que no queden recursos no deseados.
• Elimine los scripts de CLI temporales o los archivos de listas de usuarios.
• Compruebe dos veces los permisos finales de los usuarios.

Conclusión

En esta publicación, exploramos dos métodos para degradar los roles de usuario en Amazon Quick: la eliminación y recreación manual, y un enfoque flexible con la AWS CLI. Estas estrategias le ayudan a gestionar el acceso del equipo de manera eficiente y segura.

Para los entornos que usan IAM Identity Center, los cambios de roles se gestionan mediante la reasignación de grupos de IdC, lo cual no requiere la secuencia de degradación escalonada descrita aquí. Para controles de gobernanza adicionales, explore Custom Permissions para restricciones a nivel de funcionalidades y Restricted Folders para el aislamiento a nivel de contenido.

Recursos

• Gestión del acceso de usuarios en Amazon Quick
• Gestión de recursos en Amazon Quick
• Perfiles de Custom Permissions
• AWS IAM Best Practices
• AWS Business Intelligence Blog

Nos encantaría conocer sus experiencias en la gestión de usuarios. ¿Cómo maneja su organización las transiciones de roles en Quick Suite? ¿Ha desarrollado scripts o procesos personalizados para agilizar estos cambios? Comparta sus ideas y desafíos en los comentarios.

Sobre el autor