[z/OS]

Sécurité de couche Secure Sockets Layer pour WebSphere Application Server pour z/OS

Pour pouvoir aborder cette rubrique, vous devez connaître le fonctionnement du protocole SSL (Secure Sockets Layer) et des services de chiffrement System SSL sous z/OS. Le protocole SSL est utilisé par plusieurs composants dans WebSphereApplication Server afin de garantir sécurité et confidentialité. Ces composants incluent le transport HTTP intégré, l'ORB (Object Request Broker) (client et serveur) et le client LDAP (Lightweight Directory Access Protocol) sécurisé. La configuration de SSL diffère selon qu'elle est effectuée sur le client ou le serveur avec WebSphere Application Server. Si vous souhaitez bénéficier en plus de la sécurité des communications protégées et de l'authentification des utilisateurs au sein d'un réseau, vous pouvez utiliser la sécurité SSL.

SSL fait partie de la sécurité fournie par WebSphere Application Server pour z/OS. Il est activé lorsque la sécurité administrative est activée. Lors de l'activation de lasécurité administrative, SSL est toujours utilisé par le sous-système d'administration pour sécuriser les commandes d'administration, la console d'administration et les communications entre les processus WebSphereApplication Server.

L'environnement d'exécution de WebSphere Application Server pour z/OS peut utiliser SSL en option lorsque la sécurité du serveur est activée dans les cas suivants :
  • SSL permet de protéger l'application Web lorsque la confidentialité est spécifiée en tant que contrainte de sécurité d'application Web. Une garantie de transport CONFIDENTIAL ou INTEGRAL permet de s'assurer que la communication entre le client Web et le serveur Web est sécurisée et établie via le protocole HTTPS (HTTP SSL). De plus, vous pouvez utiliser SSL pour effectuer l'authentification client lorsque la contrainte de sécurité (CLIENT_CERT) est spécifiée au cours du déploiement de l'application.
  • SSL permet de protéger les demandes IIOP (Inter-ORB Protocol) lorsque SSL/TLS est pris en charge (ou requis) dans les paramètres de transport CSIv2 (Common Secure Interoperability version 2). Pour définir ces paramètres, cliquez sur Sécurité > Sécurité globale. Dans la section Sécurité RMI/IIOP, cliquez sur Transport des communications entrantes CSIv2 ou Transport des communications sortantes CSIv2.
  • SSL permet de protéger les communications entre un client et un serveur LDAP lorsque le registre d'utilisateurs actif est LDAP.
Lors de la configuration de SSL, il existe deux types de répertoire SSL dans WebSphere Application Server pour z/OS. Le type de répertoire est lié aux services sous-jacents utilisés pour traiter SSL.
  • Le répertoire JSSE (Java™ Secure Socket Extension) doit être sélectionné en tant que type de répertoire SSL pour les demandes d'administration utilisant le connecteur HTTP/SOAP. Les répertoires JSSE peuvent (après application de l'APAR PQ77586) indiquer un fichier de clés SAF du magasin de tiers dignes de confiance ou du magasin de relations dignes de confiance, ou bien indiquer un fichier du système hiérarchique de fichiers (HFS).
Remarque : Tous les répertoires de configuration SSL de type System Secure Sockets Layer (SSSL) type, à l'exception de ceux appartenant au démon, sont convertis vers le type Java Secure Socket Extension (JSSE). System SSL (SSSL) est utilisé uniquement par l'espace d'adressage du démon car ce dernier s'exécute sans machine virtuelle Java (JVM) et JSSE est uniquement pris en charge dans Java.

Cette rubrique décrit brièvement le protocole SSL et son mode de fonctionnement sous z/OS. Pour toute information sur le protocole SSL, connectez-vous au site Web suivant : http://home.netscape.com/eng/ssl3/ssl-toc.html

