Dans le premier article de cette série, Fédérer l'accès à votre cluster Amazon Redshift avec Active Directory Federation Services (AD FS) : Partie 1, vous avez configuré l'authentification basée sur Microsoft Active Directory Federation Services (AD FS) et SAML (Security Assertion Markup Language) et testé la fédération SAML à l'aide d'un navigateur Web.
In Partie 2, vous avez appris à mettre en place un Redshift d'Amazon cluster et utilisez l'authentification fédérée avec AD FS pour vous connecter à partir d'un outil client JDBC SQL.
Dans cet article, nous passons en revue les étapes de configuration Éditeur de requête Amazon Redshift v2 pour travailler avec la fédération AD FS SSO.
Les organisations souhaitent permettre à leurs utilisateurs finaux tels que les analystes de données, les scientifiques des données et les développeurs de bases de données d'utiliser l'éditeur de requête v2 pour accélérer l'analyse en libre-service. L'éditeur de requêtes Amazon Redshift v2 permet aux utilisateurs d'explorer, d'analyser et de collaborer sur des données. Vous pouvez utiliser l'éditeur de requête pour créer des bases de données, des schémas, des tables et charger des données à partir d'Amazon Simple Storage Service (Amazon S3) à l'aide de la commande COPY ou d'un assistant. Vous pouvez parcourir plusieurs bases de données et exécuter des requêtes sur votre entrepôt de données ou lac de données Amazon Redshift, ou exécuter des requêtes fédérées sur des bases de données opérationnelles telles que Amazon Aurora.
Dans cet article, nous montrons comment vous pouvez utiliser votre Active Directory (AD) d'entreprise et le fournisseur d'identité SAML 2.0 AD FS (IdP) pour permettre à vos utilisateurs d'accéder facilement aux clusters Amazon Redshift via l'éditeur de requête v2 en utilisant des noms d'utilisateur d'entreprise sans gérer les utilisateurs de la base de données. et mots de passe. Nous montrons également comment vous pouvez limiter l'accès de vos utilisateurs à utiliser uniquement l'éditeur de requête sans leur donner accès pour effectuer des fonctions d'administration sur le Console de gestion AWS.
Vue d'ensemble de la solution
Après avoir suivi les étapes expliquées dans Partie 1, vous configurez un lien profond pour les utilisateurs fédérés via SAML 2.0 RelayState
paramètre dans AD FS. Vous utilisez l'utilisateur que vous avez configuré dans votre AD dans la partie 1 (Bob
) pour s'authentifier à l'aide d'AD FS et contrôler l'accès aux objets de la base de données en fonction du groupe auquel l'utilisateur est affecté. Vous testez également si l'utilisateur Bob
est intégré aux groupes de bases de données Amazon Redshift tels qu'ils sont contrôlés dans les groupes AD.
À la fin de cet article, vous aurez créé un lien profond unique qui authentifie l'utilisateur Bob
à l'aide d'AD FS et les redirige directement vers la console de l'éditeur de requête v2, où ils sont authentifiés à l'aide de l'option SSO de fédération.
Le processus de connexion est le suivant :
- L'utilisateur choisit un lien profond qui redirige vers l'IdP pour l'authentification avec les informations sur l'URL de destination (éditeur de requête v2, dans notre cas) intégré dans le
RelayState
paramètre. L'utilisateur saisit ses informations d'identification sur la page de connexion. - Votre fournisseur d'identité (AD FS dans le cas) vérifie l'identité de l'utilisateur dans votre organisation.
- Votre IdP génère une réponse d'authentification SAML qui inclut des assertions qui identifient l'utilisateur et des attributs sur l'utilisateur. L'IdP envoie cette réponse au navigateur de l'utilisateur.
- Le navigateur de l'utilisateur est redirigé vers le Authentification unique AWS point de terminaison et publie l'assertion SAML et le
RelayState
paramètre. - Le point de terminaison appelle le
AssumeRoleWithSAML
Action d'API pour demander des informations d'identification temporaires au Gestion des identités et des accès AWS (IAM) spécifié dans l'assertion SAML et crée une URL de connexion à la console v2 de l'éditeur de requête qui utilise ces informations d'identification. Le rôle IAM fait confiance à l'entité de fédération SAML et dispose également d'une stratégie qui a accès à l'éditeur de requête V2. Si la réponse d'authentification SAML inclut des attributs qui correspondent à plusieurs rôles IAM, l'utilisateur est d'abord invité à choisir le rôle à utiliser pour accéder à la console de l'éditeur de requête v2. L'URL de connexion est celle spécifiée par leRelayState
paramètre. - AWS renvoie l'URL de connexion au navigateur de l'utilisateur en tant que redirection.
- Le navigateur de l'utilisateur est redirigé vers la console de l'éditeur de requêtes Amazon Redshift v2 définie par le
RelayState
paramètre.
Le schéma suivant illustre ce flux.
Dans cet article, nous vous expliquons les étapes suivantes :
- Mettre en place le
Sales
groupe dans AD et configurer lePrincipalTag
règles de revendication dans AD FS. - Mettez à jour les rôles IAM.
- Créez l'URL SSO pour authentifier et rediriger les utilisateurs vers la console v2 de l'éditeur de requête Amazon Redshift.
- Configurer la base de données Amazon Redshift groupes et les autorisations sur le cluster Amazon Redshift.
- Configurez l'éditeur de requête Amazon Redshift v2 pour utiliser l'authentification fédérée avec AD FS pour vous connecter directement à partir de l'interface de l'éditeur de requête.
- Interrogez les objets Amazon Redshift pour valider votre autorisation.
Pré-requis
Pour cette procédure pas à pas, effectuez les étapes préalables suivantes :
- Créez un cluster Amazon Redshift. Pour obtenir des instructions, reportez-vous à Créer un exemple de cluster Amazon Redshift ou suivez les étapes de Partie 2 de cette série.
- Suivez les étapes de Partie 1 pour configurer la fédération SAML avec AD FS :
- Configurer un contrôleur de domaine AD à l'aide d'un AWS CloudFormation modèle sur un Windows 2016 Cloud de calcul élastique Amazon (Amazon EC2).
- Configurez la fédération dans AD FS.
- Configurez AWS en tant que partie de confiance avec AD FS à l'aide d'un fournisseur IAM SAML et de rôles SAML avec une stratégie attachée pour autoriser l'accès au cluster Amazon Redshift.
- Configurez les règles de revendication.
- Testez l'authentification SAML à l'aide d'un navigateur Web.
- Vérifiez que votre fournisseur d'identité prend en charge
RelayState
et est activé. Si vous utilisez AD FS 2.0, vous devez télécharger et installer soit Mettre à jour le Rollup 3 or Mettre à jour le Rollup 2 de Microsoft pour activer leRelayState
paramètre.
Configurer AD et AD FS
Après avoir configuré vos services AD FS et AD en suivant les instructions de Partie 1, vous pouvez configurer le groupe AD et les règles de revendication suivants.
Dans ce post, vous utilisez l'utilisateur Bob
pour vous connecter à Amazon Redshift et vérifier si Bob
peut accéder au Sales
et Marketing
schémas sur le cluster Amazon Redshift. Pour créer le sales
groupe et assigne l'utilisateur Bob@adfsredshift.com
connectez-vous à votre serveur AD FS (machine Amazon EC2) que vous avez créé dans la partie 1 et utilisez l'outil de commande Windows pour exécuter la commande suivante :
Vous êtes maintenant prêt à créer vos règles de revendication personnalisées : PrincipalTag:RedshiftDbUser
et PrincipalTag:RedshiftDbGroup
.
Balise principale : RedshiftDbUser
La règle de revendication personnalisée PrincipalTag:RedshiftDbUser
est mappé au nom de principal universel dans AD FS. Lorsqu'un utilisateur s'authentifie via SSO fédéré, cette règle de réclamation est mappée au nom d'utilisateur. Si l'utilisateur n'existe pas dans la base de données Amazon Redshift, l'utilisateur est automatiquement créé. L'option de création automatique est accordée via une stratégie IAM attachée au rôle IAM. Le CreateClusterUser
l'autorisation permet la création automatique de l'utilisateur (vous configurez cela dans le cadre de la partie 1 en tant que prérequis).
Procédez comme suit pour créer votre règle de revendication personnalisée :
-
- Sur la console de gestion AD FS, choisissez Invoquant Trusts Partie.
- Selectionnez Modifier la politique d'émission de réclamation.
- Selectionnez Choisissez le type de règle.
- Pour Modèle de règle de revendication, choisissez Envoyer des réclamations à l'aide d'une règle personnalisée.
- Selectionnez Suivant.
- Pour Nom de la règle de revendications, Entrer
RedshiftDbUser
. - Ajoutez la règle personnalisée suivante :
- Selectionnez Finition.
- Capturez les règles de revendication envoyées dans une réponse d'assertion SAML via votre navigateur. Pour obtenir des instructions, reportez-vous à Comment afficher une réponse SAML dans votre navigateur pour le dépannage.
Dans mon exemple, j'utilise l'attribut SAML suivant pour le RedshiftDbUser PrincipalTag
:
Balise principale : RedshiftDbGroup
La règle de revendication personnalisée PrincipalTag:RedshiftDbGroup
est construit à partir de groupes AD dont l'utilisateur est membre. Cette règle est mappée aux groupes de bases de données Amazon Redshift. Les groupes AD et les noms de groupe de base de données Amazon Redshift doivent correspondre. JoinGroup
l'autorisation définie dans la stratégie IAM permet à l'utilisateur d'assumer un groupe de bases de données et est basée sur la session. Si l'utilisateur est mappé à plusieurs groupes dans le groupe AD, la réponse d'assertion SAML doit envoyer ces groupes dans : des valeurs séparées et non comme des revendications de valeurs multiples. Les étapes suivantes montrent comment envoyer des groupes AD en tant que : valeurs séparées.
Dans cet exemple, l'utilisateur Bob
est assigné au marketing
et sales
groupes. Le code suivant montre comment envoyer plusieurs groupes via la réponse SAML lorsque l'utilisateur se trouve dans plusieurs groupes, et également comment gérer la situation lorsqu'un utilisateur n'existe pas dans un groupe particulier.
- Suivez les mêmes étapes que dans la section précédente pour créer la règle
Marketing
, en utilisant le code suivant pour la règle personnalisée : - Créer la règle
MarketingNotExists
en utilisant le code suivant : - Créer la règle
sales
en utilisant le code suivant : - Créer la règle
SalesNotExists
en utilisant le code suivant : - Créer la règle
RedshiftDbGroups
en utilisant le code suivant :
La capture d'écran suivante montre la liste des règles que j'ai créées dans mon AD FS. Notez le nombre de règles et l'ordre dans lequel elles sont positionnées. Nous avons créé les règles 6 à 11 dans le cadre de cet article.
Si vous voyez une réponse SAML similaire pour RedshiftDbGroups
, ta configuration est bonne :
Si un utilisateur n'existe pas dans l'un des groupes, une valeur vide est transmise à la règle de réclamation. Par exemple, si l'utilisateur bob est supprimé du marketing
groupe, la réponse SAML pour PrincipalTag:RedshiftDbGroup
serait :sales
.
Mettre à jour les rôles IAM
In Partie 1 de cette série, vous avez créé deux rôles IAM : ADFZ-Dev
et ADFZ-Production
. Ces deux rôles ne sont pas encore configurés avec des autorisations sur l'éditeur de requêtes. Dans cette section, vous mettez à jour ces rôles avec les autorisations de l'éditeur de requêtes.
L'éditeur de requête Amazon Redshift v2 fournit plusieurs stratégies gérées pour accéder à l'éditeur de requête. Pour obtenir la liste de toutes les stratégies gérées, reportez-vous à Configuration de votre compte AWS. Pour ce post, nous joignons le AmazonRedshiftQueryEditorV2ReadSharing
stratégie gérée aux rôles.
- Sur la console IAM, choisissez Rôles dans le volet de navigation.
- Choisissez le rôle
ADFZ-Dev
. - Selectionnez Ajouter des autorisations et alors Joindre des politiques.
- Sous Autres règles d'autorisation, recherchez le
AmazonRedshiftQueryEditorV2ReadSharing
politique gérée. - Sélectionnez la politique et choisissez Joindre des politiques.
- Modifiez les relations d'approbation pour votre rôle et ajoutez
sts:TagSession
. Pendant que vous êtes dans le rôle, sélectionnez Relations de confiance et cliquez sur Modifier la stratégie d'approbation.Lors de l'utilisation de balises de session, les stratégies d'approbation pour tous les rôles connectés aux balises de transmission IdP doivent avoir le sts:TagSession autorisation. Pour les rôles sans cette autorisation dans la stratégie d'approbation, leAssumeRole
l'opération échoue. - Choisissez Stratégie de mise à jour.
- Répétez ces étapes pour fixer le
AmazonRedshiftQueryEditorV2ReadSharing
stratégie gérée au rôle ADFZ-Production.
Limitation de l'accès des utilisateurs uniquement à l'éditeur de requête
Si vous souhaitez limiter les utilisateurs à l'accès à l'éditeur de requête, mettez à jour la politique redshift-marketing
que vous avez créé dans le billet de blog de la partie 1 comme ci-dessous.
Remarque: une fois mis à jour, les utilisateurs perdront les privilèges d'administrateur tels que créer un cluster.
Remplacez les paramètres de région, de compte et de cluster. Cette stratégie personnalisée accorde l'accès à Amazon Redshift pour obtenir les informations d'identification du cluster, créer des utilisateurs et permettre aux utilisateurs de rejoindre des groupes.
Il y a quelques points importants à noter :
- L'appartenance au groupe ne dure que pendant la durée de la session utilisateur.
- Il n'y a pas de
CreateGroup
autorisation parce que les groupes doivent être créés manuellement et accordés des privilèges de base de données.
Générer l'URL de destination SSO en tant que console de l'éditeur de requête Amazon Redshift v2
Dans cette étape, vous créez l'URL de connexion pour l'IdP AD FS afin de rediriger les utilisateurs vers la console v2 de l'éditeur de requête Amazon Redshift. Pour obtenir des instructions, reportez-vous à Comment utiliser SAML pour diriger automatiquement les utilisateurs fédérés vers une page AWS Management Console spécifique.
Pour fournir une expérience SSO complète aux utilisateurs finaux, la réponse SAML peut inclure un paramètre facultatif appelé RelayState
. Ce paramètre contient l'URL de destination.
Microsoft fournit un outil pour aider à générer ces URL SSO pour AD FS appelé le Générateur d'état de relais AD FS 2.0.
Pour créer cette URL, vous avez besoin de trois informations :
- Chaîne d'URL du fournisseur d'identité – La chaîne est au format
https://ADFSSERVER/adfs/ls/idpinitiatedsignon.aspx
. Pour ce poste, nous utilisonshttps://EC2AMAZ-F9TJOIC.adfsredshift.com/adfs/ls/IdpInitiatedSignOn.aspx
. - Identifiant de la partie de confiance – Pour AWS, c'est
urn:amazon:webservices
. - État du relais ou application cible - C'est le Console de gestion AWS URL vers laquelle vous souhaitez rediriger vos utilisateurs authentifiés. Dans ce cas, c'est
https://eu-west-1.console.aws.amazon.com/sqlworkbench/home?
. Pour ce post, nous utilisons leeu-west-1
Région, mais vous pouvez l'ajuster si nécessaire.
J'ai suivi les instructions de Comment utiliser SAML pour diriger automatiquement les utilisateurs fédérés vers une page AWS Management Console spécifique et utilisé le générateur AD FS 2.0 RelayState pour générer l'URL indiquée dans la capture d'écran suivante.
Voici un exemple de l'URL finale que vous utilisez pour vous authentifier et également être redirigé vers l'éditeur de requête Amazon Redshift v2 (cette URL ne fonctionnera pas dans votre configuration car elle a été créée spécifiquement pour un serveur AD FS dans mon compte) : https://EC2AMAZ-F9TJOIC.adfsredshift.com/adfs/ls/IdpInitiatedSignOn.aspx?RelayState=RPID%3Durn%253Aamazon%253Awebservices%26RelayState%3Dhttps%253A%252F%252Feu-west-1.console.aws.amazon.com%252Fsqlworkbench%252Fhome%253Fregion%253Deu-west-1%2523%252Fclient
Vous pouvez maintenant enregistrer cette URL et l'utiliser depuis n'importe quel endroit où vous pouvez accéder à votre serveur AD FS. Après avoir saisi l'URL dans un navigateur, vous vous authentifiez d'abord auprès d'AD FS, puis vous êtes redirigé vers la console v2 de l'éditeur de requête Amazon Redshift.
Configurer des groupes de bases de données sur le cluster Amazon Redshift
Dans cette étape, vous configurez votre groupe de base de données Amazon Redshift. Cette étape est nécessaire car lorsque l'utilisateur est authentifié, il doit faire partie d'un groupe de bases de données Amazon Redshift avec les autorisations appropriées définies sur un schéma ou une table (ou une vue).
Dans Active Directory, l'utilisateur Bob
fait partie de deux groupes : Sales
et Marketing
. Dans votre base de données Amazon Redshift, vous disposez de trois groupes de bases de données : Sales
, Marketing
et Finance
.
Lorsque l'utilisateur Bob
se connecte via l'authentification fédérée, l'utilisateur assume Sales
et Marketing
groupes de bases de données, afin que cet utilisateur puisse interroger des tables à la fois dans Sales
et Marketing
schémas. Parce que l'utilisateur Bob
ne fait pas partie du Finance
groupe, lorsqu'ils tentent d'accéder au Finance
schéma, ils reçoivent une erreur d'autorisation refusée.
Le schéma suivant illustre cette configuration.
Effectuez les étapes suivantes pour configurer vos groupes de bases de données :
- Connectez-vous en tant que
awsuser
(un superutilisateur). - Créez trois groupes de bases de données :
- Créez trois schémas :
- Créez une table dans chaque schéma :
- Insérez des exemples de données dans les trois tables :
- Vérifiez que les données sont disponibles dans les tables :
Vous pouvez maintenant configurer les privilèges appropriés pour le sales
, finance
et marketing
groupes. Les groupes sont des ensembles d'utilisateurs qui disposent tous des privilèges associés au groupe. Vous pouvez utiliser des groupes pour attribuer des privilèges par fonction. Par exemple, vous pouvez créer différents groupes pour les ventes, l'administration et le support, et accorder aux utilisateurs de chaque groupe l'accès approprié aux données dont ils ont besoin pour leur travail. Vous pouvez accorder ou révoquer des privilèges au niveau du groupe, et ces modifications s'appliquent à tous les membres du groupe, à l'exception des superutilisateurs.
- Entrez les requêtes SQL suivantes pour accorder l'accès à toutes les tables du
sales
schéma au groupe de vente, accès à toutes les tables dumarketing
schéma à lamarketing
groupe et l'accès à toutes les tables dufinance
schéma à lafinance
groupe:
Accéder à l'éditeur de requêtes Amazon Redshift v2 via l'authentification fédérée
Maintenant que vous avez terminé votre intégration SAML, la configuration des liens profonds et la configuration des groupes de bases de données et des droits d'accès, vous pouvez configurer l'éditeur de requête Amazon Redshift v2 pour utiliser l'authentification fédérée avec AD FS pour vous connecter directement à partir de l'interface de l'éditeur de requête.
- Accédez à l'URL de lien profond que vous avez créée précédemment.
Vous êtes redirigé vers la page de connexion AD FS. - Connectez-vous en tant que
bob@adfsredshift.com
.
Pour cet article, j'ai accédé à cette URL à partir d'une machine Amazon EC2, mais vous pouvez y accéder depuis n'importe quel emplacement où vous pouvez atteindre l'IdP AD FS.
Une fois qu'AD FS vous authentifie avec succès, il redirige vers le point de terminaison AWS SSO et publie l'assertion SAML etRelayState
paramètre. Étant donné que vous avez configuré deux rôles IAM du côté AWS, vous êtes invité à sélectionner un rôle. - Sélectionnez un rôle (pour cet exemple,
ADFZ-Dev
) et choisissez Se connecter.
AWS envoie l'URL de connexion basée sur leRelayState
valeur vers votre navigateur en tant que redirection. Votre navigateur est automatiquement redirigé vers la console de l'éditeur de requête v2. - Cliquez avec le bouton droit sur votre cluster Amazon Redshift (pour cet article,
redshift-cluster-1
) et choisissez Modifier la connexion.
La valeur pour nom d'utilisateur est automatiquement rempli, et Accès fédéré est automatiquement sélectionné. - Selectionnez Modifier la connexion pour enregistrer la connexion et se connecter à la base de données.
Une fois connecté, vous pouvez parcourir les objets de la base de données dans le volet de gauche. - Testez la connexion en exécutant la requête suivante :
La capture d'écran suivante montre la sortie.
La sortie montre que l'utilisateur bob@adfsredshift.com
a été authentifié à l'aide d'AD FS. L'utilisateur a également rejoint le marketing
et Sales
groupes tels qu'appliqués par AD FS PrincipalTag:RedshiftDbGroups
règle de revendication et la politique associée à la ADFZ-Dev
rôle que l'utilisateur assume au cours de cette session.
Exécuter des requêtes pour valider l'autorisation via des groupes fédérés
Dans cette dernière étape, vous validez la manière dont les groupes et l'appartenance configurés dans AD sont intégrés de manière transparente aux groupes de base de données Amazon Redshift.
Exécutez la requête suivante sur le marketing
et sales
schéma:
Les captures d'écran suivantes montrent le résultat :
Les images précédentes montrent que l'utilisateur AD Bob
fait partie du groupe AD RSDB-marketing
et RSDB-sales
, qui sont mappés aux groupes de bases de données marketing
et sales
. Ces groupes de bases de données ont un accès sélectif aux schémas marketing et ventes et à toutes les tables de ces schémas. Par conséquent, l'utilisateur peut interroger les tables avec succès.
Pour exécuter une requête sur le finance
schéma, saisissez le code suivant :
La capture d'écran suivante montre la sortie.
La sortie montre que Bob
n'est qu'une partie des groupes AD RSDB-marketing
et RSDB-sales
. En raison de la configuration de la règle de revendication, Bob
n'a pas accès au groupe de base de données finance
, et par conséquent la requête renvoie une erreur d'autorisation refusée.
Nettoyer
Pour éviter des frais futurs, supprimez les ressources en supprimant la pile CloudFormation. Cela nettoie toutes les ressources de votre compte AWS que vous avez configurées dans Partie 1.
Conclusion
Dans cet article, nous avons montré comment configurer un serveur AD FS, configurer différents PrincipalTag
attributs utilisés pour l'éditeur de requête Amazon Redshift v2 et générer une URL SSO avec l'éditeur de requête comme emplacement de destination. Vous vous êtes ensuite connecté au cluster de base de données Amazon Redshift à l'aide d'un utilisateur de base de données disposant de privilèges d'administrateur pour configurer des groupes et des autorisations de base de données, et avez utilisé une authentification d'utilisateur fédéré avec AD FS pour exécuter plusieurs requêtes. Cette solution vous permet de contrôler l'accès à vos objets de base de données Amazon Redshift en utilisant des groupes et des adhésions AD de manière transparente.
Si vous avez des commentaires ou des questions, veuillez les laisser dans les commentaires.
À propos des auteurs
Sumeet Joshi est un architecte de solutions spécialisées en analyse basé à New York. Il se spécialise dans la construction de solutions d'entreposage de données à grande échelle. Il a plus de 16 ans d'expérience dans le domaine de l'entreposage de données et de l'analyse.
Bhanu Pittampally est un architecte de solutions spécialisées en analyse basé à Dallas. Il est spécialisé dans la construction de solutions analytiques. Son expérience est dans les données et l'analyse depuis plus de 14 ans. Son profil LinkedIn peut être trouvé ici.
Erol Murtezaoğlu, responsable produit technique chez AWS, est un penseur curieux et enthousiaste, animé par une volonté d'amélioration personnelle et d'apprentissage. Il possède une expérience technique solide et éprouvée dans le développement et l'architecture de logiciels, équilibrée par une volonté de fournir des produits à succès commercial. Erol accorde une grande importance au processus de compréhension des besoins et des problèmes des clients, afin de fournir des solutions qui dépassent les attentes.
Yanis Télaoumaten est ingénieur en développement logiciel chez AWS. Ses passions sont la construction de logiciels fiables et la création d'outils permettant à d'autres ingénieurs de travailler plus efficacement. Au cours des dernières années, il a travaillé sur l'identité, la sécurité et la fiabilité des services Redshift