Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Contrôle d'accès basé sur les rôles (RBAC)

Au lieu d'authentifier les utilisateurs avec la commande Valkey et Redis OSS AUTH comme décrit dans Valkey 7.2 et versions ultérieures et Redis OSS 6.0 et versions ultérieuresAuthentification avec la commande Valkey et Redis OSS AUTH, vous pouvez utiliser une fonctionnalité appelée contrôle d'accès basé sur les rôles (RBAC). Le RBAC est également le seul moyen de contrôler l’accès aux caches sans serveur.

Contrairement à Valkey et Redis OSS AUTH, où tous les clients authentifiés ont un accès complet au cache si leur jeton est authentifié, le RBAC vous permet de contrôler l'accès au cache par le biais de groupes d'utilisateurs. Ces groupes d’utilisateurs sont conçus comme un moyen d’organiser l’accès aux caches.

Avec RBAC, vous créez des utilisateurs et leur attribuez des autorisations spécifiques à l'aide d'une chaîne d'accès, comme décrit ci-dessous. Vous assignez les utilisateurs à des groupes d'utilisateurs correspondant à un rôle spécifique (administrateurs, ressources humaines) qui sont ensuite déployés dans un ou plusieurs ElastiCache caches. Ce faisant, vous pouvez établir des limites de sécurité entre les clients utilisant le ou les mêmes caches Valkey ou Redis OSS et empêcher les clients d'accéder aux données des autres.

Le RBAC est conçu pour prendre en charge l'introduction de l'ACL dans Redis OSS 6. Lorsque vous utilisez RBAC avec votre cache ElastiCache Valkey ou Redis OSS, certaines limites s'appliquent :

L'utilisation de RBAC avec ElastiCache pour Redis OSS est décrite plus en détail ci-dessous.

Définition des autorisations à l'aide d'une chaîne d'accès

Pour spécifier les autorisations d'accès à un ElastiCache cache Redis OSS, vous créez une chaîne d'accès et vous l'attribuez à un utilisateur en utilisant le AWS CLI ou AWS Management Console.

Les chaînes d'accès sont définies comme une liste de règles délimitées par des espaces qui sont appliquées à l'utilisateur. Elles définissent les commandes qu'un utilisateur peut exécuter et les clés qu'un utilisateur peut utiliser. Pour exécuter une commande, un utilisateur doit avoir accès à la commande en cours d'exécution et à toutes les clés accessibles par la commande. Les règles sont appliquées de gauche à droite de manière cumulative, et une chaîne plus simple peut être utilisée à la place de celle fournie s'il y a des redondances dans la chaîne fournie.

Pour plus d'informations sur la syntaxe des règles de liste ACL, veuillez consulter Listes ACL.

Dans l'exemple suivant, la chaîne d'accès représente un utilisateur actif ayant accès à toutes les clés et commandes disponibles.

on ~* +@all

La syntaxe de la chaîne d'accès se décompose comme suit :

Les paramètres précédents sont les moins restrictifs. Vous pouvez modifier ces paramètres pour les rendre plus sécurisés.

Dans l'exemple suivant, la chaîne d'accès représente un utilisateur dont l'accès est restreint à l'accès en lecture sur les clés commençant par un keyspace « app:: »

on ~app::* -@all +@read

Vous pouvez affiner ces autorisations en listant les commandes auxquelles l'utilisateur a accès :

+command1 : l'accès de l'utilisateur aux commandes est limité à command1.

+@category : l'accès de l'utilisateur est limité à une catégorie de commandes.

Pour plus d'informations sur l'attribution d'une chaîne d'accès à un utilisateur, veuillez consulter Création d'utilisateurs et de groupes d'utilisateurs avec la console et la CLI.

Si vous migrez une charge de travail existante vers ElastiCache, vous pouvez récupérer la chaîne d'accès en appelantACL LIST, en excluant l'utilisateur et tout hachage de mot de passe.

Pour Redis OSS version 6.2 et versions ultérieures, la syntaxe de chaîne d'accès suivante est également prise en charge :

Pour Redis OSS version 7.0 et supérieure, la syntaxe de chaîne d'accès suivante est également prise en charge :

Appliquer le RBAC à un cache ElastiCache pour Valkey ou Redis OSS

