DB2 - Connectivité - Informations complémentaires

Configuration du serveur d'applications

Le support de serveur d'applications de DB2 pour MVS/ESA lui permet d'assurer une fonction serveur pour les demandeurs d'application DRDA. Le demandeur d'application connecté à un serveur d'applications DB2 pour MVS/ESA peut être :

Pour n'importe quel demandeur d'application connecté à un serveur d'applications DB2 pour MVS/ESA, ce dernier prend en charge l'accès à la base de données, comme suit :

Définition des données réseau

Pour que le serveur d'applications DB2 pour MVS/ESA puisse correctement traiter les demandes de bases de données réparties, vous devez procéder comme suit :

  1. Définissez le serveur d'applications sur le gestionnaire de communications local.
  2. Définissez chaque destination de serveur secondaire potentiel pour permettre au serveur d'applications DB2 pour MVS/ESA de réacheminer les demandes SQL vers leur destination finale.
  3. Définissez la sécurité nécessaire.
  4. Prévoyez la représentation des données.

Définition du serveur d'applications

Pour que le serveur d'applications puisse recevoir des demandes de bases de données réparties, il doit être défini sur le gestionnaire de communications local et avoir une valeur RDB_NAME unique. Vous devez effectuer les opérations suivantes pour définir correctement le serveur d'applications :

  1. Sélectionnez le nom de LU et le RDB_NAME devant être utilisés par le serveur d'applications DB2 pour MVS/ESA. Le procédé d'enregistrement de ces noms dans DB2 pour MVS/ESA et VTAM est identique à celui décrit à la section Définition du système local. Le RDB_NAME choisi pour DB2 pour MVS/ESA doit être fourni à l'ensemble des utilisateurs finals et des demandeurs d'application pour lesquels la connectivité au serveur d'applications est nécessaire.
  2. Enregistrez la valeur NETID.LUNAME pour le serveur d'applications DB2 pour MVS/ESA avec chaque demandeur d'application requérant l'accès, de sorte que le demandeur d'application puisse acheminer les demandes SNA vers le serveur DB2 pour MVS/ESA. Il en est ainsi même dans les cas où le demandeur d'application est en mesure d'exécuter un routage de réseau dynamique, car le demandeur d'application doit connaître le NETID.LUNAME avant que le routage de réseau dynamique puisse être utilisé.
  3. Fournissez le TPN par défaut de DRDA (X'07F6C4C2') pour chaque demandeur d'application car DB2 pour MVS/ESA utilise cette valeur automatiquement.
  4. Créez une entrée dans la table de modes VTAM pour chaque nom de mode demandé par un demandeur d'application. Ces entrées décrivent les tailles de RU, la taille de la fenêtre de régulation et la classe de service pour chaque nom de mode.
  5. Définissez le nombre maximal de sessions pour les demandeurs d'application qui se connectent au serveur d'applications DB2 pour MVS/ESA. L'instruction VTAM APPL définit le nombre maximal de sessions par défaut pour tous les systèmes partenaires. Si vous voulez définir des valeurs par défaut uniques pour un partenaire donné, vous pouvez utiliser la table SYSIBM.SYSLUMODES de la base de données de communications (CDB).

    Reportez-vous à la section Définition de la taille de RU et de la régulation, pour savoir comment visualiser votre réseau VTAM.

  6. Créez des entrées dans la base de données de communications de DB2 pour MVS/ESA afin d'identifier les demandeur d'applications autorisés à se connecter au serveur d'applications DB2 pour MVS/ESA. Deux approches de base permettent de définir des entrées de base de données de communications pour les demandeurs d'application sur le réseau :
    1. Vous pouvez insérer une ligne dans la table SYSIBM.SYSLUNAMES qui fournit les valeurs par défaut à utiliser pour toute LU ne faisant pas l'objet d'une description particulière dans la base de données de communication (la ligne par défaut contient une valeur à blanc dans la colonne LUNAME). Cette approche vous permet de définir des attributs particuliers pour certaines des LU de votre réseau, tout en définissant des valeurs par défaut pour toutes les autres LU.

      Par exemple, vous pouvez permettre au système DALLAS (autre système DB2 pour MVS/ESA) d'envoyer des demandes de bases de données réparties déjà vérifiées (LU 6.2 SECURITY=SAME), tout en demandant aux gestionnaires de bases de données d'envoyer des mots de passe. Par ailleurs, vous pouvez ne pas vouloir enregistrer d'entrées dans la base de données de communication de chaque gestionnaire de bases de données, en particulier si ces derniers sont nombreux. La Figure 10 montre comment la base de données de communications peut servir à spécifier SECURITY=SAME pour le système DALLAS, tout en imposant SECURITY=PGM pour tous les autres demandeurs.

      Figure 10. Définition de valeurs par défaut pour les connexions de demandeurs d'application

      INSERT INTO SYSIBM.SYSLUNAMES
           (LUNAME, SYSMODENAME, USERSECURITY, ENCRYPTPSWDS, MODESELECT, USERNAMES)
      VALUES ('LUDALLAS', ' ', 'A', 'N', 'N', ' ');
      INSERT INTO SYSIBM.SYSLUNAMES
           (LUNAME, SYSMODENAME, USERSECURITY, ENCRYPTPSWDS, MODESELECT, USERNAMES)
      VALUES (' ', ' ', 'C', 'N', 'N', ' ');
      

    2. Vous pouvez utiliser la base de données de communications pour accorder des droits à chaque demandeur d'application individuellement sur le réseau, selon l'une des deux méthodes suivantes :
      • N'enregistrez pas de ligne par défaut dans la table SYSIBM.SYSLUNAMES. En l'absence de ligne par défaut (ligne contenant un nom de LU à blanc), DB2 pour MVS/ESA requiert une ligne dans la table SYSIBM.SYSLUNAMES contenant le nom de LU de chaque demandeur d'application essayant de se connecter. Si la base de données de communications ne contient pas de ligne correspondante, le demandeur d'application se voit refuser l'accès.
      • Enregistrez une ligne par défaut dans la table SYSIBM.SYSLUNAMES indiquant que l'identification du site émetteur est requise (colonne USERNAMES ayant pour valeur 'I' ou 'B'). Du coup, DB2 pour MVS/ESA limite l'accès aux seuls demandeur d'application et aux utilisateurs finals identifiés dans la table SYSIBM.SYSUSERNAMES, comme décrit dans la section Identification du site émetteur . Il se peut que vous souhaitiez utiliser cette approche si les règles de conversion de nom que vous utilisez requièrent une ligne contenant un nom de LU à blanc dans la table SYSIBM.SYSLUNAMES, mais que vous ne voulez pas que DB2 pour MVS/ESA utilise cette ligne pour permettre un accès non restreint au serveur d'applications DB2 pour MVS/ESA.

      Dans la Figure 11, aucune ligne ne contient de valeur à blanc dans la colonne LUNAME, par conséquent DB2 pour MVS/ESA refuse l'accès à toute LU autre que LUDALLAS ou LUNYC.

      Figure 11. Identification de connexions de demandeurs d'application individuelles

      INSERT INTO SYSIBM.SYSLUNAMES
           (LUNAME, SYSMODENAME, USERSECURITY, ENCRYPTPSWDS, MODESELECT, USERNAMES)
      VALUES ('LUDALLAS', ' ', 'A', 'N', 'N', ' ');
      INSERT INTO SYSIBM.SYSLUNAMES
           (LUNAME, SYSMODENAME, USERSECURITY, ENCRYPTPSWDS, MODESELECT, USERNAMES)
      VALUES ('LUNYC', ' ', 'A', 'N', 'N', ' ');
      

