28. Le logging 30. JNI (Java Native Interface) Imprimer Sommaire Consulter avec table des matières
Développons en Java   v 1.90  
Copyright (C) 1999-2013 .  

 

29. La sécurité

 

chapitre 2 9

 

 

Niveau : niveau 5 Confirmé 

 

Depuis sa conception, la sécurité dans le langage Java a toujours été une grande préoccupation pour Sun.

Avec Java, la sécurité revêt de nombreux aspects :

Ces deux premiers aspects ont été intégrés à java dès sa première version.

Ce chapitre contient plusieurs sections :

 

 

en construction
Ce chapitre est très incomplet : la suite de ce chapitre sera développée dans une version future de ce document

 

29.1. La sécurité dans les spécifications du langage

Les spécifications du langage apportent de nombreuses fonctionnalités pour renforcer la sécurité du code aussi bien lors de la phase de compilation que lors de la phase d'exécution :

 

29.1.1. Les contrôles lors de la compilation

 

 

29.1.2. Les contrôles lors de l'exécution

La JVM exécute un certain nombre de contrôles au moment de l'exécution :

 

29.2. Le contrôle des droits d'une application

Un système de contrôle des droits des applications a été intégré à Java dès sa première version notamment pour permettre de sécuriser l'exécution des applets. Ces applications téléchargées sur le réseau et exécutées sur le poste client doivent impérativement assurer aux personnes qui les utilisent qu'elles ne risquent pas de réaliser des actions malveillantes sur le système dans lequel elles s'exécutent.

Le modèle de sécurité relatif aux droits des applications développées en Java a évolué au fur et à mesure des différentes versions de Java.

 

29.2.1. Le modèle de sécurité de Java 1.0

Le modèle proposé par Java 1.0 est très sommaire puisqu'il ne distingue que deux catégories d'applications :

Le modèle est basé sur le "tout ou rien". Les applications locales ont tous les droits et les applications téléchargées ont des droits très limités. Les restrictions de ces dernières sont nombreuses :

La mise en oeuvre de ce modèle est assurée par le "bac à sable" (sandbox en anglais) dans lequel s'exécutent les applications téléchargées.

 

29.2.2. Le modèle de sécurité de Java 1.1

Le modèle proposé par la version 1.0 est très efficace mais beaucoup trop restrictif surtout dans le cadre d'une utilisation personnelle telle que celle des applications pour un intranet par exemple.

Le modèle de la version 1.1 propose la possibilité de signer les applications packagées dans un fichier .jar. Une application ainsi signée possède les mêmes droits qu'une application locale.

 

29.2.3. Le modèle Java 1.2

Le modèle proposé par la version 1.1 a apporté des débuts de solution pour attribuer des droits à certaines applications. Mais ce modèle manque cruellement de souplesse puisqu'il s'appuie toujours sur le modèle "tout au rien".

Le modèle de la version 1.2 apporte enfin une solution très souple mais plus compliquée à mettre en oeuvre.

Les droits accordés à une application sont rassemblés dans un fichier externe au code qui se nomme politique de sécurité. Pour les différentes applications, l'ensemble des fichiers se situe dans le répertoire lib/security du répertoire où est installé le JRE. Par convention, ces fichiers ont pour extension .policy.

 

29.3. JCE (Java Cryptography Extension)

JCE est une API qui propose de standardiser l'utilisation de la cryptographie en restant indépendant des algorithmes utilisés. Elle prend en compte le cryptage/décryptage de données, la génération de clés et l'utilisation de la technologie MAC (Message Authentication Code) pour garantir l'intégrité d'un message.

JCE a été intégrée au JDK 1.4. Auparavant, cette API était disponible en tant qu'extension pour les JDK 1.2 et 1.3.

Pour pouvoir utiliser cette API, il faut obligatoirement utiliser une implémentation développée par un fournisseur (provider). Avec le JDK 1.4, Sun fournit une implémentation de référence nommée SunJCE.

Les classes et interfaces de l'API sont regroupées dans le package javax.crypto

 

29.3.1. La classe Cipher

Cette classe encapsule le cryptage et le décryptage de données.

 

La méthode statique getInstance() permet d'obtenir une instance particulière d'un algorithme proposé par un fournisseur. Le nom de l'algorithme est fourni en paramètre de la méthode sous la forme d'une chaîne de caractères.

Avant la première utilisation de l'instance obtenue, il faut initialiser l'objet en utilisant une des nombreuses surcharges de la méthode init().

 

29.4. JSSE (Java Secure Sockets Extension)

Les classes et interfaces de cette API sont regroupées dans les packages javax.net et javax.net.ssl.

 

29.5. JAAS (Java Authentication and Authorization Service)

Les classes et interfaces de cette API sont regroupées dans le package javax.security.auth

Cette API a été intégrée au J.D.K. 1.4.


  28. Le logging 30. JNI (Java Native Interface) Imprimer Sommaire Consulter avec table des matières Développons en Java   v 1.90  
Copyright (C) 1999-2013 .