Le besoin de collaboration avec l’externe : éternel point de souffrance des entreprises

Les entreprises ont toujours eu besoin de collaborer entre elles en partageant des ressources et en échangeant des données. Pour ce faire, leurs collaborateurs doivent être capables d’interagir en toute sécurité avec des utilisateurs extérieurs à leur environnement.

Plusieurs cas d’usages sont à couvrir, dont un des plus fréquents devient la collaboration bornée dans le temps avec des partenaires, des prestataires externes, des fournisseurs ou des clients B2B.

Aussi, il est courant d’observer une collaboration continue entre filiales d’un même groupe, qui ont besoin d’avoir accès aux ressources et données de l’entreprise, et qui ne partagent pas nécessairement le même Système d’Information.

Historiquement, la collaboration pouvait se réaliser de plusieurs façons présentant des inconvénients :

• Par échange successifs de mails, à la fois peu efficaces et entrainant une perte de contrôle de la donnée échangée ;
• En utilisant des solutions dédiées au partage de document à des tiers, qui s’avèrent coûteuses et peu adaptées d’un point de vue expérience utilisateur ;
• En créant une nouvelle identité dans les systèmes historiques (Active Directory, etc.), et en dotant les entités tierces de moyens pour accéder au SI de l’entreprise (VPN, machines virtuelles, machines physiques, etc.), ce qui augmentait considérablement la surface d’attaque de l’entreprise.

Microsoft a introduit Azure AD B2B pour ce besoin de collaboration

Aujourd’hui, l’usage d’Azure AD B2B permet à deux entités ou plus de collaborer au sein du tenant Azure de l’entreprise d’accueil. Les ressources partagées peuvent être des applications, des documents, des sites SharePoint, des OneDrive ou des équipes Teams.

Dans les faits, la solution Azure B2B permet à un utilisateur externe d’accéder au tenant de l’entreprise d’accueil via son compte habituel en lui créant une identité « invité » au sein de l’Azure Active Directory (AAD) de l’entreprise.

Le tenant « client » fait alors totalement ou en partie confiance au tenant « externe » pour l’authentification via un mécanisme d’échange de jeton.

Il existe trois possibilités natives pour créer une identité « invité » :

• Directement depuis le portail Azure ;
• Via un partage de document sur OneDrive/SharePoint/Teams ;
• Via l’utilisation de la graph API.

Au niveau du tenant d’accueil, le propriétaire peut autoriser ou non le partage de données à des externes et également administrer les comptes invités (création, désactivation, suppression…).

Cette solution de collaboration présente un avantage direct : la facilité d’utilisation pour les utilisateurs habitués aux environnement Microsoft.

Le deuxième avantage à prendre en compte, est bien évidemment le coût de la solution. En effet, une identité « invité » présente une économie de licence : jusqu’à un plafond de 50 000 identités « invité », leur licence est gratuite. Au-delà et selon les souscriptions de l’entreprise, une licence pourra coûter entre 0,003€ et 0,015€ / mois / utilisateur, auxquels viennent se rajouter des frais fixes d’un montant de 0,029 € pour chaque tentative d’authentification multi facteur. Cette politique tarifaire est en décalage avec le tarif habituel d’une licence M365 : entre 10€ et 50€ / mois / utilisateur selon le plan de licence.

Cependant Azure AD B2B présente une configuration par défaut trop ouverte, qui engendre des risques pour l’entreprise

Azure AD B2B introduit plusieurs facteurs qui peuvent induire des risques :

• La création des identités invités est très simple et non contrôlée (pas de responsable pour l’identité, pas de traçabilité, pas de restrictions…) ;
• Le nombre d’identité invité peut augmenter de façon non contrôlée et il est compliqué de gérer simplement leur cycle de vie ;
• L’entreprise ne maitrise pas la sécurité du tenant initial de l’identité « invité » ;
• Aucune règle d’accès conditionnel n’est mise en place par défaut (pas d’authentification forte, pas de restriction d’accès au portail Azure AD, etc.) ;
• L’identité « invité » à accès aux attributs Azure AD des autres utilisateurs.

Ces facteurs engendrent des risques pour les données de l’entreprise, étant donné qu’une identité « invité » peut avoir des droits sur un nombre important de documents et des informations sur son tenant d’accueil.

On peut considérer deux évènements déclencheurs pour les différents scénarios de menaces :

• Une identité « invité » malveillante ;
• Une identité « invité » compromise par un attaquant.

Ensuite, et selon le niveau de configuration et les droits de l’identité « invité », cette dernière aurait l’opportunité de :

• Récupérer de la donnée confidentielle, à laquelle l’identité a accès ;
• Détruire l’ensemble des données accessibles par cette identité ;
• Compromettre l’AD via attribution de rôles à cette identité ;
• Réaliser de l’ingénierie sociale via l’accès à l’ensemble des données des utilisateurs.

En fonction du niveau de maturité de l’entreprise et de la volonté de couvrir le risque, il est nécessaire de mettre en œuvre un certain nombre de mesures

Pour bien commencer : durcir la configuration par défaut

Maitriser les moyens d’ajouter des identités « invité » sur le tenant

Un des premiers points à traiter est de couper l’accès au portail Azure aux collaborateurs non-administrateur de l’entreprise, pour qu’il ne soit plus un vecteur de création d’identités « invité ».

Il faut noter qu’il est également possible de restreindre la population pouvant inviter des externes à collaborer, mais dans les faits cela ne sera pas applicable à toutes les entreprises, et notamment celles qui souhaitent décentraliser la gestion de cette population. En effet le fait de restreindre cette population oblige à créer un service dédié à la création de ces identités, ce qui va à l’encontre du principe même de ce service, qui est de laisser la main aux utilisateurs.

Enfin, il existe une fonctionnalité permettant de positionner des contraintes sur l’adresse mail des identités « invité », via white-list ou black-list de nom de domaine. Cependant avant de se lancer dans ce chantier, il est nécessaire de tenir compte de la complexité de sa mise en œuvre (notamment pour une entreprise qui ne maitrise pas les partenaires avec qui elle collabore), et de la faible réduction du risque associé.

Restreindre ce à quoi peuvent avoir accès ces identités

Il est possible de restreindre les attributs qui peuvent être consultés par les identités invités, afin que ces dernières soient dans l’incapacité de récupérer un gros volume d’information sur le tenant d’accueil.

Renforcer l’authentification et le contrôle d’accès des identités « invité »

Le mécanisme d’authentification multi facteur (MFA) pour une identité « invité » est quasi natif et permet de diminuer le risque d’usurpation par un attaquant. En effet il suffit de mettre en place une politique d’accès conditionnel qui cible spécifiquement ces identités « invité », et qui applique le contrôle relatif au MFA.

Plusieurs défis viennent néanmoins complexifier cette opération, et sont à prendre en compte

• La gestion de la conduite du changement sur ces populations « invité » reste complexe à effectuer, même si les opérations d’onboarding des utilisateurs sont simples et guidées ;
• La gestion des processus de réinitialisation de second facteur en cas de perte ou de vol peut être coûteuse et complexe si elle n’est pas maitrisée.

Sensibiliser les utilisateurs aux risques et aux bonnes pratiques de collaboration

La complexité majeure de la solution Azure AD B2B est l’absence de mécanisme de gestion des identités « invités ». Les utilisateurs sont donc les principaux acteurs de la stratégie de gestion, et doivent être sensibilisés au bon niveau, en insistant sur :

• Les bonnes pratiques de collaboration : dans quel cas doivent-ils utiliser la solution, comment créer un invité, etc ;
• La bonne gestion de leurs accès : ils doivent être supprimés dès que possible afin d’éviter un accès illégitime ultérieur ;
• La désactivation des identités lorsqu’elles ne sont plus utilisées, en particulier pour les prestataires / partenaires, en insistant sur le fait que les documents produits ne sont pas perdus.

Protéger la donnée à laquelle peut avoir accès les invités

Il ne faut pas non plus oublier de protéger la donnée à laquelle peut avoir accès un invité légitime, ce qui donne lieu à plusieurs mesures :

• Il est possible de mettre en place des contraintes pour les identités « invité » via des règles d’accès conditionnels : utilisation obligatoire des clients légers (clients web), ayant pour effet d’empêcher la synchronisation des données et prérequis à des mesures avancées que nous verrons ensuite, l’interdiction du téléchargement des données, contraintes sur les terminaux à utiliser ;
• Si l’entreprise a déployé l’outil de classification AIP (Azure Identity Protection), une autre solution peut être la création d’une étiquette de confidentialité chiffrant la donnée pour les identités « invité ». Cette étiquette pourra également servir à restreindre certaines actions pour cette population : restriction des modifications (via les permissions associées), restriction du téléchargement (via une règle DLP), etc.

Pour aller plus loin, un Cloud Access Security Broker (comme Microsoft Defender for Cloud Apps de Microsoft) peut permettre la mise en place de règles avancées et ciblées comme par exemple : empêcher le téléchargement sur des espaces Sharepoint spécifiques.

Bien gérer le cycle de vie des identités « invité » : 3 Scénarios à considérer

Comme évoqué précédemment, le sujet clé reste la maitrise du cycle de vie des identités « invités » : Création, suppression, et revue des accès. 3 scénarios peuvent être envisagés, en fonction de la couverture du risque souhaitée, du niveau de maturité de la gestion des identités et des accès, et du coût de mise en œuvre du scénario.

Scénario 1 – Rester pragmatique avec un petit budget : utiliser les outils et configurations natives

Dans ce scénario, l’entreprise dédie une certaine typologie de groupe au partage à l’externe, et donc à la création d’invités. La distinction peut se faire par la nomenclature du groupe par exemple : tous les groupes externes doivent commencer par « X_ », ce qui nécessite de contrôler la création des groupes au préalables.

Elle peut ainsi réaliser des contrôles plus facilement sur ce périmètre restreint de groupes.

Le prérequis principal est de bloquer les ajouts d’identités « invités » aux groupes de type « Internes », et il est possible de le faire de deux façons :

• Si l’entreprise a déployé l’outil de classification AIP sur les espaces SharePoint et Teams : utilisation d’une étiquette dédiée pour empêcher le partage aux externes sur ces espaces. Exemple : création d’un label « Interne » qui bloque le partage avec les identités « invité » ; – LIEN
• Via un script PowerShell, bloquer le partage avec les identités « invité » pour les groupes « Internes », en les identifiant via leur nomenclature. – LIEN

Création d’une identité « invité »

La seule possibilité pour créer une identité « invité » est de les ajouter des utilisateurs externes dans des groupes de type « Externes ».

Si l’entreprise a besoin de donner accès à son tenant à une filiale ou une entité entière, il est possible de synchroniser régulièrement leur AD ou Azure AD, et ainsi créer leurs identités en « invité » dans le tenant de l’entreprise.

Suppression d’une identités « invité »

Le processus de suppression des identités reste basique, avec à minima la suppression des identités « invités » inactif, en utilisant par exemple un script PowerShell s’appuyant sur la notion de « Sign In Activity ». Il pourra également être intéressant de supprimer les identités « invité » n’ayant accès à aucun groupe via un script PowerShell.

Revue des accès « invité »

Pour couvrir le risque lié à la revue des accès dans ce scénario, il est possible de faire expirer les accès des identités « invité » sur les groupes SharePoint ou les OneDrive au bout de 60 jours. Il est à noter que le propriétaire des groupes SharePoint ou OneDrive sera notifié de l’expiration 21 jours avant échéance.

Enfin, il est envisageable d’utiliser la fonctionnalité « Guest Access Review » pour les groupes externes où le partage à des invités est possible. Il faut cependant noter qu’elle nécessite des licences avancées (AAD P2) attribuées aux utilisateurs devant effectuer les revues, donc tous les propriétaires des groupes en question (normalement en nombre limité).

Ce scénario est un bon moyen de réduire le risque lié aux invités, en gardant une solution quasi native, et sans trop investir dans la solution.

Scénario 2 – Pour aller plus loin dans le niveau de sécurité : développer une application de gestion des invités

Dans ce second scénario, l’entreprise souhaite avoir complètement la main sur la gestion du cycle de vie des identités « invité », et sortir du mécanisme natif trop permissif de Microsoft. Pour ce faire, l’entreprise crée une application (par exemple en utilisant Power App) pour gérer ce cycle de vie, en en faisant le point unique de création et suppression.

Une fois ce cycle de vie mis en place, il est nécessaire de positionner le paramètre de partage SharePoint sur le mode « Existing guest only », permettant uniquement de partager du contenu avec des identités « invité » déjà existante dans le tenant Azure AD. Ceci permet d’empêcher la création de nouvelles identités via ce vecteur.

 Création d’une identité « invité »