Secure Sockets Layer (SSL) est utilisé par plusieurs composants de WebSphere Application Server pour établir des relations de confiance et la confidentialité des données. Ces composants correspondent au transport HTTP intégré, à l'ORB (client et serveur) et au client LDAP sécurisé. La configuration de SSL diffère selon qu'elle est effectuée sur le client ou le serveur avec WebSphere Application Server. Si vous souhaitez bénéficier en plus de la sécurité des communications protégées et de l'authentification des utilisateurs au sein d'un réseau, vous pouvez utiliser la sécurité SSL (Secure Sockets Layer). La prise en charge de SSL dans WebSphere Application Server pour z/OS a plusieurs objectifs :
  • Fournir des moyens conformes aux normes de l'industrie de protéger la sécurité des messages qui circulent sur le réseau. Cette notion est souvent désignée sous l'appellation TLS (Transport Layer Security). La fonction TLS assure la confidentialité et l'intégrité des données entre deux applications qui communiquent entre elles. La protection s'effectue dans une couche du logiciel placée au-dessus du protocole de transport de base (TCP/IP, par exemple).

    SSL assure la sécurité des liaisons par le biais de la technologie de chiffrement qui garantit l'intégrité des messages sur un réseau. Les communications étant chiffrées entre les deux parties, un tiers ne peut pas falsifier les messages. SSL assure également la confidentialité (en faisant en sorte que le contenu des messages ne puisse pas être lu), la détection des lectures et de la désynchronisation.

  • Pour fournir un moyen de communication sécurisé par le biais duquel peuvent s'exécuter plusieurs protocoles d'authentification. Une seule session SSL peut porter plusieurs protocoles d'authentification qui permettent de prouver l'identité des parties entre lesquelles une communication a été établie.
    La prise en charge de SSL fournit toujours un mécanisme permettant au serveur de prouver son identité. Dans WebSphere Application Server pour z/OS, cette méthode permet au client de prouver son identité de plusieurs manières :
    • L'authentification de base (également appelée authentification SSL de type 1) dans laquelle un client fait la preuve de son identité auprès du serveur en lui transmettant une identité utilisateur et un mot de passe (ou phrase de mot de passe) connu du serveur cible.
      Avec l'authentification de base SSL :
      • Un client z/OS peut communiquer en toute sécurité avec WebSphere Application Server pour z/OS à l'aide d'un ID utilisateur et d'un mot de passe tels que définis par le mécanisme de nom d'utilisateur et de mot de passe CSIv2 GSSUP (Generic Security Services Username Password).
      • Un client WebSphere Application Server peut communiquer en toute sécurité avec un serveur WebSphere Application Server pour z/OS en utilisant un ID utilisateur et un mot de passe MVS (ou une chaîne du mot de passe).
      • Un mot de passe étant toujours requis dans une demande, seules des connexions client-serveur simples peuvent être établies. En d'autres termes, le serveur ne peut pas envoyer un ID utilisateur du client à un autre serveur pour répondre à une demande.
    • La prise en charge des certificats client dans laquelle le serveur et le client fournissent des certificats numériques pour prouver leur identité l'un vis à vis de l'autre.

      Lorsque des certificats numériques sont fournis pour l'authentification auprès de WebSphere Application Server pour z/OS, le certificat déchiffré est mappé vers une identité utilisateur valide dans le référentiel d'utilisateurs activé. Les applications Web peuvent avoir plusieurs milliers de clients, ce qui complique fortement la gestion de l'authentification client. Lorsque le système d'exploitation local est le référentiel d'utilisateurs activé dans WebSphere Application Server pour z/OS, le filtrage des noms de certificat SAF permet de mapper les certificats client sans les stocker vers des ID utilisateur MVS. Par le biais du filtrage de noms de certificat, vous pouvez autoriser les utilisateurs à accéder aux serveurs sans entraîner de surcharge administrative liée à la création d'ID utilisateur MVS et à la gestion des certificats client pour tous les utilisateurs.

    • La prise en charge de SSL fournit toujours un mécanisme permettant au serveur de prouver son identité. Divers mécanismes peuvent être utilisés pour prouver l'identité des clients. Le protocole SSL v3 (et TLS) autorise l'échange facultatif de certificats numériques client. Ces certificats peuvent être utilisés pour l'authentification.
    • La vérification d'identité CSIv2 qui prend en charge les principaux z/OS, les noms distinctifs X501 et les certificats numériques X509.
    • La vérification d'identité, ou relations de confiance, dans laquelle un serveur intermédiaire peut envoyer les identités de ses clients à un serveur cible de manière à la fois sûre et efficace. Cette prise en charge utilise les certificats client pour établir le serveur intermédiaire en tant que propriétaire d'une session SSL. Par le biais de la fonction RACF (Resource Access Control Facility), le système peut vérifier que le serveur intermédiaire est digne de confiance (pour accorder ce niveau de confiance, les administrateurs attribuent l'autorisation CBIND aux ID RACF qui exécutent exclusivement un code système sécurisé). Une fois que ce serveur intermédiaire a été jugé digne de confiance, les identités du client (ID utilisateur MVS) ne doivent pas être vérifiées individuellement par le serveur cible ; ces identités client sont simplement vérifiées sans nécessiter d'authentification.
  • Pour pouvoir fonctionner en interaction avec d'autres produits, tels que :
    • Serveur de transactions CICS) (Customer Information Control System) pour z/OS
    • Autres versions de WebSphere Application Server
    • ORB compatibles CORBA (Common Object Request Broker Architecture)