Définition de serveurs secondaires

DB2 pour MVS/ESA ne met pas en oeuvre de serveur de bases de données comme défini dans DRDA. En revanche, DB2 pour MVS/ESA fournit des serveurs secondaires permettant l'accès à plusieurs systèmes DB2 pour MVS/ESA dans une seule unité d'oeuvre, via l'accès défini par le système.

Différences de SQL 

Le SQL pris en charge par l'accès défini par le système diffère de manière significative de l'unité d'oeuvre éloignée DRDA :

Noms d'objets SQL 

Lorsque le serveur d'applications DB2 pour MVS/ESA reçoit une requête SQL, il examine le nom d'objet SQL afin de déterminer l'emplacement de l'objet sur le réseau. DB2 pour MVS/ESA accepte des noms d'objets SQL monopartites, bipartites ou tripartites, sous l'une des formes suivantes :

nomobj indique le nom d'une table, d'une vue, d'un synonyme ou d'un alias DB2 pour MVS/ESA

idaut.nomobj indique le propriétaire et le nom de l'objet

emplacement.idaut.nomobj indique le système propriétaire, l'utilisateur propriétaire ainsi que le nom de l'objet

Si le nom d'emplacement (première partie du nom d'objet tripartite) correspond au RDB_NAME du système DB2 pour MVS/ESA local, la demande identifie un objet DB2 pour MVS/ESA local.

