Ouvrir son Système d Information -freins et solutions-

Transcription

1 Ouvrir son Système d Information -freins et solutions- 1

2 Organisation traditionnelle Une organisation: Un ou plusieurs domaines de sécurité: Architectures réseaux déployées Pratiques sécuritaires adoptées Cloisonnement des domaines de sécurité (par des pare feu, routeur, etc.) Vision globale du réseau de l organisation gestion aisée du parc informatique 2

3 Collaboration entre organisations De nouvelles opportunités métiers se présentent : naissance du besoin de collaboration entre organisations nécessité d ouvrir son Système d Information Naissance de nouvelles formes d organisations: Entreprises (organisations) externalisées Entreprises (organisations) étendues et récemment les Entreprises (organisations) virtuelles Dilemme: Ouvrir et protéger son Système d Information 3

4 Organisation Virtuelle Une Organisation Virtuelle est une alliance temporaire d organisations (organisations, institutions, industries, etc.) qui se réunissent pour partager leurs compétences et leurs ressources afin de mieux répondre aux opportunités métier qui se présentent. La coopération est soutenue par des réseaux informatiques [Camarinha-Matos et Lima 1998] Un plateau virtuel est une forme d Organisation Virtuelle 4

5 Chaîne logistique AIRBUS PME Plateau Internet Virtuel PME 5

6 Gestion de l infrastructure distribuée Services attendus: Contrôle d accès (services d authentification et d autorisation) Délégation Traçabilité des usagers et auditabilité. Intérêt porté à la gestion du contrôle d accès. Modèles de gestion de contrôle d accès: Centralisé : une autorité centrale gère l ensemble des ressources (humaines, matérielles et logicielles) partagées. perdre le contrôle sur ses ressources Distribué : chaque partenaire gère les ressources qu il partage garder le contrôle sur ses ressources 6

7 Cas de figure PKI PKI -Public Key Infrastructure- 7

8 Rappels des principes des IGC Cryptographie asymétrique Bi-clef de chiffrement et/ou de signature. Comment associer une identité à une clé publique? Objectif des IGC Pourquoi y croire : Le fichier contenant l association clé pub /nom est sécurisé. Idée originale de Diffie et Hellman La structure de données associant clé pub au nom est sécurisée Idée des certificats certifiés par des autorités Comment certifie-t-on un certificat? Certificats X.509 / certificats PGP Impact sur le modèle de confiance et les architectures de gestion Evolution IGC vers les IGP (Privileges Management Infrastructure) Certificats d Attributs X.509v4 Exemple: PERMIS policies, roles, etc. Différentes architectures de gestion/certificats/standards

9 Interopérabilité des IGC Différents Modèles: AC racine / Hiérarchie Certification croisée AC pivot Reconnaissance mutuelle Liste d AC de confiance CA EE EE BCA CTL CA EE EE

10 Interopérabilité des IGC certificats Format Quels extensions/attributs? quel format pour les noms? Comment acquérir les certificats? Algorithmes de sécurité/longueur des clés etc Listes de révocation des certificats Format Obtention de la liste de révocation? Evaluation des politiques de certification ou déclarations des pratiques de certification

11 Interopérabilité des IGC À l international projets/forums/groupes de travail Interoperable Delivery of pan-european egovernment Services to Public Administrations, Businesses and Citizens OASIS PKI working group Interoperability Working Group of Asia PKI Forum esecurity Task Group of Asia Pacific Economic Cooperation Different models/solutions with pros and cons

12 IGC : Pour résumer La solution dépend du contexte d utilisation!! Quel type de certificat? authentification ou Authentification+accréditations Extensions/attributs spécifiques métiers (chaîne logistique aéronautique) Qui gère quoi? Autorité et responsabilité IGC interopérables? Dépend de la relation métier Dépend des entités impliquées Pays Confiance vis à vis des IGC partenaires? Audit du niveau de maturité

13 Travaux SIERA Notre équipe de recherche traite les problématiques de : Formation des Organisations Virtuelles, Gestion du contrôle d accès dans le cadre d une OV (proposition et déploiement de solutions techniques), Gestion de la confiance dans le cadre d une OV (évaluation des pratiques sécuritaires, évaluation du niveau de confiance dans une PKI, etc.), Nous avons proposé: des patrons techniques et, un patron organisationnel Interconnexion d IGC basée sur la notion de réputation 13

14 Formation d Organisation Virtuelle Organisation 1 admin OV Organisation 2 admin 14

