Présentation de la planification de la sécurité

Lorsque vous accédez à des information sur Internet, vous vous connectez via des serveurs Web et des serveurs d'applications aux données d'une entreprise en bout de chaîne. Dans la présente section, nous étudierons les configurations et les stratégies de sécurité les plus couramment utilisées.

La présente section décrit la protection apportée par chaque couche de sécurité et examine les procédures de sécurité couramment appliquées pour assurer une protection optimale de bout en bout. La figure suivante présente les blocs de construction composant l'environnement d'exploitation de la sécurité dans WebSphere Application Server :

La présente section décrit la protection apportée par chaque couche de sécurité et examine les procédures de sécurité couramment appliquées pour assurer une protection optimale de bout en bout. La figure présente les blocs composant l'environnement d'exploitation de la sécurité dans WebSphere Application Server.

Les informations suivantes décrivent chacun des composants de la sécurité WebSphere Application Server, de la sécurité Java™ et de la sécurité de la plateforme illustrés dans la figure précédente.
Sécurité WebSphere Application Server
Sécurité WebSphere
La sécurité WebSphere Application Server applique les stratégies et les services de sécurité de manière uniforme lors de l'accès aux ressources Web, aux beans enterprise et aux ressources administratives JMX. Elle fait appel aux technologies et aux fonctions de la sécurité WebSphere Application Server pour répondre aux besoins d'un environnement d'entreprise sécurisé.
Sécurité Java
Interface de programmation d'application (API) de la sécurité Java EE (Java Platform, Enterprise Edition)
Le collaborateur de sécurité applique les stratégies de sécurité Java EE (Java Platform, Enterprise Edition) et prend en charge les API de la sécurité Java EE.
Sécurité EJB en utilisant le protocole CSIv2 (Common Secure Interoperability Version 2)
CSIv2 (Common Secure Interoperability Version 2) est un protocole de sécurité à trois niveaux IIOP développé par OMG (Object Management Group). Il fournit une protection des données, une authentification interopérable et une délégation. Les trois niveaux incluent un niveau de sécurité de transport de base, un niveau d'authentification client supplémentaire et un niveau d'attribut de sécurité. WebSphere Application Server for z/OS prend en charge CSIv2, niveau de compatibilité 0.
Sécurité Java 2
Le modèle Sécurité Java 2 assure un contrôle avancé des accès aux ressources système et notamment au système de fichiers, aux propriétés système, à la connexion socket, à la création d'unités d'exécution, au chargement des classes, etc. Le code d'application doit accorder explicitement des droits d'accès à une ressource protégée.
Java Virtual Machine (JVM) 5.0
Le modèle de sécurité JVM fournit une couche de sécurité située au-dessus de la couche de sécurité du système d'exploitation. Par exemple, la sécurité JVM protège la mémoire contre les accès non limités, génère des exceptions lorsque des erreurs se produisent dans une unité d'exécution et définissent des types de tableau.
Sécurité de la plateforme
[AIX Solaris HP-UX Linux Windows][IBM i]Sécurité du système d'exploitation

L'infrastructure de sécurité du système d'exploitation sous-jacent fournit certains services de sécurité pour WebSphere Application Server. Ces services incluent la sécurité du système de fichiers qui protège les fichiers sensibles lors de l'installation du produit pour WebSphere Application Server. L'administrateur système peut configurer le produit pour obtenir des informations d'authentification provenant directement du registre d'utilisateurs du système d'exploitation.

[z/OS]Sécurité du système d'exploitation

L'infrastructure de sécurité du système d'exploitation sous-jacent fournit certains services de sécurité pour WebSphere Application Server. L'identité du système d'exploitation du serviteur, du contrôleur et du démon Started Task, telle que définie par le profil STARTED, est l'identité utilisée pour contrôler l'accès aux ressources, telles que les fichiers ou les sockets. La sécurité du système d'exploitation peut éventuellement fournir des services d'authentification en utilisant le registre d'utilisateurs du système d'exploitation local et/ou des services d'autorisation en utilisant le mécanisme d'autorisation SAF pour la console d'administration WebSphere et pour les applications exécutées sur le serveur d'applications.

L'administrateur doit non seulement connaître SSL (Secure Sockets Layer) et TLS (Transport Layer Security), mais également SAF (System Authorization Facility) et RACF (Resource Access Control Facility) ou un produit équivalent fondé sur SAF.

