Les attaques impliquant ces chaînes d’approvisionnement introduisent de nouveaux risques dans les systèmes d’information. Des intrusions peuvent entraîner des fuites de propriété intellectuelle, des altérations de code source, des interruptions de service ainsi que des élévations de privilèges vers des parties plus critiques du SI.  

Quels sont donc ces nouveaux vecteurs d’attaques sur les chaînes CI/CD et comment s’en protéger ? Cet article vise à dresser un panorama de chemins de compromission observés sur le terrain, ainsi que des recommandations pour les contrer. 

Quels risques pour les chaînes CI/CD ? 

L’attaque de SolarWinds en 2020 est un exemple qui ne cesse d’être énoncé, mais qui a mis en lumière l‘ampleur qu’une attaque de ce type peut causer. Après avoir vraisemblablement volé des identifiants FTP laissés en clair dans un ancien dépôt GitHub, l’opération a exploité la chaîne d’approvisionnement de SolarWinds en insérant un beacon C2 (Command & Control) dans leur logiciel de gestion réseau, Orion, en amont du processus de signature. 

Cette backdoor a permis aux attaquants d’accéder aux réseaux internes de plusieurs agences gouvernementales américaines et entreprises privées, et ce, pendant plusieurs mois avant d’être détectée. 

Cet incident, ainsi que des plus récents comme Log4Shell, Codecov et XZ Utils, ont non seulement souligné la nécessité d’une sécurité accrue dans la chaîne CI/CD mais aussi celle d’une réponse à incident beaucoup plus adaptative. L’OWASP présente de façon concrète un panorama des surfaces de risques les plus communes dans leur Top 10 CI/CD Security. 

Fig 1 – Top 10 OWASP CICD-Sec 

Quels retours terrain chez Wavestone ? 

Les audits et tests d’intrusion permettent de détecter des vulnérabilités de façon proactive avant qu’elles ne soient exploitées par des attaquants. En simulant de réelles attaques, ces évaluations offrent une perspective pratique sur la manière dont un système peut être compromis, ce qui permet d’appréhender plus concrètement les potentielles failles dans un système. 

Les différentes interventions menées chez nos clients nous permettent de faire un constat clair : 

• Dans nos audits Cloud et CI/CD, des vulnérabilités sont systématiquement trouvées au niveau des chaînes CI/CD, permettant dans la majorité des cas de prendre le contrôle de la chaîne, des artefacts, voire des infrastructures sous-jacentes.  
• De même, au niveau de nos interventions CERT & RedTeam, nous observons que les chaînes CI/CD sont souvent utilisées comme accélérateur dans les chemins de compromission. 

Regardons ensemble deux exemples d’attaque observés par nos équipes d’audit : 

Ce premier test d’intrusion en boîte grise a permis la compromission totale d’une organisation Cloud AWS (600+ comptes) en partant de comptes standards de DevOps. 

Dans ce scénario d’attaque, 

• Un attaquant pousse du code malveillant vers un repository GitLab, déclenchant une pipeline dans GitLab CI qui déploie ce code dans un pod Kubernetes générique. 
• Ce code ouvre un reverse shell, permettant à l’attaquant de se connecter à distance à l’environnement Kubernetes. 
• Depuis ce pod, l’attaquant exploite le fait que le compte de service associé au nœud dispose de privilèges trop élevés (capacité de patcher des jetons dans le cluster) et patch le jeton du nœud administrateur par un jeton générique. 
• Quand un redéploiement est déclenché, le pod malveillant ne peut qu’être déployer sur l’ancien nœud administrateur bénéficiant toujours des droits admin. 
• Cela permet donc à l’attaquant d’obtenir des privilèges élevés et de se latéraliser dans l’infrastructure AWS, compromettant ainsi le cluster Elastic Kubernetes Service (EKS) et les ressources associées. 

Regardons maintenant un deuxième exemple : 

Fig 3 – Condensé de plusieurs typologies d’attaques observées dans les CI/CD de nos clients 

Ce condensé, présenté à la DefCon & BSides 2022, met en évidence comment différents composants d’une chaîne peuvent être utilisés dans une attaque. Retrouvez cette présentation détaillée sur les nouveaux vecteurs d’attaque liés aux CI/CD en vidéo ! 

Quelles recommandations pour sécuriser sa chaîne CI/CD ? 

La chaîne CI/CD est désormais devenue un composant systémique des systèmes d’information pouvant être utilisée afin de compromettre des ressources critiques d’une entreprise. 

Nos recommandations en matière de sécurité de la chaîne CI/CD peuvent être articulées autour de trois grands axes : la gestion des identités et des accès (IAM), une meilleure conception de la chaîne CI/CD, ainsi que sa surveillance. Ces recommandations suivent notamment le guide DevSecOps de l’ANSSI. 

Fig 4 – Trois grands axes de recommandations pour sécuriser une CI/CD 

Gestion des identités et accès (IAM) 

Fig 5 – Recommandations IAM

Gestion des identités 

Outre les règles traditionnelles de gestion du cycle de vie des identités, il est recommandé d’utiliser systématiquement du Single-Sign On (SSO) avec authentification multifacteur (MFA) afin de réduire significativement le risque d’intrusion en CI/CD. Cela assurerait par exemple que les utilisateurs qui accèdent aux dépôts de code, qui signent un commit ou effectuent tout autre action privilégiée soient légitimés. 

Contrôle des accès 

Il est nécessaire de limiter au maximum les droits des utilisateurs et des comptes de service selon leur fonction dans la chaîne CI/CD, toujours en suivant le principe du moindre privilège. Les comptes sans mot de passe gérés par jetons d’accès doivent également être soumis à une gouvernance claire, avec des règles de cycle de vie, de rotation et de recertification régulière pour réduire les risques liés à leur utilisation. 

Cela peut aussi se faire en passant par du contrôle d’accès basé sur les rôles (RBAC). Par exemple, il ne serait pas utile de manière générale de donner un accès en écriture sur la configuration de la chaîne en elle-même à un développeur travaillant sur un projet spécifique. 

De la même façon, il est pertinent de segmenter ses projets en utilisant différents dépôts de code et de s’assurer que le compte orchestrateur d’un projet n’ait pas des droits excessifs sur le déploiement des projets auxquels il n’est pas rattaché. 

Gestion des secrets 

Les secrets en CI/CD désignent des données sensibles telles que des mots de passe, des clés d’API, des certificats ou des jetons d’accès. Ces secrets permettent notamment d’effectuer des actions privilégiées dans les pipelines et doivent être récupérés de façon automatique. 

Des éditeurs comme HashiCorp proposent des solutions de gestionnaires de secrets pour stocker facilement ses données sensibles et les chiffrer en transit et au repos.  

Conception de la CI/CD 

Fig 6 – Recommandations sur la conception d’une CI/CD 

Segmentation des environnements 

Il est nécessaire de préserver le cloisonnement entre les utilisateurs, les applications et l’infrastructure pour minimiser les impacts en cas de compromission. Reprenant des conseils de l’ANSSI, il faut considérer les actions réalisées par la chaîne CI/CD de production comme des actions d’administration et réduire au maximum le nombre d’utilisateurs pouvant y accéder. De plus, il est nécessaire d’utiliser du chiffrement bout à bout et de s’assurer qu’aucun environnement n’est exposé sur internet. 

Intégration d’outils tiers 

De la même manière que l’attaque SolarWinds, un grand nombre d’attaques de type supply-chain sont à l’origine un composant tiers compromis dans une chaîne CI/CD. Ces outils tiers sont souvent indispensables au bon fonctionnement des chaînes d’approvisionnement, ils peuvent aller d’un simple add-on sur un espace de développement, jusqu’à un outil de contrôle de version ou un orchestrateur. 

Généralement, ces outils se voient accorder des droits leur permettant d’accéder à des ressources sensibles ou d’effectuer des actions spécifiques au sein de la chaîne CI/CD. Si une vulnérabilité sur un outil n’est pas patchée et est exploitée par un attaquant, la capacité d’intervention sera limitée car la résolution de la faille dépendra souvent du fournisseur de l’outil. Il convient donc d’adopter une gouvernance stricte et un processus de Third-Party Cyber Risk Management (TPCRM) pour ces outils tiers. 

Gestion des artefacts 

Pour éviter de stocker des artefacts malveillants, il est recommandé de les signer en amont de la chaîne pour assurer leur intégrité en vérifiant cette signature au moment de leur déploiement. De la même façon, il faut s’assurer de ne pas déployer des librairies malveillantes en réalisant des scans Software Composition Analysis (SCA) régulièrement. 