Si le nom d'emplacement ne correspond pas au RDB_NAME du système DB2 pour MVS/ESA local, le serveur d'applications DB2 pour MVS/ESA réachemine la demande vers le système identifié par le nom d'emplacement à l'aide de l'accès défini par le système. Le système cible doit être un autre système DB2 pour MVS/ESA car l'accès défini par le système est pris en charge uniquement entre les systèmes DB2 pour MVS/ESA. L'accès défini par le système ne prend en charge aucune fonction de définition d'accès éloigné. Par conséquent, l'application ne doit pas obligatoirement être liée au serveur avant son exécution. La Figure 12 résume le procédé utilisé par DB2 pour MVS/ESA pour résoudre les noms d'objet SQL.

Figure 12. Résolution de noms d'objets SQL DB2 pour MVS/ESA

                                                                                  
                                                                                 
 

REQTEXT

Définition du serveur 

Si le serveur d'applications DB2 pour MVS/ESA doit réacheminer les requêtes SQL, vous devez définir chaque serveur secondaire dans la base de données de communications et VTAM. Le processus de définition est en grande partie identique au processus décrit à la section Définition des systèmes éloignés. Pour connecter des serveurs secondaires, procédez comme suit :

  1. Enregistrez les valeurs correspondant au RDB_NAME et au nom de LU pour chaque serveur dans la base de données de communications et dans VTAM. La valeur de TPN utilisée par l'accès défini par le système est différente de la valeur par défaut de DRDA. Toutefois, cette différence n'est pas importante car DB2 pour MVS/ESA choisit automatiquement la valeur correcte.
  2. Définissez, dans la table SYSIBM.SYSLUNAMES, les conditions requises pour la sécurité de chaque serveur secondaire. Vous trouverez la description de ce processus à la section Définition de la sécurité.
  3. Définissez le nom de mode (ou les noms) utilisé entre le serveur d'applications DB2 pour MVS/ESA et les serveurs secondaires et placez ces noms de mode dans la table de modes VTAM. Le nom de mode par défaut est IBMDB2LM.
  4. Définissez le nombre maximal de sessions pour chaque serveur secondaire. Le processus utilisé pour établir le nombre maximal de sessions est identique à celui décrit à la section Définition du système local. Toutefois, l'accès défini par le système peut établir plusieurs conversations pour chaque application SQL. Il se peut que vous ayez besoin d'établir un nombre maximal de sessions supérieur pour les connexions d'accès défini par le système par rapport au nombre de sessions associé aux connexions DRDA. Reportez-vous à la section "Connexion de systèmes de bases de données réparties" dans le manuel DB2 - Guide de l'administrateur, pour en savoir plus sur le calcul du nombre de sessions LU 6.2 requises par les applications d'accès défini par le système.