Dans ce scénario les utilisateurs utilisent l’application dédiée pour créer les identités « invité », en renseignant une date de fin. L’utilisateur désigne alors le propriétaire de l’identité créée.

Suppression d’une identité « invité »

Pour supprimer les identités, il est possible de déclencher un workflow automatique en amont de la date de fin, pour demander au propriétaire de l’identité en question s’il faut effectivement la supprimer ou prolonger sa date de fin. Il est à noter que si le propriétaire a quitté l’entreprise sans faire le changement de propriétaire, on peut envisager de réaffecter l’invité à son supérieur hiérarchique.

Revue des accès « invité »

Avec ce type d’application « maison », il est compliqué d’aller beaucoup plus loin dans la gestion du cycle de vie, et notamment quand il s’agit de revue des accès.

Il est toujours possible comme pour le scénario 1 de faire expirer les accès des invités ou d’utiliser la fonctionnalité « Guest Access review » (avec les mêmes contraintes qu’énoncé précédemment).

Pour aller plus loin, on peut également envisager l’utilisation d’outils tiers type IDECSI ou Sharegate qui permettent notamment de gérer ces revues d’accès de façon automatique et intuitive.

Ce scénario change le comportement natif et permet de mieux maitriser le cycle de vie, mais à un coup important au regard du déploiement et de la conduite du changement à mettre en œuvre.

Scénario 2’ – Intégrer les identités « invité » dans les processus IAM classiques

Le dernier scénario à considérer est une variante du scénario précédent, où l’entreprise souhaite toujours avoir la main sur la gestion du cycle de vie des identités « invité ». L’entreprise peut dans ce cas intégrer la gestion des identités « invités » dans ses outils de gestion des identités et des accès (IAM), au même titre que les identités « externe ».

L’outil IAM devient alors la source autoritaire pour ce type de population, et sa gestion s’y fait directement.

Dans ce scénario comme dans le précédent il faut également positionner le paramètre de partage SharePoint sur le mode « Existing guest only ».

Création d’une identité « invité »

La création des identités se fait via les formulaires de création d’externes depuis les outils IAM, en choisissant le type « invité » pour l’identité. L’identité « invité » pourra ensuite être provisionnée automatiquement dans l’Azure AD par les outils IAM.

Suppression d’une identité « invité »

La suppression de l’identité est également faite par l’outil IAM en fonction de la date de fin positionnée, et selon les workflows déjà définis.

Revues des accès « invité »

Dans le cas où les outils IAM de l’entreprise sont utilisés pour gérer les droits sur les espaces Sharepoint, il est possible d’utiliser les capacités de revue d’accès de ces outils pour faire la revue des accès aux ressources sensibles auxquelles ont accès les identités « invité ».

Une deuxième option peut également être d’utiliser les fonctionnalités de gouvernance des accès via les solutions IAM type Sailpoint, OneIdentity ou via des solutions dédiées d’Identity and Access Governance type Brainwave ou Varonis. On peut imaginer récupérer les droits attribués directement dans l’Azure AD, et les faire vérifier aux propriétaires des ressources à travers ces outils.

Ce scénario est une variante du scénario 2, qui permet aux entreprises les plus matures sur la gestion des identités et des accès de capitaliser sur les outils et processus existant.

Enfin, ne pas négliger la surveillance de cette population exposée

En premier lieu il est pertinent de construire un reporting adapté à l’aide de KPI et tableaux de bord. Beaucoup d’informations sont disponibles nativement dans l’Azure AD (date de dernière connexion, activité sur le tenant ainsi que sur Office 365 via les « unified audit logs »). Ces informations peuvent assez simplement être exploités par exemple via Power bi pour la génération de tableaux de bord.

Ensuite, il est important de surveiller les activités de ces populations particulièrement exposées. Deux niveaux de détection peuvent être mis en place en fonction des capacités de surveillance :

• Implémenter des règles de DLP natives ou des scénarios d’alertes classiques dans la console Microsoft : certains scénarios d’alertes sont préconfigurés comme la suppression massive de documents, une élévation de privilège etc.
• Mettre en place des règles DLP avancées et des scénarios de détection ou des seuils spécifiques pour les invités avec l’appui du SOC de l’entreprise. Par exemple, le seuil de téléchargement de données autorisé pour un invité peut être inférieur à celui autorisé pour un interne.

Pour aller plus loin on peut imaginer l’utilisation du module Azure AD Identity Protection, afin de déclencher des alertes pour les invités ayant un niveau de risque élevés.

En conclusion, AAD B2B facilite grandement la collaboration, mais sa configuration nécessite d’être durcie pour réduire le niveau de risque induit par la solution

AAD B2B simplifie grandement la collaboration avec des utilisateurs externes à l’entreprise, mais induit des risques liés à l’ouverture par défaut de la solution. Pour maitriser ces risques, il est nécessaire de réduire l’ouverture, et de contrôler le cycle de vie de ces identités de façon plus ou moins avancé, en fonction de l’investissement possible sur le sujet. Enfin il faut également mettre l’accent sur leur surveillance via les outils natifs ou les outils utilisés par l’entreprise, étant donné la forte exposition de ces populations.

Cet article Bien gérer les identités « Invités » Azure AD B2B est apparu en premier sur RiskInsight.

Notamment, avec l’explosion des IoT et les réglementations tels que la DSP2, le besoin de déclencher des authentifications décorrélées du medium d’accès de l’utilisateur se fait de plus en plus présent : en effet, ce dernier ne dispose peut-être pas des interfaces nécessaires, ou peut ne pas être reconnu comme un support suffisamment sécurisé.

La cinématique additionnelle CIBA, Client Initiated Backchannel Authentication Flow a pour but de définir les échanges et les appels permettant de déclencher des tels authentifications. Ce premier article a pour but de décrire brièvement le fonctionnement haut niveau de cette cinématique, et de présenter les apports et les cas d’usage supplémentaire qu’il peut couvrir.

C’est quoi CIBA ?

CIBA signifie Client Initiated Backchannel Authentication. Il s’agit d’un nouveau flux d’authentification et d’autorisation du standard OpenID Connect définit par la fondation Open ID.

Le flux CIBA est le premier flux d’OpenID qualifié de « découplé » car il introduit la notion de Consumption Device (CD) et d’Authentication Device (AD). Le CD est l’appareil sur lequel l’accès à un service (Relying Party, RP) est demandé tandis que l’AD est l’appareil sur lequel l’utilisateur s’authentifie auprès de l’OpenID Provider (OP) et autorise l’accès qui est demandé sur le CD, en donnant son consentement.

Contrairement aux autres flux du standard OIDC, CIBA considère donc que l’utilisateur peut s’authentifier sur un appareil différent de celui sur lequel il veut accéder au service. Par exemple, un utilisateur cherche à accéder à son compte en banque depuis son ordinateur et s’authentifie pour autoriser l’accès depuis son smartphone.

Quels apports ?

Le flux CIBA présente plusieurs intérêts significatifs pour l’authentification des utilisateurs.

Les flux d’authentification OIDC aujourd’hui sont conçus autour de la notion de redirections web entre le service accédé (Relying Party) et le fournisseur d’identité. Ces redirections peuvent se montrer inconfortables et perturbantes pour l’utilisateur qui voit son navigateur ou son application passer d’un site à un autre sans forcément comprendre ce comportement. Avec CIBA, l’appareil que l’utilisateur utilise pour accéder à un service reste sur la page du service demandé en attendant que l’authentification soit réalisée sur l’AD. Cette disparition des redirections améliore également l’acceptation des Relying Party qui ne perdent plus le contrôle et la visibilité des actions de l’utilisateur lorsque ce-dernier doit s’authentifier auprès de l’OP.

Bénéfice par population

L’authentification multi-facteur (MFA) est de plus en plus répandue et recommandée pour accéder à des services sur Internet. Les SMS, les soft-token ou encore les Out-Of-Band push notification sont divers exemples de facteurs d’authentification additionnels, utilisés aujourd’hui en complément d’un mot de passe. Avec CIBA, la présence de ce facteur fait naturellement partie de l’authentification puisque celle-ci s’effectue sur un appareil enregistré comme AD. En demandant à l’utilisateur de s’authentifier sur l’AD avec un mot de passe, un code PIN, un facteur biométrique, … on permet de centraliser les actions d’authentification sur un seul et même appareil tout en permettant de faire du MFA.

Exemples de cas d’usage

Le call center

Lorsqu’un client appelle aujourd’hui un centre d’aide ou de services, l’opérateur vérifie le plus souvent l’identité du client avec diverses questions personnelles (date et lieu de naissance, numéro de sécurité sociale) ou bien à l’aide des questions de sécurité. Cette méthode d’authentification est particulièrement vulnérable à des attaques telles que l’ingénierie sociale.

Grâce à CIBA, il est possible pour l’opérateur de déclencher une demande d’authentification de l’appelant sur son Authentication Device et ainsi s’assurer de façon plus sécurisée de l’identité du client.

Les assistants virtuels

La DSP2 impose aux organismes bancaires de s’assurer de l’identité de la personne effectuant une opération au-dessus de certain montant, ce qui passe obligatoirement par une phase d’authentification (2 facteurs) lors d’un transfert par exemple. Néanmoins, les IoT tels que les assistants vocaux ne disposent pas d’interface permettant à l’utilisateur de saisir leurs identifiants, et forcer le client à valider une demande de transfert sur un portail web via son smartphone ou son pc n’est pas l’expérience utilisateur idéale. CIBA permet de s’affranchir de cette contrainte, car la banque du client est alors en capacité d’envoyer une demande d’authentification directement sur le bon terminal (AD), limitant l’impression de rupture de parcours pour le client.

Conclusion

La cinématique d’authentification CIBA comble de vraies faiblesses du protocole OpenID Connect, tant au niveau de la couverture fonctionnelle que de l’expérience utilisateur. Sa mise en œuvre dans le monde réel devrait se faire rapidement, et de nombreux acteurs du marché regardent déjà comment l’implémenter.

Cet article FAPI-CIBA : Comment authentifier mon utilisateur sans interface ! est apparu en premier sur RiskInsight.

Cette réflexion doit permettre de couvrir les risques principaux que sont la fuite de données et l’accès aux données par des administrateurs, Microsoft et des personnes ou des applications tierces.

Un nouveau modèle de gouvernance imposé par Microsoft

Office 365 est une solution de communication et de collaboration SaaS. En tant que telle, la plateforme est en constante évolution, contrairement aux solutions historiques dites « on-premise » : de nouvelles fonctionnalités ou paramétrages apparaissent, sont modifiés tandis que d’autres disparaissent ; on peut citer la disparition annoncée de Skype en 2021 ou la fin du support de l’authentification legacy pour Exchange Online en 2020. Le rythme de cette livraison continue, « continuous delivery » en anglais, est imposée par Microsoft sans contrôle possible, ce qui nécessite un tout nouveau modèle de gouvernance.

L’intégration des changements ne peut plus se faire en mode projet, mais doit suivre un processus établi. Dans ce modèle, les équipes workplace et sécurité doivent travailler main dans la main et être représentées dans l’ensemble des comités projets et d’architecture, et ce dès la conception des cas d’usages de la plateforme. Ces équipes également auront pour responsabilité commune de veiller à la bonne santé et à la conformité réglementaire de la plateforme.

L’équipe sécurité ainsi voit son périmètre évoluer : elle n’a plus la main sur les outils de sécurité et peut, voire doit, avoir un rôle de business enabler afin d’accompagner la migration vers le Cloud en proposant de nouveaux usages (ex : ouverture d’un service maîtrisé d’échange de fichiers à l’externe). Une organisation adéquate doit être mise en place ; on pourrait même envisager d’avoir un Security officer dédiée à la plateforme au plus près des métiers, ayant pour rôle de conseiller les projets, de suivre la configuration de la plateforme, d’assurer le suivi des alertes de sécurité, etc.

Un autre sujet à traiter concerne la délégation de l’administration. Il n’est pas envisageable d’avoir près de 20 Administrateurs Généraux pour un tenant O365, même si cela n’est pas une situation si rare. La mise en place d’une solution de délégation d’administration des comptes utilisateurs et des objets doit être envisagée, via la mise en place d’une interface ou d’un connecteur basé sur PowerShell ou Graph API. Ce traitement devra permettre de gérer l’ensemble de objets tout en tenant compte des logiques métiers. Autour de cette nouvelle gouvernance, doivent s’articuler les piliers de la sécurité ci-dessous :