Surveillance de la chaîne  

Fig 7 – Recommandations de surveillance 

Journalisation et détection 

Garder un haut niveau de visibilité et de contrôle sur tous les composants de la chaîne permet d’assurer une maintenance plus facile et une réponse plus rapide en cas d’attaque.  

Premièrement, il faut mettre en place une stratégie de journalisation adaptée, en maintenant des logs contenant uniquement ce qui est utile à la traçabilité et la responsabilité en cas d’incident. Il faut aussi s’assurer de stocker ces logs de façon sécurisée, ne pas y laisser des secrets en dur, ainsi que les partager efficacement à son Security information and Event management (SIEM). 

Aussi, pour réévaluer sa posture de sécurité et limiter au maximum les possibles chemins de compromission du pipeline CI/CD, des audits et des tests d’intrusion réguliers sont nécessaires.  

Réponse à incident 

Enfin, il faut s’assurer d’inclure sa chaine CI/CD dans ses plans de réponses à incident au même titre que n’importe quel autre périmètre de son système d’information. Il convient par exemple d’avoir des sauvegardes de son code source et ses configurations ainsi que des plans de continuité d’activités en cas de panne d’un outil. 

En conclusion 

Les chaînes CI/CD sont devenues une véritable pierre angulaire dans les systèmes d’information. Ces composants systémiques sont aujourd’hui indispensables pour développer et déployer des applications. Pourtant, leur criticité dans les SI appelle à mettre en place des mesures de sécurité adaptées pour qu’elles ne deviennent pas un vecteur d’attaques.  

Fig 8 – Quelques composants systémiques et critiques en CI/CD 

Outre les recommandations de cet article, d’autres mesures préventives peuvent se traduire plus précisément par des guides de durcissement pour des outils particuliers d’une chaîne. L’adoption d’une stratégie pertinente de formation des utilisateurs ainsi que de conduite du changement est aussi nécessaire pour réussir ces transformations.  

Un grand merci à Jeanne GRENIER pour sa précieuse contribution à la rédaction de cet article.

Cet article CI/CD : la nouvelle pierre angulaire du SI ?  est apparu en premier sur RiskInsight.

Afin d’accompagner cette évolution, l’Union européenne avait instauré la Directive sur les Services de Paiement. Dans sa deuxième version (DSP2), publiée en 2015, cette directive a voulu la création et la régulation du secteur de l’Open Banking. L’objectif était de permettre aux utilisateurs de laisser un accès à leurs données bancaires à de nouveaux acteurs innovants tels que les initiateurs de paiement et les agrégateurs, tout en favorisant la sécurité et la compétition au sein de l’écosystème des services de paiement.

Malheureusement, la DSP2 présente des limites dont :

• Un problème d’harmonisation des législations conduisant au « forum shopping » qui consiste, pour les fournisseurs de services de paiement, à choisir leur pays d’installation en fonction de la législation locale la plus arrangeante à leur égard.
• Un écart qui n’a pas été suffisamment comblé entre les banques, qui sont en position privilégiée pour fournir des services aux consommateurs, et les prestataires de services de paiement qui en dépendent.
• La fraude, pour laquelle les méthodes employées évoluent rapidement, et pour laquelle les provisions de DSP2 sont maintenant insuffisantes.

C’est pour cela que l’Union Européenne a publié un projet de DSP3 le 28 juin 2023, et une version finale est attendue pour fin 2024 ou début 2025. Le texte sera alors applicable 18 mois après la publication, soit aux alentours du troisième trimestre 2026.

Comment uniformiser l’existant de la DSP2 ?

A la lecture de cette ébauche, il est clair que là où la DSP2 a instauré des concepts structurants et complètement nouveaux comme l’Open Banking ou l’Authentification Forte du Client, la DSP3 cherche à apporter une mise à niveau sur des concepts existants. Comme indiqué sur le site de la commission européenne, il s’agit d’

« une évolution, pas une révolution ».

La forme évolue : la DSP3 s’accompagne d’un règlement, le RSP (Règlement sur les Services de Paiement). Dans son contenu, elle reprend beaucoup d’éléments présents dans la DSP2, ou ses RTS (pour Regulatory Technical Standards ou Normes Techniques de Règlementation). La nouveauté vient du format : il s’agit d’un règlement, qui est donc directement applicable dans les états membres, au contraire des directives qui ont besoin d’être traduites en droit local. Il s’agit d’une des solutions que l’UE considère pour aborder le problème d’harmonisation mentionné précédemment.

Le cadre réglementaire des monnaies électroniques se retrouve aussi simplifié. Les difficultés pratiques liées à la différenciation existante entre les paiements en ligne, réglementés par DSP2, et l’utilisation de monnaies électroniques, réglementée par la Directive sur les Monnaies Electroniques de 2009 (DME) disparaissent puisque DSP3 couvre maintenant ces deux types de services.

En outre, bien qu’il ne s’agisse pas de nouveautés à proprement parler, DSP3 apporte un lot de clarifications dans ses définitions :

• Les comptes de dépôt, tels que les livrets, sont explicitement exclus de la définition de comptes de paiements.
• Les agrégateurs sont définis par leur capacité à collecter et consolider de l’information sur les comptes de paiement, et ce même si l’utilisateur détenteur des comptes n’est pas le destinataire de l’information agrégée.
• Les authentifications multi-facteurs reposent sur deux facteurs dans les catégories classiquement définies (ce que je sais, ce que je suis, ce que je possède), mais il n’est pas nécessaire que les deux facteurs soient de catégories différentes, seulement qu’ils soient indépendants (défini comme : la compromission de l’un n’affecte pas le niveau de sécurité de l’autre).

Que devront faire les différents fournisseurs de services de paiement pour se conformer à la DSP3 ?

Les évolutions phares de la DSP3 portent sur des changements techniques visant protéger le consommateur contre la fraude.

Ainsi, les prestataires de services de paiement vont devoir proposer de nouveaux services. Un premier exemple consiste à fournir à l’utilisateur un tableau de bord de permissions permettant de vérifier à tout moment qui est autorisé à accéder aux données des comptes de paiement. Un autre exemple est le service de vérification du nom du détenteur du compte bénéficiaire d’un paiement, visant à informer l’utilisateur d’une éventuelle usurpation d’identité.

De même, la DSP3 s’intéresse à l’accessibilité pour tous de l’authentification forte. Toutes les banques devront avoir la capacité de fournir un moyen d’authentification adapté à tous leurs utilisateurs, y compris les personnes en situation d’handicap, les personnes âgées, les personnes ayant des faibles compétences numériques ou sans smartphone etc…

L’ajout d’un nouvel acteur en particulier va changer la répartition des responsabilités de conformité : il s’agit des prestataires de services techniques. Ces derniers hériteront d’une partie de la charge de mise en conformité et d’audit, en particulier pour ce qui touche à l’authentification forte du client, lorsque celle-ci est gérée par une solution tierce.

Quels seront les impacts de ces changements ?

Les banques et autres prestataires de paiement sont incités par les changements de la DSP3 à s’échanger des informations pour lutter contre la fraude : des dispositions sont d’ailleurs prévues pour pouvoir le faire dans le respect de la RGPD.

En particulier pour la vérification du nom du détenteur du compte bénéficiaire, cela signifie que les APIs d’Open Banking devront être mises à jour pour pouvoir permettre cette vérification par la banque du payeur. A cause de la complexité de cette opération, à plus forte raison pour les paiements instantanés, l’article associé entrera en vigueur 2 ans après le reste (donc pas avant le troisième trimestre 2028).

Les utilisateurs vont aussi voir apparaitre de nouvelles fonctionnalités, et un temps d’adaptation sera nécessaire pour qu’ils se familiarisent avec ces nouveautés. Un accompagnement devra être mis en place afin de faciliter la compréhension et favoriser l’adoption de ces nouvelles fonctionnalités.

Si le texte final est publié début 2025, les entreprises du secteur des paiements auront jusqu’au troisième trimestre 2026 pour se mettre en conformité.

Il est essentiel de prendre en compte ces changements dès aujourd’hui et d’assurer une veille réglementaire pour se tenir informé des différents textes (RTS, guidelines) qui seront publiés à la fois par la commission européenne et l’Autorité Bancaire Européenne.

[1] Rapport annuel de l’Observatoire de la sécurité des moyens de paiement 2023

Cet article Transition vers la 3e Directive sur les Services de Paiements : quels impacts ? est apparu en premier sur RiskInsight.

Aussi, malgré de belles réussites et le rôle cardinal de l’identité dans les transformations des entreprises, l’IAM demeure une thématique dénigrée dans les organisations, synonyme de « mal nécessaire » plutôt que « d’enjeu clé » pour l’entreprise.