En tant que propriétaire des ressources de base de données, le serveur secondaire contrôle la sécurité de base de données pour les objets SQL résidant au niveau du serveur. Toutefois, cette responsabilité est partagée par le serveur d'applications DB2 pour MVS/ESA qui émet la demande. Le serveur contrôle l'accès aux objets SQL, comme suit :

Définition de la sécurité

Lorsqu'un demandeur d'application achemine une demande de base de données répartie vers le serveur d'application, DB2 pour MVS/ESA, les critères de sécurité suivants peuvent être pris en compte :

Identification du site émetteur

Lorsqu'un serveur d'applications DB2 pour MVS/ESA reçoit un nom d'utilisateur final du demandeur d'application, il peut limiter les noms d'utilisateurs reçus d'un demandeur d'application donné. Cela est rendu possible par l'utilisation de l'identification du site émetteur. L'identification du site émetteur permet au serveur d'applications d'indiquer que seuls des partenaires donnés sont autorisés à utiliser un ID utilisateur donné. Par exemple, le serveur d'applications peut limiter JONES à "identification du site émetteur" DALLAS. Si un autre demandeur d'application (différent de DALLAS) tente d'envoyer le nom JONES au serveur d'applications, ce dernier peut rejeter la demande car le nom ne provient pas de l'emplacement réseau correct.

DB2 pour MVS/ESA exécute l'identification du site émetteur comme faisant partie de la fonction de conversion sortante du nom d'utilisateur final, dont vous trouverez la description à la section suivante.

Sélection des noms d'utilisateurs finals

