Vers une gestion d’identités moderne

1. Vers une gestion d’identités moderne Pascal AUBRYHenri JACOBSaâdAÏT OMARSerge AUMONT

2. Avertissement

3. Plan réflexion autoflagellation [action]

4. Êtes-vous concerné(e) ? • La création de tout ou partie des comptes de vos utilisateurs est-elle effectuée par votre service informatique ? • Est-ce bien le rôle de la DSI ? • La DSI est-elle à même de juger de la pertinence des privilèges des utilisateurs ?

5. Êtes-vous concerné(e) ? • Lorsqu’un utilisateur a besoin d’accéder à une application, lui est-il également automatiquement attribué un répertoire d’accueil et une adresse électronique ?

6. Êtes-vous concerné(e) ? • L’accès aux applications sensibles est-il protégé par une authentification de type SSO ?

7. Êtes-vous concerné(e) ? • Lorsqu’un utilisateur change de statut ou quitte l’établissement, une intervention manuelle est-elle nécessaire pour supprimer tous les droits associés à son identifiant ? • Le deprovisioning, ça vous parle ?

8. Êtes-vous concerné(e) ? • Le même mot de passe est-il utilisé pour se connecter au réseau, pour la messagerie et pour l’accès à l’ENT ? • Êtes-vous sûr de tous les périphériques stockant ce mot de passe (BYOD) ?

9. Si vous avez répondu OUI au moins une foisvous êtes concerné(e) • Sinon merci de quitter cette salle :-)

10. Système actuel… et cible

11. Un système actuel dépassé • Fonctionnel • Besoins non remplis • Coût de gestion exorbitant • Sécurité • Conflit avec la PSSI • Technique • Coût d’évolution très élevés

12. De nouvelles populations • Ajout des extérieurs dans les bases institutionnelles • Utilisation sauvage des outils du cloud • Étudiants • Personnels • Anciens étudiants (diplômés) • Retraités • Utilisateurs des bibliothèques • Intervenants extérieurs

13. De nouveaux usages • Forte poussée des réseaux sociaux • La possession d’un compte ou adresse électronique institutionnelle n’est plus la preuve tangible de l’identité • Ouverture des SI vers les prestataires d’identités extérieurs • Gain fonctionnel sans perte de sécurité

14. Une décentralisation nécessaire • Gestion des bases institutionnelles : fonctionnels • Scolarités, RH • Le reste : traitement à la marge par la DSI  • Comptes étudiants banalisés pour les formations ponctuelles, comptes fonctionnels des composantes, comptes spécifiques à la recherche, … • Un coût exorbitant • Des relents de l’informatique gourou

15. Tradition orale • Quand un vieillard meurt… • …c’est une bibliothèque qui brûle • Quand un ingénieur part en retraite… • …il arrive qu'on ne sache plus pourquoi telle ou telle pratique est opposée aux utilisateurs comme une règle de sécurité • Formalisation des processus métier

16. Sécurité approximative • De multiples services • Une authentification pratique mais faible • Un deprovisioningdéficient • Une imputabilité limitée

17. Multiples services • Avant : une palette simple • Essentiellement des ressources : stockage, messagerie électronique, connexion aux postes de travail • Mais ça c’était avant • Environnements Numériques de Travail • Attribution d’accès aux services directement reliée à l’attribution d’un compte dans le Système d’Information • Manque de souplesse dans l’allocation des privilèges • Conséquences non négligeables sur la sécurité des systèmes

18. Authentification pratique mais faible • Utilisation du Single Sign-On • Confortable (compte/mot de passe unique) • Mise en œuvre universelle de certaines mesures de sécurité • Bloquer un compte, forcer le changement d'un mot de passe • Moins de post-it « pense-bête » sur les écrans • Bilan néanmoins mitigé • Compromissions plus dommageables • Authentification auprès des services sensibles

19. Deprovisioningdéficient • Allocation des privilèges fidèle aux besoins • par nécessité… • Suppression des privilèges délaissée • Départ, changement de statut • Conséquences graves sur la sécurité

