[Tribune] Sur site et dans le Cloud : le défi des identités hybrides

La migration massive des applications jadis hébergées sur site vers le Cloud (qu’il s’agisse d’un Cloud d’infrastructure ou simplement d’applications en mode SaaS) vient jeter un éclairage cru sur les pratiques de gestion des identités au sein des entreprises, en particulier pour les comptes à privilège. Car avec un système d’information hybride, l’entreprise se retrouve rapidement à devoir gérer des silos : des droits similaires sur des périmètres différents. Car en dehors de ce qui peut être lié à un AD dans Microsoft Azure, la synchronisation des deux univers ne se fait que rarement, ou de manière imparfaite. Hicham Bouali, directeur Avant-Ventes EMEA de One Identity, nous livre son analyse.

[caption id="attachment_93874" align="alignleft" width="300"]

Hicham Bouali, directeur Avant-Ventes EMEA de One Identity[/caption]

Les risques, pourtant, sont bien connus : dans l’attaque Solarwinds, par exemple, les pirates ont ciblé spécifiquement les éléments d’authentification internes (la génération de jetons SAML) afin de bénéficier d’un accès administrateur aux services hébergés dans le Cloud.

A lire aussi : [Alliancy Inspiration] DSI : Quelles stratégie et organisation pour se lancer seul (ou non) dans le cloud en 2021 ?

Ils ont exploité ainsi le lien entre les droits d’administration du système d’information on-premises et les comptes privilégiés dans le Cloud. Et ces liens sont, trop souvent, uniquement fonctionnels, échappant à une gouvernance globale.

Dans le cas particulier de Solarwinds, une compromission locale permet de créer des comptes « plus vrais que nature », qui seront acceptés sans sourciller dans le Cloud – et quel que soit le fournisseur, puisqu’il s’agira bien souvent de jetons SAML standardisés signés par leur propre certificat de confiance.

Et c’est bien parce qu’il est difficile d’unifier la gouvernance des identités entre le on-premises et le Cloud que l’entreprise aura du mal à réaliser, par exemple, que de nouveaux comptes à privilèges sont apparus ou sont utilisés de manière non standard.

Il est donc vital, pour les défenseurs, de pouvoir s’appuyer sur une visibilité unifiée des identités et des droits, quel que soit l’environnement où ils sont utilisés – en ligne ou localement.

Gouvernance & provisionning : faire et savoir !

Il est en particulier essentiel d’être capable de déterminer quels sont les comptes et les droits associés, savoir d’où ils viennent et qui les a attribués. Un compte (surtout s’il est privilégié) ne devrait pas bénéficier de droits forts sans qu’il ne soit possible d’y associer une trace d’audit permettant de connaître leur origine (qui a validé l’attribution de ces droits ? Pourquoi ? Quand, et pour combien de temps ?). Être en mesure de réconcilier la vision technique et organisationnelle, à travers les environnements locaux et Cloud, permettra d’identifier rapidement les anomalies telles que la création de comptes ou l’attribution illégitime de droits.

Cette capacité de gouvernance a son pendant dans le domaine technique : la capacité de provisionning des comptes : garantir que leur création (et l’attribution des privilèges qui vont avec) se fasse en respectant la politique de l’entreprise, aussi bien localement que dans le Cloud. Et là, toute la difficulté réside dans la capacité d’associer ce qui est possible de faire localement avec les capacités du Cloud choisi…)

Puis contrôler…

Décider, c’est bien, mais encore faut-il être en mesure de contrôler l’application des règles, en particulier pour les comptes à privilèges (majoritairement ciblés par les attaquants). Or, en la matière, il n’est pas rare que les DSI soient aveugles, ou presque. Hormis les journaux par défaut, il leur est parfois difficile de savoir exactement comment a été utilisé tel ou tel compte à privilège (et encore, ça, c’est quand les bons événements Windows sont journalisés localement et le bon niveau de licence est souscrit dans le Cloud…).

Il est pourtant vital de déterminer si l’usage d’un compte à privilège est conforme aux règles établies. Certaines choses peuvent être automatisées (faire tourner les mots de passe, par exemple, pour s’assurer que la politique de l’entreprise soit respectée de manière uniforme), mais d’autres doivent être anticipées. C’est le cas, par exemple, de l’enregistrement de sessions. La capacité à rejouer ce qui a été fait par un compte d’administration peut s’avérer vitale dans le cas d’une réponse à incident, et pour garantir le respect des bonnes pratiques d’administration, par exemple.

La mise en œuvre

La mise en œuvre d’une telle approche se heurte cependant à des difficultés d’interconnexion : gérer des droits et des identités de manière industrialisée en local comme dans le Cloud exige d’être capable de collecter l’information partout où elle se trouve : sur les systèmes locaux (l’écosystème Windows est relativement accessible, mais les mainframes sont plus difficiles à intégrer, par exemple), comme dans le Cloud (où les niveaux de droits et les informations exposées par les API varient selon les fournisseurs).

L’intégration des différentes sources d’information est ainsi un aspect crucial du projet, et il est généralement plus efficace de déléguer cet aspect à une solution en mode SaaS (public ou privé, voire en mode hybride). Cela évitera d’avoir à administrer et entretenir tout un nouvel écosystème de connecteurs, de moteurs d’analyse de règles et les systèmes dédiés. L’important, finalement, c’est avant tout l’intelligence derrière les règles, et la garantie d’accéder aux bonnes alertes au bon moment !

Enfin, la brique de reporting est un incontournable d’un tel projet. Le temps passé par les équipes de la DSI à compiler des rapports de conformité (PCI-DSS, Bâle 2, RGPD…) sera finalement mieux utilisé à affiner, justement, les règles et les politiques d’audit de l’utilisation des comptes, tandis que les rapports seront générés automatiquement.