Diese Präsentation wurde erfolgreich gemeldet.
Die SlideShare-Präsentation wird heruntergeladen. ×

chap 4 Sécurité des accès.pdf

Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Wird geladen in …3
×

Hier ansehen

1 von 47 Anzeige
Anzeige

Weitere Verwandte Inhalte

Aktuellste (20)

Anzeige

chap 4 Sécurité des accès.pdf

  1. 1. 1 S€curit€ des r€seaux Chapitre 4 – S€curit€ des acc‚s
  2. 2. Sommaire S€curit€ des Acc•s • Authentification – Mots de passe – Authentification/Authentification forte • Les protocoles / Utilisation – RADIUS – TACACS / TACACS+ – Kerberos – 802.1x 2
  3. 3. Introduction • La s€curit€ des acc•s fait intervenir un certain nombre de m€canismes – Filtrage des €changes par un Firewall – Filtrage des €changes par un relais applicatif – Authentification des tiers • Algorithmes ‚ clefs publiques • Nous allons d€velopper ce point en pr€sentant d’autres solutions d’authentification • Cette section a €galement pour but de pr€senter les protocoles permettant de g€rer l’authentification et les acc•s au syst•me d’information de l’entreprise – Le concept du „ Single Sign On … – Les protocoles RADIUS, TACACS, Kerberos 3
  4. 4. Authentification – Bases (1) • Identification : Identit€ num€rique  Personne – Chaque personne ayant acc•s au syst•me d’information doit se voir attribuer un IDENTIFIANT UNIQUE • L’authentification = Challenge – L’authentification repose toujours sur un challenge lanc€ par le syst•me de destination ‚ l’intention du client afin que celui-ci prouve sont identit€ • Mot de passe, clef priv€e, empreinte digitale, … • La r€ussite du challenge valide l’association client  Identifiant 4 Qui Ätes vous ? Prouvez le. Dupond = 1 identifiant Mon mot de passe est toto OK, c'est DUPOND
  5. 5. Authentification – Bases (2) • Trois m€thodes d’authentification – La connaissance • Secret connu (ex : mot de passe) – La possession • Possession d’un objet (ex: Carte, badge, clef) – L’entit€ • Caract€ristique physique (ex :biom€trie) • Prise une ‚ une ces techniques ont toutes des points faibles, – C’est la combinaison de plusieurs m€thodes d’authentification qui permet de mettre en place des solutions d’authentification forte 5
  6. 6. Mots de passe • Utilisation de mots de passe – Gestion Indispensable • Cr€ation, Modification, D€blocage, Suppression – Probl•me : stockage, transfert sur le r€seau, rejeu, m€morisation difficile pour les utilisateurs, gestion pour l’administrateur – Des r•gles simples rarement respect€es • 8 caract•res minimum • Non pr€dictible (Pr€nom, nom, identifiant, …) • Renouvellement r€gulier • Jamais €crit – La plupart des intrusions ont pour origine un mot de passe trivial, un compte syst•me ou applicatif ayant conserv€ son mot de passe par d€faut 6
  7. 7. Badges et cartes • Cartes d’identit€ (sans mot de passe) – Code barre, Carte magn€tique, puce – Probl•mes : • Copie, vol, liaison lecteur Serveur, rejeu 7  Cartes d’identit• + mot de passe  Authentification double facteur  Probl‚mes :  Liaison lecteur Serveur, rejeu  En cas copie ou de vol le pirate doit ƒ simplement „ r€soudre un probl‚me de mot de passe
  8. 8. Mot de passe unique • OTP (One Time Password) – Mot de passe utilisable une seule fois • Protection contre le rejeu • Non pr€dictible si l’algorithme est gard€ secret – Pour parer aux probl•mes de vol on adjoint souvent au code g€n€r€ un code personnel (PIN) – Plusieurs techniques • Asynchrone (challenge/r€ponse) – Envoi d’un challenge par le serveur, l’utilisateur poss•de une calculatrice qui transforme le challenge en un mot de passe qu’il saisit. Le serveur fait la mˆme op€ration et compare. • Synchrone d€pendant du temps – Le mot de passe est fonction du temps et est g€n€r€ ‚ intervalle r€gulier. Le challenge (utilis€ dans le mode asynchrone) est en fait la date et l’heure. • Synchrone ind€pendant du temps – Utilisation d’un compteur interne ‚ la calculatrice incr€ment€ ‚ chaque utilisation. Le serveur est synchronis€ sur ce compteur et n’accepte pas de code ant€rieur au compteur 8
  9. 9. Biom€trie • Se base sur les propri€t€s du corps humain et la faible probabilit€ de trouver des caract€ristiques identiques sur deux personnes diff€rentes – S’assure de l’association physique de l’identifiant avec la personne • Fond de l’œil, empreinte digitale, voix – Probl•mes : • Cr€ation des authentifiants (fiabilit€) • Liaison lecteur  Serveur, rejeu • Ne fonctionne pas avec le mat€riel 9
  10. 10. Authentification Unique • SSO (Single Sign On) – Le Single Sign On est une facilit€ permettant ‚ un utilisateur de ne s’authentifier qu’une seule fois pour acc€der ‚ un ensemble de ressources h€t€rog•nes ; on distingue : • Le „ SSO Poste … appliqu€ aux autorisations pour l’acc•s aux serveurs applicatifs du Syst•me d’information • Le „ SSO Serveur … appliqu€ aux applications Web type Intranet, Services Internet, … – Le Single Sign On permet ‚ l’utilisateur de n’avoir qu’un seul mot de passe pour l’acc•s ‚ un ensemble d’applications • Le b€n€fice pour la s€curit€ est la r€duction du nombre de mots de passe ‚ m€moriser par l’utilisateur, €vitant en th€orie les mots de passe trop simples ou €crits sur un papier – Pour l’administrateur, la centralisation de la base des mots de passe garantie une administration simplifi€e et homog•ne de la politique d’authentification 10
  11. 11. Inconv€nients • Le b€n€fice apport€ par le SSO en terme de s€curit€ est grandement att€nu€ par le fait qu’il permet de contourner d’une certaine mani•re le processus d’authentification en l’automatisant – Comment garantir que c’est bien l’utilisateur qui se trouve devant son poste si celui-ci n’a plus ‚ intervenir pour s’authentifier ? – Le SSO implique la mise en place de m€canismes garantissant la pr€sence PHYSIQUE de l’utilisateur devant son poste • Carte ‚ puce dans un lecteur par exemple – L’utilisateur devant enlever la carte ‚ puce du lecteur ‚ chaque fois qu’il s’absente ; l’obligeant ‚ r€p€ter le processus d’authentification ‚ son retour… • Le SSO est souvent pr€sent€ par les constructeurs comme un moyen de pr€parer l’arriv€e des PKI (car pr€parant l’infrastructure ‚ l’int€gration des PKI) mais pour beaucoup le SSO semble ˆtre une fonctionnalit€ des PKI ‚ ne pas exploiter – Cf. „ CDROM/Infrastructure ‚ clefs publiques/Ten Risks of PKI.doc … • Par Carl Ellison et Bruce Schneier deux experts en cryptographie et s€curit€ 11
  12. 12. SSO Serveur • 3 alternatives d’architecture – SSO Reverse Proxy: L’acc•s aux applications et l’authentification primaire sont r€alis€s par un serveur de s€curit€ install€ en mode reverse proxy, – SSO proxy web: L’acc•s aux applications et l’authentification primaire sont r€alis€s par un serveur de s€curit€ install€ en mode proxy web ou associ€ ‚ un portail d’entreprise, – SSO bas€e sur des agents filtres: Un agent install€ sur chaque serveur est intercal€ entre le poste client et le serveur de s€curit€ dont il est le client. • Les 3 architectures peuvent ˆtre associ€es pour r€pondre aux contraintes impos€es par l’environnement technique et applicatif. 12
  13. 13. SSO Serveur (2) • Architecture SSO Reverse Proxy 13 PROCESSUS ETAPE 1: Le client demande au DNS l’@ IP du serveur intranet , le DNS lui communique l’@ IP du Reverse Proxy SSO. ETAPE 2: Le client r•alise une authentification primaire aupr‚s du reverse proxy SSO et demande la connexion au serveur intranet, le reverse proxy SSO interroge l’annuaire pour valider les droits de client et r•cup•rer le couple L/P correspondant ƒ l’Intranet,  ETAPE 3: Le reverse proxy SSO •tablit une connexion avec le serveur intranet en pr•sentant le coupe L/P du client.
  14. 14. SSO Serveur (3) • Architecture SSO Proxy Web 14 PROCESSUS ETAPE 1: Le client web se connecte au serveur proxy web SSO. ETAPE 2: Le client r•alise une authentification primaire aupr‚s du proxy web SSO et demande la connexion au serveur intranet, le proxy web SS0 interroge l’annuaire pour valider les droits de client et r•cup•rer le couple L/P correspondant ƒ l’Intranet,  ETAPE 3: Le proxy web SSO •tablit une connexion avec le serveur intranet en pr•sentant le coupe L/P du client. ANNUAIRE Client web avec config url « Proxy.ccinca.fr » Proxy.ccinca.fr Application RH Portail INTRANET @ X ETAPE 2 ETAPE 3 ETAPE 1
  15. 15. SSO Serveur (4) • Architecture SSO Agents 15 PROCESSUS ETAPE 1: Le client web se connecte au serveur portail sur lequel est install• l’agent SSO et fournit son couple L/P. ETAPE 2: L’agent interroge le serveur SSO pour valider le couple L/P. Ce dernier interroge l’annuaire et retourne la r•ponse.  ETAPE 3: Le client ƒ cliqu• sur l’ic„ne intranet dans le portail. L’agent transmet au serveur SSO l’identit• du client et du serveur cible (intranet). Le serveur SSO interroge l’annuaire et envoi ƒ l’agent du serveur intranet le couple L/P secondaire. Ce dernier joue l’authentification.
  16. 16. Radius • RADIUS (Remote Dial-In User Service) – Radius est un protocole qui permet ‚ un serveur d’acc•s (au sens large du terme) de communiquer avec un serveur central pour authentifier les utilisateurs et autoriser les acc•s – Mod•le Client-Serveur, standard de l’IETF RFC 2138 – Toutes les transactions RADIUS sont authentifi€es par l'utilisation d'un secret qui n'est jamais transmis sur le r€seau. De plus les communications sont en partie chiffr€es en utilisant une clef secr•te d€finie sur le serveur et le client – Le client RADIUS est souvent int€gr€ dans les serveurs d’acc•s (NAS) €mettant les requˆtes pour authentifier les utilisateurs qui tentent d’acc€der au r€seau – La modularit€ du protocole permet son utilisation pour une grande vari€t€ d’applications et notamment les proxys applicatifs 16
  17. 17. Principe 17 1.L’utilisateur initie une connexion PPP avec le serveur d’accƒs 2.Le serveur d’accƒs demande l’identifiant et le mot de passe (PAP) ou envoi un challenge (CHAP – MD5) 3.L’utilisateur r„pond 4.Le client RADIUS (le NAS) envoi l’identifiant et le mot de passe au serveur RADIUS (authentification) en le chiffrant avec la clef qu’il partage avec le serveur 5.Le serveur RADIUS r„pond avec les messages Accept, Reject, or Challenge. 6.Le client RADIUS se configure en fonction du contenu des messages Accept ou Reject (autorisation)
  18. 18. Principe 18 1.L’utilisateur initie une connexion PPP avec le serveur d’accƒs 2.Le serveur d’accƒs demande l’identifiant et le mot de passe (PAP) ou envoi un challenge (CHAP – MD5) 3.L’utilisateur r„pond 4.Le client RADIUS (le NAS) envoi l’identifiant et le mot de passe au serveur RADIUS (authentification) en le chiffrant avec la clef qu’il partage avec le serveur 5.Le serveur RADIUS r„pond avec les messages Accept, Reject, or Challenge. 6.Le client RADIUS se configure en fonction du contenu des messages Accept ou Reject (autorisation)
  19. 19. Pourquoi utiliser RADIUS • AAA (Authorization Authentication Accounting) – Radius fournit en plus de l’Authentification, un moyen de g€rer les autorisations d’acc•s et la journalisation des €changes • Protocole robuste et tr•s r€pandu – NAS, VPN, Authentification domaine, Proxy, … • Modularit€ permettant une adaptation ‚ la plupart des contextes – Attributs configurables 19
  20. 20. Exemple d’utilisation RADIUS • Acc•s nomades 20 Commutateur Serveur Radius Authentification avec cl• partag•e ( preshared key ) Op•rateur Tiers R•seau priv• Dial El‚ve Serveur Radius Op•rateur NAS Op•rateur Authentification avec cl• partag•e Radius Op•rateur ( preshared key )
  21. 21. Exemple d’utilisation RADIUS (2) • R€seaux Wifi 21 Commutateur Serveur W2000 Borne Wifi Portable WEP RADIUS Authentification EAP W2000 AD Serveur Radius Authentification domaine AD DHCP Relais DHCP Adresse IP Options DHCP Authentification PEAP Enrƒlement domaine ( filaire )
  22. 22. TACACS • TACACS (Terminal Access Controller Access Control System) – TACACS est un ancien protocole du monde Unix qui permet ‚ un serveur d’acc•s de faire suivre vers un serveur d’authentification les authentifiants (login/mot de passe) d’un utilisateur afin de d€terminer quelles autorisations peuvent lui ˆtre attribu€es • Date du temps de ARPANET… – TACACS est un protocole plus ancien et beaucoup moins sŠr que RADIUS et TACACS+ – TACACS ainsi qu’une version plus r€cente XTACACS (eXtended TACACS – Cisco 1990) sont deux protocoles normalis€s par l’IETF RFC 1492 – Cisco a d€clar€ en 1997 la fin du support de ces protocoles ceux-ci ayant €t€ remplac€s • TACACS et XTACACS ne sont plus utilis€s de nous jours 22
  23. 23. TACACS+ • En d€pit de son nom TACACS+ n’est pas une €volution de TACACS mais un nouveau protocole • TACACS+ est, au mˆme titre que RADIUS un protocole qui permet ‚ un serveur d’acc•s de communiquer avec un serveur central pour authentifier les utilisateurs et autoriser les acc•s – L’impl€mentation diff•re cependant de celle de son „ concurrent … RADIUS sur certains points • AAA (Authorization Authentication Accounting) – TACACS+ fournit en plus de l’Authentification, un moyen de g€rer les autorisations d’acc•s et la journalisation des €changes • TACACS+ a fait l’objet d’un Draft de la part de Cisco mais n’a pas €t€ normalis€ et reste propri€taire 23
  24. 24. Pourquoi utiliser TACACS+ • En environnement Cisco celui-ci semble plus sŠr que RADIUS – Chiffrement de la totalit€ du message – Utilisation de TCP • TACACS+ soufre cependant de quelques vuln€rabilit€s (au mˆme titre que RADIUS) – Rejeu, la taille du mot de passe peut ˆtre d€termin€e en fonction de la taille du paquet, ... – Celles-ci ont normalement €t€ corrig€es, mais combien d’anciennes version de l’IOS continuent encore ‚ ˆtre utilis€es ? • TACACS+ reste tr•s populaire sur les r€seaux Cisco 24
  25. 25. RADIUS/TACACS+ • Radius – Utilise UDP – Publique, normalis€, forte interop€rabilit€ et modularit€ – Plus l€ger que TACACS+ (dans son concept) – Regroupe dans un seul profil utilisateur authentification et autorisation • TACACS+ – Utilise TCP – Chiffre la totalit€ des messages – Propri€taire Cisco • On trouve cependant quelques impl€mentations sur d’autres produits – Supporte plus de protocoles que RADIUS • AppleTalk Remote Access, Net BIOS Frame, … – Dissocie les profils d’authentification et d’autorisation 25
  26. 26. Kerberos • Kerberos a €t€ con‹u au MIT (Massachusetts Institute of Technology) dans les ann€es 1980. Aujourd’hui Kerberos V tend ‚ se r€pandre. • Kerberos est un protocole d’authentification r€seau – Fournit l’authentification mutuelle grŒce ‚ des clefs partag€es et du chiffrement (DES ou 3DES) ou un tiers de confiance – Utilise un m€canisme ‚ base de Tickets – Principe : tous les mots de passe et les droits d’acc•s sont stock€s sur un serveur s€curis€ • Les constituants d’une infrastructure utilisant Kerberos sont : – Les clients Kerberos – Les serveurs d’acc•s supportant Kerberos (routeur, passerelle ou serveur d’acc•s) – Les serveurs compatibles Kerberos – Le serveur de g€n€ration de Tickets (Key Distribution Center) 26
  27. 27. Kerberos
  28. 28. Pourquoi utiliser Kerberos • Authentification mutuelle s€curis€e – Chiffrement des €changes – Pas de transmission de mot de passe • Transmission de clefs de session chiffr€es – Gestion centralis€e de l’authentification • Administration centralis€e et audit facilit€ – Kerberos permet le Single Sign On… • Facilite la vie de l’utilisateur – Possibilit€ de Kerberisation de toutes les applications => Utilisation d’API Kerberos – Facilite la convergence vers la PKI • Dans la mesure ou une partie du travail aura d€j‚ €t€ fait 28
  29. 29. Terminologie (1) • Client – Entit€ pouvant obtenir un ticket (user/host) • Service – Machine ou application (ftp, pop, ssh, …) • Ticket – Cr€dit (identit€ d’un client pour un service) • TGT (Ticket Granting Ticket) – Sorte de super-ticket obtenu ‚ la premi•re authentification, qui permet ensuite l’obtention de tickets pour les services acc€d€s • REALM (royaume) – Domaine d’authentification • 1 base de donn€e Kerberos + 1 ou plusieurs KDC – Organisation hi€rarchique entre les domaines avec authentification • „ Principal … – Triplet (nom, instance, domaine) • ex: user/group@REALM ou service/host.domain@REALM 29
  30. 30. Terminologie (2) • KeyTab – Fichier du client contenant une ou plusieurs clefs • KDC (Key Distribution Center) – Contient la base des clients et des serveurs ainsi que les clefs • G•re les clefs pour les „ principales … et tickets – AS (Authentication Server/Service) • Fournit au client une clef de session et un TGT – TGS (Ticket Granting Server/Service) • Service d€livrant les tickets ‚ partir du TGT obtenu aupr•s de l’AS 30
  31. 31. Anatomie d’un Ticket 31 Domain Principal Name Ticket Flags Encryption Key Domain Principal Name Start Time End Time Host Address Authorization Data Chiffr• avec le mot de passe de l’utilisateur 32 bits indiquant les propri„t„s du ticket Champ utilis„, dans Microsoft 2000 par exemple, pour ajouter les autorisations concernent l’utilisateur (propri„taire) Adresse du client Clef de session
  32. 32. Architecture 32
  33. 33. Kerberos - Probl•mes • NAT – Le ticket contient l’adresse du client • Le support de ticket pouvant ˆtre utilis€ au travers du NAT a €t€ ajout€ ‚ Kerberos V (par d€sactivation de la v€rification de l’adresse) • Pour les versions pr€c€dentes il convient de d€sactiver la v€rification de l’adresse source manuellement – Facilite le rejeu • Probl•mes de s€curit€ – Rejeu • Il convient de synchroniser correctement les horloges – Les passphrases trop simples • Peut permettre un „ brute force … du mot de passe et donc une usurpation d’identit€ • Rejoint les probl•mes classiques de mots de passe – Postes utilis€s par plusieurs personnes • Rejoint les probl•mes du Single Sign On 33
  34. 34. 802.1x • Nouvelle norme 802.1x – Fonctionnement – Utilisation – Faiblesse(s) – •volutions 34
  35. 35. 802.1x – Historique et environnement • Quelques rep•res historiques dans la standardisation – 1994-2003 : PPP (quelques dizaines de RFC!) – 1997-2000 : RADIUS (RFC2058 remplac€ par 2138, puis 2865) – 1998 : EAP (RFC2284) – 2001 : 802.1X • Environnement d’origine et €volution – Connexion via un support physique (RTC, puis tous r€seaux) – Prolonge jusqu’au niveau 2 le d€couplage entre l’€tablissement de la connectivit€ et l’authentification – •volution ensuite vers les r€seaux 802.11….. 35
  36. 36. 802.1x – Objectifs • Standardiser un m€canisme de relais d’authentification au niveau 2 – Pour les acc•s via des interfaces IEEE 802{.3 .5 .11} – Intervient avant d’€ventuels protocoles comme DHCP • Pour permettre un contrŽle d’acc•s aux ressources – Mˆme si l’acc•s physique au r€seau n’est pas contrŽlable • Exemples d’utilisation : – Acc•s Internet depuis une aire publique – Affectation ‚ un VLAN donn€ en fonction de l’authentification 36
  37. 37. 802.1x – Fonctionnement • D€finitions – Authentificateur : Entit€ qui sur le port du r€seau local facilite l’authentification d’une autre entit€ attach€e sur le mˆme port. – Serveur d’authentification : Entit€ qui procure un service d’authentification ‚ un authentificateur. Ce service d€termine, ‚ partir des €l€ments de la requˆte du demandeur, les services qui lui sont accessibles. Ce serveur peut ˆtre sur la machine qui sert d’authentificateur ou accessible ‚ ce dernier via le r€seau. – Authentifi€ : Entit€ qui sur le port du r€seau local qui est en train d’ˆtre authentifi€ par l’authentificateur (€quivalent de peer dans EAP). – Point d’acc•s r€seau : point d’acc•s physique (ex. prise RJ45 pour 802.3) ou logique (association pour 802.11) au r€seau local (on emploie aussi le terme anglais de port, ou interface). – PAE (Port Access Entity) : Ensemble impl€mentant le protocole 802.1X, un mˆme PAE peut jouer le rŽle d’authentificateur ou d’authentifi€. – Syst•me : €quipement qui est connect€ au LAN par un ou plusieurs ports (ex: poste de travail, serveur, hub, commutateur, routeur…). 37 Syst‚me d’authentification Point d’acc‚s au r•seau Syst‚me „ authentifi• Serveur authentification Authentification 802.1X
  38. 38. 802.1x - Utilisation • 802.1X utilise le protocole EAP (Extensible Authentication Protocol), – Protocole d€di€ au transport de cr€dits d’authentification – Plusieurs m€thodes d’authentification • EAP-TLS : Authentification mutuelle du serveur et de l’utilisateur avec des certificats €lectroniques • EAP-TTLS: Seul le serveur doit disposer d’un certificat, l’utilisateur est authentifi€ par login/mot de passe • EAP-PEAP: Equivalent ‚ EAP-TTLS mais propri€taire Microsoft. Cette m€thode est disponible par d€faut dans les syst•mes Windows r€cents (XP, 2000, 2003) 38
  39. 39. 802.1x - Faiblesses • Sont essentiellement dues ‚ la conception du protocole dans un contexte de connexion physique • La norme 802.1x est vuln€rable ‚ deux types d’attaques (au moins) – Attaque par interception • Le pirate envoi un message de fin de connexion au client en se faisant passer pour le point d’acc•s • Le pirate usurpe l’identit€ du client vis ‚ vis du point d’acc•s – Attaque par interposition • Le pirate se fait passer pour le point d’acc•s vis-‚-vis du client et relaye les flux vers le point d’acc•s ‚ la mani•re d’un proxy 39
  40. 40. WPA • Wi-Fi Protected Access – Con‹u par la WiFi Alliance pour remplacer le protocole Wired Equivalent Privacy • Combler une ‚ une les failles du WEP • Rester compatible avec le mat€riel existant – il faut encore utiliser le moteur WEP – Ensemble de packages logiciels se superposant au mat€riel: • Authentification bas€e sur 802.1X et RADIUS • Renouvellement des cl€s de chiffrement plus robuste dans le temps (TKIP - Temporal Key Integrity Protocol) • Meilleur m€canisme de contrŽle d’int€grit€ (MIC) 40
  41. 41. 802.11i • Les principes – IEEE 802.11i est obligatoire dans IEEE 802.11g et IEEE 802.11e – Reprend les mˆmes m€canismes que WPA – La gestion de la cl€ est la mˆme que WPA – Le moteur WEP est remplac€ par un moteur AES (Advanced Encryption Standard) d’o• le changement de mat€riel n€cessaire 41
  42. 42. Lightweight Directory Access Protocol • Historique – 1988: La norme X500 (ISO) • D€finit de mani•re tr•s compl•te le moteur, les modules d’interrogation, les r•gles de nommage et les protocoles d’acc•s (D.A.P), – 1993: Lightweight Directory Access Protocol V1 • Fournit une interface d’acc•s simplifi€e aux annuaires X500, fonctionne sur TCPIP. – 1995: LDAP V2 (IETF RFC 1777). • „ Proposed standard …: Annuaire natif, g•re sa propre base de donn€e. – 1997: LDAP V3 (IETF RFC 2251 + 3377 de 09/02). • Enrichit de m€canismes de chiffrement, partitionnement, r€plication, etc. 42
  43. 43. Lightweight Directory Access Protocol (2) • Le protocole LDAP – Le protocole permettant d'acc€der ‚ l'information contenue dans l'annuaire, – Un mod•le d'information d€finissant le type de donn€es contenues dans l'annuaire, – Un mod•le de nommage d€finissant comment l'information est organis€e et r€f€renc€e, – Un mod•le fonctionnel qui d€finit comment on acc•de ‚ l'information , – Un mod•le de s€curit€ qui d€finit comment donn€es et acc•s sont prot€g€s, – Un mod•le de duplication qui d€finit comment la base est r€partie entre serveurs, – Des APIs pour d€velopper des applications clientes, LDIF, un format d'€change de donn€es. 43
  44. 44. Lightweight Directory Access Protocol (3) • Architecture hi€rarchique mais distribu€e : – Le service d’annuaire ne repose g€n€ralement pas sur un seul serveur mais s’€tend sur une architecture technique distribu€e apportant fiabilit€, disponibilit€ et performance, – Notion de partitionnement: Il est possible de r€partir les donn€es sur plusieurs serveurs pour des raisons de capacit€ (taille), gestion, organisation, – Les diff€rentes partitions sont n€anmoins li€es par des m€canismes de referral ou de duplication (r€plication), un peu ‚ l’image de l’annuaire D.N.S (Domain Name Service) utilis€ pour r€soudre les noms de domaines en adresses IP 44
  45. 45. Lightweight Directory Access Protocol (4) • M€ta annuaire : – R€cup€rer automatiquement les "informations d'entreprise" en constituant un lien entre plusieurs annuaires ou bases disposant de sch€mas et d’espaces de nommage diff€rents, – Agr€ger et f€d€rer ces informations dans la base d'annuaire LDAP. Il s’agit dans ce cas du mode „ aggr€gateur de contenu …, – Synchroniser ces informations d'une application ‚ l'autre : envoi de l'adresse e-mail issue de la messagerie dans l'application RH, envoi du profil issu de l'application RH dans le serveur de r€sultats, etc. Pour ce faire, il va cr€er des associations entre les diff€rentes sources de donn€es et r€aliser entre elles des synchronisations automatiques bidirectionnelles (mapping et translations entre les entr€es et leurs attributs). Il s’agit dans ce cas du mode „ courtier d’information …. 45
  46. 46. Lightweight Directory Access Protocol (5) • Annuaire et Single Sign On : – L’annuaire constitue le socle n€cessaire au contrŽle des identit€s • Il centralise et d€livre de mani•re transparente les €l€ments d'authentification, la liste des services et les droits associ€s ‚ chaque utilisateur, que la personne authentifi€e soit un employ€ ou un partenaire – Plate-forme d'authentification (agent ou serveur SSO) permet ‚ l'utilisateur de s'authentifier une seule fois avant d'acc€der ‚ l'ensemble des services (syst•mes, applications) auxquels il a droit. • Elle prend en charge la gestion et l'historique des connexions aux services autoris€s sur la base des informations de s€curit€ fournies par l'annuaire. 46
  47. 47. Lightweight Directory Access Protocol (6) • Annuaire et PKI: – L’annuaire est une des briques du socle technique n€cessaire ‚ la mise en oeuvre d’une architecture ‚ cl€ publique (P.K.I). • Stocker les certificats valides en permettant ‚ tout utilisateur de trouver le certificat d’un autre par son nom ou adresse e-mail et de v€rifier sa validit€, • Stocker les certificats r€voqu€s pour permettre ‚ toute application d’effectuer les v€rifications avant de lancer des traitements sensibles, • S€curiser les acc•s en modification de l’annuaire en assurant des fonctions d’authentification utilisant les certificats X 509. 47

×