L'identité et la vérification des utilisateurs peuvent être gérées par le biais du système d'exploitation local utilisé comme registre d'utilisateurs, de la fonction RACF ou d'un produit équivalent fondé sur SAF. Un registre d'utilisateurs LDAP, personnalisé ou fédéré peut également être utilisé.

WebSphere peut être configuré pour utiliser l'autorisation SAF qui fait appel à la fonction RACF ou à un produit équivalent fondé sur SAF pour gérer et protéger les utilisateurs et regrouper les ressources. WebSphere peut également être configuré pour utiliser le mécanisme d'autorisation de WebSphere ou un fournisseur d'autorisation externe JACC.

Lorsque vous utilisez le système d'exploitation local en tant que registre d'utilisateurs et/ou le mécanisme d'autorisation SAF, Security Auditing est une fonction héritée de RACF ou des produits équivalents fondés sur SAF.

Sécurité réseau
Les couches de sécurité réseau fournissent l'authentification au niveau du transport et assurent l'intégrité et la confidentialité des données. Vous pouvez configurer SSL pour la communication entre des serveurs d'applications distincts. Vous pouvez également faire appel à la sécurité IP et au réseau VPN (Virtual Private Network) pour renforcer la protection des messages.
Installation WebSphere Application Server, Network Deployment
Important : Une instance de l'agent de noeud existe sur chaque noeud informatique.

Chaque serveur d'applications du produit se compose d'un conteneur Web, d'un conteneur d'EJB (Enterprise Java Beans) et du sous-système d'administration.

Le gestionnaire de déploiement de WebSphere Application Server contient uniquement le code d'administration de WebSphere Application Server et la console d'administration.

La console d'administration est une application Web Java EE spécifique qui fournit l'interface graphique nécessaire pour effectuer des opérations d'administration. Les données de configuration de WebSphere Application Server sont stockées dans les fichiers de descripteur XML, qui doivent être protégés par la sécurité du système d'exploitation. Les mots de passe et les autres données de configuration confidentielles peuvent être modifiés à l'aide de la console d'administration. Toutefois, vous devez protéger ces mots de passe et ces données confidentielles. Pour plus d'informations, voir Codage des mots de passe dans les fichiers.

Pour les données de configuration, l'application Web de la console d'administration doit respecter une contrainte définie selon laquelle les servlets et les fichiers JSP (JavaServer Pages) de la console sont accessibles uniquement via la connexion SSL lorsque la sécurité administrative est activée.

[AIX Solaris HP-UX Linux Windows][IBM i]Dans WebSphere Application Server version 6.0.x et antérieure, le port HTTPS de la console d'administration a été configuré pour utiliser les fichiers DummyServerKeyFile.jks et DummyServerTrustFile.jks avec le certificat auto-signé par défaut. Les certificats et clés factices doivent être remplacés dès que l'installation de WebSphere Application Server est terminée ; les clés sont communes à l'ensemble de l'installation, elles ne sont donc pas sécurisées. WebSphere Application Server version 6.1 fournit une fonction de gestion intégrée des certificats et des clés, qui génère une clé privée distincte et un certificat auto-signé avec le nom d'hôte du serveur imbriqué pour autoriser la vérification du nom d'hôte. WebSphere Application Server version 6.1 autorise également l'intégration avec une autorité de certification externe pour utiliser les certificats émis par cette dernière. Le processus d'installation des serveurs WebSphere Application Server version 6.1 fournit une option permettant d'activer la sécurité administrative au cours de l'installation. Ainsi, un processus WebSphere Application Server est sécurisé immédiatement après l'installation. WebSphere Application Server version 7.0 étend les fonctions de gestion des certificats intégrés en créant un certificat chaîné (certificat personnel signé par un certificat racine) pour régénérer le certificat personnel sans affecter la sécurité établie. Il permet également de personnaliser le certificat au cours de la création du profil (vous pouvez importer votre propre certificat ou modifier le nom distinctif de celui créé par défaut) et de modifier le mot de passe par défaut du fichier de clés.

[AIX Solaris HP-UX Linux Windows][IBM i]La figure suivante illustre un environnement informatique classique à plusieurs niveaux.Il existe une instance de l'agent de noeud sur chaque ordinateur. Chaque serveur d'applications du produit se compose d'un conteneur Web, d'un conteneur d'EJB (Enterprise Java Beans) et du sous-système d'administration. Le gestionnaire de déploiement de WebSphere Application Server contient uniquement la console et le code d'administration de WebSphere Application Server.