15 Collaboration : freins rencontrés Besoin de faire collaborer des entreprises: de tailles différentes, ayant des stratégies et des politiques de sécurité différentes, ayant des actifs de niveaux de criticité différents, Freins rencontrés pour ouvrir son Système d Information aux partenaires: Hétérogénéité des architectures réseaux déployées, Hétérogénéité des pratiques sécuritaires adoptées par les organisations, Hétérogénéité des solutions d authentification et d autorisation adoptées, Niveau de confiance accordé à un partenaire, etc. Comment gérer le contrôle d accès dans le réseau distribué? 15

16 Collaboration : questions à se poser Qui gère les identités des utilisateurs externes? Qui se charge de l affectation des accréditations nécessaires pour accéder à des ressources partagées? Qui gère la fonction d authentification des utilisateurs externes accédant à une ressource partagée? Où faut-il gérer les ressources partagées (sur place ou déplacées)? Qui gère l accès aux ressources offertes par une organisation dans le cadre d une OV?. 16

17 Gestion centralisée du contrôle d accès Une autorité centrale gère l ensemble des ressources et l accès à ces ressources (un partenaire ou une entité externe): gestion des comptes et des accréditations des utilisateurs gestion des accréditations des ressources Moyens : utilisation d une solution collaborative Exostar WebEx.. 17

18 Gestion distribuée du contrôle d accès Un partenaire = une autorité responsable de l ensemble de ses ressources et l accès à ses ressources: gestion des comptes et des accréditations des utilisateurs (internes et externes) gestion des ressources (expression de politiques d accès) Utilisation des solutions d authentification et d autorisation déployées au niveau de chaque site 18

19 Gestion distribuée du contrôle d accès Collaborer Garder le contrôle admin Organisation 1 Organisation 2 politique admin politique admin Organisation 3 User 3 19

20 Système d authentification et d accréditation pour l OV Gestionnaire LDAP de comptes Protocole d échange Gestionnaire LDAP PKI de comptes Organisation 1 Organisation 2 20

21 La fédération d identité Fournisseur de services (page web, applications, etc.) Fournisseur d identité Fournit les services : Authentification Accréditation des utilisateurs (Rôle, identifiant de l OV, le contrat d engagement, etc.) Protocole d échange: Envoi des déclarations (preuve d authentification et attributs de l utilisateur), SAML (standard OASIS) et WS-Federation (spécification) 21

22 SAML vs WS-Federation SAML WS-Federation Répondre aux exigences d une fédération d identité Disponibilité de produits commerciaux supportant les spécifications Partie des spécifications Basé sur des standards + - Interaction avec d autres standards (ex : XACML) + - Disponibilité de tests d interopérabilité + - Nous avons choisi SAML Patrons techniques : authentification, accréditation, autorisation

23 Produits de fédération d identité Shibboleth PingFederate ADFS Open Source/ propriétaire Open Source propriétaire propriétaire Facilité de déploiement et de configuration Conformité aux langages d échange de l information de sécurité Support pour les applications patrimoniales Moyen Facile Moyen SAML et WS- Federation SAML et WS- Federation WS-Federation OUI OUI - kits d intégration Oui Support pour différents systèmes et technologies d authentification Active Directory, LDAP (mots de passe, certificats d identité X. 509, Kerberos, cartes à puce, etc.) Mots de passe, techniques biométriques, certificats d identité X. 509, etc. Active Directory

24 Fonctionnement de Shibboleth

25 Système d autorisation pour l OV Offre et renforce le service d autorisation offert par la fédération Un langage pour exprimer les exigences quant à l accès à une Ressource partagée. un langage d expression de politiques de contrôle d accès Ce langage devra supporter les modèles de contrôle d accès formels Un système de contrôle d accès pour appliquer ces politiques. 25

26 Infrastructure de Gestion de Privilèges Un service d autorisation basé sur les privilèges des utilisateurs Une IGP offre: Un langage de description de politiques, Un moteur d autorisation (PEP/PDP) pour appliquer ces politiques. politique 26

27 PERMIS Une IGP conçue par l Université de Kent. PERMIS fournit: Un langage pour l expression de politiques de contrôle d accès RBAC (basé sur la notion de rôles) et, Un moteur d autorisation pour appliquer ces politiques et, Un outil pour gérer les privilèges des utilisateurs. 27

28 XACML XACML est un langage XML pour le contrôle d accès normalisé par OASIS (version 3.0). XACML fournit : un langage universel de description des politiques de contrôle d'accès ABAC (basé sur la notion d attributs), Une architecture pour la mise en œuvre du contrôle d accès XACML favorise l interopérabilité entre les produits d administration et d autorisation hétérogènes. 28

29 Patrons techniques Fournisseur d identité Protocole d échange Fournisseur de service Gardien de ressource Décideur politique 29

