Définition des rôles de base de données à accorder aux utilisateurs fédérés dans Amazon Redshift sans serveur

PDFRSS

Lorsque vous faites partie d’une organisation, vous avez un ensemble de rôles associés. Par exemple, vous avez des rôles liés à votre fonction, comme programmeur et responsable. Vos rôles déterminent les applications et les données auxquelles vous avez accès. La plupart des organisations utilisent un fournisseur d’identité, tel que Microsoft Active Directory, pour attribuer des rôles aux utilisateurs et aux groupes. L’utilisation des rôles pour contrôler l’accès aux ressources s’est développée, car les organisations n’ont plus à gérer autant d’utilisateurs individuels.

Récemment, le contrôle d’accès basé sur les rôles a été introduit dans Amazon Redshift sans serveur. Les rôles de base de données vous permettent de sécuriser l’accès aux données et aux objets, tels que les schémas ou les tables, par exemple. Vous pouvez également utiliser les rôles pour définir un ensemble d’autorisations élevées, par exemple pour un moniteur système ou un administrateur de base de données. Mais après avoir accordé des autorisations de ressources aux rôles de la base de données, il y a une étape supplémentaire qui consiste à connecter les rôles d’un utilisateur de l’organisation aux rôles de la base de données. Vous pouvez affecter chaque utilisateur à son rôle dans la base de données lors de la première connexion en exécutant des instructions SQL, mais cela demande beaucoup d’efforts. Un moyen plus simple consiste à définir les rôles de base de données à accorder et à les transmettre à Amazon Redshift sans serveur. Cela a l’avantage de simplifier la procédure d’inscription initiale.

Vous pouvez transmettre des rôles à Amazon Redshift sans serveur à l’aide de GetCredentials. Lorsqu’un utilisateur se connecte pour la première fois à une base de données Amazon Redshift sans serveur, un utilisateur de base de données associé est créé et mappé aux rôles de base de données correspondants. Cette rubrique détaille le mécanisme de transmission des rôles à Amazon Redshift sans serveur.

La transmission des rôles de la base de données a deux utilisations principales :

• Lorsqu’un utilisateur se connecte par l’intermédiaire d’un fournisseur d’identité tiers, généralement avec une fédération configurée, et transmet les rôles au moyen d’une balise de session.

• Lorsqu’un utilisateur s’identifie à l’aide des informations d’identification d’IAM, ses rôles sont transmis au moyen d’une clé et d’une valeur de balise.

Pour plus d’informations sur le contrôle d’accès basé sur les rôles, consultez Contrôle d’accès basé sur les rôles (RBAC).

Définition des rôles de base de données

Avant de pouvoir transmettre des rôles à Amazon Redshift sans serveur, vous devez configurer des rôles de base de données dans votre base de données et leur accorder les autorisations appropriées sur les ressources de la base de données. Par exemple, dans un scénario simple, vous pouvez créer un rôle de base de données appelé ventes et lui accorder l’accès aux tables de requêtes contenant des données sur les ventes. Pour plus d’informations sur la création de rôles de base de données et l’octroi d’autorisations, consultez CREATE ROLE et GRANT.

Cas d’utilisation pour définir les rôles de base de données à accorder aux utilisateurs fédérés

Ces sections présentent quelques cas d’utilisation où le fait de transmettre des rôles de base de données à Amazon Redshift sans serveur peut simplifier l’accès aux ressources de la base de données.

Connexion à l’aide d’un fournisseur d’identité

Le premier cas d’utilisation suppose que votre organisation dispose d’identités d’utilisateurs dans un service de gestion des identités et des accès. Ce service peut être basé sur le cloud, par exemple JumpCloud ou Okta, ou sur site, tel que Microsoft Active Directory. L’objectif est de faire correspondre automatiquement les rôles d’un utilisateur du fournisseur d’identité aux rôles de votre base de données lorsqu’il se connecte à un client tel que l’éditeur de requête V2, par exemple, ou à un client JDBC. Pour ce faire, vous devez effectuer quelques tâches de configuration. Tel est le cas des éléments suivants :

1. Configurez l’intégration fédérée avec votre fournisseur d’identité (IdP) à l’aide d’une relation de confiance. Il s’agit d’un prérequis. Lorsque vous configurez cette option, le fournisseur d’identité est chargé d’authentifier l’utilisateur au moyen d’une assertion SAML et de fournir des informations d’identification de connexion. Pour plus d'informations, consultez la section Intégration de fournisseurs de solutions SAML tiers avec AWS. Vous trouverez également plus d’informations sur le blog Fédérer l’accès à l’éditeur de requêtes Amazon Redshift v2 avec Active Directory Federation Services (AD FS) ou Fédérer l’accès à authentification unique à l’éditeur de requêtes Amazon Redshift v2 avec Okta.

