Sécurité, termes et concepts

Cette section fournit une présentation générale des types de sécurité, des outils utilisés pour générer et télécharger les certificats, ainsi que les types de magasins de données installés par WebSphere Partner Gateway.

Mécanismes et protocoles de sécurité utilisés dans WebSphere Partner Gateway

Cette section présente la couche SSL, les signatures numériques et le chiffrement.

Couche SSL

WebSphere Partner Gateway peut utiliser la couche SSL pour sécuriser les documents entrants et sortants. Un document entrant est celui envoyé au concentrateur. Un document sortant est celui envoyé à partir du concentrateur.

SSL est un protocole couramment utilisé pour la gestion de la sécurité sur Internet. La couche SSL sécurise les connexions en permettant à deux applications reliées par une liaison réseau de s'identifier l'une l'autre et en assurant la confidentialité et l'intégrité des données.

Une connexion SSL HTTP est toujours lancée par le client avec une URL commençant par https:// au lieu de http://. Une connexion SSL commence par une négociation. Durant cette étape, les applications échangent des certificats numériques, se mettent d'accord sur les algorithmes de chiffrement à utiliser et génèrent des clés de chiffrement pour le reste de la session.

Remarques :
  1. WebSphere Partner Gateway accepte les algorithmes RC2 et TripleDES. L'algorithme RC5 n'est pas pris en charge. Si vous l'utilisiez dans une version précédente, passez à l'un des algorithmes pris en charge.
  2. WebSphere Partner Gateway accepte également les algorithmes AES et DES. Vous pouvez définir ces algorithmes dans le fichier bcg.properties ou à l'aide de l'API SecurityService. Pour plus de détails sur le fichier bcg.properties, consultez le Guide de l'administrateur. Consulter le Programmer Guide pour plus d'informations sur SecurityService.

Le protocole SSL fournit les dispositifs de sécurité suivants :

Signature numérique

La signature numérique est la méthode pour assurer l'irréfutabilité. Cela signifie qu'un participant ne peut pas nier être à l'origine d'un message et l'avoir envoyé. Cela assure également que le participant ne peut pas nier avoir reçu un message.

Une signature numérique permet à l'expéditeur de signer un message afin de pouvoir vérifier qu'il est bien à l'origine de l'envoi. Elle permet également de s'assurer que le message n'a pas été modifié depuis qu'il a été signé.

WebSphere Partner Gateway prend en charge les formats de signature numérique PKCS#7 SignedData, selon les protocoles métier.

Chiffrement

WebSphere Partner Gateway utilise un système de chiffrement à clé publique pour sécuriser les communications entre les participants et le concentrateur. Le chiffrement à clé publique utilise une paire de clés mathématiquement liées. Un document chiffré avec la première clé ne peut être déchiffré qu'avec la seconde, et réciproquement.

Chaque participant d'un système de clé publique dispose d'une paire de clés. L'une des clés est maintenue secrète, il s'agit de la clé privée. clé privée. L'autre clé est distribuée à quiconque la demande, il s'agit de la clé publique. WebSphere Partner Gateway utilise une clé publique de participant pour chiffrer un document. La clé privée est utilisée pour le déchiffrer.

Utilitaire iKeyman

Comme décrit dans les sections suivantes, l'outil IBM de gestion des clés (iKeyman) est utilisé pour créer des bases de données de clés, des paires de clés publiques et privées et des demandes de certificats. Vous pouvez également utiliser iKeyman pour créer des certificats auto-signés. L'utilitaire iKeyman se trouve dans le répertoire /<ProductDir>/was/bin, créé par WebSphere Partner Gateway au cours de l'installation.

Vous pouvez également utiliser iKeyman pour générer une demande de certificat auprès d'une autorité de certification.

Console de communauté

Vous utiliserez la Console de communauté pour installer tous les certificats client, de signature et de chiffrement pour le stockage de WebSphere Partner Gateway. Vous pouvez également utiliser la Console de communauté pour installer les certificats racine et intermédiaires d'autorité de certification.

Remarque : Lorsque le certificat d'un participant expire, la responsabilité lui incombe d'obtenir un nouveau certificat. La Console de communauté inclut des fonctions d'alerte d'expiration pour les certificats stockés dans WebSphere Partner Gateway.

Magasins de clés et magasins de relations de confiance

Lors de l'installation de WebSphere Partner Gateway, un magasin de clés et un magasin de relations de confiance sont également installés pour le Réceptionnaire et la Console.

Par défaut, les deux magasins de clés et les deux magasins de relations de confiance sont créés dans le répertoire <ProductDir>/common/security/keystore, sous les noms suivants :

Modification du mot de passe par défaut

Le mot de passe par défaut permettant d'accéder aux quatre magasins est WebAS. L'application WebSphere Application Server est configurée pour utiliser ces quatre magasins. Vous pouvez utiliser l'utilitaire iKeyman pour changer le mot de passe. Vous pouvez aussi utiliser la commande Unix suivante pour modifier le mot de passe du fichier de magasin de clés :

/<ProductDir>/console/was/java/bin/keytool
  -storepasswd -new $NEW_PASSWORD$ -keystore $KEYSTORE_LOCATION$
  -storepass $CURRENT_PASSWORD$ -storetype JKS