Comment redorer le blason de l’IAM ? Comment mieux l’expliquer pour lui donner sa juste place dans l’entreprise ?

Le paradoxe de l’identité

Un moteur essentiel des programmes de transformation…

Cette situation est paradoxale tant l’identité joue un rôle fondamental dans les programmes de transformation actuels, en présentant trois atouts majeurs.

• Elle est tout d’abord un pilier de la cybersécurité en permettant de :
  • Disposer d’une connaissance homogène de l’ensemble des utilisateurs, en centralisant les informations essentielles comme le nom, le manager, la fonction et bien d’autres caractéristiques propres à chacun ;
  • Garantir l’unicité des personnes via la publication d’un référentiel unique ;
  • Contrôler et adapter les accès des utilisateurs tout au long de leur cycle de vie ;
  • S’inscrire dans une démarche Zero Trust en veillant à ce que seules les bonnes personnes, avec le bon niveau de droit et le bon niveau d’authentification accèdent aux ressources appropriées.
• Elle constitue également un facilitateur métier essentiel, notamment pour :
  • Accélérer l’adoption de service Cloud, et le déploiement de nouvelles applications grâce à la création automatique de comptes et l’attribution simplifiée des droits (souvent par le biais d’un outil IGA – Identity Governance & Administration) ;
  • Faciliter l’ouverture contrôlée du SI à et vers des tiers : des partenaires, des fournisseurs ou en cas de création de Joint Ventures ;
  • Améliorer, grâce au CIAM (Customer Identity and Access Management), la relation client et la mise en conformité réglementaire en simplifiant la création progressive des comptes et le respect des règlements sur la vie privée tels que la RGPD en France.
• Enfin, avoir une gestion des identités efficiente est une condition sine qua none pour offrir une expérience utilisateur à l’état de l’art, combinant confort et exigences de sécurité :
  • Un accès fluide et sans couture à toutes ses applications et ses données, quel que soit son contexte d’accès ;
  • Des droits d’accès accordés automatiquement et disponibles le jour de son arrivée ;
  • D’un portail unique pour effectuer et suivre ses demandes ad hoc.
  • Des tableaux de bord parlants et des campagnes de revues ciblées pour répondre aux exigences réglementaires sans sur-solliciter les managers et les process owners.

… mais une thématique injustement considérée

Malgré les avantages significatifs qu’elle représente, la thématique de l’identité est rarement au centre des préoccupations des entreprises. Elle est plutôt perçue comme un mal nécessaire, voire occupe une place de « vilain petit canard ». Ainsi, il est commun de constater les écueils lorsque l’identité est insuffisamment bien gérée, et encore plus courant de considérer comme normaux et acquis les avantages qu’elle produit.

Au-delà du simple constant, il convient de comprendre les raisons qui ont mené à cette situation de manque d’investissements, de sponsoring, voire de reconnaissance.

Première explication du paradoxe : la dispersion des gains attendus vers différents bénéficiaires. En effet, l’IAM est, par nature, très transverse dans l’entreprise. Pour réussir, elle se doit d’embrasser un large panel de sujets et mobilise donc de nombreuses parties prenantes. Si chacune d’elles y verra des gains ; aucune ne se démarquera suffisamment pour endosser la responsabilité première. À titre d’exemples :

• L’identité permet de simplifier la mise en relation client, sujet d’intérêt majeur pour un responsable marketing/digital, mais pas pour le responsable conformité.
• Ce dernier verra dans l’identité un avantage significatif pour répondre aux exigences des commissaires aux comptes en matière de revue des accès.
• Le DSI attendra de l’identité une gestion homogène et automatique de l’attribution des comptes et des droits, synonymes de gains financiers, notamment en coûts de licences, en charge de support, etc.
• Quant au RSSI, sa priorité sera de supprimer les accès en cas de départ et d’appliquer le principe de « moindre droits attribués » ou encore la détection au plus tôt des comportements « suspects ».

Deuxième explication : comme toute transformation, qui plus est transverse, le lancement et la réussite d’un projet d’identité sont conditionnés par des prérequis indispensables.

La difficulté et l’effort nécessaire pour réunir ces prérequis dépendent du contexte de chaque entreprise ; mais les prérequis eux-mêmes sont relativement constants et peuvent s’articuler autour de 4 axes :

• La qualité des données : aussi bien pour les données consommées par l’IAM (organisations, structures, données d’identité provenant des RH…) que pour les données que l’IAM doit mettre à disposition (identifiants des comptes applicatifs, attributs dans les applications…).
• La connaissance profonde des processus de bout-en-bout : celle-ci est indispensable pour prévoir les impacts sur les utilisateurs des changements à venir mais surtout pour être en capacité de changer et d’harmoniser les manières de faire et ne pas reconduire l’existant « parce que l’on a toujours fait ainsi ».
• La maîtrise des applications à raccorder : il est nécessaire de mobiliser à la fois des sachants techniques (technologies utilisées, API disponibles…) et des sachants fonctionnels (populations utilisatrices, modèle de données, modèle d’habilitation…).
• Enfin et surtout, la capacité à imposer un cadre IAM « normatif », à trouver un compromis et à arbitrer tant sur la cible (modèle opérationnel, cadre fonctionnel, attributs et règles de gestion, processus d’arrivée/mobilité/départ, cadre de raccordement normé pour les applications…) que sur la trajectoire et les indicateurs de réussite (priorités, lotissement…). Pour le dire en une phrase « Ce n’est pas à l’IAM de panser ce qui a été mal pensé ou ce qui est devenu inadapté avec le temps».

Troisième et dernière explication : une gestion complète de l’identité repose sur plusieurs briques technologiques complémentaires. Avec des origines variées et des dénominations quelque peu ambigües, il n’est pas toujours facile pour un non-expert du domaine de comprendre précisément l’apport en propre de chacune de ces briques :

• IGA – Identity Governance & Administration: Gouvernance des identités
• IAI – Identity Analytics & Intelligence : Analyse et contrôle des données
• PAM – Privileged Access Management: Gestion des comptes à privilèges
• AM – Access Management: Authentification et contrôle d’accès
• CIAM – Customer Identity & Access Management: Gestion des identités clients

De plus, ces dénominations ont évolué dans le temps, parfois de manière légitime pour rendre compte d’évolutions majeures, parfois plutôt sous l’effet d’éditeurs souhaitant démarquer leur proposition de valeur. L’apparition de nouvelles fonctionnalités (détection temps réel, gestion du consentement, etc.) et les innovations proposées par les éditeurs font également évoluer le champ lexical de l’IAM.

Comment donner à l’identité sa juste place dans l’entreprise ?

Pour surmonter ce paradoxe, les pistes usuelles (sponsor de haut niveau, plus de moyens, évangélisation…) sont nécessaires mais souvent insuffisantes. Des transformations plus structurantes s’imposent.

Unifier les forces de l’identité sous une même bannière

Les thématiques IAM sont apparues en ordre dispersées dans les entreprises et ont muries à des rythmes très différents. Il en résulte que, encore trop souvent, les équipes sont isolées.

Il est donc impératif de rapprocher toutes les équipes et les budgets traitant de l’identité sous une même barrière. Et si l’union fait la force comme dit le proverbe, l’objectif n’est pas uniquement de « faire nombre » pour être visible, légitime et avoir voix au chapitre dans l’organisation.

Les synergies sont en effet nombreuses :

• Faire de l’identité un sujet pérenne et récurrent, a minima au niveau du CoDIR DSI, et dans toutes les évolutions de l’entreprise.
• Définir une proposition de valeur globale, proposer une offre unifiée plus lisible pour les métiers et les responsables applicatifs qui pourront s’appuyer sur un interlocuteur unique.
• S’inscrire dans la durée pour tirer parti des feuilles de route des éditeurs, créer une démarche d’amélioration continue et se préparer aux évolutions à venir de l’entreprise : réorganisations, fusions-acquisitions, nouvel ERP…
• Améliorer la cohérence des services IAM et se piloter avec des indicateurs de service de bout-en-bout.
• Garantir un haut niveau d’expertise en valorisant les savoir-faire des équipes, en les fidélisant et en offrant des perceptives d’évolution plus riches.

Cette transformation profonde peut apparaître comme délicate et source de risques pour les entreprises les moins matures en IAM. C’est pourquoi il est possible de l’initier progressivement, en partant d’un des axes suivants :

