Considérations sur la sécurité dans un environnement WebSphere Application ServerWebSphere Application Server, Network Deployment multi-noeuds

WebSphere Application Server, Network Deployment prend en charge la gestion centralisée de noeuds et serveurs d'application répartis. 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

[AIX Solaris HP-UX Linux Windows][IBM i]Etant donné que les processus sont répartis, le mécanisme d'authentification à utiliser 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.).

[z/OS]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 sur la console d'administration de 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.).

[z/OS]D'autres éléments doivent être pris en compte avec SSL (Secure Sockets Layer). WebSphere Application Server pour z/OS peut utiliser les fichiers de clés Resource Access Control Facility (RACF) pour stocker les clés et les fichiers de clés certifiées utilisés pour SSL, mais des protocoles SSL différents 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 Java™ Secure Sockets Extension (JSSE) devant être utilisé 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.

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

Pourquoi et quand exécuter cette tâche

Les problèmes suivants doivent être pris en compte lors de l'utilisation ou de la planification d'un environnement WebSphere Application Server, Network Deployment.

Procédure

Résultats

Une approche correcte des interactions de sécurité entre les serveurs répartis réduit fortement les erreurs détectées dans les communications sécurisées. La sécurité complique les choses car elle nécessite la gestion d'une fonction supplémentaire. Pour que la sécurité fonctionne correctement, vous devez la prendre entièrement en compte dans la planification de votre infrastructure.

Que faire ensuite

Si des incidents liés à la sécurité se produisent dans l'environnement WebSphere Application Server, Network Deployment, voir Traitement des incidents liés aux configurations de sécurité pour trouver des informations sur un incident spécifique. Lorsqu'il est nécessaire de consulter des informations de trace pour corriger une erreur, dans les cas où les serveurs sont répartis, ces informations doivent souvent être collectées simultanément sur tous les serveurs lors de la reconstitution de l'incident. Cette trace peut être activée de manière dynamique ou statique, selon le type d'incident.

Icône indiquant le type de rubrique Rubrique de tâche



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=tsec_esecarun
Nom du fichier : tsec_esecarun.html