20. Imputabilité limitée • Une obligation légale • Conseils de discipline (interne) • Réquisition judiciaire (externe) • Utilisation à outrance des comptes banalisés • Manque de traçabilité

21. Système peu maîtrisé • Évolutions et maintenance très difficiles et coûteuses • Nombreuses technologies • Forte adhérence entre les briques logicielles • Faible isolation entre les règles métier et le processus de transformation des données

22. Architecture obsolète • Séparation insuffisante authentification/autorisation • Allocation des comptes par la DSI • Délégation de l’allocation des privilèges (Grouper) • Raison techniques et humaines • Lacunes fonctionnelles • Manque de délégation ! • Charge importante pour la DSI • Manque de réactivité • Durée de propagation des modifications dans les bases institutionnelles

23. Objectifs • Prise en charge des « identités externes » • Délégation « au plus près » • Authentification forte • Maîtrise des processus métier • Maîtrise technologique • Évolutivité et ouverture

24. Prise en charge des identités externes • Comptes créés par les utilisateurs eux-mêmes • Numéro de téléphone, une adresse électronique, un identifiant Facebook, Twitter, LinkedIn, OpenID • Par défaut sans privilège

25. Vérification des identités externes • Vérification de l’identité • Existence de l’identifiant • Technique • Vérification de la personne • Association de l’identifiant à une personne physique • Organisationnel

26. Délégation « au plus près » • Amélioration des processus métiers • Au niveau de l’enregistrement des utilisateurs • Délégation des tâches administratives • Aux acteurs fonctionnels • Au plus près des utilisateurs finaux • Diminution de la charge de la DSI • Recentrage sur le cœur de métier

27. Authentification forte • Accès aux services sensibles • Conséquences financières et juridiques • SSO CAS : point faible • Évolution vers une authentification unique à plusieurs niveaux d'assurance • Certificat, OTP, double facteur • Mise en conformité avec les exigences réglementaires en vigueur

28. Maîtrise des processus métier • En particulier le deprovisioning • Lier l’utilisation des ressources au statut des utilisateurs • Condition sine qua non de la sécurité du système • Utilisation systématique (dès que possible) de Grouper • Pour la gestion des autorisations • deprovisioning automatique • Sensibilisation et formation des acteurs fonctionnels • Contrôle continu de la qualité des données

29. Maîtrise technologique • Pas de sécurité sans maîtrise technologique • Simplicité de maintenance • Évolutivité et pérennité • Utilisation uniforme de standards et de technologies ouvertes

30. Évolutivité et ouverture • Contexte politique • Contexte de fusion Rennes 1 / Rennes 2 • Hébergement d’autres établissements • Critère fondamental de choix des outils et technologies • Accueillir des identités d’un autre établissement • S’intégrer dans un autre système déjà existant

31. Exemple : allocation d’un accès wifi externe à un participant d’un congrès • Procédure • L’organisateur du congrès demande à la DSI l’autorisation d’allouer des comptes pour l’accès wifi • La DSI délègue la création des comptes • Après vérification de la qualité d’organisateur du demandeur • L’organisateur • Crée des comptes correspondant aux adresses électroniques des participants • Leur alloue l’accès au réseau wifi pour la durée du congrès • Vérification • Les adresses électroniques (base de données de l’organisation) sont vérifiées par un secret envoyé aux participants • L’identité des participants est considérée comme vérifiée par le paiement préalable des droits d’inscription au congrès

32. Choix techniques • Pistes explorées pour la mise en œuvre • Utilisation (et assemblage) de briques existantes • ETL Talend pour les opérations de provisionning • ActiveMQpour le séquencement • Grouper pour les autorisations • Développement interne (Java) pour l’interface utilisateur • Utilisation d’un framework spécialisé • Pour l’orchestration globale de toutes les opérations de gestion des identités • Grouper pour la gestion des autorisations. • Adoption de OpenIDM • Framework spécialisé

33. Processus de migration • La grande inconnue • Contraintes externes fortes • Migration ToIP • Migration messagerie • Fusion Rennes 1 / Rennes 2 • Continuité du service • Date de recette prévue : fin 2014