[z/OS]La figure suivante illustre un environnement informatique classique à plusieurs niveaux.Il existe une instance de l'agent de noeud sur chaque ordinateur. Chaque serveur d'applications du produit se compose d'un conteneur Web, d'un conteneur d'EJB (Enterprise Java Beans) et du sous-système d'administration. Le gestionnaire de déploiement de WebSphere Application Server contient uniquement la console et le code d'administration de WebSphere Application Server.

Sécurité administrative

[AIX Solaris HP-UX Linux Windows][IBM i]Les serveurs WebSphere Application Server communiquent les uns avec les autres à l'aide des protocoles de sécurité CSIv2 et SAS (Secure Authentication Services), ainsi qu'à l'aide des protocoles HTTP et HTTPS.
Important : SAS est pris en charge uniquement sur les serveurs version 6.0.x et antérieure qui ont été fédérés dans une cellule version 6.1.
[z/OS]Les serveurs WebSphere Application Server communiquent les uns avec les autres à l'aide des protocoles de sécurité CSIv2 et z/SAS (z/OS Secure Authentication Services) ainsi qu'à l'aide des protocoles HTTP et HTTPS.
Important : z/SAS est pris en charge uniquement sur les serveurs version 6.0.x et versions antérieures qui ont été fédérés dans une cellule version 6.1.

Vous pouvez configurer ces protocoles pour qu'ils utilisent SSL (Secure Sockets Layer) lorsque vous activez WebSphere Application Server sécurité administrative. Le sous-système d'administration de WebSphere Application Server de chaque serveur utilise SOAP, les connecteurs JMX (Java Management Extensions) et RMI/IIOP (Remote Method Invocation over the Internet Inter-ORB Protocol) pour transmettre les commandes d'administration et les données de configuration. Lorsque la sécurité administrative est désactivée, le connecteur JMX SOAP utilise le protocole HTTP et le connecteur RMI/IIOP utilise le protocole TCP/IP. Lorsque la sécurité administrative est activée, le connecteur JMX SOAP utilise toujours le protocole HTTPS. Lorsque la sécurité administrative est activée, vous pouvez configurer le connecteur JMX RMI/IIOP pour utiliser SSL ou TCP/IP. Il est recommandé d'activer la sécurité administrative, ainsi que SSL, pour protéger les données de configuration confidentielles.

[z/OS]Vous pouvez activer HTTPS pour les applications même si la sécurité administrative est désactivée. Vous pouvez configurer le port SSL d'un serveur spécifique en l'ajoutant à la liste des ports HTTP dans le conteneur Web du serveur, en plus de son ajout aux hôtes virtuels dans la configuration de l'environnement. Vous pouvez connecter l'application Web à l'aide de HTTPS et du port approprié. Les communications internes de WebSphere Application Server for z/OS n'utilisent pas SSL si vous n'activez pas la sécurité administrative.

Lorsque la sécurité administrative est activée, vous pouvez désactiver la sécurité d'application sur chaque serveur d'applications en désélectionnant l'option Activer la sécurité administrative au niveau du serveur. Pour plus d'informations, voir Sécurisation de serveurs d'applications spécifiques. La désactivation du serveur d'applications n'a pas d'incidence sur le sous-système d'administration de ce serveur, qui est contrôlé uniquement par la configuration de la sécurité. Le sous-système d'administration et le code de l'application disponible sur un serveur d'applications partagent la configuration du protocole de sécurité définie en option sur chaque serveur.

Sécurité des ressources Java EE

La sécurité des ressources Java EE est assurée par le conteneur Web et le conteneur d'EJB. Chacun d'eux offre deux types de sécurité, à savoir déclarative et par programmation.

Dans le premier cas, la structure de sécurité d'une application comprend l'intégrité et la confidentialité des données, les conditions d'authentification, les rôles de sécurité et le contrôle des accès. Le contrôle des accès est exprimé sous une forme extérieure à l'application. Notamment, le descripteur de déploiement est le vecteur principal d'une sécurité déclarative pour la plateforme Java EE. WebSphere Application Server gère des règles de sécurité Java EE, et notamment les informations issues du descripteur de déploiement et indiquées par les déployeurs et les administrateurs dans un jeu de fichiers XML. Au moment de l'exécution, le conteneur utilise les règles de sécurité définies dans les fichiers XML pour appliquer des contraintes de données et un contrôle d'accès.

