DB2 - Connectivité - Informations complémentaires

Configuration du serveur d'applications

Le support pour serveur d'applications disponible sur le système AS/400 lui permet de jouer le rôle d'un serveur pour les demandeurs d'application DRDA. Le demandeur d'application connecté à un serveur d'applications DB2 Universal Database pour AS/400 peut être n'importe quel client prenant en charge les protocoles DRDA.

Le demandeur d'application est autorisé à accéder aux tables stockées en local sur le serveur d'applications DB2 Universal Database pour AS/400. Il doit créer un module sur ce dernier avant qu'une instruction SQL ne puisse être exécutée. Le serveur d'applications DB2 Universal Database pour AS/400 utilise le module contenant les instructions SQL de l'application au moment de l'exécution du programme.

Définition des données réseau

Pour pouvoir traiter les demandes de base de données répartie sur le serveur d'applications AS/400, vous devez définir le nom de la base de données du serveur d'applications dans le répertoire des bases de données relationnelles. Pour les communications SNA, vous devez définir le système de serveur d'applications, ainsi que les tailles de RU et la régulation. Pour les communication TCP/IP prises en charge depuis DB2 Universal Database pour AS/400 version 4.2, reportez-vous au Chapitre Connexion de DB2 Universal Database pour AS/400 au sein d'un réseau DRDA via TCP/IP.

Définition du nom de la base de données du serveur d'applications

L'identification de la base de données du serveur d'applications (sur ce dernier) s'effectue de la même façon que pour la base de données du demandeur d'application (sur celui-ci). A l'aide de la commande ADDRDBDIRE (Ajouter poste répertoire RDB), indiquez *LOCAL comme nom d'emplacement éloigné.

Définition du serveur d'applications sur le réseau

Pour un accès via SNA, la définition du serveur d'applications sur le réseau est identique à la définition du demandeur d'application sur le réseau. Vous devez créer des descriptions appropriées de ligne, de contrôleurs, d'unités et de mode afin de définir à la fois le serveur d'applications et le demandeur d'application émetteur des demandes. Pour plus de détails sur la définition du serveur d'application, reportez-vous aux sections Définition du système local pour DB2 Universal Database pour AS/400, et Définition du système éloigné pour DB2 Universal Database pour AS/400. Consultez également le manuel AS/400 Distributed Database Programming.

Le programme de transaction utilisé pour démarrer une base de données du serveur d'applications AS/400 porte le nom DRDA par défaut X'07F6C4C2'. Ce nom de programme de transaction est défini dans le système AS/400 pour démarrer le serveur d'applications. Le port est le paramètre correspondant pour les connexions TCP/IP (lorsque DB2/400 prend en charge ce protocole). DB2/400 utilise toujours en tant que serveur le port identifié 446 DRDA.

Définition de la taille de RU et de la régulation

Vous devez passer en revue les définitions réseau pour déterminer si le réseau de bases de données réparties affecte le réseau existant. Les points à prendre en compte sont les mêmes pour le serveur d'applications et le demandeur d'application.

Définition de la sécurité

Lorsqu'un demandeur d'application achemine une requête portant sur une base de données répartie vers le serveur d'applications AS/400, les critères de sécurité suivants peuvent être pris en compte :

Sélection des noms d'utilisateurs finals

Le demandeur d'application transmet un ID utilisateur au serveur d'applications pour permettre le contrôle des droits d'accès. Le travail exécuté sur le serveur d'applications AS/400 emploie cet ID utilisateur ou, dans certaines circonstances, un ID utilisateur par défaut.

Le serveur d'applications AS/400 n'assure pas de conversion d'ID utilisateur entrante pour résoudre les conflits éventuels entre les ID utilisateur qui ne sont pas uniques au sein du réseau, ni pour regrouper plusieurs utilisateurs sous un même identificateur. Chaque ID utilisateur envoyé par un demandeur d'application doit être reconnu sur le serveur d'applications. Une technique de regroupement des requêtes entrantes sous un même ID utilisateur, avec perte partielle de sécurité, consiste à spécifier un ID utilisateur par défaut dans une entrée du sous-système de communication qui gère les demandes de démarrage de travaux éloignés. Reportez-vous aux descriptions des commandes ADDCMNE et CHGCMNE dans le manuel AS/400 CL Reference.

Sécurité réseau SNA

Il existe trois principales fonctions de sécurité réseau pour les unités logiques LU 6.2 :

Le serveur d'applications DB2 Universal Database pour AS/400 utilise la sécurité au niveau des sessions, exactement comme le demandeur d'application DB2 Universal Database pour AS/400.

Le serveur d'applications contrôle les niveaux de sécurité SNA utilisés pour les conversations. Le paramètre SECURELOC de la description d'unité APPC ou la valeur de sécurité indiquée dans la liste d'emplacements éloignés APPN détermine les éléments acceptés en provenance du demandeur d'application lors d'une conversation.

Les options possibles pour les conversations SNA sont les suivantes :

SECURITY=SAME
Egalement connue sous le nom de "sécurité déjà vérifiée", cette option implique que seul l'ID utilisateur est requis par le serveur d'applications. Aucun mot de passe n'est transmis. Utilisez ce niveau de sécurité sur le serveur d'applications en attribuant la valeur *YES au paramètre SECURELOC dans la description d'unité APPC ou au paramètre d'emplacement protégé dans la liste d'emplacements éloignés APPN.

SECURITY=PGM
Cette option implique qu'à la fois l'ID utilisateur et le mot de passe sont requis par le serveur d'applications. Utilisez ce niveau de sécurité sur le serveur d'applications en attribuant la valeur *NONE au paramètre SECURELOC dans la description d'unité APPC ou la valeur *NO au paramètre d'emplacement protégé.