SSL est désactivé par défaut et sa prise en charge est facultative. Si vous exécutez WebSphere Application Server pour z/OS alors que la sécurité est activée, SSL est requis par la console d'administration. Java Secure Socket Extension (JSSE) est le type de répertoire SSL utilisé.

Tableau 1. Séquence d'une connexion SSL.

Le tableau suivant décrit le fonctionnement d'une connexion SSL .

Etape Description
Négociation Une fois que le client a localisé le serveur, le client et le serveur négocient le type de sécurité pour les communications. Si SSL doit être utilisé, le client est invité à se connecter à un port SSL spécial.
Etablissement de liaison Le client se connecte au port SSL, ce qui donne lieu à l'établissement de liaison SSL. En cas de succès de l'opération, la communication chiffrée commence. Le client authentifie le serveur en contrôlant le certificat numérique du serveur.

Si les certificats client sont utilisés au cours de l'établissement de liaison, le serveur authentifie le client en contrôlant le certificat numérique du client.

Communication sortante Au cours de l'établissement de liaison SSL, le client et le serveur négocient la spécification de chiffrement à utiliser pour chiffrer les communications.
Première demande du client La détermination de l'identité client dépend du mécanisme d'authentification choisi, qui est l'un des suivants :
  • ID utilisateur et mot de passe CSIv2 (GSSUP)
  • Identité vérifiée CSIv2

Règles

  • Un client Java ou C++ sous z/OS est interopérable avec un serveur WebSphere Application Server pour z/OS ou un serveur d'applications et peut utiliser SSL. La sécurité CSIv2 prend en charge uniquement les clients Java sous z/OS.
  • Une partie de l'établissement de liaison consiste à négocier les spécifications de chiffrement utilisées par SSL pour protéger les messages. Les spécifications de chiffrement et les tailles de clé utilisées sont déterminées en prenant en compte deux facteurs :
    • Le niveau de sécurité des services de chiffrement installés sur le système qui détermine les spécifications de chiffrement et les tailles de clé disponibles dans WebSphere Application Server pour z/OS.
    • La configuration du serveur par le biais de la console d'administration permet de spécifier des algorithmes de chiffrement SSL.
    Pour plus d'informations, voir le document z/OS System Secure Sockets Layer Programming.
  • Pour les sockets System SSL z/OS, vous devez utiliser RACF ou une fonction équivalente pour stocker les certificats numériques et les clés. Ces derniers ne peuvent pas être placés dans une base de données de clés du système de fichiers HFS.
Conseil : Pour définir la sécurité de l'authentification de base SSL, vous devez d'abord demander un certificat signé pour le serveur, ainsi qu'un certificat auprès d'une autorité de certification ayant signé le certificat du serveur. Après avoir reçu ces deux éléments, vous devez faire appel à la fonction RACF pour autoriser l'utilisation des certificats numériques, stocker les certificats du serveur et les fichiers de clés du serveur dans RACF, créer un alias de répertoire SSL et définir les propriétés de sécurité SSL pour le serveur par le biais de la console d'administration.

Pour les clients, vous devez créer un fichier de clés et l'associer au certificat de l'autorité de certification ayant émis le certificat du serveur. Pour un client z/OS, vous devez utiliser la fonction RACF pour créer un fichier de clés client et associer le certificat de l'autorité de certification à ce fichier de clés. Pour que le client puisse authentifier le serveur, ce dernier (ou plus exactement l'ID utilisateur du contrôleur) doit posséder un certificat signé créé par une autorité de certification. Le serveur transmet le certificat signé pour prouver son identité au client. Ce dernier doit posséder le certificat émis par la même autorité de certification que celle ayant émis le certificat du serveur. Le client utilise le certificat de l'autorité de certification pour vérifier que le certificat du serveur est authentique. Une fois que le certificat a été vérifié, le client est sûr que les messages proviennent bien de ce serveur et pas d'un autre. Pour que le serveur authentifie le client, sachez que le client ne transmet aucun certificat au serveur pour prouver son identité. Dans le schéma d'authentification de base SSL, le serveur authentifie le client en demandant à ce dernier de fournir un ID utilisateur et un mot de passe (ou phrase de mot de passe).

Pour toute information sur la création d'un fichier de clés pour l'ID utilisateur s MVS du démon, voir Configuration d'un fichier de clés à l'usage de la couche SSL (Secure Sockets Layer) du démon.


Icône indiquant le type de rubrique Rubrique de concept



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=csec_settingupssl
Nom du fichier : csec_settingupssl.html