Proteja y agilice el acceso de los usuarios a una base de datos de federación de DB2 AWS mediante el uso de contextos confiables - Recomendaciones de AWS
ResumenRequisitos previos y limitacionesArquitecturaHerramientasEpicsRecursos relacionadosInformación adicional

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Proteja y agilice el acceso de los usuarios a una base de datos de federación de DB2 AWS mediante el uso de contextos confiables

Creado por Sai Parthasaradhi () AWS

Entorno: PoC o piloto

Tecnologías: bases de datos, seguridad, identidad, conformidad

Carga de trabajo: IBM

AWSservicios: Amazon EC2

Resumen

Muchas empresas están migrando sus cargas de trabajo de mainframe heredadas a Amazon Web Services (). AWS Esta migración incluye el cambio de las bases de datos de IBM Db2 for z/OS a Db2 para Linux, Unix y Windows () LUW en Amazon Elastic Compute Cloud (Amazon). EC2 Durante una migración gradual de una versión local a otraAWS, es posible que los usuarios necesiten acceder a los datos en IBM Db2 z/OS y en Db2 en LUW Amazon EC2 hasta que todas las aplicaciones y bases de datos se hayan migrado completamente a Db2. LUW En estos escenarios de acceso remoto a los datos, la autenticación de los usuarios puede resultar difícil porque las diferentes plataformas utilizan diferentes mecanismos de autenticación.

Este patrón explica cómo configurar un servidor de federación en Db2 for LUW con Db2 for z/OS como base de datos remota. El patrón utiliza un contexto confiable para propagar la identidad de un usuario de Db2 a Db2 z/OS sin volver LUW a autenticarse en la base de datos remota. Para obtener más información sobre los contextos de confianza, consulte la sección Información adicional.

Requisitos previos y limitaciones

Requisitos previos 

  • Una cuenta activa AWS

  • Una instancia de Db2 que se ejecuta en una instancia de Amazon EC2

  • Una base de datos remota de Db2 para z/OS que se ejecuta en las instalaciones

  • La red local conectada a AWS través de Direct Connect AWS Site-to-SiteVPNo AWSDirect Connect

Arquitectura

Arquitectura de destino

El mainframe local se conecta a través del servidor Db2 local y VPN a la base de datos Db2 en él. EC2

Herramientas

AWSservicios

  • Amazon Elastic Compute Cloud (AmazonEC2) proporciona capacidad informática escalable en la AWS nube. Puede lanzar tantos servidores virtuales como necesite y escalarlos o reducirlos con rapidez.

  • AWS Site-to-SiteVPNle ayuda a transferir el tráfico entre las instancias en las que se lanza AWS y su propia red remota.

Otros servicios

  • db2cli es el comando de la interfaz de línea de comandos interactiva () CLI de Db2.

Epics

TareaDescripciónHabilidades requeridas

Habilite la federación en la DB2 LUW base de datos.

Para activar la federación DB2LUW, ejecute el siguiente comando.

update dbm cfg using federated YES
DBA

Reinicie la base de datos.

Para reiniciar la base de datos, ejecute el comando siguiente:

db2stop force;
db2start;
DBA
TareaDescripciónHabilidades requeridas

Catalogue el subsistema remoto Db2 z/OS.

Para catalogar la base de datos remota de Db2 z/OS en Db2 en LUW ejecuciónAWS, utilice el siguiente comando de ejemplo.

catalog TCPIP NODE tcpnode REMOTE mainframehost SERVER mainframeport
DBA

Catalogue la base de datos remota.

Para catalogar la base de datos remota, utilice el siguiente comando de ejemplo. 

catalog db dbnam1 as ndbnam1 at node tcpnode
DBA
TareaDescripciónHabilidades requeridas

Recopile las credenciales de usuario para la base de datos remota de Db2 z/OS.

Antes de continuar con los siguientes pasos, recopile la siguiente información:

  • Nombre del subsistema Db2 z/OS: el nombre de Db2 z/OS catalogado correspondiente al paso anterior (por ejemplo,) LUW ndbnam1

  • Versión Db2 z/OS: la versión del subsistema Db2 z/OS (por ejemplo, 12)

  • ID de usuario de Db2 z/OS: el usuario con el BIND privilegio, que se necesita para crear únicamente la definición de servidor (por ejemplo,) dbuser1

  • Contraseña de Db2 z/OS: la contraseña de dbuser1 (por ejemplo, dbpasswd)

  • Usuario proxy de Db2 z/OS: el ID del usuario proxy, que se utilizará para establecer una conexión de confianza (por ejemplo, zproxy)

  • Contraseña de proxy de Db2 z/OS: la contraseña del usuario zproxy (por ejemplo, zproxy)

DBA

Cree el contenedor. DRDA

Para crear el DRDA contenedor, ejecute el siguiente comando.

CREATE WRAPPER DRDA;
DBA

Cree la definición del servidor.

Para crear la definición del servidor, ejecute el siguiente comando de ejemplo.