Lorsque la sécurité déclarative s'avère insuffisante pour exprimer le modèle de sécurité d'une application, vous pouvez utiliser la sécurité par programmation pour prendre des décisions sur les accès. Lorsque la sécurité administrative est activée et que la sécurité du serveur d'applications n'est pas désactivée au niveau du serveur, la sécurité des applications, Java EE est appliquée. Si des règles de sécurité sont définies pour une ressource Web, le conteneur Web effectue un contrôle des accès lorsque la ressource est demandée par un client Web. Le conteneur Web interroge le client sur ses données d'authentification (lorsque celles-ci ne sont pas définies selon la méthode d'authentification spécifiée), vérifie que les contraintes relatives aux données sont respectées et détermine si l'utilisateur authentifié possède le rôle de sécurité requis. Le collaborateur de sécurité Web effectue un contrôle d'accès basé sur les rôles à l'aide de l'implémentation d'un gestionnaire d'accès. Ce dernier prend des décisions d'autorisation en fonction des règles de sécurité issues du descripteur de déploiement. Un principal d'utilisateur authentifié peut accéder au servlet ou au fichier JSP demandé s'il possède l'un des rôles de sécurité requis. Les servlets et les fichiers JSP peuvent utiliser les méthodes HttpServletRequest, isUserInRole et getUserPrincipal.

[AIX Solaris HP-UX Linux Windows][IBM i]Lorsque la sécurité administrative et la sécurité d'application sont activées et que la sécurité au niveau du serveur d'applications n'est pas désactivée, le conteneur d'EJB applique le contrôle d'accès lors de l'appel de la méthode EJB.

[z/OS]Lorsque la sécurité globale est activée au niveau de la cellule et que la sécurité du serveur d'applications n'est pas désactivée, le conteneur d'EJB applique le contrôle d'accès lors de l'appel de la méthode EJB.

L'authentification est effectuée même si les droits d'accès de la méthode ne sont pas définis pour la méthode EJB spécifique. Le collaborateur de sécurité EJB assure le contrôle d'accès basé sur les rôles à l'aide de l'implémentation du gestionnaire d'accès. Ce dernier prend des décisions d'autorisation en fonction des règles de sécurité issues du descripteur de déploiement. Un principal de l'utilisateur authentifié est autorisé à accéder à la méthode EJB demandée s'il possède l'un des rôles de sécurité requis. Le code EJB peut utiliser les méthodes EJBContext, isCallerInRole et getCallerPrincipal. Utilisez le rôle Java EE fondé sur le contrôle des accès pour éviter que des utilisateurs non autorisés accèdent aux données stratégiques via Internet ou le réseau intranet. Voir Sécurisation des applications Web à l'aide d'un outil d'assemblage et Sécurisation des applications de bean enterprise.

Sécurité fondée sur les rôles

WebSphere Application Server étend le contrôle des accès fondés sur des rôles de sécurité aux ressources d'administration, telles que le sous-système de gestion JMX, les registres d'utilisateurs et l'espace de noms JNDI (Java Naming and Directory Interface). Le sous-système d'administration WebSphere définit quatre rôles de sécurité pour l'administration :
Rôle Moniteur
Un moniteur peut afficher les informations et l'état, mais ne peut effectuer aucune modification.
Rôle Opérateur
Un opérateur peut déclencher des modifications d'état lors de l'exécution, telles que le démarrage d'un serveur d'applications ou l'arrêt d'une application, mais il ne peut pas modifier la configuration.
Rôle Configurateur
Un configurateur peut modifier les informations de configuration, mais ne peut pas modifier l'état de l'environnement d'exécution.
Rôle Administrateur
Opérateur et configurateur, qui peut également modifier des données de configuration et des stratégies de sécurité, telles que les ID et mots de passe du serveur, activer ou désactiver la sécurité administrative et la sécurité Java 2 et mapper des utilisateurs et des groupes au rôle administrateur.
iscadmins
Le rôle iscadmins a des privilèges d'administrateur pour la gestion des utilisateurs et des groupes à partir de la console d'administration uniquement.
WebSphere Application Server définit deux rôles supplémentaires, disponibles par le biais de l'outil de script wsadmin.
Responsable du déploiement
Un déployeur peut exécuter à la fois des actions de configuration et des opérations d'exécution sur des applications.
AdminSecurityManager
Un gestionnaire de sécurité administrative peut octroyer des rôles d'administration aux utilisateurs. De plus, lorsqu'une sécurité administrative à granularité fine est appliquée, les utilisateurs auxquels ce rôle a été octroyé peuvent gérer des groupes d'autorisation.
Auditeur
Un auditeur peut afficher et modifier les paramètres de configuration du sous-système d'audit de sécurité.

