DB2 - Connectivité - Informations complémentaires
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 :
- un demandeur DB2 pour MVS/ESA
- DB2 Connect Version 7 pouvant s'exécuter sous AIX, HP-UX, OS/2, SCO,
Solaris, Linux, Windows 9x ou Windows NT
- DB2 Universal Database Enterprise Edition Version 7 ou DB2 Universal
Database Extended - Enterprise Edition avec utilisation du support DB2 Connect
- un demandeur DDCS version 2 pouvant s'exécuter sous AIX, HP-UX, OS/2,
Solaris, Windows 3.1, Windows 3.11 pour Workgroups,
Windows 95 ou Windows NT ainsi que sous SCO, SGI ou SINIX
- un demandeur OS/400
- un demandeur DB2 pour VM
- tout autre produit prenant en charge les protocoles pour demandeur
d'application DRDA
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 :
- Le demandeur d'application est autorisé à accéder aux tables stockées
au niveau du serveur d'applications DB2 pour MVS/ESA. Le demandeur
d'application doit créer un module au niveau du serveur
d'applications DB2 pour MVS/ESA pour que l'application puisse
s'exécuter. Le serveur d'applications DB2 pour MVS/ESA
utilise le module pour localiser les instructions SQL de l'application au
moment de l'exécution.
- Le demandeur d'application peut informer le serveur
d'applications DB2 pour MVS/ESA que l'accès doit être restreint aux
activités en lecture seulement si la connexion serveur-demandeur DRDA ne prend
pas en charge le processus de validation en deux phases. Par exemple,
un demandeur V2R3 DB2 pour MVS/ESA avec un récepteur CICS informera le serveur
d'applications DB2 pour MVS/ESA que les mises à jour ne sont pas
autorisées.
- Le demandeur d'application peut aussi se voir accorder
l'autorisation d'accéder aux tables stockées au niveau d'autres
systèmes DB2 pour MVS/ESA sur le réseau utilisant l'accès défini par le
système. L'accès défini par le système permet au demandeur
d'application d'établir des connexions à plusieurs systèmes de bases
de données dans une seule unité d'oeuvre.
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 :
- Définissez le serveur d'applications sur le gestionnaire de
communications local.
- 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.
- Définissez la sécurité nécessaire.
- Prévoyez la représentation des données.
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 :
- 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.
- 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é.
- Fournissez le TPN par défaut de DRDA (X'07F6C4C2') pour chaque
demandeur d'application car DB2 pour MVS/ESA utilise cette valeur
automatiquement.
- 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.
- 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.
- 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 :
- 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', ' ');
|
- 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', ' ');
|
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.
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 :
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
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 :
- 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.
- 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é.
- 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.
- 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 :
- Le serveur secondaire n'a pas de copie du plan DB2 pour
MVS/ESA. Par conséquent, il revient au serveur d'applications DB2
pour MVS/ESA de vérifier que l'utilisateur final est autorisé à exécuter
le module au niveau du système demandeur (le serveur
d'applications).
- Les instructions SQL statiques sont exécutées dynamiquement au niveau du
serveur secondaire grâce aux privilèges accordés au propriétaire du module DB2
pour MVS/ESA, au niveau du serveur d'applications demandeur DB2 pour
MVS/ESA.
- Les instructions SQL dynamiques sont exécutées grâce aux privilèges
accordés à l'utilisateur final, au niveau du demandeur
d'application.
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
- sélection des noms d'utilisateurs finals
- paramètres de sécurité réseau
- sécurité du gestionnaire de bases de données
- sécurité assurée par un sous-système de sécurité externe
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.
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) :
- I.AUTHID.LUNAME--Utilisateur final particulier issu
d'un demandeur d'application particulier
- I.AUTHID.espace-- Utilisateur final particulier issu de
n'importe quel demandeur d'application
- 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 :
- Vous pouvez modifier un nom d'utilisateur final pour le rendre
unique. Par exemple, les instructions SQL suivantes convertissent le
nom d'utilisateur final JONES du demandeur d'application NEWYORK
(LUNAME LUNYC) en un nom différent (NYJONES).
INSERT INTO SYSIBM.SYSLUNAMES
(LUNAME, SYSMODENAME, USERSECURITY, ENCRYPTPSWDS,
MODESELECT, USERNAMES)
VALUES ('LUNYC', ' ', 'A', 'N', 'N', 'I');
INSERT INTO SYSIBM.SYSUSERNAMES
(TYPE, AUTHID, LUNAME, NEWAUTHID, PASSWORD)
VALUES ('I', 'JONES', 'LUNYC', 'NYJONES', ' ');
- Vous pouvez modifier le nom de l'utilisateur final pour que, dans un
groupe, tous les utilisateurs soient représentés par un nom unique. Par
exemple, vous pouvez représenter tous les utilisateurs du demandeur
d'application NEWYORK (LUNAME LUNYC) par le nom d'utilisateur
NYUSER. Cela vous permet d'octroyer des privilèges SQL au nom
NYUSER et de contrôler l'accès SQL accordé aux utilisateurs de
NEWYORK.
INSERT INTO SYSIBM.SYSLUNAMES
(LUNAME, SYSMODENAME, USERSECURITY, ENCRYPTPSWDS,
MODESELECT, USERNAMES)
VALUES ('LUNYC', ' ', 'A', 'N', 'N', 'I');
INSERT INTO SYSIBM.SYSUSERNAMES
(TYPE, AUTHID, LUNAME, NEWAUTHID, PASSWORD)
VALUES ('I', ' ', 'LUNYC', 'NYUSER', ' ');
- Vous pouvez limiter le nombre de noms d'utilisateurs finals transmis
par un demandeur d'application donné. Le fait d'utiliser la
fonction de conversion de nom d'utilisateur final permet d'exécuter
l'identification du site émetteur décrite à la section Identification du site émetteur. Par exemple, les instructions SQL qui suivent
n'autorisent comme utilisateurs finals provenant de l'demandeur
d'application NETWORK que SMITH et JONES. Tout autre nom se voit
refuser l'accès car il n'est pas mentionné dans la table
SYSIBM.SYSUSERNAMES.
INSERT INTO SYSIBM.SYSLUNAMES
(LUNAME, SYSMODENAME, USERSECURITY, ENCRYPTPSWDS,
MODESELECT, USERNAMES)
VALUES ('LUNYC', ' ', 'A', 'N', 'N', 'I');
INSERT INTO SYSIBM.SYSUSERNAMES
(TYPE, AUTHID, LUNAME, NEWAUTHID, PASSWORD)
VALUES ('I', 'SMITH', 'LUNYC', ' ', ' ');
INSERT INTO SYSIBM.SYSUSERNAMES
(TYPE, AUTHID, LUNAME, NEWAUTHID, PASSWORD)
VALUES ('I', 'JONES', 'LUNYC', ' ', ' ');
- Vous pouvez limiter le nombre de demandeurs d'application autorisés à
se connecter au serveur d'applications DB2 pour MVS/ESA. Il
s'agit là d'une autre fonction d'identification du site
émetteur. Dans l'exemple qui suit, n'importe quel nom
d'utilisateur final envoyé par le demandeur d'application NEWYORK
(LUNYC) ou CHICAGO (LUCHI) est accepté. Les autres demandeurs
d'application se voient refuser l'accès car la ligne par défaut
SYSIBM.SYSLUNAMES indique la conversion de nom entrante pour toutes les
demandes entrantes.
INSERT INTO SYSIBM.SYSLUNAMES
(LUNAME, SYSMODENAME, USERSECURITY, ENCRYPTPSWDS,
MODESELECT, USERNAMES)
VALUES (' ', ' ', 'A', 'N', 'N', 'I');
INSERT INTO SYSIBM.SYSUSERNAMES
(TYPE, AUTHID, LUNAME, NEWAUTHID, PASSWORD)
VALUES ('I', ' ', 'LUNYC', ' ', ' ');
INSERT INTO SYSIBM.SYSUSERNAMES
(TYPE, AUTHID, LUNAME, NEWAUTHID, PASSWORD)
VALUES ('I', ' ', 'LUCHI', ' ', ' ');
Il existe dans LU 6.2 trois niveaux importants de
sécurité :
- la sécurité au niveau des sessions
- la sécurité au niveau des conversations
- le cryptage
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 tant que demandeur auprès de serveurs secondaires, le serveur
d'applications DB2 pour MVS/ESA est chargé d'émettre des demandes
APPC contenant les paramètres de sécurité de niveau conversations SNA requis
par les serveurs secondaires. Le serveur d'applications DB2 pour
MVS/ESA utilise la colonne USERNAMES des tables SYSIBM.SYSLUNAMES et
SYSIBM.SYSUSERNAMES pour définir les conditions requises pour la
sécurité de niveau conversations SNA pour chaque serveur secondaire.
Les explications détaillées de ces définitions sont identiques à celles
contenues dans la section Sécurité réseau.
- En tant que serveur pour le demandeur d'application, le serveur
d'applications DB2 pour MVS/ESA dicte les conditions requises pour la
sécurité de niveau conversations SNA pour le demandeur
d'application. DB2 pour MVS/ESA utilise la colonne USERSECURITY de
la table SYSIBM.SYSLUNAMES pour déterminer la sécurité des
conversations requises à partir de chaque demandeur d'application sur le
réseau. Les valeurs suivantes sont utilisées dans la colonne
USERSECURITY :
- C
- Cette valeur indique que DB2 pour MVS/ESA requiert que le demandeur
d'application envoie un ID utilisateur et un mot de passe (LU 6.2
SECURITY=PGM) avec chaque demande de base de données distribuée. Si la
colonne ENCRYPTPSWDS de la table SYSIBM.SYSLUNAMES contient un
'Y', DB2 pour MVS/ESA suppose que le mot de passe est dans un format
codé RACF (possible uniquement dans le cas d'un demandeur
d'application DB2 pour MVS/ESA). Si la colonne ENCRYPTPSWDS ne
contient pas de 'Y', DB2 pour MVS/ESA s'attend à trouver le mot
de passe dans le format LU 6.2 standard (représentation de
caractères EBCDIC). Dans les deux cas, DB2 pour MVS/ESA transmet les
valeurs correspondant à l'ID utilisateur et au mot de passe au
sous-système de sécurité pour validation. Il vous faut un sous-système
de sécurité en mesure de vérifier le mot de passe et l'ID utilisateur
APPC ; par exemple, RACF a une fonction de vérification des mots de
passe et des ID utilisateurs APPC. Si le sous-système de sécurité
rejette le couple ID-mot de passe, l'accès à la base de données répartie
est refusé.
- Toute autre valeur
- Indique que le demandeur d'application est autorisé à envoyer un ID
utilisateur déjà vérifié (LU 6.2 SECURITY=SAME) ou un ID utilisateur et
un mot de passe (LU 6.2 SECURITY=PGM). Si un ID utilisateur et
un mot de passe sont envoyés, DB2 pour MVS/ESA les traite de la façon décrite
précédemment pour la valeur 'C'. Si la demande contient
uniquement un ID utilisateur, le sous-système de sécurité est appelé pour
authentifier l'utilisateur à moins que la table sysusernames
ne soit utilisée pour la gestion des ID utilisateur entrants.
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 :
- Un message DSNL030I est émis, qui fournit la LUWID du demandeur ainsi
qu'un code anomalie DB2 décrivant l'arrêt anormal. DSNL030I
comprend également le AUTHID, si celui-ci est connu, envoyé à partir de la
demande d'application qui a été rejetée.
- Une alerte est enregistrée dans la base de données du moniteur matériel
NETVIEW, qui contient les mêmes informations que celles contenues dans le
message DSNL030I.
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 :
- DB2 pour MVS/ESA vérifie que SAL dispose des droits USE pour le
module.
- SAL peut exécuter chaque instruction SQL statique dans le module parce que
JOE dispose des privilèges d'accès aux objets SQL pour la création du
module.
- Si le module a des instructions SQL dynamiques, SAL doit disposer de ses
propres droits d'accès aux tables. Par exemple, SAL ne peut pas
exécuter SELECT * FROM JOE.TABLE5 tant qu'elle ne
dispose pas des droits d'accès en lecture à JOE.TABLE5.
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 :
- Si vous indiquez 'I' ou 'B' pour la colonne USERNAMES, la
fonction de conversion de nom entrante est active et DB2 pour MVS/ESA suppose
que l'administrateur de DB2 pour MVS/ESA utilise la conversion de nom
entrante pour exécuter une partie de la mise en place de la sécurité
système. Le sous-système de sécurité externe est appelé uniquement si
le demandeur d'application envoie une demande contenant à la fois
l'ID utilisateur et le mot de passe (SECURITY=PGM). Il vous faut
un sous-système de sécurité en mesure de vérifier le mot de passe et l'ID
utilisateur APPC ; par exemple, RACF a une fonction de vérification
des mots de passe et des ID utilisateurs APPC.
Si la demande émanant du demandeur d'application contient uniquement
un ID utilisateur (SECURITY=SAME), le système de sécurité externe n'est
en aucun cas appelé car les règles de conversion de nom entrante déterminent
les utilisateurs qui sont autorisés à se connecter au serveur
d'applications DB2 pour MVS/ESA.
- Si vous indiquez une valeur autre que 'I' ou 'B' pour la
colonne USERNAMES, le sous-système de sécurité est vérifié comme
suit :
- Lors de la réception d'une demande de base de données répartie
émanant du demandeur d'application, DB2 pour MVS/ESA appelle le système
de sécurité externe pour valider l'ID de l'utilisateur final (et le
mot de passe, le cas échéant).
- Le système de sécurité externe est appelé pour vérifier que
l'utilisateur final est autorisé à se connecter au sous-système DB2 pour
MVS/ESA.
- Dans les deux cas, une sortie d'autorisation est émise pour fournir
une liste d'ID autorisation secondaire. Pour plus de détails,
reportez-vous au manuel DB2 Administration
Guide.
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 ]