Optimisation de Liberty pour les applications sécurisées
Vous pouvez optimiser Liberty afin d'améliorer les performances pour les applications sécurisées.
Pourquoi et quand exécuter cette tâche
Lorsque vous sécurisez votre environnement d'applications WebSphere, il est important de comprendre l'effet que la sécurité peut avoir sur les performances. Dans un environnement de serveur d'applications, l'exécution d'applications avec des paramètres de sécurité diminuent souvent les performances en raison d'une utilisation accrue du processeur par les tâches de sécurité, telles que le chiffrement, l'authentification et l'autorisation. Souvent, ces services peuvent allonger le chemin d'accès des demandes du serveur d'applications, exigent davantage de ressources pour chaque demande et ralentissent la capacité de traitement de l'application.
Dans la plupart des cas, vous pouvez réduire ou éviter cette perte des performances liée à la sécurité en optimisant les performances. Vous pouvez ajuster les ressources qui sont utilisées par les services de sécurité et choisir de n'utiliser que les services de sécurité qui sont requis par une application ou un environnement particulier. Pour obtenir les meilleures performances possibles sans sacrifier la sécurité nécessaire, vous devez comprendre votre topologie de réseau ainsi que les besoins de vos applications en matière de sécurité.
Procédure
- Choisissez les connexions à chiffrer.
Dans un environnement WebSphere Application Server, vous pouvez chiffrer les transports suivants :
- Le trafic HTTP vers le serveur Web
- Le trafic HTTP du serveur Web vers le serveur d'applications
- Le trafic SOAP/JMX
- Le service de transfert de fichier
- Les services Web sur HTTP
Lorsque vous déterminez quel trafic doit être transporté via des connexions chiffrées, déterminez si le réseau qui se connecte aux machines communicantes est privé ou public. Une quantité considérable de ressources est associée à la configuration d'une connexion sécurisée ainsi qu'au chiffrement et au déchiffrement du trafic passant par cette connexion. Vous pouvez améliorer considérablement vos performances si vous n'exigez pas le chiffrement sur un réseau sécurisé, par exemple. Si votre application ne requiert pas le chiffrement du trafic du client vers le serveur HTTP et du serveur HTTP vers le serveur d'applications, vous pouvez utiliser le protocole SSL du client vers le serveur HTTP seulement et réduire ainsi la quantité de ressources requises par la sécurité.
- Activez le chiffrement AES (Advanced Encryption Standard) sur puce.
Si vous utilisez IBM SDK Java™ Technology Edition version 7, Service Refresh 3 ou ultérieur et un processeur Intel qui prend en charge l'ensemble d'instructions AES-NI (Advanced Encryption Standard New Instructions), vous pouvez améliorer les performances grâce au chiffrement AES sur puce. Avec ces fonctions, vous pouvez procéder au chiffrement et au déchiffrement AES en suivant les instructions relatives au matériel sans logiciel supplémentaire.
Pour activer l'utilisation de l'ensemble d'instructions AES-NI, ajoutez la propriété suivante à la ligne de commande de la machine virtuelle Java ou au fichier jvm.options :
com.ibm.crypto.provider.doAESInHardware=true
Ajoutez la propriété suivante sur la ligne de commande de la machine virtuelle Java ou dans le fichier jvm.options pour vérifier que le processeur prend en charge l'ensemble d'instructions AES-NI :
com.ibm.crypto.provider.AESNITrace=true
Pour plus d'informations, voir Intel Advanced Encryption Standard New Instructions.
- Choisissez la longueur de votre clé de chiffrement.
Dans certains cas, la longueur de bits d'une clé de chiffrement dépend des règles appliquées au transfert de certains types de données. Dans ces cas, le chiffrement et la longueur de clé que vous choisissez pour une connexion SSL particulière peuvent être prédéterminés. Lorsque la longueur de clé n'est pas réglementée, vous devez choisir les ressources appropriées à allouer à la sécurité pour que les performances ne diminuent pas plus que nécessaire. Par exemple, un chiffrement 256 bits est plus fort qu'un chiffrement 128 bits. Toutefois, le déchiffrement de messages dont le chiffrement est renforcé requiert plus de temps.
Lorsque vous prenez votre décision concernant le niveau de chiffrement, tenez compte du type des données qui sont transmises sur le réseau. Par exemple, des informations sensibles telles que des dossiers financiers ou médicaux nécessitent une sécurité maximale. Tenez également compte des utilisateurs ayant accès au réseau. Si le réseau est protégé par un mot de passe, envisagez de réduire le niveau du chiffrement ou, dans la mesure du possible de transmettre les données via une connexion déchiffrée.
Pour plus d'informations sur la configuration des paramètres SSL sous Liberty, voir Liberty : Attributs de configuration SSL
- Définissez des demandes de connexion keep-alive.
Dans le protocole SSL (Secure Socket Layer), l'établissement de liaison initial utilise un chiffrement de clé publique pour échanger une clé privée en vue d'un chiffrement plus rapide de la clé privée. Ce chiffrement plus rapide permet de chiffrer et de déchiffrer la communication au-delà de l'établissement de liaison initial. Etant donné que le chiffrement utilisé pour les communications suivantes est plus rapide que celui qui est utilisé pour l'établissement de liaison initial, il est important du point de vue des performances de limiter le nombre d'établissements de liaison SSL sur le serveur d'applications. Pour ce faire, augmentez la longueur d'une connexion SSL en augmentant l'affinité de session.
Pour augmenter la durée d'une connexion SSL, vous pouvez activer les connexions keep-alive HTTP persistantes. L'augmentation de la durée évite que des liaisons SSL soient établies au cours des demandes suivantes. Vous pouvez vous assurer que des connexions persistantes sont activées en vérifiant que l'attribut keepAliveEnabled dans l'élément httpOptions a la valeur true dans le fichier server.xml. La valeur par défaut est true.
Vous pouvez aussi optimiser les connexions persistantes en définissant le nombre maximal de demandes consécutives pour une connexion HTTP unique. Si vos clients envoient plus de 100 demandes consécutivement, envisagez d'augmenter la valeur de l'attribut maxKeepAliveRequests de l'élément httpOptions dans le fichier server.xml. La valeur par défaut est 100.
Pour en savoir plus sur les attributs des connexions persistantes, voir Java Servlets 3.0.
- Définissez les paramètres du cache d'authentification.
Comme la création d'un sujet d'authentification peut augmenter l'utilisation du processeur, Liberty fournit un cache d'authentification permettant de stocker le sujet après l'authentification d'un utilisateur. Pour bénéficier de tous les avantages de ce service afin d'améliorer les performances, vous devez vérifier qu'il est activé et optimisé en fonction de vos utilisateurs et de vos applications.
Assurez-vous de ne pas désactiver le cache d'authentification. Par défaut, il est activé pour améliorer les performances.
Envisagez de changer la valeur de délai d'attente du cache d'authentification. Si vous l'augmentez, les sujets peuvent rester dans le cache d'authentification plus longtemps, ce qui permet de réduire le nombre de réauthentifications. Toutefois, le risque que les droits utilisateur deviennent périmés sera plus élevé, par rapport à un référentiel externe modifié, comme LDAP. Définissez le délai d'attente de votre cache d'authentification de sorte qu'il reflète la longueur estimée des sessions de client. Vous pouvez spécifier le délai d'attente du cache en associant au délai d'attente la valeur de votre choix dans l'élément authCache du fichier server.xml. La valeur par défaut est 600 secondes.
Enfin, si les temps d'authentification sont plus longs que prévu, ou si le trafic vers un référentiel d'authentification externe est plus important que prévu, cela peut signifier que le cache d'authentification est plein. Si tel est le cas, les sujets sont expulsés. Il n'existe pas de mappage un-à-un des utilisateurs authentifiés vers les entrées du cache d'authentification. Le nombre d'entrées dans le cache par utilisateur dépend d'autres configurations de sécurité. Il est recommandé de définir une taille maximale de cache d'authentification supérieure au nombre d'utilisateurs authentifiés distincts accédant au serveur simultanément. La définition de la taille maximale du cache d'authentification de cette façon permet d'éviter que des sujets soient expulsés du cache avant leur expiration. Vous pouvez changer la taille maximale du cache d'authentification en définissant la valeur de l'attribut maxSize dans l'élément authCache du fichier server.xml. La taille par défaut est 25000.
Pour plus d'informations, voir Configuration du cache d'authentification dans Liberty.
- Configurez les paramètres d'affinité de session HTTP.
Dans un environnement d'application sécurisée, l'une des opérations qui réduit le plus les performances est la configuration initiale, notamment l'établissement de liaison SSL et l'authentification. Dans les environnements de cluster, les performances peuvent diminuer si un client Web accède à différents serveurs d'applications. Pour éviter une augmentation de l'utilisation du processeur lors de l'établissement de liaison SSL et de la réauthentification, vous devez vous assurer que l'affinité de session HTTP est configurée.
L'affinité de session HTTP garantit l'acheminement des demandes de client consécutives vers le même serveur d'applications. Elle améliore les performances de différentes façons et évite notamment une utilisation accrue du processeur lors de la réauthentification et de l'établissement de liaison SSL. Consultez la documentation de votre serveur HTTP ou de votre équilibreur de charge pour des instructions relatives à la configuration de l'affinité de session HTTP.
Pour plus d'informations, voir Configuration de la persistance de session pour Liberty.


http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=twlp_tun_sec
Nom du fichier : twlp_tun_sec.html