2. L’utilisateur doit disposer des autorisations suivantes en matière de politique :

   • GetCredentials : fournit des informations d’identification pour une autorisation temporaire de connexion à Amazon Redshift sans serveur.

   • sts:AssumeRoleWithSAML— Fournit un mécanisme permettant de lier une banque d'identités ou un répertoire d'entreprise à un accès basé sur les rôles AWS .

   • sts:TagSession : autorisation pour l’action balise relative au principal du fournisseur d’identité.

   Dans ce cas, AssumeRoleWithSAML renvoie un ensemble d’informations d’identification de sécurité pour les utilisateurs qui ont été authentifiés via une réponse SAML authentifiée. Cette opération fournit un mécanisme permettant de lier une banque d'identités ou un répertoire à un AWS accès basé sur les rôles sans informations d'identification spécifiques à l'utilisateur. Pour les utilisateurs ayant l’autorisation à AssumeRoleWithSAML, le fournisseur d’identité est responsable de la gestion de l’assertion SAML utilisée pour transmettre les informations relatives au rôle.

   Il est recommandé d’associer des politiques d’autorisation à un rôle IAM, puis de l’attribuer à des utilisateurs et à des groupes, le cas échéant. Pour plus d’informations, consultez Identity and Access Management dans Amazon Redshift.

3. Vous configurez la balise RedshiftDbRoles avec les valeurs de rôle séparées par deux points, dans le format role1:role2. Par exemple, manager:engineer. Vous pouvez les récupérer à partir d’une mise en œuvre de balisage de session configurée dans votre fournisseur d’identité. La demande d’authentification SAML transmet les rôles par programmation. Pour plus d’informations sur la transmission des balises de session, consultez Transmission des balises de session dans AWS STS.

   Si vous transmettez un nom de rôle qui n’existe pas dans la base de données, il est ignoré.

Dans ce cas d’utilisation, lorsqu’un utilisateur se connecte à l’aide d’une identité fédérée, ses rôles sont transmis dans la demande d’autorisation par le biais de la clé et de la valeur de la balise de session. Ensuite, après autorisation, GetCredentials transmet les rôles à la base de données. Lorsque la connexion est établie, les rôles de la base de données sont mappés et l’utilisateur peut effectuer les tâches de la base de données correspondant à son rôle. L’essentiel de l’opération consiste à attribuer à la balise de la session RedshiftDbRoles les rôles prévus dans la demande d’autorisation initiale. Pour plus d'informations sur la transmission de balises de session, consultez la section Transmission de balises de session à l'aide de AssumeRoleWith SAML.

Connexion à l’aide des informations d’identification IAM

Dans le deuxième cas d’utilisation, des rôles peuvent être attribués à un utilisateur et celui-ci peut accéder à une application client de base de données par le biais d’informations d’identification IAM.

1. L’utilisateur qui se connecte dans ce cas doit se voir attribuer des autorisations de politique pour les actions suivantes :

   • tag:GetResources : renvoie les ressources balisées associées aux balises spécifiées.

   • tag:GetTagKeys : renvoie les balises en cours d’utilisation.

     Il est recommandé d’associer des politiques d’autorisation à un rôle IAM, puis de l’attribuer à des utilisateurs et à des groupes, le cas échéant. Pour plus d’informations, consultez Identity and Access Management dans Amazon Redshift.

2. Des autorisations sont également nécessaires pour accéder au service de base de données, comme Amazon Redshift sans serveur.

3. Pour ce cas d’utilisation, configurez les valeurs de balisage pour vos rôles dans AWS Identity and Access Management. Vous pouvez choisir de modifier les balises et de créer une clé de balise appelée RedshiftDbRolesaccompagnée d'une chaîne de valeur de balise contenant les rôles. Par exemple, manager:engineer.

Lorsqu’un utilisateur se connecte, son rôle est ajouté à la demande d’autorisation et transmis à la base de données. Il est mappé à un rôle de base de données existant.

Ressources supplémentaires

Comme indiqué dans les cas d’utilisation, vous pouvez configurer la relation de confiance entre votre IdP et AWS. Pour plus d’informations, consultez Configuration de votre IdP SAML 2.0 à l’aide d’une relation d’approbation des parties utilisatrices et ajout de demandes.