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

Novembre – Décembre 2005 Version 1.01 1 État de lart de la sécurité informatique Chapitre 3 – Sécurité des accès Auteurs : Stéphan GUIDARINI – Consultant.

Présentations similaires


Présentation au sujet: "Novembre – Décembre 2005 Version 1.01 1 État de lart de la sécurité informatique Chapitre 3 – Sécurité des accès Auteurs : Stéphan GUIDARINI – Consultant."— Transcription de la présentation:

1

2 Novembre – Décembre 2005 Version État de lart de la sécurité informatique Chapitre 3 – Sécurité des accès Auteurs : Stéphan GUIDARINI – Consultant Senior Sébastien DESSE – Expert Réseaux et Sécurité

3 Novembre – Décembre 2005 Version Sommaire Sécurité des Accès Authentification Mots de passe Authentification/Authentification forte Les protocoles / Utilisation RADIUS TACACS / TACACS+ Kerberos 802.1x

4 Novembre – Décembre 2005 Version Introduction La sécurité des accès fait intervenir un certain nombre de mécanismes que nous avons décrits dans les sections précédentes 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 dautres solutions dauthentification Cette section a également pour but de présenter les protocoles permettant de gérer lauthentification et les accès au système dinformation de lentreprise Le concept du « Single Sign On » Les protocoles RADIUS, TACACS, Kerberos

5 Novembre – Décembre 2005 Version Authentification – Bases (1) Identification : Identité numérique Personne Chaque personne ayant accès au système dinformation doit se voir attribuer un IDENTIFIANT UNIQUE Lauthentification = Challenge Lauthentification repose toujours sur un challenge lancé par le système de destination à lintention du client afin que celui-ci prouve sont identité Mot de passe, clef privée, empreinte digitale, … La réussite du challenge valide lassociation client Identifiant Qui êtes vous ? Prouvez le. Dupond = 1 identifiant Mon mot de passe est toto OK, c'est DUPOND

6 Novembre – Décembre 2005 Version Authentification – Bases (2) Trois méthodes dauthentification La connaissance Secret connu (ex : mot de passe) La possession Possession dun objet (ex: Carte, badge, clef) Lentité Caractéristique physique (ex :biométrie) Prise une à une ces techniques ont toutes des points faibles, Cest la combinaison de plusieurs méthodes dauthentification qui permet de mettre en place des solutions dauthentification forte

7 Novembre – Décembre 2005 Version 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 ladministrateur 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

8 Novembre – Décembre 2005 Version Badges et cartes Cartes didentité (sans mot de passe) Code barre, Carte magnétique, puce Problèmes : Copie, vol, liaison lecteur Serveur, rejeu Cartes didentité + 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

9 Novembre – Décembre 2005 Version Mot de passe unique OTP (One Time Password) Mot de passe utilisable une seule fois Protection contre le rejeu Non prédictible si lalgorithme 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 dun challenge par le serveur, lutilisateur possède une calculatrice qui transforme le challenge en un mot de passe quil 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 lheure. Synchrone indépendant du temps Utilisation dun compteur interne à la calculatrice incrémenté à chaque utilisation. Le serveur est synchronisé sur ce compteur et naccepte pas de code antérieur au compteur

10 Novembre – Décembre 2005 Version 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 Sassure de lassociation physique de lidentifiant 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

11 Novembre – Décembre 2005 Version Authentification Unique SSO (Single Sign On) Le Single Sign On est une facilité permettant à un utilisateur de ne sauthentifier quune seule fois pour accéder à un ensemble de ressources hétérogènes ; on distingue : Le « SSO Poste » appliqué aux autorisations pour laccès aux serveurs applicatifs du Système dinformation Le « SSO Serveur » appliqué aux applications Web type Intranet, Services Internet, … Le Single Sign On permet à lutilisateur de navoir quun seul mot de passe pour laccès à un ensemble dapplications Le bénéfice pour la sécurité est la réduction du nombre de mots de passe à mémoriser par lutilisateur, évitant en théorie les mots de passe trop simples ou écrits sur un papier Pour ladministrateur, la centralisation de la base des mots de passe garantie une administration simplifiée et homogène de la politique dauthentification

