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 Sécurité > Sécurité globale > RMI/IIOP > Communications entrantes CSIv2. Sans la zone Transport sélectionnez SSL requis dans la liste déroulante et cliquez sur Appliquer.

Recommencez ces étapes pour les communications sortantes CSIv2 et cliquez sur Sécurité > Sécurité globale > RMI/IIOP > Communications sortantes CSIv2. Sans la zone Transport sélectionnez SSL requis dans la liste de menu et cliquez sur Appliquer.

Si 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 Sécurité > Sécurité globale > Propriétés personnalisées. Cliquez sur Nouveau et entrez com.ibm.ws.security.addHttpOnlyAttributeToCookies comme Nom et true comme Valeur.

Vous pouvez également activer l'attribut HttpOnly via la console d'administration, en cliquant sur Sécurité > Sécurité globale > Connexion unique (SSO). 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 Serveurs > Types de serveurs > Serveurs d'applications WebSphere > server1 > Gestion de session. Cochez la case Intégration de la sécurité.

Pour activer la persistance des données d'identification à partir de la console d'administration, cliquez sur Sécurité > Sécurité globale > Sécurité Web et SIP > Paramètres généraux. Sélectionnez la case à cocher Utiliser les données d'authentification disponibles quand un URI protégé est accédé.

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.


Icône indiquant le type de rubrique Rubrique de concept



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