Dans ce deuxième article, nous analyserons des scénarios d’attaque pratiques qui menacent le Control Plane, et fournirons des recommandations concrètes pour atténuer ces risques. Plus précisément, nous explorerons trois scénarios d’attaque courants qui menacent significativement le Control Plane : la compromission du support IT, du poste de travail de l’administrateur du Control Plane et du CI/CD. En comprenant ces vecteurs d’attaque et en mettant en œuvre des mesures de sécurité robustes, il est possible d’améliorer considérablement la résilience de son environnement cloud contre les compromissions potentielles. 

La compromission du support IT  

Prenons un scénario où le compte d’un membre du support IT est compromis. Cela peut découler d’une attaque par hameçonnage, d’une opération d’ingénierie sociale ou même d’une tentative d’usurpation d’identité. Ces comptes peuvent souvent réinitialiser des mots de passe, y compris ceux des utilisateurs ayant des privilèges très élevés, tels que l’administrateur d’application ou le Owner Azure au niveau root, obtenant ainsi un accès non autorisé à des ressources critiques, allant de l’Entra ID au cloud, en passant par les environnements sur site et les services SaaS. 

Ce type d’attaque illustre un point crucial que nous avons abordé dans le premier article : la nécessité de délimiter et d’isoler efficacement le Control Plane. Le service d’assistance, bien qu’essentiel pour les opérations quotidiennes, doit être rigoureusement séparé des fonctions administratives à haut privilège. L’absence d’une telle séparation peut permettre à un attaquant de passer d’un compte de service d’assistance compromis à un rôle d’administrateur global. 

Pour réduire ce risque, les organisations doivent mettre en œuvre une série de défenses stratégiques :  

• Dans un premier temps, isoler les comptes du Control Plane de ceux gérés par le support IT est essentiel. De cette façon, même si un compte du service d’assistance est compromis, il ne pourra pas accéder ou manipuler des comptes à haut privilège. Ainsi, la compromission d’un compte de service d’assistance ne permettrait pas d’accéder à des comptes à privilèges élevés ou de les manipuler. 
• Dans un second temps, utiliser exclusivement des comptes cloud dédiés aux tâches du Control Plane réduit la probabilité d’exploitation des systèmes hérités comme point d’entrée.  
• Finalement, associer ces comptes à une authentification multi-facteurs (MFA) résistante au phishing, à une administration Just-In-Time (JIT), à une gouvernance d’identité robuste et à des politiques d’accès conditionnel, ainsi qu’à une conformité stricte des postes de travail, crée une défense en couches qui diminue considérablement le risque d’une telle attaque. 

Ce scénario souligne l’importance de considérer chaque compte comme un vecteur de menace potentiel. Mettre en place une isolation stricte et des contrôles rigoureux permet de garantir la sécurité de votre Control Plane en cas de compromission d’un compte de niveau inférieur. 

Compromission d’un poste administrateur du Control Plane  

