Rétrograder les rôles utilisateurs dans Amazon Quick

La gestion efficace des permissions d'accès est un aspect important du maintien d'un environnement sécurisé et collaboratif dans Amazon Quick. Quick prend en charge des options polyvalentes de gestion des utilisateurs, conçues pour s'adapter à divers types d'identités et besoins organisationnels. Vous pouvez provisionner les utilisateurs nativement via Quick Identity ou les gérer via des fournisseurs d'identité d'entreprise tels que AWS IAM Identity Center ou Active Directory. Ces systèmes permettent d'attribuer et de regrouper les rôles utilisateurs, notamment Admin, Author et Reader, en fonction des fonctions professionnelles et des exigences de sécurité. Lorsque des membres de l'équipe rejoignent l'organisation, changent de rôle ou la quittent, les administrateurs doivent s'assurer que les transitions se déroulent en douceur, sans perturber les flux de travail métier ni créer de failles de sécurité.

Des revues régulières des accès sont importantes pour maintenir la sécurité dans votre environnement Quick. Planifiez des audits mensuels ou trimestriels des rôles utilisateurs afin de confirmer que chacun dispose des permissions appropriées. Lorsque les responsabilités des membres de l'équipe changent, transférez de manière proactive la propriété de leurs tableaux de bord et analyses pour éviter les ressources orphelines. Cette pratique, recommandée dans le AWS Well-Architected Framework, aide à maintenir la continuité des visualisations critiques pour l'entreprise.

Dans cet article, nous nous concentrons sur une tâche spécifique mais importante du cycle de vie des utilisateurs : la rétrogradation des rôles utilisateurs.

Pourquoi rétrograder ?

Le principe du moindre privilège s'applique fortement à l'administration de Quick. Les utilisateurs ne devraient avoir accès qu'à ce dont ils ont besoin pour leurs fonctions professionnelles spécifiques. La rétrogradation des rôles utilisateurs est un élément clé de l'application du moindre privilège. Lorsque les responsabilités d'un utilisateur ne nécessitent plus de capacités de création ou d'administration, réduisez son rôle en conséquence afin de minimiser la surface d'attaque.

La tarification de Quick est également basée sur les rôles : les Authors et les Admins paient des frais mensuels fixes par utilisateur, tandis que les Readers sont soumis à une tarification basée sur les sessions. Les organisations dont les utilisateurs sont provisionnés en tant qu'Authors mais qui se contentent de consulter des tableaux de bord peuvent réduire considérablement leurs coûts en les réaffectant au rôle de Reader. Pour connaître les détails actuels de la tarification, consultez la page de tarification d'Amazon Quick.

Pour un contrôle plus granulaire au-delà des rôles intégrés dans Amazon Quick, envisagez de compléter les attributions de rôles avec les Custom Permissions, qui restreignent des capacités spécifiques au sein d'un niveau de rôle. L'intégration d'Amazon Quick avec AWS Identity and Access Management (IAM) offre des limites de permissions supplémentaires qui complètent le système de rôles de base.

Portée de cet article

Bien que les étapes exactes dépendent du type d'identité de l'utilisateur, cet article traite principalement des utilisateurs Amazon Quick Identity (également appelés utilisateurs gérés par Quick). Les utilisateurs authentifiés via IAM Identity Center ou Active Directory ont généralement leurs changements de rôle gérés par le biais des mappages de groupes de leur fournisseur d'identité externe. Si votre environnement utilise IAM Identity Center, la rétrogradation de rôle est effectuée en déplaçant l'utilisateur d'un groupe IdC vers un autre (par exemple, d'un groupe Quick-Admins vers un groupe Quick-Readers). Aucune séquence de rétrogradation progressive n'est nécessaire.