12 Novembre – Décembre 2005 Version Inconvénients Le bénéfice apporté par le SSO en terme de sécurité est grandement atténué par le fait quil permet de contourner dune certaine manière le processus dauthentification en lautomatisant Comment garantir que cest bien lutilisateur qui se trouve devant son poste si celui-ci na plus à intervenir pour sauthentifier ? Le SSO implique la mise en place de mécanismes garantissant la présence PHYSIQUE de lutilisateur devant son poste Carte à puce dans un lecteur par exemple Lutilisateur devant enlever la carte à puce du lecteur à chaque fois quil sabsente ; lobligeant à répéter le processus dauthentification à son retour… Le SSO est souvent présenté par les constructeurs comme un moyen de préparer larrivée des PKI (car préparant linfrastructure à linté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é

13 Novembre – Décembre 2005 Version SSO Serveur 3 alternatives darchitecture SSO Reverse Proxy: Laccès aux applications et lauthentification primaire sont réalisés par un serveur de sécurité installé en mode reverse proxy, SSO proxy web: Laccès aux applications et lauthentification primaire sont réalisés par un serveur de sécurité installé en mode proxy web ou associé à un portail dentreprise, 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 lenvironnement technique et applicatif.

14 Novembre – Décembre 2005 Version SSO Serveur (2) Architecture SSO Reverse Proxy PROCESSUS ETAPE 1: Le client demande au DNS IP du serveur intranet, le DNS lui communique 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 lannuaire pour valider les droits de client et récupérer le couple L/P correspondant à lIntranet, ETAPE 3: Le reverse proxy SSO établit une connexion avec le serveur intranet en présentant le coupe L/P du client.

15 Novembre – Décembre 2005 Version SSO Serveur (3) Architecture SSO Proxy Web 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 lannuaire pour valider les droits de client et récupérer le couple L/P correspondant à lIntranet, ETAPE 3: Le proxy web SSO établit une connexion avec le serveur intranet en présentant le coupe L/P du client.

16 Novembre – Décembre 2005 Version SSO Serveur (4) Architecture SSO Agents PROCESSUS ETAPE 1: Le client web se connecte au serveur portail sur lequel est installé lagent SSO et fournit son couple L/P. ETAPE 2: Lagent interroge le serveur SSO pour valider le couple L/P. Ce dernier interroge lannuaire et retourne la réponse. ETAPE 3: Le client à cliqué sur licône intranet dans le portail. Lagent transmet au serveur SSO lidentité du client et du serveur cible (intranet). Le serveur SSO interroge lannuaire et envoi à lagent du serveur intranet le couple L/P secondaire. Ce dernier joue lauthentification.

17 Novembre – Décembre 2005 Version Radius RADIUS (Remote Dial-In User Service) Radius est un protocole qui permet à un serveur daccè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 lIETF 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 daccès (NAS) émettant les requêtes pour authentifier les utilisateurs qui tentent daccéder au réseau La modularité du protocole permet son utilisation pour une grande variété dapplications et notamment les proxys applicatifs

18 Novembre – Décembre 2005 Version Principe 1.Lutilisateur initie une connexion PPP avec le serveur daccès 2.Le serveur daccès demande lidentifiant et le mot de passe (PAP) ou envoi un challenge (CHAP – MD5) 3.Lutilisateur répond 4.Le client RADIUS (le NAS) envoi lidentifiant et le mot de passe au serveur RADIUS (authentification) en le chiffrant avec la clef quil 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 Novembre – Décembre 2005 Version Principe 1.Lutilisateur initie une connexion PPP avec le serveur daccès 2.Le serveur daccès demande lidentifiant et le mot de passe (PAP) ou envoi un challenge (CHAP – MD5) 3.Lutilisateur répond 4.Le client RADIUS (le NAS) envoi lidentifiant et le mot de passe au serveur RADIUS (authentification) en le chiffrant avec la clef quil 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)

20 Novembre – Décembre 2005 Version Pourquoi utiliser RADIUS AAA (Authorization Authentication Accounting) Radius fournit en plus de lAuthentification, un moyen de gérer les autorisations daccè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

21 Novembre – Décembre 2005 Version Exemple dutilisation RADIUS Accès nomades 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 )

22 Novembre – Décembre 2005 Version Exemple dutilisation RADIUS (2) Réseaux Wifi Commutateur Serveur W2000 Borne WifiPortable WEP RADIUS Authentification EAP W2000 AD Serveur Radius Authentification domaine AD DHCP Relais DHCP Adresse IP Options DHCP Authentification PEAP Enrôlement domaine ( filaire )