• La gestion des identités ;
• La maîtrise des services et des usages ;
• Le contrôle du bon respect des politiques de l’entreprise.

La gestion des identités au cœur du sujet

Dans une solution conçue pour permettre une collaboration interne ou externe, avec une utilisation ATAWAD (Any Time, Any Where, Any Device), la gestion de l’identité et donc des authentifications est le cœur de la gestion plateforme.  Comme pour tout projet, la phase de définition de qui peut accéder à quoi, quand et où est fondamentale.

Sur Office 365, on retrouve trois types d’utilisateurs ayant chacun des niveaux de privilèges différents : les administrateurs, les utilisateurs internes et les invités (externes invités à collaborer sur un fichier ou au sein d’un Groupe O365 ou d’un site SharePoint).

Pour chacun de ces types de comptes, l’implémentation des mesures de sécurité définies va être pleine de défis. Outre l’incontournable authentification multi-facteur, mise en valeur par la fuite de données ayant touché Deloitte en 2017 se posent notamment les problématiques essentielles de la maîtrise des accès des administrateurs (rôles personnalisés ou prédéfinis, accès permanent ou ponctuel etc.) et du cycle de vie des utilisateurs invités (rien n’étant clairement défini par défaut). La question du coût des licences Azure AD Premium ou d’un outil tiers va être élément majeur de la discussion.

À noter également, Office 365 permet à des applications externes, de communiquer avec ses APIs. L’application externe peut alors agir au nom d’un utilisateur avec ses droits propres ou d’un administrateur avec des privilèges plus élevés. Ces applications peuvent provenir de différents magasins d’applications (comme AppSource ou AAD) ou être développées localement. La gestion des permissions accordées à ces applications doit faire preuve d’un point d’attention pour les entreprises. En effet, à travers les APIs, il est très facile d’imaginer une fuite de données massives en cas de dupe d’un utilisateur (ex : cas d’une application requérant des permissions non nécessaires, comme celui de l’accès aux mails).

Une maîtrise des services et des usages indispensable mais délaissée

Une fois les accès à Office 365 sous contrôle, le sujet suivant est de maîtriser l’usage qui en est fait. Il n’est pas rare d’observer que des services, non priorisés lors de la migration vers le Cloud (Power BI, Teams, Flow, accès aux API etc.) sont laissés accessibles avec leur configuration par défaut. Les deux raisons avancées sont généralement de favoriser l’adoption et le manque de temps à consacrer à ces services non prioritaires. En plus du paramétrage du service, il est également indispensable de définir des règles précises autour des usages afin de clarifier qui peut faire quoi et quand (ex : gestion des habilitations SharePoint, création des Groupes). L’idéal étant bien sûr de mettre en place des mesures techniques (paramétrages généraux ou configuration via PowerShell) cohérentes avec la politique définie.

L’absence de sécurisation de ces services laisse toutefois là porte ouverte à de potentielle fuites de données : transfert automatique vers l’extérieur, exposition sur Internet ou encore perte de contrôle la donnée. Comme écrit plus haut, la gouvernance doit prendre en compte la sécurité dès la conception des futurs usages. Les services doivent être analysés et testés sur des populations réduites. En effet, il sera toujours plus facile d’ouvrir une fonctionnalité, que de restreindre un usage déjà bien répandu. Dans le deuxième cas, il sera nécessaire de faire une analyse d’impact, de bricoler une solution de contournement et de sensibiliser largement les utilisateurs. Des actions qui peuvent nécessiter un investissement important et qui pourraient être évitées.

Le suivi des services ne doit pas s’arrêter à la fin de l’adoption des utilisateurs. Les équipes sécurité et workplace auront ainsi la charge de faire un suivi des évolutions d’Office 365 (programme Evergreen, mise en place d’une veille, suivi des blogs Microsoft, …) afin d’évaluer les nouvelles opportunités et menaces.

Le contrôle du bon respect des politiques de l’entreprise

Le dernier pilier, et pas le moindre, consiste en l’implémentation des politiques de sécurité de l’entreprise. Cela passe notamment par la mise en place d’outils de sécurité : protection de l’information, anti-malware, supervision et alerting.

Concernant la sécurité d’Office 365, on peut différencier 3 niveaux de maturité aujourd’hui. Les moyens mis en place vont être conditionnés par les expertises disponibles (les ressources étant limitées sur le marché) et le budget (dépendant notamment de la stratégie de l’entreprise de gestion des licences Microsoft) :

• Niveau 1 – Maîtrise des identités, des services et utilisation du Centre de Sécurité et de Conformité : l’entreprise met en place les solutions de sécurité natives du Security Center et du Compliance Center (incluant notamment Office DLP, Exchange Online Protection, eDiscovery) accessibles avec des licences basiques ;
• Niveau 2 – Développement d’ « outils maisons »: l’entreprise crée un ensemble de scripts simples ou tableaux de bords, en s’appuyant sur Graph API, Security Graph API et PowerShell, pour mettre en place des contrôles et des mesures de sécurité adaptés à son contexte (ex : gestion du cycle de vie des utilisateurs invités) ;
• Niveau 3 –Utilisation d’outils de sécurité avancée : l’entreprise met en place des solutions additionnelles pour renforcer le niveau de sécurité : outils permettant de lutter contre les fuites de données, d’analyser les malwares sur les mails, de revoir les droits, de détecter comportements anormaux ou encore de durcir l’utilisation de la plateforme en fonction du contexte.

La maîtrise des services Office 365, de leurs usages et des fonctionnalités natives de sécurité est indispensable, et doit précéder toute réflexion concernant l’ajout d’un outil de sécurité supplémentaire, qui ne couvrirait pas les failles existantes et ne ferait qu’ajouter de la complexité.

Exemple de contrôles de notre méthodologie d’Audit Office 365

Office 365 est un cas intéressant de l’ouverture des applications métiers sur Internet via le Cloud. Cette évolution requière d’adapter le modèle de sécurité historique de l’entreprise, en tendant vers le modèle de la compagnie aérienne avec l’adoption du Cloud.

La sécurisation d’Office 365 ne doit toutefois pas omettre celle des briques on-premise nécessaires au fonctionnement de la plateforme le cas échéant, comme c’est le cas généralement pour l’authentification qui est portée par l’ADFS.

Cet article Un Office 365 sécurisé, une perle rare ? est apparu en premier sur RiskInsight.

Pourtant, le volet IAM « Identity and Access Management » est souvent relégué au second plan dans les Programmes de mise en conformité LPM/NIS mis en œuvre par les Opérateurs d’Importance Vitale (OIV) / Opérateurs de Service Essentiel (OSE).

Comment comprendre cette situation et quelles leçons en tirer pour construire sa feuille de route IAM pour ses infrastructures critiques ?

L’IAM est un des piliers du volet cybersécurité de la LPM/NIS

Les mesures IAM à mettre en place sur les infrastructures critiques sont décrites dans les quatre règles suivantes :

Auxquelles il convient d’ajouter la règle portant sur les indicateurs (règle 20 pour la LPM et règle 4 pour NIS).

Les bonnes pratiques IAM habituelles à appliquer à tous les accès

Les exigences des trois premières règles reprennent les bonnes pratiques habituelles à appliquer à la gestion des comptes et des droits, tant pour les utilisateurs physiques que pour les processus automatiques accédant aux infrastructures critiques :

• Gérer le cycle de vie des utilisateurs, notamment les mutations et départs
• Affecter les droits selon le principe du moindre privilège
• Revoir (ou recertifier) régulièrement les droits affectés, a minima annuellement
• Contrôler et auditer les droits
• Attribuer des comptes et des moyens d’authentification strictement nominatifs

Le cadre ci-dessous résume les règles concernées :

Ces règles fixent un cadre mais laissent une grande liberté aux Opérateurs pour les décliner dans leur contexte.

Des comptes d’administration dédiés et soumis aux mêmes exigences

La quatrième règle (n°14 LPM et n°11 NIS) traite spécifiquement des comptes d’administration, destinés aux seuls personnels en charge de l’administration des infrastructures critiques : installation, configuration, maintenance, supervision, etc. L’exigence forte est la mise en place de comptes d’administration dédiés à la réalisation des opérations d’administration.

Au-delà du principe de moindre privilège explicitement mentionné, les comptes d’administration doivent respecter les mêmes exigences que les autres comptes telles que décrites précédemment.

Des indicateurs à produire pour surveiller les comptes à risque élevé

Enfin, la règle sur les indicateurs prévoit la définition de plusieurs indicateurs concernant la gestion des comptes présentant un niveau de risque élevé :

• Pourcentage de comptes partagés
• Pourcentage de comptes privilégiés
• Pourcentage de ressources dont les éléments secrets ne peuvent pas être modifiés

Au vu de ces exigences, l’intégration des infrastructures critiques dans les outils IAM (ci-après appelés « l’IAM ») de l’Opérateur apparaît comme la réponse nécessaire ; à compléter par l’application de mesures de durcissement (suppression, désactivation ou changement de mot de passe des comptes par défaut).

NB : les exigences LPM et NIS étant très similaires, nous emploierons par la suite le terme « OIV » pour désigner aussi bien les Opérateurs d’Importante Vitale et les Opérateurs de Service Essentiel, et le terme « SIIV » pour désigner les Systèmes d’Informations d’Importance Vitale et les Systèmes d’Informations Essentiels.

Pourtant, les Opérateurs hésitent encore à raccorder leurs infrastructures critiques à l’IAM

Les règlementations LPM et NIS ont accéléré la mise en place et le déploiement de solutions de bastion d’administration afin de sécuriser les accès d’administration. Cependant, bien que ces projets soient nécessaires, ils ne permettent de répondre que très partiellement aux exigences évoquées précédemment.

Ces règlementations devraient pourtant être un bon driver pour les projets IAM, mais les Opérateurs sont confrontés à deux principaux problèmes :

• La complexité d’intégration des systèmes industriels avec l’IAM – pour les Opérateurs industriels.
• Le risque induit par le raccordement des infrastructures critiques à l’IAM.

Des systèmes industriels complexes à intégrer

Les systèmes industriels présentent en effet des spécificités qui, d’une part complexifient le raccordement à un outil IAM, et d’autre part le rendent moins indispensable. Car, de façon générale :

• le nombre d’utilisateurs est limité ;
• ces systèmes sont cloisonnés, voire isolés du réseau d’entreprise ;
• la maturité sécurité des éditeurs et constructeurs est en retrait, les capacités d’interfaçage sont réduites, tant pour la gestion des comptes que pour la délégation d’authentification ;
• la granularité des droits d’accès est faible, se limitant souvent à autoriser l’accès ou non à l’ensemble du système, et non fonctionnalité par fonctionnalité.

Une intégration potentiellement génératrice de risques

Mais, au-delà de ces considérations propres aux systèmes industriels, les Opérateurs sont parfois réticents à mettre en place cette intégration, car elle est perçue comme génératrice de risques. En effet, si l’outil IAM ne présente pas un niveau de sécurité à la hauteur des règlementations, il pourrait paradoxalement constituer un point d’entrée sur les SIIV et ainsi amener de nouvelles vulnérabilités : création de compte ou attribution de droit illégitime, suppression malveillante de tous les comptes, etc.

Quant à mettre en place un IAM entièrement dédié au périmètre SIIV, cela représente un investissement très conséquent, parfois disproportionné, et qui ne permet pas de tirer tous les avantages d’un IAM mutualisé, par exemples les liens avec les sources autoritaires comme le SI RH.

Différentes approches d’intégration IAM permettent de répondre aux exigences règlementaires en maintenant un niveau de cloisonnement élevé

Dès lors, comment répondre efficacement aux exigences de la LPM et de la directive NIS ? Comment tirer parti des services proposés par les outils IAM sans ouvrir de nouvelle porte sur les infrastructures critiques ?

Nous distinguons différentes approches pour intégrer un système avec les outils IAM.

L’approche « délégation », à l’état de l’art mais fortement couplée

La première approche consiste à déléguer l’authentification et l’autorisation à l’IAM, en l’occurrence au service d’authentification et de contrôle d’accès, via un protocole de Fédération d’Identités (SAML2, OpenID Connect / OAuth2) ou via un raccordement Active Directory / LDAP.

Cette solution permet une gestion des comptes et des accès à l’état de l’art, mais rend le SIIV totalement dépendant de ce service et l’expose aux risques évoqués précédemment. Même en situation de crise, une isolation du SIIV serait difficilement envisageable.