• Rapprocher sous une même organisation les équipes travaillant sur les différentes thématiques IAM : IGA, IAI, AM, PAM et même CIAM.
• Unifier les équipes en charge des projets et celles en charge du « RUN » afin de proposer une approche « produit » de chaque service d’identité, et s’inscrire dans une logique d’amélioration continue.
• Étendre la responsabilité des équipes IAM sur le contrôle des données enfin de pouvoir s’engager sur des indicateurs et, au final, sur la qualité du service rendu et perçu.

Sur ce dernier point, précisons néanmoins que les équipes IAM ne peuvent endosser la responsabilité de la qualité des données et des référentiels de l’entreprise. Il s’agira néanmoins de garantir la qualité du service rendu en s’assurant à la fois du bon fonctionnement des services IAM (le « contenant ») et de la qualité des données manipulées (le « contenu »). Ainsi, les équipes IAM doivent s’outiller et s’organiser pour superviser, contrôler et alerter la qualité des données reçues comme l’usage qui en est fait.

Une unification avantageuse mais qui oblige

Cette ambition d’unification, qui met l’IAM en pleine lumière, oblige de facto le responsable Identité à être exemplaire dans son rôle et ses responsabilités :

• Face à ses clients: disposer d’une offre de service claire, tenir compte des retours et des réalités du terrain, définir et respecter une feuille de route d’évolutions, fournir des indicateurs de qualité du service rendu « parlants » c’est-à-dire ayant un sens dans le quotidien des métiers, valoriser les gains et les bénéfices…
• Vis-à-vis des autres parties prenantes dans l’entreprise (RH, Achats, Cybersécurité, Conformité réglementaire, Audit et contrôle…) : communiquer, matérialiser et aider à l’appropriation de la proposition de valeur de l’Identité au quotidien et lors de transformations structurantes (réorganisations, acquisitions…), trouver des voies de compromis, monter le caractère « gagnant-gagnant » des évolutions de processus et de modèle opérationnel, partager les rôles et responsabilités de chacun, illustrer les impacts en cas de manquements…
• Pour ses équipes: disposer d’un modèle opérationnel robuste, équilibrer les responsabilités entre collaborateurs internes et prestataires externes, construire une véritable ambition RH à moyen et long terme (validation de l’expertise, gestion des talents, construction de parcours d’évolutions, valorisation de la filière IAM…).

Conclusion

L’unification des services IAM est une tendance de fond et, d’ici 3 ans, une large majorité des grandes entreprises aura convergé vers ce modèle, a minima partiellement.

Ce mouvement ne résulte pas toujours d’une volonté de repositionner de manière durable l’identité dans l’organisation. Il est parfois subi par les équipes pour pallier des manques de ressources, d’expertise ou dans un espoir de maîtrise des coûts ; renforçant dans ce cas le sentiment de manque de considération.

Pourtant, les opportunités sont nombreuses pour démontrer la nécessité de repenser en profondeur son ambition IAM et de lui donner sa juste place : obsolescence technique des outils IAM, stratégie d’entreprise pour basculer vers des solutions Cloud, difficultés à accompagner les transformations structurantes de l’organisation, nouvelles exigences réglementaires, ou résultats d’une simple enquête de satisfaction auprès des utilisateurs ou des responsables d’applications…

Oserez-vous les saisir ?

Cet article Comment donner à l’identité sa juste place dans l’entreprise est apparu en premier sur RiskInsight.

Depuis l’arrivée de Facebook en 2004, Internet a été témoin d’une explosion du nombre de réseaux sociaux, des plus généralistes aux plus spécialisés. Leur adoption et utilisation massive les positionnent comme des véritables mines d’or pour les entreprises, en leur offrant une porte d’accès à des données jusqu’alors inaccessibles (préférences de leurs clients, envies, intérêts…).

À l’heure où l’expérience utilisateur et la connaissance des clients deviennent des problématiques incontournables pour les entreprises, le social login semble être la solution rêvée… mais est-ce vraiment le cas ?

Chapitre 1 : la promesse

En 2018, nous comptons plus de 70 réseaux sociaux, dont les plus connus et utilisés restent Facebook, Google+, Twitter ou encore LinkedIn. Certains réseaux peuvent être même rattachés à des plaques géographiques ou pays particuliers, comme l’Asie avec WeChat, Weibo, Mixi ou et la Russie avec Vkontakte.

À titre indicatif, l’utilisation de réseaux sociaux est passée de 153 millions d’utilisateurs en 2011 à 837 millions en 2013, pour passer largement au-delà du milliard en 2017.

Les réseaux sociaux sont donc devenus de véritables référentiels d’identités, dont certains promettent de détenir l’Identité de référence sur Internet, les motivant à se positionner naturellement comme fournisseur d’identités pour les entreprises. C’est dans ce cadre et sur la base de cette promesse que le social login est né.

L’objectif premier du social login est de permettre à un utilisateur d’accéder aux services d’une marque ou boutique virtuelle le plus simplement possible, à l’aide d’un compte d’un réseau social.

Il s’affiche comme une réponse aux attentes des clients en simplifiant les processus d’enregistrement et d’accès aux services, mais également à celles des entreprises en donnant des moyens d’authentification rapides à déployer afin d’améliorer le taux de conversion des prospects.

Une solution pratique et simple à utiliser

Lorsque nous parlons de social login, nous distinguons deux cas d’usage :

• Social registration: utilisation d’un compte d’un réseau social (ex : Facebook, Google, Twitter, LinkedIn…) pour créer un compte sur une application
• Social login: utilisation d’un compte d’un réseau social pour s’authentifier sur une application pour laquelle le compte applicatif a été déjà créé via social registration

La cinématique décrite ci-après présente les étapes du social registration. La cinématique du social login est similaire et repose uniquement sur les étapes 1, 2 et 3.

Étape 1 – Accès initial au service

L’utilisateur accède à l’application (mobile ou web) d’une entreprise qui lui fournit des services et choisit de créer un compte depuis le réseau social de son choix.

Étape 2 – Authentification

L’utilisateur est alors redirigé vers le réseau social sélectionné pour s’authentifier selon le mécanisme en vigueur (ex : identifiant / mot de passe, code (OTP) envoyé par SMS…).

Dans l’éventualité où l’utilisateur a déjà une session active sur ce réseau social, il sera automatiquement authentifié (SSO – Single Sign On) et passera directement à l’étape suivante.

Étape 3a – Recueil du consentement

Le réseau social informe l’utilisateur que l’application souhaite accéder à des informations de son compte (ex : nom, prénom, date de naissance, liste des amis, préférences…) afin de lui créer un compte applicatif. L’utilisateur doit alors donner son consentement explicite pour que la cinématique se poursuive.

À noter que certains réseaux sociaux comme Facebook offrent la possibilité à l’utilisateur de visualiser en détail les informations que l’application souhaite recueillir afin de pouvoir gérer plus finement son consentement (étape 3b).

Étape 3b – Gestion fine du consentement

L’utilisateur visualise l’ensemble des informations que l’application souhaite recueillir. Il peut alors décocher celles qu’il ne souhaite pas partager. Toutefois, des informations peuvent être obligatoires pour que l’application puisse lui créer un compte applicatif et ne pourront être décochées par l’utilisateur (généralement l’adresse e-mail car souvent utilisée comme identifiant).

Étape 3 / Étape 3c – Redirection vers le service souhaité

L’utilisateur est alors redirigé vers le service souhaité. Éventuellement, l’affichage pourra être personnalisé pour montrer l’intérêt de partager les informations de son compte social (affichage de la photo de profil, contenus personnalisés sur la base des préférences de l’utilisateur…).

Un avantage concurrentiel pour les entreprises

Simplifier le processus de création

La conversion des prospects en clients est l’objectif principal des entreprises. L’un des premiers freins à cette conversion est le processus de création de compte. Selon une étude de WebHostingBuzz, plus de 86% de prospects abandonnent dès cette étape, souvent jugée trop longue et complexe.

Le social registration est une alternative de plus en plus adoptée par les entreprises : abandonner le formulaire de création de compte traditionnel pour mettre en avant l’utilisation d’un compte d’un réseau social. En d’autres termes, passer de plusieurs minutes à quelques clics.

Faciliter l’accès aux services

Simplifier le processus de création de compte n’est pas une fin en soi. Il faut également donner envie aux clients de revenir et consommer les services de l’entreprise, notamment en :

• Offrant une expérience utilisateur omnicanale: ne pas perdre le client en lui imposant des parcours différents en fonction du moyen d’accès utilisé
• Réduisant le nombre de mots de passe à retenir: favoriser l’usage d’un compte (i.e. : couple identifiant / mot de passe) déjà connu de l’utilisateur pour éviter de récréer un nouveau mot de passe