ElastiCache Pour l'utiliser pour Valkey ou Redis OSS RBAC, vous devez suivre les étapes suivantes :

Ces étapes sont décrites en détail ci-dessous.

Création d'utilisateurs et de groupes d'utilisateurs avec la console et la CLI

Les informations utilisateur pour les utilisateurs RBAC sont un ID utilisateur, un nom d'utilisateur et éventuellement un mot de passe et une chaîne d'accès. La chaîne d'accès fournit le niveau d'autorisation relatif aux clés et commandes. L'ID utilisateur est unique à l'utilisateur, et le nom d'utilisateur est celui qui est transmis au moteur.

Assurez-vous que les autorisations d'utilisateur que vous fournissez correspondent à l'objectif visé du groupe d'utilisateurs. Par exemple, si vous créez un groupe d'utilisateurs appelé Administrators, tout utilisateur que vous ajoutez à ce groupe doit avoir sa chaîne d'accès définie pour un accès complet aux clés et aux commandes. Pour les utilisateurs d'un groupe d'utilisateurs e-commerce, vous pouvez définir leurs chaînes d'accès en lecture seule.

ElastiCache configure automatiquement un utilisateur par défaut avec son ID utilisateur et son nom d'utilisateur "default" et l'ajoute à tous les groupes d'utilisateurs. Vous ne pouvez pas le supprimer ou le modifier. Cet utilisateur est destiné à être compatible avec le comportement par défaut des versions précédentes de Redis OSS et dispose d'une chaîne d'accès qui lui permet d'appeler toutes les commandes et d'accéder à toutes les touches.

Pour ajouter un contrôle d’accès approprié à un cache, remplacez cet utilisateur par défaut par un nouvel utilisateur qui n’est pas activé ou qui utilise un mot de passe fort. Pour modifier l'utilisateur par défaut, créez un nouvel utilisateur avec le nom d'utilisateur défini sur default. Vous pouvez ensuite l'échanger avec l'utilisateur par défaut d'origine.

Les procédures suivantes montrent comment échanger l'utilisateur default d'origine avec un autre utilisateur default qui a une chaîne d'accès modifiée.

Lors de la création d'un utilisateur, vous pouvez configurer jusqu'à deux mots de passe. Lorsque vous modifiez un mot de passe, toutes les connexions existantes aux caches sont maintenues.

Tenez compte en particulier de ces contraintes liées au mot de passe utilisateur lorsque vous utilisez RBAC ElastiCache pour Redis OSS :

Gestion des utilisateurs avec la console et la CLI

Utilisez la procédure suivante pour gérer les utilisateurs sur la console.

Utilisez les procédures suivantes pour gérer les utilisateurs avec l' AWS CLI.

Pour afficher une liste des utilisateurs, appelez l'opération describe-users.

aws elasticache describe-users

Gestion des groupes d'utilisateurs avec la console et la CLI

Vous pouvez créer des groupes d’utilisateurs pour organiser et contrôler l’accès des utilisateurs à un ou plusieurs caches, comme indiqué ci-dessous.

Utilisez la procédure suivante pour gérer des groupes d'utilisateurs à l'aide de la console.

Utilisez les procédures suivantes pour gérer des groupes d'utilisateurs à l'aide de la CLI.

Pour voir la liste des groupes d'utilisateurs, vous pouvez appeler l'describe-user-groupsopération.

aws elasticache describe-user-groups \
  --user-group-id test-group

Attribution de groupes d’utilisateurs à des caches sans serveur

Après avoir créé un groupe d’utilisateurs et ajouté des utilisateurs, la dernière étape de la mise en œuvre du RBAC consiste à attribuer le groupe d’utilisateurs à un cache sans serveur.

Attribution de groupes d’utilisateurs à des caches sans serveur à l’aide de la console

Pour ajouter un groupe d'utilisateurs à un cache sans serveur à l'aide du AWS Management Console, procédez comme suit :

Affectation de groupes d'utilisateurs à des caches sans serveur à l'aide du AWS CLI

L' AWS CLI opération suivante crée un cache sans serveur en utilisant le user-group-id paramètre avec la valeurmy-user-group-id. Remplacez le groupe de sous-réseaux sng-test par un groupe de sous-réseaux existant.