Cette approche est donc plutôt à réserver aux applications qui fonctionnent déjà sur ce principe, typiquement les applications du SI de gestion avec un grand nombre d’utilisateurs. Pour les systèmes industriels, la solution à privilégier est de conserver le service d’authentification au sein du SIIV et d’opter pour une autre approche.

L’approche « provisioning », avec un niveau de couplage à ajuster au contexte

Cette approche consiste à conserver un système d’authentification et de contrôle d’accès propre au SIIV mais provisionné – c’est-à-dire alimenté – par l’IAM : les comptes et droits des utilisateurs sont stockés dans un référentiel interne au SIIV, et la solution IAM les gère au travers d’un connecteur. En fonction du niveau d’isolation souhaité, ce connecteur peut prendre différentes formes :

• Un connecteur automatique, permettant à l’IAM d’écrire directement les informations sur les comptes et accès dans le SIIV. Une isolation temporaire devient possible, en situation de crise ou en cas de détection d’activité anormale (par exemple : suppression massive de tous les comptes). Mais rien n’empêche un utilisateur malveillant ayant la main sur l’IAM de se donner accès au SIIV.
• Des ordres transmis aux administrateurs du SIIV (par ticket ITSM ou par mail) qui réalisent les actions manuellement. Un « sas » d’isolation est ainsi maintenu entre l’IAM et le SIIV, avec une étape de contrôle par les administrateurs.

Cette approche permet de bénéficier des processus de gestion des identités et des accès : validation et traçabilité des demandes d’accès, retrait des comptes et droits en cas de mutation ou de départ, etc. tout en préservant un degré de cloisonnement du SIIV.

L’approche « revue », orientée contrôle a posteriori

L’approche « revue » (également appelée « recertification ») se distingue des autres par le fait qu’elle repose sur une logique de contrôle a posteriori plutôt que de gestion a priori. Il s’agit cette fois d’analyser périodiquement les accès déclarés dans le SIIV afin de vérifier s’ils sont toujours légitimes. Cette vérification peut reposer sur un rapprochement des comptes avec un référentiel de collaborateurs (fichier RH, solution IAM, etc.), ou sur une validation explicite de la part des responsables des utilisateurs.

Ce peut être l’occasion de réaliser des contrôles approfondis (par exemple détection de combinaisons toxiques), de produire des indicateurs et des rapports d’audit.

Adapter son projet IAM – Infrastructures critiques à son niveau de maturité et à la typologie du SIIV

Sur la base de ces différentes options, nous proposons ci-dessous des pistes pour construire la feuille de route de mise en conformité LPM/NIS en fonction du niveau de maturité IAM et de la typologie des SIIV concernés.

Conserver la brique d’authentification et autorisation localement dans chaque SIIV

Il est préférable de conserver un référentiel de comptes et de droits d’accès localement dans chaque SIIV. Cependant, pour les systèmes déjà raccordés à un service mutualisé d’authentification et d’autorisation, le système mutualisé peut être conservé mais l’Opérateur doit lui appliquer les mesures prévues par la LPM et NIS : a minima le cloisonnement réseau, le durcissement, le maintien en conditions de sécurité, l’administration depuis un SI d’administration dédié, l’envoi des logs au SIEM, etc.

Dans un environnement de gestion des identités et des accès non mature, commencer par la revue des comptes et des droits

En l’absence d’outillage de gestion IAM mature, le moyen le plus rapide d’atteindre un premier niveau de maîtrise des risques et de conformité est de définir et mettre en œuvre un processus de revue régulière, sur une base a minima annuelle.

Sur un SIIV au nombre d’utilisateurs limité, le processus peut être déroulé manuellement, avec un niveau de qualité acceptable et une charge de travail raisonnable. Mais pour gérer des volumétries plus importantes, un outillage adéquat est à envisager : il facilite le pilotage des campagnes de revue et garantit la traçabilité des décisions. Il constitue en outre une opportunité pour envisager ensuite la mise en place d’un outil de gestion IAM.

Lorsqu’un outil de gestion IAM est en place, le sécuriser pour y raccorder les SIIV

Lorsque l’Opérateur dispose d’un outillage IAM mature, le provisioning des SIIV par l’IAM est recommandé : l’automatisation, la fiabilisation et la maîtrise que permettent les outils doivent compenser les risques induits par le couplage. A condition toutefois de garantir la sécurité de l’IAM : en complément des mesures techniques précédemment évoquées, l’Opérateur doit configurer l’IAM de sorte à ce que seuls les utilisateurs susceptibles d’accéder au SIIV peuvent demander l’accès, que le propriétaire du SIIV valide les demandes d’accès et puisse consulter facilement la liste des utilisateurs autorisés, et enfin que des contrôles permettent de détecter des anomalies sur les comptes et accès.

Le rehaussement de la sécurité profitera d’ailleurs à l’ensemble du Système d’Informations.

Trouver le bon équilibre risques / bénéfices pour construire son projet IAM – Infrastructures critiques

Ces propositions doivent permettre à tout Opérateur de construire sa feuille de route IAM pour ses infrastructures critiques en trouvant le bon équilibre entre les bénéfices apportés, les risques induits et le coût de mise en conformité.

Cet article Quelle approche pour gérer les identités et les accès sur les infrastructures critiques ? est apparu en premier sur RiskInsight.

Les objets connectés apportent de nouvelles perspectives pour l’évolution des processus et méthodes de travail des entreprises et utilisateurs. En effet, ces objets sont aujourd’hui en capacité d’interagir avec leur environnement pour échanger des informations ou exécuter des actions. Ces échanges se caractérisent notamment par des relations avec le système d’information de l’entreprise, les employés, les utilisateurs finaux et même les autres objets. Afin d’assurer la sécurité de ces échanges, il est absolument nécessaire de mettre en œuvre des mécanismes de contrôle d’accès, ce qui implique de connaître et de maîtriser les identités de l’ensemble des objets connectés du parc ainsi que celles des utilisateurs.

Cette discipline de gestion des identités est connue au sein des entreprises et rattachée au domaine de l’IAM (Identity & Access Management), c’est-à-dire la gestion du cycle de vie des identités des collaborateurs et partenaires (IAM traditionnel) ou des clients finaux (Customer IAM ou CIAM). Elle doit désormais se décliner sur le périmètre des objets connectés : c’est l’IAM of Things (IAMoT).

Figure 1 – IAM traditionnel, Customer IAM et IAMoT : trois domaines fortement liés

Un objet connecté, oui… mais avec quoi ?

Les interactions entre un objet connecté et son environnement peuvent être regroupées en 3 catégories principales.

1. Un objet connecté au SI de l’entreprise

C’est le premier cas d’usage qui vient à l’esprit. Chaque objet communique avec le SI via une identité unique qui le caractérise et des droits d’accès associés. Cela implique la mise en place de principes de création, de référencement, de gestion, de contrôle et de pilotage de ces identités. L’état d’un objet ou l’identité de son propriétaire doivent être connus à tout moment.

Dans une chaîne technologique type « objets – relais – plate-forme IoT – applications » la plate-forme IoT offre un point central permettant la gestion de l’ensemble des identités des objets.

Dans ce cadre, il est par ailleurs essentiel de maîtriser l’authentification des objets auprès des applications, et donc de définir les principes de génération des secrets qu’ils utiliseront.

Figure 2 – Chaîne technologique type

2. Un objet utilisé par les clients finaux

Pour ce type d’objets, une relation forte avec le domaine du Customer IAM apparaît. En effet, l’objet doit être en mesure de vérifier l’identité de l’utilisateur auprès du CIAM et de déterminer les services auxquels il a souscrit.

En cas d’usage partagé d’un même objet, un modèle de rôles et de données impliquant différents types d’utilisateurs finaux doit aussi être envisagé.

Prenons l’exemple d’un véhicule connecté :

• Le conducteur du véhicule souhaite accéder au service GPS. Avant de permettre l’accès au service le véhicule doit répondre à de nombreuses questions. Quelle est l’identité du conducteur et quel profil personnel dois-je utiliser (chargement des précédents trajets) ? Est-il propriétaire du véhicule, locataire ou s’agit-il d’un prêt pour un usage ponctuel ? Le conducteur a-t-il souscrit au service GPS auprès du fabricant et à quel niveau de service (calcul des trajets uniquement ou alerte des zones de danger) ?

3. Un objet en interaction avec les employés de l’entreprise et ses partenaires

Dernier cas, chaque objet peut interagir avec les employés de l’entreprise, des prestataires ou des partenaires. La relation avec le domaine de l’IAM traditionnel assurant la gestion des habilitations et des rôles des partenaires et employés de l’entreprise est alors essentielle.

Les différents usages de l’objet imposent la création d’un modèle de rôle permettant de répondre à la question : quels droits pour quelles populations sur quelles fonctionnalités de l’objet ?

Reprenons l’exemple d’un véhicule connecté :

• Lors d’une réparation un garagiste doit pouvoir, à des fins de diagnostic, visualiser les derniers indicateurs de fonctionnement d’un véhicule avant une panne. S’agit-il d’un garagiste du réseau constructeur ou d’un garagiste indépendant ? Peut-il accéder aux informations GPS ou uniquement aux indicateurs techniques du moteur ? Le client final peut-il consentir ou a minima être informé de l’accès aux données de son véhicule ?

Cet exemple met aussi en évidence le fait que les droits accordés peuvent être étroitement liés à la notion de temps (uniquement pendant la durée de la réparation) ou à la nature d’une donnée (protection de la vie privée dans le cas des données GPS).

L’IAM of Things, c’est aussi des processus

Tous les experts de l’IAM vous le diront : il n’y a pas d’IAM sans une étude approfondie du cycle de vie de identités concernées. L’IAMoT doit étudier l’ensemble des processus impliquant l’objet sur l’ensemble de son cycle de vie. En effet, tout au long de la vie d’un objet, la nature des interactions avec son environnement est amenée à évoluer selon l’état dans lequel il se trouve. Un objet neuf devra, par exemple, être associé à son utilisateur principal via un processus d’appairage assurant un niveau de confiance en cohérence avec les enjeux.

Appuyons-nous une dernière fois sur l’exemple du véhicule connecté :

• Un particulier vient de faire l’acquisition d’un véhicule connecté d’occasion auprès d’un autre particulier. Dans le cadre de cette revente, il est nécessaire pour le nouvel acquéreur de s’assurer que les accès aux services sont révoqués pour le précédent propriétaire. La détection de l’événement de revente doit donc déclencher un processus de désappairage de l’ancien propriétaire.

Figure 3 – Ingrédients pour la recette de l’IAM of Things

L’IAM of Things, une nouvelle discipline s’appuyant sur des concepts maîtrisés

Cet article met en évidence la problématique de la gestion des identités pour l’IoT et souligne les liens existant avec les autres domaines de l’IAM. Il est important de retenir que, même si les principes fondamentaux de l’IAM s’appliquent aussi à l’identité des objets connectés, des réponses adaptées à chaque contexte projet doivent être étudiées.

Cet article Qu’est-ce que l’IAM of Things ? est apparu en premier sur RiskInsight.

Ce vecteur d’attaque est applicable à tous les services utilisant une solution de SSO basée sur le protocole SAML2 (hors implémentation HSM).

Explication du Golden SAML

Le titre du billet n’est pas anodin puisque le « Golden SAML » s’apparente au « Golden Ticket » qui frappe le protocole Kerberos. Comme le Golden Ticket, le Golden SAML permet à un attaquant d’accéder à des ressources protégées par des agents SAML (exemples :  Azure, AWS, vSphere, Okta, Salesforce, …) avec des privilèges élevés grâce à un « ticket en or ». Elle permet en outre à l’attaquant d’agir dans l’ombre sans se faire repérer, puisque suite à l’attaque les jetons peuvent être générés hors du SI sans sollicitation du fournisseur d’identité (IDP).

Dans une cinématique standard SAML :

1. Le client tente d’accéder à une application (Service Provider).
2. L’application génère une requête « SAML AuthRequest » afin d’authentifier l’utilisateur.
3. Le fournisseur d’identité (Identity Provider ou IDP) authentifie l’utilisateur et envoie à l’utilisateur une réponse « SAML response » qu’il peut utiliser pour accéder à des ressources exposées par un fournisseur de service (Service Provider ou SP).
4. Le SP vérifie la réponse et identifie l’utilisateur qui est désormais habilité à utiliser le service.