L'utilisateur qui possède le rôle Configurateur peut effectuer la plupart des opérations d'administration, notamment l'installation d'applications et de serveurs d'applications. Lorsque la sécurité administrative est activée, le configurateur ne dispose pas de droits suffisants pour effectuer certaines tâches de configuration, telles que la modification de l'identité et du mot de passe de WebSphere Application Server, la redéfinition du mot de passe et des clés LTPA (Lightweight Third-Party Authentication) et l'affectation des utilisateurs aux rôles de sécurité pour l'administration. Ces tâches de configuration confidentielles requièrent l'utilisation du rôle d'administration car l'ID du serveur est mappé au rôle Administrateur.

Activez la sécurité administrative de WebSphere Application Server pour assurer l'intégrité du sous-système d'administration. La sécurité du serveur d'applications peut être désactivée au cas par cas si vous ne possédez pas d'informations confidentielles à protéger. Pour garantir la sécurité d'administration, voir Autorisation de l'accès pour des rôles d'administration et Affectation d'utilisateurs et de groupes à des rôles.

Droits de sécurité Java 2

WebSphere Application Server utilise le modèle de sécurité Java 2 pour créer un environnement sécurisé et exécuter le code de l'application. La sécurité Java 2 fournit un contrôle des accès affiné et fondé sur les règles pour protéger les ressources système, telles que les fichiers, les propriétés système, l'ouverture des connexions socket, le chargement des bibliothèques, etc. La spécification Java EE version 1.4 définit la série de droits d'accès de sécurité Java 2 standard que les composants Web et EJB doivent posséder.

Tableau 1. Droits d'accès de la sécurité Java EE pour les composants Web. Les autorisations de sécurité Java EE définies pour les composants Web sont répertoriées dans le tableau ci-dessous.
Droits de sécurité Cible Action
java.lang.RuntimePermission loadLibrary  
java.lang.RuntimePermission queuePrintJob  
java.net.SocketPermission * connexion
java.io.FilePermission * lecture, écriture
java.util.PropertyPermission * lecture
Tableau 2. Droits d'accès de la sécurité Java EE pour les composants EJB. Les autorisations de sécurité Java EE définies pour les composants EJB sont répertoriées dans le tableau ci-dessous.
Droits de sécurité Cible Action
java.lang.RuntimePermission queuePrintJob  
java.net.SocketPermission * connexion
java.util.PropertyPermission * lecture
Les règles par défaut de la sécurité WebSphere Application Server Java 2 reposent sur la spécification Java EE version 1.4. Cette spécification accorde aux composants Web des droits d'accès en lecture et en écriture à tous les fichiers du système de fichiers. Cette disposition est peut-être trop permissive. Les règles par défaut de WebSphere Application Server accordent aux composants Web des droits en lecture et en écriture dans le sous-répertoire et la sous-arborescence où le module Web est installé. Les stratégies de sécurité Java 2 par défaut de toutes les machines virtuelles Java et de tous les processus WebSphere Application Server sont définies dans les fichiers de règles suivants :
[IBM i]/QIBM/ProdData/Java400/jdk15/lib/security/java.policy
[IBM i]Ce fichier est utilisé comme règle par défaut pour la machine virtuelle Java (JVM).
[AIX Solaris HP-UX Linux Windows][z/OS]${java.home}/jre/lib/security/java.policy
[AIX Solaris HP-UX Linux Windows][z/OS]Ce fichier est utilisé comme règle par défaut pour la machine virtuelle Java (JVM).
[AIX Solaris HP-UX Linux Windows][IBM i]${USER_INSTALL_ROOT}/properties/server.policy
[AIX Solaris HP-UX Linux Windows][IBM i]Ce fichier est utilisé comme règle par défaut pour tous les processus serveur du produit.
[z/OS]$WAS_HOME/properties/server.policy
[z/OS]Ce fichier est utilisé comme règle par défaut pour tous les processus serveur du produit.

Pour simplifier la gestion, les règles de WebSphere Application Server reposent sur le type de ressource plutôt que sur la base de code (emplacement). Les fichiers suivants sont les fichiers de règles par défaut d'un sous-système WebSphere Application Server. Ces fichiers de règles, qui sont une extension de l'environnement d'exécution de WebSphere Application Server sont appelés interfaces SPI (Service Provider Programming Interfaces) et sont partagés par plusieurs applications Java EE :

