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 - Recommandations AWS
RécapitulatifConditions préalables et limitationsArchitectureOutilsÉpopéesRessources connexesInformations supplémentaires

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.

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)

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 Site-to-SiteVPN AWS ou AWS Direct Connect

Architecture

Architecture cible

Le mainframe local se connecte via un serveur DB2 local et un VPN à la base de données DB2 sur. EC2

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.

  • Site-to-SiteLe VPN AWS 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

TâcheDescriptionCompé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
TâcheDescriptionCompé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
TâcheDescriptionCompé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
TâcheDescriptionCompé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
TâcheDescriptionCompé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

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 schéma 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 la connexion 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, PERSON1 l'ID utilisateur Db2 z/OS correspondant 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 à la fois 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.