L’attaque repose sur la falsification de la réponse SAML qui permet d’identifier et d’authentifier l’utilisateur. La réponse est signée par la clé privée du fournisseur d’identité et éventuellement chiffrée, selon l’implémentation. En vérifiant l’intégrité de la réponse SAML grâce à sa signature, l’application s’assure que celle-ci a bien été forgée par le fournisseur d’identité et n’a pas été modifiée durant son transit.

Afin de falsifier la réponse, plusieurs informations sont nécessaires :

• La clé privée du fournisseur d’identité ;
• Le certificat public du fournisseur d’identité ;
• Le nom du fournisseur d’identité ;
• Le nom du rôle à usurper (exemple : administrateur).

La seule information réellement complexe à obtenir est la clé privée de signature des réponses SAML. Les trois autres sont des données facilement accessibles, notamment dans les réponses.

Il est possible d’exporter la clé privée en accédant à l’IdP avec un compte admin AD FS. Une première attaque sur ce compte est donc nécessaire.

Une fois ces informations collectées, l’attaquant peut alors librement générer des réponses valides en dehors du domaine sans être repéré. La mise en place d’une authentification forte sur les comptes visés ne protège pas d’avantage de l’attaque puisque la preuve de cette authentification reste portée par la réponse SAML qui peut désormais être falsifiée.

Tant que le certificat de l’IdP n’est pas modifié et que ce changement n’est pas pris en compte sur l’ensemble des fournisseurs de services, l’attaque peut perdurer.

Décryptage de l’attaque

Malgré le ton alarmiste du billet, la vulnérabilité décrite peut tout au plus être assimilée à un choix de conception discutable du protocole SAML 2 qui utilise des jetons signés, mais non à une faille réelle de sécurité. En effet, la condition nécessaire est d’avoir compromis un compte administrateur AD FS pour récupérer la clé privée du domaine. Cependant, l’impact est fort puisque l’attaquant peut, de manière illimitée et hors domaine, accéder à des services protégés par des agents SAML faisant confiance au domaine. La récupération du compte IdP peut être détectée mais les falsifications de réponse peuvent se faire en toute discrétion a posteriori.

En outre, si la compromission d’un compte d’administrateur IdP est détectée, le changement de mot de passe de ce compte ne rendra pas la confidentialité de la clé privée et ne permettra pas de contrer le Golden SAML. Ainsi, la seule solution pour bloquer l’attaquant est de changer la clé privée, ce qui peut avoir un impact fort pour les fournisseurs de service faisant confiance à l’IdP à savoir le rejet temporaire des réponses signées avec la nouvelle clé.

En définitive, le vol de clé privée permet de rendre vulnérable la fédération d’identité et ceci n’est pas nouveau. Les IdP SAML sont concernés comme tout protocole de sécurité émettant des documents signés (OpenID Connect, PKI …)

Comment se prémunir ?

La sécurité des jetons SAML reposant avant tout sur celle de la clé privée de l’IdP, il est impératif de mettre en œuvre tous les moyens nécessaires pour la protéger.

Deux approches sont possibles pour stocker et utiliser cette clé : la solution logicielle et la solution matérielle.

Solution logicielle

Dans le premier cas, la clé est stockée sur un serveur qui porte la responsabilité de la conserver secrète et de réaliser les opérations de signature des réponses. On devra ainsi s’assurer que la machine et son environnement soient bien protégés. Pour cela, il est recommandé d’appliquer certaines recommandations habituelles de sécurité à savoir : isoler cette machine sur un VLAN d’administration, restreindre son accès aux opérateurs essentiels à son fonctionnement, sécuriser ─ via une authentification forte ─ les comptes à privilège permettant d’accéder à la clé, appliquer régulièrement les correctifs de sécurité sur la machine, journaliser les accès, mettre en place des règles SIEM appropriées à l’IdP pour détecter les intrusions, etc.

Si ces mesures de préventions permettent de limiter les risques de compromission de la clé, elles ne peuvent garantir de manière certaine que celle-ci n’ait pas été ou ne sera pas exfiltrée. Il est donc souhaitable que le certificat de l’IdP et sa clé privée puissent être renouvelés à intervalles réguliers, ou en cas de doute sur le maintien de sa confidentialité. Suite au renouvellement du certificat de l’IdP, il sera nécessaire que les fournisseurs de service puissent accepter les jetons sans interruption des accès; en s’assurant qu’ils soient en capacité de récupérer le certificat de manière synchrone et d’accepter les jetons signés par cette clé tout en rendant l’ancien certificat invalide. Cela pourra se faire en exposant le nouveau certificat sur une ressource dédiée.
Toutefois, il est souvent constaté que des effets de bords apparaissent lors d’une rotation de clés (exemple : impacts sur le Service Provider). De même, il est rare qu’un Service Provider puisse supporter une révocation de clé via CRL.

Solution matérielle

La solution matérielle, qui repose sur l’utilisation d’un HSM (Hardware Security Module), est bien plus robuste car elle garantit l’inviolabilité de la clé de signature. Le module se charge de protéger la clé et de réaliser l’ensemble des opérations cryptographiques nécessaires à la signature des réponses. La clé ne sort donc jamais du HSM et une génération de jeton à l’extérieur du SI devient impossible.

Cependant, l’IdP devra protéger le secret lui permettant d’interroger le HSM en suivant les recommandations usuelles exposées précédemment. Si ce secret est compromis, il pourra être généré de nouveau sans impacter les fournisseurs de service.

Cet article Décryptage de l’attaque « Golden SAML » de CyberArk est apparu en premier sur RiskInsight.

Pour éviter ces attaques aux conséquences onéreuses, les entreprises se concentrent bien évidemment sur la sécurisation de leurs infrastructures informatiques critiques, mais les cyber-attaques ne visent pas uniquement les vulnérabilités des réseaux, data centers et postes de travail. Les utilisateurs qu’ils soient internes ou externes à l’organisation sont une cible de choix pour les attaquants, qui usurpent l’identité de l’organisation ciblée afin de réaliser leur méfait.

La présence digitale d’une entreprise : un nouveau facteur de risque

Ces dernières années, la transformation digitale des entreprises s’est caractérisée, entre autres, par un développement exponentiel de la communication externe via le numérique ; les canaux de communication se sont multipliés et renforcés en tant que vecteurs privilégiés d’échange et d’interaction, révolutionnant la relation client et les échanges avec les partenaires. Pour être toujours plus proches près de ces derniers, les entreprises ont favorisé l’utilisation de la communication digitale via :

• Les emails
• La messagerie instantanée
• Les sites web institutionnels et applications web
• Les applications mobiles
• Les réseaux sociaux

Ces médias sont la vitrine de l’entreprise, ils lui permettent de se dépeindre, d’exposer et faire rayonner son image de marque, via les messages, les éléments de langage et l’impact graphique qui lui sont propres. Ils sont la personnification de l’entreprise et renvoient donc directement à sa valeur perçue. De plus, la digitalisation a permis de substituer en grande partie la relation physique par les services numériques, accessibles à toute heure, n’importe où dans le monde et via lesquels l’entreprise donne accès à sa communauté ainsi qu’à ses services et produits, permettant de dynamiser les interactions avec les utilisateurs, toujours plus simples, rapides et personnalisées.

Cette présence digitale accrue ayant permis aux entreprises de développer leur communication ainsi que l’accessibilité à leurs services, les canaux digitaux représentent donc directement l’entreprise et sont l’étendard de son image de marque. Mais il y a bien un revers à cette médaille : cette omniprésence digitale augmente la possibilité pour les attaquants d’usurper l’identité de la société à des fins malveillantes.

La dégradation de l’image de marque : dommage collatéral des cyberattaques

Lors d’une cyberattaque utilisant l’usurpation de l’identité de l’entreprise comme vecteur, les intentions des attaquants peuvent être diverses :

Certaines attaques ont pour objectif direct la décrédibilisation d’une entreprise, mettant ainsi en exergue une certaine incompétence de l’entreprise ou la supériorité d’un groupe malveillant qui souhaite imposer son idéologie antagoniste :

Sur les dernières années, ont eu lieu des cas de défacement de sites internet où le contenu des pages s’est retrouvé modifié pour transmettre de fausses informations et moquer les entreprises afin de nuire à leur image. En 2015, Lenovo en a fait les frais quand le groupe de hackers activistes Lizard Squad s’en est pris à son site web, en redirigeant les visiteurs vers des photos des protagonistes de l’attaque. Il est aussi possible pour les attaquants de publier de fausses informations sur un réseau social après le vol des identifiants du Community Manager. Un des faits marquants de 2017 a été la prise en main du compte Tweeter du ministère de la culture par un plaisantin distillant de nombreux tweets injurieux. Pour les entreprises victimes de ces attaques, les conséquences financières sont à prévoir : suite à ces évènements et annonces, les répercussions sur les ventes et le cours de la bourse sont toujours accompagnées d’un lourd impact sur l’image de marque.

Dans d’autres cas, l’identité de l’entreprise est cette fois détournée par les attaquants cherchant à dérober de l’argent. Dans ce cas, les attaquants se font passer pour l’entreprise afin de réaliser des fraudes visant directement les utilisateurs avec pour but de les duper :

Les arnaques au président sont en augmentation constante et permettent aux attaquants de détourner des sommes d’argent importantes en trompant les employés des directions financières qui pensent devoir exécuter un virement urgent pour un directeur ou membre du COMEX. En France, le préjudice total de cette fraude est estimé à plus de 400 millions d’euros par an.

Les employés des entreprises sont également la cible des campagnes de phishing, qui permettent de déclencher une charge virale contenue dans une pièce jointe ou un lien d’un e-mail paraissant familier. Le but peut être de déployer un cryptolocker pour demander une rançon, ou d’avoir une porte d’entrée sur le système d’information de l’organisation.

Les entreprises sont aussi touchées indirectement quand les campagnes de phishing utilisent leur nom de domaine pour envoyer de faux emails aux clients et leur demandent une mise à jour de leurs informations bancaires ou autres données personnelles pouvant avoir de la valeur.

La grande nouveauté pour la récupération de données client est l’utilisation de fausses apps mobiles imitant une application légitime par son logo et son interface mais agissant comme un logiciel espion (spyware) une fois installée sur le smartphone de l’utilisateur. Ainsi, une fausse application Whatsapp intégrant un malware a été téléchargée plus d’1 millions de fois sur le Google Play store au mois d’octobre 2017.

Dans un monde numérique où la confiance des clients, de plus en plus sensibles aux sujets cyber, se perd facilement, protéger son image et sa marque est donc devenu un enjeu majeur pour les entreprises, au même titre que la protection de ses infrastructures informatiques et ses données. Mais quelles sont les bonnes pratiques à mettre en place pour limiter ces risques d’usurpation ?

Des solutions dédiées et une veille organisée pour mieux se protéger

La protection de l’image de marque d’une entreprise passe ainsi nécessairement par la protection des canaux de communication digitaux. Dépendant de la typologie du canal, différentes actions peuvent être entreprises :

• L’organisation de veille sur les noms de sites web, d’adresses email et de comptes de réseaux sociaux similaires à celui de l’entreprise est une pratique conseillée par l’ANSSI pour lutter contre l’usurpation de la marque, de même que la surveillance des « Dark App store » mettant à disposition des utilisateurs des versions piratées et potentiellement malveillantes d’applications mobiles de l’entreprise.
• La réalisation régulière d’audits et l’utilisation de scanners de vulnérabilité sur les sites institutionnels et les applications mobiles permet l’identification des vulnérabilités qui seraient des points d’entrées lors d’une cyberattaque. Les mesures de correction nécessaires peuvent alors être mises en œuvre pour sécuriser ces médias notamment contre le défacement.
• L’implémentation d’authentification multi-facteurs pour les comptes des administrateurs des services email et des réseaux sociaux permet de réduire le risque d’usurpation de session par le simple vol d’identifiants. Le risque d’une publication ou du partage de contenus malveillants se retrouve ainsi limité, de même que le vol de données sensibles accessibles via les boîtes mails, comme ce fut le cas en 2017 pour le cabinet Deloitte. En effet, plus de 5 millions d’emails contenant des échanges sensibles avec leurs clients ont été dérobés, suite au vol des identifiants d’un de des administrateurs du cabinet
• L’activation de protection comme SPF, DKIM ou DMARC permet d’empêcher l’usurpation des adresses emails de l’entreprise. En effet, ces protocoles permettent de protéger les noms de domaine de l’entreprise en déclarant les adresses IP légitimes pour l’envoi d’emails et en implémentant des mécanismes de signature des emails pour les certifier. Ces protocoles garantissent qu’on ne puisse pas utiliser le nom de domaine de l’entreprise depuis un serveur non déclaré.