CREATE SERVER ndbserver
TYPE DB2/ZOS VERSION 12
WRAPPER DRDA
AUTHORIZATION "dbuser1" PASSWORD "dbpasswd" OPTIONS ( DBNAME 'ndbnam1',FED_PROXY_USER 'ZPROXY' );

En esta definición, FED_PROXY_USER especifica el usuario proxy que se utilizará para establecer conexiones de confianza a la base de datos Db2 z/OS. El ID de usuario y la contraseña de autorización solo son necesarios para crear el objeto de servidor remoto en la base de datos de Db2LUW. No se utilizarán más adelante durante el tiempo de ejecución.

DBA
TareaDescripciónHabilidades requeridas

Cree un asignación de usuarios para el usuario proxy.

Para crear un asignación de usuarios para el usuario proxy, ejecute el siguiente comando.

CREATE USER MAPPING FOR ZPROXY SERVER ndbserver OPTIONS (REMOTE_AUTHID 'ZPROXY', REMOTE_PASSWORD 'zproxy');
DBA

Cree asignaciones de usuarios para cada usuario de Db2. LUW

Cree mapeos de usuarios para todos los usuarios de la base de datos de Db2 AWS que necesiten acceder a LUW datos remotos a través del usuario proxy. Ejecute el siguiente comando para crear las asignaciones de usuario.

CREATE USER MAPPING FOR PERSON1 SERVER ndbserver OPTIONS (REMOTE_AUTHID 'USERZID', USE_TRUSTED_CONTEXT 'Y');

La declaración especifica que un usuario de Db2 LUW (PERSON1) puede establecer una conexión de confianza con la base de datos remota de Db2 z/OS (). USE_TRUSTED_CONTEXT 'Y' Una vez establecida la conexión a través del usuario proxy, el usuario puede acceder a los datos mediante el ID de usuario de Db2 z/OS (REMOTE_AUTHID 'USERZID').

DBA
TareaDescripciónHabilidades requeridas

Cree el objeto de contexto de confianza.

Para crear el objeto de contexto de confianza en la base de datos remota de Db2 z/OS, utilice el siguiente comando de ejemplo.

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;

En esta definición, CTX_LUW_ZOS es un nombre arbitrario para el objeto de contexto de confianza. El objeto contiene el ID del usuario proxy y la dirección IP del servidor desde el que debe originarse la conexión de confianza. En este ejemplo, el servidor en el que se encuentra la base de datos de Db2. LUW AWS También puede utilizar el nombre de dominio en lugar de la dirección IP. La cláusula WITH USE FOR PUBLIC WITHOUT AUTHENTICATION indica que se permite cambiar el ID de usuario en una conexión de confianza para cada ID de usuario. No es necesario proporcionar una contraseña.

DBA

Recursos relacionados

Información adicional

Contextos de confianza de Db2

Un contexto de confianza es un objeto de base de datos de Db2 que define una relación de confianza entre un servidor federado y un servidor de base de datos remoto. Para definir una relación de confianza, el contexto de confianza especifica los atributos de confianza. Existen tres tipos de atributos de confianza:

  • El ID de autorización del sistema que realiza la solicitud de conexión inicial a la base de datos

  • La dirección IP o el nombre de dominio desde los que se realiza la conexión

  • La configuración de cifrado para las comunicaciones de datos entre el servidor de la base de datos y el cliente de la base de datos

Se establece una conexión de confianza cuando todos los atributos de una solicitud de conexión coinciden con los atributos especificados en cualquier objeto de contexto de confianza definido en el servidor. Existen dos tipos diferentes de conexiones de confianza: implícitas y explícitas. Una vez establecida una conexión de confianza implícita, el usuario hereda un rol que no está disponible para él fuera del ámbito de esa definición de conexión de confianza. Una vez establecida una conexión de confianza explícita, los usuarios pueden conectarse a la misma conexión física, con o sin autenticación. Además, a los usuarios de Db2 se les pueden asignar roles que especifiquen privilegios que solo se utilizarán dentro de la conexión de confianza. Este patrón utiliza una conexión de confianza explícita.

Contexto de confianza en este patrón

Una vez completado el patrón, PERSON1 en Db2 LUW accede a los datos remotos de Db2 z/OS mediante un contexto de confianza federado. La conexión para PERSON1 se establece a través de un usuario proxy si la conexión se origina en la dirección IP o el nombre de dominio que se especifica en la definición del contexto de confianza. Una vez establecida la conexión, el ID PERSON1 de usuario de Db2 z/OS correspondiente se cambia sin necesidad de volver a autenticarse, y el usuario puede acceder a los datos u objetos en función de los privilegios de Db2 configurados para ese usuario.

Ventajas de los contextos de confianza federados

  • Este enfoque mantiene el principio del privilegio mínimo al eliminar el uso de un ID de usuario o de aplicación común, que requeriría un conjunto de todos los privilegios que requieren todos los usuarios.

  • La identidad real del usuario que realiza la transacción tanto en la base de datos federada como en la remota siempre se conoce y se puede auditar.

  • El rendimiento mejora porque la conexión física se reutiliza entre los usuarios sin necesidad de que el servidor federado vuelva a autenticarse.