La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

Le modèle de sécurité de Java 2 SEE - Février 2000 Sécurité logique et Objets.

Présentations similaires


Présentation au sujet: "Le modèle de sécurité de Java 2 SEE - Février 2000 Sécurité logique et Objets."— Transcription de la présentation:

1 Le modèle de sécurité de Java 2 SEE - Février 2000 Sécurité logique et Objets

2 Page 2 Pourquoi toujours plus de sécurité dans Java ? Java est un langage particulier : orienté réseau / Internet / Web le code est téléchargé progressivement (avec possibilité de sources multiples) dynamiquement (risques de modification) le vecteur est publique et « à risque » le code peut avoir besoin daccéder à des ressources locales Protéger les ressources locales contre du code... malveillant (virus, cheval de Troie, …) indiscret / instigateur (accès à des informations personnelles) Protéger le code et les données quil gère contre … leurs utilisateurs

3 Page 3 De quels services de sécurité a-t-on besoin ? Dauthentification de lorigine du code on veut authentifier lauteur / le fournisseur, pas le colporteur des utilisateurs du code Dintégrité du code transmis des données générées / manipulées par le code De confidentialité des données générées / manipulées par le code De contrôle daccès du code sur les ressources locales de lutilisateur sur les ressources locales ou sur les ressources applicatives Dadministration de la sécurité ! Eventuellement : de non-répudiation, d audit, …

4 Page 4 Propriétés recherchées Généricité Souplesse de configuration et dutilisation Interchangeabilité des moyens cryptographiques des services de sécurité authentification autorisation administration Besoin de changer de fournisseur, de sadapter à des contraintes légales, de suivre létat de lArt, etc.

5 Page 5 « Sécurité » du langage Plusieurs niveau daccès aux classes, méthodes et attributs : private, package, protected, public Contrôles dintégrité à la compilation et à lexécution variables non initialisées dépassement de tableau conversion de type illégale Vérificateur de bytecode (code intermédiaire) mini-démonstrateur de théorème ; vérifie en particulier : que le format du fichier est correct que les classes classes finales ne sont pas sous-classées que les contraintes générales du langage sont respectées Chargeur de classe spécialisable Gestionnaire de sécurité / Contrôleur daccès contrôle tous les accès aux ressources (en particulier OS)

6 Page 6 Le « bac à sable » Ou : « sandbox » Ce principe existe depuis le JDK 1.0 : fournir un environnement dexécution restreint au code « inconnu » (en particulier, celui arrivant du réseau) limitation des accès aux ressources locales : §système de fichiers §moyens de communication, sauf vers le serveur ayant transmis le code à certaines données système §liste des chemins d accès aux classes locales §nom de l utilisateur courant §... Distinction entre « applet » et « application » une application a « tous les droits » une applet chargée localement a « tous les droits » une applet chargée depuis le réseau subit le principe du « bac à sable »

7 Page 7 Modèle de sécurité du JDK 1.0

8 Page 8 La signature de code A partir du JDK 1.1, Java permet daccorder sa confiance à du code téléchargé : par le biais dune signature digitale réalisée au moyen doutils livrés avec le JDK la signature associée à une classe (ou un ensemble de classes fichiers JAR), et les choix de réseaux de confiance exprimés par le réceptionnaire, permettent de garantir à celui-ci lorigine du code téléchargé et son intégrité le code signé et approuvé obtient les mêmes droits que le code local sur les ressources locales La distinction entre « applet » et « application » est maintenue en JDK 1.1, mais disparaît en JDK 1.2 : les applications peuvent être soumises à des politiques de sécurité et être signées

9 Page 9 Modèle de sécurité du JDK 1.1

10 Page 10 Le contrôle daccès (1/5) Le JDK 1.2 introduit un modèle de contrôle daccès fin et paramétrable, applicable aussi bien aux applets quaux applications, au travers des notions de : permission : un couple droit + ressource exemple de droit : « read », « write », « execute », … exemple de ressource : « fichier », « port », « imprimante », … les définitions de droit et de ressource sont génériques et extensibles le modèle est applicable aux ressources applicatives toutes les classes « permission » doivent : implémenter une méthode « implies » : §« a implies b » signifie : si la permission « a » est accordée, alors la permission « b » lest aussi Permission p1 = new FilePermission("/tmp/*", "read"); Permission p2 = new FilePermission("/tmp/readme", "read"); p1.implies(p2) == true p2.implies(p1) == false (implicitement) définir une liste de droits et un système de nommage des ressources