Si les mots de passe des magasins de clés sont changés, la configuration de chaque instance de WebSphere Application Server doit l'être également. Pour cela, vous pouvez utiliser le script bcgChgPassword.jacl. Pour l'instance de console, naviguez jusqu'au répertoire suivant :

/<ProductDir>/bin

et exécutez la commande suivante :

./bcgwsadmin.sh -f /<ProductDir>/scripts/
 bcgChgPassword.jacl -conntype NONE

Répétez cette commande pour les instances de WebSphere Application Server du Réceptionnaire et du Gestionnaire de documents.

Remarque : Pour Windows, utilisez bcgwsadmin.bat au lieu de ./bcgwsadmin.sh.

Vous êtes alors invité à saisir le nouveau mot de passe.

Remplacement d'un certificat arrivé à expiration

Si un certificat du magasin de relations de confiance arrive à expiration, vous devez le remplacer par un nouveau certificat de la façon suivante :

  1. Lancez iKeyman, s'il n'est pas déjà en cours d'exécution.
  2. Ouvrez le fichier du magasin de relations de confiance.
  3. Saisissez le mot de passe et cliquez sur OK.
  4. Dans le menu, sélectionnez Signer les certificats.
  5. Cliquez sur le bouton d'ajout.
  6. Sélectionnez un type de donnés, tel que "données ASCII codées en base 64".

    Ce type de données doit correspondre au type de données du certificat importé.

  7. Saisissez un nom de fichier de certificat et un emplacement pour le certificat numérique racine de l'autorité de certification ou cliquez sur Parcourir pour sélectionner le nom et l'emplacement.
  8. Cliquez sur OK.
  9. Saisissez un libellé pour le certificat importé.
  10. Cliquez sur OK.

Hiérarchies de certificats

Une hiérarchie de certificats se compose des certificats d'un participant et de tout certificat utilisé pour les authentifier. Par exemple, si un CA a été utilisé pour créer le certificat du participant, ce CA peut avoir lui-même avoir été certifié par un autre CA. La hiérarchie des relations de confiance commence au CA racine (l'ancrage des relations de confiance). Le certificat numérique du CA racine est auto-signé, c'est-à-dire qu'il utilise sa propre clé privée pour signer le certificat numérique. Tous les certificats entre l'ancrage des relations de confiance et le certificat du participant (le certificat cible) sont des certificats intermédiaires.

Pour tout certificat émis par le CA, il faut ajouter tous les certificats de la hiérarchie. Par exemple, pour une chaîne de certificats dans laquelle A (l'ancrage des relations de confiance) est l'émetteur de B, et B l'émetteur de C (le certificat cible), les trois certificats doivent être téléchargés en tant que certificats CA.

WebSphere Partner Gateway traite tous les certificats auto-signés en tant qu'ancrages de relations de confiance. Le certificat auto-signé peut être du type CA ou généré par le participant.

Certificat principal et certificat secondaire

Vous pouvez créer plusieurs certificats d'un type donné, et en désigner un en tant que certificat principal et l'autre en tant que certificat secondaire. Si le certificat principal expire ou est inutilisable, WebSphere Partner Gateway bascule sur le certificat secondaire. La Console de communauté sert à préciser celui qui est principal et celui qui est secondaire.

Il est possible de définir des certificats principaux et secondaires pour les certificats suivants :

Modification de la puissance du chiffrement

Prenez note des limitations importantes formulées ci-dessous, concernant l'utilisation de certificats de chiffrement. L'environnement Java Runtime Environment (JRE) fourni avec WebSphere Partner Gateway impose des restrictions concernant les algorithmes cryptographiques et les longueurs de chiffrement maximales autorisés. Par exemple, les règles imposent des limites de longueur qui ont des répercussions sur les performances des clés de chiffrement. Ces limitations sont spécifiées dans les fichiers nommés fichiers de règle de juridiction. La longueur maximum possible est de 2048 octets. Si vous souhaitez prendre en charge des certificats avec une taille de clé supérieure à 2048 octets, utilisez la version non limitée des fichiers de règle de juridiction. Vous pouvez préciser que vous souhaitez appliquer une règle non limitée plus efficace, en installant de nouveaux fichiers de règle dans un sous-répertoire de l'environnement JRE installé. Il existe également des restrictions sur les algorithmes de chiffrement symétriques, tels que DES3. S'il vous faut un algorithme fort à clé symétrique, le fait de remplacer les fichiers de règle de juridiction lèvera également les restrictions concernant les clés symétriques.

Pour installer des fichiers de règle de juridiction dans WebSphere Partner Gateway, procédez comme suit :

  1. Téléchargez les fichiers de règle de juridiction non limités depuis le lien IBM SDK Policy files du site http://www.ibm.com/developerworks/java/jdk/security/142/.
  2. Décompressez le fichier dans un dossier temporaire
  3. Copiez les fichiers local_policy.jar et US_export_policy.jar depuis ce dossier temporaire.
  4. Passez dans le répertoire <ProductDir>\was\java\jre\lib\security.
  5. Renommez les fichiers local_policy.jar et US_export_policy.jar en local_policy.jar.bak et US_export_policy.jar.bak
  6. Collez les fichiers copiés à l'étape 3 dans le dossier où vous êtes, <ProductDir>\was\java\jre\lib\security.
  7. Redémarrez le serveur.

Ces étapes s'appliquent à toutes les instances configurées de WebSphere Application Server.

Copyright IBM Corp. 2003, 2005