DB2 - Connectivité - Informations complémentaires

Configuration du serveur d'applications

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

Pour n'importe quel demandeur d'application connecté à un serveur d'applications DB2 Universal Database for OS/390, 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 Universal Database for OS/390 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 Universal Database for OS/390 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 (SNA)

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. La présente section traite des connexions SNA. 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 Universal Database for OS/390. Le procédé d'enregistrement de ces noms dans DB2 Universal Database for OS/390 et VTAM est identique à celui décrit à la section Définition du système local (SNA). Le RDB_NAME choisi pour DB2 Universal Database for OS/390 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 Universal Database for OS/390 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 Universal Database for OS/390. 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 Universal Database for OS/390 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 Universal Database for OS/390. 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.LUMODES 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 DB2 Universal Database for OS/390 afin d'identifier les demandeurs d'application autorisés à se connecter au serveur d'applications DB2 Universal Database for OS/390. 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.LUNAMES 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 communications (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 Universal Database for OS/390) 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 25, illustre comment utiliser la base de données de communications pour spécifier SECURITY=SAME pour le système DALLAS tout en appliquant SECURITY=PGM pour tous les autres demandeurs.

      Figure 25. Définition de valeurs par défaut pour les connexions de demandeurs d'application (SNA)

      INSERT INTO SYSIBM.LUNAMES
           (LUNAME, SYSMODENAME, SECURITY_IN, ENCRYPTPSWDS, MODESELECT, USERNAMES)
      VALUES ('LUDALLAS', ' ', 'A', 'N', 'N', ' ');
      INSERT INTO SYSIBM.LUNAMES
           (LUNAME, SYSMODENAME, SECURITY_IN, 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.LUNAMES. En l'absence de ligne par défaut (ligne contenant un nom de LU à blanc), DB2 Universal Database for OS/390 requiert une ligne dans la table SYSIBM.LUNAMES 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.LUNAMES indiquant que l'identification du site émetteur est requise (colonne USERNAMES ayant pour valeur 'I' ou 'B'). Il en résulte que DB2 Universal Database for OS/390 limite l'accès aux demandeurs d'application et utilisateurs finals identifiés dans la table SYSIBM.USERNAMES, 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.LUNAMES, mais vous ne voulez pas que DB2 Universal Database for OS/390 utilise cette ligne pour permettre un accès non restreint au serveur d'applications DB2 Universal Database for OS/390.

      Dans la Figure 26, aucune ligne ne contient de valeur à blanc dans la colonne LUNAME, par conséquent DB2 Universal Database for OS/390 refuse l'accès à toute LU autre que LUDALLAS ou LUNYC.

      Figure 26. Identification de connexions de demandeurs d'application individuelles (SNA)

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

Définition du serveur d'applications (TCP/IP)

Pour que le serveur d'applications puisse recevoir des demandes de bases de données réparties sur des connexions TCP/IP, il doit être défini sur le sous-système TCP/IP local et avoir une valeur RDB_NAME unique. En outre, le fichier d'amorçage de DB2 Universal Database for OS/390 doit comprendre les paramètres nécessaires, et il se peut que vous deviez effectuer des mises à jour dans la base de données de communications de DB2 Universal Database for OS/390.

  1. Pour obtenir des informations sur la configuration de TCP/IP sur le serveur d'applications, reportez-vous au manuel DB2 for OS/390 Installation Reference. La configuration du demandeur d'application est décrite dans les manuels DB2 Connect Enterprise Edition pour OS/2 et Windows - Mise en route et DB2 Connect Personal Edition - Mise en route.
  2. Un exemple de définition de fichier d'amorçage est présenté à la Figure 18.
  3. Aucune mise à jour de la base de données de communications n'est requise si vous n'utilisez que les connexions de bases de données entrantes ; ainsi, si vous souhaitez n'utiliser DB2 Universal Database for OS/390 qu'en tant que serveur, il n'est pas nécessaire de remplir la base de données de communications et les valeurs par défaut peuvent être utilisées. Vous trouverez ci-après un exemple simple de mise à jour de SYSIBM.IPNAMES.

    Si vous souhaitez autoriser les demandes de connexion de base de données entrantes pour les noeuds TCP/IP, vous pouvez utiliser une commande SQL comme celle-ci pour mettre à jour cette table :

    INSERT INTO SYSIBM.IPNAMES (LINKNAME) VALUES('        ')                                   
    

Définition de la sécurité

Lorsqu'un demandeur d'application achemine une demande portant sur une base de données répartie vers le serveur d'applications DB2 Universal Database for OS/390, les critères de sécurité suivants peuvent être pris en compte :

Identification du site émetteur

Lorsqu'un serveur d'applications DB2 Universal Database for OS/390 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 Universal Database for OS/390 exécute l'identification du site émetteur dans le cadre de la conversion sortante de nom d'utilisateur final, dont vous trouverez la description à la section suivante.
Remarque :L'identification de site entrant et de site émetteur n'est pas effectuée pour les demandes entrantes TCP/IP.

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 Universal Database for OS/390 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 Universal Database for OS/390 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 définition de la colonne USERNAMES de la table SYSIBM.LUNAMES ou SYSIBM.IPNAMES a pour valeur 'I' (conversion entrante) ou 'B' (conversion entrante et sortante). Lorsque la conversion de nom entrante est active, DB2 Universal Database for OS/390 convertit l'ID utilisateur envoyé par le demandeur d'application et le nom du propriétaire du plan DB2 Universal Database for OS/390 (si le demandeur d'application est un autre système DB2 Universal Database for OS/390).

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.USERNAMES 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 Universal Database for OS/390 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 Universal Database for OS/390 Administration Guide.

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

  1. I.AUTHID.LINKNAME-- 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.LINKNAME-- 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 Universal Database for OS/390 (par exemple, privilèges de tables SQL) effectuées par DB2 Universal Database for OS/390 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 Universal Database for OS/390 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 de DB2 Universal Database for OS/390 :

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

Pour les connexions SNA, la LU 6.2 offre trois grandes fonctions de sécurité réseau :

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

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 Universal Database for OS/390. Le serveur d'applications DB2 Universal Database for OS/390 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 Universal Database for OS/390 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 Universal Database for OS/390 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 Universal Database for OS/390 contrôle les fonctions de sécurité de base de données pour les objets SQL résidant sur le serveur d'applications DB2 Universal Database for OS/390. L'accès aux objets gérés par DB2 Universal Database for OS/390 est régi par des privilèges octroyés aux utilisateurs par l'administrateur de DB2 Universal Database for OS/390 ou les propriétaires des objets individuels. Les deux classes d'objets de base contrôlées par le serveur d'applications DB2 Universal Database for OS/390 sont les suivantes :

Lors de la création d'un module, l'option DISABLE/ENABLE vous permet de contrôler les types de connexion DB2 Universal Database for OS/390 en mesure d'exécuter le module. Vous pouvez utiliser les routines d'exit de sécurité RACF et DB2 Universal Database for OS/390 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 Universal Database for OS/390 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 Universal Database for OS/390 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.LUNAMES :

Représentation des données

Vous devez vous assurer que votre sous-système DB2 Universal Database for OS/390 dispose de la fonction de conversion du CCSID du demandeur d'application en CCSID d'installation du sous-système DB2 Universal Database for OS/390. 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 ]