23 Novembre – Décembre 2005 Version TACACS TACACS (Terminal Access Controller Access Control System) TACACS est un ancien protocole du monde Unix qui permet à un serveur daccès de faire suivre vers un serveur dauthentification les authentifiants (login/mot de passe) dun 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 quune version plus récente XTACACS (eXtended TACACS – Cisco 1990) sont deux protocoles normalisés par lIETF 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

24 Novembre – Décembre 2005 Version TACACS+ En dépit de son nom TACACS+ nest pas une évolution de TACACS mais un nouveau protocole TACACS+ est, au même titre que RADIUS un protocole qui permet à un serveur daccès de communiquer avec un serveur central pour authentifier les utilisateurs et autoriser les accès Limplémentation diffère cependant de celle de son « concurrent » RADIUS sur certains points AAA (Authorization Authentication Accounting) TACACS+ fournit en plus de lAuthentification, un moyen de gérer les autorisations daccès et la journalisation des échanges TACACS+ a fait lobjet dun Draft de la part de Cisco mais na pas été normalisé et reste propriétaire

25 Novembre – Décembre 2005 Version 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 danciennes version de lIOS continuent encore à être utilisées ? TACACS+ reste très populaire sur les réseaux Cisco

26 Novembre – Décembre 2005 Version 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 dautres produits Supporte plus de protocoles que RADIUS AppleTalk Remote Access, Net BIOS Frame, … Dissocie les profils dauthentification et dautorisation

27 Novembre – Décembre 2005 Version Kerberos Kerberos a été conçu au MIT (Massachusetts Institute of Technology) dans les années Aujourdhui Kerberos V tend à se répandre. Kerberos est un protocole dauthentification réseau Fournit lauthentification 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 daccès sont stockés sur un serveur sécurisé Les constituants dune infrastructure utilisant Kerberos sont : Les clients Kerberos Les serveurs daccès supportant Kerberos (routeur, passerelle ou serveur daccès) Les serveurs compatibles Kerberos Le serveur de génération de Tickets (Key Distribution Center)

28 Novembre – Décembre 2005 Version 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 lauthentification Administration centralisée et audit facilité Kerberos permet le Single Sign On… Facilite la vie de lutilisateur Possibilité de Kerberisation de toutes les applications => Utilisation dAPI Kerberos Facilite la convergence vers la PKI Dans la mesure ou une partie du travail aura déjà été fait

29 Novembre – Décembre 2005 Version Terminologie (1) Client Entité pouvant obtenir un ticket (user/host) Service Machine ou application (ftp, pop, ssh, …) Ticket Crédit (identité dun client pour un service) TGT (Ticket Granting Ticket) Sorte de super-ticket obtenu à la première authentification, qui permet ensuite lobtention de tickets pour les services accédés REALM (royaume) Domaine dauthentification 1 base de donnée Kerberos + 1 ou plusieurs KDC Organisation hiérarchique entre les domaines avec authentification « Principal » Triplet (nom, instance, domaine) ex: ou

30 Novembre – Décembre 2005 Version 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 lAS

31 Novembre – Décembre 2005 Version Anatomie dun Ticket 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 lutilisateur 32 bits indiquant les propriétés du ticket Champ utilisé, dans Microsoft 2000 par exemple, pour ajouter les autorisations concernent lutilisateur (propriétaire) Adresse du client Clef de session

32 Novembre – Décembre 2005 Version Architecture

33 Novembre – Décembre 2005 Version Kerberos - Problèmes NAT Le ticket contient ladresse 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 ladresse) Pour les versions précédentes il convient de désactiver la vérification de ladresse 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 didentité Rejoint les problèmes classiques de mots de passe Postes utilisés par plusieurs personnes Rejoint les problèmes du Single Sign On

34 Novembre – Décembre 2005 Version x Nouvelle norme 802.1x Fonctionnement Utilisation Faiblesse(s) Évolutions

35 Novembre – Décembre 2005 Version x – Historique et environnement Quelques repères historiques dans la standardisation : PPP (quelques dizaines de RFC!) : RADIUS (RFC2058 remplacé par 2138, puis 2865) 1998 : EAP (RFC2284) 2001 : 802.1X Environnement dorigine et évolution Connexion via un support physique (RTC, puis tous réseaux) Prolonge jusquau niveau 2 le découplage entre létablissement de la connectivité et lauthentification Évolution ensuite vers les réseaux …..

