Considérations sur la sécurité dans un environnement WebSphere Application Server multinoeud

WebSphere® Application Server Network Deployment prend en charge la gestion centralisée des noeuds distribués et des serveurs d'applications. Cette prise en charge rend les choses complexes, surtout lorsque la sécurité est impliquée. Etant donné que tout est réparti, la sécurité joue un rôle même plus grand pour assurer que les communications sont sécurisées de façon appropriée entre les serveurs d'applications et les agents de noeuds et entre les agents de noeuds, qui sont des gestionnaires de configuration propres aux noeuds) et le gestionnaire de déploiement (qui est un gestionnaire de configuration centralisé, opérant sur l'ensemble du domaine).

Avant de commencer

Etant donné que les processus sont distribués, le mécanisme d'authentification qui doit être utilisé est LTPA (Lightweight Third Party Authentication). Les jetons LTPA sont chiffrés, signés et peuvent être acheminés vers des processus distants. Ils ont toutefois des dates d'expiration. Le connecteur SOAP, qui est le connecteur par défaut, est utilisé pour la sécurité d'administration et ne dispose d'aucune logique de relance des jetons arrivés à expiration. Cependant, le protocole est sans état. Un nouveau jeton est donc créé pour chaque demande s'il n'y a pas assez de temps pour exécuter la demande avec le temps spécifié restant dans le jeton. Il existe un autre connecteur, le connecteur RMI, qui est avec état (stateful) et contient une logique de renouvellement pour corriger les jetons arrivés à expiration en soumettant à nouveau les demandes après la détection de l'erreur. Les jetons ayant des délais d'expiration spécifiques, la synchronisation des horloges système est essentielle au bon fonctionnement de la validation à base de jetons. Si les horloges sont trop décalées (d'environ 10 à 15 minutes), des erreurs de validation irrémédiables peuvent se produire. Assurez-vous que la date et l'heure des horloges ainsi que les fuseaux horaires sont identiques sur tous les systèmes. Les noeuds peuvent être répartis sur plusieurs fuseaux horaires si les heures sont exactes dans les fuseaux horaires (par exemple, 5 PM CST = 6 PM EST, etc.).

Les processus étant répartis, un mécanisme d'authentification prenant en charge un jeton d'authentification tel que LTPA (Lightweight Third Party Authentication) doit être sélectionné. Les jetons sont chiffrés, signés et peuvent être acheminés vers des processus distants. Toutefois, les jetons ont des délais d'expiration définis dans la console d'administration WebSphere Application Server . Le connecteur SOAP, qui est le connecteur par défaut, est utilisé pour la sécurité d'administration et ne dispose d'aucune logique de relance des jetons arrivés à expiration. Cependant, le protocole est sans état. Un nouveau jeton est donc créé pour chaque demande s'il n'y a pas assez de temps pour exécuter la demande avec le temps spécifié restant dans le jeton. Il existe un autre connecteur, le connecteur RMI (Remote Method Invocation), qui est avec état (stateful) et contient une logique de renouvellement pour corriger les jetons arrivés à expiration en soumettant à nouveau les demandes après la détection de l'erreur. Les jetons ayant des délais d'expiration spécifiques, la synchronisation des horloges système est essentielle au bon fonctionnement de la validation à base de jetons. Si les horloges sont trop décalées (d'environ 10 à 15 minutes), des erreurs de validation irrémédiables peuvent se produire. Assurez-vous que la date et l'heure des horloges ainsi que les fuseaux horaires sont identiques sur tous les systèmes. Les noeuds peuvent être répartis sur plusieurs fuseaux horaires si les heures sont exactes dans les fuseaux horaires (par exemple, 5 PM CST = 6 PM EST, etc.).

Fonction obsolète: La prise en charge du connecteur RMI est obsolète. Utilisez des connecteurs JSR160RMI à la place des connecteurs RMI.

D'autres éléments doivent être pris en compte avec SSL (Secure Sockets Layer). WebSphere Application Server for z/OS® peut utiliser des fichiers de clés RACF (Resource Access Control Facility) pour stocker les clés et les fichiers de clés certifiées utilisés pour SSL, mais différents protocoles SSL sont utilisés en interne. Vous devez configurer les deux éléments suivants :

• un répertoire SSL système à utiliser par le conteneur Web
• Un répertoire SSL JSSE (Java™ Secure Sockets Extension) à utiliser par le connecteur SOAP HTTP si le connecteur SOAP est utilisé pour les demandes d'administration

Vérifiez que les magasins de clés et les magasins des tiers dignes de confiance que vous configurez sont établis pour sécuriser uniquement les serveurs avec lesquels ils communiquent. Assurez-vous qu'ils comportent les certificats signataires nécessaires émanant de ces serveurs dans les fichiers des tiers dignes de confiance de tous les serveurs du domaine. Lorsque vous utilisez une autorité de certification pour créer des certificats personnels, il est plus facile de s'assurer que tous les serveurs se sécurisent entre eux en ayant le certificat CA Root dans tous les signataires.

L'outil de gestion des profils WebSphere z/OS ou la commande zpmt utilise la même autorité de certification pour générer des certificats pour tous les serveurs d'une cellule donnée, y compris ceux des agents de noeud et du gestionnaire de déploiement.

• Lorsque vous tentez d'exécuter des commandes de gestion de système telles que la commande stopNode , spécifiez explicitement les données d'identification d'administration pour effectuer l'opération. La plupart des commandes acceptent les paramètres -user et -password pour l'indication de l'ID utilisateur et du mot de passe. Spécifiez l'ID utilisateur et le mot de passe d'un administrateur (par exemple, un utilisateur membre des utilisateurs de la console disposant des droits Utilisateur ou Administrateur ou l'ID administrateur configuré dans le registre d'utilisateurs).
  Voici un exemple de la commande stopNode :

  stopNode -username user -password pass

  stopNode.sh -username user -password pass

• Vérifiez que la configuration au niveau des agents de noeuds est toujours synchronisée avec le gestionnaire de déploiement avant de démarrer ou de redémarrer un noeud. Pour synchroniser la configuration manuellement, exécutez la commande syncNode à partir de chaque noeud qui n'est pas synchronisé. Pour synchroniser la configuration des agents de noeuds ayant démarré, cliquez sur Administration système > Noeuds. Sélectionnez tous les noeuds démarrés, puis cliquez sur Synchroniser.
• Vérifiez que les horloges de tous les systèmes sont synchronisées, y compris l'heure et la date. Si elles ne sont pas synchronisées, les jetons arrivent à expiration dès qu'ils atteignent le serveur cible en raison des différences d'heure. L'heure universelle coordonnée (UTC) est utilisée par défaut et toutes les autres machines doivent avoir la même heure UTC. Pour savoir comment le vérifier, consultez la documentation de votre système d'exploitation.
• Vérifiez que la période d'expiration du jeton LTPA suffit pour l'exécution de la plus longue demande en aval. Certains justificatifs sont mis en cache et le délai d'expiration ne prend pas toujours en compte la longueur de la demande. Plus spécifiquement, pour les données d'identification en cache, il se peut que vous deviez évaluer vos paramètres pour le cache de sécurité (WSSecureMap) et le délai d'attente LTPA.
• Le connecteur d'administration utilisé par défaut par la gestion du système est SOAP. SOAP est un protocole HTTP sans état (stateless). Dans la plupart des situations, ce connecteur suffit. Lorsqu'un incident se produit avec le connecteur SOAP, il peut être souhaitable de remplacer le connecteur SOAP par défaut sur tous les serveurs par le connecteur RMI. Le connecteur RMI utilise CSIv2 (Common Secure Interoperability Version 2), un protocole avec état (stateful) interopérable, et peut être configuré pour utiliser la vérification d'identité (la délégation en aval), l'authentification par couche de messages (BasicAuth ou Token) et l'authentification par certificat client (pour l'isolement des relations de confiance des serveurs). Pour changer le connecteur par défaut sur un serveur donné, cliquez sur Services d'administration dans les propriétés supplémentaires disponibles pour ce serveur.
• Un message d'erreur peut se produire dans la sécurité du sous-système d'administration. Cette erreur indique que le processus expéditeur n'a pas fourni de justificatif au processus destinataire. En général, cet incident est dû au fait que la sécurité est désactivée pour le processus expéditeur alors qu'elle est activée pour le processus destinataire. Cette configuration indique habituellement que l'un des deux processus n'est pas synchronisé avec la cellule. Le fait que la sécurité d'un serveur d'applications spécifique soit désactivée n'affecte pas la sécurité d'administration.
• Un message d'erreur peut se produire dans la sécurité du sous-système d'administration. Cette erreur indique que le processus expéditeur n'a pas fourni de justificatif au processus destinataire. En général, les causes de cet incident sont les suivantes :
  • La sécurité est désactivée pour le processus expéditeur alors qu'elle est activée pour le processus destinataire. Cette configuration indique habituellement que l'un des deux processus n'est pas synchronisé avec la cellule. Le fait que la sécurité d'un serveur d'applications spécifique soit désactivée n'affecte pas la sécurité d'administration.
  • Les horloges ne sont pas synchronisées d'un système à l'autre, ce qui invalide immédiatement les jetons de justificatif. Assurez-vous que la date, l'heure et les fuseaux horaires sont synchronisés sur les deux postes. Une erreur semblable à la suivante peut se produire :

    [9/18/02 16:48:23:859 CDT] 3b9cef35 RoleBasedAuth A CWSCJ0305I : La vérification de l'autorisation basée sur des rôles 
    a échoué pour le nom de sécurité <null>, accessId NO_CRED_NO_ACCESS_ID 
    lors de l'appel de la méthode propagateNotifications:[Ljavax.management.Notification; 
    sur la ressource NotificationService et le module NotificationService.

• Lors de l'obtention du message d'erreur suivant, vérifiez que les horloges sont synchronisées entre tous les serveurs de la cellule et que les configurations sont synchronisées entre tous les noeuds et le gestionnaire de déploiement. Une erreur semblable à la suivante peut se produire :

  [9/18/02 16:48:22:859 CDT] 3bd06f34 LTPAServerObj E CWSCJ0372E : La validation du 
  jeton a échoué.