11 Page 11 Le contrôle daccès (2/5)

12 Page 12 Le contrôle daccès (3/5) politique de sécurité : un ensemble de « permissions » sapplique aussi bien au code local quau code réseau configurée par lutilisateur ou un administrateur grant [codebase " "] [signedBy " "] { permission [permission class] ["target"], ["actions"]; permission... }; grant codebase "http://www.sun.com/", signedby "JavaSoft Division" { permission java.net.SocketPermission "java.sun.com", "connect, accept"; }; les alias font référence à des clés / certificats stockés dans un fichier spécial ( keystore maintenu par lutilisateur)

13 Page 13 Le contrôle daccès (4/5) origine du code (« code source ») : un couple auteur + serveur dorigine domaine de protection ensemble de classes (désignées par une « origine de code ») dont les instances bénéficient des mêmes « permissions » une façon de se créer ses propres « bacs à sable »… Permissions permissions = Policy.getPolicy().getPermissions(codesource); ProtectionDomain domain = new ProtectionDomain(codesource, permissions);

14 Page 14 Le contrôle daccès (5/5) Les applications Java peuvent utiliser ce modèle pour bâtir leur propres contrôles accès aux options de menus et aux boutons daction accès aux données dune table... Le gestionnaire de sécurité sappuie sur ce modèle pour contrôler les accès aux ressources locales

15 Page 15 Modèle de sécurité du JDK 1.2 Signé ou non Chargeur de classes

16 Page 16 Architecture de sécurité d une application Java 1.2 Remote class filesLocal class files Signed class files Byte code verifier Class loader Core Java API Security package Core API class files Operating system Access controller Security manager Key database Eléments jouant un rôle dans la « sandbox » Respect du langage Chargement des classes qui ne sont pas dans le CLASSPATH Limite les accès à l OS Auth. des classes signées + crypto.

17 Page 17 Le chargeur de classes Un des rôles fondamentaux dun chargeur de classe est de maintenir une distinction de nommage entre des classes chargées sur des sites différents : deux classes de même nom (et éventuellement de même package), chargée depuis deux sites différents ne sont pas équivalentes et peuvent avoir des permissions différentes le JDK 1.2 facilite le développement de nouveau chargeurs de classe Le JDK 1.2 est livré avec deux nouveaux chargeurs : le SecureClassLoader : sert de base au développement dautres chargeurs de classe associe un domaine de protection aux classes quil charge l URLClassLoader : chargeur à usage général

18 Page 18 Gestionnaire de sécurité et contrôleur daccès Ou : « Security Manager » et « Access Controller » Le gestionnaire de sécurité existe depuis le JDK 1.0 mais été remanié en 1.2 : est maintenu en 1.2 pour des raisons de compatibilité sous-traite toutes les tâches de calcul de contrôle d accès au contrôleur d accès Le contrôleur daccès est un nouveau composant en 1.2 : réalise toute les prises de décision daccès « système », sur la base de fichiers de politique de sécurité est impliqué dans le passage de morceaux de code en mode « privilégié »