L’exposition de l’identité des entreprises ayant été favorisée par la digitalisation, les attaquants et cyber activistes en profitent donc pour attaquer les entreprises et leur écosystème en se faisant passer pour celles-ci. Dans l’ensemble de ces attaques et fraudes, l’attaquant arrive par des moyens plus ou moins complexes à usurper l’identité de l’entreprise pour l’attaquer et à la fragiliser. Une dégradation de l’image de marque d’une entreprise auprès de ses clients mais également du grand public, peut provoquer des pertes financières se chiffrant millions d’euros, auxquels s’ajoutent les pertes faramineuses qu’une attaque paralysant le SI de l’entreprise engendre.

Le sujet de la protection de l’identité digitale des entreprises, quelle que soit sa forme, doit donc être adressé afin qu’elles se prémunissent des fréquentes et coûteuses usurpations dont elles sont victimes.

Cet article Protection de l’identité de l’entreprise, nouveau challenge de la digitalisation 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.

VERS UN CADRE COMMUN

Bien qu’aujourd’hui le règlement reprenne la majeure partie des dispositions de la directive qu’il abroge, il y apporte cependant quelques modifications, et de nouvelles dispositions, renforçant ainsi cette reconnaissance européenne des services de confiance. Le règlement détermine notamment :

• Les conditions dans lesquelles un État membre reconnaît les moyens d’identification électronique des personnes physiques et morales qui relèvent d’un schéma d’identification électronique notifié d’un autre État membre ;
• Les règles applicables aux services de confiance, en particulier pour les transactions électroniques ;
• Le cadre juridique pour les services de signatures électroniques, de cachets électroniques, d’horodatages électroniques, de documents électroniques, d’envoi recommandé électronique et les services de certificats pour l’authentification de site internet.

Contrairement à la directive 1999/93/CE, eIDAS est un règlement, il n’y a donc pas de transposition nationale, le texte est applicable pour l’ensemble des États membres.

VERS UNE HARMONISATION EUROPÉENNE : LES POINTS CLÉS

Le règlement introduit un certain nombre de nouvelles notions, parmi lesquelles on peut noter :

• L’acceptation du document électronique en tant que preuve devant la justice;
• La création d’un label de confiance pour un marché plus transparent ;
• L’encadrement des méthodes de validation de signatures qualifiées par le biais de prestataires de services de confiance ;
• Le service de conservation qualifié des signatures électroniques qualifiées pour garantir la fiabilité des signatures et donc leur valeur dans le temps ;
• L’horodatage au niveau européen permettant une reconnaissance de la datation et de l’intégrité de données numérique et donc de la validité juridique du document dans toute l’UE ;
• L’obligation pour les États membres de maintenir des listes de confiance des services et prestataires qualifiés et labélisés à disposition du grand public ;
• L’assouplissement de la signature sécurisée : reconnaissance de la signature créée à distance par un tiers de confiance au nom du signataire pour faciliter les usages en mobilité.

Parmi les autres points remarquables, nous pouvons citer l’apparition d’un nouveau principe juridique : la signature électronique de personne morale. Le cachet électronique permettra donc aux entreprises et administrations de signer électroniquement en leur nom des documents afin de certifier leur provenance. Concrètement, un juge français ne pourra pas refuser un cachet ou une signature électronique apposé par un italien avec une solution allemande. Enfin, nous pouvons également souligner l’introduction de la notion de signature qualifiée côté serveur, ce qui permettra otamment le développement de nouvelles offres (en SaaS), objectif clairement affiché de ce nouveau règlement.

eIDAS définit ainsi une graduation en 3 niveaux de signature de personne physique, synthétisé dans le tableau ci-dessous, contre 2 niveaux anciennement pour la directive.

3 niveaux de signature physique

L’Europe s’intéresse à l’adoption de ces technologies dans les pays membres

Les autorités européennes, en particulier la direction générale de l’informatique (DG DIGIT) en charge des 4 piliers fondamentaux que sont l’eInvoicing, l’eDelivery, l’eSignature et l’eID, ont souhaité évaluer concrètement les forces en présence dans chaque pays. À ce titre, ils ont fait réaliser par Wavestone Luxembourg un sondage et organisé des groupes de travail à l’échelle européenne pour identifier les acteurs présents sur le marché et leurs besoins. Les différentes solutions pour stimuler l’adoption de chacun de ces piliers fondamentaux ont été analysées et discutées avec l’ensemble des acteurs. Résultats à venir !

Cet article Nouveau règlement eIDAS : en route vers une Europe de la confiance numérique est apparu en premier sur RiskInsight.

Touch ID, un lecteur d’empreintes simple et plus sûr

Selon Apple, Touch ID est plus sécurisé qu’un code à quatre chiffres : la probabilité que le capteur confonde deux empreintes digitales est de 1 sur 50 000 et elle augmente à « 1 sur 10 000 lorsqu’un utilisateur non autorisé devine un code d’accès à 4 chiffres ». Il faut néanmoins préciser que ces deux chiffres ne sont pas réellement de même nature car le premier représente une probabilité de fausse détection tandis que le second correspond à la probabilité de trouver le bon code de déverrouillage, et donc de pouvoir se ré-authentifier par la suite.

Utiliser Touch ID est également relativement simple. Lorsque le doigt est apposé sur le bouton d’activation de l’écran d’accueil, une photographie haute résolution de l’empreinte digitale est prise, puis comparée à un gabarit référence généré au moment de l’enregistrement de l’utilisateur. Concernant la confidentialité de ces données, la documentation technique précise que lors du processus d’enregistrement, c’est la modélisation mathématique de l’empreinte digitale qui est hébergée dans l’enclave sécurisée du processeur, au plus proche du capteur, et non les empreintes digitales des utilisateurs.

Un capteur biométrique aux usages multiples

Avec le lancement de l’iPhone 6 et d’iOS 8, les usages évoluent. Jusqu’à présent, le capteur permettait uniquement de s’authentifier et de payer ses achats sur l’Apple store, l’iTunes Store et l’iBooks Store. Désormais, l’arrivée d’Apple Pay permet de réaliser tous types d’achats en validant ses paiements via Touch ID, notamment grâce à l’intégration d’une puce NFC (pour le moment, Apple Pay n’est disponible qu’aux États-Unis). Il devient également possible de sécuriser l’accès à des applications tierces.

Les nouvelles fonctionnalités que pourraient offrir ces capteurs biométriques sont nombreuses, telles que déverrouiller une voiture ou effectuer un virement bancaire. La question de la sécurité devient donc cruciale.

Performances et limites de Touch ID

En dépit des tests et des études montrant que cette technologie est robuste et que les taux de faux positif et de faux négatif restent bas, Touch ID possède quelques limites.

L’authentification peut être avortée si le lecteur biométrique porte des traces de poussières, de graisse…Le capteur est également insensible à la chaleur corporelle et ne fait donc pas la différence entre la peau et les corps inertes. Enfin, comme pratiquement tous les lecteurs d’empreintes digitales, il est possible de le piéger. De nombreux experts en sécurité ont posté des vidéos montrant leurs tentatives réussies de piratages à partir de fausses empreintes digitales. Le « Chaos Computer Club » a ainsi réussi à tromper Touch ID en photographiant en haute résolution une empreinte digitale et en moulant cette dernière.

Nous avons, nous aussi, voulu tester la fiabilité de cette technologie avec de fausses empreintes digitales réalisées en gélatine alimentaire et en colle à bois. Le processus est fastidieux et les résultats varient en fonction de la qualité des copies et de leur fidélité par rapport à l’originale, mais nous sommes bien parvenus à déjouer le capteur biométrique.

Ainsi, une personne mal intentionnée pourrait parvenir, moyennant de nombreux efforts, à s’authentifier sur les appareils utilisant la biométrie par Touch ID. Cela implique cependant de pouvoir récolter une empreinte digitale nette, claire et épaisse qui puisse être facilement dupliquée, ce qui est au quotidien difficile à trouver.

Des évolutions dans le futur ?

Simple d’usage et efficace, la technologie Touch ID est une belle avancée pour la sécurité des terminaux mobiles. Malgré ses limites, les usages cités précédemment (accès aux données personnelles sur les terminaux, paiements mobiles…) ne devraient théoriquement pas souffrir de problèmes majeurs de sécurité pour le grand public.

Cependant, pour des populations sensibles ou dans des contextes à risques, il faut avoir conscience des limites concrètement démontrées. Il aurait été souhaitable que la sortie de l’iPhone 6 améliore de façon notable la sécurité et les performances du capteur biométrique. Malheureusement, à part une plus grande sensibilité impliquant une diminution du taux de faux négatifs (la résolution du capteur étant plus grande), il n’y a pas eu de modifications substantielles. Dans le futur, une approche combinant l’empreinte et un code pourrait être une évolution intéressante et simple à mettre en œuvre.

Enfin, si l’on souhaitait renforcer la sécurité de manière significative, on aurait pu s’orienter vers des technologies biométriques « sans traces » (réseau veineux, reconnaissance d’iris…etc). Mise à part l’usabilité de la plupart de ces technologies qui ne permet pas à l’heure actuelle de les intégrer sur un smartphone, la question essentielle est de savoir si le grand public est prêt à les accepter et à les utiliser. Affaire à suivre…

Cet article Touch ID marque-t-il la sécurité de son empreinte ? est apparu en premier sur RiskInsight.

Des tentatives infructueuses

La carte d’identité nationale électronique sécurisée est un projet d’identité numérique français datant de 2003. Cette carte d’identité devait contenir des informations biométriques. Ces données devaient également être conservées dans un fichier centralisé, solution perçue comme une atteinte aux libertés individuelles par nombre d’associations. Le projet a été arrêté puis relancé à de nombreuses reprises jusqu’en 2012. Le Conseil constitutionnel donna alors un coup d’arrêt définitif au projet en le censurant.

En parallèle, certains citoyens français ont pu expérimenter l’utilisation d’un certificat électronique « pour un usage unique » dans le cadre de leur déclaration d’impôts en ligne. L’expérimentation a finalement été abandonnée en raison de processus jugés trop complexes pour les utilisateurs (notamment lors d’un changement d’ordinateur) et trop coûteux pour le fournisseur (notamment en matière de support aux utilisateurs).

En 2010, un nouveau projet d’identité numérique, baptisé IDéNum est lancé. Deux ans plus tard, peu d’avancées concrètes à constater, sans qu’aucune raison officielle ne soit donnée.

L’échec des précédents projets gouvernementaux n’a cependant pas découragé les initiatives privées. Ainsi, La Poste propose un service de courrier recommandé en ligne, via une identité numérique baptisée « IDN ». Les informations personnelles sont vérifiées via plusieurs mécanismes, notamment la présentation d’une pièce d’identité à domicile à un facteur. Son utilisation reste cependant limitée à cet usage très ciblé.

2013 : un nouvel envol ?

Le gouvernement tente de relancer le projet IDéNum depuis début 2013. Le projet, financé par un partenariat public-privé, doit permettre de « préserver notre souveraineté nationale face aux alternatives étrangères et non sécurisées ».

Le projet adopte une approche innovante : garantir la fiabilité des Identités émises sans imposer l’État comme autorité de confiance. Ainsi, IDéNum devrait proposer un ou plusieurs « labels » reprenant des critères de qualité, de confidentialité, d’interopérabilité ou encore de contrôle fixés par l’État. Charge aux fournisseurs d’Identités privés de répondre à ces critères pour être labélisés et ainsi pouvoir émettre des Identités numériques fiables et reconnues.

Cette identité numérique devrait permettre d’accéder aux services administratifs de l’État, et plus largement à n’importe quel service privé qui y aura souscrit. C’est donc bien le « label » qui porte le niveau de fiabilité associé à l’identité numérique. D’où, peut-être, la possibilité de promouvoir plusieurs labels, correspondant à des critères de qualité différents, et adaptés à différents usages. Le « label » devrait aussi définir les « droits et devoirs » des fournisseurs de services souhaitant utiliser IDéNum. Ainsi, il permettrait d’encadrer l’usage et la diffusion des données recueillies.

Caractère universel, maîtrise de ses informations personnelles et fiabilité : 3 conditions de succès

Quels que soient les choix retenus, trois points cristallisent la relation à l’objet « identité numérique », et donc son futur niveau d’adoption : le caractère universel de son usage, la confiance de l’utilisateur dans le système – matérialisée par la maîtrise de ses informations personnelles -, et la confiance des fournisseurs de services utilisant ce même système, matérialisée par la fiabilité des informations.