Le social login se positionne comme une solution permettant de répondre à ces problématiques : que ce soit depuis un ordinateur, un smartphone, une tablette, le client bénéficiera de la même expérience utilisateur (même cinématique d’accès), basée sur l’usage d’un compte social pour accéder aux services de l’entreprise, et ses partenaires.

Personnaliser l’expérience utilisateur

L’utilisation du social login permet d’accéder à un nombre important de données qualitatives sur les clients : données d’identité (nom, prénom, date de naissance), données de contact (adresse e-mail, numéro de téléphone…), données de préférences (intérêts, partages, likes) …

Des données jusqu’alors inaccessibles dans une gestion des identités clients classique le deviennent, qui offrent la possibilité aux entreprises de personnaliser davantage leur relation avec leurs clients :

• Affichage et communication personnalisés
• Proposition de contenu personnalisé
• Anticipation ou adaptation de services en ligne avec les intérêts des clients

La personnalisation de l’expérience utilisateur permettra aux entreprises d’instaurer un climat de confiance, proposer des services sur-mesure et fidéliser ses clients dans la durée.

Ils l’ont adopté… ou pas encore

L’adoption du social login est très disparate en fonction du secteur d’activité de l’entreprise et de la nature de ses relations avec ses clients. Nous distinguons deux typologies de clients :

• Les consommateurs: bénéficient des services d’une entreprise sans pour autant avoir de relation directe et/ou de contrat les liant (ex : j’achète une bouteille de soda dans mon magasin préféré, mais l’entreprise qui conçoit ce soda ne me connait pas forcément)
• Les clients directs: bénéficient des services d’une entreprise sur la base d’un lien direct (contrat, comptes bancaires…), nécessitant une relation de proximité entre l’entreprise et le client

Selon une étude Wavestone réalisée en mars 2018 sur un échantillon de 172 marques majeures réparties dans tous les secteurs d’activité, 32% d’entre elles ont adopté le social login.

Ce constat met en lumière une adoption forte par les entreprises ayant des clients de type « consommateurs », dont l’objectif est de vendre rapidement des services de consommation (VOD, matériels, presse…).

À contrario, peu, voire pas du tout, d’entreprises ayant des clients directs adoptent le social login, leur relation débutant par l’établissement d’un contrat (et donc la création d’un compte avec des données vérifiées par l’entreprise (carte d’identité, justificatif de domicile…)). Toutefois, certaines de ces entreprises ont déjà commencé à instruire le social login dans leur feuille de route de services numériques, et il commence à s’imposer comme une norme au regard de l’arrivée d’un nouveau type de clients : la génération Z.

Parmi les entreprises ayant adopté le social login, Facebook et Google+ sortent du lot avec un taux d’adoption respectivement de 100% et 55,4%. Suivent LinkedIn (15,4%), Twitter (12,3%) et Yahoo (9,2%).

Du rêve à la réalité

La transformation numérique et l’évolution de la relation client repositionne l’expérience utilisateur au cœur des réflexions stratégiques des entreprises.

Simplicité, efficacité, fidélité sont les maîtres-mots de la nouvelle relation client, trois enjeux pour lesquels le social login semble être un accélérateur à considérer.

Toutefois, son déploiement n’est pas une évidence, ni même opportun pour toutes les entreprises (en fonction du secteur d’activité, des populations cibles, de la typologie de clients…) et requiert le respect de certaines bonnes pratiques de sécurité et de protection des données personnelles.

Pour plus de détails, rendez-vous au prochain article : « Chapitre 2 : La réalité ».

Cet article Social Login : faire d’un rêve une réalité (1/2) est apparu en premier sur RiskInsight.

Ces dernières années, les entreprises ont fait face à un élargissement du champ d’action de l’Identity and Access Management. Cette discipline n’est plus uniquement centrée sur les problématiques de provisioning utilisateur et d’authentification ; elle s’est tournée non seulement vers des problématiques de revue et de certification des comptes mais aussi vers l’utilisation des mécanismes de fédération d’identités (eg. SAML). Ces changements concernent aussi bien les applications SaaS que les applications restées en interne. Ces évolutions ont chacune permis une ouverture du SI toujours plus large, et nécessitent par conséquent d’être correctement implémentées pour limiter les failles de sécurité.

Cette évolution de l’IAM se fait en parallèle de la généralisation des services Cloud, qui ne cessent de donner naissance à de nouveaux usages pour plus de flexibilité et de souplesse dans l’accès et l’utilisation du SI. Les utilisateurs internes accédant au SI le font de plus en plus majoritairement depuis l’extérieur du réseau de l’entreprise, et ce depuis des terminaux de plus en plus variés.

En outre, les nouvelles technologies agiles et DevOps poussent le SI à évoluer différemment, intégrant beaucoup plus rapidement de nouvelles technologies (IoT, etc.) et de nouveaux usages.

Toutes ces évolutions font aujourd’hui du SI une bulle parmi d’autres interagissant avec son environnement et devant maîtriser, à distance, des interactions entre des composants décentralisés.

… rendant les APIs incontournables

Ce nouveau modèle décentralisé du SI donne naissance à la problématique d’interconnexion des services et des applications : comment assurer l’accès aux données à chaque instant et en chaque endroit ?

Aujourd’hui les APIs (Application Programmable Interface) représentent déjà un mécanisme de communication prépondérant et incontournable pour toute entreprise lancée dans sa transformation numérique. Elles sont utilisées dans  les traitements réalisés non seulement sur des données publiques (adresses d’agences, horaires des transports, etc.) mais aussi sur des données personnelles (tracking fitness, application Ameli et CAF, etc.) et des données sensibles (DSP2, achat en ligne, informations industrielles en mobilité, etc.).

Quelle recette pour sécuriser ses API ?

La sécurisation des API passe par une recette à base de 4 ingrédients à doser finement.

Une base de security as usual

Selon un benchmark Wavestone sur le sujet de la sécurité des applications web, sur 128 applications auditées, des failles graves sont observées dans 60% des cas et la situation est très similaire pour les APIs. À cet effet, les recommandations habituelles de la sécurité web, par exemple celles d’OWASP doivent être prises en compte de la même manière.

Il s’agit essentiellement de s’assurer de couvrir les principales zones à risques d’une application web et de déterminer les mesures de sécurité appropriées.

Une pincée d’OAuth

OAuth est un framework de délégation d’autorisation qui permet à une application d’obtenir l’autorisation d’accès à une ressource au nom d’un utilisateur.

OAuth se propose de couvrir un large éventail de cas d’usages (applications web, mobile, accès ou non à un navigateur, accès serveur-à-serveur, etc.) et offre à cet effet 4 cinématiques principales pour obtenir un jeton. Combiné à une spécification détaillant l’utilisation de ce jeton, un document détaillant le threat model, et enfin une surcouche dédiée à l’authentification (OpenID Connect), il s’agit d’un corpus documentaire équivalent à 250 pages, laissant une place certaine à un grand nombre d’options et de choix d’implémentation.

Et c’est bien cette abondance d’options et ce manque de contraintes qui entraînent les failles de sécurité observées régulièrement dans la mise en place d’OAuth2.0 : usurpation d’identité d’une application, accès aux données personnelles d’un utilisateur tiers, vol de cookie Facebook/Google lors d’un social login ou encore compromission de compte utilisateur.

Les six recommandations suivantes sont essentielles pour une mise en place sécurisée du Framework :

• Secret local : L’application est munie d’identifiants lui permettant de s’authentifier auprès du serveur OAuth : ne pas mettre ce secret (identifiant du service) dans l’application mobile ou le considérer compromis
• Redirect URI: Valider strictement les URLs de redirection vers l’application, sans wildcard
• Implicit: Éviter le « Implicit grant » dans la mesure du possible (et se tourner vers le proxy pattern)
• Authorization code: Valider strictement les authorization codes et clients associés
• State and PKCE: À utiliser pour garantir l’intégrité d’une cinématique complète
• Authorization ≠ Authentication: Utiliser OpenID Connect pour authentifier, OAuth pour déléguer l’accès

Limitez les additifs

À peine cette première pincée d’OAuth digérée, il faut déjà réfléchir à des solutions de sécurité permettant de répondre aux besoins que nous rencontrons le plus fréquemment.

Le Single Sign-On mobile, ou comment permettre à des employés en mobilité ou des clients d’accéder aisément aux applications sans se réauthentifier ?

