Download - Administration des réseaux et des systèmes
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés 1 ©[JP. Brossard, M. Brunet] [2009] INSA de Lyon. Tous droits
réservés
1
2001
IF INFORMATIQUE
Administration des réseaux et des systèmes
Auteur : Gérard Beuchot
ADMINISTRATION
DES RESEAUX
ET
DES SYSTEMES
2
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Un besoin nouveau ?
• Il y a quelques années ou aujourd'hui ?
3
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Un besoin nouveau : suite
• Aujourd'hui ou demain !
4
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
QUALITE DE SERVICE
• DISPONIBILITE
– Continuité du service
• Redondance
• (Re)configuration
• PERFORMANCES
– Gestion statique
– Gestion dynamique
• COÛTS
• COMPROMIS
5
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Présentation• L'ADMINISTRATION DE RESEAUX ENGLOBE
L'ENSEMBLE DES MOYENS MIS EN OEUVRE POUR :
– OFFRIR AUX UTILISATEURS UNE QUALITE DE SERVICE DONNEE
– PERMETTRE L'EVOLUTION DU SYSTEME
• Nouvelles fonctionnalités
• Nouvelles performances
– REPRESENTER LA PARTIE OPERATIONNELLE D'UN SYSTEME
– L'ADMINISTRATION DE RESEAUX EST APPLIQUEE EN SUIVANT
• UNE POLITIQUE : Objectifs à atteindre
QUI SPECIFIE
• UNE STRATEGIE : Plan des actions à entreprendre
• UNE TACTIQUE : Plan d'exécution
• UN FONCTIONNEMENT OPERATIONNEL :
– Modes opératoires
– Mise en oeuvre
6
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Présentation : suite
• L'ADMINISTRATION DE RESEAUX COMPORTE 3 DISCIPLINES
– ADMINISTRATION DES UTILISATEURS
– ADMINISTRATION DES SERVEURS ET DES RESSOURCES
– ADMINISTRATION DE LA RESSOURCE RESEAU DE
TELECOMMUNICATIONS
• L'ADMINISTRATION DE RESEAUX EST GLOBALE
7
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Différents points de vue
d'après J.P. Claudé
PORTEE MOYENSDECISIONDUREE
DISCIPLINES
Fonctionnalités
Configuration performances anomalies sécurité comptabilité
Activités
Ressources
humaines
Outils
court terme
moyen terme
Long terme
Facilités utilisateurs ressources réseaudonnées applications
serveurs
Stratégique
tactique
opérationnelle
Planification
Analyse
Gestion
Contrôle
8
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Fonctionnalités• GESTION DES FAUTES (ANOMALIES)
– Détection et analyse des défauts, Maintenance
• GESTION DES PERFORMANCES
– Réglages (ex : Routage), Planification
• GESTION DE LA COMPTABILITE
– Coûts de communications, Coûts des services et ressources
• GESTION DE LA SECURITE
– Gestion des clés, gestion des droits
• La SECURITE est un domaine d'application à part entière qui doit être
administré
• GESTION DE LA CONFIGURATION ET DES NOMS
– Adresses logiques et physiques
– Base des autres fonctionnalités
– Assure la transparence aux applications et aux utilisateurs
• Serveur de noms
• Modification de la configuration9
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Rappels: Sécurité des réseaux
• Rappel :
– La SECURITE est un ensemble fonctionnel parallèle à l'ADMINISTRATION
qui garantit le RESEAU et les ABONNES et assure :
• L'AUTHENTIFICATION (réciproque) des entités
• Le CONTRÔLE d'ACCES
• La CONFIDENTIALITE des données
• L'INTEGRITE des données
• La NON-REPUDIATION d' ORIGINE
• La NON-REPUDIATION de REMISE
– Signature
– Notarisation
• Ces fonctions utilisent des mécanismes de CHIFFREMENT
10
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Portée et responsabilités
• Contrôle opérationnel
– Opérateurs
– Bureau d'aide
– Support technique
• Gestion
– des problèmes
– des services
– des ressources
• Analyse
– des performances
• Planification
– Evolution
– Techniques nouvelles
11
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Bureau d'aide
Opérateur
réseau
Support
technique
gestion des
problèmes
Comptabilité
Modifications
Inventaires
Performances Réglages
Planification Modélisation
Nouvelles technologies
F
o
u
r
n
i
s
s
e
u
r
s
Usagers Réseau
M
I
B
B
A
S
E
D
E
D
O
N
N
E
E
S
Contrôle opérationnel
• Entre Utilisateurs et Bureau d'Aide
– Erreurs de type 1 (Mise sous tension, modem, débit, parité ...)
• 80% des cas
• Surveillance par opérateur Réseau
– Problèmes même si le système a des reprises automatiques
• parasites, incidents
• Support technique
– Aide opérateur à la maintenance
– Maintenance partagée avec le vendeur
• défauts de type 2 résolus avec ou par l'opérateur
• 15 % des cas
12
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Gestion des problèmes
• Montage du réseau ou nouvelle version,
• nouvelle technologie
– Problèmes très vite résolus
ou
très complexes
– très peu de cas intermédiaires
– 5 à 10 % des cas
– l'essentiel des difficultés
13
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Complexité du problème de
l'Administration de réseaux• HETEROGENEITE
• DISTRIBUE ET PARTITIONNE EN DOMAINES
– Géographiques
– d'Application
– Constructeurs
– de Normalisation (ISO, TCP/IP, SNA ..)
• EVOLUTIVITE
– Un réseau n'est pratiquement jamais remplacé mais EVOLUE
• L'ADMINISTRATION DE RESEAUX DOIT FONCTIONNER MÊME EN CAS DE PANNE DU
RESEAU
– Sous-Réseau d'administration (qui l'administre ?)
– Maillage --> (Re)configuration
• LOCALISATION DES RESPONSABILITES
– Qui administre le réseau (ou le domaine) ?
– Quelle est son autorité ? sa responsabilité ?
– Que fait-il ?
– Problèmes de responsabilité réseaux publics /réseaux privés14
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Domaines d'administration
• Domaines d'administration
– Un système gestionnaire
– plusieurs (au moins un) systèmes
administrés
• Systèmes multidomaines
– Un administré du domaine A est
gestionnaire du domaine B
– Structure hiérarchique
• Système gestionnaire
– Interface administrateur
– traitements
• Système administré
– acquisition des données
– actions
MIBobjetsattributs
Processeurd'applications
Fonctionsde base
MIBobjetsattributs
Processeurd'applications
Fonctionsde base
MIBobjetsattributs
Fonctionsde base
SYSTEMEADMINISTRE SYSTEMEGESTIONNAIRE
SYSTEMEGESTIONNAIRE
SYSTEMEADMINISTRE
DOMAINEB
DOMAINEA
15
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
• Standards
– ISO 7498-4: framework
– ISO 9595-9596 : CMIS/CMIP administration commune
– ISO 10040 : vue d'ensemble de l'administration
X701
– ISO 10164 /10165 : administration système - gestion des objets X72x
• OSI-NMF: Network Management Forum
ADMINISTRATION
de
RESEAUX OSI
16
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Modèles
• Modèle organisationnel
– découpage en domaines
• Modèle opérationnel ou d'information
– description et organisation des données
– modèle OBJET
– nommage
– standards: 10165-1
• Modèle fonctionnel
– architecture logicielle
• administration Système
• administration de couche
• opérations de couche
– standards 9595 -9596
17
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Modèle organisationnel
• domaines
– sous-domaines
• administration
– par l'intermédiaire des
objets gérés
• remontée au central des
informations administratives
CENTRAL
NOEUD
NOEUD
NOEUD
NOEUD
NOEUD
SOUS-
DOMAINE
OBJETOBJET
OBJET
Information
administrative
Information
administrative
RESEAU
D'ADMINISTRATION
FONCTIONS
D'ADMINISTRATION
PROTOCOLES
D'ADMINISTRATION
Information
administrative
18
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
System Manager
Process Manager
Système gestionnaire - système(s)
agent(s)
• les objets sont gérés par :
– le process agent
– la communication est réalisée entre les
process manager et agent
System Agent
Process Agent
Objet
Administré
Objet
Administré
19
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Modèle opérationnel : Principes• Modèle OBJET
• Encapsulation
– toutes les opérations passent par l'échange de messages entre objets
– l'opération est interne à l'objet et porte sur les ATTRIBUTS
– La création ou la suppression d'un objet est réalisée par l'intermédiaire d'un autre
objet
• Héritage
– Tous les objets qui ont les mêmes : ATTRIBUTS - OPERATIONS -
NOTIFICATIONS font partie de la même CLASSE
– Super-classe sous-classe
• Allomorphisme
– capacité pour une INSTANCE d'un objet d'une sous-classe de se comporter comme
sa super-classe.
– permet les migrations de versions matérielles ou logicielles
• Packages conditionnels
– prise en compte CONDITIONNELLE de groupes d'attributs 20
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Objets gérés - Classes d'objets
• Objets gérés
– groupés en classes
– Nom
– Attributs
– Opérations
– Notifications (sur les attributs)
• Sous-classe
– ajout d'attribut(s), d'opération(s) ou
de notification(s) à partir d'une classe
: extension
– de plus en plus SPECIALISE
• Super-classe
– retraits de ....
– une sous-classe peut hériter de
plusieurs super-classes
TOP
SYSTEME ENTITE DE COUCHE
ENTITE DETRANSPORT
CONNEXION
ENTITE DERESEAU
CONNEXION DETRANSPORT
CONNEXION DERESEAU
ENTITE X25
ENTITE IP
21
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Contenance et nommage
• contenance
– un objet géré peut contenir des
objet de la même ou d'autres
classes.
– supérieur subordonné
• modèlise le monde réel
• base du nommage
ROOT
SYSTEME OUVERT GERE
ENTITE RESEAU
MODULECONNEXION
ENTITE TRANSPORT
MODULEEMISSION/
RECEPTION
MODULEEMISSION/
RECEPTION
MODULECONNEXION
CIRCUIT VIRTUEL
NSAP
TSAP
TCEP
22
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Héritage et Contenance
• notions orthogonales
• héritage
– caractéristiques
d'un objet
• attributs
• opérations
• notifications
• contenance
– organisation des
objets
– architecture
TOP
SYSTEMEOUVERT
GERE
ENTITE DE COUCHE
ENTITE DETRANSPORT
CONNEXION
ENTITE DERESEAU
CONNEXION DETRANSPORT
CONNEXION DERESEAU
ROOT
23
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Principes du nommage
• Noms relatifs
– ROOT
– MS.id = "ABC" Système Géré
– L3.id = "3" L4.id = "4" Entités
– CONSP.id = "xyz" TCON.id = "Tcn1" Connexions
– CVC.id = "6" NSAP.id = "abcd"
• Le nom GLOBAL est un AGREGAT de noms RELATIFS
• Noms absolus
Noms relatifs Noms absolus
MS.id= "ABC"
L3.id= "3"
CONSP.id = "xyz"
CVC.id="6"
[MS.id="ABC"]
[MS.id="ABC",L3.id="3"]
[MS.id="ABC",L3.id="3",CONSP.id="xyz"]
[MS.id="ABC",L3.id="3",CONSP.id="xyz",CVC.id="6"]
24
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Arbre de nommage
• désignation d'un objet par son constructeur
• on doit aussi ajouter sa localisation dans le réseaux(voir ci-dessous)
Xyplex
33
SysIdent
1
Character
2
Internet
4
CharPhysNumber
1
CharPhysTable
2
CharPhysEntry
1
CharPhysSpeed
7
root
iso1
ccitt0
joint-iso-ccitt2
org3
dod6
internet1
directory1
mgmt2
experimental3
private4
enterprises1
0 standard
1: autorité enregistrée
2: membre
3: organisations
exemple : Xyplesx= 1.3.1.6.1.4.1.33.
objet : vitesse d'un port d'un concentrateur Xyplex = 1.3.1.6.1.4.1.33..2.2.1.7
Object Identifier ::= {org dod internet private enterprises Xyplex
character charPhysTable charPhysEntry 7}
25
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Base de données administrative : MIB• Information Management Base : regroupe tous les objets administrés
• MIB-II : 171 objets pour architecture Inet (TCP/IP)
• MIB privée– objets fournis par le vendeur de l'équipement
– agents : logiciels pour gérer ces objets à distance
– EXEMPLE
• system group
– system OBJECT IDENTIFIER :: { mib 1}
• sysDescript : description de l'appareil
• sysObjectId : identificateur de l'appareil (N° d'objet dans MIB privée 1.3.2.45. ...)
• sysUpTime : durée (en seconde) depuis laquelle l'appareil est actif
• sysContact : nom de la personne à contacter pour cet appareil (ex: adm@ifhpserv ..)
• sysName : nom de l'appareil (ex: ifhpserv)
• sysLocation : bat 501 -T 202
• sysServices : services offerts (code les niveaux OSI par 2 L-1)
– exemple : transport + administration = 8 + 64 = 48hexa)
26
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Aspects visibles d'un objet
• ATTRIBUTS
• OPERATIONS APPLICABLES
– SUR L'OBJET
– SUR LES ATTRIBUTS
• COMPORTEMENT
– en REPONSE à une OPERATION
• NOTIFICATION
– EMISE par l'objet SANS demande d'Opération
• PACKAGE CONDITIONNEL
– ENCAPSULE DANS L'OBJET
• POSITION DANS LA HIERARCHIE DES CLASSES
• OBJETS ALLOMORPHES AVEC LA CLASSE
27
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Caractéristiques des objets: Attributs
• Les ATTRIBUTS représentent les PROPRIETES des objets
• ils sont
– LUS de façon ATOMIQUE ( par GET)
– MODIFIES " " " ( par SET)
• Ces OPERATIONS sont réalisées INDIRECTEMENT à travers l'objet
• Les ATTRIBUTS sont
– OBLIGATOIRES
– ou placés dans un PACKAGE CONDITIONNEL
• ATTRIBUTS DE BASE
– NOM
– CLASSE DE L'OBJET
– SUPERCLASSES ALLOMORPHES
– CHAÎNAGE DE NOMS
• Classes d'objets que l'on PEUT NOMMER depuis cet objet
– PACKAGE (s'il en fait partie)
28
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Caractéristiques des objets: Opérations• Elles permettent d'AGIR
– SUR LES ATTRIBUTS
• GET
• REPLACE
• SET to DEFAULT
• ADD Member
• REMOVE Member
– GLOBALEMENT sur l'objet
• CREATE
• DELETE
• ACTION
– Action complexe sur des ATTRIBUTS avec INDICATION ou non du
RESULTAT
– SYNCHRONISATION des opérations sur plusieurs attributs gérée par
l'objet lui-même
29
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Caractéristiques des objets:
Notifications - Filtres
• NOTIFICATIONS
– INFORMATIONS EMISES "SPONTANEMENT" par un objet
• à la suite d'une modification ou d'un événement subit par l'objet
• impliquant la modification d'un attribut
• FILTRES
– pour SPECIFIER des CRITERES auxquels doivent satisfaire un objet pour
qu'une opération soit effectuée
– Sélection de plusieurs objets pour des opérations identiques
30
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Caractéristiques des objets:
Comportements - Packages
• COMPORTEMENT
– SEMANTIQUE des attributs, notifications et opérations
– REPONSE aux OPERATIONS INVOQUEES
– Circonstances dans lesquelles les NOTIFICATIONS sont émises
– DEPENDANCES entre VALEURS d'attributs particuliers
– EFFETS des RELATIONS sur les autres objets gérés
• PACKAGES CONDITIONNELS
– COLLECTIONS d'attributs optionnels, d'opérations et de notifications
(sur ces attributs) qui sont tous absents ou présents SIMULTANEMENT
– Une seule instance possible
– Instanciation à travers l'objet
31
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
MIB pour Internet: Objets gérés
• Les objets "Internet" sont décrits par seulement 5 paramètres :– Descripteur de l'objet
Nom et identificateur dans l'arbre de nommage
– Syntaxe
Type en ASN.1
– Définition
Description en texte libre
– Droits d' Accès
lecture seule
lecture - écriture
écriture seule
non accessible
– Statut
obligatoire
optionnel
obsolète
32
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
MIB pour Internet: Objets gérés (suite)
• Ainsi un objet est caractérisé par
– un NOM
– une SYNTAXE
– un CODAGE
• La syntaxe utilisée est un SOUS-ENSEMBLE de ASN.1
– La structure est une version très simplifiée de la structure des objets OSI avec
seulement 2 ATTRIBUTS en plus du nom.
33
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Syntaxe ASN.1 pour MIB Internet• Le sous-ensemble utilisé comporte les types suivants :
– INTEGER
– OCTET STRING
– SEQUENCE { }
– SEQUENCE OF
– OBJECT IDENTIFIER
– NULL
• et les types Applications :
– NetworkAdress (choix { internet IpAdress})
– IpAdress (chaine de 4 octets)
– Counter (entier 0..4294967295)
– Gauge Seuils (entier 0..4294967295)
– Timeticks Temporisation (entier 0..4294967295)
– Opaque Masque tout type spécifique (chaine d'octets)
34
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Syntaxe ASN.1 pour MIB Internet:
Exemple 1• issu de la MIB II :
• OBJECT :
IpAddrTable {ip 20}
Syntax :
SEQUENCE OF IpAddrEntry
Definition:
The table of adressing information relevant to this entity's IP adresses
Acces :
read-only
Status :
mandatory
35
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Syntaxe ASN.1 pour MIB Internet:
Exemple 2• DEBIT D'UN PORT D'UN CONCENTRATEUR DE TERMINAUX XYPLEX POUR
SNMP
• entreprise XYPLEX 1.3.1.6.1.4.1.33
– OBJECT
• SysIdent {system 1}
• Syntax : DisplayString (SIZE (0..40))
• Definition : (chaîne d'identification ......)
• Acces : read-only
• Status : Mandatory
– OBJECT
• charPhysNumber {character 1}
• Syntax : INTEGER
• Definition : (Nombre de ports physiques ......)
• Acces : read-only
• Status : Mandatory36
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Syntaxe ASN.1 pour MIB Internet:
Exemple 2 (suite)– OBJECT
• charPhysTable {character 2}
• Syntax : INTEGER
• Definition : (Liste des ports d'entrée arytmiques......)
• Acces : read-only
• Status : Mandatory
– OBJECT
• charPhysEntry {charPhysTable 1}
• Syntax : charPhysEntry ::= SEQUENCE {
charPhysIndex,
INTEGER, ....
charPhysSpeed,
INTEGER, .......}
• Definition : (Caractéristique d'un port d'entrée ......)
• Acces : read-only
• Status : Mandatory 37
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Syntaxe ASN.1 pour MIB Internet:
Exemple 2 (suite)– OBJECT
• charPhysSpeed {charPhysEntry 7}
• Syntax : INTEGER
• Definition : (Vitesse du port......)
• Acces : read-write
• Status : Mandatory
• Ainsi la vitesse d'un port de ce concentrateur est un objet administrable qui peut être
lu ou positionné.
– Il est identifié de manière unique par
• charPhysSpeed OBJECT IDENTIFIER ::=
{org dod internet private enterprises XYPLEX
character charPhysTable charPhysEntry 7}
– soit 1.3.6.1.4.1.33.2.2.1.738
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
MIB-II• RFC 1158
• CONTENU
– 171 objets de type Réseau TCP/IP
39
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Type Nombre Commentaires
system 7 Nœud administré
interface 23 attachement réseau (Ethernet, Token Ring, X25, etc.)
at 3 Translation de l'adresse IP en adresse niveau 2
IP 38 Protocole IP (niveau )
ICMP 26 Protocole ICMP (niveau 3 - supervision)
TCP 19 Protocole de transport TCP
UDP 7 Protocole de transport sans connexion UDP
EGP 18 Routeurs (Gateway)
transmission 0 objets réseau spécifiques
snmp 30 Niveau 7 : administration de réseaux SNMP
MIB-II: Exemple d'objet
• system group
– system OBJECT IDENTIFIER :: { mib 1}
– sysDescript : description de l'appareil
– sysObjectId : identificateur de l'appareil
• (N° d'objet dans MIB privée 1.3.2.45. ...)
– sysUpTime : durée (en seconde) depuis laquelle l'appareil est actif
– sysContact : nom de la personne contact pour cet appareil
• (adm@ifhpserv ..)
– sysName : nom de l'appareil (ifhpserv)
– sysLocation : bat 501 T 502
– sysServices : services offerts (code les niveaux OSI par * 2 L-1)
• exemple : transport + administration = 8 + 64 = 48hexa
40
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Internet
1
mgmt
2
directory
1
experimental
3
private
4
mib
1
tcp
6
ip
4
Adres.
transl.
3
interfaces
2
system
1
icmp
5
egp
8
udp
7
cmot
9transmission
10
snmp
11
sysDescr
1sysObjectID
2
sysName
5sysLocation
6
ipAddrTable
20
ipAddrEntry
1
ipAdEntAddr
1
ipAdEntNetMask
3
ipRoutingTable
21
ipRouteEntry
1
ipRouteDest
1
ipRouteMetric1
3
1.3.6.
Identification des objets de la MIB-II
• Identification des objets
«Inet»
– exemple : Adresse IP
1.3.6.1.2.1.4.20.1.1
41
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Modèle Fonctionnel• GESTION SYSTEME
– SERVICES CMIS et SMIS
– PROTOCOLES CMIP et SMIP
• CMIP utilise le service ROSE
– RO-INVOKE RO-RESULT RO-ERROR
• GESTION DE COUCHE
– Service particulier parallèle à un service de communications
– lui préférer quand c'est possible un service de niveau 7 en "remontant" les
informations nécessaires– sondes administratives
– Utile pour les couches basses (par exemple routage)
• architecture d'un routeur ne comprend que les couches 1 à 3
• OPERATIONS DE COUCHE
– Inclues dans les services de communication
– par exemple taxation dans X25 et plusieurs autres champs de facilité
• Toutes les informations utiles sont rangés dans la MIB
42
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Architecture fonctionnelle
• SMAE
– System Management
Application Entity
• LE
– Layer Entity
• SM ASE
– System Management
Application Service Element
• SMIP
– System Management
Information Protocol
• CMIP
– Common Management
Information Protocol
SMAE
SM ASE
SM ASE
SM ASE
CMISE
SMAE
SM ASE
SM ASE
SM ASE
CMISECMIP
SMIP
SM
SMAE
7 7
LE
LME
M
I
B
SM
M
I
B
SMAE
7 7
LE
LME
SMP
N-protocole
N-LM-Protocole
(SMP)
43
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Service Commun d'Administration OSI
• Il comporte 2 sous-ensembles obligatoires et un sous-ensemble d'extension
• SERVICE D'ASSOCIATION: Il s'appuie sur ACSE et utilise les primitives• M.INITIALIZE service CONFIRME
• M.TERMINATE service CONFIRME
• M.ABORT service NON CONFIRME
• SERVICE DE TRANSPORT– SERVICE D'OPERATIONS
• M.GET Consultation CONFIRME ou NON
• M.SET Mise à jour CONFIRME ou NON
• M.CREATE Création CONFIRME
• M.DELETE Suppression CONFIRME
• M.ACTION Opérations complexes CONFIRME ou NON
– SERVICE DE NOTIFICATION• M.EVENT-REPORT CONFIRME ou NON
• EXTENSION• CANCEL-GET Annulation d'une opération GET
• SET Ajout d'éléments dans une liste
44
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Gestion Système
• LISTE NON EXHAUSTIVE ....
• Standards 10164-x et 10165-x
• FONCTIONNALITES SUPPORTEES
– GESTION D'OBJETS
– GESTION D'ETATS
– GESTION DE RELATIONS
– COMPTE-RENDU D'ALARMES
– COMPTE-RENDU D'EVENEMENTS
– COMMANDE D'ARCHIVAGE (LOG)
– COMPTE-RENDU D'ALARMES DE SECURITE
– SYNTHESE DE MESURES
– SYNTHESE DE DIAGNOSTICS
45
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Gestion d'objets
• Fonctionnalités de base "passe tout droit" (pass-through)
projetées sur le Service Commun CMIS
• Les objets suivent le modèle d'information décrit plus haut avec
– Attributs
– Opérations
– Comportement
– Notifications
– Packages conditionnels
– Position dans la hiérarchie d'héritage
– Allomorphisme
46
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Gestion d'objets (suite)
• PRIMITIVES
– OPERATIONS
• P-CREATE
• P-DELETE
• P-ACTION
• P-SET
– replace
– add
– remove
– set-to-default
• P-GET
– NOTIFICATIONS
• P-EVENT
47
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Gestion d'état
• 3 types d'ETATS sont à considérer. Ils ne sont pas totalement indépendants et sont regroupés dans l'ETAT de GESTION.
– OPERABILITE
• INVALIDE
• VALIDE
– USAGE
• ACTIF
• OCCUPE
– OPERATIONNEL = OPERABILITE + USAGE
– ADMINISTRATION
• VEROUILLE
• FERMETURE
• DEVEROUILLE
– GESTION
• Combine état opérationnel et état administratif (voir ci-dessous)
– Un ETAT de SANTE est aussi fourni.
48
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Gestion d'état: Etat de gestion
OpérationnelINVALIDE VALIDE ACTIF OCCUPE
Administratif
VEROUILLE Invalide Vérouillé Valide Vérouillé Impossible Impossible
FERMETURE
Basculement
automatique vers
invalide occupé
Basculement
automatique vers
valide occupé
Actif FermetureOccupé
Fermeture
DEVEROUILLEInvalide
Dévérouillé
Valide
DévérouilléActif Dévérouillé
Occupé
dévérouillé
49
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Etats opérationnels
• Opérabilité
– enable
– disable
• Usage
– New user
– User quit
– Last user quit
• CD capacité décroît
• CI: Capacité croît
Invalide
Valide
Actif
new User
enabledisable
User quit
last userquit
new userou CD
User quitou CI
disable
new userou CD
user quitnon partageable
Occupé
50
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Etats Administratifs
– Verrouillage
– Déverrouillage des objets
– FermetureDévérouillé
Fermeture
Vérouillé
Fermer
utilisateursrestants
Dévérouiller
Quitterdernier utilisateur
Vérouiller
Vérouiller
Dévérouilleroui non
51
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Santé d'un objet• Donne des précisions sur l'état d'un objet invalide
Gestion des anomalies– ANOMALIE RAPPORTEE
– EN FAUTE
– EN REPARATION
– RESERVE POUR TEST
– EN TEST
– NON INSTALLE
– JAMAIS INSTALLE
– JAMAIS UTILISE
– HORS TENSION
– HORS LIGNE
– HORS USAGE (temps limite dépassé)
– INITIALISATION INCOMPLETE
– INITIALISATION REQUISE
52
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Gestion de relations entre objets• RELATIONS
– DIRECTES
– INDIRECTES
– SYMETRIQUES
– ASYMETRIQUES
• RELATIONS DEFINIES– CONTENANCE
– EXPLICITES• SERVICE Client/Fournisseur
• PAIRE (peer)
• REPLI (fallback) Primaire/Secondaire
• REMPLACEMENT (backup) Remplaçant/Remplacé
• GROUPE Propriétaire/Membre
• etc.
• Elles sont– CREES par Add
– SUPPRIMEES par Remove
– MODIFIEES par Replace ou Set-to-default
A
AB
B
RARA
BA
Relation directe AB
Attribut relation RA; ici RA contient BA
53
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Compte-rendu d'événements
• Permet de notifier des événements localement
• ou au système gestionnaire
OBJET
GERE
Compte-rendu
d'événements
Détéction
d'événements
et
traitements
EFD
Notifications
Notifications
Commande
Réponse
EFD :
Event Forwarding Discriminator
OBJET
GERE
Compte-rendu
d'événements
Séléction locale
d'événements
Détéction
d'événements
et
traitements
Notifications
Traitement
local
Traitement local
et
Rapport à d'autres sytèmes
54
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Administration Inet
SNMP
Simple Network Management Protocol
SNMP-V1 (version 1): RFC 1157
MIB-II: RFC1213 (RFC 1212)
SNMP-V2 (version 2): RFC 1441 à 1452
55
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Architecture SNMP (Inet): Simple network Management
Protocol
• Equipements administrés
– Hôtes
• stations de travail
• serveurs
• concentrateurs
• imprimantes
• etc
– routeurs, passerelles
– ponts, hubs,etc.
– logiciels TCP/IP
interface graphique
Base de données
Application d'
Administration
Traducteur SNMP
Gestion du transport
Gestion du transport Gestion du transport
Agent SNMP
MIB Equipement
Proxy SNMP
Informations
Propriétaires
Application et
Equipement SNMP
Station d'Administration
Equipement
non SNMP
56
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Opérations SNMP
• Chaque équipement géré est vu comme un ensemble de variables que l'on peut :
– consulter Get-Request
– Get-Next-Request
• Table "Traversal" :
– Balayage de tables
– Traversée pour les routages
– modifier Set-Request
• à distance. Cet ensemble correspond à un objet dans le modèle d'information
OSI, les variables étant des attributs.
– On peut aussi en recevoir spontanément des informations (notifications) :
• trap
57
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Opérations SNMP: le "puissant" GET-
NEXT• Permet les opérations de type "TRAVERSAL " pour explorer des tables
• utilisé en particulier pour les tables de ROUTAGE
ou les tables d'ADRESSES• Problème :
– TROUVER une valeur dans une table de la MIB avec SNMP qui ne traite que des objets simples (contrairement à administration OSI)
• exemple :
– si on demande get-next (sysDescript)
– on obtient la vaeur de l'objet suivant soit sysObjectId
• UTILE pour les tables dont on ne connaît pas
– le contenu réel
– la taille
• get-next peut avoir plusieurs paramètres (comme set ou get ...)
– tables à plusieurs colonnes
58
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Exemple d'utilisation de Get-Next
• get-next (ipRoureDest, ipRouteIfIndex, ipRoureNextHop)
– donne la première ligne de la table de routage
• en rappelant get-next avec la valeur reçue ---> ligne suivante
• remarque :
– ipRouteNextHop identifie le routeur suivant dans le réseau
– qui peut à son tour être testé
– peut être utilisé pour surveiller une route
59
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Messages SNMP: Requêtes• codés dans un sous-ensemble de syntaxe ASN.1
– message: SEQUENCE {version(1), communauté, PDU}
• Requêtes
– GetRequest-PDU
– GetResponse-PDU
– GetNextRequest-PDU
– SetRequest-PDU
• identificateur
• type d'erreur
– noError (0)
– tooBig (1)
– noSuchName (2)
– BadValue (3)
– readOnly (4)
– genErr (5)
• index d'erreur (numéro de la variable en erreur)
• liste (agrégat) de variables (nom et valeur) 60
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Messages SNMP: Trap• TRAP
– Trap-PDU
• identification de l'agent source
• adresse de l'agent
• type de trap
– coldStart (0)
– warmStart (1)
– linkDown (2)
– linkUp (3)
– authentificationFailure (4)
– egpNeighborLoss (5)
– enterpriseSpecific (6)
• champ spécifique pour traps particuliers
• date de l'événement
• liste des variables associées à ce trap
• Manque de sécurité
– nom de "communauté" : sorte de mot de passe super-utilisateur
– version SNMP 2
61
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Outils
d ’administration
62
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Outils d'administration
• Mono ou Multistandard
– Architecture constructeur
• exemples: Netview (SNA), Administration Netware, Windows NT...
– Architecture SNMP
• exemple: SunNetManager, SNMPc
– SNMP + OSI + SNA
• exemple: HP OpenView, IBM System View, ...
– Hyperviseurs
• Permet de superviser plusieurs systèmes d'administration
• Introduction de systèmes- expert
• Outils de bas-niveau: analyseurs
– sondes administratives
63
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Superviseurs de réseaux
• Faciliter l'administration des grands réseaux, plus ou moinshétérogènes– A terme, ils devraient supporter l'ensemble des fonctionnalités de
l'administration de réseaux. Actuellement, ils ne supportent généralementque les fonctionnalités de:
Gestion de la configuration et des noms
– partiellementGestion des anomalies
Gestion des performances
– et parfoisGestion de la sécurité (par collecte des alarmes de sécurité)
• Un superviseur comporte deux grands groupes de fonctions:
les fonctions de surveillance et d'acquisition des informations
les fonctions d'observation et de commande
64
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Principales fonctions d ’un superviseur
de réseaux• Fonctions de surveillance et d'acquisition des informations
– supporté par des "démons" qui tournent de manière permanente sur le système d'administration
• (qui doit donc être multitâches: Unix ou Windows NT par exemple)
• les fonctions d'observation et de commande– description manuelle de l'architecture du réseau serait longue et complexe
– découverte automatique du réseau supervisé.
• une des premières fonctionnalités d'un superviseur
• Après identification des systèmes constituants et des moyens de les atteindre,
– Surveillance• par scrutations périodiques (fonction Get de SNMP),
• par acquisition des notifications d'événements– émises par des systèmes en anomalie ou sujet à des attaques (Trap de SNMP)
– Mise à jour la configuration courante du réseau
– Enregistrement dans des journaux (Log)• consultables à la demande.
65
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Exemples d ’utilisation (HP Openview)
66
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Exemples d ’utilisation (HP Openview) : suite
67
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Exemple: architecture OpenView
• Routeur
– fonctions de bases
• Objets de gestion : MIB
• Objets de gestions permanents
– ne peuvent être détruits
même en cas de panne
Interface
Utilisateur SuperviseurObjets
de gestion
ROUTEURServices
de gestion
Objets
de gestion
permanents
Applications
de gestion
Services
d'environnement
Profils de
communications
RéseauRéseau
68
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Hypervision d'un réseau
L'utilisation de proxy permet de traiter les
problèmes d'hétérogénéitéHyperviseur
Superviseur 1
ex: SNMPSuperviseur 2
ex: Sare
Ressources X25
Proxy SNMP
Netware
agent SNMPSNMP
Ressources TCPIP
Ressources LAN
Proxy SNMP Proxy (SARE)
69
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
ROUTAGE
ET
ACHEMINEMENT
70
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Définitions
• Routage : Etablissement d'un itinéraire entre deux systèmes hôtes d'un réseau
• Acheminement : Conduit un message à une destination prévue à l'avance
– Aiguillage des données
• Les noeuds intermédiaires sont des routeurs
– des commutateurs de paquets
– IS : Intermediate System
• Les hôtes sont des ETTD : Equipements terminaux de traitement de données
– DTE
– ES : End System
A
D
B
C
E
71
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Aspects
• 4 points de vue
– Algorithmes de routage
• permettent de calculer les tables de routage
– Protocoles de routage
• Echange des informations entre routeurs
• ou routeurs et ES
– Programme de routage
• Calcul des tables de routage d’après les informations de routage
– Programme d’acheminement
• Aiguillage des données sur les ports du routeur
72
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Normalisation
• Normalisation OSI :
– ISO 9542 : Echange d'information de routage entre ES et IS sur un
• réseau sans connexion (IP)
– ISO10030 :Echange d'information de routage entre ES et IS sur un
• réseau avec connexion (X25)
– ISO 10589 : Echange d'information de routage entre IS et IS sur un
• réseau sans connexion (IP)
• RFC pour Inet
– RIP
– EGP
– OSPF
– autres: Hello, BGP
– (IGRP ), EIGRP (Cisco)
73
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Expression des besoins
• Acheminement :
– Adresse destination
– Itinéraire connu pour atteindre cette adresse
ou hasard ou inondation ....
• Routage :
– Topologie du réseau
– Expression des coûts des chemins possibles
– Estimation du trafic à acheminer
– Modifications
• rares ( pannes, changements de topologie)
• fréquentes (trafic)
74
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Modes de gestion du Routage
• Gestion du réseau
– Globale
• Echange d'information de routage entre ES, IS et Centre de gestion dans les
deux sens pour donner l'état du réseau et changer le routage
– Distribuée
• Echange d'information de routage entre ESet IS pour donner l'état du réseau
• Besoins différents pour systèmes
– avec connexion : itinéraire établi en phase de connexion
– sans connexion : itinéraire pour chaque paquet
– sans connexion: chemin établi avec premier paquet et transmis à la source... qui
l'utilise pour paquets suivants
75
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Types de Routage
• FIXE :
– déterministe
– avec alternative
– aléatoire
– par inondation
• ADAPTATIF :
– centralisé
– distribué
• à contrôle local
• par domaine
76
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Routage fixe Destination
A B C D E
Source
A A B B D E
B A B C C A
C B B C D D
D A C C D A
E A A A A E
Tables de routage
A
D
B
C
E
Routage avec alternativesDestination
A B C D E
Source
A A B B,D D E
B A B C,A C A
C B,D B C D,B D
D A C,A C D A
E A A A A E
TABLES d'ACHEMINEMENT DANS LES NOEUDS
Routage fixe Destination
A B C D E
(C) B B C D D
Routage avec alternativesDestination
A B C D E
(C) B,D B C D,B E77
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Algorithme du CHEMIN LE PLUS
COURT• Métrique
– de coût
– de performance
– ou les deux successivement
• Algorithme de base :
– Initialisation :
• Ni = noeud courant Na = noeud de départ, di= , da=0
• Méthode par balayage– L'algorithme s'applique en prenant successivement les noeuds du réseau comme
noeuds de départ.
– A chaque noeud on assigne un couple de valeurs (noeud, distance).
– On recherche pour tout couple i, j une branche i,j telle que di + l(i,j) < dj
– On associe au noeud Nj le couple (Ni, di + l(i,j))
– On dispose de la plus courte distance à Na et du noeud voisin le plus proche.
– Le noeud indiqué est le prochain noeud sur le chemin le plus court.
78
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Routage sur TRANSPAC
• ADAPTATIF
– En fonction des pannes ou de très fortes surcharges
– Chaque commutateur
• surveille son environnement
• compare état avec seuils (à hystérésis)
• si seuils dépasséschangement d'itinéraire
• retour état antérieur si on revient au dessous
• Routage hiérarchisable
– Point visé
• proche : analyse fine
• éloigné : transfert vers un point proche du point visé
79
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Routage sur TRANSPAC (suite)
• Algorithme distribué
• Chaque commutateur
– est autonome
– tient compte
• de son environnement
• des informations transmises par ses voisins
– propage ses informations d'environnement
• Prise en compte des coûts
– Si liaisons "périphériques" "coût" pris en compte
– Si panne ou surcharge "coût" très élevé …
• Routage par point visé si longue distance
80
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Routage sur INTERNET• Routage par protocoles
– RIP (RFC 1058)
– OSI10589 (RFC 1195) (mixte OSI / INET)
– OSPF (RFC 1247)
– EGP (RFC 904 - 911)
– EIGRP (Cisco)
• Algorithme de type "vecteur distance"
– Chemin le plus long limité à 15 ?? étapes
– Mise à jour des routes au minimum toutes les 30 s
• ADAPTATIF mais pas au trafic en temps réel
• Informations transportées par messages
– RIP
– autres
– mis dans des messages UDP
81
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
RIP
• Routing Information Protocol
• Table de routage établie pour chaque nœud donne
– Distance vers toutes les destinations
– Prochain nœud à emprunter
– Cette table est envoyée pour mise à jour à tous les voisins
• Métrique : nombre de nœuds traversés
– on peut ajouter un "coût" à chaque étape
– Coût de i à j par k = D(i,j) = mink d(i,k) + D (k,j)
– meilleure route : D(i,j) minimal
• Routage se modifie de proche en proche (variation des d(i,k))
– Suppose que la topologie reste fixe.
– si elle change (panne) liste des voisins change et routage modifié
82
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
EGP
• Exterior Gateway Protocol
• Grands réseaux
– Systèmes autonomes: RIP
– Interconnexion de systèmes autonomes: EGP
– Faire connaître ses routes à un routeur d ’un autre système autonome
• Acquisition de voisinage
– voisin EGP ou pair EGP
– Vérifie que pairs EGP sont toujours accessibles
– Echange des informations de routage avec pairs EGP
• aucune interprétation des notions de distance échangées
• abandonné pour OSPF ou EIGRP
83
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
OSPF• Open Shortest Path First
– Type SPF: plusieurs route identiofiées, choix de la plus courte
• Concepts
– Routage par type de service
• Réseaux multi-accès
– Annonce de l’état des liens
• routeur désigné (pour réduire diffusion)
– Equilibrage de charge
– Domaines (zones) interconnectés (grands réseaux)
• Masques de réseau de longueur variable
– Echanges entre routeurs authentifiés
– Echange d ’informations acquises de sites extérieurs
• peut transporter des messages RIP
• Version simplifiée ?? Concurrente de ISO 10589
– Au dessus de IP (IS-IS est au niveau 3…)84
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
EIGRP
• Enhanced Interior Gateway Routing Protocol
• Concepts
– Routage hybride
• vecteurs distance
• Etat des liens
– voisin de 10589 IS-IS
– convergence rapide
• multi-protocole
– IP - IPX - Apple
• multipoint
85
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Programmes de routage
• Routed
– Unix Berkeley 4.2
– utilise RIP
• pour diffuser des informations issues des tables de routage
– essaie d ’éliminer les boucles de routage
– Routage statique: commande « route »
• Gated
– combine RIP, Hello, EGP
– modifie les tables de routage locales
– propage les info de routage par EGP
86
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
SECURITE
DES RESEAUX
ET DES SYSTEMES
87
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
ObjetSécurité des
systèmes répartis
Fonctionnalités
de sécurité
Aspects
Techniques
Mécanismes
de sécurité
Aspects
Organisationnels
Evaluation
Sécurité Physique
Organisation
Infrastructures de
Gestion de Clés
publiques (PKI)
Aspects
juridiques et
légaux
Cryptographie
Architecture
logicielle
Sécurité
individuelle
Sécurité collective
Sécurité sur
Internet
utilisent souvent
Reposent sur sont organisés dans
impose d'abord
Protocoles de
sécurité
Cartes à pucemettent
en oeuvre
peuvent
utiliser
Algotithmes
cryptographiques
nécessite
Politique
de sécurité
dépend de
attaques
pirates..
tests
d'intrusion
88
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Sommaire• Généralités
• Politique de sécurité
• Aspects légaux et juridiques
• Aspects organisationnels
• Aspects techniques
• Fonctionnalités
• Carte à puce
• Sécurité individuelle
• Kerberos - DCE
• Sécurité collective
• Cloisonnement - coupe-feu
• Analyseur de sécurité
• Sécurisation de l ’Internet
• Protocoles de sécurité
• Services Réseau et Transport
• Services Application
• Infrastructures de Gestion de Clés publiques
• Évaluation de la sécurité
89
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Généralités
90
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Introduction
• Sécurité de l’information
– protection du capital d’information contre les divulgations, modifications ou destructions intentionnelles ou accidentelles mais interdites
• Valeur de l’information vs. Coût de la sécurité
– coûts directs
– coûts indirects : réduction de performances ou d’utilisabilité des systèmes
• Sécurité soumise à des attaques
– Politique de sécurité
– Services de sécurité
• d ’un système
• d ’un ensemble de systèmes en réseau privé
• des communications entre systèmes ou réseaux privés
– Gestion de la sécurité : aspects organisationnels
– Évaluation de la sécurité
91
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Classification des attaques– Interruption: Attaque sur la
Disponibilité
– Interception: Attaque sur la
Confidentialité
– Modification: Attaque sur l ’Intégrité
– Fabrication: Attaque sur
l ’Authentification
Passive Attacks
Release of message
contents
Intercept ion
Confidentiality
Traffic analysis
Active Attacks
Fabricat ion
Integritity
Modificat ion
Integrity
Interrupt ion
Availabil ity
Interruption
Interception
Modification
Fabrication
92
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Exemples d’attaques• Abus de Privilège
– Exécution d ’une action interdite par un utilisateur
• Data diddling (duper)
– modification des données entre source et collecteur
• Attaque par les données (Data Driven)
– Envoi de données codées qui semblent inoffensives et s ’exécute sur
système distant
• Manipulation de données
– modification ou fabrication de données durant leur transfert ou leur stockage
• Déni de service
– empêche usage d ’un service par utilisateurs légitimes (inondation du réseau,
rupture de communication, interdiction d ’accès à une personne, rupture de
service…)93
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Exemple d’attaques (suite)• DNS spoofing (parodie)
– attaque sur le service de noms
• Email bombing / spamming
– bombardement d ’email : n fois le même ou par des milliers d’utilisateurs
• Espionnage (Eavesdropping )
– espionnage, écoute des communications
• IP Spoofing
– parodie, emprunt d’adresse IP
• IP Splicing / Session Hijacking (épissure)
– interception et utilisation conjointe d ’une session (après phase
d ’authentification)
• Attaque « Man-in-the-middle »
– Intrusion dans l’échange de clés initial (système à clé publique) 94
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Exemple d ’attaques (suite)
• Mascarade
– L ’attaquant se fait passer pour un utilisateur autorisé
• Attaque du fichier de mots de passe
– «craquer» le mot de passe du super-utilisateur, des administrateurs de préférence ...
• Attaque « Replay »
– réémettre un message par exemple login/password ou authentification
• Attaque « Smurf »– un utilisateur d ’Internet malveillant dupe des milliers de systèmes en leur envoyant du
trafic, des pings, ...
• Forgeage ou parodie d’Email– différentes formes mais résultat, l ’utilisateur reçoit des messages qui semblent venir d ’une
autre source…exemple demande par un administrateur ou une autorité (changer de mot de passe par exemple)
95
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Politique de sécurité
96
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Bases
• Pourquoi ?
– Comprendre les menaces contre l ’information et les systèmes
– Évaluer les risques et les coûts
– Définir les action pour prévenir les ou répondre aux menaces
• Approche de base
– Regarder ce qu’il y a à protéger
– Regarder contre quoi ou qui on doit se protéger
– Déterminer la probabilité des menaces
– implémenter des mesures pour se protéger à un coût adapté
– Analyse ce qui arrive quand la politique est violée
Toujours bien considérer que le coût de la protection doit être inférieur au coût de la
remise en état ou des dommages….
97
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Questions organisationnelles• Organisation
– Elle dépend de l’entreprise, de ses buts, des risques, des menaces, …
– On doit tenir compte des politiques définies dans les autres domaines
– On doit traiter les risques locaux mais aussi tenir compte des sites distants
• Responsabilités– effort conjoint des décideurs et du personnel technique
• qui connaît mieux les risques, les points faibles, …
– Tout le monde doit connaître ses propres responsabilités pour maintenir la sécurité
• Niveaux de responsabilité associés à la politique de sécurité
– responsabilités particulières des gestionnaires systèmes et gestionnaires réseaux
• Évaluation des risques– coût de l ’information : valeur ou sensibilité, valeur d ’un mot de passe,….
• Qu’est ce qui arrive quand la politique est violée ?
• Que faire quand un utilisateur local viole la politique d’un site distant ?– Négligence, faute, accident ….
98
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Questions à se poser
• Questions générales
• Que doit on protéger
• Problèmes possibles
– vulnérabilité
• Questions économiques
• Quelle philosophie appliquer
– tout ce qui n ’est pas interdit est permis ou l ’inverse
• 5 critères pour évaluer une politique de sécurité
• Que faire en cas de problèmes
– Protéger et traiter si ...
– continuer et poursuivre en justice si ...
99
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Document à rédiger
• Public et très largement diffusé
• Relatif à la protection de l ’information
• Base pour fixer les directions à suivre et indiquer la conduite à tenir
• Conduite à tenir soutenue par l ’exécutif supérieur de l ’entreprise
• document périodiquement mis à jour ou renouvelé
• Doit contenir
– définition de l ’organisation de la sécurité
– un exposé sur l ’applicabilité
– les conséquences d ’une non-conformité
– les exigences pour la propriété ou la classification de l ’information
– les responsabilités individuelles de tous
– les actions à entreprendre en cas d’attaque
• Doit être connu, compris (pour ce qui le concerne) et agréé par tous
100
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Évaluation de la politique de sécurité• 5 critères : la politique
– respecte elle la loi, les devoirs vis à vis des tiers ?
– Compromet elle (sans nécessité) les intérêts:
• des employés
• de l ’employeur
• des tiers
– est elle réalisable de manière pratique ou peut elle être renforcée ?
– Traite elle de manière appropriée tous les problèmes
• communication
• stockage
– est elle annoncée à l’avance et agréée par tous ?
• Document public largement diffusé, mis à jour, renouvelé
– responsabilités de chacun ...
– connu de tous, agréé par tous…
101
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Aspects légaux et juridiques
102
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Aspects juridiques et légaux :
généralités
• Aspects légaux
– Cryptographie (loi de 1996, décrets et arrêté de mars 1999)
– Preuve et signature (loi/code civil : mars 2000 - décret: mars 2001)
• Aspects juridiques
– validité des signatures
– validité des clés de chiffrements
• Tiers de confiance
• Infrastructures de Gestion de Clés publiques (IGC)
– PKI : Public Key Infrastructure
– Droits de la propriété intellectuelle
• Filigranes (watermarks)
103
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Aspects organisationnels
104
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
• Responsabilités, pouvoirs, devoirs
– définis à différents niveaux
• Sécurité : fonction de management
– seul chef d’entreprise peut prendre les décisions d’organisation
• conseillé par « hommes de l ’art »
– Administrateur de la sécurité
– 2 Equipes aux responsabilités et compétences complémentaires
• Equipe fonctionnelle
– Élabore un modèle de sécurité
– définit ce qui doit être protégé
• Equipe opérationnelle
– met en œuvre la politique
– traite les problèmes techniques
• Actions à entreprendre au niveau organisation
• Gestion de l’analyse des risques
105
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Actions à prévoir et planifier
• Diffusion d’information, de recommandations
– Campagnes de sensibilisation
– Réactions à un incident
• Gestion des mots de passe
– création ou vérification
• taille, facile à mémoriser, pas dans les listes
• outils de cassage pour vérifier
– règles d’utilisation
• jamais noté, jamais donné …
• si possible, jamais transmis surtout en clair ….
– Système centralisé (Kerberos/DCE)….
• Gestion de la sécurité du réseau
– mise en place des outils et configuration
– tests d’intrusion
106
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Gestion des risques• Risques évoluent avec :
– valeur du capital d’information
– évolution technique des outils d’attaque
• Si risque se concrétise : incident de sécurité (violation)– Réparer les dommages
– Prévenir incidents ou les minimiser
• mesures préventives
• mesures de réduction– Sauvegardes
• En cas d’incident :– mesures répressives contre les auteurs
– mesures correctives
– Si incident grave :
• Analyse du problème
• amélioration du système
• Équipe pluridisciplinaire
107
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Sécurité physique• Pas de sécurité du système TI si lui même n’est pas physiquement sur …
• attaques délibérées ou accidentelles
– incendie, dommage des eaux, chaleur, moisissures
– poussières, fumées
– champs magnétiques (supports de stockage)
• moteurs, câbles, hauts-parleurs , ….
• Quelques points particuliers
– sécurité des consoles
• limiter, contrôler l’accès à la pièce , verrouillage …
– sécurité des données
• sauvegardes : à faire et à protéger !
• Documents imprimés …à détruire
– sécurité des équipements : alimentation régulée et secourue
– conduite des usagers (mots de passe, écran , ..)
– bannière de bienvenue : accès non autorisé , violeurs seront poursuivis ….
108
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Sécurité physique (suite)
• Checklist pour planifier la sécurité physique
– types de contrôles et niveau d’efficacité des opérations
– périmètres et barrières de protection
– Identification de l’importance des équipements, des données
– Facteurs d’évaluation : environnements de la sécurité
– Sécurité procédurale et formulation de la politique
– Sécurité des documents sensibles
– Désignation des niveaux de responsabilité et de protection
– Planification de la sécurité physique de base
– Mesures à prendre pour protéger des documents ou des papiers
– Armoires blindées, chambres fortes …
– Considérations générales d’usage des lieux ou armoires protégées
– Contrôle des personnes et planification de la sécurité
– Étude des risques naturels
109
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Aspects techniques
110
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Fonctionnalités
ARCHITECTURE
de
SECURITE
OSI
Concepts de base
111
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Présentation
• Architecture fonctionnelle permettant la mise en œuvre d'une POLITIQUE de
SECURITE
• 14 services de sécurités (5 groupes)
reposant sur
• 8 mécanismes de sécurité spécifiques
et
• 5 mécanismes communs de sécurité
• Mécanismes introduits dans certaines couches pour fournir les services
112
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Services de sécurité
• Authentification
– de l'entité homologue - de l'origine des données
• Contrôle d'accès
• Confidentialité des données
– en mode connexion - en mode sans connexion
– sélective par champ
– du flux de données
• Intégrité des données
– mode connexion - avec - sans - reprise
– mode sans connexion
– sélective par champ en mode - avec - sans - connexion
• Non-répudiation
– avec preuve de l'origine - avec preuve de la remise
113
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Mécanismes spécifiques de sécurité
• Chiffrement A
• Signature numérique B
• Contrôle d'accès C
• Intégrité des données D
• Échange d'authentification E
• Bourrage F
• Contrôle de routage G
• Notarisation H
114
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Mécanismes communs de sécurité
• Pas spécifique à un service
• Pas incorporé dans une couche spécifique
• Fonctionnalité de confiance
• Étiquettes de sécurité
• Détection d'événements
• Journal d'audit de sécurité
• Reprise de sécurité
115
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Mécanismes spécifiques et
Services de sécuritéServices Mécanismes
A B C D E F G H
Authentification de l'entité homologue X X X
Authentification de l'origine des données X X
Service de contrôle d'accès X
Confidentialité en mode connexion X X
Confidentialité en mode sans connexion X X
Confidentialité sélective par champ X
Confidentialité du flux de données X X X
Intégrité en mode connexion avec reprise X X
Intégrité en mode connexion sans reprise X X
Intégrité en mode connexion sélective par champ X X
Intégrité en mode sans connexion X X X
Intégrité en mode sans connexion sélective par champ X X X
Non-répudiation, origine X X
Non-répudiation, remise X X
116
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Services de sécurité et services de
communication
117
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Services Couches
1 2 3 4 5 6 7
Authentification de l'entité homologue X X X
Authentification de l'origine des données X X X
Service de contrôle d'accès X X X
Confidentialité en mode connexion X X X X X
Confidentialité en mode sans connexion X X X X
Confidentialité sélective par champ X
Confidentialité du flux de données X X X
Intégrité en mode connexion avec reprise X X
Intégrité en mode connexion sans reprise X X X
Intégrité en mode connexion sélective par champ X
Intégrité en mode sans connexion X X X
Intégrité en mode sans connexion sélective par champ X
Non-répudiation, origine X
Non-répudiation, remise X
Carte à puce
118
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Carte à puce• Usages
– stockages de secrets
– vérification de secrets (processeur)
• Types
– nom usuel mais ambigu
• ISO : ICC (Integrated Circuit Card)
– avec ou sans contact
– Standards :
• Européen (CEN 726)
– OSF DCE (RFC 57.0 et 57.1)
• industriels
– cartes bancaires (EMV)
– OpenCard Framework
– JavaCard
– PC/SC
• Terminaux
ROMOperat ing System
RAM
Temporary Operat ing Storage
EEPROM
Applicat ion Storage
Cryptographic
Coprocessor
I/ O System
CPU
Access Cont rol
Data Flow
Access Condit ions, Keys
Internal Bus System
ICC Chip
119
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Fonctionnalités de sécurité
• Authentification
– utilisation du mécanisme interne d’authentification
– envoi d ’un « challenge » (nombre aléatoire) à la puce
– génération et retour d’un cryptogramme à partir de ce challenge et d’une clé secrète
• Signature digitale
– authentification d’origine, non répudiation, intégrité de messages
– génération d ’une signature à partir de clé secrète et identificateur de carte
• Intégrité des données
– Pour le transfert d’information contenues sur la carte
– Codage par DES ou RSA
• Confidentialité des données
– chiffrement de mots de passe, de clés, de secrets courts ...
• Stockage sûr de données
– Carte à mémoire
120
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Sécurité de la carte à puce
• Vérification du détenteur de la carte
– comparaison d’une clé avec un secret contenu dans la carte
– carte invalidée après 3 essais infructueux
• éventuellement prévoir clé de déblocage
• Authentification mutuelle
– génération d ’un « challenge » (nombre aléatoire) présenté à l’extérieur
– transformation en cryptogramme à partir d’une clé secrète et envoi à la carte
– vérification et autorisation d’accès
• Point de fragilité : interface avec le terminal
– espionnage possible du bus pour capter mot de passe du possesseur
• Autres attaques
– ingénierie inverse destructive de la puce
– découverte du contenu de la mémoire par analyse différentielle
• carte soumise à un stress pour donner information erronée
121
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Sécurité individuelle
122
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Kerberos - DCE
123
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Kerberos: principe
• Tiers de confiance hiérarchique
– connait les clés utilisateur et Serveur
• pas de mot de passe transmis
• mot de passe utilisateur = clé de
chiffrement de clés
• relation de bout en bout
– utilisateur-serveur
– asymétrique
• problèmes
– Utilisation du DES
– différentes "incarnations"
– pas d'interface standardisée
– certaines faiblesses
Client
Serveur
Tiers
Serveur de clés
2
1
3
12
3
Nom client
3
réponse
3
demande
23
Nom client
124
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Protocole d'authentification Kerberos
• Utilisation d'une base de données sûre
– clients
– Services
• Protocole d'authentification
– 1: demande initiale d'authentification
– 2: paramètre d'authentification chiffré• enrégistrement chiffré par le mot de passe de
l'utilisateur
– 3: mot de passe pour déchiffer le ticket
– 4: Requête au service de Ticket
– 5: réception d'un Ticket de service chiffré
– 6: Envoi du Ticket de service et de paramètres au serveur
– 7: Contrôle du Ticket de service;
renvoi de l'heure chiffrée pour authentification
Serveur
d'Authentification
Kerberos
KAS
Serveur
de Tickets
d'Accès
TGS
Utilisateur
ClientServeur
Base de données
Kerberos
3
Mot de
Passe
12 4
5
6
7
125
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Cellule DCE
• Stations
• Serveurs
• Serveur de sécurité
– mot de passe en un seul endroit
– login : donne un ticket
• Serveur de temps
• Serveur de noms de cellule
– droits d'accès en un lieu unique
• Protocoles de sécurité inter-cellules
– login unique
– utilisation du RPC sécurisé
Serveur de noms Serveur de temps
Serveur de sécurité
126
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Authentification DCE : Schéma
simplifié• login DCE
– 1: demande de TGT
• login sans mot de passe
– 2: TGT et CK1 (chiffré par pwd)
• déchiffrement TGT et CK1 par pwd
– 1* : demande ticket pour SP
– 2*: Ticket pour SP et CK2
– 3: demande de PTGT
– 4: PTGT avec PAC et CK3
• Demande de service
– 5: demande de ticket pour un service
– 6: ticket du service et CK4
– 7: présentation du ticket
– 8: échange d'aléas
• TGT: Ticket-Granting Ticket
• PAC: certificat d'attribution de privilège
• CKi: temps i (timestamp)
serveur
d'authentification
serveur
de privilèges
serveur
de tickets d'accès
TGS
PS
AS
Client
Serveur
1
2
3
4
5
67
8
ticket
ticket+requête
127
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Sécurité collective
128
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Cloisonnement - coupe-feu
129
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Sécurité collective: Intranet
• Réseaux privés
– Isolés ou protégés du monde extérieur
– Coup-feu - Firewalls
• Renforcer le contrôle d’accès aux frontières
• Mise en œuvre d’une politique de sécurité
– doit être très bien définie
– Utilisateurs: accès juste nécessaires
– Equilibre: besoins/restrictions
• Restreindre accès DEPUIS extérieur
– à ensemble ou partie des systèmes
– à certains services
• Email, Web, Ftp, ....
• Restreindre accès VERS l’extérieur
– Eviter sortie d’information après intrusion
Réseau
non
sécurisé
Coupe-feu
Réseau
sécurisé
Pas d’autre accès !
(maintenance, direct ...)
130
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Présentation• Système ou ensemble de systèmes qui renforcent les
contrôles d'accès entre deux réseaux
– grande variété
– deux mécanismes
• un qui bloque le trafic
• l'autre qui permet le trafic
• Bien définir la POLITIQUE de contrôle d'accès
– restreindre les accès, depuis l'extérieur
• à l'ensemble du réseau
• à certains systèmes
• à certains services
– Web
– ftp
– telnet, rlogin, finger, etc....
– restreindre les services vers l'extérieur
Réseau
sécuriséInternet
Filtrage des paquets
131
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Contre quoi se protège-t-on?
• Peut protèger contre les accès non-authentifiés du monde extérieur
• "point d'étranglement" où la sécurité et l'audit peuvent être imposés
• Ne protège pas contre
– les attaques internes
– les attaques qui ne passent pas par lui ...
– les virus
• Deux types : + ou - de transparence pour l'usager
– niveau Réseau : transparent
• filtrage des paquets IP dans un routeur d'entrée
– niveau Application : plutôt opaque ....
• utilisation d'un proxy par type d'application à protéger (Ftp, telnet, ...)
132
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Types de coupe-feu
• Filtrage des paquets
– sur les routeurs
– Par adresse
– Par port : Application
– Translation d ’adresses
• Passerelle à double attachement
Réseau
sécuriséInternet
Filtrage des paquets
Réseau
sécuriséInternet
toutes applications
par Proxyserv. d’information
Serv. proxy
(éventuellement)
filtrage de
paquets
133
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Types de coupe-feu (suite)
• Hôte écran
• Sous-réseau
écran
Réseau
sécuriséInternet
serv. d’informationServ. proxy
filtrage de
paquets
trafic direct permis
accès aux services par PROXY
le PROXY donne accès aux
services
Réseau
sécuriséInternet
Serveur d’informationServeur
PROXY
filtrage de
paquetsfiltrage de
paquets
Serveur
trafic direct permis
accès par PROXY
accès aux services
134
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Réseaux virtuels privés: Tunnels
• Protocole de niveau 3/OSI (réseau)
sécurisé
– ex: IPv6 avec options de sécurité
• Filtrage des adresses
– domaines approuvés
• Routes sécurisées
– choix des routeurs traversés
• Données chiffrées
– si autorisé
ou embrouillées
135
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Serveurs de noms
• En pratique
– un serveur de noms (DNS) public hors coupe-feu
– un serveur de noms interne
• pour usager interne
– résolution directe pour accès interne
– relais par serveur externe pour le monde externe
• pour usager externe
– résolution normale pour monde externe
– résolution filtrée, éventuellement avec translation, pour mode interne
– problème éventuel avec serveurs ftp anonymes qui veulent connaître leur
correspondant ....
136
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
FTP, gopher, archie
• utilisation d'un proxy
– restriction sur les "ports" accessibles
• modifier les clients FTP internes ...
• inhiber FTP et ne permettre que accès FTP par le Web
– problème pour exporter des fichiers ....
• option "PASV"
– serveur FTP distant doit permettre au client d'initier la connexion
• Gopher, Archie
– accès par le Web seulement (proxy Web)
137
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Analyseur de sécurité
138
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Contrôle d'accès "Intra-domaine"
• Invisible
– fonctionnement réseau
non modifié
• Coupure de connexion
– 2: Observation du
message de l'intrus par
l'analyseur
– 5: Fermeture en se
faisant passer pour
l'intrus
– 6: Fermeture en se
faisant passer pour le
serveur
Serveur
de fichiers
Analyseur
de sécurité
Intrus
1
1
2
5
6
3
4
Fichier
de configuration
Domaine sécurisé
139
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Intégrité des données "inter-domaines"
• 3: Analyseurs créent et stockent les sceaux pour les messages
• 4: Analyseurs retrouvent les sceaux pour les messages
• 5: Authentification mutuelle
• 6: Comparaison des sceaux pour un message: les messages sont signés
– analyseurs peuvent aussi servir à la non-répudiation (s'ils sont "notaires")
Analyseur
de sécurité
11
2
5
6
3
4
Disque de
stockage
Domaine sécurisé
Réseaux externes
Domaine sécurisé
11
3
42
Disque de
stockage
Analyseur
de sécurité
Station A Station B
140
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Sécurisation de l ’Internet
141
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Présentation
• Sujet très à la mode ...
– Besoin réel et urgent
– Internet pas conçu pour être sûr (voir loi l’interdisant ...)
• Exposé basé sur
– Documentation Microsoft, Verisign, HP ....
• Microsoft Internet Security Framework
• Projet SET: Secure Electronic Transactions
– Projet de RFCs de IETF
• Problème en pleine évolution depuis début 1996 ?
– Communications sécurisées sur Internet
– Commerce International
– Evolution de la juridiction aux USA
• voir procès Zimmerman sur PGP et nouveau décret «Clinton»
142
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Les besoins
• Pour le Client
– Secret (intimité), Intégrité, Authentification, Transactions sûres
– Facteur d’échelle (Scalability)
– Administrabilité
– Interopérabilité
– Intégration de systèmes existants
• Pour l’industrie
– Autorité de Certification de confiance (pour authentification, etc.)
– Services de Révocation
– Support d’estampilles temporelles, de Notarisation
– Fiabilité
– Convivialité
– Standards
143
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Sûreté (individuelle) sur les réseaux
ouverts : Internet• Services nécessaires
– Authentification des utilisateurs et des
serveurs
– Authentification (d’origine)des données
– Intégrité des données
– Non-répudiation des données
– Confidentialité des données
• si autorisée par législation
• Moyens
– Clès d’authentification
– Clès d’intégrité
– Signature digitale
– Chiffrement
• des clès et signatures
• des données (optionnel)
Protection des
données transmises
Authentification
Source ET Destination
Application principale:
Commerce éléctronique
Non-Répudiation
144
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Partenariats ....– Microsoft, Netscape
– RSA, Spyrus, BBN, Cylink, etc.
– Verisign, GTE, Verifone, VISA, Mastercard, AMEX, etc...
– Bull, HP, Schlumberger, Siemens
– DEC, Crel, Wall Data, Attachmate, SAP
– etc ....
• Sur les standards
– IETF, WWW Consortium (W3C)
– Association de Netscape et Microsoft pour TLS..
• TLS: Transport Layer Secure
• SSL (Secure Socket Layer) d’origine Netscape
• PCT (Private Communication Technology) de Microsoft
– Signature digitale: VERISIGN, HP
– Carte à puce: Bull, HP, Siemens, Schlumberger
– SET: Visa, Mastercard, American Express, IBM, Netscape, Microsoft, ....
– Jepi: Joint Electronic Payement Initiative
145
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Sous-ensembles• Applications: SET, JEPI
• Protocoles d’application– S-HTTP
– PFX (Personal inFormation eXchange)
– Portefeuille Sécurisé
• Protocoles de Transport sécurisés– Protocole PCT (Private Communication Technology)
– SSL: Secure Socket Layer
– TLS: Transport Layer Secure SSL+ PCT• Utilisation: FTP sur SSL
• Protocoles de réseaux sécurisé– IPSec
– Accès au réseau - liaisons entre routeurs (PAP, CHAP, EAP)
• Signature digitale - Certificats - Authentification– Authenticode (Authentification des éditeurs de logiciel)
– DigitalID
• Chiffrement
146
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Signature digitale
• Mécanisme de base
• permet:
– Authentification d’origine
– Intégrité des données
• Repose sur chiffrement à
clé publique
et Fonction de Hachage
– donne une empreinte
• problème: durée de validité
– peut être révoquée
– validité à TRES long
terme
Document
Hachage
Empreinte
Clé Privée
Signature
Signature
Document
Signature
Envoi Document signé
Document
SignatureHachage
Empreinte
Clé Publique
Comparaison des résumés
Réception
147
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Signature Digitale (suite)
• Prouver identité et droit d’accès à l’Information
• Délivrée par une Autorité de Certification (CA)
– Signée par la clé PRIVEE de cette autorité
• Contient:
– Clé publique du propriétaire
– Nom du propriétaire
– Date d’expiration de la clé publique
– Nom du distributeur
– Numéro de série de la signature digitale
– Signature digitale du Distributeur
• Format X509 (Annuaire)
– Détails Standards PKCS et PEM
148
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Signature Digitale (suite)• Usages
– Transactions électroniques:
• E-Mail, Commerce, Groupware, Transfert de fonds
• Serveur commercial Netscape requiert une signature digitale
– Authentification de l’opérateur «centre commercial»
– contenu fourni par le vendeur
– Pour avoir confiance avant de communiquer numéro de carte bancaire
– Centres commerciaux virtuels
– Télébanques
– Services électroniques
• Chiffement insuffisant
– Pour prouver l’identité de celui qui envoie les informations chiffrées
– Serveur sûr doit aussi avoir sa signature pour assurer l’utilisateur que le serveur utilisé est bien celui de l’organisation qu’il croit....
– Degré de sécurité supérieur à signature manuscrite ...
149
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Validité des signatures et Estampilles
temporelles
• Problème de la durée de validité des signatures digitales
– DigitalID a une durée de vie limitée
– Document signé peut avoir durée de vie très longue
– Estampille temporelle prouve la validité de la signature après ....
– Estampille ne doit pas pouvoir être contrefaite même à très long terme
• Horodatage du document et chiffrement
– clé de chiffrement fournie par serveur d’estampille de confiance
• DTS: digital time-stamping Service
– On envoie résumé (hashing) du document signé à DTS
– DTS retourne Résumé signé HORODATE et Signé par lui (DTS)
– DTS ne peut connaître le document
– Le document et son estampille prouve la date de dépôt du document
• par exemple pour prouver antériorité
150
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Certificats d’authentification
• Authentification
par Tiers de Confiance
• utilise la signature
numérique
– de l’utilisateur
– du tiers de confiance
• problème: durée de vie
– signature ....private
Certificate ties a
name or identity to
public keys
The authenticity of the certificate
is guaranteed by the digital
signature generated using the
CA’s private key.
Certificate Validation
pu
bli
c
Name: “Jane Doe”
Expires: 6/18/96
Key-Exchange Key:
Signed: CA’s Signature
Serial #: 29483756
Signature Key:
pu
bli
c
Other Data: 10236283025273
Other data
151
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Authentification par Certificats
• Authentification des clients auprès des serveurs Web
• Utilisateurs obtiennent certificats auprès de CA
– Certificate Authority
• Le «butineur» client présente certificat à serveur Web
– Vérification de l’identité de l’usager
– Contrôle des droits d’accès
– Personnalisation des clients des serveurs
• certificat peut contenir des informations spécifiques
• Avec signature digitale plus de mots de passe à connaître pour chaque site Web ....
– Mots de passe ne circulent plus sur le réseau et ne peuvent être interceptés
– Mot de passe local, sur machine du client
152
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Acquisition de certificat
–Générer un paire de clé
• sur client et Serveur
–Demande d’inscription
• Enrollment
– Client ID
– Issuer ID
– Signature
–Serveur verifie et donne certificat en fonction de la politique choisie
• Extensions
• Clé publique
•Exemple d’autorité
–Verisign
• site Web
Private Key
Public Key
Client Cert Server
Private Key
Public Key
Policy
Extensions
Public Key
Issuer ID
Client ID
Signature
153
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Protocoles de sécurité
154
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Services Réseau et Transport
155
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
IPSec
• Fournir des fonctions de sécurité interopérables de haute qualité– Options dans IPv6 ou IPv4
– Accès au réseau Inet
• Services :– authentification
– intégrité
– intimité (privacy) : optionnel
– protection contre la possibilité de « rejouer » : optionnel
• Deux types de paquets– ESP : Encaspulating Security Payload
– AH : Authentification Header
• Deux modes– transport : sécurisation des paquets IP existants
– tunnel : encapsulation de paquets IP dans d’autres paquets IP (TCP, UDP)
• transmis de bout en bout d’un tunnel (entre routeurs, passerelles)
• format IPSec
156
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
IPSec : Associations de sécurité
• Connexion simplex
– qui fournit des moyens pour sécuriser le trafic qu’elle transporte
– identifiée par un triplet :
• Index des paramètres de sécurité
• adresse destination
• identificateur de protocole de sécurité (AH ou ESP)
• « Liasse » (bundle) de SA :
– séquence de SA pour satisfaire la politique de sécurité
• par exemple entre un terminal mobile et une passerelle et entre des passerelles
• Passerelle de sécurité
– permet d ’atteindre de manière sûre les destinataires souhaités
– doit pouvoir être localisée, authentifiée et vérifiée ses autorisation à représenter ceux-ci
• Base de données d’associations de sécurité
– règles à suivre par tout le trafic (à sécuriser ou non..)
• si aucune règle ne convient : paquet détruit !
– Paramètres associés à chaque association de sécurité157
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
ISAKMP : protocole d ’association de
sécurité et de gestion de clés
• Support pour l’établissement d’association de sécurité
– négociation
– canal de communication est une association de sécurité bi-directionnelle
• Établissement d’association de sécurité
– un simple bloc de données (payload)
• domaine d ’interprétation :
– formats, types d ’échanges, conventions de nommage
• Situation
– ensemble d ’informations pour déterminer les services demandés
– suivi ede au moins bloc de «propositions»
• capacités de l ’initiateur (protocoles, mécanismes)
– suivie de au moins un bloc de «transformation» par bloc de «proposition»
• Protocole(s) pour négocier les services et mécanismes
158
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Protocole de réseaux: IPv6
• Introduit de manière
– plus puissante
– plus ...les mécanismes facultatifs de IPV4
• En-têtes optionnelles
– Authentification-Intégrité• IP Authentication Header
– empreinte MD5 (Message Digest)
– Confidentialité• IP ESP
– Encapsulating Security Payload
– placée à partir de zône à protéger
• Mode Tunnel
– différents codes: DES, 3-DES, CBC..
• authentification possible
Header IPv6
Next Header
=
Routage
Header Routage
Next Header
=
Authentication
Header Authentication
Next Header
=
Data
Header TCP
+
DATA
Header IPv6
Next Header
=
ESP
Header ESP
Next Header
=
Authentication
Header Authentication
Next Header
=
Fragment
Header ....
159
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Protocoles IPSec
• AH : Authentification Header
– Intégrité et authentification d’origine des paquets IP
– prochain SPI (index de paramètres de sécurité)
– Numéro de séquence (SN, compteur 32 bits) :anti «re-joué»
– données d’authentification
– Contrôle d’intégrité (ICV : Integrity check Value)
• Calculé avec champ AD à zéro (HMAC/MD5 ou SHA-1)
• ESP : Encapsulating Security Payload
– Confidentialité, intégrité, authentification d’origine, anti-«rejoué»
– mécanismes similaires à AH
– Encapsulation IP dans IP
• mode « transport » : juste des données de transport
• mode tunnel : tout le paquet
• remplissage si nécessaire (taille aléatoire…)
– chiffrement du paquet encapsulé
160
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Protocole d’accès sécurisé : PPP
• Transmettre des datagrammes sur une liaison série point à
point
– paquets IP
– paquets IPX, Appeltalk, …
• Utilisé (entre autres) pour accéder à distance à Internet
• Authentification (optionnel)
– PAP: Password Authentication
• Émission répétitive, par le distant, du couple login/mot de
passe (en clair) jusqu’à réception d’un acquittement
– CHAP : Challenge Handshake Authentication Protocol
• Contrôle et vérifie périodiquement l’identité du distant
• Envoi d’un « Challenge »(nombre aléatoire), retour d’une
réponse calculée selon mot de passe et acquittement ou rejet
– EAP : Extensible Authentication Protocol
• supporte des mécanismes multiples
Lien mort
UP
Down
Etablissement
de Lien
Authentification
(optionnel)
Ouverture
Echec
Echec
Fermeture
Passe
Configuration
Réseau
Transfert
Rupture de
Lien
161
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
CHAP : Challenge Handshake Authentication Protocol
• RFC1994 : transmission d’un «challenge» avec réponse et acquittement
– secret partagé mais non transmis
• envoi d’un nombre aléatoire
• hachage avec mot de passe et envoi empreinte (MD5)
• contrôle et acquittement
• protection contre attaque de type «playback»
• répétition limite les temps pour attaques simples
• Inconvénient : mot de passe disponible en «plein texte»
• Format des paquets
– protocole CHAP identifié par «C223» dans PPP
– type : Challenge, Réponse, Succès, Echec
– Identificateur
– Longueur
– Valeur selon code
• Challenge/Réponse :taille de la valeur, valeur, nom
• acquittements : message162
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
EAP : Extensible Authentication
Protocol• Supporte, pour PPP, des mécanismes d’authentification multiples
• Inconvénient : modification de la couche LCP de PPP nécessaire– pour permettre la négociation de mécanismes durant l’établissement
• Échanges de base semblables à CHAP– transmission d’un «challenge» avec réponse et acquittement
– Code «C227» pour PPP
– Types dans Requêtes/Réponses
• Identité (3 éssais)
• Notification : message affichable chez utilisateur
• Nack (seulement dans les réponses) : type non acceptable
• Challenge MD5 (comme CHAP)
• Mot de passe Une-fois (one-time, RFC1938)– message affichable avec Challenge OTP
• Carte à jeton générique– requête : message texte
– réponse : information de Token Card
163
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Protocoles de Transport
• Demain: TLS (Transport Layer Structure)
basé sur
– SSL (Socket Secure Layer)
• Netscape, disponible sur Web
– PCT (Private Communication Technology)
• Microsoft
• Au dessus de la couche Transport (TCP)
• Échange de
– certificats d’authentification
– paramètres cryptographiques
– valeurs aléatoires
• Chiffrement (optionnel) des données
Applications
TCP
encapsulation
Protole de sécurité
ex: Handshake
164
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Protocoles de Transport: SSL
• Objectif: Sécuriser les communications sur Internet– Applications Client-Serveur
• Eviter espionnage, falsification, contrefaçon
– eavesdropping, tampering, forgery– Transparent aux protocoles d’Application
– plusieurs Sessions en parallèle possibles
• Deux sous-couches– Supporté par Transport fiable: TCP
– Sous-couche SSL Record
• Encapsulation de protocoles variés
– Sous-couche supérieure
• par exemple SSL Handshake Protocol
• Fournit des connections sécurisées– Connexion privée: Transfert de données chiffrées par clé privée (DES, RC4)
– Authentification réciproque des entités paires par chiffrement à clé publique (RSA, DSS)
– Connexion fiable par clé d’Intégrité (Hashing SHA, MD5, etc)
165
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
SSL (suite)
• Langage pour décrire des messages
– sous-ensemble de C (même idée que XDR...)
• Protocole SSL
– Pour chaque sous-couche
• champs: longueur, description, contenu
– SSL
• segmente
• compresse (optionnel)
• applique un Code d’Authentification du Message (MAC)
– SHA, MD5
– Message secret (maître) partagé à 48 octets (384 bits < 512 bits ...)
• Chiffre
– Clés de chiffrement «en volume» (d’après clé maître)
• Transmet
166
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
SSL (suite): Protocole de Handshake
• Etat de session initialisé par ce protocole– Identificateur de session (fournit par serveur)
– Paire de certificats (X509) (peut être null...)
– Méthode de compression
– Spécifications de chiffrement
• Algorithme de chiffrement (en volume) des données: null, DES ...
• Algorithme de chiffrement d’authentification: MD5, SHA
• Attributs cryptographiques (hashing , ...)
– Secret maître (48 octets)
– Finissable (is resumable) pour ouvrir nouvelle connexion dans session
• Etat de connexion– Nombres aléatoires client et serveur
– Secrets MAC serveur et client
– Clés d’écriture (de données ) serveur et client
– Vecteur d’initialisation (bloc final d’un enregistrement sert à chiffrer le suivant)
– Séquencement
167
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Protoles de Transport: PCT • Protocole «Private Communication Technology»
• Protocole de niveau Transport– utilisable par HTTP, FTP, Telnet, etc.
– Toutes les messages sont des enregistrements de taille variable, avec une En-Tête
• données et acquittements, erreurs, gestion de clés, etc.
– Echanges groupés en connexions et Connexions groupées en Sessions
– Supporté par protocole deTransport fiable : TCP
• datagrammes possibles pour données isolées
• Pour chaque connexion– phase de «Handshake»
• Négociation de clés de Session symétrique
• Demande d’authentification basée sur échange de clés publiques
– on peut utiliser clés privées partagées à l’avance
– Phase de Transfert
• (Pré)Chiffrement des données + Intégrité
168
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Transport Layer Secure: TLS
• Strictement basé sur SSL
– extensions issue de PCT
• pour Interopérabilité, Extensibilité, Performances
• Clarification de SSL
169
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
TLS: Protocole de Handshake• Buts
– Échange de messages «Hello» pour négocier
• algorithmes, valeurs aléatoire, contrôles
– Échange des paramètres cryptographiques
– Échange des certificats et informations cryptographiques
• pour Authentification réciproque (ou mono sens)
– Génération du secret maître
• à partir du secret «pré-maître» et de valeurs aléatoires
– Fournir les paramètres de sécurité à la sous-couche basse (Enregistrement)
– Permettre au Client et au Serveur de vérifier la cohérence des paramètres de sécurité
• Échanges– Voir ci-dessous
– Certains messages sont optionnels
– Protocoles de changement de mode de chiffrement, alertes si pb, etc. sont contextuels
170
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
TLS: Protocole de Handshake (suite)
• CLIENT SERVEUR
ClientHello --------> ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
171
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Services Application
172
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Services Application
• Certains services sont à éliminer (de toute façon...)
• Services classiques sécurisés par TLS ou SSL (ou PGP ...) ou Tunnels
– FTP, Telnet, E-Mail
• Nouvelles versions de services
– S-HTTP pour le Web
• Nouveaux services
– Porte-feuille électronique (Wallet - Microsoft)
– Échange de données personnelles (PFX - Microsoft)
• Transporter le porte-feuille électronique ...
• Services spécifiques utilisant les services Applications existants
173
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
PFX: Personal inFormation eXchange
• Problème: accès à des serveurs sécurisés multiples
• Identité d’un utilisateur sur le Net:
– Clés privées,Certificats, Certificats des partenaires récents, secrets assortis ...
– Fournir une syntaxe de transfert unique indépendante de la plate-forme
• Deux ou trois mondes:
– en ligne («Internet Toaster»)
• pas de disque dur, de disquette, de carte à puce (NC...)
• secrets doivent être transportés sur le Net
– Hors ligne
• si disquettes: transport des secrets sur disquette
• protection physique des secrets
• réduit la difficulté de chiffrement
– Troisième monde: Moyens annexes
• cartes à puce pour clés
• Cartes mémoire (fat card..) pour données privées174
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
PFX: Personal inFormation eXchange
(suite)• Principe
– Transport de clé PFX du collecteur à source
– Création , chiffrement et signature d’ «un «sac» contenant «V»
• V : clé privée authentifiée
• V
– chiffrée pour collecteur par sa clé publique PFX
– signée par clé de la source pour intégrité
– Transport du «sac PFX» vers le collecteur
– vérification de l’intégrité et déchiffrement du «sac PFX» par le collecteur
– installation de «V» sur le collecteur
• Modes– Système à clés publiques (secret et/ou intégrité)
– Système à mot de passe (secret et/ou intégrité)
• Génération de clés privées sur des plate-forme multiples
175
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Portefeuille Electronique
• Pour contenir de manière sûre toutes les références
– Certificats
– Numéro de cartes à puce
– Informations privées, etc.
• Informations pas accessibles directement
– accès pour des opérations spécifiques
– permission d’accès par utilisateur
• Sur un seul système (à la fois)
– Système sur lequel travaille l’utilisateur
– Doit pouvoir se déplacer avec utilisateur
• Utilisation de PFX (Personal inFormation eXchange)
176
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Applications
• Développées pour le commerce international
– Sécurisation des commandes, des moyens de paiement
• Applications spécifiques
– GcTech, CyberCash, etc
• SET (Visa, Mastercard, ---- Microsoft, ....)
– Protocole de payement - Pas de protocole «réseau» spécifique
• essaie de résoudre l’hétérogénéité...
– Banque est de fait un Tiers de Confiance
– délivre des certificats de paiement
• JEPI: Joint Electronic Payment Initiative (W3C)
– Récent (Fin 1996-1997)
– Mécanismes pour négocier les moyens de paiement
– Complémentaire des précédents
177
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
SET: Secure Electronic Transactions
• Système de paiement développé par Visa et Mastercard
– Valable pour toute carte bancaire (ex: American Express)
– version finale fin 1996 ....délivrée (free) par Visa et Mastercard
– Basé sur la délivrance de Certificats
• Certificat délivré par organisme carte bancaire
• envoyé par le client WEB de l’acheteur au serveur WEB du vendeur
• Celui-ci peut tester validité auprès organisme bancaire
178
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Joint Electronic Payment Initiative : JEPI
• JEPI: Joint Electronic Payment Initiative
(W3C)
– Récent (Fin 1996-1997)
– Mécanismes pour négocier les moyens de paiement
• SET, Gctech, CyberCash, etc.
– Complément à Http:
• UPP: Préambule
• PEP: Extensions Http
SET GCTech
UPP
PEP logic
Client Http
Serveur Http
UPP
PEP logic
SET GCTech
Wallet
Wallet
JEPI
179
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Conclusion: les approches• Normative
– ISO, Organisations (banques)
– IETF (Internet)
définit des concepts, des fonctions, des mécanismes
• via les systèmes informatiques :– Kerberos,
– OSF/DCE
– WindowsNT, Netware, ...
• par (sous-) réseau protégé et validé:– Intranets
– Réseaux virtuels
• par protection des communications sur réseaux ouverts– Groupes fermés d’usager (X25)
– Nouveaux développement pour Internet
Toutes reposent sur des fonctions et mécanismes communs
180
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Infrastructures de Gestion de Clés
publiques
• IGC ou PKI : Public Key Infrastructure
181
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Rôle• Préserver l’intégrité des certificats de clés publiques
• Protéger la confidentialité des secrets gérés
– intégrité et authentification d’origine d’un document : signature numérique
– Confidentialité : échanges de clés privées ou clés publiques
• Fragilité :
– Confiance accordée au couple « clé publique - propriétaire de cette clé »
– Lien établi par :
• Autorité de certification
• se porte garant des informations contenues dans le certificat
• signature par sa clé privée
• Fonctions incidentes :
– Enregistrement des utilisateurs
– Publication de certificats
182
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Clés à gérer• Confidentialité
– messages longs : système cryptographique à clé secrète
• Échange sûr de clés
– système cryptographique à clé publique
– messages très courts : système cryptographique à clé publique
• Au moins deux ou trois clés publiques
– Signature
• Intégrité, authentification, non répudiation
• doit être certifiée
– Échange de clés secrètes
• perte ne permet pas de lire les données reçues ou stockées
• Utilité d’un système de recouvrement de clés
– Confidentialité des messages courts
• exemple : données cartes bancaires ….
• Éventuellement certifiée (selon applications)
183
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Certificats
• Permettent de diffuser des clés publiques certifiées
– Tiers de confiance
• privé : accord de type commercial
• public : certification légale
• Clé publique de l’utilisateur
– récupérable auprès d’un tiers
• besoin de ne connaître que lui …
– certifiée par signature de ce tiers
• besoin de ne posséder, de manière sûre, que sa clé publique
• Problèmes
– enregistrement des clés publiques des utilisateurs
– diffusion des certificats de clés publiques ou de signature
– recouvrement de clés publiques
184
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Autorités• Autorité de Certification
– se porte garant des informations délivrées dans les certificats
– révoque, si nécessaire, les certificats (divulgation de clé)
– met à la disposition des usagers les certificats
• directement ou indirectement
• Autorité d’Enregistrement
– point de contact entre utilisateur et autorité de certification
– reçoit la demande de certification
– vérifie les données propres au demandeur : VALIDATION
• identité, possession de la clé privée correspondante
– crée le certificat et le transmet pour signature à l ’autorité de certification
• Service de publication
– diffuse les certificats pour une ou plusieurs autorités de certification
• annuaire X509
– gère la liste des certificats révoqués
185
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Enregistrement
• Informations propres au demandeur
– selon POLITIQUE DE CERTIFICATION
– preuve de l’identité
– preuve de la possession de la clé privée
– preuve de la fonction occupée par le demandeur ...
– autorisation de demande de certificat ….
• Enregistrement seulement après vérifications
– validation des demandeurs selon les Déclarations des pratiques de Certification
• CPS : Certification Practice Statement
• Déclaration par Autorité de Certification ou Autorité légale
• plus détaillé que documents de politique de certification
• Transmission à l’autorité de certification des seules informations nécessaires
186
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Publication et services annexes
• Publication
– pour une communauté d’utilisateurs
– une ou plusieurs autorités de certification
– différents types :
• annuaire(s)
• serveur Web
• papier, disquette, etc.
– doit être à jour, accessible, disponible
– Diffuse aussi les listes de révocation
• pour les certificats qui ne sont plus « de confiance »
• Services annexes
– Recouvrement de clé (pour un utilisateur)
– Génération / Renouvellement de bi-clés
– Délivrance de datation de confiance
187
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
IGC
• Fonctions de base :
– enregistrement, identification, authentification des utilisateurs
– génération, révocation, publication, archivage des certificats
• Opérations internes
– imputabilité, identification et authentification des exploitants
• Services annexes
– génération ou mise à jour (remplacement) de bi-clés
– recouvrement de clés
– délivrance de datation de confiance
• Composée de :
– une autorité de Certification
– plusieurs autorités d’Enregistrement
– un service de publication
188
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Indicateurs de confiance• Politique de certification
– description en voie de normalisation à l’IETF (groupe PKIX)• Déclaration relative aux procédures de certification
– Énonce les pratiques utilisées par l ’IGC
– Document décrivant les modalités de fonctionnement
• types de documents à fournir à l’autorité d’enregistrement
• procédures de révocation (qui contacter, comment …)
• etc ...
• Conformité à des documents formalisant le niveau de sécurité
– voir : Critères Communs d’Évaluation (Profil de protection)
• Régime légal de l’infrastructure
– Service officiel (réflexion en cours …)
– Schéma d’accréditation
• par exemple : Organismes bancaires
• Certification croisée
189
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Modèle d ’IGC X509 et annuaire X500• Problème :Multiplicité des autorités de certification
• trouver l ’autorité de certification de son
correspondant
• Récupérer auprès de son autorité, le certificat de
l ’autorité du correspondant
– RECURSIF : Chemin de certification
• Certification croisée
• Annuaire X500
– basé sur des objets : pays, organisation, unité
organisationnelle, personne…
– attributs : décrivent objet (au moins Nom)
• ex: personne : nom usuel, adresse E-mail, ….
– Chaque entrée repérée par son DN : distinguished name
• arborescence : OID
• nom basé sur même arbre que objets d ’administration
itu-t
0Iso1
join-Iso-itu-t
2
Country16
France208
Organisat ion
10
XXXXX9
algorithmes5 3
polit iques
4
La polit ique
6
190
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Modèle de certificat X509• Certificat de base
– version du format
– Numéro de série
– signature de l’autorité de certification (CA)
– Nom X500 de l’autorité de certification
– Période de validité
– Nom X500 du sujet : personne, entité, organisation, …
– Information sur la clé publique
• valeur de la clé publique
• identification de l’algorithme utilisable
• Extensions– à la demande d ’organismes : banques, ITU, SET
– 3 champs : type, Criticité, valeur
– Exemples:
• Extension d’Identificateur de clé d ’autorité de certification
• Extension d’Identificateur de clé d ’autorité de certification
• Extension d’usage de la clé
• Extension de période d ’usage de la clé
191
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Échanges d ’information entre entités
Entité
terminale
Autorité
d'Enregistrement
Autorité de
Certification
Autorité de
Certification 2
Entrepôt
de
Cert ificats
et de
listes de
révocation
publicat ion de liste de révocat ion
Utilisateurs de l'IGC
Entités de l'IGC
publicat ion de cert ificatinit ialisat ion
hors-bande
a
a
a
b
b
b
cd
ef
g
g
g
h
cross
cert ificat ion
publicat ion
hors-bande
192
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Protocole de gestion des certificats
X509 : CMP• Nécessaire pour supporter les interactions en ligne avec IGC
• Définition d’extensions
• Opérations
– (Établissement d’une nouvelle CA)
– Initialisation d’une entité terminale
• importation de la clé publique de la CA et de informations
– Certification
• Enregistrement initial/Certification
• mise à jour des clés
• mise à jour des clés de la CA
• mise à jour des certificats
• demande de certification croisée
– Révocation de clés
– Recouvrement de clés
• Schémas : authentifié de base ou centralisé (optionnel)
CA/RA Utilisateur
Initialisation
Hors bande
Demande de certification
Réponse de certification
Message de confirmation
193
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Protocole d’État en Ligne des certificats
X509 : OCSP• vérifier la validité
– sans utiliser les listes de révocation (CRL)
• problème de mise à jour, disponibilité des listes
– Requête
• version du protocole, demande de service
• identificateur du certificat cible, extensions
– Réponse
• version de protocole, nom du répondeur
• réponses pour chaque certificat
– identificateur du certificat cible
– valeur de l ’état du certificat
– intervalle de validité de la réponse
» bon, révoqué, inconnu
– extensions optionnelles
– signature de l’autorité de certification
• extensions
• identificateur de l’algorithme de signature
194
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Protocole d’estampille temporelle : TSP
• Pour communiquer avec les autorités de datation (TSA)
• Buts:
– vérifier qu ’un certificat a été émis avant révocation
– indiquer un temps de dépôt si date limite est critique
– indiquer la date/heure d ’une transaction pour log
• Propriétés
– source de temps de confiance
– ne pas inclure d’identification du demandeur
– estampiller une « empreinte » (hashing)
– signature de chaque estampille
– récépissé signé au demandeur
195
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Évaluation de la sécurité
196
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Systèmes de référence
• TCSec (Orange book)
– dès 1985 environ
– à la demande du DoD
– Définit des niveaux de sécurité : D à A
• ITSec
– vers 1990, communauté européenne
– pour les problèmes commerciaux , les banques, …
– système plus avancé : 10 classes
7 critères de corrections et 5 critères d’assurance
• Critères communs
– définis à partir de 1996 par 6 organismes nationaux
– autre approche plus réaliste
notion de profil de protection
197
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
"Orange book" (1)
• Basé essentiellement sur la confidentialité
• Besoins fondamentaux
– Politique de sécurité
– Marquage:
étiquettes de contrôle d'accès associées aux objets
– Identification:
des usagers individuellement
– Imputabilité:
garder les traces sélectives des audits pour retrouver les responsables
– Assurance:
mécanismes hard/soft évalués indépendamment
– Protection continue
198
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
"Orange book" (2): Classes de critères• D: Protection minimale• C1: Protection de sécurité discrétionnaire
– Séparation des usagers et et des données
– limitation d'accès sur une base individuelle
• C2: Protection par contrôle d'accès– Login
– Audit des événements de sécurité
– Isolation des ressources
• B1: Protection de sécurité étiqueté– Étiquetage des données
– Contrôle d'accès obligatoires sur des sujets et des objets nommés
• B2: Protection structurée– Relativement résistant à la pénétration
• B3: Domaines de sécurité– Haute résistance à la pénétration
– Administrateur de sécurité requis
• A1: Conception vérifiée– Comme B3 mais vérifications
199
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
"Orange book" (3) : Table d'évaluation
des critères
pas de demande
pas de demande additionnelle
demande nouvelle ou renforcée
A1B3B2B1C2C1
Politique de sécuritéImputabilité
Assurance Documentation
Contrôle d'accès discrétionnaireRéutilisation des objets
EtiquettesIntégrité de l'étiquettage
Exportation d'informations étiquettées
Exportation vers des équipementsmultiniveaux
Sortie lisible des étiquettes
Contrôle d'accès obligatoire
Etiquettage des sujetsEtiquettage des appareils
Identification et AuthentificationAudit
Chemins de confiance
Architecture système
Test de la sécuritéIntégrité du système
Spécification et vérification de la conception
Analyse des canaux cachés
Gestion de confiance des facilités
Gestion de la configuration
Recouvrement de confiance
Distribution de confiance
Guide des usagers des mesures de sécuritéManuel des facilités de confiance
Documentation des tests
Documentation de la conception
200
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Standard européen :ITSECInformation Technology Security Evaluation Criteria
• Cible d'évaluation : TOE (Target Of Evaluation)
– Produit ou système
– Cible de sécurité associée à TOE
– Niveau visé
– Fonctionnalité de la TOE
Objectifs de sécurité
Fonctions de sécurité : 8 titres
– Identification et authentification$ Réutilisation d'objets
– Contrôle d'accès $ Fidélité
– Imputabilité $Continuité de service
– Audit $Echange de données
mécanismes de sécurité
– Assurance
critères de correction : E0 à E6
– vérifier spécification et réalisation de la fonctionnalité visée
critères d'efficacité
– 10 classes: F/C1+E2 = C1, F/C2+E2=C2, F/B1+E3=B1, F/B2+E4=B2, F/B3+E5=B3,
F/B3+E6=A1 201
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Critères communs
• Regroupement de 6 organismes autour d’un projet commun : Common Criteria
• Différents aspects
– Exigences fonctionnelles
– Exigences d’assurance
– Profils de protection (PP)
définis à partir d’un ensemble d ’objectifs et d’exigences de sécurité
pour un groupe d’utilisateurs ayant des besoins de même type
indépendant de l ’implémentation
– 7 niveaux d’assurance de l’évaluation : EAL
niveaux 1 à 4 : possible à atteindre avec des produits déjà développés
niveaux 5 à 7 : exigences spéciales
• Cibles :
– d’évaluation (TOE) : partie du système soumise à évaluation
– de sécurité (ST) : objectifs, mesures de sécurité et d’assurance, spécifications,
202
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Concepts clés
• Cible d’évaluation (TOE)
– Produit ou système TI, Objet de l ’évaluation
• avec documentation utilisateur et administrateur
– Fonctions de sécurité de la TOE (TSF)
• parties de la TOE auxquelles il faut se fier pour que la politique de sécurité soit
correctement appliquée
– Politique de sécurité de la TOE (TSP)
• Règles de gestion, de protection et de répartition des biens au sein d’une TOE
• Cible de sécurité (ST)
– objectifs et exigences de sécurité pour un produit ou système spécifique
– mesures fonctionnelles et d’assurance offertes par ce produit
– Conforme à un ou plusieurs profils de protection
– base de l’évaluation
203
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Composants• Prise en compte de menaces
• Organisation hiérarchique – familles
– classes
• Désignation : concaténation– nom de classe
– nom de famille
– numéro d’ordre
• Dépendances– entre composantes fonctionnelles
– entre composants d ’assurance
– mixtes (plus rarement)
• Opérations– pour contrer une menace particulière
– spécification, sélection, itération, raffinement
Classe
FamilleFamille
Famille
Composant ComposantComposantComposantComposant
Paquet
FMT_SMR
Rôles de gestion
de la sécurité
1 2
3
Ex : FMT_SMR.2
204
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Composants 1 : Exigences
fonctionnelles
• Ensembles ordonnés d’éléments fonctionnels
• 11 classes
– FAU : Audit de la sécurité
– FCO : Communication
– FCS : Support cryptographique
– FDP : Protection des données de l’utilisateur
– FIA : Identification et Authentification
– FMT : Gestion de la sécurité
– FPR : Protection de la vie privée
– FPT : Protection des fonctions de sécurité de la TOE
– FRU : Utilisation des ressources
– FTA : Accès à la TOE
– FTP : Chemins et Canaux de confiance
• Extensible : agréés par organisme de certification
205
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Composants 1 : Exigences
fonctionnelles (suite)
• FCO : garantir identité– non répudiation d’origine
– non répudiation de la réception
• FMT : gestion des attributs de sécurité– définir et attribuer aux utilisateurs les rôles de gestion de la sécurité
• FPR : Protection des utilisateurs contre connaissance ou utilisation indue de son identité
• FTP : Intégrité– gestion des mécanismes et des données de la TSF
• FRU : disponibilité (CPU, stockage)– tolérances aux pannes, priorités de service, allocation de ressources
• FTA : établissement d ’une session
• FTP : chemins entre utilisateurs et TSF ou entre TSF– échanges garantis
206
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Composants 2 : Exigences d’assurance
• 2 classes pour évaluation des PP et des ST
– APE : Évaluation d’un Profil de Protection
– ASE : Évaluation d’une cible de sécurité
• 7 classes pour évaluation d ’une TOE
– ACM : Gestion de configuration
– ADO : Livraison et exploitation (et installation …)
– ADV : Développement
– AGD : Guides
– ALC : Support au cycle de vie
• outils et techniques de développement, sécurité des développeurs, correction des
erreurs trouvées par les utilisateurs
– ATE : Tests
– AVA : Estimation des vulnérabilités
• 1 classe pour la maintenance de l’assurance
– AMA : Maintenance de l ’assurance
207
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Niveaux d’assurance
• Ensembles de niveaux d’assurances
– composants issus de familles d ’assurance
– Offrir des paquets d’assurance génériques dotés de cohérence interne
• Niveaux (+) spécifiques
– répondre à des besoins spécifiques
– ajouts de composants aux niveaux standards
• Échelle croissante
– 7 niveaux
– compromis entre
• niveau d’assurance visé
• coût et faisabilité de l’évaluation
208
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Niveaux d’assurance EAL1 à EAL4
• Pas de techniques de développement spécialisées. Introduction de– rigueur croissante
– détails supplémentaires
• EAL1 : testé fonctionnellement– fonctionnement correct
– menaces considérées comme non sérieuses
– analyse des fonctions de sécurité et tests indépendants de ces fonctions
• EAL2 : testé structurellement– analyse de vulnérabilité
– tests du développeur
• EAL3 : testé et vérifié méthodiquement– pratiques de sécurité dès la conception
– TOE non piégée durant le développement
• EAL4 : conçu, testé et vérifié méthodiquement– plus haut niveau d ’adaptation d’une gamme de produits existante
– accroissement significatif par rapport à EAL3
209
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Niveaux d’assurance EAL5 à EAL7
• Techniques spécialisées de développement sécurisé
– produits et systèmes conçus et développés spécifiquement
• EAL5 :Conçu de façon semi-formelle et testé
– conception modulaire
– analyse des canaux cachés (« trous de sécurité »)
– garantie que TOE non piégée au cours du développement
• EAL6 :conception vérifiée, de façon semi-formelle et testée
– techniques d’ingénierie de sécurité
– environnement de développement rigoureux
– TOE de qualité élevée pour protéger des biens de grande valeur
– analyse approfondie de la vulnérabilité, étude systématique des canaux cachés , ...
• EAL7 : conception vérifiée, de façon formelle et testée
– TOE dédiés à la sécurité
– Risques extrêmement élevés ou très grande valeur des biens
– fonctionnalités de sécurité extrêmement concentrées : analyse formelle extensive
– tests étendus 210
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Profils de protection
• Ensemble d ’objectifs et d ’exigences de sécurité
• indépendant de l ’implémentation
• formulation des problèmes de sécurité à résoudre
• Ensemble de composants fonctionnels et d’assurance (niveau en général)
– choix expliqué dans un argumentaire
• Contenu :
– description de la TOE
– environnement de sécurité de la TOE
• hypothèses sur sécurité physique, personnels, etc.
• menaces présumées
• politique organisationnelle
– Objectifs de sécurité
– Exigences de sécurité
– Argumentaire
• sur objectifs
• sur exigences 211
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Exemples de profils de protection• Circuits imprimés pour cartes à puce
– microcontrôleur pour carte à puce
– EAL4+
• Coupe-feu à protection élevée
– passerelle filtrante configurable
– EAL5+
• Infrastructure de Gestion de Clés (IGC)
– mise en œuvre d’une IGC (certification, enregistrement ,…)
– EAL4+
• outils de sécurisation de messages
– inclus une IGC et serveurs de messagerie
– ressources cryptographiques
• identification , authentification, signatures,
• génération de clés, de condensats, …
• vérification des certificats, signatures - protection des clés
– EAL5+
212
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Exemples de profils de protection
(suite)
• Échanges de données informatisées (EDI)
– EAL3+
• Sécurité commerciale CS1
– Protection d ’accès contrôlée de base
• Sécurité commerciale CS3
– Protection d ’accès basée sur des rôles (RBAC)
• Standard ECMA E-COFC
– Extended Commercially Oriented Functionnality
– 2 classes
• Enterprise Business class (besoins internes)
• Contract Business class (B to B)
213
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Cible de sécurité (ST)
• Base de l’évaluation de la TOE
• définit les mesures de sécurité offertes par la TOE
– spécifique à une TOE (PP est générique)
• fait en général référence à un ou plusieurs PP
– éventuellement auteur complète les exigences
• Contenu :
– Description de la TOE
– Environnement de sécurité de la TOE
– Objectifs de sécurité
– Exigences de sécurité
– Spécifications globales de la TOE
• définition des fonctions de sécurité et des mesures d’assurance
– Annonce de la conformité à un PP
– Argumentaire
214
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Évaluation
• Faite par rapports aux critères définis dans les CC
• Plusieurs types
– Évaluation d’un PP
• conformité d’un PP aux CC
• intelligible
• techniquement correct
– Évaluation d’une ST
• mêmes objectifs que PP
• facilitée si s’appuie sur de PP
– Évaluation d’une TOE
• TOE satisfait aux exigences de la ST
• recherche des vulnérabilités
• tests de pénétration
– Maintenance de l’assurance
• selon AMA
Profils de
Protection
Cibles de
Sécuritécommanditaires
EVALUATIONS
Besoins des
utilisateursComposants
fonctionnels
Composants
d'assurance
Niveaux
d'assurance
215
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Bibliographie
• INTERNET SECURITY - Professional Reference D. Atkins & al. New Riders ISBN 1-56205-557-7
• " http://ictt.insa-lyon.fr/TeleRegionsSUN2/
• Pour compléter ces informations, les sites suivant peuvent être pris comme point de départ :
Bases de liens : http://www.ins.com/knowledge/whitepapers/#security,
http://www.dharris.com/French.htmlAspects légaux : http://www.scssi.gouv.fr/document/chiffre.html et
– http://www.legifrance.gouv.fr/citoyen/officiels.ow
Aspects organisationnels :
http://ictt.insa-lyon.fr/TeleRegionsSUN2/aesopian_security_management.pdf
IGC (PKI) : http://www.pkilaw.com/
et http://www.scssi.gouv.fr/document/igc.html
Evaluation - Critères communs : http://csrc.nist.gov/cc/
et http://www.scssi.gouv.fr/document/certif.html
Aspects techniques : http://www.cs.auckland.ac.nz/~pgut001/tutorial ,
http://www.netsec.psu.edu/netsec/kerberos.html,
http://www.ins.com/knowledge/whitepapers/#security
Standards : Les RFC portant sur le sujet …
http://www.semper.org/sirene/outsideworld/standard.html
Vulnérabilités, tests : http://www.cert.org216
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Sécurité NT
217
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Gestion des utilisateurs
• Groupes
– dont un utilisateur est membre
– Gestion des droits d'accès aux ressources (voir ci-dessous)
• Profil
– de l'utilisateur, scripts d'accès, répertoire de base
• Horaires
– durant lesquels le compte d'utilisateur peut se connecter aux serveurs
• Accès depuis
– Stations de travail à partir desquelles un utilisateur peut ouvrir une session
• Compte
– Global ou local; date d'expiration
– validité (max, min), unicité, longueur minimale du mot de passe
• Audit
218
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Groupes• Contrôleurs de domaines
– Administrateur Un administrateur doit avoir un compte utilisateur
– Utilisateurs
– Invités
– Opérateurs• de serveur
• d'impression
• de sauvegarde
• de comptes
– Duplicateur
• Stations de travail et serveurs– Administrateur
– Utilisateurs
– Utilisateurs avec pouvoir
– Invités local ou réseau
– Opérateurs de sauvegarde
– Duplicateur
219
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Groupes globaux et groupes locaux
• Groupe global
– ensemble de comptes utilisateurs d'un domaine
– moyen d'exporter des utilisateurs vers d'autres domaines
– droits dans son domaine et dans les domaines qui approuvent le sien
– ne contient pas d'autres groupes
– seulement sur des serveurs
• Groupe local
– ensemble d'utilisateurs et de groupes globaux d'un ou plusieurs domaines
– permet d'importer des utilisateurs et des groupes d'autres domaines
– droits d'accès seulement sur les serveurs du seul domaine du groupe local
– groupe local d'une station n'est pas utilisable sur un autre ordinateur
220
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Domaines et relations d'approbation
• Domaine– unité administrative de base pour administration et sécurité
• base de données des utilisateurs
– Contrôleur principal
– Dupliquée sur contrôleurs secondaires
• statégie de sécurité
– groupe de serveurs
• notion de "workgroup"
– ne pas confondre avec les domaines "protocolaires" : TCP/IP
• Relations d'approbation– liaisons entre domaines qui permettent l'authentification par traversée
• pas transitif: l'approbation n'est pas exportée ...
– compte utilisateur unique
– si un domaine A approuve un domaine B, les utilisateurs du domaine B peuvent obtenir des permissions et des droits dans le domaine A (même s'ils n'ont pas de comptes dans ce domaine)
221
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Protection contre les virus
• SENSIBILISATION des utilisateurs
• Droits d'accès aux fichiers
– lister répertoires
– lire (lecture et exécution)
– Ajouter de nouveaux fichiers (pas de lecture ni de modification)
– Ajouter et lire
– Modifier les fichiers et les répertoires
– Contrôle total: modifier + changer les permissions et les droits d'accès
• Test du fichier par anti-virus
– sur machine isolée
– sur poste réseau mais avec seul droit d'invité
• sauvegardes régulières
222
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Protection contre les chevaux de Troie
• Cheval de Troie
– Programme déguiser en programme ordinaire pour obtenir des informations
– Ex: Se faire passer pour un écran d'accès au système pour tenter d'obtenir des
informations sur les utilisateurs et les mots de passe
• Ouverture de session protégée par mot de passe
– Ctrl+Alt+Supp active directement l'écran d'ouverture de session
– si station verrouillée
• déverrouillage par ctrl+alt+sup et mot de passe
– Verrouiller en "Lire" les applications sensibles pour éviter leur remplacement par
des applications déguisées
223
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés
Réseau IF, ROCAD, Internet ....
• Découpage en
– sous-réseaux
• protocoles
– IP
– Netbeui
– IPX
• filtrage par routeurs
– groupes
• domaines NT
TRANSPAC
TPH
RNIS
Internet
Renater
Aramis
CISM
IN2P3
IF
UCBL INSA
ROCAD
univ-lyon1.fr insa-lyon.fr
zône "if"
ROCAD
Token
Ring
Ethernet
fanout
Hub
PONT
ROUTEUR
Répéteur
dorsale
Répéteurs
IF
Domaine NT
IFTELIF
OS/2NT
Autonome
Domaine NT
INSA-IFNT
NT NT
NTPrimaire
Secondaires
224
©[G.Beuchot] [2001] INSA de Lyon. Tous droits réservés