Remarques sur l'activation et la migration des fonctions de renforcement de la sécurité
Dans cette édition de WebSphere Application Server, des fonctions supplémentaires de renforcement de la sécurité sont activées par défaut. Lors de la migration, les paramètres qui étaient préalablement activés sont conservés. Toutefois, si ces fonctions ne sont pas activées à l'issue de la migration, vous pouvez les activer vous-même.
Pour que la configuration WebSphere Application Server soit sécurisée par défaut, les valeurs par défaut suivantes ont été modifiées dans les nouvelles fonctions de renforcement de la sécurité dans WebSphere Application Server Version 8.0 :
- Activation de SSL (Secure Sockets Layer) requis dans le transport CSIv2 (Common Secure
Interoperability version 2) par défaut
Les paramètres suivants sont disponibles pour la couche de transport CSIv2 : TCP/IP pour une connexion TCP/IP, SSL pris en charge pour une connexion TCP/IP ou SSL, et SSL requis pour une connexion SSL uniquement. SSL requis est le nouveau paramètre par défaut dans cette édition de WebSphere Application Server. Le basculement vers SSL requis comme paramètre par défaut garantit que toutes les connexions CSIv2 à l'intérieur et à l'extérieur du serveur utilisent la connexion SSL sécurisée.
- Activation de l'attribut HttpOnly sur les cookies LTPA par défaut
Lorsque la propriété personnalisée com.ibm.ws.security.addHttpOnlyAttributeToCookies est définie sur true, l'attribut HttpOnly est ajouté aux cookies de sécurité (cookies LTPA et WASReqURL) qui sont créés par le serveur. L'attribut HttpOnly est un attribut de navigation créé pour empêcher les applications client (telles que les scripts Java™) d'accéder aux cookies pour éliminer des failles de scriptage intersites. Cet attribut peut être défini désormais dans la console d'administration. Avant WebSphere Application Server Version 8.0, la priorité personnalisée com.ibm.ws.security.addHttpOnlyAttributeToCookies par défaut était false. Pour WebSphere Application Server Version 8.0, la valeur par défaut est maintenant true pour le cookie LTPA et le cookie de session.
Pour plus d'informations, consultez la propriété personnalisée com.ibm.ws.security.addHttpOnlyAttributeToCookies dans la rubrique relative aux propriétés personnalisées.
- Activation de la fonction Session Security Integration par défaut
Seuls les utilisateurs authentifiés peuvent accéder aux sessions créées dans les pages sécurisées. L'utilitaire de gestion de session utilise l'infrastructure de sécurité pour déterminer l'identité authentifiée associée à une requête HTTP d'un client et pour récupérer ou créer une session. Pour plus d'informations sur la sécurité de niveau session, lisez la rubrique relative à la prise en charge de la sécurité de niveau session.
De même que la fonction Session Security Integration, la persistance des données d'identification est également activée. Les informations de connexion sont ainsi disponibles pour les clients Web non protégés afin d'offrir un accès supplémentaire aux informations utilisateur. Pour plus d'informations sur la persistance des données d'identification, consultez la section "Utiliser les données d'authentification disponibles quand un URI protégé est accédé" dans la rubrique relative aux paramètres d'authentification Web.
Activation des nouvelles fonction de renforcement de la sécurité après la migration
Si les nouvelles fonctions de sécurité ne sont pas activées après la migration, vous pouvez les activer vous-même à partir de la console d'administration ou à l'aide de scripts.
- Activation de la fonction SSL par défaut dans CSIv2
- Pour activer la fonction SSL par défaut pour les transports entrants et sortants dans CSIv2 :
Si vous utilisez la console d'administration, sélectionnez SSL requis dans la liste déroulante et cliquez sur Appliquer.
. Sans la zone Transport sélectionnezRecommencez ces étapes pour les communications sortantes CSIv2 et cliquez sur SSL requis dans la liste de menu et cliquez sur Appliquer.
. Sans la zone Transport sélectionnezSi vous souhaitez activer SSL par défaut pour les transports entrants et sortants sur CSIv2 à l'aide de scripts, utilisez les commandes configureCSIInbound et configureCSIOutbound. Pour plus d'informations, consultez la rubrique Configuration de l'authentification d'interopérabilité sécurisée commune (Common Secure Interoperability, CSI) à l'aide de scripts.
Pour le côté client, éditez le fichier sas.client.props. Définissez com.ibm.CSI.performTransportAssocSSLTLSRequired sur true et com.ibm.CSI.performTransportAssocSSLTLSSupported sur false.
- Activation de l'attribut de cookie HttpOnly
- Pour activer l'attribut HttpOnly pour les cookies par défaut :
Si vous utilisez la console d'administration, cliquez sur Nouveau et entrez com.ibm.ws.security.addHttpOnlyAttributeToCookies comme Nom et true comme Valeur.
. Cliquez surVous pouvez également activer l'attribut HttpOnly via la console d'administration, en cliquant sur . Cliquez sur Associer les cookies de sécurité à la valeur HTTPOnly pour éviter les attaques de script CSS puis cliquez sur Appliquer.
Pour activer l'attribut HttpOnly sur les cookies par défaut à l'aide de scripts, utilisez la commande setAdminActiveSecuritySettings.
- Activation de la fonction Session Security Integration
- Pour activer la fonction Session Security Integration pour chaque serveur à partir de la
console d'administration, sélectionnez Intégration de la sécurité.
Pour activer la persistance des données d'identification à partir de la console d'administration, cliquez sur Utiliser les données d'authentification disponibles quand un URI protégé est accédé.
. Sélectionnez la case à cocher
. Cochez la case
Identification et résolution des incidents relatifs à l'activation et la migration des fonctions de renforcement de la sécurité
Lors de l'activation des nouvelles fonctions de renforcement de la sécurité, il se peut que vous notiez des différences dans le comportement du système en fonction de l'environnement utilisé auparavant.
Par exemple, si vous utilisiez un environnement dans lequel le transport CSIv2 était défini sur le paramètre SSL pris en charge précédemment défini par défaut, vous ne notez aucune différence car SSL pris en charge communique à la fois avec les connexions TCP/IP et SSL. Si un incident est détecté, néanmoins, il se peut que les certificats n'aient pas été correctement échangés pour permettre au client et au serveur de communiquer. Pour plus d'informations, consultez la rubrique Sécurisation des communications à l'aide de la couche SSL.
Si vous travailliez dans un environnement où TCP/IP était utilisé pour la connexion à CSIv2, vous pouvez rencontrer des problèmes de connexion à la connexion CSIv2 SSL. La configuration de serveur peut être remplacée par SSL pris en charge ou TCP/IP si SSL n'est pas requis.
Pour l'attribut HttpOnly, lorsque ce dernier est ajouté aux cookies de sécurité, le navigateur empêche les scripts côté client d'accéder à ces cookies. La plupart du temps, il doit s'agir du comportement par défaut pour réduire le risque d'attaques de script CSS. Si vous devez impérativement autoriser les scripts client à accéder aux cookies de sécurité WebSphere et que vous connaissez les conséquences possibles, la valeur de l'attribut HttpOnly peut être désactivée.
Toutefois, l'attribut HttpOnly peut découvrir les scripts client utilisés pour accéder aux coolies WebSphere, puis les utiliser, même si ce n'était pas prévu. Dans ce cas, l'application Web qui permet aux scripts d'accéder aux cookies WebSphere doit être évaluée.
Pour l'activation de la fonction Session Security Integration, lorsque la sécurité intégrée de niveau session est activée, vous pouvez recevoir une exception UnauthorizedSessionRequestException sur les servlets si ces derniers accèdent à une session appartenant à des identités authentifiées autres que l'identité actuellement propriétaire de la session. Si vous ne voulez pas que cette vérification soit effectuée, vous pouvez désactiver l sécurité de niveau session à partir du serveur qui rencontre ce problème.