Qu’il s’agisse d’un agent terrain en contact clientèle ou en tournée d’intervention qui peut utiliser plus d’une dizaine d’applications par jour ou qu’il s’agisse d’un client ayant installé plusieurs applications sur le store public, le besoin d’accéder à l’ensemble des applications sans avoir à se réauthentifier sur chacune est aujourd’hui très présent. Si, depuis 2008, les techniques le permettant ont varié au gré des possibilités offertes par les OS mobiles (KeyChain iOS, paramètres d’URL, Mobile Device Management…), Apple et Google ont convergé vers une solution commune en 2015 : utiliser le navigateur système comme point d’ancrage d’une session SSO. C’est maintenant une bonne pratique officielle matérialisée par la BCP « OAuth2 for native applications »

L’authentification contextuelle, ou comment adapter le niveau d’accès à une donnée en fonction de la criticité de celle-ci ?

Un des nombreux enjeux concernant l’authentification est de simplifier au maximum l’accès des utilisateurs à leurs données tout en garantissant un niveau de sécurité satisfaisant. L’authentification contextuelle permet de répondre à cet enjeu, en adaptant le niveau d’accès à la nature de la transaction, à ses caractéristiques, aux habitudes utilisateurs, à son contexte…. On parle de LOA (Level of Assurance). Dans le cadre d’une application mobile bancaire, cela permet à l’utilisateur de consulter son compte en banque, de bénéficier de la météo de ses comptes sans avoir à se réauthentifier à chaque accès. L’application requerra toutefois une authentification au moment de réaliser une opération sensible (un virement interne par exemple), et une authentification forte au moment de réaliser une opération très sensible (ajout d’un bénéficiaire par exemple).

Les solutions du marché proposent aujourd’hui des solutions pensées selon une logique où le client applicatif est responsable d’initier la demande de LOA correspondant à la donnée ou au service auquel il souhaite accéder. Mais le vrai besoin consiste à définir et appliquer ces politiques d’accès aux données de manière centralisée, au sein du serveur d’autorisation. Il s’agit notamment d’un besoin essentiel lorsque l’on veut appliquer une authentification liée au niveau de risque du contexte (géolocalisation, terminal connu ou non, habitudes de transactions, etc.)

Propagation de l’identité, ou comment transmettre un jeton d’accès entre deux applications (ou plus) ?

Il est courant qu’un appel vers une API déclenche une cascade d’appels vers d’autres API, notamment dans le cadre d’une architecture de type micro-service. La transmission de l’identité de l’utilisateur doit alors être assurée sans créer de risque de sécurité. Et les trois premières solutions qui viennent à l’esprit présentent des limites :

• La transmission du token initial est évidement à proscrire, à la vue du risque de fraude interne très élevé que cela entrainerait.
• L’authentification de l’appelant seule n’est pas suffisante non plus, car un composant compromis dans la chaîne peut usurper l’identité de n’importe quel utilisateur et compromet le reste de la chaîne.
• La génération d’un token pour l’appelant transmis avec le token de l’utilisateur initial ne permet pas d’assurer l’intégrité de la combinaison utilisateur/API et ne permet pas de vérifier la chaine.

Une ébauche avancée de solution existe aujourd’hui, proposant un nouveau grant type : Token Exchange. Ce mécanisme permet à l’appelant de demander un jeton intermédiaire, composé notamment de l’identité de l’utilisateur, de l’identité de l’appelant et de la chaine d’appel déjà effectuée. Cette nouvelle cinématique permet de centraliser la politique d’appel entre micro-service et l’application de cette politique, et d’assurer la traçabilité des appels.

Protection contre le vol de jeton, ou comment se prémunir du vol d’un ou d’une base de jetons ?

Par principe, le jeton contient de nombreuses informations sur son porteur, ce qui entraîne un risque important en cas de vol. Plus impactant encore, dans certains contextes (e.g. DSP2), un tiers (agrégateur) peut se retrouver en possession de très nombreux jetons, et le propriétaire de l’API se retrouve à la merci de ce tiers et de son niveau de sécurité. La détection du vol étant très difficile, il a fallu trouver d’autres solutions comme le Token Binding, un mécanisme de négociation à deux ou trois composants, permettant de lier un jeton à une paire de clés cryptographiques, et dans lequel le client doit prouver qu’il possède la clé privée constituant une partie de cette paire en établissant une connexion TLS mutuelle avec l’API.

Écrire la recette

Dernier ingrédient de la recette, il convient de décliner une architecture de référence de OAuth pour l’adapter au contexte du SI de l’entreprise. Pour cela, il faut définir le cadre d’utilisation des API en :

• Définissant et partageant les règles de sécurité : Les cinématiques autorisées et le cadre d’application, les checklists sécurité et l’architecture de référence doivent être formalisées.
• Formant et outillant les développeurs: Des sessions de formation et de présentations des principes adoptés doivent être organisées. Les équipes projets peuvent être rendues autonomes dans leur intégration au reste du SI.
• Intégrant les ressources sécurité dans les sprints agiles: Les ressources agissant en tant que coach sécurité doivent être identifiées pour accompagner la conception applicative et apporter des solutions prêtes à l’emploi et être un accélérateur

En synthèse

Au final, comme la recette du bon miel, sécuriser des APIs nécessite une succession d’ingrédients allant du plus basique jusqu’au plus élaboré tout en tenant compte du besoin et du contexte.

Cet article La sécurité des APIs ou la recette du bon miel est apparu en premier sur RiskInsight.

Dans ce contexte, la grande majorité des entreprises a mené des projets d’IAM : les accès aux applications sensibles sont étroitement contrôlés et les niveaux d’accès sont restreints selon les profils des utilisateurs et les actions à réaliser.

Or, trop souvent, ces démarches IAM « oublient » les populations IT qui ont pourtant des accès privilégiés sur l’infrastructure de l’entreprise. Et pour ces derniers, plusieurs spécificités sont à prendre en compte.

Les utilisateurs IT ont des besoins d’accès différents

Les utilisateurs « non-IT » représentent les utilisateurs « standards » du SI : utilisateurs des directions métier ou des fonctions support comme RH, paie, ou comptabilité… Ils accèdent classiquement :

• Aux applications en environnement de production,
• Et via les IHM standard de celles-ci.

Les populations « IT » (service informatique interne, télémaintenance, support…) ont quant à elles des accès très différents :

• Elles opèrent les infrastructures (serveurs, bases de données), et le code applicatif, sur lesquels reposent les applications ;
• Elles accèdent à tous les environnements et en particulier production et hors-production (ces derniers contenant souvent des données de production ou à caractère sensible ou personnel) ;
• Très souvent, elles opèrent avec des niveaux de droits (des « privilèges ») très élevés, présentant donc un niveau de risque non négligeable.

Ainsi, la terminologie « accès à privilèges » désigne tout accès technique, sur une infrastructure ou une brique logicielle, dans des environnements de production ou hors-production.

Ces accès sont parfois créés pour des individus, ou pour les applications elles-mêmes (une application a besoin de plusieurs comptes techniques, comme pour écrire dans une base de données).

On distingue différents niveaux d’accès « à privilèges ». Les plus critiques, de niveau « administrateur », offrent un contrôle total d’un ou plusieurs serveurs, et donc potentiellement plusieurs applications. Les accès IT de niveau « standard » sont moins sensibles mais restent à surveiller. Ces derniers pourraient permettre, par exemple, de consulter des informations sensibles dans une base de données.

Accès IT, risques métier

Par définition, la maitrise des accès privilégiés des populations IT doit être au cœur des préoccupations des entreprises.

Parmi les risques les plus importants, nous retrouvons :

• Les risques opérationnels, sans impact sur la production

Exemple : des traces d’exploitation sont supprimées par erreur ou un serveur non critique est éteint.

• Les risques sur l’activité de l’entreprise

Exemple : indisponibilité de la plateforme de flux des paiements / transaction suite à un redémarrage des serveurs par erreur.

• Les risques de non-conformité aux régulations

Exemple : mise en évidence d’un accès non-justifié sur un périmètre régulé suite à un audit interne.

• Des actions frauduleuses

Exemple : délit d’initié commis grâce à une information sensible consultée directement depuis une base de données.

Sans compter les risques plus larges autour du système d’information : vol de données, ransomwares et autres actions malveillantes. Parce qu’ils sont puissants (et permettent notamment de désactiver les mesures de sécurité), les accès à privilèges sont des cibles de choix en cas de cyber-attaque.

Aujourd’hui, la plupart des responsables d’application sensibles sont en mesure de rendre des comptes quant à l’usage des accès métier dans leur application. De la même manière, les responsables d’application et les responsables d’infrastructure doivent pouvoir répondre à des questions simples telles que :