19 Page 19 Blocs et objets protégés Très utile pour les composants intermédiaires darchitectures trois tiers, ou les composants qui font de la délégation de service (serveur d imprimante, par exemple), etc. Permet à un composant dexécuter un bout de code avec ses permissions propres (ie. : celles liées à lorigine et au signataire du composant), indépendamment de celles de celui qui a appelé le composant exécutant la fonction protégée void someMethod() { // normal code here try { AccessController.beginPrivileged(); // privileged code goes here } finally { AccessController.endPrivileged(); }

20 Page 20 Accès aux ressources cryptographiques (1/5) JCA : Java Cryptography Architecture introduit avec le JDK 1.1 concentre les accès aux ressources cryptographiques modèle à « fournisseur de services » deux niveaux d API : les classes « moteur » : API présentant sous forme générique des services cryptographiques de base à du code client linterface « SPI » : permet à un fournisseur dimplémentation de service cryptographique de sinsérer dans l infrastructure des CSP : « Cryptographic Service Provider » le JDK 1.1 fournit des services de calcul de condensats de signature / vérification de signature de message le JDK 1.2 en ajoute quelques autres : création et gestion d espace de stockage de clés et de certificats gestion des paramètres liés aux algorithmes Key Factory : conversion de formats de clé

21 Page 21 Accès aux ressources cryptographiques (2/5) Certificate Factory : génération de certificats et de CRL et support de plusieurs encodages fourniture dun service (surchargeable) de génération de nombres aléatoires la JRE 5.2 arrive avec une implémentation minimale (Sun) DSA, MD5, SHA-1, géné. certif. et CRL, KeyStore, géné. aléa. A cela sajoute un package supplémentaire : JCE (Java Cryptographic Extensions) diffusion restreinte échanges de clés chiffrement / déchiffrement calculs de MAC (Message Authentication code) implémentation Sun : DES, 3DES, PBE, DH, HMAC... Remarques : les possibilités de signature et de vérification de signature de classe, y compris pour le code chargé localement, prennent alors toute leur importance

22 Page 22 Accès aux ressources cryptographiques (3/5)

23 Page 23 Accès aux ressources cryptographiques (4/5)

24 Page 24 Accès aux ressources cryptographiques (5/5) Autres nouveautés : classes de manipulation de certificat décodage et gestion de certificats support de X509 V3 mais ouvert à d autres formats et à dautres encodages classes de manipulation de clés et de paires de clés classe engine « KeyStore » + 1 fournisseur par défaut des interfaces de spécification de clé, permettant de manipuler des clés indépendamment de leur représentation

25 Page 25 JAAS (1/3) « Java Authentication and Authorization Service » Extension à la plate-forme Java Part dune remarque : le contrôleur daccès sintéresse à lorigine du code et à qui la signé JAAS s intéresse à qui exécute ou fait exécuter le code JAAS adresse les besoins des applications qui veulent sadapter à leurs utilisateurs en les authentifiant, en contrôlant leurs caractéristiques avant de leur imposer des contrôles daccès Inclut deux composants un composant dauthentification des utilisateurs un composant dautorisation qui travaille à la manière du contrôleur daccès avec en plus des informations utilisateur

26 Page 26 JAAS (2/3) Sinspire des principes et de larchitecture de la technologie PAM (Pluggable Authentication Module) de Sun Prévoit le support de modèles de contrôle daccès orientés utilisateur, groupes dutilisateurs ou privilèges dans les faits, ne supporte que le contrôle daccès basé sur le nom de principal Principe dextensions / remplaçabilité par des plug-ins

27 Page 27 JAAS (3/3) Introduit les notions de : sujet : entité qui peut être authentifiée identité « nom » utilisé pour lauthentification principal : entité authentifiée à un moment donné « credential » : données ou preuves dauthentication domaine de technologie de sécurité : environnement regroupant les composant utilisant un même mécanisme de sécurité (Kerberos, DCE, …)

28 Page 28 Les outils Les nouveaux : keytool : permet de gérer les clés et les certificats permettant de signer des applications et des applets met à jour une base de données appelée keystore jarsigner : signe et vérifie la signature de JAR sappuie sur le keystore policytool : crée et modifie des fichiers de politiques de sécurité

29 Page 29 Exemple de mise en œuvre : Role Based Management

30 Page 30 Conclusion Le JDK 1.2 dispose de tout ce quil faut pour concevoir désormais des applications sécurisées réellement sécurisées Les bons points : JCA le modèle à base de permissions simple et de bon goût Les déceptions : la disponibilité de JCE ou déquivalents bon marché un package JAAS prometteur mais non finalisé manques notoires dans la définition des credentials insuffisances dans l expression des identités, des privilèges et des attributs de sécurité


Télécharger ppt "Le modèle de sécurité de Java 2 SEE - Février 2000 Sécurité logique et Objets."

Présentations similaires


Annonces Google