DB2 - Connectivité - Informations complémentaires
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 :
- un demandeur DB2 Universal Database for OS/390
- DB2 Connect
- DB2 Universal Database Enterprise Edition Version 7 ou DB2 Universal
Database Extended - Enterprise Edition avec utilisation du support DB2 Connect
- un demandeur DB2 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 Macintosh, SCO, SGI ou
SINIX. DDCS multi-utilisateur version 2.3, DDCS
mono-utilisateur version 2.3 et DDCS pour Windows version
2.4 offrent cette fonction
- un demandeur OS/400
- un demandeur DB2 pour VM
- tout produit prenant en charge les protocoles pour demandeur
d'application DRDA
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 :
- Le demandeur d'application est autorisé à accéder aux tables stockées
au niveau du serveur d'applications DB2 Universal Database for
OS/390. Le demandeur d'application doit créer un module au niveau
du serveur d'applications DB2 Universal Database for OS/390 pour que
l'application puisse s'exécuter. Le serveur
d'applications DB2 Universal Database for OS/390 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 Universal Database for OS/390 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 DDCS V2R3 avec un récepteur CICS
informera le serveur d'applications DB2 Universal Database for OS/390 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 Universal Database for OS/390 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 Universal Database for OS/390
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 Universal Database for OS/390 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. La présente section traite des connexions SNA. 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 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.
- 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é.
- 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.
- 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
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.
- 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 :
- 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', ' ');
|
- 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', ' ');
|
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.
- 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.
- Un exemple de définition de fichier d'amorçage est présenté à la Figure 18.
- 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(' ')
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
- 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 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.
|
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).
- I.AUTHID.LINKNAME-- 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.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 :
- 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.LUNAMES
(LUNAME, SYSMODENAME, SECURITY_IN, ENCRYPTPSWDS,
MODESELECT, USERNAMES)
VALUES ('LUNYC', ' ', 'A', 'N', 'N', 'I');
INSERT INTO SYSIBM.USERNAMES
(TYPE, AUTHID, LINKNAME, 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.LUNAMES
(LUNAME, SYSMODENAME, SECURITY_IN, ENCRYPTPSWDS,
MODESELECT, USERNAMES)
VALUES ('LUNYC', ' ', 'A', 'N', 'N', 'I');
INSERT INTO SYSIBM.USERNAMES
(TYPE, AUTHID, LINKNAME, 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
admettent uniquement SMITH et JONES comme noms d'utilisateurs finals du
demandeur d'application NEWYORK. Tout autre nom se voit refuser
l'accès car il n'est pas mentionné dans la table
SYSIBM.USERNAMES.
INSERT INTO SYSIBM.LUNAMES
(LUNAME, SYSMODENAME, SECURITY_IN, ENCRYPTPSWDS,
MODESELECT, USERNAMES)
VALUES ('LUNYC', ' ', 'A', 'N', 'N', 'I');
INSERT INTO SYSIBM.USERNAMES
(TYPE, AUTHID, LINKNAME, NEWAUTHID, PASSWORD)
VALUES ('I', 'SMITH', 'LUNYC', ' ', ' ');
INSERT INTO SYSIBM.USERNAMES
(TYPE, AUTHID, LINKNAME, NEWAUTHID, PASSWORD)
VALUES ('I', 'JONES', 'LUNYC', ' ', ' ');
- Vous pouvez restreindre le nombre de demandeurs d'application
autorisés à se connecter au serveur d'applications DB2 Universal Database
for OS/390. 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é.
D'autres demandeurs d'application se voient refuser l'accès car
la ligne par défaut SYSIBM.LUNAMES indique la conversion de nom
entrante pour toutes les demandes entrantes.
INSERT INTO SYSIBM.LUNAMES
(LUNAME, SYSMODENAME, SECURITY_IN, ENCRYPTPSWDS,
MODESELECT, USERNAMES)
VALUES (' ', ' ', 'A', 'N', 'N', 'I');
INSERT INTO SYSIBM.USERNAMES
(TYPE, AUTHID, LINKNAME, NEWAUTHID, PASSWORD)
VALUES ('I', ' ', 'LUNYC', ' ', ' ');
INSERT INTO SYSIBM.USERNAMES
(TYPE, AUTHID, LINKNAME, NEWAUTHID, PASSWORD)
VALUES ('I', ' ', 'LUCHI', ' ', ' ');
Pour les connexions SNA, la LU 6.2 offre trois grandes fonctions de
sécurité réseau :
- Sécurité au niveau des sessions
- Sécurité au niveau des conversations
- 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 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 tant que demandeur auprès de serveurs secondaires, le serveur
d'applications DB2 Universal Database for OS/390 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 Universal Database for OS/390 utilise la
colonne USERNAMES des tables SYSIBM.LUNAMES et SYSIBM.USERNAMES
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 Universal Database for OS/390 dicte les conditions
requises pour la sécurité de niveau conversations SNA pour le demandeur
d'application. DB2 Universal Database for OS/390 utilise la
colonne USERSECURITY de la table SYSIBM.LUNAMES 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 Universal Database for OS/390 demande au
demandeur d'application d'envoyer un ID utilisateur et un mot de
passe (LU 6.2 SECURITY=PGM) avec chaque demande portant sur une base de
données distribuée. Si la colonne ENCRYPTPSWDS de la table
SYSIBM.LUNAMES contient un 'Y', DB2 Universal Database for
OS/390 suppose que le mot de passe est dans un format codé RACF (possible
uniquement dans le cas d'un demandeur d'application DB2 Universal
Database for OS/390). Si la colonne ENCRYPTPSWDS ne contient pas de
'Y', DB2 Universal Database for OS/390 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 Universal Database for
OS/390 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 Universal Database for OS/390 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 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 :
- 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 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 :
- DB2 Universal Database for OS/390 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 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 :
- Si vous indiquez 'I' ou 'B' pour la colonne USERNAMES, la
fonction de conversion de nom entrante est active et DB2 Universal Database
for OS/390 suppose que l'administrateur de DB2 Universal Database for
OS/390 utilise la conversion de nom entrante pour exécuter une partie de la
mise en place de la sécurité. 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 Universal Database for OS/390.
- 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 Universal Database for OS/390
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
Universal Database for OS/390.
- 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 Universal Database for OS/390 Administration
Guide.
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 ]