• Qui utilise réellement des accès à privilèges sur mon périmètre ?
• Combien de comptes à privilèges existent sur mon périmètre ?
• Les mots de passe de ces comptes sont-ils changés régulièrement ?
• Quels sont les niveaux d’accès nécessaires pour mon application ou mes services, et qui ne peuvent pas être retirés sans conséquence pour la production ?

Plusieurs particularités à prendre en compte

Avant de se lancer dans un projet de mise sous contrôle des accès à privilèges, il est bon d’avoir conscience de certaines spécificités qui ne s’appliquent pas pour les accès métier.

À commencer par le cycle de vie de certains accès à privilèges. Dans le monde des accès métier, le cycle de vie est lié au statut RH de leur unique propriétaire. Mais dans le monde IT, il existe des accès partagés entre plusieurs personnes (pour des besoins opérationnels spécifiques), ou bien qui sont utilisés par l’application elle-même pour fonctionner. La durée de vie de ces accès-là est plutôt liée à la durée de vie de l’application concernée, ou bien parfois à la durée d’un projet.

Certaines contraintes opérationnelles sont aussi à prendre en compte. Notamment en ce qui concerne :

• La gestion de la production, qui ne souffre aucun délai. Dans le monde des accès métier, les niveaux d’accès sont généralement liés à la fiche de poste des utilisateurs, et c’est aussi le cas pour les populations IT. Mais dans certaines circonstances, les utilisateurs IT doivent pouvoir obtenir de nouveaux accès sans délai. Par exemple, en cas de panne d’une application critique, les équipes IT doivent pouvoir intervenir au plus vite avec toute la latitude nécessaire. Ce qui peut nécessiter des élévations de privilèges. Dans ce contexte, des processus de validation seraient trop longs (avec validation du responsable hiérarchique, puis éventuellement un autre niveau de validation…). Une autre approche peut consister à autoriser ce type de demande sans validation préalable, mais tracer et contrôler à posteriori l’usage qui a été fait de cet accès.

• Le grand nombre de ressources cibles. Certaines applications reposent sur un grand nombre de serveurs de production, et au moins autant de serveurs hors-production. Des applications peuvent aujourd’hui créer ou supprimer des serveurs virtuels à la volée, en fonction de la charge. Dans ce cas, il serait vite ingérable d’imposer aux utilisateurs des demandes d’accès pour chaque ressource cible. Une solution peut consister à gérer des demandes d’accès à des groupes de ressources (par exemple un groupe Active Directory qui représente tous les serveurs de production d’une application, lequel groupe pourrait même être déployé automatiquement sur les nouveaux serveurs par un orchestrateur).

Surtout, l’hétérogénéité de l’environnement peut rendre le modèle d’accès complexe. En effet, articuler la gestion des accès à privilèges autour d’un modèle cohérent, implique de composer avec :

• Des serveurs qui hébergent parfois plusieurs applications. Dans ce cas, un besoin d’accès à une seule application se traduit, en pratique, par des accès indus à plusieurs applications. Dans le cas d’applications critiques, il vaut donc mieux investir dans des serveurs dédiés (virtuels ou non, face aux risques portés par les administrateurs des plateformes de virtualisation).

• Des ressources hétérogènes avec leurs propres particularités. Serveur Windows, Unix, base de données Oracle, middleware Tomcat, des équipements réseau, voire des conteneurs comme Docker… La liste des technologies à prendre en compte est longue.

• Pour une même ressource, différents comptes à créer. Un utilisateur peut souvent intervenir sur une même ressource via différents moyens. Pour un même serveur, on pourra offrir la possibilité de s’y connecter directement (protocoles SSH, RDP…), via l’intermédiaire d’un serveur de rebond (et dans ce cas, c’est sur ce serveur qu’il faut créer un accès utilisateur), ou encore via une interface logicielle d’administration (c’est d’ailleurs la voie du DevOps).

• Des populations hétérogènes et des besoins qui évoluent rapidement. Le modèle d’accès est difficile à uniformiser, notamment parce que différents types de population, comme des administrateurs d’infrastructures ou des développeurs, ont des besoins différents. Par exemple, un administrateur Windows opère tous les serveurs Windows, quelle que soit l’application, alors qu’un développeur intervient sur plusieurs technologies dans la limite d’une application. Mais il est aussi difficile d’uniformiser le modèle d’accès pour une même population, car les développeurs de 2 applications différentes peuvent avoir des besoins différents.

Les accès à privilèges : un challenge pour la sécurité ?

Accès standards métier et accès à privilèges sont les 2 faces de la même pièce. Et les accès à privilèges en sont la face sombre, car ils sont à la fois plus sensibles et techniquement plus complexes à gérer.

Face à cet état des lieux, la prise de conscience des entreprises est inégale. Les mieux informées sont les équipes techniques IT qui utilisent les comptes à privilèges, et qui sont souvent favorables au statuquo.

Au-delà de la Direction des systèmes d’information, ce sont les Directions en charge des processus internes, de la qualité ou encore le contrôle interne, qui ont un rôle clé de sponsoring à jouer.

Le législateur, lui, commence aussi à s’y intéresser. Ainsi la Loi de programmation militaire, qui concerne les opérateurs d’importance vitale, impose une mise sous contrôle des accès à privilèges les plus critiques.

Mais alors comment s’y prendre, pour mettre les accès à privilèges sous contrôle ? Nous y reviendrons dans un prochain article.

Cet article Accès à privilèges : la face sombre de l’IAM est apparu en premier sur RiskInsight.

Historiquement la discipline de la gestion des identités et des accès (IAM ou identity and access management en anglais) s’est constituée autour du besoin de maîtriser qui accède (comment et) à quoi dans le système d’information de l’entreprise.

Du côté de la gestion des identités, les projets se sont initialement attelés à l’automatisation du provisioning et des tâches à faible valeur ajoutée. La discipline s’est ensuite peu à peu tournée vers les processus de demande et d’approbation de droits d’accès et plus récemment vers les problématiques de revue et recertification des comptes et habilitations.

Sur le sujet du contrôle d’accès, nous sommes passés par une première ère où l’authentification fut centralisée (sur un annuaire partagé par exemple), puis déléguée (à une solution de WebSSO) et enfin standardisée avec l’utilisation des mécanismes de fédération d’identités (eg. SAML) autant pour les applications SaaS que pour les applications restées en interne.

Dans le même temps, ces dernières années, le système d’information de nos entreprises s’est énormément ouvert à Internet : SaaS, IaaS, utilisateurs internes en mobilité, partenaires & clients accédant au SI, applications mobiles, etc. Et l’IAM a pu à chaque fois proposer des solutions à ces nouveaux usages et nouvelles orientations sans forcément nécessiter de remettre en cause l’existant et ses principes fondamentaux. Le marché s’est d’ailleurs petit à petit consolidé et nous sommes dans une situation de relatif calme… avant la tempête.

Les évolutions du SI

Nous estimons en effet que nous n’en sommes qu’au début de ces transformations.

Sous l’impulsion du Cloud d’une part, nous allons vers encore plus de SaaS, une utilisation du IaaS majoritaire par rapport aux datacenters historiques, une réelle adoption du PaaS (sous la forme d’applications conteneurisées, et server-less apps), des utilisateurs internes accédant majoritairement depuis l’extérieur et une explosion du nombre de terminaux accédant au SI (toujours plus de clients dont le parcours est digitalisé, explosion à venir du nombre d’objets connectés, OpenData, etc.)

Et sous l’impulsion de nouvelles méthodologies agiles et DevOps, le SI n’évolue plus de la même manière. Les cycles de développement et déploiement se sont considérablement raccourcis, les interactions entre le métier et la DSI se heurtent de moins en moins à l’opposition historique, et traditionnellement française, entre MOA et MOE. Ces nouvelles méthodes se sont d’ores et déjà répandues dans l’entreprise et il est difficile d’y résister.

Si la mission de l’IAM n’a guère changé : maîtriser qui accède à quoi dans le SI, il y aura beaucoup plus de « qui », de « quoi » et le SI ne sera plus qu’une bulle parmi d’autres interagissant avec son environnement et devant maîtriser, à distance, des interactions entre des composants décentralisés.

L’IAM de demain

Dans ce nouvel environnement où les métiers pilotent l’innovation technologique et imposent leurs exigences, où il est même parfois prescripteur de solutions technologiques, l’IAM doit se faire une nouvelle place. Dans ces architectures majoritairement Cloud, l’IAM doit démontrer qu’elle permet de maîtriser cette orientation et même d’apporter des plus-values par rapport à la situation précédentes.

