Migration de la stratégie de sécurité Java 2

Cette rubrique fournit une aide pour la migration de la stratégie de sécurité Java™ 2.

Pourquoi et quand exécuter cette tâche

Versions précédentes de WebSphere Application Server

WebSphere Application Server utilise le gestionnaire de sécurité Java 2 dans l'environnement d'exécution du serveur pour empêcher les applications d'entreprise d'appeler les méthodes System.exit et System.setSecurityManager. Ces deux API Java ont des effets indésirables lorsqu'elles sont appelées par des applications d'entreprise. L'API System.exit, par exemple, provoque l'arrêt prématuré de la machine virtuelle Java, ce qui n'est pas recommandé pour le serveur d'applications.

Pour prendre correctement en charge la sécurité Java 2, l'intégralité de l'exécution du serveur doit être marquée comme privilégiée (les appels de l'API doPrivileged étant insérés aux emplacements corrects) et doit identifier les ensembles de droits ou les règles par défaut). Le code de l'application n'est pas privilégié et dépend des stratégies définies dans les fichiers de règles. L'instrumentation doPrivileged est importante et nécessaire pour la prise en charge de la sécurité Java 2. Sans cette instrumentation, vous devez accorder au code d'application les droits requis par le module d'exécution du serveur. Cette situation est due à la conception et à l'algorithme utilisé par la sécurité Java 2 pour appliquer les vérifications des droits d'accès. Reportez-vous à l'algorithme des droits d'accès de vérification de la sécurité Java 2.

Les deux droits d'accès suivants sont appliqués par le gestionnaire de sécurité Java 2 (codé en dur) pour WebSphere Application Server :
  • java.lang.RuntimePermission(exitVM)
  • java.lang.RuntimePermission(setSecurityManager)

Ces droits d'accès sont refusés au code de l'application, quel que soit le contenu de la stratégie de sécurité Java 2. Toutefois, ces droits d'accès sont accordés à l'exécution du serveur. Aucune autre vérification de droit n'est appliquée.

Seuls deux droits sont pris en charge :
  • java.net.SocketPermission
  • java.net.NetPermission

Toutefois, le module d'exécution du serveur du produit n'est pas entièrement marqué correctement comme privilégié. Vous devez accorder au code de l'application tous les droits (et non pas seulement les deux spécifiés précédemment) pour que l'application d'entreprise puisse être exécutée correctement. Cette stratégie de sécurité Java 2 pour les applications d'entreprise est très souple.

Nouveautés

La sécurité Java 2 est totalement prise en charge dans WebSphere Application Server, ce qui signifie que tous les droits sont appliqués. La stratégie de sécurité Java 2 par défaut pour l'application d'entreprise constitue l'ensemble de droits recommandés définis par la spécification Java Platform, Enterprise Edition (Java EE) version 1.4. Voir le fichier racine_profil/config/cells/nom_cellule/nodes/nom_noeud/app.policy pour en savoir plus sur la stratégie de sécurité Java 2 par défaut qui est attribuée aux applications d'entreprise. Cette stratégie est beaucoup plus stricte que celles des versions précédentes.

Toutes les stratégies sont déclaratives. Le gestionnaire de sécurité du produit gère toutes les stratégies déclarées dans les fichiers de règles. Il existe une exception à cette règle : l'accès aux droits déclarés dans le fichier racine_profil/config/cells/nom_cellule/filter.policy est refusé aux applications d'entreprise.

Remarque : La stratégie de sécurité Java 2 par défaut des applications d'entreprise est beaucoup plus stricte et tous les droits sont appliqués dans WebSphere Application Server Version 9.0. La règle de sécurité peut échouer car le code d'application ne dispose pas des droits nécessaires alors qu'il est possible d'accéder par programmation aux ressources système (E-S de fichier, par exemple) pour lesquelles une vérification de droits est désormais effectuée.

N'utilisez pas la permission setSecurityManager dans le code d'application pour définir un gestionnaire de sécurité. Lorsqu'une application utilise la permission setSecurityManager, cela provoque un conflit avec le gestionnaire de sécurité interne de WebSphere Application Server. Si vous devez définir un gestionnaire de sécurité dans une application pour des raisons de RMI, vous devez également activer l'option Utiliser la sécurité Java 2 pour limiter l'accès aux applications par les ressources locales dans la page Sécurité globale dans la console d'administration de WebSphere Application Server. WebSphere Application Server enregistre alors un gestionnaire de sécurité. Le code d'application peut vérifier si ce gestionnaire de sécurité est enregistré à l'aide de l'API System.getSecurityManager().

Migration des propriétés système

Les propriétés système suivantes sont utilisées dans les versions précédentes liées à la sécurité Java 2 :
  • java.security.policy. Chemin absolu du fichier de règles (action requise). Cette propriété système contient les droits système (droits accordés à la machine Java Virtual Machine [JVM] et au module d'exécution serveur du produit) et les droits d'application d'entreprise. Migrez la stratégie de sécurité Java 2 de l'application d'entreprise vers Version 9.0. Pour la migration de la stratégie de sécurité Java 2, reportez-vous à la procédure de migration de la stratégie de sécurité Java 2.
  • enableJava2Security. Permet d'activer la mise en application de la sécurité Java 2 (aucune action requise). Cette propriété du système est obsolète ; un indicateur dans l'API de configuration WebSphere permet de contrôler s'il est nécessaire d'activer la sécurité Java 2. Activez cette option via la console d'administration.
  • was.home. Etendu au répertoire d'installation de WebSphere Application Server (une action peut être requise). Cette propriété système est déconseillée et remplacée par les propriétés ${user.install.root} et ${was.install.root}. Si le répertoire contient des données propres à l'instance, ${user.install.root} est utilisée ; sinon ${was.install.root} est utilisée. Ces propriétés peuvent être utilisées indifféremment pour les environnements WebSphere Application Server ou WebSphere Application Server, Network Deployment. Reportez-vous à la procédure de migration des stratégies de sécurité Java 2.

Migration de la stratégie de sécurité Java 2

Il n'existe pas de méthode simple pour migrer automatiquement le fichier de règles Java vers Version 9.0. Cela est dû au fait que des droits système et des droits d'application coexistent dans le même fichier de règles. Copiez manuellement la stratégie de sécurité Java 2 des applications d'entreprise dans un fichier was.policy ou app.policy. Toutefois, la migration de la stratégie de sécurité Java 2 vers un fichier was.policy représente la meilleure méthode car les symboles ou l'attribut code relatif sont utilisés à la place de l'attribut code absolu. Cela a de nombreux avantages. Accordez les droits définis dans le fichier was.policy uniquement à une application d'entreprise spécifique, et les droits définis dans le fichier app.policy à toutes les applications d'entreprise exécutées sur le noeud auquel le fichierapp.policy appartient.

Pour plus d'informations sur la gestion des stratégies, voir Fichiers de règles de sécurité Java 2.

L'exemple ci-après illustre la migration d'une stratégie de sécurité Java 2 à partir d'une version antérieure. Il comprend le fichier de règles de la sécurité Java 2 de l'application d'entreprise app1.ear et les droits d'accès système, droits accordés à la machine JVM (Java virtual machine) et à l'environnement d'exécution du serveur.

[AIX Solaris HP-UX Linux Windows][z/OS]L'emplacement par défaut du fichier de règles de sécurité Java 2 est racine_profil/properties/java.policy. Les droits par défaut sont omis pour plus de clarté :

[IBM i]L'emplacement par défaut du fichier de règles de sécurité Java 2 est racine_profil/properties/java.policy. Les droits par défaut sont omis pour plus de clarté :

// Pour les exemples de produit
   grant codeBase "file:${racine_serveur_app}/installedApps/app1.ear/-" {
     permission java.security.SecurityPermission "printIdentity";
     permission java.io.FilePermission "${racine_serveur_app}${/}temp${/}fichier.txt", 
       "read";
   };

Dans un souci de clarté, tous les droits d'accès indiqués dans cet exemple sont migrés au niveau de l'application. Toutefois, vous pouvez accorder des droits d'accès à un niveau plus granulaire au niveau de composant (Web, beans enterprise, connecteur ou fichier JAR (Java) d'utilitaire) ou à un composant spécifique.

Procédure

  1. Assurez-vous que la sécurité Java 2 est désactivée sur le serveur d'applications.
  2. Créez un fichier was.policy, si vous n'en possédez pas, ou mettez à jour le fichier was.policy des applications migrées dans le référentiel de configuration en indiquant les éléments suivants :
    grant codeBase "file:${application}" {
         permission java.security.SecurityPermission "printIdentity";
         permission java.io.FilePermission "
                 ${user.install.root}${/}temp${/}fichier.txt", "read";
       };

    La troisième et la quatrième lignes de l'exemple de code précédent sont scindées à des fins de présentation.

    Le fichier was.policy se trouve dans le répertoire racine_profil/config/cells/nom_cellule/applications/app.ear/deployments/app/META-INF/.

  3. Utilisez un outil d'assemblage pour associer le fichier was.policy au fichier EAR.

    Vous pouvez également utiliser cet outil pour valider le contenu du fichier was.policy. Pour plus d'informations, voir Configuration du fichier was.policy pour la sécurité Java 2.

  4. Vérifiez que l'application d'entreprise ne nécessite aucun droit supplémentaire en dehors des droits migrés de la sécurité Java 2 et du jeu de droits d'accès par défaut déclarés dans le fichier ${user.install.root}/config/cells/nom_cellule/nodes/nom_noeud/app.policy. Cette validation comprend la vérification et l'inspection du code, la vérification de la documentation de l'application, le test du bac à sable des applications d'entreprise migrées avec la sécurité Java 2 activée dans un environnement de pré-production. Pour Reportez-vous aux API du kit de développeur protégées par la sécurité Java 2 pour plus d'informations sur les API qui sont protégées par la sécurité Java 2. Si vous utilisez des bibliothèques tierces, consultez la documentation du fournisseur pour connaître les API protégées par la sécurité Java 2. Assurez-vous que vous avez accordé à l'application tous les droits requis. Dans le cas contraire, son exécution risque d'échouer lorsque la sécurité Java 2 est activée.
  5. Effectuez un test de pré-production avec l'application d'entreprise migrée avec la sécurité Java 2 activée. Activez la fonction de trace du gestionnaire de sécurité WebSphere Application Server Java 2 dans un environnement de test de préproduction avec la chaîne de trace suivante : com.ibm.ws.security.core.SecurityManager=all=enabled. Cette fonction de trace peut s'avérer utile pour déboguer l'exception AccessControlException générée lorsqu'une application ne dispose pas des droits d'accès dont elle a besoin ou qu'une partie du code système n'a pas été correctement définie comme privilégiée. Lorsque l'exception est créée, la fonction de trace effectue un cliché des données de trace sur la pile et des droits d'accès accordés aux classes sur la pile d'appels.

    Pour plus d'informations, voir la rubrique Exception de contrôle d'accès pour la sécurité Java 2.

    Remarque : Les stratégies de sécurité Java 2 étant beaucoup plus contraignantes que celles appliquées dans les versions précédentes, l'administrateur ou le responsable du déploiement doit vérifier ses applications d'entreprise pour déterminer s'il doit leur accorder des droits supplémentaires avant d'activer la sécurité Java 2. Si vous n'accordez pas les droits nécessaires aux applications d'entreprise, leur exécution échoue.

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_migratejava2sec
Nom du fichier : tsec_migratejava2sec.html