[AIX Solaris HP-UX Linux Windows]
  • racine_profil/config/cells/nom_cellule/nodes/nom_noeud/spi.policy

    Ce fichier est utilisé pour les ressources imbriquées définies dans le fichier resources.xml, telles que le service JMS (Java Message Service), JavaMail et les pilotes JDBC.

  • racine_profil/config/cells/nom_cellule/nodes/nom_noeud/library.policy

    Ce fichier est utilisé par la bibliothèque partagée définie par la console d'administration WebSphere Application Server.

  • racine_profil/config/cells/nom_cellule/nodes/nom_noeud/app.policy

    Ce fichier est utilisé comme règle par défaut pour les applications Java EE.

[z/OS]
  • $WAS_HOME/config/cells/nom_cellule/nodes/nom_noeud/spi.policy

    Ce fichier est utilisé pour les ressources imbriquées définies dans le fichier resources.xml, telles que le service JMS (Java Message Service), l'API JavaMail et les pilotes JDBC.

  • $WAS_HOME/config/cells/nom_cellule/nodes/nom_noeud/library.policy

    Ce fichier est utilisé par la bibliothèque partagée définie par la console d'administration WebSphere Application Server.

  • $WAS_HOME/config/cells/nom_cellule/nodes/nom_noeud/app.policy

    Ce fichier est utilisé comme règle par défaut pour les applications Java EE.

[IBM i]
  • racine_profil/config/cells/nom_cellule/nodes/nom_noeud/spi.policy

    Ce fichier est utilisé pour les ressources imbriquées définies dans le fichier resources.xml, telles que le service JMS (Java Message Service), JavaMail et les pilotes JDBC.

  • racine_profil/config/cells/nom_cellule/nodes/nom_noeud/library.policy

    Ce fichier est utilisé par la bibliothèque partagée définie par la console d'administration WebSphere Application Server.

  • racine_profil/config/cells/nom_cellule/nodes/nom_noeud/app.policy

    Ce fichier est utilisé comme règle par défaut pour les applications Java EE.

En règle générale, les applications ne requièrent pas plus de droits pour être exécutées que ceux recommandés par la spécification Java EE pour assurer leur portabilité sur différents serveurs d'applications. Toutefois, certaines applications peuvent requérir des droits d'accès supplémentaires. WebSphere Application Server prend en charge la mise en package d'un fichier was.policy avec chaque application pour octroyer des droits supplémentaires à cette application.
Avertissement : Vous devez être très prudent lorsque vous décidez d'accorder des droits supplémentaires à une application car vous risquez de compromettre l'intégrité du système.

Le chargement de bibliothèques dans WebSphere Application Server permet aux applications de quitter le bac à sable Java. WebSphere Application Server utilise un fichier de règles de filtrage pour vous alerter lorsque l'installation d'une application échoue car elle requiert des droits supplémentaires. Par exemple, il est recommandé de ne pas accorder le droit java.lang.RuntimePermission exitVM à une application afin que le code de l'application ne puisse pas arrêter WebSphere Application Server.

Les règles de filtrage sont définies par le masque du filtre dans le fichier racine_profil/config/cells/nom_cellule/filter.policy. En outre, WebSphere Application Server effectue un filtrage des droits d'exécution en fonction de la règle indiquée pour s'assurer que le code de l'application n'a pas reçu de droits dangereux pour l'intégrité du système.

De nombreuses applications développées pour des versions précédentes de WebSphere Application Server risquent donc de ne pas être conformes à la sécurité Java 2. Pour migrer rapidement ces applications vers la version la plus récente de WebSphere Application Server, vous pouvez leur accorder provisoirement le droit java.security.AllPermission dans le fichier was.policy. Testez ces applications pour vérifier qu'elles s'exécutent dans un environnement où la sécurité Java 2 est active. Par exemple, identifiez les droits supplémentaires éventuellement requis et accordez ces droits uniquement à une application spécifique. Si vous n'accordez pas le droit AllPermission aux applications, vous limitez les risques d'altération du système. Pour plus d'informations sur la migration des applications, voir Migration de la stratégie de sécurité Java 2.

L'environnement d'exécution de WebSphere Application Server utilise la sécurité Java 2 pour protéger les fonctions d'exécution confidentielles. Les applications auxquelles est accordé le droit AllPermission ont non seulement accès aux ressources système confidentielles, mais aussi aux ressources d'exécution de WebSphere Application Server. Elles peuvent altérer ces deux types de ressources. Dans certains cas où une application est considérée comme sûre, WebSphere Application Server permet de désactiver la sécurité Java 2 au niveau de chaque serveur d'applications. Vous pouvez appliquer la sécurité Java 2 par défaut dans la console d'administration et désélectionner l'indicateur de sécurité Java 2 pour la désactiver sur un serveur d'applications spécifique.

