Déploiement d'une infrastructure à  clé publique enjeux et conformité 1.2

870 vues

Publié le

MISE EN PLACE D’UNE INFRASTRUCTURE À CLÉS PUBLIQUES (ICP) ENJEUX ET CONFORMITÉ
UNE VISION PRATIQUE
par HECTOR SZABO et THOMAS PORNIN
le 31 mars 2015, ISACA-Québec

Publié dans : Technologie
  • Soyez le premier à commenter

Déploiement d'une infrastructure à  clé publique enjeux et conformité 1.2

  1. 1. MISE EN PLACE D’UNE  INFRASTRUCTURE À CLÉS PUBLIQUES (ICP)  ENJEUX ET CONFORMITÉ UNE VISION PRATIQUE HECTOR SZABO – THOMAS PORNIN CONFÉRENCIER HECTOR SZABO DATE 31 MARS 2015 http://www.isaca‐quebec.ca
  2. 2. 2 OBJECTIF ET AGENDA Objectif  Décrire les enjeux principaux lors de la mise en place, opération et  amélioration d’une ICP Agenda  Concepts entourant une ICP  Certificats numériques et infonuagique  Gouvernance et ICP: impacts sur l’audit et la conformité  WebTrust 2.0: un encadrement robuste  Montage et audit d’une Autorité de Certification: défis pratiques   Utiliser des certificats: quelques orientations  Conclusions
  3. 3. 3 Concepts entourant une ICP Infrastructures à clés publiques
  4. 4. 4 INFRASTRUCTURE À CLÉS PUBLIQUES  (OQLF) Système permettant la gestion de clés de chiffrement  constituées de séquences de symboles et la délivrance de  certificats numériques, tout en assurant la sécurité et la  confidentialité des échanges d'information et des  transactions électroniques par des réseaux informatiques  comme Internet. 4
  5. 5. 5 AUTORITÉS DE CERTIFICATION: POURQUOI? Objectifs  Identifier les partenaires d’affaires sans ambigüités  Simplifier et uniformiser les procédures d’autorisation  Permettre la signature numérique  Assurer la non‐répudiation des transactions  Assurer la non‐répudiation de la date et heure des transactions  Assurer la pérennité des signatures numériques   Assurer la confidentialité des communications  Assurer la confidentialité des contenus  Permettre la récupération de contenus confidentiels
  6. 6. 6 SERVICES ET COMPOSANTES POSSIBLES D’UNE  SOLUTION D’ICP Identité et clés Identification  / émission de  certificats Révocation et  publication de certificats  annulés  Publication  des certificats  (annuaire) Conservation  des certificats  et historique  des clés Sauvegarde  des clés  (chiffrement) Recouvrement  des clés  (chiffrement) 6 Autres services Certification  croisée Solutions  d’itinérance Provision de  jetons  logiques Chiffrement Horodatage Signature  (non  répudiation)
  7. 7. 7 IDENTITÉ Identification  •Annoncer dans un format normalisé  les données nominatives de  l’utilisateur •Établir les données requises •Supporter différents moyens de  discrétion et anonymat Authentification  •Assurer l’intégrité des données  d’identification présentées •Utiliser des moyens normalisés pour  la vérification de l’intégrité Autorisation •Fournir des moyens normalisés pour  décider les accès aux ressources  fournies •Admettre la délégation dans la  gestion des accès •Admettre la fédération des identités  et droits sur la base d’indicateurs de  qualité 
  8. 8. 8 CRYPTOGRAPHIE:  BASES ET UTILISATION
  9. 9. 9 CHIFFREMENT ASSURE LA CONFIDENTIALITÉ • Chiffrement : transformation des données pour les rendre inintelligibles. • Le chiffrement utilise un algorithme (public) et une clé (secrète). • L’opération est réversible (déchiffrement) à condition de connaître la clé. Le chiffrement réduit le problème de la confidentialité des données à celui de la  confidentialité de la clé. 9
  10. 10. 10 MAC MESSAGE AUTHENTICATION CODE : ASSURE L’INTÉGRITÉ • Calcul d’une somme de contrôle sur des données binaires  arbitraires, paramétré par une clé secrète. • Le MAC est recalculé par le destinataire, en utilisant la  même clé. • Sans la clé, impossible de reproduire un MAC valide. 10 b7 22 a1 84 97 a5 24 75 c8 45 c2  f6 f8 34 c3 a6 ed ba 27 7a EF1C3A Hash Lorem ipsum dolor sit amet, consectetur adipiscing elit. Praesent vitae sem dolor.  Suspendisse interdum purus non nisl ultricies, ac tempus odio efficitur.  Le contrôle d’intégrité est  important pour assurer la  confidentialité (attaques actives  qui observent le comportement  du destinataire sur des données  modifiées).
  11. 11. 11 CHIFFREMENT ASYMÉTRIQUE • Chiffrement asymétrique : la clé de chiffrement et la clé de déchiffrement sont  mathématiquement liées, mais distinctes. • On peut rendre publique la clé de chiffrement,  sans révéler la clé de déchiffrement (clé privée). • RSA, ElGamal, ECIES… Le chiffrement asymétrique transforme le problème  de distribution de clés secrètes en un problème  de distribution de clés publiques. 11
  12. 12. 12 POURQUOI ASYMÉTRIQUE • Le chiffrement symétrique requiert des prévisions  pour la distribution, conservation et destruction de  la clé symétrique utilisée. • La gestion de la clé unique requiert le même niveau  de sécurité et de moyens de prévention du risque  sur tous les utilisateurs de la même clé • La robustesse de la distribution de clés symétriques  revient au maillon le plus faible des lignes et  moyens de distribution 
  13. 13. 13 SIGNATURE 13 • La signature utilise le chiffrement assymétrique • La clé de génération de signature, et la clé de  vérification de signature, sont distinctes. • Algorithmes : RSA, DSA, ECDSA… • Les signatures sont un outil utile pour la non‐ répudiation. • Il n’est pas conseillé d’utiliser la même clé pour le  chiffrement asymétrique et pour les signatures. • Une clé publique n’est pas une identité. Signature • Contenant  protégé • Longue durée Chiffrement • Tiers de  confiance • Cycle court
  14. 14. 14 CERTIFICATS NUMÉRIQUES ET  INFONUAGIQUE Cryptographie et son utilisation dans les interactions dans l’infonuagique
  15. 15. 15 CERTIFICATS 15 • Certificat : établit le lien entre une identité et une clé publique. • Le certificat est émis (signé) par une Autorité de Certification. • Standard : X.509. Un certificat contient : • Un numéro de série • L’identité du propriétaire du certificat • L’identité de l’AC qui a émis le certificat • La clé publique du propriétaire du certificat • Des dates de validité • Des extensions…
  16. 16. 16 CERTIFICATS : ÉMISSION 16 • L’Autorité d’Enregistrement (Registration Authority) :fait le lien entre l’identité physique et la clé  publique, via une procédure (par exemple rencontre en personne avec le détenteur de la clé). • L’AE communique à l’AC la clé publique et l’identité ; l’AC émet le certificat. • La clé publique voyage sous la forme d’une requête de certificat (PKCS#10, CMC…). • La clé privée ne sort pas du contrôle du détenteur. • Variante : la paire de clé est générée par l’AC, et communiquée au détenteur avec le certificat.
  17. 17. 17 CERTIFICATS : CHAÎNES 17 Nom: Jeanne Tremblay Date d’émission: 2012/04/20 Date d’échéance: 2015/04/20 Numéro de série: 122aced2 Émetteur: AC FooBarEmet Utilisation du  certificat… Autres données 0EVwRUMEZDM9K777i3Ge  jDqyCzEN2iv7SyDqCwXE Nom: AC FooBarEmet Date d’émission: 2012/01/10 Date d’échéance: 2018/01/10 Numéro de série: a234efa1 Émetteur:AC Racine FooBar Utilisation du  certificat… Autres données KedJuTob5gtvYx9qM3k3gm7 kbLBwVbEQRl26S2tmXjqNND 7MRGtoew== Signé avec la clé privée De l’autorité racine Nom: AC Racine FooBar Date d’émission: 2011/01/10 Date d’échéance: 2037/01/10 Numéro de série: aa234113 Émetteur:AC Racine FooBar Utilisation du  certificat… Autres données Signale où retrouver le  Certificat et la liste de certificats révoqués de l’autorité de certification émettrice Signale où retrouver le  Certificat et la liste de certificats révoqués de l’autorité de certification racine Utilisateur Signé avec la clé privée De l’autorité de  certification Auto‐signé Par l’autorité racine
  18. 18. 18 CERTIFICATS : CHAÎNES 18 • Pour vérifier la signature sur un certificat, il faut connaître la  clé publique de l’AC → le problème a été déplacé. • Chaque participant connaît quelques clés d’AC « racines » a  priori (installées avec le système d’exploitation ou par  l’administrateur). • Une AC non‐racine est dite « intermédiaire ». • Chaque certificat peut contenir un lien (URL) vers le  certificat de son AC émettrice. • La validation est un processus compliqué dont l’élément  principal est la vérification des signatures cryptographiques.
  19. 19. 19 CERTIFICATS : RÉVOCATION 19
  20. 20. 20 CERTIFICATS : RÉVOCATION 20 • Révocation : permet de déclarer des certificats comme invalides. • Publication régulière de Certificate Revocation Lists qui contiennent les  numéros de série des certificats révoqués. Chaque CRL est signée  (normalement par l’AC elle‐même) et a une durée de vie brève. • Un certificat contient des liens (URL) vers la CRL qui le concerne. • La validation du certificat comporte la vérification de CRL . Le mécanisme de révocation est fonctionnellement équivalent à une réémission  automatique de certificats à courte durée de vie.
  21. 21. 21 CARTE À PUCE • Une carte à puce est un dispositif blindé qui fabrique, stocke et utilise une  clé privée. • La carte authentifie son détenteur via un code PIN. 21
  22. 22. 22 CARTE À PUCE : INITIALISATION 22 • Le code PIN est normalement choisi par l’utilisateur. • Le code PIN est un mot de passe. • La carte à puce se bloque après  plusieurs tentatives infructueuses. • L’initialisation est souvent faite sous contrôle de l’AE : l’utilisateur reçoit sa carte et son certificat en même temps.
  23. 23. 23 CARTE À PUCE : GÉNÉRATION DES CLÉS 23 • La carte contient un accélérateur cryptographique qui lui permet de fabriquer efficacement une  nouvelle paire de clés (quelques secondes). • Le certificat est obtenu auprès de l’AC et stocké sur la carte. • Sans code PIN, on peut obtenir une copie du certificat, mais on ne peut pas utiliser la clé privée. • La clé privée ne sort jamais. • Après un certain nombre d’accès ratés la carte se bloque ou se détruit
  24. 24. 24 CARTE À PUCE : UTILISATION 24 • La carte à puce produit une signature sur le haché du document présenté (la carte ne  voit pas le document lui‐même). • La carte accepte de produire une signature sur présentation du code PIN. • Déchiffrement : fonctionnement similaire. • Authentification par carte à puce (Kerberos, SSL…) : en interne, une signature est  calculée par la carte, sur un défi (Challenge) envoyé par le serveur.
  25. 25. 25 HORODATAGE • Un horodatage est une signature effectuée par une Autorité d’Horodatage (Time Stamp Authority). Cette  signature porte sur le haché d’un document et la date d’horodatage. • L’horodatage établit une preuve d’antériorité. • On peut « sceller » une signature en appliquant un horodatage : cela permet une validation a posteriori en se  plaçant à la date de l’horodatage, même si le certificat de signature a expiré ou a été révoqué entretemps. • … mais uniquement si on peut valider le certificat de la TSA à la date courante. • Applications : DLL ActiveX, documents PDF signés (PAdES). 25
  26. 26. 26 TYPES D’AUTORITÉS DE CERTIFICATION • Autorité racine: • Par définition, une autorité racine est irrévocable. Elle doit donc être  particulièrement protégée. • Une autorité racine robuste est hors‐ligne. Elle émet des listes de certificats  révoqués avec une procédure régulière mais manuelle (transfert par clé USB). • Autorité émettrice: • Elle est en ligne et émet les certificats pour les utilisateurs et les « choses »  (pour l’Internet of things) • Autorité intermédiaire: • Une autorité intermédiaire pourrait être utilisée si on décide avoir des autorités  émettrices distinctes pour des rôles très différents (certificats pour des ballots  et certificats de signature, par exemple) 26
  27. 27. 27 SERVICES ET COMPOSANTES POSSIBLES D’UNE  SOLUTION D’ICP – CAS TYPIQUE Identité et clés Identification  / émission de  certificats Révocation et  publication de certificats  annulés  Publication  des certificats  (annuaire) Conservation  des certificats  et historique  des clés Sauvegarde  des clés  (chiffrement) Recouvrement  des clés  (chiffrement) 27 Autres services Certification  croisée Solutions  d’itinérance Provision de  jetons  logiques Chiffrement Horodatage Signature  (non  répudiation)
  28. 28. 28 GOUVERNANCE ET ICP: IMPACTS SUR L’AUDIT ET LA  CONFORMITÉ Quelques mots sur l’arrimage des objectifs de l’entreprise et les besoins en ICP Impacts sur les fonctions d’audit, conformité et vérification
  29. 29. 29 L’ICP COMMENCE PAR LES ENTENTES • Sans un cadre concret, signé et accepté par tous les  utilisateurs des produits de l’ICP, ceux‐ci n’auront pas  la valeur prévue. • Les scénarios de compromission sont flous ou  risquent d’être déconnectés avec la réalité. • Les exigences et la gestion des RRHH manquent d’un  cadre directeur pour établir des barèmes et  contrôles. • La valeur des produits de l’ICP reste ressort de la  bonne volonté et peut être discutable si une situation  de conflit d’intérêts se produit.
  30. 30. 30 ENCADREMENT: LES ENTENTES PRÉALABLES QUI RENDENT UNE ICP UTILE Cadre d’identification Cadre d’octroi de certificats Utilisations acceptées Niveaux de confiance requis Moyens de conservation acceptés Gestion des supports cryptographiques Gestion de la compromission Contextes admissibles pour la récupération 30
  31. 31. 31 TYPES DE PARTENARIAT Quelques exemples d’ententes et ses impacts
  32. 32. 32 TYPES DE PARTENARIAT QUELQUES EXEMPLES D’ENTENTES ET SES IMPACTS Loteries  (terminaux) Moyen : Certificats signés par le concessionnaire aux exploitants de la concession Cadre : Règles non négociables But : Connexion SSL et identification Besoin : Postes portatifs faciles à voler Solution : Identification / non répudiation / SSL / révocation simple. Santé Moyen : Certificats à valeur gouvernementale Cadre : Lois de la santé, ententes entre fournisseurs de services et produits But : Connexion SSL, identification et signature Besoin : non répudiation des actes médicaux, protection des données Solution : Identification / non répudiation (utilisateur et B2B) / contrôle des accès Home Banking Moyen : Certificats à valeur universelle Cadre : Ententes très fortes non négociables But : Signature des transferts entre comptes et transactions internationales / Lien SSL Besoin : Assurer la non‐répudiation à valeur juridique sur des moyens robustes Solution : Cartes cryptographiques pour authentification de transactions bancaires  32
  33. 33. 33 LES BESOINS LE CLIENT POURRA IDENTIFIER SES BESOINS ET ÉTABLIR LE CADRE D’ENTENTES 33 Niveaux de confiance requis • Standard adhéré par la solution • Moyens acceptés pour le support de multiples niveaux de confiance • Cadre inter‐partenaire et légal en application Services requis • Standards adhérés pour chaque service • Identification, Chiffrement, Signature, Horodatage Contenants cryptographiques • Standard adhéré  • Quantité de facteurs requis selon le niveau de confiance • Types de plateformes à supporter • Exigences acceptées par les partenaires, provision, mise à jour et remplacement des contenants  Niveau de service • Comment assurer la CIA /CID • Résilience requise et plans de relève • Moyens de support requis, coûts et moyens de financement, RRHH (rôles, exclusions, disponibilités)
  34. 34. 34 ICP: DE LA SOLUTION DE GARAGE AUX  SOLUTIONS HOMOLOGABLES Autorité  unique auto‐ signée • Démos • Preuves de  concept  initiales Autorité à  deux niveaux  virtuels sur  infrastructur e partagée • Preuves de  concept • Solutions  internes Autorité à  deux niveaux  virtuels sur  infrastructur e privée • Solutions  internes • Développe ment de  solutions  complexes • Preuves de  concept  avancées Autorité à  deux niveaux  physiques  avec racine  isolée, sans  HSM • Solutions  d’affaires à  faible  encadremen t légal Autorité à  deux niveaux  avec racine  isolée et  conteneurs  de clés  cryptographi ques (HSM) • Solution  homologabl e • Solutions  d’affaires  complexes Autorité à  deux  niveaux,  racine isolée,  HSM et HSM  pour key escrow • Solution  homologabl e pour  chiffrement Autorité à  trois ou plus  niveaux,  racine isolée  et HSM  • Support de  solutions à  niveaux de  confiance  différents 34
  35. 35. 35 PLAN DE TRAVAIL POUR LE MONTAGE D’UNE ICP Établir le niveau de reconnaissance requis Établissement de la documentation pour le niveau de reconnaissance requis Préparation des procédures pour le niveau de reconnaissance requis Moyens d’assurance des niveaux de résilience requis Moyens de préservation de l’autorité de certification émettrice et la racine (CIA/CID) Moyens de préservation et diffusion du PDS (IA/ID) Établissement des ressources humaines requises pour le montage (profil/ségrégation) 35 CIA: Confidentiality, Integrity, Availability, Confidentialité, Intégrité, Disponibilité (CID)
  36. 36. 36 INTÉRACTION DES COMPOSANTES TYPIQUES D’UNE  ICP 36 Identités AC Racine AE Identité RBAC AD AD Identités AD CRL OCSP TITULAIRE AC AC Émettrice
  37. 37. 37 WEBTRUST 2.0: UN ENCADREMENT ROBUSTE
  38. 38. 38 WEB TRUST 2.0:  TRUST SERVICE PRINCIPLES AND CRITERIA FOR CERTIFICATION  Introduction 1. Divulgation des pratiques d’affaires de l’AC 2. Gestion des pratiques d’affaires de l’AC 3.  Contrôles environnementaux de l’AC 4. Contrôles de gestion du cycle de vie des clés de l’AC 5. Contrôles de gestion du cycle de vie des clés des souscripteurs 6. Contrôles de gestion du cycle de vie des certificats 38
  39. 39. 39 WEBTRUST 2.0 PATRONS DE CONTRÔLE Traçabilité  du matériel Pré‐ documenté Traçabilité  du logiciel Horodatage Contrôles  croisés Valider avec  l’auditeur Enregistre ment  Zonage
  40. 40. 40 IMPACTS DES EXIGENCES WEBTRUST Les activités de configuration doivent prévoir la traçabilité Les composantes ont différents niveaux d’exigence Quelques activités requièrent la présence d’un notaire ou enregistrement vidéo Les normes des CTI exigent qu’on n’utilise pas des caméras dans les locaux Quelques activités requièrent deux participants indépendants ou témoins La virtualisation de composantes peut complexifier la gestion des ressources La plupart des exigences sont incluses dans les normes et pratiques de l’industrie 40
  41. 41. 41 ZONAGE WEBTRUST ‐ ACCÈS 41 A D AC Émettrice AC Racine LRA Identité RBAC A D A D CRL OCSP TITULAIRE SCSMS LCA
  42. 42. 42 ZONAGE WEBTRUST: DÉPLOIEMENT DU CODE 42 A D AC Émettrice AC Racine LRA Identité RBAC A D A D CRL OCSP TITULAIRE SCSMS LCA
  43. 43. 43 Utiliser des certificats: quelques orientations Quelques idées et bonnes pratiques
  44. 44. 44 UTILISER DES CERTIFICATS Réaliser la demande sur le serveur qui les utilisera Déclarer les clés non exportables Prévoir des procédures de mitigation en cas de destruction Limiter le personnel qui peut demander et déployer des certificats Établir le cadre d’utilisation et responsabilité Documenter au préalable et tester les procédures Choisir soigneusement l’autorité de certification 44
  45. 45. 45 UTILISER DES CERTIFICATS Certificats de signature de code Chiffrement de contenus (documents, disques) Certificats pour des serveurs en grappe Caractères spéciaux  HSM ‐ TPM Certificat comme moyen d’accès (mauvaise pratique) 45
  46. 46. 46 Conclusions
  47. 47. 47 LEÇONS APPRISES : QUELQUES EXEMPLES   Clé de diversification Gestion des sources et du déploiement Vidéo Gestion des clés Râteliers et murs Virtualisation et SAN Redondance 47
  48. 48. 48 LEÇONS APPRISES : ÉLÉMENTS CRITIQUES CRL Annuaires Échéances, renouvellements et propagation Vieillissement des moyens cryptographiques Facteur humain 48
  49. 49. 49 COORDONNÉES Hector.Szabo@gmail.com Thomas.Pornin@cgi.com 49

×