30 Scénario Workflow Engine -Spécification partagée- Anna Role = Analyzer identity: Organisation B Organisation Virtuelle identity: Shared Design identity: identity: Organisation C Gunther Role = Designer identity: identity: identity: Conductor Role = wfe-status Michel Role =Integrator Organisation A Romain Role =Validator

31 Le patron Shibboleth-PERMIS

32 Expression de politique: ABAC ABAC = Attribute Based Access Control Exemple de politique: 1) role(s) = integrator voagreement(s) = contract1 (name(a) = read name(a) = write) name(r) = specification-document status (R) = start Anna Role = Analyzer 2) role(s) = designer voagreement(s) = contract1 identity: (name(a) identity: = read Organisation name(a) Virtuelle = write) name(r) Gunther Role = = specification-document identity: identity: status (R) = awaitdesign Organisation B Organisation C Designer Shared Design 3)... identity: +) role(s) = wfe-status identity: identity: voagreement(s) = contract1 (name(a) Michel = read Organisation name(a) A = write) Conductor Romain name(r) = status- Role =Integrator specification-document Role =Validator

33 Définition des attributs des utilisateurs Gunther

34 Définition des attributs des ressources Définition des attributs:

35 Politique: Définition des attributs <RoleHierarchyPolicy> <RoleSpec OID=" " Type="permisRole"> <SupRole Value="Integrator"> <SubRole Value="any"/> </SupRole> <SupRole Value="Designer"> <SubRole Value="any"/> </SupRole> <SupRole Value="Analyzer"> <SubRole Value="any"/> </SupRole> <SupRole Value="Validator"> <SubRole Value="any"/> </SupRole> <SupRole Value="any"/> <SupRole Value="wfe-status"/> </RoleSpec> Integrator Wfe-status Designer Analyzer Validator any

36 Politique: Définition des attributs <RoleSpec OID=" " Type="voagreement"> <SupRole Value="contract1"/> <SupRole Value="contract2"/> </RoleSpec> <RoleSpec OID=" " Type="status"> <SupRole Value="start"/> <SupRole Value="await-design"/> <SupRole Value="await-analysis"/> <SupRole Value="await-validation"/> <SupRole Value="validated"/> <SupRole Value="stop"/> </RoleSpec> </RoleHierarchyPolicy>

37 Politique: Définition des Autorités d Attributs (AA) <SOAPolicy> <SOASpec ID="organisation A idp" LDAPDN="cn=idpA.example.org,o=test,c=FR"/> <SOASpec ID="organisation B idp " LDAPDN="cn=idpB.example.org,o=test,c=FR"/> <SOASpec ID="organisation C idp " LDAPDN="cn=idpC.example.org,o=test,c=FR"/> <SOASpec ID="home" LDAPDN="cn=home,o=test,c=FR"/> </SOAPolicy>

38 Politique: Définition des droits des AA <RoleAssignmentPolicy> <RoleAssignment> <SubjectDomain ID="SubjectDomain"/> <RoleList> <Role Type="permisRole" Value=«Validator"/> <Role Type="permisRole" Value="wfe-status"/> <Role Type="permisRole" Value="Integrator"/> <Role Type="voagreement" Value="contract1"/> </RoleList> <Delegate Depth="0"/> <SOA ID="organisation A idp"/> <Validity/> </RoleAssignment>

39 Politique: Définition des ressources protégées <TargetPolicy> <TargetDomainSpec ID="TargetDomain1"> <Include URL=" <Include URL=" </TargetDomainSpec> <TargetDomainSpec ID="wfe-status-domain"> <Include URL=" <Include URL=" </TargetDomainSpec> </TargetPolicy>

40 Politique: Définition des droits du Conductor role(s) = wfe-status voagreement(s) = contract1 (name(a) = read name(a) = write) name(r) = status- specification-document <TargetAccessPolicy> <TargetAccess> <RoleList> <Role Type="permisRole" Value="wfe-status"/> <Role Type="voagreement" Value="contract1"/> </RoleList> <TargetList> <Target Actions="GET,POST"> <TargetDomain ID="wfe-status-domain"/> </Target> </TargetList> </TargetAccess>

41 Politique: Définition des droits du rôle Integrator role(s) = integrator voagreement(s) = contract1 (name(a) = read name(a) = write) name(r) = specification-document status (R) = start <TargetAccess> <RoleList> <Role Type="permisRole" Value="Integrator"/> <Role Type="voagreement" Value="contract1"/> <Role Type="status" Value="start"/> </RoleList> <TargetList> <Target Actions="GET,POST"> <TargetDomain ID="TargetDomain1"/> </Target> </TargetList> </TargetAccess>