SECURITY=NONE
Aucun ID utilisateur ni mot de passe n'est requis par le serveur d'applications. La conversation peut s'effectuer à l'aide d'un profil utilisateur par défaut sur le serveur d'applications. Pour utiliser cette option, indiquez un profil utilisateur par défaut dans le répertoire des communications du sous-système et attribuez la valeur *NO au paramètre SECURELOC ou au paramètre d'emplacement protégé.

Les services SNADS nécessitent la définition d'un ID utilisateur par défaut. Ils doivent donc disposer de leur propre sous-système si vous n'utilisez pas d'ID utilisateur par défaut pour les applications DRDA.

Reportez-vous à la section Sélection des noms d'utilisateurs finals, pour connaître l'une des techniques de regroupement des demandes de démarrage de travaux entrantes sous un même ID utilisateur. Cette technique n'entraîne pas la vérification de l'ID utilisateur transmis par le demandeur d'application. Le démarrage du travail sur le serveur d'applications s'effectue sous l'ID utilisateur par défaut et l'utilisateur qui a demandé la connexion à partir du serveur d'application peut accéder à ce dernier même si son ID utilisateur dispose de droits restreints. Pour que cela soit possible, le serveur d'applications doit être défini comme un emplacement non protégé, un ID utilisateur par défaut doit être spécifié dans le répertoire de communications du sous-système AS/400 et le demandeur d'application doit être configuré pour transmettre uniquement un ID utilisateur lors du traitement de la connexion. Si un mot de passe est transmis, l'ID utilisateur qui l'accompagne est utilisé à la place de l'ID utilisateur par défaut.

Les entrées du répertoire de communications du sous-système AS/400 se distinguent en fonction de l'unité et du nom de mode utilisés pour démarrer la conversation. Si vous affectez un ID utilisateur par défaut distinct aux différentes combinaisons unité/mode, les utilisateurs peuvent être regroupés en fonction du mode de communication avec le serveur d'applications.

Le système AS/400 offre également une fonction de sécurité réseau utilisée uniquement pour la gestion des bases de données et des fichiers répartis. Il existe un attribut réseau pour l'accès à ces types de systèmes qui entraîne le rejet de toutes les tentatives d'accès ou bien qui autorise un contrôle objet-par-objet de la sécurité par le système.

Sécurité réseau TCP/IP

DB2 Universal Database pour AS/400 version 4.2 comporte une nouvelle commande appelée CRTDDMTCPA. Elle vous permet d'indiquer si un serveur accepte ou non les demandes de connexion TCP/IP sans mot de passe.

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

Toutes les procédures de sécurité sont gérées par la fonction de sécurité du système d'exploitation OS/400.

Sécurité système

L'AS/400 ne dispose pas d'un sous-système de sécurité externe. La gestion de la sécurité est assurée dans son ensemble par la fonction de sécurité de l'OS/400, qui fait partie intégrante du système d'exploitation. Ce dernier contrôle les droits d'accès sur tous les objets présents sur le système (programmes, modules, tables, vues et collections).

Le serveur d'applications contrôle les accès aux objets résidant sur ce dernier. Ce contrôle s'effectue en fonction de l'ID utilisateur qui démarre le travail sur le serveur d'applications. La section Sélection des noms d'utilisateurs finals, décrit comment cet ID utilisateur est déterminé.

La sécurité des accès aux objets peut être gérée à l'aide des commandes CL de gestion des droits sur les objets et des instructions SQL GRANT et REVOKE. Il s'agit des commandes CL GRTOBJAUT (Octroyer droits sur un objet) et RVKOBJAUT (Révoquer droits sur un objet), que vous pouvez utiliser pour tout objet résidant sur le système. Les instructions GRANT et REVOKE, en revanche, ne s'appliquent qu'aux objets SQL : tables, vues et modules. Par conséquent, si vous devez modifier les droits d'accès à d'autres objets que ces derniers (à des programmes ou des collections, par exemple), utilisez les commandes GRTOBJAUT et RVKOBJAUT.

Lorsque des objets sont créés sur le système, les utilisateurs se voient octroyer des droits d'accès par défaut à ces derniers : le créateur d'une table, d'une vue ou d'un module reçoit tous les droits sur cet objet, tandis que le public (c'est-à-dire tous les autres ID utilisateur) se voit octroyer les mêmes droits que ceux dont il dispose sur la collection ou la bibliothèque dans laquelle l'objet est créé.

Les droits sur les objets auxquels font référence les instructions statiques ou dynamiques d'un module sont vérifiés au moment de l'exécution de ce module. Si le créateur du module ne dispose pas d'un droit d'accès aux objets référencés, des messages d'avertissement sont renvoyés lorsque le module est créé. Au moment de l'exécution, l'utilisateur qui exécute le module prend les mêmes droits d'accès que le créateur du module. Si ce dernier est autorisé à accéder à une table mais que l'utilisateur qui exécute le module ne l'est pas, il reçoit le même droit que le créateur du module sur la table et peut donc utiliser cette dernière.

Pour plus de détails sur la sécurité système, reportez-vous au manuel AS/400 Security - Reference.

Représentation des données

Les produits prenant en charge l'architecture DRDA effectuent automatiquement les opérations de conversion requises sur le serveur d'applications. Pour que cela soit possible, il est toutefois nécessaire que le CCSID du serveur d'applications soit convertible par le demandeur d'application.

Sur un serveur d'applications, prêtez attention au CCSID associé aux éléments suivants :


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