Lorsque vous utilisez les options Activer la sécurité administrative et Utiliser la sécurité Java 2 pour limiter l'accès aux applications par les ressources locales dans le panneau Sécurité globale de la console d'administration, les informations et les autres données de configuration confidentielles sont stockées dans un jeu de fichiers de configuration XML. Les contrôles des accès basés sur les rôles et sur les droits de la sécurité Java 2 permettent de protéger l'intégrité des données de configuration. L'exemple utilise la protection des données de configuration pour expliquer comment l'intégrité du système est maintenue.
Avertissement : L'option Activer la sécurité globale, disponible dans les versions précédentes de WebSphere Application Server, est identique à l'option Activer la sécurité administrative de Version 9.0. De plus, l'option Activer la sécurité Java 2, disponible dans les versions précédentes est identique à l'option Utiliser la sécurité Java 2 pour limiter l'accès aux applications par les ressources locales dans Version 9.0.
  • Lorsque la sécurité Java 2 est appliquée, le code de l'application ne peut pas accéder aux classes d'exécution WebSphere Application Server chargées de gérer les données de configuration tant qu'il ne dispose pas des droits d'exécution WebSphere Application Server.
  • Lorsque la sécurité Java 2 est appliquée, le code de l'application ne peut pas accéder aux fichiers de configuration XML de WebSphere Application Server tant qu'il ne dispose pas des droits de lecture et d'écriture nécessaires pour ces fichiers.
  • Le sous-système d'administration JMX fournit SOAP sur HTTP ou HTTPS et une interface éloignée RMI/IIOP pour permettre aux programmes d'applications d'extraire et de modifier les fichiers et les données de configuration. Lorsque la sécurité administrative est activée, une application peut modifier la configuration de WebSphere Application Server dans la mesure où elle présente des données d'authentification valides et où l'identité de sécurité possède les rôles requis.
  • Si un utilisateur peut désactiver la sécurité Java 2, il peut également modifier la configuration de WebSphere Application Server, y compris l'identité de sécurité de WebSphere Application Server, les données d'authentification et d'autres données confidentielles. Seuls les utilisateurs possédant le rôle de sécurité Administrateur sont autorisés à désactiver la sécurité Java 2.
  • Comme l'identité de sécurité de WebSphere Application Server est associée au rôle Administrateur, seuls les utilisateurs possédant ce rôle sont autorisés à désactiver la sécurité administrative, à modifier les ID et mots de passe du serveur et à mapper les utilisateurs et les groupes vers des rôles d'administration.
[AIX Solaris HP-UX Linux Windows][IBM i]

Autres ressources d'exécution

Les autres ressources d'exécution de WebSphere Application Server sont protégées par un mécanisme identique, comme décrit précédemment. Il est indispensable d'activer la sécurité administrative de WebSphere Application Server et d'utiliser la sécurité Java 2 pour limiter l'accès des ressources locales aux applications. La spécification Java EE définit plusieurs méthodes d'authentification pour les composants Web : authentification de base HTTP, authentification par formulaire et authentification par certificat client HTTPS. Lorsque vous utilisez la connexion par certificat client, il est plus pratique pour le navigateur client que les ressources Web possèdent une contrainte pour les données confidentielles ou intégrales. Si un navigateur utilise HTTP pour accéder à la ressource Web, le conteneur Web le redirige automatiquement vers le port HTTPS. Le protocole de sécurité CSIv2 prend également en charge l'authentification par certificat client. Vous pouvez également utiliser l'authentification client SSL pour configurer des communications sécurisées entre un groupe de serveurs sélectionnés, sur la base d'une relation de confiance.

[z/OS]Le protocole de sécurité CSIv2 prend également en charge l'authentification par certificat client. Vous pouvez utiliser l'authentification client SSL pour configurer des communications sécurisées entre un groupe de serveurs sélectionnés, sur la base d'une relation de confiance.