Pour Linux, macOS ou Unix :

aws elasticache create-serverless-cache \
    --serverless-cache-name "new-serverless-cache" \
    --description "new-serverless-cache" \
    --engine "redis" \
    --user-group-id "new-group-1"

Pour Windows :

aws elasticache create-serverless-cache ^
    --serverless-cache-name "new-serverless-cache" ^
    --description "new-serverless-cache" ^
    --engine "redis" ^
    --user-group-id "new-group-1"

L' AWS CLI opération suivante modifie un cache sans serveur avec le user-group-id paramètre associé à la valeur. my-user-group-id

Pour Linux, macOS ou Unix :

aws elasticache modify-serverless-cache \
    --serverless-cache-name serverless-cache-1 \
    --user-group-id "new-group-2"

Pour Windows :

aws elasticache modify-serverless-cache ^
    --serverless-cache-name serverless-cache-1 ^
    --user-group-id "new-group-2"

Notez que les modifications apportées à un cache sont mises à jour de manière asynchrone. Vous pouvez surveiller cette progression en consultant les événements. Pour de plus amples informations, veuillez consulter Affichage des ElastiCache événements.

Attribution de groupes d'utilisateurs à des groupes de réplication

Après avoir créé un groupe d'utilisateurs et ajouté des utilisateurs, la dernière étape de la mise en œuvre de RBAC consiste à attribuer le groupe d'utilisateurs à un groupe de réplication.

Attribution de groupes d'utilisateurs à des groupes de réplication à l'aide de la console

Pour ajouter un groupe d'utilisateurs à une réplication à l'aide du AWS Management Console, procédez comme suit :

Affectation de groupes d'utilisateurs à des groupes de réplication à l'aide du AWS CLI

L' AWS CLI opération suivante crée un groupe de réplication avec le chiffrement en transit (TLS) activé et le user-group-ids paramètre avec la valeurmy-user-group-id. Remplacez le groupe de sous-réseaux sng-test par un groupe de sous-réseaux existant.

Pour Linux, macOS ou Unix :

aws elasticache create-replication-group \
    --replication-group-id "new-replication-group" \
    --replication-group-description "new-replication-group" \
    --engine "redis" \
    --cache-node-type cache.m5.large \
    --transit-encryption-enabled \
    --user-group-ids "new-group-1" \
    --cache-subnet-group "cache-subnet-group"

Pour Windows :

aws elasticache create-replication-group ^
    --replication-group-id "new-replication-group" ^
    --replication-group-description "new-replication-group" ^
    --engine "redis" ^
    --cache-node-type cache.m5.large ^
    --transit-encryption-enabled ^
    --user-group-ids "new-group-1" ^
    --cache-subnet-group "cache-subnet-group"

L' AWS CLI opération suivante modifie un groupe de réplication avec le chiffrement en transit (TLS) activé et le user-group-ids paramètre avec la valeur. my-user-group-id

Pour Linux, macOS ou Unix :

aws elasticache modify-replication-group \
    --replication-group-id replication-group-1 \
    --user-group-ids-to-remove "new-group-1" \
    --user-group-ids-to-add "new-group-2"

Pour Windows :

aws elasticache modify-replication-group ^
    --replication-group-id replication-group-1 ^
    --user-group-ids-to-remove "new-group-1" ^
    --user-group-ids-to-add "new-group-2"

Notez le PendingChanges dans la réponse. Toutes les modifications apportées à un cache sont mises à jour de manière asynchrone. Vous pouvez surveiller cette progression en consultant les événements. Pour de plus amples informations, veuillez consulter Affichage des ElastiCache événements.

Migration d'AUTH vers RBAC

Si vous utilisez AUTH comme décrit dans Authentification avec la commande Valkey et Redis OSS AUTH et que vous souhaitez migrer vers le RBAC, suivez les procédures suivantes.

Utilisez la procédure suivante pour migrer d'AUTH vers RBAC à l'aide de la console.

Utilisez la procédure suivante pour migrer de Valkey ou Redis OSS AUTH vers RBAC à l'aide de la CLI.

Migration de RBAC vers AUTH

Si vous utilisez RBAC et souhaitez migrer vers Redis OSS AUTH, consultez. Migration de RBAC vers AUTH