Le caractère quasi universel d’une identité numérique – c’est-à-dire la possibilité de l’utiliser pour tout, tout le temps sans limite ni contrainte – est une condition sine qua non à une adoption de masse. Aussi, la question de l’interopérabilité, avec fournisseurs de services et entre pays, est primordiale. Le projet se doit donc d’emporter l’adhésion de nombreux acteurs publics comme privés. Pour cela il doit notamment offrir une prise en main et une utilisation des plus simples, pour les utilisateurs et également pour les fournisseurs de services. Par ailleurs, les initiatives de chaque pays européen doivent être compatibles et offrir un unique standard d’interopérabilité. En 2012, la Commission européenne a d’ailleurs publié un projet de règlement visant à définir un cadre européen pour l’identité numérique.

De plus, les utilisateurs doivent avoir confiance dans la maîtrise de leurs informations personnelles. La multiplication des comptes en ligne a conduit les internautes à diffuser massivement des informations personnelles, qui sont parfois monnayées à des tiers. L’identité numérique, qui fournit des informations qualifiées, ne doit pas devenir une source d’information à tout-va. L’utilisateur devra pouvoir choisir quelles informations il souhaite communiquer en fonction du service accédé et donc contrôler la diffusion de ses informations personnelles.

Aujourd’hui, un site de poker en ligne qui souhaite vérifier que vous êtes majeur vous demande de fournir une photocopie de votre carte d’identité. Cette dernière contient bien plus d’informations que la simple réponse à la question « Êtes-vous majeur ? ». Une identité numérique pourrait autoriser une granularité bien plus fine dans la diffusion des informations personnelles. De la même manière, un site de vente en ligne a besoin de connaître votre adresse postale, mais non votre date de naissance ou votre statut marital. Autre point d’attention : les adhérences entre les sphères privées, publiques ou professionnelles. Un fournisseur de services (par exemple de la sphère professionnelle) ne devrait a priori pas avoir connaissance des autres usages associés à une identité. L’identité numérique doit donc garantir souplesse, transparence et confidentialité sur les informations diffusées.

Enfin, l’adoption par les fournisseurs de services passe par un niveau de confiance élevé dans la fiabilité des informations recueillies. Par exemple, pour les services les plus critiques, permettre d’interroger le fournisseur d’Identités numériques pour garantir la validité de l’information fournie. À l’instar des cartes d’Identité physique, le vol ou la falsification seront autant de menaces pesant sur l’identité numérique. D’où la nécessité de définir un cadre légal, autant pour protéger les utilisateurs que les fournisseurs de services.

Alors, l’identité numérique, un levier pour de nouveaux usages ?

IDéNum doit permettre de dématérialiser encore plus de procédures, avec un niveau de confiance adapté, et accélérer ainsi l’émergence de nouveaux services sur internet (B2C notamment). Les entreprises vont en particulier y trouver un levier pour faciliter la relation client. L’identité numérique devrait simplifier des processus de souscription, et améliorer la confiance mutuelle : l’utilisateur dans l’usage de ses données personnelles et les fournisseurs de services dans la qualité des informations recueillies.

Mais soyons pragmatiques et n’attendons pas IDéNum pour avancer. Les Identités numériques existent déjà, même si elles ne sont pas qualifiées ou réputées fiables. Et pour certains usages, c’est déjà bien suffisant. Quels risques à permettre à un prospect de sauvegarder un devis et de s’authentifier avec son compte Google ? Si vous employez des étudiants saisonniers durant les congés estivaux, est-ce plus risqué d’utiliser des comptes génériques avec un mot de passe trivial, ou de leur permettre de s’authentifier avec leur compte Facebook ou LinkedIn ? Cette tendance est d’ailleurs déjà associée à un acronyme : « BYOID » pour Bring Your Own IDentity.

Au-delà des concepts, les fondamentaux « traditionnels » de l’identité doivent rester au cœur des réflexions : comment proposer une Identité unique et pérenne ? Comment garantir le lien avec le cycle de vie des utilisateurs dans l’entreprise ? Ou encore comment garantir un niveau d’authentification en cohérence avec les services offerts et les risques associés ? Autant de questions qui devront servir de guide à la définition de l’identité numérique de demain.

Cet article Identité numérique : quel état des lieux aujourd’hui en France ? est apparu en premier sur RiskInsight.

Des principes de bases partagés mais des divergences dans leur application

De nombreux pays tentent, à leur échelle, de répondre aux enjeux de l’identité numérique. Ces initiatives partagent les mêmes principes de base, calqués sur ceux de l’identité réelle. En revanche, elles divergent sur la mise en application de ces principes : acteurs autorisés à émettre des identités numériques, stockage des données personnelles, caractère universel ou non, etc. Ces spécificités ont pour objectif de façonner une identité numérique au plus près de la culture de chaque pays.

L’émission des identités numériques : par l’État, mais pas uniquement

Contrairement au monde réel, ce sont les acteurs privés qui ont été force d’initiative sur Internet. Par exemple Yahoo, Facebook, Google ou d’autres sites proposent d’ores et déjà de vous authentifier sur des sites tiers. Mais attention, si ce mode de fonctionnement apporte un réel confort aux utilisateurs, ces identités restent déclaratives, sans réellement améliorer le niveau de confiance associé. En effet, personne n’a vérifié que vous êtes bien la personne que vous prétendez être.

Comment alors vérifier les informations fournies et améliorer la fiabilité des identités ?

C’est souvent l’État qui se charge de vérifier et délivrer les Identités numériques de confiance. Toutefois, et principalement pour des raisons culturelles, cette responsabilité peut être déléguée à des entreprises privées, parfois sous contrôle de l’État. C’est notamment le cas au Royaume-Uni, où il n’existe pas de carte d’identité. La dernière tentative du gouvernement pour introduire une carte d’identité en 2010 n’a pas survécu à son impopularité. Le gouvernement s’est alors tourné vers les modèles américains et canadiens, en choisissant de confier la délivrance d’Identités numériques à des acteurs privés. Ainsi, il est possible de se connecter certains sites administratifs de l’État avec une Identité numérique fournie par Paypal ou The Post Office.

Des données personnelles stockées de manière centralisée ou portées par chacun

Autre point structurant de divergence entre les initiatives : le stockage des données d’identité.

Le plus souvent, les informations d’Identité numérique se présentent sous la forme d’une carte à puce. Celle-ci contient peu ou prou les mêmes informations qu’une carte d’identité traditionnelle, ainsi que des certificats électroniques protégés par un code PIN. Elle peut être intégrée à la carte d’identité physique, ou être contenue dans un support dédié (carte à puce, clé USB, carte SIM du téléphone portable…).

À contrario, l’Inde a pris le parti de centraliser les données biométriques de ses citoyens dans une base de données unique. D’ici 2015, le gouvernement espère enregistrer dans un fichier centralisé les empreintes digitales et rétiniennes de la moitié de la population. Avec un terminal biométrique, toute administration ou commerçant affilié peut alors identifier une personne. Notons que, en l’état actuel, un tel dispositif ne pourrait être transposable en France, la CNIL interdisant l’utilisation d’une base de données biométrique centralisée, sauf pour « fort impératif de sécurité »¹.

Déployer l’identité numérique : l’exemple Estonien 

L’initiative de l’Estonie se démarque cependant par son niveau d’adoption et le caractère universel de l’usage de l’identité numérique, tant dans le monde numérique que dans le monde réel. Grâce à un badge remis à tout citoyen (ou à la carte SIM de leur mobile), les estoniens sont en mesure depuis 2002 de certifier dans le monde numérique leur identité, et toute information personnelle qui s’y rattache (âge, sexe, domicile, etc.). Plus qu’une carte d’identité dématérialisée, cette identité numérique est pleinement intégrée à leur quotidien. Moyens de transport, transactions bancaires, déclarations fiscales, inscriptions à l’université, créations d’entreprise, etc. Elle permet même de voter aux élections nationales.

L’Estonie fait figure d’exception,  les niveaux d’adoption restant généralement faibles et les déploiements limités à des usages ciblés. L’Identité numérique existe malgré tout aujourd’hui dans plusieurs pays, et notamment en Europe. Qu’en est-il de la France ? Des initiatives sont-elles à y souligner ? La réponse est oui.

À suivre au 3^ème épisode…

Cet article Identité numérique : de nombreuses initiatives à travers le monde est apparu en premier sur RiskInsight.

Internet : à chaque usage son avatar

Des réseaux sociaux à votre banque en ligne, en passant par votre messagerie électronique, tous ces comptes, ou « avatars », vous représentent dans la sphère numérique. Mais le développement libre et tous azimuts d’internet pose d’évidents problèmes de confiance. Se pose notamment la question du lien entre une personne physique, ses avatars numériques, et le sujet de droit qui la représente dans le cadre juridique. L’ère numérique se caractérise par la constante augmentation de la dématérialisation des usages : achats, déclaration d’impôts, signature de contrats, etc. Autant d’activités qui nécessitent de fournir des informations d’identification fiables.

Cet article L’identité numérique, vecteur de confiance est apparu en premier sur RiskInsight.

La sécurité de l’information, un pré-requis sur les canaux numériques

La protection des données est aujourd’hui une préoccupation évidente des clients et usagers. C’est ce que révèle un sondage de l’Economist Intelligence Unit en 2013, dans lequel 90% des sondés affirment penser que leurs données utilisées en ligne peuvent être volées, notamment pour détourner de l’argent. C’est également une préoccupation des pouvoirs publics qui renforcent les obligations en termes de sécurité. Attirer les clients sur les canaux digitaux est  une nécessité pour beaucoup d’entreprises. La sécurité est un prérequis indispensable à cette transition.

D’une part, Il faut rassurer les clients, et pour cela démontrer de manière visible que des mesures de sécurité existent pour protéger les données critiques et éviter notamment les fraudes financières. Une création de compte, une transaction, un changement de RIB… une bonne sécurisation, organisationnelle ou technique, peut conforter les clients dans leur confiance dans le canal numérique.

D’autre part, en cas d’incident, la capacité à bien réagir,  tant  pour résoudre l’incident le plus rapidement possible, que pour communiquer clairement et rassurer les clients concernés est un élément clé. L’évolution de la réglementation autour de la notification des incidents poussera d’ailleurs les organisations à développer ce point.

Enfin, il est important de relayer cette position au travers des acteurs de la relation client sur le terrain (vendeurs, conseillers…) en les sensibilisant pour qu’ils portent également ces messages en magasins, agences, etc.

La sécurité de l’information, un facteur de différenciation et de compétitivité

Démontrer un réel engagement dans la sécurité de l’information peut être un élément différenciant sur le marché. Pour ce faire, des solutions de sécurité avancées peuvent être proposées. Des banques comme Société Générale ou HSBC, proposent ainsi un logiciel à installer gratuitement pour renforcer la sécurité du terminal de l’utilisateur lorsqu’il utilise leur site. D’autres, comme Natwest et Barclays mettent à disposition de leurs clients des moyens d’authentification renforcés.  Au-delà des solutions techniques, certains acteurs vont jusqu’à sensibiliser leurs clients et usagers sur l’importance du respect de bonnes pratiques de sécurité. AXA a ainsi publié le « Le guide du bon sens numérique » et encore Le Groupe La Poste a communiqué sur des bonnes pratiques à adopter sur les réseaux sociaux.

Les services marketing doivent donc travailler en collaboration avec les équipes de sécurité à la fois pour innover et proposer des solutions de sécurité, mais aussi pour écouter et savoir tenir compte des attentes des consommateurs.

La sécurité de l’information, une offre à part entière ?

Et si de centre de coûts, la sécurité devenait une source de gains ? En étant attentifs aux attentes des clients, différentes entreprises se sont posées cette question et lancent aujourd’hui des offres de sécurité en tant que telles..

Plusieurs secteurs se sont d’ores et déjà  lancés : celui de l’assurance par exemple. Cyber-assurance ou encore protection de l’identité numérique, des assurances comme AIG, AXA ou Swiss Life, ont entendu l’intérêt que portent leurs clients à la sécurité de l’information, B2B comme B2C. Autre exemple, les opérateurs télécoms qui proposent un anti-virus avec les abonnements d’accès à Internet. Ou encore, d’autres opérateurs, d’un tout autre secteur, celui des jeux en ligne, mettent à disposition de l’authentification renforcée pour leurs clients.

Ainsi, au-delà d’être un pré-requis  la sécurité de l’information peut devenir un avantage concurrentiel, voire représenter une offre à part entière. C’est à chaque organisation de choisir la posture qu’elle souhaite adopter !