Notre vision de l’IAM de demain s’articule autour de sept thèmes. Trois besoins exprimés par le métier et quatre nouvelles disciplines au sein de l’IAM.

L’agilité

Le métier attend de pouvoir proposer de nouveaux produits en un temps toujours plus court et ce qu’il a obtenu sur les applications métier est aujourd’hui attendu de tout le SI, y compris les services d’infrastructure et de sécurité et donc de l’IAM.

C’est l’occasion de passer d’un IAM monolithique, complexe à sortir de terre et très difficile à manœuvrer pour embrasser une architecture plus légère basée, par exemple, sur des micro-services.

La gestion des identités clients (Customer IAM ou CIAM)

La transformation numérique engagée par de nombreuses entreprises aujourd’hui a poussé le métier à interagir avec ses clients de plein de manières différentes et via toujours plus de canaux différents.

Une expérience utilisateur parfaite et la simplification du parcours client sont requis. L’optimisation des conversions clients et les taux de retours deviennent des indicateurs clés sur lesquels le métier insiste pour obtenir de l’IAM plus d’efforts.

Les objets connectés (Internet of Things ou IoT)

Que votre entreprise se lance dans la fabrication d’objets connectés ou qu’elle ne fasse que fournir des services consommés par ces objets, un certain nombre de questions vont devenir incontournables :

• Comment s’assurer que l’objet avec lequel je communique et celui qu’il prétend être ? Dans mon cas d’usage, est-ce finalement si important de le savoir ?
• Comment m’assurer de tenir la charge face au volume d’objets déployés ?
• Comment assurer la sécurité de bout en bout ?
• Quel cycle de vie doit-on anticiper ?

Ce sont des questions passionnantes qui imposent de savoir revenir à la planche à dessin et prendre en compte des hypothèses extrêmement différentes de celles de l’IAM classique.

IDentity as a Service

Comme nous l’avions prédit il y a quelques années, les entreprises n’hésitent plus à exporter leur IAM dans le cloud pour des questions de sécurité mais reviennent à la bonne question : en ai-je besoin ? Que vais-je gagner ?

Si le marché de l’IDaaS est encore jeune, les offres actuelles ne couvrant que très partiellement le spectre de l’IAM, tous les indicateurs montrent que cela ne va pas durer et que toute la gamme de fonctionnalités de gestion des identités aujourd’hui manquantes (provisioning on-premises, demande et approbation de droits, gouvernance des identités, etc.) sera bientôt couverte. Il reste à savoir si gestion des identités et contrôle d’accès seront packagés ou proposés par des acteurs différents et à choisir le(s) bon(s) acteur(s)…

APIs

Les APIs représentent déjà un format de communication prépondérant et incontournable pour toute entreprise lancée dans sa transformation numérique : échange avec les partenaires, applications mobiles, applications IHM client-side, OpenData, etc. Si vous ne vous êtes pas encore lancés, il va falloir sérieusement songer à plonger dans ce sujet !

Malgré des manques perçus par rapports aux standards des web-services des années précédentes (spécifiquement aux nostalgiques de la suite WS-*), il faut se résoudre à embrasser la vague REST/JSON, il faut se lancer dans Oauth2 et vous poser la question du API first pour tous vos projets.

Standards

La guerre des standards est éternelle. Et tout standard qui s’impose aujourd’hui a vocation à être challengé et remplacé plus tard par un autre. Cela n’empêche pas de bons standards de voir le jour, d’être adoptés et de permettre de correctement répondre aux problématiques de l’IAM.

Sur le sujet du contrôle d’accès en particulier, tant sur le volet de l’authentification proprement dite que de la propagation de cette authentification au travers du SI, plusieurs standards et protocoles sont matures et d’ores et déjà adoptés par une bonne part du marché. FIDO, U2F, OpenID Connect pour ne citer que ceux-là sont parmi les plus prometteurs de par leur ouverture, la maturité des technologies sous-jacentes ou encore les acteurs qui les ont conçus collectivement.

Identity & Access Intelligence

C’est sans doute le domaine de l’IAM qui offre les perspectives les plus excitantes. L’application des algorithmes du machine learning, la détection de signaux faibles, des réseaux neuronaux et bien d’autres encore pour faire émerger de nouveaux usages, de nouvelles possibilités en lien avec les identités de nos utilisateurs (ou objets) et leur comportement.

Détecter les scénarios de fraude avant même qu’ils ne se concrétisent, anticiper les risques et fermer la porte avant même que quelqu’un ne l’emprunte réellement. Il y a sans doute encore un peu de science-fiction dans les scénarios présentés par les éditeurs mais ce marché en pleine ébullition regorge de pépites et de bonnes surprises.

En synthèse

Ces sept thèmes, incontournables selon nous, requièrent d’ores et déjà une expertise à la fois pointue et très spécifique. Dans les prochaines semaines, nous éclairerons progressivement ces différents sujets pour donner les clés d’analyse et d’action sur l’IAM de demain, que ce soit en phase de cadrage, d’expérimentation ou de premières mises en œuvre.

Cet article Quel IAM pour demain ? est apparu en premier sur RiskInsight.

Mettre en œuvre la carte CPS au travers d’un projet de gestion des identités et des accès

Le SI, tout en connaissant de profondes transformations, devient un enjeu majeur dans les hôpitaux : informatisation continue des services de soins, ouverture du SIH, dématérialisation des échanges et interopérabilité, renforcement des exigences réglementaires, etc. Ces évolutions facilitent le partage de l’information médicale mais rendent sa protection plus difficile.

La mise en œuvre d’un espace de confiance numérique pour le partage des données de santé devient alors une nécessité. Cette nécessité devient un prérequis dans le cadre du programme Hôpital Numérique et de la certification HAS (Haute Autorité de Santé).

La mise en place d’une gestion des identités et des accès, qui associe l’utilisation d’un dispositif d’authentification forte comme la Carte de Professionnel de Santé, permet de créer un espace de confiance numérique qui répond aux problématiques suivantes :

• Respecter les nouvelles règlementations ;
• Simplifier et sécuriser l’accès au SIH ;
• Accélérer les processus de gestion des droits ;
• Diminuer la charge d’administration et réduire les coûts de support.

Mener un projet de gestion des identités et des accès adapté au monde hospitalier

La gestion des identités et des accès associe des processus, des technologies et une stratégie de gestion des identités numériques et de spécification de leur usage pour accéder aux ressources informatiques de l’entreprise.

Mener un tel projet s’avère généralement plus complexe que la plupart des autres projets informatiques en raison du nombre et de la diversité des référentiels d’identités numériques, des solutions techniques mises en œuvre et des besoins des entités gouvernantes amenées à collaborer.

Notamment, les acteurs concernés par un tel projet dans le monde hospitalier sont nombreux : la Direction Générale, la Commission Médicale d’Établissement (CME), le Département d’Information Médicale (DIM), les directions gérant le personnel salarié et non salarié de l’établissement (Direction des Affaires Médicales, Direction des Ressources Humaines), le corps médical et soignant, la Direction des systèmes d’information (ou le service informatique), etc.

Par ailleurs, certains thèmes à aborder sont spécifiques aux établissements de santé :

• Comment instruire ce projet dans le cadre d’une mise en réseau de l’établissement au sein d’une ou plusieurs communautés hospitalières ?
• Faut-il limiter l’utilisation de la carte à l’accès aux postes de travail ou bien ai-je intérêt à étendre son usage comme pour l’accès aux locaux ?
• À qui dois-je la fournir ?
• Comment m’assurer que la carte CPS facilitera l’accès aux postes de travail ?
• Quelles applications dois-je prendre en compte dans mon projet ?

Un projet d’établissement nécessitant un engagement de moyens ainsi qu’une implication de tous les acteurs pour le rendre maîtrisable

Mettre en œuvre la carte CPS au travers d’un projet de gestion des identités et des accès se révèle être un projet stratégique d’établissement, porteur d’enjeux à la fois techniques, organisationnels et de conduite du changement, et à ce titre requiert une phase préalable de cadrage qui permettra :

• De définir le périmètre et évaluer la dimension du projet : état des lieux, besoins et les attentes, axes d’amélioration, périmètre fonctionnel cible, macro-évaluation charges, coûts, délais ;
• D’inscrire le projet dans une démarche globale : acteurs à mobiliser, instances de pilotage, possibilités de mutualisation.

Et vous, où en êtes-vous de la mise en œuvre de la carte de Professionnel de Santé au sein de votre établissement ?

Cet article La carte CPS : un projet d’établissement ou un projet informatique ? est apparu en premier sur RiskInsight.