Considérons maintenant une situation où un attaquant parvient à compromettre le compte administrateur de l’Intune Mobile Device Manager (MDM). Avec cet accès, l’attaquant obtient le contrôle du portail d’administration d’Intune, lui permettant de manipuler le poste de travail d’un administrateur du Control Plane. Il peut déployer des configurations malveillantes, installer des portes dérobées ou se connecter directement à l’ordinateur de l’administrateur (Remote help. Cet accès transforme le poste de l’administrateur en un outil puissant pour une exploitation ultérieure, offrant à l’attaquant la capacité d’exécuter des commandes, d’exfiltrer des données sensibles et de manipuler des ressources cloud sans recourir à des techniques de piratage supplémentaires. 

Ce scénario nous rappelle un principe clé du premier article : la sécurité du cloud doit être abordée de manière holistique. Il ne s’agit pas seulement de sécuriser les identités, mais aussi de garantir que les appareils utilisés pour accéder au Control Plane sont sécurisés. Dans ce cas, le poste de l’administrateur du Control Plane devient un atout critique qui, s’il est compromis, pourrait compromettre les défenses cloud les plus sophistiquées. 

Compromission du CI/CD 

Les environnements Cloud reposant fortement sur l’automatisation, les pipelines CI/CD pour la gestion de l’infrastructure deviennent des cibles privilégiées pour les attaquants. Imaginons un scénario où un attaquant parvient à accéder au compte d’un ingénieur DevOps par le biais d’une attaque de phishing ou d’un vol d’identifiants. Avec cet accès, il introduit un changement malveillant d’Infrastructure as Code (IaC) dans un dépôt Git, sachant que cela déclenchera un pipeline Azure automatisé. Le pipeline valide, planifie et déploie l’infrastructure sur Azure, entraînant la destruction ou l’altération de ressources clés d’Azure, c’est-à-dire les fondations de la Landing Zone. De plus, l’attaquant modifie la configuration YAML du pipeline Azure. Ce faisant, il provoque la fuite d’un secret Service Principal dans les journaux ou la console de débogage, qui est ensuite utilisé pour effectuer des appels non autorisés à l’API Graph. En exploitant cette identité sur-privilégiée, l’attaquant peut escalader ses privilèges, compromettant ainsi les identités Entra ID ou les comptes Office 365. 

Les runners jouent également un rôle crucial dans le pipeline CI/CD. Ces agents sont responsables de l’exécution des tâches dans le pipeline et peuvent être hébergés et maintenus par le fournisseur cloud ou sur site. Comme pour tout serveur, leur compromission peut être utilisée comme point de pivot pour rebondir vers la Landing Zone (par exemple : vol de token) ou d’autres services associés. 

Ce scénario illustre l’interconnexion de la sécurité du cloud. Le pipeline CI/CD, souvent perçu comme une fonction de back-office, est en réalité profondément intégré au Control Plane. Sa compromission peut entraîner des conséquences dévastatrices et généralisées pour les fondations mêmes de vos opérations cloud. 

Pour se protéger contre une telle menace, il est crucial d’isoler le pipeline du Control Plane, dont le but est de construire la Landing Zone, des pipelines de projet. Ensuite, il convient d’appliquer le principe du moindre privilège, en veillant à ce que les comptes et les runners au sein du pipeline n’aient que les permissions nécessaires pour accomplir leurs tâches. Par exemple, pour limiter les permissions des runners, nous pouvons utiliser l’identité fédérée et demander des token OpenID Connect (OIDC), qui fournissent un accès limité et temporaire aux services cloud comme Azure. De plus, l’adoption de pratiques de sécurité automatisées telles que Configuration as Code (CaC) ou Policy as Code (PaC) peut aider à réduire les erreurs humaines et à garantir une sécurité cohérente dans vos déploiements. 

En matière de sécurité cloud, chaque processus et chaque outil doit être considéré sous l’angle du risque. Le pipeline CI/CD ne fait pas exception. En sécurisant ce composant critique, vous protégez non seulement votre Control Plane, mais vous assurez également la stabilité et la sécurité de l’ensemble de votre infrastructure cloud. Cette approche holistique de la sécurité du cloud est ce qui permettra finalement à vos opérations de fonctionner correctement, même face à des attaques sophistiquées. 

Synthèse

Dans cet article, nous avons examiné trois scénarios d’attaque qui menacent la sécurité du Control Plane dans les environnements cloud : la compromission du support IT, la compromission du poste de travail de l’administrateur du Control Plane et la compromission du pipeline CI/CD. 

Chacun de ces scénarios met en évidence l’importance d’une approche de sécurité à plusieurs niveaux, incluant des mesures techniques et organisationnelles. Nous proposons une stratégie en quatre étapes pour concevoir votre Control Plane et le sécuriser contre les attaques potentielles : 

• Étape 1 : Définir ce qui est systémique pour votre infrastructure : identifier les composants et comptes critiques au sein de votre Control Plane qui, s’ils sont compromis, pourraient entraîner une perturbation globale. 
• Étape 2 : Evaluer votre risque actuel avec un audit de sécurité : réaliser des audits de sécurité réguliers pour évaluer l’état actuel de la sécurité de votre Control Plane. Cela vous aidera à identifier les vulnérabilités et à prioriser les efforts de remédiation. 
• Étape 3 : Définir une feuille de route pour isoler et sécuriser les actifs les plus à risque : sur la base des résultats de votre audit, élaborer une feuille de route claire pour sécuriser les actifs les plus critiques. Cela devrait inclure des échéanciers, l’allocation des ressources et des actions spécifiques pour atténuer les risques identifiés. 
• Étape 4 : Se préparer aux scénarios de suppression du cloud : envisager les pires scénarios où des sections entières de votre infrastructure cloud pourraient être compromises ou désactivées. Élaborer des plans de contingence et s’assurer que les processus de sauvegarde et de reprise après sinistre sont en place. 

En suivant ces recommandations, vous pouvez construire une défense robuste contre les menaces potentielles à votre Control Plane, garantissant que votre environnement cloud reste sécurisé et résilient. 

Merci à Louis CLAVERO pour sa contribution à cet article.

Cet article Enterprise Access Model (2/2) : Quelles solutions pour sécuriser un Control Plane ?  est apparu en premier sur RiskInsight.

Aujourd’hui, la plupart des entreprises utilisent le Cloud public pour héberger de nombreuses applications, répondant à tout type de besoin allant du commercial au fonctionnel. Bien que cela apporte des avantages, le Cloud introduit également de nouveaux paradigmes, qui doivent être clairement compris afin d’être sécurisés. 

Historiquement, les entreprises s’appuient sur un modèle à 3 tiers pour sécuriser les environnements Active Directory. Ce modèle segmente le réseau en trois niveaux distincts : le tiers 0 pour les systèmes et les données les plus sensibles, le tiers 1 pour l’administration des serveurs et le tiers 2 pour les postes de travail et les terminaux utilisateurs. Bien que ce modèle se soit avéré efficace dans les environnements on-premise, le passage à des infrastructures basées sur le Cloud nécessite une réévaluation de son applicabilité. 

Ce premier article se concentre sur une tendance récente et inquiétante : la compromission globale d’Entra ID, résultant de la compromission d’un compte du support. Une telle attaque peut avoir de graves répercussions, aux impacts finalement plus larges qu’une compromission d’un administrateur de domaine AD. Nous explorerons les mécanismes à l’origine de ces attaques, leurs implications et, surtout comment nous devrions nous protéger contre ce type d’élévation de privilèges et mettre en œuvre un modèle d’administration adapté au Cloud et sécurisé. 

Comprendre Entra ID, Active Directory, et les permissions Azure  

Comme le montre la figure 1, l’Active Directory et Entra ID (anciennement Azure Active Directory) sont deux services d’identité avec des propriétés structurelles et des protocoles IAM différents. Alors qu’Entra ID se concentre sur la gestion des identités et des accès dans les environnements Cloud et on-premise, en fournissant l’authentification et la gestion des utilisateurs, les permissions Azure s’attèlent à la gestion plus large de l’infrastructure et des services Cloud. Comprendre les distinctions et les interconnexions entre ces outils est essentiel pour maintenir une sécurité robuste et un contrôle d’accès efficace dans les environnements actuels d’entreprise. 

Figure 1: Différences clés entre Active Directory et Entra ID. 

Entre Active Directory, Entra ID et Azure, chacun gère son propre modèle de permissions : 

• Active Directory utilise un modèle de permission unifié pour tous ses objets, des utilisateurs aux machines. 
• Entra ID utilise le contrôle d’accès basé sur des rôles (RBAC : Role-Based Access Control) pour gérer les objets de son tenant (par exemple : les utilisateurs, les appareils, les applications). 
• Azure Resource Manager (RM) utilise le RBAC pour gérer les ressources Azure 

Cependant, il existe un pont entre Entra ID et Azure RM grâce à la relation unique entre un tenant Entra ID et une organisation Azure : l’utilisateur Global Administrator d’Entra ID se voit attribuer par défaut le rôle User Access Administrator dans Azure. Par conséquent, il peut dès lors s’attribuer n’importe quelle permission sur le scope Azure.  

Bien qu’il existe un lien entre Azure et Entra ID, il est important de garder à l’esprit que les rôles dans Entra ID et Azure RM peuvent être attribués indépendamment l’un de l’autre. Par exemple, un utilisateur Entra ID standard avec des autorisations très limitées sur Entra ID peut détenir les privilèges les plus élevés dans Azure, ce qui constitue un point critique de vulnérabilité exploité dans les attaques. 

L’élévation de privilèges dans Entra ID peut entraîner une compromission importante d’Azure (y compris toutes les ressources et infrastructures), de Microsoft 365, des postes de travail, des serveurs Windows, des réseaux cloud, etc. 

Les rôles à plus haut privilège dans chacun de ces services sont : 

• Entra ID: Global Administrator 
• Azure RM: Owner (qui peut être restreint à un périmètre allant d’un Management Group jusqu’à une ressource) 

Ces différences significatives signifient que les concepts du modèle 3-tiers traditionnel de l’AD ne peuvent pas être appliqués directement aux environnements cloud. Nous devons repenser et adapter ces concepts pour nous assurer qu’ils sont pertinents et efficaces dans les contextes Clouds, notamment en répondant adéquatement aux exigences et aux risques spécifiques associés à ces environnements. 

Une compromission globale d’Entra ID bien réelle 

Pour se concentrer sur la compromission et l’élévation de privilèges de l’administration Cloud, quelques hypothèses initiales sont prises : 

• L’entreprise victime utilise un tenant Entra ID comme fournisseur d’identité (Identity Provider = IdP). 
• L’entreprise victime utilise Microsoft Intune pour gérer toute sa flotte de postes de travail. 
• L’entreprise victime a un abonnement Azure (Azure subscription) pour supporter ses activités liées aux VDI (Virtual Desktop Infrastructures). 
• Un compte du support a été compromis (on ne précise pas la source de l’attaque, mais il est important de noter qu’il s’agit d’un scenario très plausible pouvant être le résultat d’un hameçonnage, d’ingénierie sociale, ou encore d’une compromission du poste de travail, etc.) 

1 Compromission du compte du support 

• A la suite de nos hypothèses, nous supposons donc que l’attaquant a pris le contrôle d’un compte du support, ayant la permission de réinitialiser des mots de passe utilisateurs ainsi que des MFA (Multi-Factor Authentication)  

 2 Première tentative: Réinitialisation du mot de passe du compte Global Administrator 

• L’attaquant tente initialement de réinitialiser le compte Global Administrator, en cherchant le chemin le plus rapide pour devenir Global Administrator d’Entra ID.  

• Cette action est bloquée par défaut par Microsoft. Le rôle Global Administrator est un privileged role, et seuls d’autres privileged roles spécifiques sont autorisés à réinitialiser son mot de passe ou à modifier ses attributs. Microsoft met à jour ici sa liste de privileged roles natifs à Entra ID. 

 3 Seconde tentative: Compromission d’un compte standard Entra ID 

• L’attaquant étant restreint à la réinitialisation de mot de passe pour un utilisateur standard (non privileged), il identifie ensuite un utilisateur appelé « VDI Admin”, qui se trouve être Owner d’un abonnement Azure, utilisé pour héberger des services d’administration de postes de travail. 
• Malgré la double authentification activée, l’attaquant parvient à réinitialiser à la fois le mot de passe et le mécanisme de MFA, gagnant accès à ce compte. 

4 Recherche de l’abonnement Azure 

• Grâce à la compromission du compte « VDI Admin », l’attaquant se connecte en utilisant le mot de passe fraichement réinitialisé, et accède à l’abonnement Azure.  
• En faisant un petit peu de reconnaissance, il découvre un Key Vault contenant des identifiants et mots de passe pour un compte de service. 
• L’attaquant vérifie les permissions, et découvre que ce compte de service a le rôle « Intune Administrator » au niveau d’Entra ID. 

5 Utilisation des privilèges Intune Administrator 

• L’attaquant se connecte en tant qu’Intune Administrator, obtenant des permissions liées à l’administration des postes de travail, y compris la possibilité d’exécuter des scripts sur n’importe lequel d’entre eux. 
• Ils déploient un script sur le poste de travail du Global Administrator d’Entra ID, afin ensuite d’extraire les cookies d’authentification de son navigateur, et de pouvoir avoir accès à la console Azure. 

6 Compromission du compte Global Administrator

• L’attaquant récupère les cookies d’authentification du Global Administrator et les utilise sur son propre poste de travail pour se faire passer pour ce dernier. 

• Cela permet à l’attaquant de contrôler l’ensemble du tenant Entra ID, ce qui inclut la compromission du tenant Microsoft 365, des environnements Azure RM et de tous les autres outils cloud Microsoft reposant sur Entra ID. 

Figure 2: Chemin de compromission globale du Cloud Azure 

En suivant ces étapes, l’attaquant, au-delà de sa capacité à compromettre l’ensemble de l’infrastructure cloud, peut profondément affecter les activités d’une entreprise par un accès non autorisé aux e-mails et aux documents SharePoint, aux sauvegardes, aux postes de travail et serveurs, et au réseau de l’entreprise. Cette attaque démontre l’importance cruciale de sécuriser les comptes à privilèges élevés qui disposent de permissions susceptibles de conduire à une compromission mondiale. 

Figure 3 Impact d’une compromission du Control Plane 

Comment prévenir ce type d’attaque: Implémenter l’Enterprise Access Model, et restreindre l’accès au Control Plane 

Comme nous l’avons vu dans la première partie, les annuaires Cloud, en particulier Entra ID, présentent des différences clés par rapport à un Active Directory. Par conséquent, le modèle traditionnel 3-Tiers doit être adapté pour être pleinement efficace dans les environnements cloud. Pour relever ces défis, Microsoft a introduit un nouveau modèle d’administration spécialement conçu pour les environnements cloud : l’Enterprise Access Model (EAM) 

Figure 4: L’Enterprise Access Model 

Bien qu’il y ait quelques modifications, le concept de base reste le même : les ressources sensibles doivent être isolées pour s’assurer qu’une compromission dans d’un plane (anciennement Tiers) n’entraîne pas une compromission d’un autre. Cela nous amène à une question cruciale : comment devrions-nous définir notre Control Plane au sein de notre système d’information pour l’isoler efficacement et atténuer les risques d’une compromission globale ? 

La réponse réside dans l’identification des composants systémiques de notre système d’information, c’est-à-dire ceux dont la compromission pourrait conduire à une compromission globale. Perdre un projet d’une entité métier est bien moins critique qu’une compromission globale de l’ensemble du Système d’Information. 

Dans notre environnement cloud, de nombreux composants interagissent pour supporter les projets, de l’infrastructure CI/CD et des pipelines de déploiement aux différents outils IAM (tels que les fournisseurs d’identité comme l’AD, Entra ID ou Okta, les outils d’IGA, etc.), ainsi que les outils de sécurité transverses (tels que l’EDR, le Bastion et les outils de MDM par exemple). Bien qu’il s’agisse de composants génériques probablement présents dans de nombreux systèmes, il existe également de nombreux composants spécifiques à l’environnement à prendre en compte. 

Ensuite, Nous devons évaluer l’impact de la compromission des comptes à privilèges élevés au sein de ces composants. Par exemple, si un attaquant prend le contrôle d’un compte à privilèges élevés au sein de l’infrastructure CI/CD, il pourrait potentiellement modifier les processus CI/CD et/ou exécuter un pipeline spécifique pour déployer des modifications non autorisées dans le cloud, ce qui lui permettrait d’obtenir un accès global. Par conséquent, ces comptes CI/CD à privilèges élevés doivent faire partie du Control Plane. De même, considérons la solution EDR : si un administrateur à privilèges élevés peut exécuter des scripts sur tous les postes de travail, potentiellement en volant des cookies d’authentification, en accédant à des données critiques ou en rendant tous les postes de travail inutilisables, alors ce compte à privilèges élevés doit également être inclus dans Control Plane. 

En définissant et en sécurisant soigneusement notre Control Plane, nous pouvons réduire considérablement le risque d’une compromission globale au sein de notre système d’information. 

Synthèse 

Comme nous l’avons vu, le risque de compromission globale dans un environnement Cloud est important. Si les environnements Clouds offrent une flexibilité, une résilience et une optimisation des coûts accrues, ils introduisent également de nouveaux paradigmes et méthodologies opérationnelles qui doivent être comprises et maîtrisés pour garantir la sécurité. 

Le modèle traditionnel 3-Tiers des environnements on-premise, en particulier de l’Active Directory, n’est pas adapté à l’organisation de l’administration dans le cloud. Pour remédier à ce problème, Microsoft a introduit l’Enterprise Access Model (EAM). Ce modèle étend les 3 niveaux en cinq planes distincts, le plus critique étant le Control Plane. Cependant, tout comme pour le modèle 3-Tiers, les mesures d’isolement sont cruciales dans l’EAM, nécessitant l’identification des composants critiques et des comptes à privilèges élevés au sein de votre système d’information. C’est la priorité absolue pour assurer la sécurité globale du cloud. 

Le prochain article de cette série fournira d’autres exemples concrets de scénarios d’attaque qui peuvent conduire à une compromission globale des environnements cloud. Il comprendra également des recommandations de sécurité pour améliorer l’administration du cloud et éviter que ces risques ne se transforment en incidents de sécurité. 

Merci à Louis CLAVERO pour sa contribution à cet article.

Cet article Enterprise Access Model (1/2): Comment définir un Control Plane pour sécuriser l’administration Cloud et empêcher une compromission à grande échelle est apparu en premier sur RiskInsight.

Pour répondre à cet enjeu, Microsoft a défini l’Enterprise Access Model, offrant une nouvelle approche de la gestion des identités et des accès adaptés à la réalité du cloud. Ce modèle a pour promesse de redéfinir la manière dont les entreprises gèrent l’accès aux ressources numériques, que ce soit dans le cadre de solutions cloud comme Azure, d’applications Office 365 ou d’autres services stratégiques. 

Cet article propose une méthodologie et des exemples de mise en œuvre de ce modèle, en définissant des critères d’attribution des rôles à la Management Plane ou à la Control Plane. Il vise également à mettre en lumière les risques liés à une mauvaise implémentation du modèle, avec des exemples concrets. Enfin, il liste quelques bonnes pratiques de configuration ou de gestion du modèle d’accès, permettant de mitiger ces risques.  

Le modèle en tier, un modèle inadapté pour la gestion des accès dans le cloud ?

(Pour plus d’informations sur ce sujet, veuillez consulter notre livre blanc disponible ici)  

Le modèle de sécurité du tiering, appliqué à l’Active Directory, repose sur le principe fondamental de segmentation des comptes à privilèges en 3 différentes couches, appelés tiers. L’objectif est de garantir qu’en cas de compromission d’une ressource ou d’un compte d’un tier, les tiers de confiance supérieure demeurent préservés, évitant ainsi toute propagation potentielle de la compromission à l’ensemble du système. 

• Le tier 0 est le plus critique, il regroupe l’ensemble des composants de l’infrastructure qui gèrent les Domaines Contrôleurs AD de l’entreprise.  
• Le tier 1 se compose classiquement des applications de l’entreprise et des serveurs qui les hébergent.  
• Le tier 2 regroupe tout ce qui gravite autour de l’environnement utilisateur.  

Si le modèle de tiering permet de sécuriser l’infrastructure Active Directory, il rencontre néanmoins des défis significatifs lors de son application dans un contexte cloud. L’un des défis majeurs réside dans la nature même du cloud, pour lequel l’accès et l’administration se font généralement via des consoles exposées sur Internet, contrairement aux environnements on-premise. 

Microsoft a donc défini un nouveau modèle, « l’Enterpise Access Model » pour prendre en compte ces nouveaux défis. Nous examinerons comment ce modèle peut être mis en œuvre efficacement dans un environnement cloud Microsoft. 

Le modèle d’accès aux entreprises : un nouveau modèle adapté pour aux besoins du cloud  

L’une des caractéristiques clés de l’Enterprise Access Model est l’implémentation d’un mode d’accès privilégié pour certaines tâches critiques et la gestion d’une multitude de ressources critiques dites on-premise ou sur le Cloud.  

Source : https://learn.microsoft.com/en-us/security/privileged-access-workstations/privileged-access-access-model

Évolution de l’objectif et du champ d’application 

Tier 0 -> Control plane  

Le control plane comprend la gestion de tous les aspects du contrôle d’accès, la gestion des identités ainsi que tous les éléments pouvant mettre en péril le tenant. 

Tier 1 découpé en 2 morceaux  

• Management Plane : gestion du socle d’infrastructure des applications comme les serveurs ou la configuration des services PaaS (Platform as a Service). 
• Data/Workload Plane : gestion et configuration des applications, des ressources et des APIs. 

Tier 2 découpé en 2 morceaux  

• User access : inclut les scénarios d’accès B2B, B2C et public. 
• App access : permet de tenir compte de la surface d’attaque des échanges applications à applications via les API. 

Quels comptes mettre dans le control plane ? 

Pour définir les comptes du Control Plane, nous proposons une approche basée sur la criticité des rôles et l’impact qu’ils peuvent avoir sur l’environnement cloud. Si le rôle permet d’avoir un impact systémique pour l’Entreprise (destruction d’une part importante du cloud et des backups par exemple), il doit être géré dans le control plane. 

Attention à bien faire l’analyse complète, certains rôles courant comme par exemple le Helpdesk Administrator sans privilège critique sur des ressources direct ont la possibilité de prendre le contrôle de comptes qui eux en possèdent !  

Stratégie basée sur la criticité 

Optimiser la Sécurité : Appliquer l’Enterprise Access Model au Cloud Microsoft 

Au cœur de l’écosystème cloud de Microsoft se trouvent les rôles, une composante essentielle qui régit la manière dont les utilisateurs et les services interagissent avec les ressources cloud.  

Dans cette section, nous plongerons au cœur de cet aspect crucial de la gestion des identités et des accès dans le cloud. Nous expliquerons ce que sont les rôles Azure, comment ils fonctionnent, et pourquoi une bonne gestion est primordiale pour la sécurité et la performance de votre infrastructure cloud.  

Organisation des rôles dans les Cloud Microsoft: 

Les rôles sont un ensemble de permissions qui permettent de contrôler qui peut accéder aux ressources Azure et quelles actions ils peuvent effectuer. 

Les rôles dans Microsoft Cloud  

Il est important de différencier trois types de rôles : 

• Les rôles Azure qui sont dédiés à l’accès et gestion des ressources Azure. 
• Les rôles Microsoft Entra qui sont utilisés pour gérer les ressources de l’annuaire Microsoft Entra ID.  
• Les rôles Microsoft Entra qui sont utilisés pour gérer les ressources Office 365 associées. 

Il est important de souligner que ces rôles peuvent être interconnectés. 

Les rôles Azure : 

Les rôles Azure sont organisés en suivant le principe du Role-Based Access Control (RBAC), qui est une fonctionnalité intégrée de la plateforme cloud Azure de Microsoft.  

Ils sont dédiés à la gestion et à l’accès des ressources Azure et englobent des éléments tels que les machines virtuelles Azure, les bases de données SQL, les services, ainsi que les services d’application comme les Web Apps… 

L’assignation des rôles Azure est une étape clé de la mise en œuvre de la gestion des accès dans un environnement cloud. Elle détermine qui a accès à quelles ressources et quels privilèges sont accordés.  

Les « Security Principal » sur Azure font référence aux entités auxquelles des autorisations sont attribuées, que ce soient des utilisateurs, des groupes ou des services. Il existe plusieurs types de principaux de sécurité sur Azure, qui peuvent être des humains ou non. 

Security Principal 

L’étendue (scope) lors de l’attribution des rôles dans Azure est crucial pour déterminer où les autorisations s’appliquent. Il peut être spécifiée à différents niveaux comme le montre le schéma ci-dessous :  

Les étendues 

Afin de mieux comprendre l’attribution des rôles couplé à notre stratégie basé sur la criticité des rôles et de leurs impacts sur le cloud en ce qui concerne leur placement dans la Control plane nous vous proposons deux exemples concrets : 

Exemple d’application de la stratégie 

Dans l’exemple 1 nous attribuons à un User le rôle de Owner (permettant de lire, écrire et assigner des rôles à d’autres utilisateurs sur toute l’étendue sur laquelle le rôle est attribuée), sur l’étendue d’un Management group. Dans cet exemple le rôle de Owner est critique car l’étendue est très haut niveau : il aura donc les pleins pouvoirs sur toutes les Subscriptions, Resource groups et Resources de son Management group. C’est pourquoi dans ce cas nous plaçons le rôle de Owner dans la Control plane. 

Dans l’exemple 2 nous attribuons à un Group le rôle de Contributor (permettant de lire et écrire sur toute l’étendue sur laquelle le rôle est attribuée), sur l’étendue d’une Subscription. Dans cet exemple, l’impact est limité à une souscription donc probablement pas systémique pour l’Entreprise. C’est pourquoi dans ce cas nous plaçons le rôle de Contributor dans la Management plane. 

Ce qu’il faut retenir de ces exemples c’est que la criticité d’un rôle est en relation directe avec les permissions mais aussi l’étendue sur laquelle on attribue ce rôle.  

Une segmentation entre Microsoft Entra ID et Azure ? Le cas du Global Admin 

Les rôles Microsoft Entra ID et Azure sont définis de manière indépendante : respectivement dans Microsoft Entra ID et dans Azure RBAC. Cela signifie que les autorisations attribuées aux rôles Microsoft Entra ID n’offrent pas d’accès aux ressources Azure, et réciproquement. Cependant, en tant que Global Admin au sein de Microsoft Entra ID, nous avons la possibilité de nous octroyer un accès à tous les souscription et Management groups Azure associés.  

Quand le Global Admin s’accorde des accès vers Azure, le rôle d’User Access Administrator lui est attribué au niveau de l’étendue racine (Management group Root) d’Azure. Ceci lui permet de voir toutes les ressources et d’attribuer des accès dans n’importe quelle souscription ou management groupe de l’annuaire. 

Il est donc important de bien contrôler les personnes et le nombre de personnes se voyant attribuer le rôle de Global Admin, ainsi que de le gérer dans le Control Plane. 

Global Admin vers Azure 

Escalade de privilège par réinitialisation des mots de passe et MFA  

Cette méthode repose sur l’exploitation de privilèges qui autorisent la réinitialisation des mots de passe pour des comptes d’utilisateurs ou des systèmes. Les attaquants ciblent souvent des rôles spécifiques qui ont ce privilège, car une fois compromis, ils peuvent réinitialiser les mots de passe de comptes plus sensibles et donc y accéder pour prendre le contrôle de systèmes critiques.  

Le tableau ci-dessous met en avant les rôles Microsoft Entra ID pouvant réinitialiser le mot de passe de n’importe quel Owner d’une Subscription.  

A noter que certaines mesures de sécurité comme la MFA (Multi-Factor Authentication) permettent de réduire ce risque, comme nous allons le voir dans la suite de l’article.  

Un utilisateur ayant un rôle dans la colonne 1 peut-il réinitialiser le mot de passe de l’utilisateur de la ligne 1 ? 

Scénario d’attaque 1 : Escalade de privilège vers un rôle de Azure depuis un rôle Microsoft Entra ID : 

Un Helpdesk Administrator qui est un rôle est très courant en entreprise peut réinitialiser le mot de passe d’un Owner d’une Subscription et donc accéder à Azure en étant de base dans Microsoft Entra ID. De ce fait la segmentation entre les deux mondes n’est plus garantie. 

Scénario d’attaque 2 : Escalade de privilège vers un rôle de Microsoft Entra ID depuis un rôle Microsoft Entra ID : 

On observe qu’au sein même de Microsoft Entra ID une escalade de privilège d’un Helpdesk Administrator vers un Authentication Administrator est possible.  

Ces deux scénarios ne sont plus possibles si la MFA est paramétrée car le mot de passe seul ne permet pas de s’authentifier sur le compte. Cette mesure de sécurité permet dans la plupart des cas de couvrir ce type d’escalade de privilège. Cependant certains rôles ont la main mise sur les deux paramètres à savoir la réinitialisation de mot de passe et le paramétrage de la MFA et il n’est pas rare que le support utilisateur ait cette capacité. 

Un utilisateur ayant un rôle dans la colonne 1 a-t-il des droits sur la MFA ? 

Scénario d’attaque 3 : Escalade de privilège vers depuis un Authentication Administrator vers Azure ou Microsoft Entra ID : 

Ici nous prenons le cas du Authentication Administrator un rôle peut gérer et réinitialiser les méthodes d’authentification des utilisateurs qui ne possèdent pas un rôle d’administrateur. On observe donc qu’en plus de pouvoir avoir la main la MFA on a également via ce rôle la possibilité de modifier ou de réinitialiser les mots de passes d’une large partie des utilisateurs. Les tableaux ci-dessus montrent qu’il peut prendre le rôle d’un Helpdesk Administrator ou d’un Owner d’un Subscription.  

Il faut donc gérer ces rôles dans le Control plane pour éviter ces scénarios d’escalade de privilège et maintenir l’étanchéité entre Microsoft Entra ID et Azure. 

Renforcez Votre Sécurité, quelques exemples de mesures de sécurité supplémentaires 

Accorder des privilèges à une Managed Identity plutôt qu’à un utilisateur 

Afin de limiter les risques liés à l’attribution de rôles de la Control plane, il faut privilégier l’utilisation des Managed Identities comme alternatives aux autorisations accordées aux utilisateurs, ou du PIM (Privileged Identity Management) pour mieux gérer les utilisateurs à hauts privilèges. Cette approche permet de limiter les risques d’escalade de privilège. 

Les Managed Identities sont des entités d’authentification gérées par Azure pour les applications et les services. Plutôt que d’accorder des privilèges à des utilisateurs individuels, vous pouvez attribuer des autorisations aux Managed Identities associées à ces applications ou services. Cette approche présente les avantages suivants : 

1. Exposition aux Identifiants réduite : En utilisant des Managed Identities, on réduit la surface d’attaque potentielle, car les identifiants ne sont pas exposés ni partagés. 
2. Automatisation Sécurisée : Les applications et les services qui utilisent des Managed Identities peuvent automatiser des tâches sans nécessiter de comptes d’utilisateur avec des privilèges élevés. 
3. Contrôle Centralisé : La gestion des autorisations se fait de manière centralisée, ce qui facilite la gestion des privilèges à l’échelle de l’ensemble de l’environnement cloud. 

Limiter les risques avec le service Privileged Identity Management (PIM) 

Dans le cas où l’attribution de rôles à hauts privilèges ou des rôles de la Control plane et surtout à des utilisateurs, il est très important de contrôler et de surveiller l’attribution de ses rôles. L’utilisation de PIM qui est une fonctionnalité qui permet une gestion précise des privilèges d’administration peut s’avérer intéressant. PIM repose sur : 

1. L’élévation temporaire des privilèges : Les utilisateurs peuvent obtenir des privilèges d’administration de manière temporaire pour effectuer des tâches spécifiques, réduisant ainsi les risques associés à des autorisations permanentes et aux erreurs. 
2. La justification obligatoire lors d’une élévation de privilège. 
3. La mise en place un contrôle et surveillance. 
4. La création d’un workflow de validation des élévations privilège : /!\ Nécessite une maturité très forte pour pouvoir gérer la réactivité ainsi que les besoins en HNO (Heures Non Ouvrées). 

La sécurisation d’un environnement cloud est une préoccupation essentielle. Les attaques utilisant les concepts et les subtilités de la gestion du cloud augmenteront dans un futur proche, il serait dommage d’attendre que les attaquants commencent à traiter ce sujet pour commencer à traiter correctement ce sujet. 

Dans cet article, nous avons exploré divers aspects de la gestion des privilèges et de la sécurité dans le cloud, en mettant en lumière des stratégies et des pratiques fondamentales pour protéger efficacement la control plane qui regroupe des données et ressources très sensibles pour l’intégrité de l’infrastructure d’une entreprise. 

Nous avons exploré le modèle d’accès aux entreprises de Microsoft, qui repose sur le principe du « Zero Trust ». Ce modèle offre une approche flexible et sécurisée pour la gestion des accès dans un environnement cloud. 

Nous avons ensuite présenté les rôles de Microsoft Azure et certains risques d’escalade de privilège, soulignant l’importance de l’attribution précise des autorisations et de la surveillance continue pour prévenir les abus et les menaces potentielles. 

La sécurisation de la Control Plane dans un environnement cloud revêt une importance capitale pour la protection des données et des ressources sensibles d’une entreprise. En explorant les stratégies et les bonnes pratiques évoquées dans cet article, il est clair que chaque organisation doit définir avec soin son modèle de rôles, en veillant à ce que les comptes et les autorisations soient attribués de manière appropriée dans le Control Plane ou le Management Plane. Il est impératif de mettre en place des mesures garantissant l’isolation de chaque plan, tout en accordant une attention particulière à la gestion précise des autorisations et à la surveillance continue pour prévenir les abus et les menaces potentielles (notamment les escalades de privilège).  

La sécurité dans le cloud n’est plus une option, mais une nécessité absolue ! 

Cet article Protéger le Control Plane : Les Enjeux Cruciaux de la Sécurité dans le Cloud  est apparu en premier sur RiskInsight.

Par ailleurs, nous évoluons vers des Systèmes d’Information construits sur une diversité d’environnements de plus en plus vaste, notamment grâce au Cloud, maintenant omniprésent dans les SI des entreprises. Cela leur permet d’élargir leurs capacités mais, d’un point de vue sécurité, accroît la surface et les risques d’attaques. 

Des techniques classiques de protection et de détection contre les intrusions existent déjà et se développent de manière exponentielle. Celles-ci sont efficaces pour les attaques les plus courantes mais ne sont bien souvent pas ou peu adaptées aux spécificités du Cloud. 

Ainsi, des questions se posent sur l’utilisation de stratégies proactives, telle que la Deceptive Security, permettant de garder une longueur d’avance sur les attaquants. Notamment dans le cadre de Cyber-Résilience : comment utiliser ce genre de technologie sur des environnements de types traditionnels et Cloud ? 

Dans quels cas utiliser des techniques de Deceptive Security ? Est-ce que les solutions de Deceptive Security dans le Cloud sont développées aujourd’hui ? Y a-t-il des stratégies spécifiques à envisager dans le cadre d’un environnement Cloud comparé au traditionnel ? 

Nous répondrons à ces questions dans une mini-série de 2 articles. Dans le premier article, nous vous montrions comment développer et évaluer votre stratégie de leurre. Dans le second article, nous présentons un exemple pratique de sécurité trompeuse dans AWS. 

Postulats initiaux et choix du scenario  

Grâce à l’expertise Wavestone et aux ressources partagées par notre CyberLab, nous avons conçu un scénario simple pour illustrer l’utilisation de leurres en environnement Cloud AWS. L’exemple détaillé dans la suite est inspiré par un scénario CTF (Capture The Flag) dessiné par l’équipe du CyberLab pour illustrer la propagation latérale d’un attaquant. 

De même manière que dans les scénarios traités précédemment, où nous utilisions la Deceptive pour la détection d’attaquants déjà introduits au sein du SI, il s’agit encore une fois d’éviter d’attirer des attaquants opportunistes sur notre réseau dans une optique de Deceptive « de recherche ». Ainsi, nous postulons une infection initiale quelconque, fortement probable (à fortiori dans des environnements Cloud peu maitrisés), et nous concentrons sur la détection de l’intrus en cours de déploiement sur le réseau. 

L’application de cette démarche à un environnement AWS n’est pas innocent. Un des apports du Cloud repose en effet dans la gestion des identités simplifiée et la délégation aisée des accès, mais cet atout peut toutefois tourner à l’avantage d’attaquants en cas d’exposition involontaire de ressources ou de création de liens dangereux entre zones de niveau de sécurité différents. Les mesures de durcissement et de prévention ne manquent pas et sont généreusement promues par les fournisseurs Cloud eux-mêmes mais ces vulnérabilités demeurent le lot des comptes et souscriptions peu durcis, dont l’administration obéit trop souvent à des règles encore informelles.  

Le scénario d’attaque et de leurrage associé reposera donc sur ce principe de liaison entre deux comptes AWS, ici conçus comme un environnement de production et un autre de développement, moins critique. Nous nous placerons dans un scénario où une relation d’approbation permet de se propager depuis le compte de développement vers le compte de production, via l’endossement d’un rôle cross-account.  

Scénario de leurrage 

Description du scénario  

Partons de l’idée selon laquelle un utilisateur non autorisé a obtenu des accès sur une machine EC2 (domainIntegrated-EC2) au sein du compte de test (infection initiale). Après une première connexion réussie, il tente d’accéder à des ressources couramment utilisées telles que Amazon Simple Storage Service (Amazon S3) ou essaye d’élever ses privilèges en assumant d’autres rôles (rôle chaining) liés au rôle auquel il a accès. 

Ce scénario de propagation latérale est une technique d’attaque courante dans les environnements Cloud en raison de la nature de leur architecture et du modèle de responsabilité du cloud computing, où le client est responsable de la sécurisation de ses applications, de ses données et du contrôle d’accès (alors que le fournisseur veille à la sécurité de l’infrastructure sous-jacente). 

Tel qu’illustré ci-dessous, les attaques de propagation latérale tirent parti des faiblesses des contrôles de sécurité du client, telles que des autorisations mal configurées ou l’application de mécanismes d’authentification trop faibles, pour obtenir un accès non autorisé à d’autres ressources dans l’environnement. 

Scénario du point de vue de l’attaquant 

0. Après avoir compromis une machine EC2 « domainIntegrated », l’attaquant s’aperçoit qu’un rôle lui est associé (« Semi-Admin-role ») : 

Enumération de la machine EC2 domainIntegrated 

Il énumère ensuite les droits du rôle « Semi-Admin-Role » :  

Enumération des droits du rôle Semi-Admin-Role 

Tout d’abord ce rôle a des privilèges de modification sur une ressource du compte « AWS – SHARED » : il peut en effet endosser (sts :assumeRole) et modifier (iam :UpdateRole) un rôle intitulé « LambdaAuto ». Il peut ensuite endosser (par « role chaining », étape 5 du schéma ci-dessus) un autre rôle nommé « SecurityAudit» dans un compte différent, intitulé AWS MASTER. 

L’attaquant réalise par ailleurs qu’il peut également assumer directement un autre rôle (« IAM-RO-Role ») du compte AWS – MASTER. Ce dernier rôle attire particulièrement son attention car le compte MASTER suggère par son nom un périmètre d’action bien plus important que le simple compte SHARED, et le rôle IAM-RO-Role évoque un périmètre de vision étendu sur les ressources de ce compte. 

1. L’attaquant endosse le « SemiAdmin-role » qui lui permet par la suite d’assumer le rôle « IAM-RO » et tenter d’autres actions qui lui permettront de bien analyser son champ de vision. 
2. En effet, après avoir assumé le rôle « IAM-RO », il procède à une énumération de l’IAM où il s’aperçoit des rôles et des utilisateurs dans son champ de vision :  

Liste des rôles dans le champ de vision du rôle IAM-RO 

Liste des utilisateurs dans le champ de vision du rôle IAM-RO 

Le rôle « SecurityAudit » attire particulièrement son attention grâce aux privilèges que ce nom suggère et la description du rôle qui donne des informations sur lesdits privilèges : 

Description du rôle SecurityAudit 

Toutefois, l’attaquant n’a qu’un accès en lecture sur les ressources listées. Il va donc chercher si certaines de ces ressources sont accessibles en écriture depuis le compte SHARED où il a de hauts privilèges. Par exemple, si certains rôles du comptes MASTER peuvent être endossés par des rôles du compte SHARED : 

Liste des rôles pouvant être assumés depuis un compte externe (ici le compte SHARED) 

L’attaquant investigue la relation d’approbation du rôle « SecurityAudit », qui justement, autorise un endossement par le rôle « LambdaAuto » du compte SHARED. 

3. De retour sur le compte SHARED, l’attaquant n’a plus qu’à vérifier que l’autre pendant de cette relation d’approbation, c’est-à-dire que le rôle « LambdaAuto » autorise bien dans sa politique d’approbation l’endossement du rôle « SecurityAudit ». Ce n’est pas le cas, mais le rôle « SemiAdminRole » lui permet de configurer cette autorisation. 

4. Une fois la politique d’approbation du rôle « LambdaAuto » modifiée, il peut maintenant assumer le rôle « LambdaAuto ». 

5. Puis, il endosse (par role-chaining) le rôle « SecurityAudit », le véritable leurre. 

Role chaining de l’attaquant 

Après sa tentative d’endossement du rôle « SecurityAudit » dont il espère les privilèges d’auditeur sécurité (annoncés en étape 1), l’attaquant se retrouve en réalité sans réels pouvoirs, par exemple : 

Exemple d’un accès refusé depuis le rôle SecurityAudit 

Création des leurres  

Le schéma ci-dessous révèle à présent les ajouts de leurres aux différentes étapes de l’attaque et leur configuration par le défenseur : 

Scénario du point de vue du défenseur 

0. Le rôle « Semi-Admin-Role » est le point d’entrée dans le scenario de leurrage. Il peut donc être associé à toute ressource susceptible d’être compromise (ici l’EC2 « domainIntegrated ») pour rediriger l’attaquant vers les leurres.  

Aucune alerte n’est configurée à ce niveau car la connexion du rôle Semi-Admin-Rôle à l’ensemble des ressources du compte SHARED rend probable le déclenchement d’un endossement involontaire et, par suite, d’alertes faussement positives. 

1. Une fois le rôle IAM-RO assumé, l’attaquant est donc invité dans un compte entièrement dédié au leurrage et se familiarise avec les ressources alentour, obtenant ainsi une vue d’ensemble complète de tous les rôles et utilisateurs du compte. 

2. En peuplant le champ de vision de l’attaquant, non seulement avec le leurre principal « SecurityAudit », mais également avec d’autres rôles et utilisateurs factices, nous nous assurons que l’aspect du compte semble crédible et que notre leurre-clé, le rôle SecurityAudit ne soit pas isolé. 

Nous ajoutons ainsi au sein du compte :  

• Des Users : différents noms d’utilisateurs attrayants pour l’attaquant.  
• Le rôle « LambdaFunction » : ce rôle est créé pour la simulation d’une fonction Lambda qui fait appel aux services AWS. 
• Le rôle « LogsAndS3Bucket » : un rôle créé avec objectif de faciliter l’accès aux services de journalisation et aux ressources de stockage S3 au sein du compte. 
• Le rôles « taskExecutionRole » : le rôle d’exécution des tâches pouvant être utilisé pour différents objectifs et services associés au compte. 

3. Le rôle « SemiAdminRole » a volontairement été configuré avec la permission (iam :UpdateRole) sur le rôle « LambdaAuto » lui permettant de modifier ce rôle et donc d’ajouter la relation d’approbation vers le rôle « SemiAdminRole ». Pour des raisons de surveillance, une première alerte peut être déclenchée à ce niveau lors de la mise à jour de la relation d’approbation de « LambdaAuto » permettant au « SemiAdminRole » de l’assumer. 

4. Le rôle « LambdaAuto » est créé volontairement comme la porte d’entrée vers le rôle « SecurityAudit », une fois sa relation d’approbation modifiée grâce aux privilèges du rôle « SeminAdminRole ». 

5. Le rôle « SecurityAudit » est volontairement configuré avec une relation d’approbation autorisant le rôle « LambdaAuto » du compte SHARED à l’assumer. 

6. A cette étape, l’attaquant avait supposé qu’il obtiendrait des droits d’auditeur de sécurité. Cependant, une politique de contrôle de sécurité (SCP) très restrictive a été appliquée, ne lui accordant aucun privilège sur le compte. 

La politique interdisant toutes actions depuis le rôle Security-Audit-Role 

Chaîne d’alerting 

Une chaîne d’alerting dans le cloud AWS fait référence à un moyen de communiquer des notifications ou des alertes générées par les services AWS aux utilisateurs ou aux équipes responsables de la gestion de ces services, leur permettant de prendre des mesures rapides pour résoudre les problèmes et minimiser les interruptions de service.  

Pour configurer une chaîne d’alerting, vous devez d’abord configurer les services AWS pour générer des alertes lorsque certains événements se produisent, comme un serveur en panne ou une application dépassant un seuil spécifique d’utilisation du processeur. Une fois ces alertes générées, elles peuvent être envoyées à la chaîne d’alerting appropriée en fonction des préférences de notification configurées par l’utilisateur ou l’équipe responsable de la gestion du service. 

Afin de détecter l’attaquant, nous utilisons les services AWS suivants pour créer la chaine d’alerting : 

• CloudTrail pour traquer les actions réalisées sur le compte AWS compromis ; 
• EventBridge pour détecter tout événement « AssumeRole » du rôle « SecurityAudit » et déclencher une alerte ; 
• Simple Notification Service (SNS) pour envoyer l’alerte par e-mail avec les informations recueillies lors de l’attaque. 

Illustration de la chaîne d’alerting 

Etapes de création de la chaîne d’alerting : 

Configuration de CloudTrail 

La première étape de la création d’une chaîne d’alerting sur AWS consiste à activer CloudTrail (s’il n’est pas activé) dans votre compte AWS. CloudTrail enregistre toutes les activités et calls API dans votre compte, ce qui peut être utile à des fins de sécurité, de conformité et de dépannage.  

Partant des logs générés dans CloudTrail, nous avons créé une règle EventBridge qui envoie des notifications au service SNS chaque fois que le rôle « SecurityAudit » est assumé (type d’événement : AssumeRole). 

Création d’une règle EventBridge 

Une règle permet de surveiller des types d’événements spécifiques et lorsqu’un événement correspondant se produit, il est routé vers le service associé à la règle et traitant l’événement (ici le service SNS). 

Le modèle d’événement permet de détecter tous les événements du type « AssumeRole » se produisant dans le compte utilisé et déclencher l’alerte. Afin d’éviter les faux positifs lors du déclenchement des alertes, nous avons affinés le modèle d’événement pour qu’il soit aussi précis que possible pour correspondre aux événements qui nous intéressent.  

De ce fait, il sied d’inclure des champs pertinents, tels que la source de l’événement, le type de détail ou des valeurs spécifiques, pour affiner les critères de correspondance. Cela permet de réduire les risques que des événements non liés déclenchent la règle. 

Le modèle d’événement détectant tous les événements « AssumeRole » sur le rôle « SecurityAudit » 

Le service Eventbridge doit donc être préalablement lié à la cible SNS.  

La cible liée à la règle EventBridge 

Configuration d’une rubrique SNS 

A cette étape, une rubrique SNS est créée et liée à un abonnement d’un point de terminaison par mail authentifié par la suite. Le sujet SNS sera la cible de la règle EventBridge. Après la création du sujet, on procède à l’abonnement par e-mail en sélectionnant l’adresse de messagerie comme protocole (point de terminaison) où on souhaite recevoir les alertes. 

On pourrait envisager d’autres cible que mail pour la réception de l’alerte (ServiceNow, SIEM, etc…). 

Détails de la rubrique SNS 

Personnalisation de l’alerte 

Afin de personnaliser le contenu de l’alerte et de n’afficher que les éléments importants recherchés, la fonction Transformateur d’entrée d’EventBridge a été utilisée.  

Elle permet de personnaliser le texte d’un événement avant qu’il ne soit transmis à la cible.  Pour ce faire, il sied de définir des variables JSON pour référencer des valeurs dans la source d’événement d’origine. 

Configuration du transformateur d’entrées 

Pour notre cas, les variables répertoriées ci-dessous constitueront le message de l’alerte : 

Création du transformateur d’entrée 

Modèle d’entrée 

Le modèle d’entrée va utiliser les variables définies précédemment au sein du message d’alerte final :  

 Création du modèle d’entrée 

Ainsi, après endossement du rôle « SecurityAudit », une alerte est envoyée au point de terminaison créé : 

Exemple du contenu de l’alerte par mail 

Coût des services AWS utilisés 

AWS offre une approche de paiement à l’utilisation pour la tarification de ses services cloud. Avec AWS, vous ne payez que les services dont vous avez besoin, tant que vous continuez à les utiliser et ce, sans contrat à long terme. Vous ne payez que les services que vous utilisez, et si vous cessez de vous en servir, aucun coût additionnel ou frais de résiliation ne vous sera facturé. 

Les services déployés dans le cadre de ce scénario n’ont pas vocation à être utilisé sauf dans le cas d’une intrusion donc d’un incident de sécurité. Les coûts associés sont donc négligeables. 

Evaluation du leurre avec la matrice PARCS 

Plusieurs critères permettent d’évaluer un leurre et voici les résultats de notre analyse au regard de la matrice PARCS : 

• Pertinence : 4/4 

« Diverses approches peuvent être adoptées pour efficacement repérer la compromission initiale d’une instance EC2 et la propagation latérale d’un attaquant Dans notre contexte, selon les ressources à notre disposition, une stratégie envisageable consiste à surveiller les opérations en analysant les journaux, ce qui permettra de détecter des actions malveillantes. Ces observations pourraient ensuite être utilisées pour générer des alertes destinées aux administrateurs. Par exemple, une alerte pourrait être déclenchée en cas de tentative d’intrusion via une attaque de force brute sur le service RDP des instances EC2 au sein de notre environnement AWS, grâce à GuardDuty. 

De plus, il serait possible d’utiliser une combinaison de services AWS tels que CloudTrail et EventBridge pour établir des règles de détection et d’automatisation des interventions en réponse à des activités spécifiques, notamment celles liées aux accès entre comptes (cross-account) et créer des règles de détection qui surveillent tous les événements d’endossement afin de déclencher les actions en cas d’événements correspondant.» 

• Attractivité : 4/4 

« Le leurre se distingue par un compte dédié, augmentant ainsi de manière significative son pouvoir d’attraction. En ayant accès aux métadonnées de toutes les ressources à sa portée, l’attaquant peut également vérifier divers niveaux de privilèges ce qui renforce substantiellement la crédibilité. Grâce à la capacité de visualiser les dates et heures des dernières utilisations des ressources dans son champ de vision, il peut en déduire que ces ressources sont rarement utilisées. Dans cette optique, une fonction lambda est mise en œuvre pour automatiser l’exécution de différentes ressources ou leur authentification, garantissant ainsi des preuves d’utilisation récentes. » 

• Risqué : 4/4 

« L’autorisation accordée au rôle IAM-RO ne confère des privilèges IAM à l’attaquant que dans le contexte d’un compte purement fictif. Grâce à une configuration appropriée de la SCP en amont, toutes les tentatives d’actions du rôle Security-Audit seront également contrées. Les seuls éléments délibérément introduits dans un environnement réel sont les rôles Semi-Admin et Lambda-Auto, qui sont soumis à des politiques rigoureuses empêchant toute attribution de droits ou de privilèges en cas de tentative d’utilisation malveillante. Ces politiques incluent un accès en lecture seule (IAMReadOnlyAccess) et une restriction empêchant toute modification des autorisations liées au rôle du compte, tel que défini par la SCP. » 

• Crédibilité : 3/4 

« La crédibilité du leurre peut être remise en question en raison des ressources disponibles à sa disposition et des limitations potentielles, notamment une Inline Policy qui restreint les autorisations et les actions possibles. Il est important de prendre en compte ces éléments, car ils peuvent susciter des doutes chez les attaquants et compromettre l’efficacité du leurre. Il est donc crucial de mettre en place des mesures qui rendent le leurre aussi réaliste et convaincant que possible, en veillant à ce qu’il ait accès aux ressources et aux autorisations pertinentes pour créer un scénario crédible. » 

• Scalabilité : 3/4 

« En fonction de la taille d’une infrastructure, il devient envisageable de mettre en place un déploiement et une maintenance fluides des composants, grâce à l’emploi de scripts automatisés habilités à exécuter des opérations sur les ressources. Toutefois, il est essentiel de garantir une surveillance minutieuse de l’intégralité des ressources afin de consolider la sécurité face à d’éventuelles atteintes et d’assurer une réaction rapide pour défendre un périmètre étendu. » 

En conclusion, la mise en œuvre d’un tel scénario de Deceptive Security dans le Cloud, offre une approche pour améliorer sa sécurité globale. Cela contribue à restreindre la capacité d’un attaquant à explorer et à se propager à travers le réseau en présentant des chemins trompeurs, en retardant leur progression et en permettant une détection et des réponses plus rapides. Les leurres, qui ressemblent à des cibles attrayantes, détournent l’attention et les ressources des attaquants des véritables actifs, ce qui accroît les chances de détection précoce. 

De plus, les mécanismes d’alerte jouent un rôle crucial en fournissant des informations rapides sur les intrusions potentielles aux équipes de sécurité, ce qui permet une réponse rapide aux incidents et limite l’impact des attaques. 

En combinant ces stratégies de défense, on renforce la posture de sécurité globale des environnements Cloud, on améliore leur résilience face aux cybermenaces en constante évolution et on garantit l’intégrité et la confidentialité des données sensibles.  

En utilisant ces mesures de sécurité trompeuses, les entreprises peuvent renforcer leur défense contre les cyberattaques. Toutefois, il est important de noter que la Deceptive Security ne remplace pas les solutions de cybersécurité standard existantes et que la protection contre les cyberattaques nécessite l’utilisation de techniques de sécurité complémentaires pour une défense optimale. 

ANNEXES – Services AWS 

Les définitions suivantes sont issues de la source : AWS documentation → docs.aws.amazon.com. 

 SCP – Politiques de contrôle de services : Les politiques de contrôle de services sont un type de politique permettant de contrôler de manière centrale les autorisations. Cela permet de veiller à ce que les grandes directives soient respecter pour tous les comptes AWS de l’organisation. 

EC2 – Elastic Compute Cloud : AWS EC2 permet de louer des serveurs (des instances EC2) pour répondre au mieux aux besoins de la charge de travail. 

STS – Security Token Service : AWS STS permet de demander des informations d’identification de sécurité temporaires pour les ressources AWS. Cela permet d’attribuer un accès temporaire aux ressources via des appels API, la console AWS ou le CLI (Console Line Interface) AWS. 

À noter : Chaque jeton STS possède un cycle de vie, défini lors de la création de celui-ci, pouvant aller entre 15 minutes et 36 heures. 

CloudTrail : AWS CloudTrail est un service qui enregistre les actions effectuées par un utilisateur, un rôle ou un service AWS. 

Fonction Lambda : La fonction Lambda est un service permettant d’exécuter du code. 

SNS – Simple Notification Service : Amazon SNS est un service web permettant de gérer l’envoi de messages (SMS, e-mails, HTTP.S, etc.). 

Merci à Charles BULABULA pour sa contribution à cet article. 

Cet article Deceptive Security : la solution pour une détection efficace dans le Cloud ? – Exemple d’application de la Deceptive dans le Cloud AWS  est apparu en premier sur RiskInsight.

Par ailleurs, nous évoluons vers des Systèmes d’Information construits sur une diversité d’environnements de plus en plus vaste, notamment grâce au Cloud, maintenant omniprésent dans les SI des entreprises. Cela leur permet d’élargir leurs capacités mais, d’un point de vue sécurité, accroît la surface et les risques d’attaques. 

Des techniques classiques de protection et de détection contre les intrusions existent déjà et se développent de manière exponentielle. Celles-ci sont efficaces pour les attaques les plus courantes mais ne sont bien souvent pas ou peu adaptées aux spécificités du Cloud. 

Ainsi, des questions se posent sur l’utilisation de stratégies proactives, telle que la Deceptive Security, permettant de garder une longueur d’avance sur les attaquants. Notamment dans le cadre de Cyber-Résilience : comment utiliser ce genre de technologie sur des environnements de types traditionnels et Cloud ? 

Dans quels cas utiliser des techniques de Deceptive Security ? Est-ce que les solutions de Deceptive Security dans le Cloud sont développées aujourd’hui ? Y a-t-il des stratégies spécifiques à envisager dans le cadre d’un environnement Cloud comparé au traditionnel ? 

Nous répondrons à ces questions dans une mini-série de 2 articles. Dans le premier article, nous vous montrerons comment développer et évaluer votre stratégie de leurre. Dans le second article, nous présenterons un exemple pratique de sécurité trompeuse dans AWS.

Elaborer et évaluer sa stratégie de leurrage 

Ambitions de la Deceptive Security 

La Deceptive Security dans les grandes lignes 

La « Deceptive Security » (désignée par « Deceptive » dans la suite de l’article), ou « leurrage numérique », est une technique de cyberdéfense qui fait face à l’intrusion d’attaquants dans un SI (Système d’Information). Ceci fonctionne grâce à la mise en place de pièges et/ou leurres dans un SI. Ces derniers ont pour objectif d’imiter des technologiques légitimes pour ne pas être repérés. 

Cette méthode permet de détecter des intrusions en générant des alertes, d’empêcher de nuire à l’infrastructure réelle mais aussi d’observer les pratiques utilisées par l’attaquant. 

Avant d’entamer ce sujet dans les détails, il est conseillé de parcourir l’article « Deceptive Security : comment arroser l’arroseur ? » qui décrit les principaux concepts de la « Deceptive Security ». 

Les grands objectifs de la Deceptive 

L’utilisation de la Deceptive sur un SI peut avoir plusieurs objectifs : 

• Détecter une intrusion 
• Distraire l’attaquant 
• Analyser les techniques utilisées lors de l’attaque 

Cette technologie peut être utilisée à différents degrés de maturité et selon les besoins identifiés.  

Effectivement, cette technologie permet de répondre à plusieurs besoins, vus ci-dessus, or, l’objectif est de déterminer en amont nos exigences face à cette technologie. Si on restreint le besoin à de la détection, il faut noter que la configuration, le déploiement et la maintenance de la Deceptive sera bien moins complexe que si on pousse au maximum les possibilités de cette technologie (exemple : mise en place de scénarios complexes pour leurrer l’attaquant et analyse stratégique de ses faits et gestes). 

Les atouts de la Deceptive  

Pourquoi la Deceptive ? 

Comme abordé dans l’introduction, les challenges actuels de cybersécurité sont nourris par le besoin de détection et réaction face à des attaques grandissantes. 

La Deceptive ne remplace pas les solutions de cybersécurité standards existantes. Plus complexe, elle agit en complément pour couvrir tous les types d’attaques, dont les plus sophistiquées. 

Cette technologie n’est pas conçue pour prévenir une attaque, mais pour alerter les équipes de sécurité, minimiser l’effet de l’attaque et observer le modus operandi de l’intrus (« Détecter, Distraire & Analyser »). 

Honeypot VS Honeytoken 

Présentation des termes 

Les leurres peuvent être de nature différente selon le besoin et comment on prévoit de les utiliser. Dans tous les cas, ils prennent l’apparence d’attributs composants notre Système d’Information. 

Les leurres les plus connus sont les « honeypots ». Ce sont des serveurs ou postes de travail qui vont venir imiter des machines réelles sur le réseau. On retrouve également ce qu’on appelle « honeynet » : un ensemble de serveurs rassemblés en réseau.  

Un autre type de leurres intéresse de plus en plus aujourd’hui. C’est un leurre qui vient se cacher directement sur un système. On parle d’abord de « honeyfiles » qui sont généralement représentés par des documents ou autres fichiers qui ont pour rôle de déclencher une alerte lorsque que quelqu’un vient interagir avec eux. Enfin, nous avons les « honeytokens » qui sont des données, informations, souvent des secrets ou clés utilisés pour accéder à une ressource factice sur le SI (un honeypot par exemple). 

Une différence fondamentale 

L’utilisation traditionnelle d’honeypots peut permettre l’observation et la compréhension des actions de l’attaquant en plus de la détection d’une intrusion. La difficulté dans ce cas est de configurer un leurre assez attractif et crédible pour que le cyberattaquant tombe dans le piège, sans pour autant livrer des informations pouvant compromettre un composant de notre réelle infrastructure. 

L’intérêt des honeytokens est que l’on va travailler un leurre plus complexe certes mais plus fin et très crédible, pour ensuite interagir avec le reste de notre piège. Sans les honeytokens, la probabilité que l’on piège un attaquant est plus faible et les résultats d’analyses pas toujours fiables. La dépendance que créer l’honeytoken avec son environnement le rend d’autant plus attractif comparé à un honeypot seul qui ne représente qu’un piège sans possibilité d’escalade par la suite. Pour que les honeypots soient efficaces, il faut recommander le déploiement d’un ou plusieurs honeynets complets, mais le nouveau souci que l’on rencontre ici est le coût d’une telle infrastructure. 

Développement de la technologie dans le Cloud 

Le défi aujourd’hui pour les éditeurs de solutions Deceptive les plus matures, est le développement de services spécifiques dans le Cloud. 

Effectivement, les entreprises utilisent de plus en plus le Cloud pour étendre leur stockage, déployer des machines virtuelles, des conteneurs, etc. Cette mise à disposition de services est très populaire et efficace or, l’intérêt pour les cyberattaquants augmente du même temps. Les templates, ou configurations par défaut facilitent la vie des entreprises mais peuvent augmenter les risques de cybersécurité. Même si de nombreux fournisseurs Cloud évolue beaucoup sur le sujet, les configurations par défaut ne répondent pas toujours aux préconisations de sécurité informatique. 

Le Cloud est donc un nouveau terrain de jeu pour les cyberattaquants. C’est pour cela que l’on s’intéresse aujourd’hui à l’adaptation de nos connaissances de la Deceptive pour également protéger les environnements et services Cloud. 

Aperçu des principaux éditeurs sur le marché 

Il faut noter que la Deceptive n’est pas réservée uniquement dans des cas d’usage trop complexes. Il existe aujourd’hui toutes sortes d’offres sur le marché. Certaines proposent des services permettant d’obtenir un outil clé en main complet, alors que d’autres privilégient le sur-mesure, la qualité des leurres et donc plutôt la possibilité d’utiliser leur outil pour créer soi-même ses leurres (configuration et maintenance non gérées par la solution en elle-même). 

Voici un aperçu des principaux éditeurs et leurs solutions :  

Pour certains, la tendance actuelle est de s’allier à d’autres outils ou d’intégrer leur solution à des EDR (Endpoint Detection and Response) pour augmenter l’efficacité de la technologie et répondre au besoin du marché. 

Comme exprimé précédemment, le challenge que certains ont choisi de relever est de s’adapter à un environnement Cloud. Par exemple, des solutions comme « Attivo Networks », rachetée par SentinelOne, développent des offres Cloud AWS qui propose la création de leurres en lien avec le service (e.g. : EC2, S3, AWS access keys, etc.). 

Comment construire et placer ses leurres ? 

Les stratégies de Deceptive  

Une fois avoir pris connaissance de cette technologie et à toutes les possibilités qu’elle apporte, il devient intéressant de se demander quelle.s stratégie.s adopter quant à la quantité de pièges et/ou leurres à implémenter et à la disposition de ces derniers dans le SI. 

Pour s’adapter aux différents cas d’usages, 3 stratégies se détachent répondant à des besoins distincts : 

Effectivement, la stratégie de Deceptive à adopter est souvent sur-mesure en fonction de l’infrastructure du SI et surtout en fonction des priorités et objectifs définis au préalable. 

À titre d’exemple : Si nous sommes dans le cas d’un besoin d’enrichissement de ses technologies de détection au sein de son SI, il peut être intéressant d’étudier la stratégie de « déploiement en masse » de leurres. Ceci a pour volonté de créer un SI fantôme et, ainsi, augmenter la probabilité que le cybercriminel tombe dans un piège qui déclenchera une alerte à destination des équipes de sécurité. 

La matrice PARCS 

Le challenge lorsque l’on parle de Deceptive, et plus spécifiquement de leurres, est de répondre aux questions : Qu’est-ce qu’un bon leurre ? Comment créer un bon leurre ? Où le placer ? Combien en placer ? etc. 

L’article « HoneyWISE : stratégie d’exploitation d’honeytokens en environnement Active Directory », écrit par Augustin TOURNYOL-DU-CLOS et Nathan FAEDDA, propose une stratégie de leurrage contre certaines attaques dans un contexte précis : l’AD (Active Directory). Nous aborderons également le sujet des honeytokens, mis en comparaison avec les honeypots, dans la suite de cet article. 

Les objectifs de cette étude étaient de tester simplement l’implémentation de leurres au sein de l’AD et de mesurer leur efficacité grâce à la matrice « PARCS ». 

PARCS est ainsi née sur la base de 5 critères, pensée à l’origine dans le contexte d’un environnement AD mais applicable à tous les environnements :  

Lors du processus de réalisation d’un leurre, il est conseillé de préparer un PARCS pour vérifier sa réflexion et valider que celui-ci correspond à nos attentes. Il faut également penser aux besoins minimums illustrés par ces 5 critères : Pertinence, Risque, Crédibilité, Attractivité et Scalabilité. 

À travers cette matrice, l’objectif est d’estimer un besoin pour ensuite déterminer une balance d’importance et de priorité sur ces critères (Est-ce que l’attractivité du leurre a de l’importance dans mon cas d’usage ? Est-ce que j’ai besoin d’une solution scalable ? À quel point ? etc.).  

Exemple de l’utilisation de PARCS : scenario Kerberoasting « Voler ou falsifier des tickets Kerberos » 

Le plus parlant est surement d’illustrer la présentation de la matrice PARCS avec un exemple exposé dans l’article « HoneyWISE ». 

L’attaque de l’AD appelée Kerberoasting est, « […] en synthèse, le brute force offline (pas d’échec de logon) d’un ticket Kerberos recevant le secret d’un compte de service, sans devoir envoyer un seul paquet à ce service ni même être administrateur local du poste compromis ». 

Le « […] Kerberoasting détourne le fonctionnement natif de Kerberos afin de réaliser une attaque. Ce détournement se fait sur les étapes 3 et 4 de l’authentification Kerberos présentées par le schéma suivant : » 

Pour ce cas d’attaque, Augustin TOURNYOL-DU-CLOS et Nathan FAEDDA proposent dans leur article de déployer un honeytoken contre le Kerberoasting (voir partie 2.3 « Description des scénarios de détection » – scénario 2). 

Voici le résultat, à travers PARCS, de l’étude de ce type d’honeytoken dans le cadre d’un scénario de Kerberoasting (16/20) : 

• Pertinence : 4/4 
  • « Les alertes générées par ce honeytoken sont fiables. En effet, à partir du moment où un ticket TGS est demandé pour accéder à service non-utilisé et inexistant, il apparait clairement qu’une action malveillante est en cours. » 
• Attractivité : 3/4 
  • « L’attractivité de ce token repose dans le fait que la réalisation de l’attaque ne nécessite pas de privilèges et permet potentiellement d’en gagner tout en étant silencieuse (génération de trafic jugé légitime). Sous réserve que le compte choisi pour leurrer l’attaquant paraisse privilégié et géré par un utilisateur (afin que le mot de passe soit vraisemblablement simple) ce honeytoken est donc fortement attractif. » 
• Risque : 4/4 
  • « Dans notre exemple un mot de passe de 64 caractères a été défini ce qui n’est pas cassable dans un temps raisonnable. » 
• Crédibilité : 3/4 
  • « Sous réserve du choix du nom et des attributs du compte en fonction du contexte de production dans lequel il est déployé, l’attaque se basant sur un fonctionnement normal de Kerberos, il ne sera pas étonnant de pouvoir la réaliser. La crédibilité est donc forte. » 
• Scalabilité : 2/4 
  • « Le déploiement du compte de leurrage peut se faire automatiquement sur plusieurs domaines grâce à des scripts. Néanmoins pour un leurre efficace, la contextualisation reste primordiale et constituera l’obstacle majeur à un déploiement de masse efficace. Il faudra donc prendre en compte le coût d’apporter cette contextualisation et de la maintenir à jour. » 

Pour conclure, les solutions de Deceptive Security sont à étudier au cas par cas. Il est impératif d’avoir déterminé au préalable les objectifs à prioriser, la stratégie à adopter, le périmètre concerné etc. 

Dans certains cas d’usage, surtout pour les entreprises ayant une sécurité informatique déjà mature, il est pertinent de mettre en place des solutions du type Deceptive Security. Ceci est à appliquer en complément d’outils de sécurité standards minimums tels que les firewalls, les antivirus, les systèmes de détection et/ou de prévention d’intrusion,… L’objectif étant de couvrir tous les types de cyberattaques (type « 0-day », sans pattern connu).  

Cette technologie peut être difficile à mettre en œuvre pour les entreprises de petite taille car elles n’ont pas forcément les outils de sécurité essentiels mis en place par défaut et ne disposent pas des ressources nécessaires pour configurer (ex : designer les leurres, créer les stratégies et scénarios) et maintenir une telle solution (ex : équipes de maintenance dédiées). 

Aujourd’hui, le marché est en expansion, principalement sur les sujets de détection grâce à la Deceptive, mais pas uniquement. L’intérêt des éditeurs à construire des solutions de Deceptive est cependant centré, pour le moment, sur les environnements traditionnels. Les solutions pour le Cloud AWS, Azure, etc., sont encore peu développées.   

Merci à Augustin TOURNYOL DU CLOS pour sa contribution à cet article.

Cet article Deceptive Security : la solution pour une détection efficace dans le Cloud ? – Stratégie de leurrage est apparu en premier sur RiskInsight.

J’ai eu l’occasion d’organiser pour les Assises de la Sécurité de 2022 une table ronde sur le confidential computing animée par Thierry AUGER CISO & Corporate CIO de Lagardère et regroupant Mathieu Jeandron d’AWS, Thiébaut Meyer de Google Cloud, Arnaud Jumelet de Microsoft France et Julien Levrard d’OVHCloud. Cet article vise à faire une synthèse des éléments échangées en présentant des cas d’usage, la technologie et les premiers pas y aller.

Le confidential computing pour quels besoins ?

Le principe du confidential computing est de créer une enclave garantissant que seul le traitement s’exécutant dans l’enclave peut accéder en clair aux données. Avant de rentrer dans l’explication de la technologie, nous allons voir 4 cas d’usage où le confidential computing peut améliorer la Cybersécurité.

Multi-party confidential data analytics

Plusieurs acteurs souhaitent mettre en commun des données mais aucune des parties ne doit pouvoir accéder aux données des autres. La mise en œuvre d’une enclave de confidential computing va permettre d’assurer cette exigence, seule l’encave étant en mesure d’accéder aux données mises à disposition par chaque acteur.

Exemple : plusieurs banques souhaitent mutualiser leur effort pour construire un algorithme de détection des fraudes. Aucune des banques ne souhaite que les données des clients qui serviront à cette analyse  puissent être connues des autres.

Apprentissage d’IA fédérée.

Plusieurs acteurs souhaitent mettre en commun leurs données pour entrainer un algorithme d’Intelligence Artificielle. Les données ne doivent pas pouvoir être divulguées ou connues d’un autre acteur. L’enclave confidential computing va garantir que seul l’algorithme d’Intelligence Artificielle puisse accéder aux données.

Exemple : plusieurs hôpitaux souhaitent entrainer un modèle d’IA visant à aider au diagnostic médical permettant d’avoir un volume plus significatif. Le secret médical impose qu’en aucun cas, les données d’un patient ne puissent être accédées par un autre acteur.

Protection des calculs dans le edge computing

La sécurité physique des traitements réalisés dans le edge computing ne peut pas être garantie au même niveau qu’un datacenter. On souhaite cependant que le code embarqué et les données traitées ne puissent être accédés ou modifiés. L’enclave confidential computing va permettre d’apporter cette garantie.

Exemple : un fournisseur de solution IOT veut s’assurer que le code embarqué dans son objet de puisse être accédé pour garantir sa propriété intellectuelle.

Enfin le cas d’usage de plus souvent cité : la protection vis-à-vis de son fournisseur d’infrastructure

Ici, il s’agit de garantir que les administrateurs de l’infrastructure sur laquelle je vais réaliser mes traitements ne puissent accéder à mes données. Satya Nadella CEO de Microsoft a lui-même indiqué, lors de la Microsoft Build de mai 2022, qu’il considère le confidential computing comme un “game-changer ».

Exemple : un fournisseur de services Cloud ne doit pas pouvoir accéder aux données qui sont traitées sur son infrastructure . Aujourd’hui, les mécanismes d’isolation logique existants ou des mesures de sécurité mises en œuvre permettant de limiter les actions possibles des administrateurs, le confidential computing ajoute une garantie supplémentaire basée sur le matériel. L’enclave permet également de renforcer le niveau de sécurité vis-à-vis d’un accès malveillant par une autre machine virtuelle s’exécutant sur le même hyperviseur en cas de vulnérabilité sur celui-ci.

Les promesses semblent intéressantes, comment fonctionne le confidential computing?

Le confidential computing vise à réaliser le traitement dans une enclave accessible seulement par le processeur : cette propriété est garantie matériellement par le processeur et son firmware ^(*). Un canal sécurisé est créé entre l’enclave et le processeur, tous les composants sur le chemin (Hyperviseur, OS…) ne pouvant accéder à la donnée.
^(*)’L’implémentation technique de l’enclave varie suivant les fondeurs de processeur (Intel, AMD, ARM, IBM…) nous nous y attarderons pas dans cette article.

Deux grands types d’enclave sont possibles :

• Enclave au niveau de la machine ou du conteneur: tous les traitements réalisés dans la machine virtuelle ou le conteneur seront protégés
• Enclave au niveau d’une application : seul un morceau de l’application sera protégé par l’enclave (par exemple le code réalisant des traitements sensibles : les données brutes n’étant jamais accessibles, seuls les résultats l’étant)

Lors de la table ronde, Arnaud Jumelet a présenté une analogie avec un immeuble :

Une enclave au niveau d’une VM ou d’un conteneur peut être comparée à une protection qu’apporterait un appartement via à vis du reste du bâtiment : seules les personnes disposant des clés peuvent y accéder.

Dans le cas d’une enclave au niveau d’une application ou du code, on peut le comparer à un coffre-fort au sein de l’appartement qui protègerait le traitement.

Dans le 1^er cas, le gestionnaire de l’immeuble (ie la gestion de l’infrastructure SI) n’a pas la vision de ce qu’il se passe dans l’appartement, alors que dans le 2^ème cas même les personnes ayant la clé de l’appartement (ie l’administrateur de la VM) n’ont pas la vision sur ce qu’il se passe dans le coffre-fort.

Tout cela semble magique, est-ce que cela couvre tous mes risques ?

Le confidential computing est une nouvelle boite à outil pour réduire les risques. Mathieu Jeandron nous met en garde, il ne faut pas l’opposer aux mesures existantes : il s’agit d’ajouter une garantie supplémentaire par le matériel à l’isolation logique apportée par la virtualisation.

Comme tout outil, il peut avoir ses propres failles de sécurité comme par exemple des attaques par canal latéral ( ou Side-channel attacks) telle la vulnérbilités SQUIP ou des attaques affectant d’autres fonctions du processerus (comme l’attaque ). Il s’agit cependant d’attaques nécessitant un niveau élevé d’expertise. Thiébaut Meyer indiquait, lors de la table ronde, que la désactivation de l’hyperthreading permet de limiter les risques associés à ces vulnérabilités. Il est également important que l’enclave à son démarrage vérifie qu’elle s’exécute bien dans un espace de confiance : challenge du processus, vérification de la version du firmware du processeur par exemple.

Mathieu Jeandron est pour sa part revenu sur la nécessite de comprendre que le confidential computing ne va pas traiter tous mes risques :

• Dans le cadre d’une enclave au niveau d’un VM, l’administrateur de la VM y aura toujours accès
• Une vulnérabilité sur le code s’exécutant dans une enclave pourra toujours être exploitée par un attaquant pour accéder à la donnée
• La compromission de la supply chain produisant les processeurs est toujours envisageable…

La mise en œuvre d’enclave peut rendre aveugle certain mécanisme de détection Cybersécurité qui sont à l’extérieur : attention ce que l’on d’un côté peut être perdu de l’autre !

Il est donc nécessaire de bien comprendre la technologie et les risques associés pour définir une stratégie réfléchie d’usage.

La protection des données, une histoire de gestion de clés

Quand l’on parle de protection de données, le chiffrement n’est jamais très loin. Et qui dit chiffrement, dit outils de génération et stockage de clés. Julien Levrard nous a rappelé que la protection apportée par l’enclave n’est qu’une partie problème, alors qu’il faut le voir dans sa globalité.

En particulier, les données devant être traitées ou même le code s’exécutant dans l’enclave proviennent de l’extérieur de l’enclave. Il est donc nécessaire qu’ils soient chiffés et que seule l’enclave puisse accéder aux clés permettant de déchiffrer les données. Les clés devront être donc séquestrées dans un HSM ou KMS qui devra s’assurer avant de libérer les clés qu’il s’agit bien de la bonne enclave qui lui demande d’y accéder. Le client aura le choix d’utiliser des services de son fournisseur ou d’implémenter des mécanismes de BYOK ou HYOK.

Je vois une opportunité, n’est-ce pas trop compliqué d’y aller?

La majorité des initiatives confidential computing en France sont aujourd’hui au stade de POC. Il existe cependant déjà des cas d’usage en production : la messagerie SIGNAL utilise par exemple le confidential computing pour protéger les messages. Thiébaut Meyer indiquait même que des premiers ransomwares utilisent la technologie pour ne pas être détectés !

Si l’on souhaite tester, Julien Levrard a expliqué que les prérequis techniques ne sont pas compliqués à atteindre : il suffit de commander un serveur de nouvelle génération et d’activer la fonction dans le firmware ou de souscription à des ressources compatibles chez un cloud provider. On peut alors facilement déployer un OS ou un conteneur disposant des bons drivers dans une enclave. Pour les cas d’usage métier indiqués au début de l’article, il sera cependant nécessaire de refondre le code de l’application.

Pour faciliter l’adoption, le Confidential Computing Consortium, qui vise à promouvoir la technologie, met à disposition des accélérateurs. Arnaud Jumelet a par exemple mentionné le projet opensource OpenEnclave ou Enarx. Il existe également des acteurs construisent des solutions disponibles as a service comme Securitee, Cosmian ou bien Decentriq. De nombreux acteurs logiciels ont également ajoutés à la roadmap l’intégration de fonctionnalité de confidential computing, dans le futur il s’agira peut-être du fonctionnement par défaut !

Le confidential computing une technologie qui gagne en maturité

Nous avons pu le voir le confidential computing gagne en maturité et qu’il n’est pas nécessaire d’être expert en assembleur pour l’utiliser. C’est probablement le bon moment pour les entreprises ayant des cas d’usage de tester la technologie pour mieux l’appréhender et la comprendre avant de pouvoir décider d’un usage en production. Une inscription dans une roadmap sécurité a aujourd’hui tout son sens.

Cet article <em>Confidential computing</em> : révolution ou nouveau mirage ? est apparu en premier sur RiskInsight.

Figure 1 : Les trois principes fondamentaux du modèle Zero Trust

Ces principes sont aujourd’hui bien connus mais leur mise en œuvre concrète demeure un défi pour beaucoup d’organisations.

Il n’existe et n’existera pas de produit unique permettant d’implémenter un modèle Zero Trust. Les architectures d’implémentation sont par ailleurs multiples. Pour les accès utilisateurs, le Zero Trust peut être implémenté à l’aide de deux principaux modèles d’architecture (qui ne s’opposent pas et peuvent être complémentaires) :

• Un modèle utilisant un élément d’infrastructure en coupure, par exemple dans une approche de type Secure Access Service Edge (SASE). Il va contrôler dynamiquement l’accès réseau aux ressources du SI (l’identité et la posture de l’utilisateur étant bien évidemment utilisées pour prendre la décision).
• Une approche où seul l’identité est utilisée pour faire la coupure : l’accès aux ressources du SI est conditionné par la présentation de preuves d’authentification et d’autorisation. Dans cette approche, le contrôle d’accès est réalisé par un Identity provider (gestionnaire d’identité ou IdP) et par les ressources cibles elles-mêmes.

C’est ce deuxième type d’architecture qui fera l’objet de cet article. Nous nous intéresserons en particulier à une implémentation utilisant Azure Active Directory (AAD) comme Identity Provider.

Avant de comprendre comment l’Identity Provider peut permettre d’implémenter le Zéro Trust, un peu de théorie sur les mécanismes de la gestion des accès basée sur des jetons.

La gestion des accès basée sur AAD : une histoire de jetons

La gestion des accès basée sur AAD reprend les principes du schéma d’accès faisant intervenir un Identity Provider, à savoir un service auquel la ressource cible délègue la gestion du cycle de vie des identités des utilisateurs et leur authentification.

Dans ce schéma, l’accès d’un utilisateur à une ressource nécessite la présentation d’un laisser-passer valide délivré par l’Identity Provider après authentification de l’utilisateur et (potentiellement) vérification de son habilitation à accéder à la ressource cible. Ces laisser-passer sont appelés jetons ou tokens et sont signés cryptographiquement pour se prémunir de l’utilisation de faux jetons.

Au fait, un Token c’est quoi ? C’est une chaine de caractères contenant diverses informations que l’on appelle des clauses, et qui se transmet par exemple par requête HTTPs.

AAD, en tant que fournisseur d’identité, délivre trois types de jetons appelés Security Tokens :

ID Token: Preuve de l’authentification de l’utilisateur. Il contient des informations sur l’identité de l’utilisateur et sur le contexte d’authentification. Il n’est associé à aucune ressource en particulier et n’intervient pas dans le contrôle d’accès.

Access Token: Laisser-passer autorisant l’accès à une ressource en particulier. Il peut contenir des attributs ou claims permettant à la ressource cible d’affiner le contrôle d’accès. Dans le cas d’Azure AD, il s’agit de jeton autoporteur^(*) (JWT) : donc non révocable après émission. Sa durée de vie est d’une heure en moyenne. Autrement dit, un Access Token est valide tant que sa durée de vie n’a pas expirée.
^(*)une autre implémentation d’OAuth aurait pu être avec des jetons opaques nécessitant d’interroger l’Authorization server pour connaitre le détail. Ce type d’implémentation permettant une révocation plus facile. Ce n’est pas le choix fait par Microsoft.

Refresh Token: jeton fourni en même temps que l’Access Token, Il permet d’obtenir une nouvelle paire Access Token/Refresh Token après expiration de l’Access Token précédent, sans réauthentification explicite de l’utilisateur. Il permet également de récupérer des Access Tokens pour d’autres ressources sans authentification explicite de l’utilisateur. Dans le cadre d’Azure AD, sa une durée de vie est de 90j ou 24h pour les Single Page Applications et contrairement à l’acces Token, il est possible de le révoquer avant son expiration.

A noter que Microsoft a défini un quatrième type de jeton, le Primary Refresh Token, permettant de faire du Single Sign-On entre applications sur un device donné. Ce jeton ne sera pas évoqué dans la suite du document par souci de simplification.

A présent, il nous reste à comprendre comment ces différents Tokens circulent d’acteur en acteur !

Accès initial à la ressource cible

Lors de l’accès initial, nous supposons qu’il n’y aucun jeton en cours de validité : pas d’Access Token pour la ressource cible ni de Refresh Token. Quand l’utilisateur voudra accéder à la ressource cible, il sera redirigé vers AAD pour être authentifié (et éventuellement autorisé).

Figure 2 : Cinématique d’obtention d’une paire Access Token/Refresh Token lors de l’accès initial à la ressource

L’Access Token obtenu sera inclus dans chacune des requêtes destinées à la ressource cible. Celle-ci les traitera tant que l’Access Token n’aura pas expiré.

Renouvellement du droit d’accès à la ressource

Après expiration de l’Access Token initial, le Refresh Token sera utilisé pour récupérer silencieusement, sans intervention de l’utilisateur, une nouvelle paire Access Token/Refresh Token

Figure 3 : Cinématique de maintien de la session d’accès via le renouvellement de la paire Access Token/Refresh Token

Dans un modèle de gestion des accès faisant intervenir un Identity Provider comme AAD, nous constatons que les jetons sont les clés du château et l’Identity Provider en est le gardien.

Regardons à présent dans quelle mesure ce modèle de gestion des accès permet d’implémenter les principes du Zero Trust pour les applications qui s’appuient sur AAD pour gérer leur sessions de connexion.

Les jetons : des supports de confiance implicite vulnérables

En examinant le fonctionnement de la gestion des accès basée sur Azure AD, nous constatons que :

• L’accès à toute ressource déléguant la gestion des accès nécessite une preuve d’authentification et d’autorisation, à travers la présentation d’un Access Token valide, et ce indépendamment de l’origine réseau de l’accès.
• Un Access Token ne donne accès qu’à une seule ressource. L’accès à une ressource différente nécessite l’obtention d’un Access Token dédié auprès de l’Identity Provider
• Le Refresh Token permet d’obtenir des Access Tokens pour toutes les ressources auxquelles l’utilisateur est autorisé

L’application des principes du Zero Trust est à ce stade partielle et perfectible :

• Par défaut, la délivrance de l’Access Token se fait contre une authentification basique (login et mot de passe)
• La validité de l’Access Token est décorrélé du contexte. Il est utilisable pendant sa période de validité indépendamment des signaux de compromission potentiels détectés
• L’Access Token peut être renouvelé sans vérification que le contexte d’authentification n’ait pas changé

Le Conditional Access (CA) renforce les conditions de délivrance des Tokens et la sécurité de la session

Le Conditional Access (CA) est une fonction d’AAD nécessitant une licence AAD Premium P1 ou M365 Business Premium permettant la prise en compte du contexte dans la gestion des accès.

Grâce au CA, il est possible d’intégrer dans la décision d’autorisation d’un accès un ensemble de signaux liés à l’identité de l’utilisateur, au terminal utilisé, à la ressource cible, au contexte d’accès et/ou au niveau de risque.

Le CA permet par ailleurs d’appliquer des décisions d’autorisation non binaires. Ainsi un accès réalisé dans un certain contexte peut être autorisé sous conditions, celles-ci visant à compenser et réduire le niveau de risque associé au contexte d’accès. 

Figure 4 : Principe de fonctionnement du Conditional Access

La délivrance d’un Access Token peut ainsi être conditionnée par une authentification renforcée à double facteur, ce qui aide à se prémunir d’un accès non autorisé découlant d’un vol d’identifiants.

Le CA propose d’autres mécanismes permettant de conditionner l’utilisation des jetons. Nous nous intéresserons ici à deux mécanismes en particulier : la Sign-In Frequency (SIF) et le Continuous Access Evaluation (CAE).

La Sign-In Frequency : moyen d’action sur la fréquence d’authentification explicite de l’utilisateur

La Sign-In Frequency permet de définir une durée maximale au-delà de laquelle l’utilisateur doit explicitement se réauthentifier après avoir été initialement autorisé à accéder à la ressource cible.

Au-delà de cette durée, le Refresh Token ne peut pas être utilisé pour renouveler implicitement la paire Access Token/Refresh Token.

La SIF est ainsi un moyen de limiter dans le temps la confiance implicite accordée aux Refresh Tokens.

Le fonctionnement du mécanisme est illustré ci-dessous, pour une SIF définie à 90 minutes.

Figure 5 : Illustration du fonctionnement de la Sign-in Frequency

On notera que la SIF n’a aucun effet sur la validité des Access Tokens déjà émis. Un Access Token qui n’a pas encore expiré pourra toujours être utilisé pour accéder à la ressource associée, même après expiration de la durée maximale définie par la SIF. La SIF n’intervient en effet que pour empêcher un renouvellement implicite des Access Tokens déjà émis ou l’obtention implicite de nouveaux Access Tokens. Pour pouvoir agir sur les Access Tokens déjà émis, il faut se tourner vers le Continuous Access Evaluation (CAE).

Le Continuous Access Evaluation (CAE), un moyen de lier la validité des Access Tokens au contexte

Le CAE est une fonctionnalité du CA disponible depuis janvier 2022 qui permet la prise en compte du contexte tout au long de la session d’accès et pas seulement au moment de l’autorisation initiale, de sorte à pouvoir forcer un renouvellement de l’Access Token déjà émis en réponse à certains signaux, notamment des signaux suggérant une compromission.

Figure 6 : Types de signaux pouvant forcer le renouvellement de l’Access Token

Pour ce faire, le CAE nécessite un lien de communication entre AAD et la ressource cible permettant de notifier à celle-ci les signaux nécessitant une réauthentification et de récupérer les politiques d’accès conditionnel définies la concernant. Quand la ressource cible reçoit une requête d’accès, elle vérifie si elle n’a pas préalablement reçu une notification à propos de l’utilisateur concerné et/ou si le contexte d’accès est différent de celui autorisé par les politiques d’accès conditionnel. Le cas échéant, elle rejette la requête d’accès et renvoie l’utilisateur vers AAD avec un challenge pour une réauthentification explicite et une réévaluation des politiques d’accès applicables.

On notera que le CAE n’est pas un mécanisme transparent pour les ressources cibles et que sa mise en œuvre nécessite des modifications dans leur logique de fonctionnement. La mise en œuvre du CAE nécessite une application cliente compatible (CAE-capable client) capable d’interpréter le challenge renvoyé par la ressource cible et de rediriger l’utilisateur vers AAD. Microsoft a pour sa part commencé à implémenter pour les applications de sa suite collaborative M365.

En synthèse

Il est aujourd’hui possible d’implémenter une philosophie Zéro Trust access basée sur l’identité mais pour éviter de tomber dans les travers des modèles de sécurité historiques, il convient de durcir les conditions de délivrance et d’utilisation de ces jetons, sous peine d’en faire les supports d’une confiance implicite et excessive.

L’usage de mécanismes permettant d’intégrer de signaux permettant d’évaluer le contexte de la connexion et d’avoir un contrôle continu sur les jetons délivrés est nécessaire.

Il faut cependant garder en tête que, face au scénario de vol de jetons, ces mécanismes jouent un rôle réactif dépendant des capacités de détection, et non préventif capable d’empêcher l’utilisation de jetons volés. Nous aurons l’occasion de revenir plus en détails dans un prochain article sur la problématique de vol de jetons et sur les différentes solutions existantes et émergentes permettant d’y faire face. 

Cet article Le Zero Trust et l’identité comme nouveau périmètre : faut-il avoir les jetons ? est apparu en premier sur RiskInsight.

Les erreurs de configuration dans les environnements Cloud sont encore source d’incidents majeurs et ce n’est pas près de s’arrêter. L’actualité regorge d’exemples : fuite de 1 milliard de donnés de citoyens lié à une fuite de clé,  campagne de phishing utilisant une clés AWS de Kaspersky, mauvaise configuration d’une base de données NoSQL, 3TB de données sensibles des aéroports…

L’objectif de cet article est de voir comment anticiper un tel scénario en mettant en œuvre une Tour de contrôle (ou outil de supervision continue de la configuration des ressources Cloud).

Avant toute chose, un peu de théorie sur les logs

Les logs cloud peuvent être répartis en 3 catégories :

• System logs: Ils sont générés par les OS et les applications hébergées en mode IaaS/CaaS. Les enjeux ne sont pas différents d’un SI classique on premise, seule l’architecture de collecte de logs peut être à adapter.

• Security infrastructure admin logs : Il s’agit des logs des appliances de sécurité mais également des services PaaS de sécurité utilisés par le client et des logs des flux réseaux. Pour les appliances, là encore rien de bien nouveau, il s’agit du même composant déjà utilisé et bien connu. En revanche pour les services PaaS de sécurité et les logs réseaux, il est nécessaire de mettre en œuvre une intégration spécifique et d’adapter les scénarios de détection.

• Cloud Infra API logs : Lors de chaque call API pour créer, modifier ou supprimer une ressource, le Cloud Service Provider va générer un log.

Ces logs sont accessibles dans des services managés dédiés tels que AWS CloudTrail, AWS config ou Azure activity log

Le délai de mise à disposition va dépendre du SLA du CSP, les logs sont généralement disponibles de quelques minutes à 15 minutes après réalisation de l’opération.

Exploiter ces logs va permettre de passer d’une conformité manuelle et statique à une conformité automatique et continue :

Quelles options techniques pour construire une Tour de contrôle ?

Trois grandes options s’offrent à un client qui souhaiterait mettre en œuvre une tour de contrôle :

• Natif intégré (built-in)
• Natif personnalisé (custom)
• Cloud Security Posture Management (CSPM)

Natif intégré (built-in)

Dans ce premier cas, les outils activés par défaut par le Cloud Service Provider, parfois gratuitement, utilisant des alertes prédéfinies pour évaluer la conformité de vos environnements et délivrer un score de sécurité sont utilisés.

Par exemple Trusted Advisor sur AWS ou Microsoft Defender for Cloud sur Azure.

Ces solutions natives et non-personnalisées permettent d’initier une tour de contrôle, mais elles sont cependant rapidement limitées : il s’agit d’une réponse générique à des problématiques spécifiques.

Natif personnalisés (custom)

Les fournisseurs Cloud mettent à disposition de nombreux services permettant aux clients de construire un outil de vérification de la conformité de leur infrastructure : les outils du CSP disponibles sont personnalisés pour créer des alertes de conformité spécifiques et des tableaux de bord/KPIs personnalisés.

Dans cette option, il est nécessaire de prévoir un projet de 10 à 40 jours hommes pour mettre en œuvre l’infrastructure de supervision, définir les 1^ères alertes et construire les tableaux de bords.

L’usage de plusieurs tenants, organisations ou Cloud nécessitera de définir une architecture spécifique car il n’existe pas de solution clé en main.

CSPM : Cloud Security Posture Management

Wavestone voit un marché en plein essor. Marketsandmarkets estime que le marché devrait plus que doubler entre 2022 et 2027 en passant de 4,2 milliards de $ à 8,6 milliards de $.

Les CSPM supportent nativement de nombreux Cloud providers et mettent à disposition de leurs clients de nombreux tableaux de bord basés sur les grands référentiels du marché. Le client pourra également définir facilement ses propres standards, politiques et alertes.

Le déploiement de ce type d’outil est très simple, nécessitant que quelques jours hommes.

Les coûts récurrents pourront cependant être significatifs : généralement 3 à 5% de la facture Cloud en plus des services du Cloud à activer (similaire à l’option des services natifs et personnalisés).

La vitesse de détection sera également un peu moins rapide car le SLA du CSPM s’additionne à celui de génération des logs de CSP, généralement un délai de détection de 20 minutes à 1 heure.

Que doit superviser ma Tour de Contrôle ?

Le problème majeur que rencontrent les clients lors de la mise en œuvre d’un CSPM avec l’activation d’alertes proposées est la génération de dizaines voire de centaines de milliers d’alertes de criticité haute à traiter. Les équipes ne savent pas par quoi commencer et c’est bien souvent le découragement qui l’emporte. Il faut faire attention à ne pas surcharger les équipes de sécurité !

Pour la mise en œuvre d’une tour de contrôle sur un SI Cloud de production, nous recommandons de déployer les contrôles de sécurité par vague de 10 à 15 à la fois. Pour cela, il faut prioriser les sujets les plus importants. Ci-dessous un exemple de priorisation :

Malheureusement, à toute règle ses exceptions ! Elles sont principalement liées à l’existant Cloud, à des architectures spécifiques ou des contraintes techniques. Il est donc primordial dès la conception de prévoir ce cas de figure et la gouvernance associée :

• Validation : par le RSSI local et/ou le RSSI global
• Expiration
• Revue : décentralisée (localement ou lors d’audits globaux annuels) ou centralisée (par un suivi continu global)

L’utilisation de tag pour les ressources Cloud est la solution la plus simple à ce jour pour le faire – attention toutefois, certaines ressources peuvent ne pas être compatibles comme les services IAM.

Quel que soit le modèle choisi, les sujets à traiter restent principalement les mêmes :

• Garantir l’utilisation et l’application légitime des exceptions
• Définir des indicateurs spécifiques sur des exceptions pour les sujets à risques du Top Management
• Mettre en place des campagnes régulières de suivi des exceptions
• Alerter et traiter lorsqu’une exception expire

Comment mettre en œuvre un processus de remédiation efficace ?

La mise en œuvre d’une tour de contrôle va générer de nombreuses alertes, qu’il va falloir corriger. Trois options sont possibles : bloquer, remédier automatique ou manuellement

Refus (Mode deny)

Pourquoi remédier alors qu’il suffit de bloquer préventivement les ressources non-conformes ?

Avec des Azure Policy ou des AWS SCP, il est possible nativement de bloquer certaines configurations et ainsi éviter la génération de nouvelles alertes.

Pour les cas d’usage non couverts, il est possible de mettre en place des vérifications des templates de déploiement dans les chaines CI/CD (cela nécessite néanmoins une forte maturité).

Déployer un mécanisme de refus – ou deny – sur des environnements existants est rarement implémenté car le risque de générer des mécontentements des équipes de développement est trop fort :

• Les ressources existantes non conformes ne peuvent plus être modifiées
• Cela va générer une charge supplémentaire aux équipes de développement car les habitudes doivent être changées
• …

Remédiation automatique

Ici, il s’agit de corriger directement et automatiquement les configurations déviantes : attention aux effets de bord !

Pour se faire, il est possible d’utiliser les services natifs des cloud provider (Azure policy ou AWS SSM Manager) ou pour des cas non supportés de développer des fonctions (AWS Lambda, Azure Function ou Azure LogicApps).

Manuel

Il s’agit malheureusement de la solution la plus rencontrée mais aussi la plus coûteuse en ressources humaines. Les configurations déviantes sont remédiées à la main par les équipes.

Pour garantir le succès d’une remédiation manuelle, il est nécessaire d’avoir un appui fort du top management pour assurer l’adhésion et la motivation des équipes.

La mise en œuvre d’un tableau de bord de type Cloud OWSAP mettant en lumière les priorités du moment est une bonne solution, permettant de responsabiliser chacun sur son périmètre. Chaque sujet mentionné ci-contre pouvant avoir un ou plusieurs indicateurs.

Avoir l’appui du management n’est cependant pas suffisant, il est nécessaire de connaitre le responsable de la ressource pour lui demander de faire les modifications. Dans un grand groupe international ce n’est pas chose aisée. Notre recommandation est de nommer à minima un security officer par compte/souscription qui devra avoir la connaissance fine des applications et des responsables des ressources.

En parallèle, il est nécessaire de mettre en œuvre un programme de formation et de sensibilisation efficace. Si l’on veut minimiser le nombre d’alertes et éviter de remplir plus vite la baignoire qu’elle se vide, les équipes de développement doivent connaitre et maitriser parfaitement les exigences sécurité à respecter dans le Cloud.

Pour commencer le processus de remédiation, notre conseil est de démarrer de manière centralisée avec une équipe compétente et bien dimensionnée en charge de la mise en œuvre de la tour de contrôle, mais également en charge de mobiliser et former des relais locaux, permettant à terme aux équipes locales de suivre et gérer de façon autonome la conformité sur leur périmètre.

Alerte de conformité ou alerte de sécurité ?

La majorité des entreprises considère la supervision de la conformité de leurs ressources Cloud comme n’étant pas une responsabilité des équipes SOC. Mais la frontière n’est pas si simple à définir, d’autant plus au vu du nombre d’incidents de sécurité dans le Cloud provenant d’erreurs de configuration : exposition publique d’une ressource de stockage contenant des données critiques, MFA non-configuré sur un compte admin ou encore RDP ou SSH exposés sur internet.

La génération d’une alerte de sécurité au SOC permet de tirer parti des processus et outillages déjà en place, pour un traitement 24h sur 24, 7 jours sur 7 même si les ressources SOC ne sont pas expertes Cloud.

Et finalement, cela sera une bonne occasion de rapprocher les sécurités Cloud et les équipes SOC pour améliorer les supervisions sécurité en l’adaptant à la réalité du cloud. Ce sujet pourra faire l’objet d’un article dédié.

Cet article Conformité dans le Cloud, un nouveau paradigme est apparu en premier sur RiskInsight.

Par manque de ressources internes ou d’expertise, il est encore fréquent d’observer des erreurs de configuration, comme un Storage Account ou bucket S3 déployé publiquement, permettant aux attaquants d’y accéder et d’exfiltrer les données, ou encore des Network Security Group qui n’ont pas été correctement configurés pour restreindre les flux, permettant alors aux attaquants de compromettre le compte cloud grâce à l’exploitation de flux non contrôlés.

Ces erreurs de configuration créent de nouvelles surfaces d’exposition et offrent aux attaquants de nouveaux moyens de compromettre les SI.

Assurer un usage sécurisé et contrôlé des services cloud est un enjeu majeur, qui nécessite des compétences spécifiques et une gouvernance adaptée.

La gestion de la posture de sécurité cloud : qu’est-ce que c’est ?

La gestion de la posture de sécurité cloud est un ensemble de stratégies et d’outils visant à réduire les risques de sécurité liés à l’usage du cloud. Cet objectif est assuré par la mise en place de contrôles sur la configuration des ressources ainsi que des mécanismes permettant de réagir en cas de détection d’un écart par rapport aux bonnes pratiques.

On distingue 4 piliers principaux dans la gestion de la posture de sécurité cloud :

Une des premières étapes de la gestion de posture de sécurité cloud est la prise de connaissance de l’environnement dans sa globalité ; inventaire et classification des ressources, indicateurs de conformité, dashboards de visualisation des risques… Cette vue d’ensemble permet d’identifier la surface exposée de son environnement et de prioriser les chantiers à mener.

Une gestion de la posture de sécurité cloud efficace repose sur un certain nombre d’outils permettant de détecter automatiquement les configurations de ressources non conformes aux bonnes pratiques de sécurité. La plupart des outils permettent notamment de s’évaluer vis-à-vis de standards et normes (CIS, RGPD, HIPAA, …) et ainsi d’identifier les écarts entre l’environnement actuel et la cible à atteindre. En plus des règles de sécurité génériques proposées par les outils, les entreprises peuvent également intégrer des règles propres à leur contexte afin d’affiner les contrôles effectués et ainsi construire leur propre référentiel de sécurité.

Les environnements Cloud offrent des capacités d’industrialisation et d’automatisation avancées permettant le déploiement rapide de nouvelles solutions afin de réduire le Time to market , le temps nécessaire pour concrétiser une idée et livrer un produit fini aux consommateurs. Dans ce contexte d’évolution rapide il est nécessaire d’assurer une surveillance continue de son environnement afin d’être en mesure de réagir au plus vite lors du déploiement d’une ressource non conforme : mise en quarantaine de la ressource, remédiation automatique, etc.

Un des enjeux de la sécurité est de réussir à l’intégrer au plus tôt dans le cycle projet afin de limiter les impacts de la mauvaise configuration d’une ressource. Dans le cadre de la gestion de la posture de sécurité, il est possible d’intégrer des contrôles de conformité dès la phase de développement, avec l’intégration dans les chaines CI/CD d’analyses de templates Terraform ou Cloudformation par exemple. Notons que cette étape nécessite une maturité avancée et de maitriser les 3 autres piliers cités plus haut.

Focus outils CSPM : quel type d’outil pour quel cas d’usage ?

Les outils CSPM (Cloud Security Posture Management) sont une gamme de logiciels permettant d’assister les entreprises dans la gestion de posture de sécurité cloud. Il en existe de nombreux sur le marché, que nous distinguerons par la suite en 3 grandes catégories : outils d’éditeurs du marché (ex : Prisma Cloud, Cloud Conformity, Cloud Health, CloudGuard, Zscaler, Aquasec…), outils natifs des cloud providers (ex : Microsoft Defender for Cloud & Azure policy, AWS config…) et outils open source (ex : Cloud Custodian, ScoutSuite…).

Bien que ces outils aient un objectif commun, on observe de nombreuses différences dont il convient d’étudier les impacts afin de déterminer la solution la plus adapté au contexte local. Exemple de points d’attention lors de la sélection d’un outil CSPM :

Gouvernance et administration de l’outil :

Quels sont les moyens mis à disposition afin de faciliter la gestion de l’outil (ex : rôles disponibles et modèle RBAC, processus implémentés, interface de gestion, interconnexions possibles, etc.) ?

Couverture de l’outil :

L’outil est-il mono ou multicloud ? Quels sont les services pris en charge ? Quelles sont les règles de sécurité implémentées au sein de l’outil ?

Fonctionnalités de l’outil :

Quelles sont les capacités de tableau de bord ? Est-il possible de mettre en place des alertes ? Certains outils CSPM se spécialisent sur un ou plusieurs des piliers de la gestion de posture de sécurité cités plus haut, ou sont plus matures pour un fournisseur cloud que pour les autres. Il convient d’étudier les fonctionnalités offertes par chaque outil afin de vérifier qu’il couvre bien l’intégralité des cas d’usages souhaités.

Facilité de déploiement :

Comment l’outil est-il déployé ? Combien de temps cela prend-il ? L’outil est-il disponible en mode Saas ou nécessite-il la mise en place d’une architecture spécifique ?

Facilité d’utilisation :

Comment est l’interface utilisateur ? Ce critère est particulièrement important car certains outils, bien que très flexibles, demandent des compétences spécifiques (ex : développement de scripts) et peuvent demander une connaissance fine du sujet.

Support disponible :

Les standards de sécurité sont mis à jour automatiquement ? Les nouveaux services cloud sont implémentés combien de temps après leur mise sur le marché ? Le cloud est un environnement très évolutif, de nouveaux services sont régulièrement mis à disposition, impliquant de nouveaux risques de sécurité. La capacité d’un éditeur CSPM à s’adapter aux évolutions de ses clients en proposant de nouvelles règles et services supportés est donc un atout majeur

Tarification :

Quel est le modèle de tarification ? Doit-on payer par ressource ? Combien de personnes sont nécessaires pour l’administration de l’outil ? En fonction de l’outil choisi les prix peuvent varier largement. Une attention particulière doit être portée au choix d’une solution bien dimensionnée par rapports aux attentes exprimées.

En se basant sur ces critères il est possible d’observer de grandes tendances partagées par les outils de la même catégorie.

Pour résumer : les outils CSPM d’éditeurs du marché proposent de nombreuses fonctionnalités, déployables facilement mais peu personnalisables.

Quant aux outils CSPM natifs des fournisseurs cloud bénéficient d’une intégration aisée au sein de l’écosystème existant et de fonctionnalités propres au fournisseur cloud, ce qui ne permet pas toujours de couvrir l’ensemble des besoins.

Et finalement, les outils open source, ils ont l’avantage d’être très flexibles et de laisser à l’utilisateur une grande marge de manœuvre mais ces outils sont complexes à maintenir dans la durée et nécessitent des compétences spécifiques pour être déployés et utilisés.

Choisir le type d’outil le plus adapté nécessite donc d’identifier les enjeux propres à son contexte et d’étudier comment chaque type de solution y répond selon ses caractéristiques.

Voici quelques exemples de questions qu’une entreprise pourrait se poser dans le cadre de la sélection d’un outil CSPM : la maturité de l’entreprise en matière de gestion de posture de sécurité est-elle adaptée à l’usage actuel qu’elle fait du cloud ? Si non, le retard se situe-t-il dans l’outillage ou la définition des bonnes pratiques sécurité dans un référentiel groupe ? L’entreprise possède-t-elle les compétences internes permettant d’assurer que la gestion de la posture de sécurité évolue à la même vitesse que les besoins métiers d’usage du cloud ?

En effet, le choix d’un outil CSPM doit s’inscrire dans un processus plus global de gestion de la posture de sécurité, c’est-à-dire en s’appuyant sur les capacités de gouvernance et d’expertise locales de l’entreprise.

Industrialisation CSPM : les étapes clés

La mise en place d’une gestion de la posture de sécurité efficace est un long processus de plusieurs étapes. Toute entreprise souhaitant gagner en maturité sur le sujet doit définir une stratégie d’industrialisation permettant d’atteindre progressivement la cible. Le graphique suivant est un exemple de stratégie d’industrialisation :

Cela consiste dans un premier temps par la mise en conformité initiale des environnements cloud pour les sécuriser. Cette phase peut être assurée à l’aide des outils CSPM natifs cloud ou à l’aide d’un outil du marché. En effet, ces outils présentent l’avantage de fournir un cadre et des règles de sécurité génériques sur lesquelles une entreprise avec peu d’expérience en la matière pourra s’appuyer. Afin de capitaliser sur les retours de l’outil, une gouvernance et un plan d’actions devront être mis en place pour :

• Prioriser les chantiers identifiés
• Définir des indicateurs de suivi de mise en conformité (ex : pourcentage de conformité des ressources par service et/ou par criticité)
• Assurer l’accompagnement des projets dans la mise en conformité de leur environnement en leur fournissant les éléments nécessaires pour la remédiation des non-conformités

Une fois le niveau minimal de sécurité souhaité atteint (ou en parallèle de la mise en conformité initiale), un des enjeux suivants est d’assurer que les nouveaux projets cloud ne sont pas vecteurs de nouvelles vulnérabilités. Il convient alors de mettre en place une structure permettant d’accompagner les équipes de développement dans leurs projets cloud. Cette structure devra notamment permettre :

• Le maintien d’un référentiel de sécurité cloud groupe adapté au contexte de l’entreprise et évoluant au rythme des demandes de nouveaux usages métiers
• La mise en place de processus de validation sécurité (automatisés ou non) afin de valider les différentes étapes projets (éligibilité cloud, passage d’environnement de développement en production…)
• La veille sécurité autour des services cloud utilisés au sein de l’entreprise

Les deux premières étapes permettent de sécuriser l’existant et les évolutions futures. Les deux prochaines étapes ont quant à elles pour objectif d’ajouter une couche de validations et de contrôles supplémentaires dans le but de pérenniser l’usage des bonnes pratiques à l’échelle de l’organisation. Afin de mettre en place une surveillance continue généralisée, il est préférable de se concentrer initialement sur un périmètre test ; cette phase de test permet notamment de :

• Tester une nouvelle approche en matière d’infrastructure de contrôle. Sur le plan technique cela se traduit par la mise en place du/des outils CSPM nécessaires pour assurer à la fois des audits ponctuels sur un périmètre précis mais également une surveillance continue sur l’ensemble du périmètre test. Sur le plan organisationnel cela se traduit par la mise en place d’équipes spécialisées et de processus de validations.
• Définir des points de contrôle à l’échelle de l’organisation et les mécanismes permettant d’en assurer la pérennité : gestion du cycle de vie des règles de sécurité, définition des actions de remédiation par règle, etc.
• Préparer la mise à l’échelle de la surveillance continue.

En se basant sur les retours de la phase de test précédente, le périmètre de surveillance continue peut ensuite être élargi afin d’industrialiser la gestion de posture de sécurité cloud au sein de l’organisation.

La dernière étape correspond au dernier pilier de la gestion de posture de sécurité cloud, l’anticipation et donc à la mise en place de fonctionnalités avancées pour améliorer les pratiques existantes. La sécurité est intégrée en amont de la mise en production donc à gauche de ce cycle, ce qu’on appelle le « shift-left ».

Synthèse

Assurer la gestion de la posture de sécurité cloud au sein de son organisation est un enjeu majeur aux impacts forts nécessitant une mise en place progressive et incrémentale.

En s’appuyant sur les 4 piliers de la gestion de la posture de sécurité -Visualiser, Contrôler, Superviser, Anticiper- les entreprises sont en mesure d’assurer la conformité de son environnement cloud tout en suivant les besoins et évolutions du métier. Cet objectif nécessite une gouvernance dédiée et des outils adaptés au contexte local, le tout évoluant avec la maturité de l’entreprise en matière de sécurité du Cloud.

Les solutions CSPM disponibles sont nombreuses et chacune possède ses avantages et inconvénients, une attention particulière devra être portée à l’étude de la solution la plus adaptée aux besoins exprimés et aux futurs évolutions envisagées.

Cet article Gestion de la posture de sécurité cloud : vers une industrialisation de la maîtrise de son environnement cloud est apparu en premier sur RiskInsight.

Le projet de loi, créé à la base pour modifier un projet de loi de 1986, le «Stored Communication Act», permet aux États-Unis de forcer les fournisseurs de services américains  à transmettre les données de leurs clients stockées à l’étranger de manière beaucoup plus rapide. Il faut en moyenne dix mois pour obtenir les données, une durée improductive pour les enquêtes menées par les États-Unis. Le projet de loi vise à permettre aux autorités américaines (du shérif à la CIA) à accéder à des données hébergées par des entreprises américaines sans passage devant un juge. Les grandes entreprises technologiques, qui ont soutenu le projet de loi devant le Sénat, pourront s’opposer à une demande si :

• Le client ou l’abonné n’est pas américain ou ne réside pas aux États-Unis (section 3.2.b.h.2.i), et
• Le transfert obligerait le fournisseur à enfreindre les réglementations du pays hébergeant les données (section 3.2.b.h.2.ii)

Cette demande sera alors portée devant un tribunal américain qui pourra alors casser ou non la demande de transfert de données. Sa décision sera basée, entre autres, sur la validité des informations apportées, de l’intérêt de la requête pour les Etats-Unis et de l’envergure et les chances d’application de la violation de loi dans le pays étranger. Le caractère public du recours n’est pas précisé, en particulier la capacité des entreprises à communiquer sur ces contestations. Aujourd’hui, il nous parait probable que les grands acteurs américains utilisent ce recours pour garder la confiance de leurs clients.

Afin d’éviter d’enfreindre les réglementations des pays concernés, les États-Unis pourront passer des accords bilatéraux avec ces États, qui, en échange de leur bonne volonté, pourront accéder aux données sur le territoire américain.

Aux États-Unis, le CLOUD Act reste contesté pour les risques hérités par les potentiels accords avec les pays étrangers. Le fait que le pouvoir exécutif soit à même de mettre en place les accords mutuels inquiète la population américaine, qui craint que des puissances étrangères se servent du Cloud Act pour aller fouiller dans leurs données sans garde-fou.

Quelles conséquences pour les clients européens ?

Alors que les géants de la technologie (Facebook, Google, Microsoft, Apple) ont soutenu le projet de loi (les autorités américaines s’abstenant de les approcher pour un accès backdoor et fournissant un cadre clair pour exercer le transfert de données), ces réglementations peuvent être inquiétantes pour la privacy des clients des entreprises ciblés. Cette loi pourrait laisser les clients sans droit de regard, ni information sur l’accès à leurs données par les autorités américaines.

Cependant, les clients européens dont les données sont traitées en Europe pourraient être bientôt protégés par le Règlement Général sur la Protection des Données (RGPD). Les articles 45 et 48 du règlement qui entrera bientôt en vigueur définissent un ensemble de règles claires pour permettre le transfert vers des pays tiers. Selon Frank Jennings (avocat de renom sur les sujets cloud), l’European Data Protection Board, en charge de l’implémentation du RGPD, sera en charge de décider si les saisies dans le cadre du CLOUD Act constituent une mesure nécessaire à la sauvegarde de la sécurité nationale américaine, ou si la demande ne respecte pas la nouvelle réglementation.  Cela pourrait obliger les États-Unis à négocier avec l’UE ou ses États membres les conditions de tels transferts, et donc à protéger leurs citoyens contre les transferts illégitimes. Les clients américains resteraient toutefois sous la portée du CLOUD Act.

Des négociations doivent commencer entre la Commission européenne et les Etats-Unis. Les dirigeants de l’UE ont déjà critiqué le projet de loi américain pour son adoption précipitée, ce qui risque de compliquer les négociations. Entre-temps, une centaine d’organisations de la société civile ont pressé le Conseil de l’Europe à rendre publiques les négociations prévues lors de la « Convention sur la cybercriminalité » (ou « Convention de Budapest »).

Les lois de confidentialité, un atout pour les entreprises ?

Alors que le RGPD a pu préoccuper une bonne partie des entreprises sur le changement que cela impliquerait pour leurs systèmes d’information et que la directive « E-Privacy » se prépare, il pourrait être intéressant de voir le rapport à la réglementation évoluer dans le monde des affaires. Les lois de «data privacy » pourraient, dans un futur proche ou lointain, être considérées comme une aide à la protection de leurs données et au maintien de la confiance des clients.

Dans un monde où les questions de confidentialité des données deviennent de plus en plus importantes (Cambridge Analytica, Google Home Mini), les protections sur les données des clients peuvent être un argument décisif lors du choix entre des offres compétitives. Le positionnement des fournisseurs américains sur les questions de Privacy et de protection des données est attendu impatiemment.

Que faire aujourd’hui ?

Pour conclure, les nouvelles réglementations sur la privacy restent assez ambiguës et peuvent même se heurter sur certains points. La principale conclusion reste que les Européens devraient être mieux protégés par le RGPD face au CLOUD Act, si les fournisseurs américains dénoncent les requêtes abusives et que les tribunaux en charge de valider la demande jouent leurs rôles. Les clients non européens, quant à eux, ne seraient pas plus protégés en hébergeant leurs données en Europe.

En attendant l’entrée en vigueur de nouvelles lois traitant de la confidentialité et les éventuelles saisies des données, vous pouvez prendre des mesures pour protéger vos données personnelles et commerciales contre les écoutes d’outre-mer et autres menaces potentielles :

1. Clarifier avec votre fournisseur dans quelles conditions il pourrait être amené à donner accès à vos données, sans oublier de prendre en compte les traités d’assistance judiciaire mutuelle (Mutual Legal Assistance Treaties).
2. Définir ou revoir votre stratégie d’hébergement suivant le type de données, la nationalité du fournisseur et la location de l’hébergement
3. Privilégier l’hébergement de données dans des datacenters européens ou dans des pays disposant de règles bien établies en matière de confidentialité des données.
4. Choisir un fournisseur français ou européen permet d’éviter les risques du CLOUD Act. En contractualisant qu’il n’utilise pas de sous-traitants américains (directement ou indirectement) !

Cet article CLOUD Act : vos données sont-elles mieux protégées ? est apparu en premier sur RiskInsight.

Le secours informatique SaaS, une responsabilité du fournisseur à formaliser

Un service SaaS (Software as a Service) est un logiciel mis à disposition et directement consommable depuis Internet. Il est géré et administré par un ou plusieurs fournisseurs.  Le client n’a donc pas la latitude nécessaire pour opérer le secours (pas d’accès aux données brutes, pas d’accès aux codes sources, ni aux applicatifs pour dupliquer l’infrastructure…), il doit donc s’en remettre au bon vouloir de son fournisseur.

Un niveau de couverture du secours informatique pour SaaS variable suivant la maturité du fournisseur

Trois grandes tendances se dessinent :

• Les fournisseurs qui disposent d’un plan de secours informatique inclus
  Dans le cadre de l’offre standard, le fournisseur assure un secours sur un datacenter distant, complété généralement par des sauvegardes externalisées. Il ne s’engage néanmoins que rarement sur les délais de reprise.
  Ex : les grands acteurs du SaaS (ex : Office 365, SalesForce, SAP…) , ainsi que certains acteurs de taille intermédiaire (ex : Evernote, Xero…) ;

• Les fournisseurs qui disposent simplement d’une sauvegarde externalisée
  En tant que tel, aucun plan de secours informatique n’est clairement établi. Le client doit alors s’interroger sur la capacité du fournisseur à restaurer les sauvegardes en cas de sinistre global sur le site principal.
  Ex : Des fournisseurs de taille intermédiaire (ex : Zervant, Sellsy…) ;

• Les fournisseurs qui ne communiquent pas ou n’en disposent pas
  Le sujet du secours informatique n’est pas abordé, il est donc préférable de considérer que rien n’est fait.
  Ex : Les acteurs de petite taille sont généralement dans ce cas.

L’importance de l’aspect contractuel

Dans la très grande majorité des cas, les fournisseurs SaaS ne s’engagent pas dans leur contrat sur leur façon de gérer le secours ; même lorsque ceux-ci mettent en avant leur capacité à traiter cette problématique. En effet, les contrats comportent généralement par défaut des clauses de Force Majeure stipulant que le fournisseur n’est pas responsable de manquement aux obligations du contrat dans la mesure où ce manquement est causé par un évènement en dehors de leur contrôle raisonnable. Le risque juridique doit donc être traité lors de la souscription et ces clauses supprimées pour s’assurer un bon niveau de couverture.

Lors de la souscription, comme pour des contrats classiques, les clients doivent s’assurer que figure bien des engagements de service, en particulier pour les secours informatiques :

• Le délai de reprise (Durée Maximale d’Interruption Acceptable ou DMIA) et les pertes de données (Perte de Données Maximale Acceptable ou PDMA) en cas de sinistre;
• Le plan de secours informatique du fournisseur incluant les modalités de gestion de crise ainsi que l’obligation de conduire plusieurs tests probants par an de ce plan avec la possibilité pour le client d’accès au rapport des tests ;
• Les pénalités financières et le droit de résilier le contrat (avec en particulier la récupération des données exploitables) en cas de manquement aux engagements.

Le secours informatique du IaaS/PaaS, une mise en oeuvre et une responsabilité du client

Le IaaS (Infrastructure as a Service) est une offre standardisée et automatisée de ressources de calcul, de moyens de stockage et de ressources réseau détenus et hébergés par un fournisseur et mis à disposition au client à la demande. L’offre PaaS (Platform as a Service) est similaire à celle du IaaS, à la différence près qu’elle ne concerne que les infrastructures applicative (définitions Gartner) Contrairement au cas du SaaS, le secours reste sous la responsabilité du client dans les deux cas : les fournisseurs IaaS/PaaS mettent à disposition des ressources dans différents datacenters et le client est responsable de l’usage et de la configuration qu’il en fait. Deux solutions s’offrent aux clients utilisant ces services : confier à un prestataire son secours ou bien le gérer lui-même.

Avoir recours à un prestataire de secours, un marché peu mature

Les prestataires de secours dans le Cloud sont désignés par l’acronyme « DRaaS » pour Disaster Recovery as a Service. Initialement, les fournisseurs DRaaS proposaient d’assurer dans le Cloud le secours de votre SI « on-premise ». Mais ils proposent également aujourd’hui d’assurer le secours de vos infrastructures déjà dans le Cloud, AWS ou Azure par exemple. La maturité reste très variable selon les fournisseurs et le cloud utilisé. Certains fournisseurs DRaaS imposent que le Cloud de destination du secours soit le leur, ne permettant pas ainsi de couvrir le secours de service PaaS.

Comme avec le SaaS, pas de garanties incluses par défaut quant aux pertes de données ou au délai de reprise, il faut les négocier. Les fournisseurs promettent de pouvoir s’adapter aux exigences du client ! Pour s’assurer que le secours fonctionne, le client doit prévoir la réalisation régulière de tests probants du secours (recommandation d’une fois par an).

Réaliser soi-même son secours en utilisant les outils proposés par le fournisseur

Comme sur une infrastructure « on-premise », il est nécessaire de réfléchir et définir sa stratégie de secours dès la conception. Cette stratégie doit intégrer la capacité de réaliser des tests probants permettant d’assurer un niveau de confiance suffisant dans son plan.

La mise en place est simplifiée par les outils mis à disposition par les fournisseurs Cloud et la forte standardisation des environnements Cloud. Les grands acteurs publient dans des livres blancs les grandes lignes directrices pour mettre en place un tel projet (par exemple AWS ou Azure).

Les concepts des stratégies du secours informatique restent proches de celles pour les datacenters on-premise.

On peut en dénombrer quatre principales :

• la sauvegarde et restauration: simple sauvegarde des données et images des machines sur un site distant, restaurées en cas de sinistre ;
• la veilleuse: réplication des bases de données et mise à disposition des machines sous forme d’images prêtes à être démarrées en cas de sinistre ;
• le secours à chaud: réplication complète du site primaire (données et machines), le site de secours est sous-dimensionné en termes de performances et est prêt à monter en charge en cas sinistre ;
• le multi site (ou actif-actif): les deux sites sont identiques et se partagent la charge des utilisateurs. En cas de sinistre, le site restant peut monter en charge pour accueillir la totalité des utilisateurs.

Des solutions hybrides pouvant mieux s’adapter aux exigences de délai de reprise, coût et complexité de la solution peuvent être envisagées.

Le véritable apport du Cloud pour le secours concerne les nombreux outils mis à disposition simplifiant la mise en œuvre et le déclenchement.

La réplication des données est ainsi simplifiée pour les options de géo-réplication asynchrones (plusieurs copies répliquées dans d’autres régions). La PDMA est variable en fonction des types de données et des outils proposés. Au-delà de cette option, une redondance locale des données est presque systématiquement incluse.

La forte standardisation permet également d’automatiser la reprise : les scripts ou API mis à disposition par les fournisseurs permettent d’automatiser le déploiement des infrastructures, le redimensionnement des instances en fonction de métriques précédemment définies, la répartition des charges et du trafic ou, l’adressage IP etc… afin d’accélérer de façon significative l’activation d’un site de secours.

Les outils de surveillance et alerte qui sont également proposés visent à faciliter le Maintien en Conditions Opérationnelles (MCO) du secours et peuvent être utilisés pour détecter au plus tôt un incident voire, dans certains cas, automatiser partiellement le déclenchement du secours.

Enfin la capacité à provisionner des nouvelles ressources en quelques minutes permet de limiter l’OPEX. A stratégie équivalente, il est ainsi possible d’avoir des gains de 40 à 70% sur le coût du secours !

Vers une plus grande prise en charge par le fournisseur ?

Azure prévoit une option, courant 2017, pour assurer le secours des machines virtuelles hébergées au sein de leur plateforme via la complétion de leur service « Site Recovery ». En effet, « Site Recovery » propose à l’heure actuelle de prendre en charge le secours de site traditionnel en utilisant le cloud Azure pour accueillir le site secondaire, mais Microsoft souhaite étendre ce service au secours de leurs propres infrastructures. Cet outil permettrait un déploiement automatique du site secondaire (de type actif-passif), une réplication automatique des données et une mise en place de tests facilitée.

Cette option est passée en « public preview » fin mai 2017. Un projet équivalent n’est pas d’actualité chez les autres principaux fournisseurs IaaS/PaaS.

Le cloud face au risque systémique des fournisseurs

Le secours informatique des services hébergés dans le cloud s’aborde différemment selon le type de service utilisé. Le secours du SaaS doit être géré contractuellement et est sous la responsabilité du fournisseur tandis que le secours du IaaS/PaaS, simplifié par les outils, reste sous la responsabilité du client.

Le risque de défaillance généralisé d’une région d’hébergement d’un fournisseur existe comme le montre les derniers incidents. Même si aujourd’hui, les incidents ont été de courte durée ou avec des impacts fiables, une défaillance généralisée ne peut pas être ignorée. Reste donc à traiter la problématique de cyber-résilience. L’utilisation d’un 2^ème fournisseur cloud permet de couvrir le risque de destruction ou d’indisponibilité majeure des infrastructures du premier. Cette solution reste très complexe car la portabilité d’un fournisseur à un autre est délicate. Pour l’instant, peu d’entreprises s’y sont risquées, même si l’on peut citer l’exemple de Snapchat qui utilise le cloud Google pour sa production et prévoit d’utiliser celui d’Amazon pour son secours d’ici à 5 ans.

Cet article Le Cloud, la fin ou renouveau du secours informatique ? est apparu en premier sur RiskInsight.