Quand une intégration ouvre plus d’une porte

Les systèmes modernes fonctionnent rarement de manière isolée. Une plateforme peut être connectée à une messagerie, une base de données, un système de gestion documentaire, un service cloud ou une application externe.

Ces intégrations permettent d’éliminer de nombreux processus manuels et aux systèmes de fonctionner comme un écosystème unifié. Mais chaque connexion crée également une relation de confiance : le Système A obtient le droit d’effectuer certaines actions au sein du Système B.

Cela change la manière dont la sécurité doit être envisagée. Il ne suffit pas de se demander si chaque système est sécurisé individuellement. Il faut également comprendre jusqu’où un système peut aller à travers les connexions qu’il entretient avec les autres.

Une intégration ne sert pas uniquement à transférer des données

Prenons l’exemple d’une plateforme connectée à un système de gestion documentaire.

L’intégration peut être autorisée à consulter des documents, à en créer de nouveaux ou à modifier des informations existantes. Une autre intégration peut communiquer avec la messagerie, tandis qu’une autre encore peut être connectée à une base de données ou à une plateforme financière.

Dans chacun de ces cas, la connexion représente bien plus qu’un simple canal de communication. Elle implique également un certain niveau d’accès.

Une question importante se pose alors lors de la conception du système : si l’un de ses composants est compromis, jusqu’où un attaquant pourrait-il aller en utilisant les accès que le système lui a légitimement accordés ?

Il ne s’agit pas uniquement d’un scénario théorique. Microsoft explique que les applications cloud peuvent utiliser des connecteurs qui conservent des autorisations donnant accès à la messagerie, aux applications SaaS, aux bases de données et à d’autres services. Si un attaquant prend le contrôle de la ressource qui gère un connecteur, il peut potentiellement utiliser cet accès pour atteindre le service connecté, sans nécessairement avoir à extraire les identifiants d’origine.

Un système de confiance peut devenir une voie d’accès vers un autre système

Cette situation soulève un enjeu particulier.

Le Système B peut être correctement configuré. Les identifiants des utilisateurs peuvent être protégés. L’authentification peut fonctionner exactement comme prévu.

Pourtant, si le Système A dispose déjà d’une connexion autorisée avec lui, la compromission du Système A peut modifier toute l’équation de sécurité.

Dans le domaine de la sécurité cloud, ce phénomène est lié au concept de lateral movement : un point d’entrée est utilisé pour atteindre d’autres ressources connectées. Microsoft souligne que les chemins d’attaque dans les applications cloud peuvent s’étendre du code applicatif aux identités, aux connecteurs, aux bases de données et à d’autres services cloud.

L’architecture de sécurité doit donc prendre en compte non seulement les différents composants, mais également les chemins qui se créent entre eux.

Le problème n’est pas l’intégration. C’est l’étendue de l’accès qu’elle permet

Une intégration a besoin de privilèges pour fonctionner. Mais rien ne justifie qu’elle dispose de droits plus étendus que ceux nécessaires à sa fonction.

Si un processus doit uniquement consulter une catégorie spécifique de documents, lui donner accès à l’ensemble du référentiel augmente inutilement la surface d’exposition. Si un service doit uniquement transmettre des informations, lui permettre de les modifier ou de les supprimer introduit des privilèges dont le processus n’a pas besoin.

C’est ici que le principe du least privilege devient une composante à part entière de la conception de l’intégration : chaque connexion ne reçoit que les autorisations nécessaires à l’exécution de sa fonction.

Ce contrôle devient de plus en plus important à mesure que les écosystèmes logiciels se connectent à davantage d’applications et de services. Microsoft propose, par exemple, une cartographie des chemins d’attaque pour les applications OAuth afin d’identifier comment une application connectée peut créer des voies d’accès vers des services et des données sensibles.

Les connexions doivent être conçues avec le même soin que les systèmes eux-mêmes

Lors de la conception d’une plateforme intégrée, les questions de sécurité doivent aller au-delà de la simple interrogation : « À quel système nous connectons-nous ? »

De quelles autorisations cette connexion dispose-t-elle ? Quelles données peut-elle consulter ? Que peut-elle modifier ? La même autorisation peut-elle être utilisée par un autre composant ? Que se passe-t-il lorsque l’intégration n’est plus nécessaire ? Et surtout, quel autre système peut être atteint à travers elle ?

Ces questions permettent d’éviter qu’une intégration ne devienne involontairement une passerelle vers d’autres parties de l’écosystème.

Des incidents réels survenus ces dernières années ont précisément mis en évidence ce phénomène. Microsoft a documenté des cas dans lesquels des jetons OAuth et des intégrations SaaS de confiance ont été utilisés pour maintenir un accès à des systèmes CRM et, dans certains cas, étendre cet accès à d’autres plateformes connectées.

La sécurité d’un écosystème dépend aussi des connexions qui le composent

Chez Soft & Solution Group, l’intégration n’est pas considérée comme un simple échange de données entre deux applications. La manière dont les systèmes s’authentifient, les privilèges qui leur sont accordés et la portée de chaque connexion font partie intégrante de l’architecture d’intégration.

Comme l’explique Ermal Beqiri, fondateur de Soft & Solution Group :

« Lorsque nous connectons deux systèmes, nous ne créons pas simplement un chemin pour les données. Nous créons également une relation de confiance. L’architecture doit définir clairement jusqu’où s’étend cette confiance et ce que chaque connexion est autorisée à faire. »

Plus les systèmes collaborent entre eux, plus les connexions qui les relient deviennent elles-mêmes une partie de la surface à protéger.

Car une intégration bien conçue ne détermine pas seulement comment une porte s’ouvre, mais aussi jusqu’où il est possible d’aller une fois cette porte ouverte.