Sécurisez et rationalisez l'accès des utilisateurs dans une base de données de fédération DB2 sur AWS en utilisant des contextes fiables

Créée par Sai Parthasaradhi (AWS)

Environnement : PoC ou pilote	Technologies : bases de données ; sécurité, identité, conformité	Charge de travail : IBM
Services AWS : Amazon EC2

Récapitulatif

De nombreuses entreprises migrent leurs anciennes charges de travail mainframe vers Amazon Web Services (AWS). Cette migration inclut le transfert des bases de données IBM Db2 for z/OS vers Db2 pour Linux, Unix et Windows (LUW) sur Amazon Elastic Compute Cloud (Amazon EC2). Lors d'une migration progressive d'un environnement sur site vers AWS, les utilisateurs peuvent avoir besoin d'accéder aux données dans IBM Db2 z/OS et dans Db2 LUW sur Amazon EC2 jusqu'à ce que toutes les applications et bases de données soient entièrement migrées vers Db2 LUW. Dans de tels scénarios d'accès aux données à distance, l'authentification des utilisateurs peut s'avérer difficile car les différentes plateformes utilisent des mécanismes d'authentification différents.

Ce modèle explique comment configurer un serveur de fédération sur Db2 pour LUW avec Db2 pour z/OS comme base de données distante. Le modèle utilise un contexte fiable pour propager l'identité d'un utilisateur de Db2 LUW à Db2 z/OS sans se réauthentifier sur la base de données distante. Pour plus d'informations sur les contextes sécurisés, consultez la section Informations supplémentaires.

Conditions préalables et limitations

Prérequis

• Un compte AWS actif

• Une instance Db2 exécutée sur une instance Amazon EC2

• Une base de données Db2 pour z/OS distante exécutée sur site

• Le réseau sur site connecté à AWS via le VPN AWS Site-to-Site ou AWS Direct Connect

Architecture

Architecture cible

Outils

Services AWS

• Amazon Elastic Compute Cloud (Amazon EC2) fournit une capacité de calcul évolutive dans le cloud AWS. Vous pouvez lancer autant de serveurs virtuels que vous le souhaitez et les augmenter ou les diminuer rapidement.

• Le VPN AWS Site-to-site vous aide à faire passer le trafic entre les instances que vous lancez sur AWS et votre propre réseau distant.

Autres services

• db2cli est la commande d'interface de ligne de commande (CLI) interactive de DB2.

Épopées

Activer la fédération sur la base de données DB2 LUW exécutée sur AWS

Tâche	Description	Compétences requises
Activez la fédération sur la base de données DB2 LUW.	Pour activer la fédération sur DB2 LUW, exécutez la commande suivante. update dbm cfg using federated YES	DBA
Redémarrez la base de données.	Pour redémarrer la base de données, exécutez la commande suivante. db2stop force; db2start;	DBA

Cataloguer la base de données distante

Tâche	Description	Compétences requises
Cataloguez le sous-système Db2 z/OS distant.	Pour cataloguer la base de données distante Db2 z/OS sur Db2 LUW exécutée sur AWS, utilisez l'exemple de commande suivant. catalog TCPIP NODE tcpnode REMOTE mainframehost SERVER mainframeport	DBA
Cataloguez la base de données distante.	Pour cataloguer la base de données distante, utilisez l'exemple de commande suivant. catalog db dbnam1 as ndbnam1 at node tcpnode	DBA

Création de la définition du serveur distant

Tâche	Description	Compétences requises
Collectez les informations d'identification utilisateur pour la base de données distante Db2 z/OS.	Avant de passer aux étapes suivantes, collectez les informations suivantes : Nom du sous-système Db2 z/OS : nom de Db2 z/OS catalogué sur LUW à partir de l'étape précédente (par exemple,) ndbnam1 Version Db2 z/OS : version du sous-système Db2 z/OS (par exemple,) 12 ID utilisateur Db2 z/OS : utilisateur disposant du privilège BIND, nécessaire pour créer uniquement la définition du serveur (par exemple,) dbuser1 Mot de passe Db2 z/OS : mot de passe pour dbuser1 (par exemple,) dbpasswd Utilisateur proxy Db2 z/OS : ID de l'utilisateur du proxy, qui sera utilisé pour établir une connexion sécurisée (par exemple,) zproxy Mot de passe du proxy Db2 z/OS : mot de passe de l'zproxyutilisateur (par exemple,) zproxy	DBA
Créez le wrapper DRDA.	Pour créer le wrapper DRDA, exécutez la commande suivante. CREATE WRAPPER DRDA;	DBA
Créez la définition du serveur.	Pour créer la définition du serveur, exécutez l'exemple de commande suivant. CREATE SERVER ndbserver TYPE DB2/ZOS VERSION 12 WRAPPER DRDA AUTHORIZATION "dbuser1" PASSWORD "dbpasswd" OPTIONS ( DBNAME 'ndbnam1',FED_PROXY_USER 'ZPROXY' ); Dans cette définition, FED_PROXY_USER indique l'utilisateur proxy qui sera utilisé pour établir des connexions fiables à la base de données Db2 z/OS. L'ID utilisateur et le mot de passe d'autorisation ne sont requis que pour créer l'objet serveur distant dans la base de données DB2 LUW. Ils ne seront pas utilisés ultérieurement pendant l'exécution.	DBA