Cet article La sécurité de l’information, au service de la relation client est apparu en premier sur RiskInsight.

Le certificat au coeur de la confiance numérique

Au centre de la confiance numérique repose le fameux « certificat ». Cette carte d’identité numérique, délivrée par les infrastructures de gestions de clés (IGC ou encore PKI),  permet de garantir qu’une personne, un équipement ou un service est bien celui qu’il prétend être dans le monde numérique.  Ce certificat est stocké sur des supports variés, pouvant être physiques (carte à puce, clé USB, badge) ou logiques (fichier). Il a le rôle d’une carte d’identité présentée lors de l’accès à des services ou à des informations pour prouver son identité.

Structurer une offre de services sous 3 axes

Pour tirer le meilleur parti des investissements réalisés, nos retours d’expérience montrent que l’entreprise doit s’attacher à construire son catalogue de service de confiance numérique en trois volets.  Premier volet, la fourniture simple de certificats. Les utilisateurs finaux pourront alors utiliser ces certificats dans leurs propres systèmes ou pour leurs projets techniques. C’est par exemple le cas de projets d’applications web métiers, d’authentification réseaux (802.1x)… Deuxième volet, la fourniture de services de confiance destinés à l’utilisateur et intégrant des certificats. Il s’agit par exemple de projets badges uniques (bâtiment, restauration, système d’information…), de chiffrement de messagerie ou de poste de travail. Le certificat est alors intégré de manière transparente dans les services fournis. Troisième et dernier volet, la fourniture de services « métiers » intégrant la confiance numérique. La dématérialisation des processus (bulletins de paye, facturation), les coffres forts numériques ou le stockage à valeur probante sont des exemples parlants.

Les 3 règles d’or de la construction

Mais au-delà de cette catégorisation, quels sont les éléments clés de la constitution de ces services ?

Règle n°1 : identifier les premiers « quick wins »

Le premier défi rencontré est celui de l’identification initiale et de l’extension du périmètre des services. L’implication des acteurs sécurité permet de recenser les besoins et préciser les volumétries, selon différentes typologies d’utilisateurs. L’identification de « quick wins » permet de cibler les premiers investissements à travers la valeur ajoutée des services qu’ils offriront. A cet égard, on peut envisager de ne retenir d’abord qu’un nombre limité de fonctionnalités de sécurité, au profit de fonctionnalités dites « de confort ». On pourra ainsi, dans un premier temps, coupler accès distant au SI (VPN) et messagerie sécurisée (signature et chiffrement de mails) et dans un second temps, une fois les identités numériques largement déployées, s’atteler à la greffe de services de sécurité éventuellement plus poussés : chiffrement de données, signature de documents, signature de code.

Règle n°2 : privilégier l’ergonomie et la facilité d’usage

En outre, l’ergonomie des outils doit rester au cœur des préoccupations : simplicité d’emploi, transparence de l’intégration au poste de travail, mais également gestion des accès de secours. Car si l’implémentation de ces derniers constitue souvent une atteinte au niveau de sécurité des outils, force est d’avouer qu’une offre rendant l’oubli du support cryptographique (carte à puce, clé USB.) bloquant pour l’utilisateur, compromettra l’acceptabilité de la solution toute entière, notamment auprès des utilisateurs les plus exigeants. lesquels sont aussi souvent les plus influents. C’est pourquoi  une étude précise des besoins des métiers permettra d’identifier le meilleur compromis entre niveau de sécurité et types d’accès de secours exigés par les utilisateurs. Notons également l’importance du dispositif utilisé, clé du succès de l’offre : un projet de badge unique, offrant par exemple, l’accès aux bâtiments, le paiement à la cantine et la sécurisation de la messagerie, comprend de vraies complexités organisationnelles mais apporte une valeur ajoutée considérable

Règle n°3 : le RSSI, sponsor de choix

Last but not least, notons que le RSSI doit, autant que possible, servir d’appui moteur au déploiement des services, que ce soit de façon directe, par exemple par le biais d’une participation au financement du projet abaissant ainsi le coût utilisateur, ou de façon indirecte, via la promulgation de règles de sécurité imposant in fine l’utilisation des services de confiance. Ce sponsoring est d’autant plus crucial que la plupart du temps, l’appétence des utilisateurs finaux pour les services de confiance numérique est relativement modeste et ne suffit pas à donner un élan au projet

La confiance a de l’avenir

Le monde a commencé sans l’homme et s’achèvera sans lui », nota le crépusculaire Levi-Strauss. « L’homme a commencé sans l’informatique et s’achèvera sans elle », pourrons-nous dire de façon analogue. Nous avons montré plus haut que, si la confiance est d’ores et déjà au coeœur de beaucoup de services offerts par les DSI, cela n’occulte en rien le fait que cette notion dépasse largement l’IT. Les technologies changent mais les principes et processus perdurent, aussi le périmètre des services de confiance s’étend-il inéluctablement aux usages métiers les plus divers, à travers la dématérialisation notamment. Le chemin est, nous l’avons vu, semé d’embûches, mais pour l’offreur avisé, c’est donc un succès assuré. Ad augusta per angusta ! (*) »

(*) « Vers la gloire, par des chemins étroits » (Victor Hugo, Hernani)

Cet article Services de confiance numérique : pour que le contrat de confiance règne ! est apparu en premier sur RiskInsight.

Forts de premiers projets réussis, les années 2010 marquent une rupture en la matière, puisque l’on voit alors se développer rapidement l’utilisation conjuguée de la dématérialisation et de la signature électronique à destination du grand public. Cela s’explique par  trois facteurs.

Un cadre réglementaire aujourd’hui maîtrisé

En 2001, la législation française institutionnalisait la signature électronique  par les articles 1316-1 et 1316-4 du code civil et le décret n°2001-272 du 30 mars 2001. Elle rendait alors la signature électronique équivalente à la signature papier, sous condition du respect des principes d’identification fiable du signataire et d’intégrité des données. Pourtant, la frilosité l’emportait, faute de retours d’expérience suffisants dans l’application de ce cadre juridique.

Il faudra attendre 10 ans pour voir se déployer plus largement la signature électronique. Quelques jurisprudences, bien qu’encore peu nombreuses, confortent les entreprises : celle de décembre 2010, par exemple, concernant  la reconnaissance juridique de la notification électronique d’une demande de résiliation (exemple d’un abonnement téléphonique) portant une signature électronique (http://www.resilier.com).

Des premiers succès rassurants dans le B2B et les administrations

Ces dernières années, des projets plutôt B2B ont vu le jour. Les grandes entreprises ont mis en œuvre des solutions de dématérialisation et de signature électronique pour des usages professionnels (ex : signature de remises réglementaires pour les établissements financiers, signature d’ordres de paiement pour les trésoriers d’entreprise, signature de contrats entre professionnels). Ces solutions s’appuient sur l’utilisation de certificats électroniques, preuve de l’identité numérique personnelle de son porteur, indispensable à la signature électronique.

Déjà éprouvées par les entreprises, ces solutions sont désormais matures et peuvent être réutilisées pour de nouveaux usages destinés au grand public.Le grand public est prêt et demandeur !

Le grand public est aujourd’hui habitué et enclin à l’achat de biens et de services sur internet, ainsi qu’à l’utilisation de processus administratifs dématérialisés en ligne (Mon Service Public, déclaration des impôts, consultation de données personnelles de santé, facturation électronique des fournisseurs d’énergie et d’internet…).

De plus, conscients des risques de fraude et d’usurpation d’identité, le grand public est dès lors sensibilisé à l’utilisation de moyens de sécurité lors de transactions en ligne, tels que l’envoi de code par SMS, l’utilisation de carte bancaire virtuelle, de clavier numérique, de certificat électronique, etc.

Enfin, le grand public montre une appétence de plus en plus forte pour l’obtention de biens et de services rapidement, voire même de façon immédiate.

Les banques françaises (BNP Paribas, LCL…) participent fortement à cet essor ; elles offrent, depuis plusieurs années déjà, la gestion en ligne des comptes bancaires (suivi de comptes, opérations de virement…) ; et plus récemment, elles proposent la souscription en ligne à des services bancaires (ex : livret d’épargne, prêt à la consommation, assurance) à leurs clients particuliers, grâce à la signature électronique mise en œuvre par l’utilisation de certificats électroniques personnels. Cette  offre répond pleinement aux attentes du grand public.

Comment lever les derniers freins ?

Il reste aujourd’hui un frein majeur au développement de la signature électronique en France : la distribution et la gestion des  parcs de certificats pour le grand public.

Des opérateurs de téléphonie mobile (SFR en France, Turkcell en Turquie) ont ainsi créé des partenariats avec des fournisseurs de puces SIM cryptographiques (Oberthur, Gemalto), afin de fournir à leurs abonnés des mobiles embarquant une solution de signature.

Ces offres, reposant sur une collaboration entre opérateurs mobiles et banques, permettent aux abonnés d’accéder à des services sécurisés en ligne grâce à leur mobile, tel que l’achat en ligne et la banque en ligne, sans aucune transmission d’informations bancaires.

Par ailleurs, le gouvernement français renouvelle sa volonté de développer l’usage du numérique avec la préparation d’un nouveau plan France Numérique 2020, qui sera dévoilé d’ici 2012, avec la perspective d’y voir s’inscrire des projets concrets de confiance numérique.

Ces innovations et projets dans la confiance numérique permettront certainement de lever les derniers freins quant à la distribution et la reconnaissance des certificats électroniques.  En effet, c’est grâce à la demande du grand public et l’implication des grands acteurs du B2C et de l’administration (G2C) que la signature électronique pourra décoller !

Cet article Dématérialisation et signature électronique : vers l’explosion des usages grand public ? est apparu en premier sur RiskInsight.

La difficulté de la prédictibilité des coûts dans le cloud

Le modèle du cloud nécessite une attention forte pour ne pas perdre au bout de quelques temps les gains économiques escomptés, voire éviter une réelle dérive des coûts. Dans le cloud, comme au sein du SI historique, une gestion fiable des identités est ainsi essentielle pour garantir durablement la maîtrise du nombre d’accédants à ces services.

Bien évidemment, elle vise également à renforcer la protection de l’accès aux informations qui y sont stockées. Elle y est même encore plus indispensable, vu l’absence de garde-fous traditionnellement rencontrés, comme par exemple la « porte d’entrée » Active Directory ou le contrôle d’accès physique.

Gérer les identités dans le cloud : quelles stratégies gagnantes ?

Comment le faire concrètement ? Plusieurs solutions sont envisageables :

–       Gestion manuelle sur le site du service cloud par les équipes de l’entreprise. C’est certes efficace pour lancer rapidement des initiatives cloud, mais il faut prévoir de rencontrer, tout aussi rapidement, toutes les limites bien connues de la gestion manuelle : écart, difficultés de maintien, complexité des revues…

–       Gestion automatisée via un service de provisioning/deprovisioning avec des contrôles a priori (validations) et/ou a posteriori (contrôles et recertifications) : l’accès aux services cloud piloté par les processus et les outils IAM de l’entreprise. Mêmes solutions que dans le SI historique… et mêmes vigilances et bonnes pratiques pour éviter toute désillusion !

–       Gestion automatisée via un service de fédération d’identités : certainement aujourd’hui la solution à privilégier quand cela est possible, puisqu’elle apporte des réponses satisfaisantes aussi bien sur les problématiques de gestion au quotidien qu’en termes d’expérience utilisateur. Après des années de balbutiements où les entreprises n’allaient quasiment jamais plus loin qu’un prototype, les derniers dix-huit mois marquent le réel envol de la fédération avec des réalisations significatives.

–       Gestion automatisée et fédérée par un tiers de confiance, jouant le rôle d’intermédiaire entre l’entreprise et les différents offreurs de services cloud. Des acteurs commencent à se positionner sur ce sujet, mais la classique question de la confiance se pose !

Le cloud : un booster pour les projets IAM

Sujets à traiter, bon sens et bonnes pratiques, priorisation et angles d’attaque, risques et écueils à éviter : la gestion des identités dans le cloud doit relever les mêmes challenges que dans le SI historique.

Et si le cloud était un levier formidable pour d’une part simplifier et fiabiliser les processus et outillages IAM actuels, et d’autre part faire décoller l’usage de nouveaux services IAM de type reporting et recertification ?

Cet article Cloud computing : maîtriser ses coûts grâce à une bonne gestion des identités est apparu en premier sur RiskInsight.