42 Complexité Cohabitation de deux technologies indépendantes à la base, Technologies issues du monde de la recherche et dans un état instable, Fonctionnalités qui changent d une version à l autre, Problème de versioning.

43 Statut du patron Le patron : 2 images virtuelles : Shibboleth IdP Shibboleth SP + PERMIS Le patron : Déployable, Personnalisable (ajout d utilisateurs à IdP, changer politique d autorisation, etc.).

44 Points faibles du patron Shibboleth/PERMIS langage de politiques propriétaire protocole propriétaire

45 Le Patron Shibboleth-XACML SAML

46 Etapes de la réalisation du patron Spécification et réalisation du serveur d autorisation XACML, Développement du traducteur SAML/XACML, Traitements des attributs (identification, extraction, et manipulation) pour la construction des requêtes SAML et XACML, Création du PEP (module Apache).

47 Statut du patron Le patron : 3 images virtuelles : Shibboleth IdP Shibboleth SP + PEP Moteur d autorisation XACML (Context handler + PDP) Le patron : Déployable, Personnalisable.

48 Technique vs Organisationnel Corrélation : gestion du contrôle d accès niveau de confiance porté à un partenaire Nécessité de quantifier le niveau de confiance Un patron organisationnel influence le choix du patron technique 48

49 Evaluation de la confiance Définition de la confiance: l assurance qu une entreprise se comportera en fonction de nos attentes et qu elle exhibera une bonne volonté [Ring et Van de Ven 1994]. Nécessité d évaluation de la confiance Tableaux de bords, Indicateurs Annoncer les résultats de l évaluation Moyens? Méthodes Audit 49

50 Gestion de la sécurité de l information Prise de conscience Information = ACTIF Nécessite une protection Construction d outils Fédération d identités Contrôle d accès Réseaux.. Construction d un SMSI (Système de Management de Sécurité de l Information) Application de méthodes Application de normes Audits. 50

51 Normes ISO Résultat d une longue réflexion BS bonnes pratiques Thèmes (11) + Objectifs (39) + Contrôles (133) politique de sécurité organisation de la sécurité de l information gestion des biens Sécurité liée aux ressources humaines Sécurité physique et environnementale gestion de l exploitation et des communications contrôle d accès Acquisition, développement et maintenance des systèmes d information Gestion des incidents liés à la sécurité de l information Gestion du plan de continuité de l activité Conformité 51

52 Stratégie d ouverture du SI d une Organisation Hypothèses retenues: Répondre rapidement à des objectifs métiers Nécessité d ouvrir le SI des partenaires Problématiques Inexistence de travaux spécifiques à la gestion de la sécurité pour les OV, Disparité et hétérogénéité des partenaires, Objectifs Evaluation d un niveau de confiance Fournir un outil d aide à la décision Moyens Utilisés Exploiter un sous ensemble d ISO Adopter les niveaux de maturité (en se basant sur CMMI) 52

53 Contributions (1) Construction d un questionnaire 2 versions (v1 : 278 questions, v2 : 158 questions) question = présence d une pratique sécuritaire analyse des chapitres : politique de sécurité organisation de la sécurité de l information gestion des biens Sécurité liée aux ressources humaines Sécurité physique et environnementale gestion de l exploitation et des communications contrôle d accès Acquisition, développement et maintenance des systèmes d information Gestion des incidents liés à la sécurité de l information Gestion du plan de continuité de l activité Conformité 53

54 Contributions (2) Calculer un score pondérer et moyenner Proposition d une échelle de valeur 1 Initial 2 minimal 3 acceptable 4 géré 5 Optimal 54

55 Contenu du chapitre 5 Politique de sécurité Raison d être : Connaître les engagements des dirigeants vis-àvis de la sécurité de l information, Objectif à atteindre Définir la politique de sécurité Contrôles de sécurité à mettre en place pour atteindre l objectif: 1) Etablir un document de politique 2) Stratégie de révision de la politique 55

56 MAT Information security policy objective QUESTIONS Information security policy document 1 A limited number of policies specific to some topics are defined and they are communicated to users in an informal way; no global policy is defined 2 Some of the organization information security policies are written 2 Individual managers develop individual policies covering parts of the information security 3 Security policy document is written and management approval is obtained for the documented policies 3 The organization has defined a program for the communication of its security policy to its employees 4 Security level measurement exists 5 Non-compliances with the organization information security policy are automatically reported to take action 5 The organization stakeholders receive a formal training about the organization security policy; they also know their responsibilities to ensure the organization security 56

57 Niveau de maturité globale 57