Bien que la console Amazon Quick ne fournisse pas de chemin de rétrogradation direct pour toutes les transitions de rôle (plus précisément, vous ne pouvez pas rétrograder d'Admin à Reader ni d'Author à Reader directement via l'interface de la console), deux solutions fiables existent : une méthode manuelle de suppression et de recréation, et une approche utilisant l'AWS Command Line Interface (AWS CLI). Nous vous présentons ces deux techniques pour vous aider à maintenir une gestion appropriée des accès à mesure que votre équipe évolue.

Prérequis

Avant de commencer, assurez-vous de disposer d'un compte AWS actif avec un accès administrateur à Amazon Quick. Si vous prévoyez d'utiliser la méthode CLI, vous devez avoir AWS CLI installé et configuré sur votre machine. Il est également utile de préparer une liste des utilisateurs dont les rôles doivent être modifiés.

Comprendre les rôles Amazon Quick

Amazon Quick propose deux niveaux d'abonnement avec des ensembles de rôles distincts :

La console ne fournit pas de moyen direct de rétrograder d'un niveau Author vers un niveau Reader. L' update-user API applique cette même contrainte, en rejetant les rétrogradations directes avec une erreur « You cannot downgrade a user role ».

La capture d'écran suivante montre la page de gestion des utilisateurs d'Amazon Quick Suite, où la console n'offre aucun contrôle direct pour faire passer un utilisateur d'un niveau Author à un niveau Reader. Cela illustre pourquoi les méthodes présentées dans cet article sont nécessaires.

Figure 1 : page de gestion des utilisateurs d'Amazon Quick Suite

La méthode de rétrogradation par étapes de la CLI fonctionne de manière fiable pour les rôles BI uniquement hérités (Admin, Author, Reader), selon la séquence suivante :

Admin > Author > Restricted Reader > Reader

Cette même séquence fonctionne également pour les utilisateurs Pro, tant que les étapes intermédiaires utilisent les rôles hérités. Par exemple, Author Pro > Author > Restricted Reader > Reader Pro se termine avec succès.

Considérations importantes avant d’apporter des modifications

Lors de la mise en œuvre de changements de rôle par l’une ou l’autre méthode, plusieurs facteurs importants sont à garder à l’esprit. Premièrement, vérifiez que tous les utilisateurs de votre liste sont actuellement des utilisateurs Admin ou Author avant d’apporter des modifications. Tenter de rétrograder des utilisateurs qui ont déjà des autorisations inférieures peut provoquer des erreurs. Les questions de propriété des ressources s’appliquent toujours, même en utilisant la méthode CLI. Les utilisateurs rétrogradés ne pourront plus modifier les ressources dont ils étaient précédemment propriétaires. Pour les grandes organisations utilisant la méthode CLI, envisagez de charger les adresses e-mail des utilisateurs depuis un fichier CSV plutôt que de les coder en dur. Si vous utilisez AWS CloudShell au lieu d’une installation CLI locale, vous pouvez omettre la spécification de la Région AWS, car AWS CloudShell utilise automatiquement le contexte de Région de votre console actuelle.

Transfert de la propriété des actifs (à faire en premier)

Avant de supprimer un utilisateur, il est essentiel de s’assurer que tous les actifs dont il est propriétaire, tels que les tableaux de bord, les jeux de données et les analyses, sont correctement réassignés. Cela évite les perturbations et empêche que des ressources restent orphelines. Si l’utilisateur est un Author, vérifiez s’il possède des jeux de données ou des tableaux de bord, et suivez les mêmes étapes de réassignation d’actifs décrites ici. Il existe trois principales façons de gérer le transfert de la propriété des actifs dans Amazon Quick.

Option 1 : Transfert proactif de la propriété à un autre administrateur

L’approche la plus contrôlée consiste à réassigner manuellement la propriété avant de supprimer l’utilisateur. Pour ce faire, accédez à chaque actif dans Quick, choisissez Share, et désignez un autre administrateur comme copropriétaire. Avec cette méthode, vous pouvez déterminer exactement qui prend en charge chaque ressource, ce qui est particulièrement utile pour les tableaux de bord ou les jeux de données à fort impact. Bien que cela puisse prendre du temps dans les environnements de grande taille, cela vous donne la flexibilité de distribuer les actifs selon la structure et les responsabilités de votre équipe.

La capture d’écran suivante montre la boîte de dialogue Share d’un actif, où vous ajoutez un autre administrateur comme copropriétaire afin que la propriété soit transférée avant que l’utilisateur d’origine ne soit supprimé.

Figure 2 : Transfert de la propriété d’un actif à un autre utilisateur

Option 2 : Utiliser le transfert groupé d’actifs d’Amazon Quick sur la page Admin

Si l’utilisateur possède de nombreux actifs, la méthode manuelle peut devenir inefficace. Dans ce cas, vous pouvez utiliser la fonctionnalité Manage assets disponible dans la section Admin de Quick. Avec cet outil, les administrateurs peuvent effectuer des transferts de propriété en masse ou mettre à jour les autorisations de partage pour plusieurs actifs à la fois. Cela simplifie considérablement le processus de réassignation, en particulier lors du départ d’utilisateurs ou de la gestion de changements organisationnels. Pour plus de détails sur l’utilisation de cette fonctionnalité, consultez la documentation officielle Managing assets in Amazon Quick .

Option 3 : Partager les actifs avec un groupe d’utilisateurs Quick

Une autre stratégie efficace consiste à partager les actifs avec un groupe d’utilisateurs. Pour les utilisateurs Quick Identity, vous pouvez créer un groupe Quick, y ajouter les membres pertinents de l’équipe, et partager des tableaux de bord ou des jeux de données avec le groupe plutôt qu’avec des utilisateurs individuels. Si votre compte est intégré à IAM Identity Center ou Active Directory, des groupes équivalents sont créés et gérés dans ces systèmes, et Quick utilise ces groupes externes pour le contrôle d’accès au lieu des groupes gérés par Quick. De cette façon, l’accès aux ressources partagées reste intact même si un utilisateur spécifique est supprimé. C’est une approche résiliente qui réduit le besoin de réassigner la propriété à l’avenir et aide à maintenir un accès cohérent au sein d’équipes en évolution.

Méthode manuelle : Suppression et recréation de l’utilisateur

Bien que ce ne soit pas l’approche la plus efficace, la méthode manuelle de suppression et de recréation est une option pour les environnements où l’utilisation de la CLI n’est pas possible. Cette méthode consiste à supprimer entièrement l’utilisateur administrateur, puis à le recréer avec des autorisations de lecteur. Cette même méthode manuelle s’applique également lors de la rétrogradation d’un Author en Reader, mais généralement avec moins de complications concernant la propriété des actifs.

Comme cette méthode nécessite de supprimer le compte utilisateur avant de le recréer avec un rôle inférieur, une préparation minutieuse est essentielle pour éviter de perdre des ressources précieuses et de perturber les flux de travail. Assurez-vous d’avoir effectué le transfert de la propriété des actifs décrit dans la section précédente avant de continuer.

Étape 1 : Supprimer l’utilisateur administrateur

Après avoir transféré la propriété de toutes les ressources, connectez-vous à la AWS Management Console et accédez au service Amazon Quick. À partir de là, choisissez l’icône de votre profil, puis choisissez Manage Quick, suivi de Manage users. Lorsque vous localisez l’utilisateur administrateur que vous souhaitez rétrograder, choisissez l’icône de suppression à côté de son nom et confirmez la suppression lorsque vous y êtes invité. Cela supprime complètement son accès actuel au système.

Si vous n’avez pas transféré toutes les ressources au préalable, Quick affiche une boîte de dialogue de transfert de propriété. Cette boîte de dialogue vous invite à sélectionner un autre administrateur qui recevra la propriété de toutes les ressources de l’utilisateur. Sélectionnez un administrateur approprié dans la liste, puis confirmez le transfert en choisissant Suppression et transfert. Ce mécanisme de transfert intégré permet d'éviter les ressources orphelines, mais transfère tout à un seul administrateur. Pour un contrôle plus granulaire, utilisez l'approche proactive mentionnée précédemment afin de répartir les ressources de manière stratégique entre les différents membres de l'équipe.

Si vous avez sauté le transfert proactif, la boîte de dialogue de suppression présentée dans la figure suivante vous permet de réaffecter toutes les ressources de l'utilisateur à un seul administrateur avant la suppression du compte.

Figure 3 : Transfert intégré des ressources lors de la suppression d'un utilisateur

Étape 2 : Recréer l'utilisateur avec le rôle Reader

Après avoir supprimé l'utilisateur avec succès, restez sur la page Users (Utilisateurs) et choisissez Invite users. Saisissez l'adresse e-mail de l'utilisateur et sélectionnez le rôle Reader parmi les options disponibles. Envoyez l'invitation pour permettre à l'utilisateur de rejoindre à nouveau Quick avec ses nouvelles autorisations plus restreintes.

Étape 3 : vérifier le changement de rôle

Après que l'utilisateur a accepté l'invitation :

• Confirmez que ses autorisations ont été mises à jour en Reader.
• Vérifiez qu'il ne peut consulter que les tableaux de bord et les rapports.
• Confirmez qu'il ne peut pas modifier ni créer de contenu.

Méthode CLI : transition de rôle par étapes (recommandée)

Si vous préférez utiliser l'AWS CLI ou AWS CloudShell, vous pouvez modifier le rôle de l'utilisateur de manière programmatique. Comme Quick exige que les changements de rôle soient effectués dans une séquence spécifique, vous ne pouvez pas passer directement d'un rôle Admin à un rôle Reader. Vous devez plutôt passer par des rôles intermédiaires.

Remarques importantes

• Remplacez <your-account-id> par l'ID de votre compte AWS.
• Remplacez <user-name> par le nom d'utilisateur de l'utilisateur.
• Remplacez <user-email> par l'adresse e-mail de l'utilisateur.
• Si vous utilisez l'AWS CLI en dehors de CloudShell, spécifiez le paramètre --region .
• La valeur --role doit correspondre exactement au nom de rôle de l'API (voir le tableau précédent).

Exemple : parcours hérité (Admin vers Reader)

Étape 1 : Changer le rôle d'Admin en Author :

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

Étape 2 : Mettre à jour le rôle d'Author en Restricted Reader :

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

Étape 3 : Changer le rôle de Restricted Reader en Reader :

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

Après le déclassement : examiner les profils de limites et les autorisations personnalisées

Les changements de rôle n’ajustent pas automatiquement les Limit Profiles ni les profils Custom Permissions. Les deux persistent indépendamment du rôle de l’utilisateur, et vous devriez les examiner après toute rétrogradation.

• Les Limit Profiles contrôlent les plafonds par utilisateur sur des ressources telles que le stockage d’index et les heures d’agent. Si le rétrogradé s’est vu attribuer un profil adapté à son précédent rôle d’Admin ou d’Author, réattribuez un profil de limite adapté à un Reader afin d’éviter une sur-allocation des ressources. Consultez la documentation des Limit Profiles pour plus de détails.
• Les Custom Permissions restreignent des capacités spécifiques au sein d’un niveau de rôle. Un profil attribué à un Author peut ne pas se comporter comme prévu sur un Reader. Soit vous le retirez lors de la dernière étape CLI (en utilisant --unapply-custom-permissions), soit vous attribuez un profil conçu pour le niveau Reader.

Script pour mettre à jour plusieurs utilisateurs

Utilisez le script suivant pour mettre à jour plusieurs utilisateurs.

#!/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!"

Fonctionnalité du script

Ce script effectue les opérations suivantes :

• Il lit les noms d’utilisateur et les adresses e-mail à partir d’un fichier externe (prend en charge les commentaires avec #).
• Il met à jour le rôle en trois étapes : Admin > Author > Restricted Reader > Reader.
• La gestion des erreurs arrête la transition d’un utilisateur si une étape échoue.
• Les commandes sleep laissent le temps aux changements de prendre effet.

Quelques points à garder à l’esprit lors de l’exécution du script :

• Confirmez que les utilisateurs sont actuellement des utilisateurs Admin ou Author avant de lancer le script.
• Utilisez le nom d'utilisateur Quick réel, qui peut différer du préfixe de l'e-mail dans les environnements fédérés.
• Aucune spécification de Région n'est nécessaire dans AWS CloudShell.
• Vous pouvez modifier le script pour charger les utilisateurs à partir d'un export CSV de list-users.

Bonnes pratiques pour la gestion des accès des utilisateurs

Pour maintenir votre environnement Quick sécurisé et bien organisé, suivez ces bonnes pratiques :

• Examinez régulièrement les rôles des utilisateurs (audits mensuels ou trimestriels).
• Transférez la propriété des ressources avant de modifier les rôles.
• Suivez le principe du moindre privilège.
• Utilisez les profils Custom Permissions pour un contrôle précis au sein d'un niveau de rôle.
• Partagez les ressources avec des groupes plutôt qu'avec des individus pour plus de résilience.
• Utilisez AWS Identity and Access Management pour des limites d'autorisations supplémentaires.

Nettoyage

Après avoir effectué les changements de rôles des utilisateurs :

• Supprimez tous les utilisateurs de test.
• Vérifiez qu'aucune ressource involontaire ne subsiste.
• Supprimez les scripts CLI temporaires ou les fichiers de listes d'utilisateurs.
• Vérifiez une dernière fois les autorisations finales des utilisateurs.

Conclusion

Dans cet article, nous avons exploré deux méthodes pour rétrograder les rôles des utilisateurs dans Amazon Quick : la suppression et la recréation manuelles, et une approche flexible avec l'AWS CLI. Ces stratégies vous aident à gérer les accès de votre équipe de manière efficace et sécurisée.

Pour les environnements utilisant IAM Identity Center, les changements de rôles sont gérés via la réaffectation des groupes IdC, ce qui ne nécessite pas la séquence de rétrogradation décrite ici. Pour des contrôles de gouvernance supplémentaires, explorez Custom Permissions pour des restrictions au niveau des fonctionnalités et Restricted Folders pour un isolement au niveau du contenu.

Ressources

• Gestion de l'accès des utilisateurs dans Amazon Quick
• Gestion des actifs dans Amazon Quick
• Profils Custom Permissions
• Bonnes pratiques AWS IAM
• AWS Business Intelligence Blog

Nous serions ravis de connaître vos expériences en matière de gestion des utilisateurs. Comment votre organisation gère-t-elle les transitions de rôles dans Quick Suite ? Avez-vous développé des scripts ou des processus personnalisés pour simplifier ces changements ? Partagez vos réflexions et vos défis dans les commentaires.

À propos de l'auteur