Création de mappages d'utilisateurs

Tâche	Description	Compétences requises
Créez un mappage utilisateur pour l'utilisateur proxy.	Pour créer un mappage utilisateur pour un utilisateur proxy, exécutez la commande suivante. CREATE USER MAPPING FOR ZPROXY SERVER ndbserver OPTIONS (REMOTE_AUTHID 'ZPROXY', REMOTE_PASSWORD 'zproxy');	DBA
Créez des mappages d'utilisateurs pour chaque utilisateur sur DB2 LUW.	Créez des mappages d'utilisateurs pour tous les utilisateurs de la base de données DB2 LUW sur AWS qui ont besoin d'accéder aux données distantes via l'utilisateur proxy. Pour créer les mappages d'utilisateurs, exécutez la commande suivante. CREATE USER MAPPING FOR PERSON1 SERVER ndbserver OPTIONS (REMOTE_AUTHID 'USERZID', USE_TRUSTED_CONTEXT 'Y'); L'instruction indique qu'un utilisateur de DB2 LUW (PERSON1) peut établir une connexion sécurisée avec la base de données distante Db2 z/OS (). USE_TRUSTED_CONTEXT 'Y' Une fois la connexion établie via l'utilisateur proxy, celui-ci peut accéder aux données à l'aide de l'ID utilisateur Db2 z/OS ()REMOTE_AUTHID 'USERZID'.	DBA

Création de l'objet de contexte sécurisé

Tâche	Description	Compétences requises
Créez l'objet de contexte sécurisé.	Pour créer l'objet de contexte sécurisé sur la base de données distante Db2 z/OS, utilisez l'exemple de commande suivant. CREATE TRUSTED CONTEXT CTX_LUW_ZOS BASED UPON CONNECTION USING SYSTEM AUTHID ZPROXY ATTRIBUTES ( ADDRESS '10.10.10.10' ) NO DEFAULT ROLE ENABLE WITH USE FOR PUBLIC WITHOUT AUTHENTICATION; Dans cette définition, CTX_LUW_ZOS il s'agit d'un nom arbitraire pour l'objet de contexte sécurisé. L'objet contient l'ID utilisateur du proxy et l'adresse IP du serveur d'où doit provenir la connexion sécurisée. Dans cet exemple, le serveur est la base de données DB2 LUW sur AWS. Vous pouvez utiliser le nom de domaine au lieu de l'adresse IP. La clause WITH USE FOR PUBLIC WITHOUT AUTHENTICATION indique que le changement d'ID utilisateur sur une connexion sécurisée est autorisé pour chaque ID utilisateur. Il n'est pas nécessaire de fournir un mot de passe.	DBA

Ressources connexes

• Installation de contrôle d'accès aux ressources IBM (RACF)

• Fédération IBM DB2 LUW

• Contextes fiables

Informations supplémentaires

Contextes fiables DB2

Un contexte sécurisé est un objet de base de données DB2 qui définit une relation de confiance entre un serveur fédéré et un serveur de base de données distant. Pour définir une relation de confiance, le contexte de confiance spécifie les attributs de confiance. Il existe trois types d'attributs de confiance :

• ID d'autorisation système à l'origine de la demande initiale de connexion à la base de données

• L'adresse IP ou le nom de domaine à partir duquel la connexion est établie

• Paramètre de chiffrement pour les communications de données entre le serveur de base de données et le client de base de données

Une connexion sécurisée est établie lorsque tous les attributs d'une demande de connexion correspondent aux attributs spécifiés dans un objet de contexte sécurisé défini sur le serveur. Il existe deux types de connexions fiables : les connexions implicites et les connexions explicites. Une fois qu'une connexion sécurisée implicite est établie, un utilisateur hérite d'un rôle auquel il n'a pas accès en dehors du cadre de cette définition de connexion sécurisée. Une fois qu'une connexion sécurisée explicite est établie, les utilisateurs peuvent être connectés à la même connexion physique, avec ou sans authentification. En outre, les utilisateurs de DB2 peuvent se voir attribuer des rôles qui spécifient des privilèges à utiliser uniquement dans le cadre de la connexion sécurisée. Ce modèle utilise une connexion sécurisée explicite.

Contexte fiable dans ce modèle

Une fois le modèle terminé, PERSON1 sur DB2 LUW accède aux données distantes depuis Db2 z/OS en utilisant un contexte sécurisé fédéré. La connexion pour PERSON1 est établie via un utilisateur proxy si elle provient de l'adresse IP ou du nom de domaine spécifié dans la définition du contexte sécurisé. Une fois la connexion établie, l'ID utilisateur Db2 z/OS correspondant à PERSON1 est changé sans nouvelle authentification, et l'utilisateur peut accéder aux données ou aux objets en fonction des privilèges Db2 configurés pour cet utilisateur.

Avantages des contextes fiables fédérés

• Cette approche maintient le principe du moindre privilège en éliminant l'utilisation d'un identifiant d'utilisateur ou d'un identifiant d'application commun qui nécessiterait un surensemble de tous les privilèges requis par tous les utilisateurs.

• L'identité réelle de l'utilisateur qui effectue la transaction sur la base de données fédérée et distante est toujours connue et peut être auditée.

• Les performances s'améliorent car la connexion physique est réutilisée entre les utilisateurs sans que le serveur fédéré n'ait besoin de s'authentifier à nouveau.