36 Novembre – Décembre 2005 Version x – Objectifs Standardiser un mécanisme de relais dauthentification au niveau 2 Pour les accès via des interfaces IEEE 802{ } Intervient avant déventuels protocoles comme DHCP Pour permettre un contrôle daccès aux ressources Même si laccès physique au réseau nest pas contrôlable Exemples dutilisation : Accès Internet depuis une aire publique Affectation à un VLAN donné en fonction de lauthentification

37 Novembre – Décembre 2005 Version x – Fonctionnement Définitions Authentificateur : Entité qui sur le port du réseau local facilite lauthentification dune autre entité attachée sur le même port. Serveur dauthentification : Entité qui procure un service dauthentification à 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 dauthentificateur 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 lauthentificateur (équivalent de peer dans EAP). Point daccès réseau : point daccès physique (ex. prise RJ45 pour 802.3) ou logique (association pour ) 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 dauthentificateur ou dauthentifié. Système : équipement qui est connecté au LAN par un ou plusieurs ports (ex: poste de travail, serveur, hub, commutateur, routeur…). Système dauthentification Point daccès au réseau Système à authentifié Serveur authentification Authentification 802.1X

38 Novembre – Décembre 2005 Version x - Utilisation 802.1X utilise le protocole EAP (Extensible Authentication Protocol), Protocole dédié au transport de crédits dauthentification Plusieurs méthodes dauthentification EAP-TLS : Authentification mutuelle du serveur et de lutilisateur avec des certificats électroniques EAP-TTLS: Seul le serveur doit disposer dun certificat, lutilisateur 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)

39 Novembre – Décembre 2005 Version x - Faiblesses Sont essentiellement dues à la conception du protocole dans un contexte de connexion physique La norme 802.1x est vulnérable à deux types dattaques (au moins) Attaque par interception Le pirate envoi un message de fin de connexion au client en se faisant passer pour le point daccès Le pirate usurpe lidentité du client vis à vis du point daccès Attaque par interposition Le pirate se fait passer pour le point daccès vis-à-vis du client et relaye les flux vers le point daccès à la manière dun proxy

40 Novembre – Décembre 2005 Version 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 dintégrité (MIC)

41 Novembre – Décembre 2005 Version i Les principes IEEE i est obligatoire dans IEEE g et IEEE e 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) doù le changement de matériel nécessaire

42 Novembre – Décembre 2005 Version Lightweight Directory Access Protocol Historique 1988: La norme X500 (ISO) Définit de manière très complète le moteur, les modules dinterrogation, les règles de nommage et les protocoles daccès (D.A.P), 1993: Lightweight Directory Access Protocol V1 Fournit une interface daccè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 de 09/02). Enrichit de mécanismes de chiffrement, partitionnement, réplication, etc.

43 Novembre – Décembre 2005 Version 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.

44 Novembre – Décembre 2005 Version Lightweight Directory Access Protocol (3) Architecture hiérarchique mais distribuée : Le service dannuaire 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 à limage de lannuaire D.N.S (Domain Name Service) utilisé pour résoudre les noms de domaines en adresses IP

45 Novembre – Décembre 2005 Version 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 despaces de nommage différents, Agréger et fédérer ces informations dans la base d'annuaire LDAP. Il sagit dans ce cas du mode « aggrégateur de contenu », Synchroniser ces informations d'une application à l'autre : envoi de l'adresse 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 sagit dans ce cas du mode « courtier dinformation ».

46 Novembre – Décembre 2005 Version Lightweight Directory Access Protocol (5) Annuaire et Single Sign On : Lannuaire 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.

47 Novembre – Décembre 2005 Version Lightweight Directory Access Protocol (6) Annuaire et PKI: Lannuaire est une des briques du socle technique nécessaire à la mise en oeuvre dune architecture à clé publique (P.K.I). Stocker les certificats valides en permettant à tout utilisateur de trouver le certificat dun autre par son nom ou adresse e- mail et de vérifier sa validité, Stocker les certificats révoqués pour permettre à toute application deffectuer les vérifications avant de lancer des traitements sensibles, Sécuriser les accès en modification de lannuaire en assurant des fonctions dauthentification utilisant les certificats X 509.


Télécharger ppt "Novembre – Décembre 2005 Version 1.01 1 État de lart de la sécurité informatique Chapitre 3 – Sécurité des accès Auteurs : Stéphan GUIDARINI – Consultant."

Présentations similaires


Annonces Google