Il se peut que l'ID utilisateur transmis par le demandeur d'application ne soit pas unique dans l'ensemble du réseau SNA. Il se peut que le serveur d'applications DB2 pour MVS/ESA ait besoin d'exécuter une conversion de nom entrante pour créer des noms d'utilisateurs finals uniques sur le réseau SNA. De la même manière, le serveur d'applications DB2 pour MVS/ESA peut avoir besoin d'effectuer une conversion de nom entrante pour fournir un nom d'utilisateur final unique aux serveurs secondaires impliqués dans l'application (pour plus de détails concernant la conversion entrante de nom d'utilisateur final, reportez-vous à la section Définition de la sécurité).

La conversion de nom entrante est activée lorsque la colonne USERNAMES de la table SYSIBM.SYSLUNAMES a pour valeur 'I' (conversion entrante) ou 'B' (conversion entrante et sortante). Lorsque la conversion de nom entrante est active, DB2 pour MVS/ESA convertit l'ID utilisateur envoyé par le demandeur d'application et le nom du propriétaire du plan DB2 pour MVS/ESA (si le demandeur d'application est un autre système DB2 pour MVS/ESA).

Si le demandeur d'application envoie un ID utilisateur et un mot de passe dans le verbe APPC ALLOCATE, ceux-ci sont validés avant la conversion de l'ID utilisateur. La colonne PASSWORD dans la table SYSIBM.SYSUSERNAMES n'est pas utilisée pour la validation du mot de passe. En revanche, l'ID utilisateur et le mot de passe sont présentés au système de sécurité externe (RACF ou produit équivalent) pour validation.

Lorsque l'ID utilisateur entrant dans le verbe ALLOCATE est vérifié, DB2 pour MVS/ESA dispose de sorties d'autorisation qui vous permettent de fournir une liste d'AUTHID secondaires et d'exécuter des contrôles de sécurité supplémentaires. Pour plus de détails, reportez-vous au manuel DB2 Administration Guide.

Le processus de conversion de nom entrante recherche, dans la table SYSIBM.SYSUSERNAMES, une ligne qui doit correspondre à l'un des modèles ci-après (TYPE.AUTHID.LUNAME) :

  1. I.AUTHID.LUNAME--Utilisateur final particulier issu d'un demandeur d'application particulier
  2. I.AUTHID.espace-- Utilisateur final particulier issu de n'importe quel demandeur d'application
  3. I.espace.LUNAME--N'importe quel utilisateur final issu d'un demandeur d'application particulier

Si aucune ligne n'est trouvée, l'accès éloigné est refusé. Si une ligne est trouvée, l'accès éloigné est autorisé et le nom de l'utilisateur final est modifié pour prendre la valeur contenue dans la colonne NEWAUTHID (une valeur NEWAUTHID à blanc indique que le nom reste inchangé). Toutes les vérifications d'autorisation de ressources DB2 pour MVS/ESA (par exemple, privilèges de tables SQL) effectuées par DB2 pour MVS/ESA sont exécutées sur les noms d'utilisateurs finals convertis plutôt que sur les noms d'utilisateurs originaux.

Lorsqu'un serveur d'applications DB2 pour MVS/ESA reçoit un nom d'utilisateur final du demandeur d'application, plusieurs objectifs peuvent être atteints par le biais de la fonction de conversion de nom entrante DB2 pour MVS/ESA :

Définition de la sécurité réseau

Il existe dans LU 6.2 trois niveaux importants de sécurité :

La section Sécurité réseau, traite de la définition de la sécurité au niveau des sessions et du cryptage avec DB2 pour MVS/ESA. Le serveur d'applications DB2 pour MVS/ESA utilise la sécurité au niveau des sessions et le cryptage exactement de la même manière que le demandeur d'application DB2 pour MVS/ESA.

Le seul critère de sécurité réseau restant est la sécurité au niveau des conversations SNA. Certains aspects relatifs à la sécurité au niveau des conversations sont uniques pour un serveur d'applications DB2 pour MVS/ESA. Le serveur d'applications DB2 pour MVS/ESA joue deux rôles distincts dans la sécurité réseau :

En cas de violation de la sécurité, la LU 6.2 exige du serveur d'applications DB2 pour MVS/ESA qu'il renvoie un code de détection d'arrêt anormal SNA ('080F6051'X) au demandeur d'application. Dans la mesure où ce code de détection ne décrit pas la cause de l'arrêt anormal, DB2 pour MVS/ESA propose deux méthodes permettant d'enregistrer la cause des violations de sécurité répartie :

Sécurité du gestionnaire de bases de données

En tant que propriétaire des ressources de base de données, le serveur d'applications DB2 pour MVS/ESA contrôle les fonctions de sécurité de base de données pour les objets SQL résidant sur le serveur d'applications DB2 pour MVS/ESA. L'accès aux objets gérés par DB2 pour MVS/ESA est régi par des privilèges octroyés aux utilisateurs par l'administrateur de DB2 pour MVS/ESA ou les propriétaires des objets individuels. Les deux classes d'objets de base contrôlées par le serveur d'applications DB2 pour MVS/ESA sont les suivantes :

Lors de la création d'un module, l'option DISABLE/ENABLE vous permet de contrôler quels sont les types de connexion DB2 pour MVS/ESA en mesure d'exécuter le module. Vous pouvez utiliser les routines de sortie d'exit de sécurité RACF et DB2 pour MVS/ESA afin de permettre, de manière sélective, aux utilisateurs finals d'utiliser DDF. Vous pouvez utiliser RLF pour définir les limites de temps de traitement pour les définitions d'accès éloigné et les exécutions de SQL dynamiques.

Prenons pour exemple un module DB2 pour MVS/ESA appelé MYPKG, et appartenant à JOE. JOE peut permettre à SAL d'exécuter le module à l'aide de l'instruction GRANT USE de DB2 Universal Database for OS/390. Lorsque SAL exécute le module, il se produit ce qui suit :

Sous-système de sécurité

L'utilisation par le serveur d'applications DB2 pour MVS/ESA du sous-système de sécurité (RACF ou produit équivalent) dépend de la façon dont vous définissez la fonction de conversion de nom entrante dans la table SYSIBM.SYSLUNAMES :

Représentation des données

Vous devez vous assurer que votre sous-système DB2 pour MVS/ESA dispose de la fonction de conversion du CCSID du demandeur d'application en CCSID d'installation du sous-système DB2 pour MVS/ESA. Reportez-vous à la section Représentation des données, pour plus de détails.


[ Début de page | Page précédente | Page suivante | Table des matières | Index ]