A partir d'un plug-in WebSphere Application Server installé sur un serveur Web, vous pouvez configurer une authentification mutuelle SSL entre le serveur Web et le serveur HTTPS de WebSphere Application Server. Lorsque vous utilisez un certificat, vous pouvez restreindre l'action du plug-in WebSphere Application Server afin de limiter les communications aux deux serveurs WebSphere Application Server sélectionnés, comme illustré dans la figure ci-dessous. Notez que vous pouvez utiliser des certificats auto-signés pour réduire l'administration et les coûts.
Par exemple, vous souhaitez limiter le serveur HTTPS au système WebSphere Application Server A et au système WebSphere Application Server B pour accepter uniquement les connexions socket sécurisées provenant du plug-in WebSphere Application Server W.
Par exemple, vous souhaitez limiter le serveur HTTPS au serveur WebSphere Application Server A et au serveur WebSphere Application Server B pour accepter uniquement les connexions socket sécurisées provenant du plug-in WebSphere Application Server W.
  • [AIX Solaris HP-UX Linux Windows][IBM i]Pour effectuer cette tâche, vous pouvez générer trois certificats à l'aide des utilitaires KEYMAN et de gestion des certificats. En outre, vous pouvez utiliser le certificat W et les certificats sécurisés A et B. Configurez le serveur HTTPS de WebSphere Application Server A pour qu'il utilise le certificat A et qu'il établisse une relation de confiance avec le certificat W.
  • [z/OS]Pour effectuer cette tâche, vous pouvez générer trois certificats à l'aide de la fonction RACF (Resource Access Control Facility), appelés certificats W, A et B. Configurez le plug-in WebSphere Application Server afin qu'il utilise le certificat W et les certificats sécurisés A et B. Configurez le serveur HTTPS de WebSphere Application Server A pour qu'il utilise le certificat A et qu'il établisse une relation de confiance avec le certificat W.
Configurez le serveur HTTPS de WebSphere Application Server B pour qu'il utilise le certificat B et qu'il établisse une relation de confiance avec le certificat W.
Tableau 3. Relations de confiance de l'exemple. La relation de confiance illustrée dans la figure précédente est présentée dans le tableau ci-dessous.
Serveur Clé Confiance
Plug-in WebSphere Application Server W A, B
WebSphere Application Server A A W
WebSphere Application Server B B W

WebSphere Application Server Deployment Manager représente le point d'administration central. Les commandes de gestion système sont envoyées par le gestionnaire de déploiement à chaque serveur d'applications. Lorsque la sécurité administrative est activée, vous pouvez configurer WebSphere Application Server afin qu'il requiert l'authentification mutuelle et SSL.

Vous pouvez appliquer des restrictions au serveur WebSphere Application Server A afin qu'il communique uniquement avec le serveur WebSphere Application Server C et que le serveur WebSphere Application Server B puisse communiquer uniquement avec le serveur WebSphere Application Server D. Tous les serveurs WebSphere Application Server doivent pouvoir communiquer avec le gestionnaire de déploiement de WebSphere Application Server E ; par conséquent, lors de l'utilisation de certificats auto-signés, vous pouvez configurer CSIv2, la clé SOAP/HTTPS et la relation de confiance, comme indiqué dans le tableau ci-dessous.
Tableau 4. CSIv2, clé SOAP/HTTPS et relations de confiance de l'exemple. Les relations de clé et de confiance CSIv2 et SOAP/HTTPS sont répertoriées dans le tableau suivant.
Serveur Clé Confiance
WebSphere Application Server A A C, E
WebSphere Application Server B B D, E
WebSphere Application Server C C A, E
WebSphere Application Server D D B, E
WebSphere Application Server Deployment Manager E E A, B, C, D

Lorsque WebSphere Application Server est configuré pour utiliser un registre d'utilisateurs LDAP (Lightweight Directory Access Protocol), vous pouvez également configurer le protocole SSL avec l'authentification mutuelle entre chaque serveur d'applications et le serveur LDAP en utilisant des certificats auto-signés afin que WebSphere Application Server transmette uniquement des mots de passe invisibles au serveur LDAP.

Dans cet exemple, les processus d'agent de noeud ne sont pas étudiés. Chaque agent de noeud doit communiquer avec les serveurs d'applications situés sur le même noeud et avec le gestionnaire de déploiement. Les agents de noeud doivent également communiquer avec les serveurs LDAP lorsqu'ils sont configurés pour utiliser un registre d'utilisateurs LDAP. Vous pouvez laisser le gestionnaire de déploiement et les agents de noeud utiliser le même certificat. Supposons que les serveurs d'applications A et C se trouvent sur le même noeud. L'agent de ce noeud doit posséder les certificats A et C dans son magasin de tiers dignes de confiance.

[AIX Solaris HP-UX Linux Windows][IBM i]WebSphere Application Server ne fournit pas d'utilitaires de configuration ou de gestion des registres. En outre, il ne définit pas les règles régissant les mots de passe du registre. Il est conseillé d'utiliser les règles recommandées par le registre, notamment la longueur définie pour le mot de passe et la date d'expiration.


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_plan
Nom du fichier : csec_plan.html