Les audits CI/CD réalisés en 2025 et 2026 ont révélé que des identifiants exposés dans des dépôts, des runners mal configurés, des stockages d’artefacts non sécurisés et des rôles cloud trop permissifs constituent autant de vecteurs d’attaque que des acteurs malveillants peuvent exploiter afin d’obtenir un accès persistant et fortement privilégié à l’ensemble de l’infrastructure.

Une vue d’ensemble des outils DevOps est illustrée ci-dessous :

Une compromission à n’importe quelle étape du pipeline peut ouvrir une voie vers des systèmes plus sensibles.

Cet article décrit une chaîne d’attaque CI/CD représentative visant un environnement CI/CD, fondée sur des scénarios observés en conditions réelles. Il met en évidence les vecteurs d’attaque les plus couramment exploités ainsi que les principales mesures de durcissement permettant de réduire la surface d’attaque à chaque étape du pipeline, depuis le code source jusqu’au déploiement en production.

La chaîne d’attaque: de la reconnaissance à la persistance

Reconnaissance et accès initial

La chaîne d’attaque débute généralement par une attaque de phishing ciblant les développeurs afin de voler des identifiants et des codes MFA, bien que le MFA puisse lui-même être contourné via le vol de jetons d’accès ou de détournement de sessions.

Il convient de noter que la compromission d’identifiants seule n’est pas toujours suffisante pour accéder directement à des portails administratifs sensibles. Les contrôles de sécurité autour des interfaces d’administration Microsoft 365 ont été renforcés par des mécanismes de MFA ainsi que, le cas échéant, par des politiques d’accès conditionnel, limitant l’impact du phishing sur les accès hautement privilégiés.

Cependant, dans les environnements d’entreprise modernes où la majorité des applications reposent sur le Single Sign-On (SSO), la compromission d’une session Microsoft (par exemple via le vol de cookies de session) peut donner aux attaquants accès à un large éventail de services interconnectés, incluant les dépôts de code et les plateformes CI/CD. Les attaquants utilisent généralement ce point d’entrée initial pour identifier les environnements de développement et établir une persistance via des mécanismes tels que les Jetons d’accès personnels (PAT).

Un risque souvent négligé survient lorsqu’un compte utilisateur est désactivé au niveau du fournisseur d’identité (ex. Entra ID) mais n’est pas entièrement désactivé dans les plateformes de dépôt. Dans ce cas, des PATs précédemment émis peuvent rester valides, permettant à un attaquant de conserver un accès malgré la révocation du compte.

D’autres vecteurs d’entrée incluent l’exploitation de CVE connues ainsi qu’une mauvaise gestion des identifiants. De nombreuses vulnérabilités majeures sur les outils DevOps sont régulièrement découvertes, ce qui souligne la nécessité d’une gestion continue des vulnérabilités. L’exploitation d’une vulnérabilité critique peut directement fournir un accès privilégié à un outil de la chaîne.

Exemples :

• CVE-2024-23897 (Jenkins), permettant à des attaquants non authentifiés de lire des fichiers arbitraires présents sur le contrôleur Jenkins, exposant ainsi des secrets sensibles,
• CVE-2023-7028 (GitLab), dans laquelle les emails de réinitialisation de mot de passe pouvaient être envoyés vers une adresse électronique non vérifiée.
• CVE-2023-36561 (Azure DevOps Server), une vulnérabilité d’élévation de privilèges permettant à un attaquant d’obtenir un accès non autorisé à certaines fonctionnalités d’Azure DevOps Server, avec un impact potentiel sur les pipelines, les secrets et les ressources des projets.

REMÉDIATION – Renforcer les contrôles d’accès aux dépôts de code source

Afin de réduire les risques liés à l’accès initial, les organisations doivent mettre en œuvre des contrôles permettant d’empêcher les accès non autorisés, de détecter les mécanismes de persistance et de renforcer la gouvernance des identités.

Appliquer des politiques d’accès strictes et réduire l’exposition réseau

• Eviter l’utilisation des comptes génériques ou partagés,
• Utiliser des identités développeurs dédiées, séparées des comptes bureautiques standards (messagerie et outils collaboratifs), afin de réduire l’exposition au phishing et l’impact d’une compromission dans les environnements CI/CD,
• Imposer des mécanismes MFA résistants au phishing (clés FIDO2, certificats, etc),
• Mettre en place des politiques d’accès conditionnel basées sur des critères contextuels (localisation réseau, conformité des appareils).

Mettre en place des mécanismes de détection de persistance

• Surveiller la création ou l’utilisation suspecte de PAT dans GitLab, ainsi que les activités anormales (ex. déploiements à des horaires inhabituels),
• Surveiller l’ajout de nouvelles méthodes d’authentification dans Entra ID, notamment les méthodes sans mot de passe, après un événement de phishing.

Réviser périodiquement les accès et supprimer les comptes inutilisés

• Désactiver ou supprimer les comptes inutilisés ou inactifs,
• Révoquer les accès des collaborateurs sortis de l’organisation sur tous les systèmes,
• Réaliser des revues d’accès périodiques, au minimum tous les six mois pour les utilisateurs à risque élevé.

Compromission des dépôts de code et des pipelines

Les dépôts de code sont souvent directement intégrés aux pipelines CI/CD, ce qui signifie que toute modification du code peut déclencher automatiquement des processus de build et de déploiement. Ainsi, la compromission d’un compte développeur peut influencer la manière dont les applications sont construites et déployées.

Pour réduire le risque de modifications non autorisées en production, les organisations protègent généralement les branches de production (ex. main ou master) via des pull requests, des validations et des contrôles automatisés. En revanche, les branches de développement sont souvent moins strictement contrôlées afin de favoriser la rapidité de développement et de test.

Dans le scénario observé, l’attaquant cible la branche de développement et modifie le fichier de configuration du pipeline (gitlab-ci.yml), en y injectant une commande malveillante (visant à établir un accès distant) au sein d’un job existant. Lors de l’exécution du pipeline, cette commande est exécutée sur le runner CI/CD, ce qui permet à l’attaquant d’obtenir un accès distant à ce dernier.

Une fois dans le runner CI/CD, l’attaquant peut alors exécuter du code arbitraire sur le runner CI/CD et, entre autres, énumérer les variables d’environnement contenant des paramètres de configurations et les secrets définis dans le projet GitLab.

Cependant, il arrive que certains composants de la chaîne CI/CD ne sont pas dupliqués entre environnements pour des raisons de coûts. Dans ce cas précis, les secrets GitLab ne sont pas segmentés entre les environnements de production et de développement. Ainsi l’attaquant est en capacité de lister les secrets de production depuis le runner CI/CD de développement.

Un exemple de variables d’environnement rencontrées dans les pipelines CI/CD est présenté ci-dessous.

Ce flux d’attaque montre comment la manipulation de pipeline permet l’exécution de code dans le runner et l’extraction de variables sensibles de production depuis un environnement de développement.

Parmi les identifiants récupérés dans l’environnement CI/CD compromis, l’attaquant obtient un jeton d’accès à Nexus, système de gestion d’artefacts utilisé pour stocker et distribuer les artefacts de build de confiance consommés par les pipelines situés en aval.

REMÉDIATION – Durcir la sécurité des dépôts de code

La sécurisation du dépôt de code est essentielle pour empêcher l’exploitation des pipelines CI/CD après un accès initial, car les dépôts contrôlent directement le build et le déploiement.

Durcir les dépôts pour limiter les déclenchements de pipeline

• Configurer des branches protégées pour les branches de déploiement,
• Mettre en place des workflows d’approbation multi-niveaux pour les merge requests déclenchant des pipelines et interdire l’auto-approbation,
• Utiliser la propriété du code (ownership) pour assigner et exiger l’approbation des responsables désignés sur les fichiers sensibles (ex. configuration CI/CD).

Limiter la visibilité et les permissions

• Limiter les droits d’écriture aux seuls utilisateurs qui en ont besoin,
• Restreindre la visibilité des projets selon le principe du besoin de savoir (interne ou privé recommandé).

Mettre en place une bonne hygiène de gestion des secrets

• Configurer des secrets CI/CD scopés au niveau projet et privilégier des identifiants éphémères,
• Détecter les secrets en clair le plus tôt possible (au moment du commit ou avant la publication du code) et les révoquer immédiatement en cas d’exposition,
• Réaliser des revues périodiques (ex. audits internes, exercices de red team) sur des plateformes telles que les dépôts Git, Jira ou Confluence afin d’identifier d’éventuelles fuites de secrets passées inaperçues.

REMÉDIATION – Renforcer la sécurité des runners auto-hébergés

Les runners sont des composants critiques des pipelines CI/CD car ils exécutent le code et manipulent des données sensibles. S’ils sont compromis, ils peuvent permettre des mouvements latéraux, l’accès aux secrets ou la prise de contrôle de l’environnement.

Réduire l’exposition réseau et le périmètre d’exécution

• Restreindre le trafic réseau des runners uniquement à ce qui est nécessaire à l’exécution des pipelines, et appliquer des contrôles réseau tels que des proxies et de la segmentation afin d’empêcher tout accès Internet non contrôlé et limiter les mouvements latéraux au sein des réseaux internes,
• Restreindre les déclenchements depuis des dépôts non fiables ou personnels.

Considérer les runners comme des systèmes sensibles

• Considérer les runners comme des serveurs critiques (Application régulière des correctifs du système d’exploitation et durcissement),
• Déployer des solutions de Endpoint Detection and Response (EDR) pour la surveillance des processus, y compris dans les environnements conteneurisés.

Utiliser des runners dédiés et éphémères

• Privilégier des runners dédiés par projet ou environnement. Le partage de runners entre plusieurs contextes augmente le risque de contamination inter-projets et d’escalade de privilèges,
• Utiliser des runners éphémères / autoscalés détruits après chaque job,
• S’assurer que les runners basés sur VM soient également éphémères et isolés afin qu’aucune donnée ou accès résiduel ne persiste entre les exécutions. En complément, s’appuyer uniquement sur des images de base durcies et de confiance (par exemple des golden images pour les runners VM et des images conteneurs approuvées), afin d’éviter toute exécution dans des environnements compromis ou non vérifiés.

Sécuriser les runners containerisés

• N’autoriser que des images approuvées et de confiance dans les exécutions de pipelines afin d’éviter l’introduction de code malveillant via des images compromises ou non vérifiées,
• Appliquer le principe du moindre privilège dans les environnements d’exécution conteneurisés,
• Éviter le mode privilégié et supprimer les capacités Linux inutiles,
• Utiliser des moteurs de build sécurisés (BuildKit / Buildah) lorsque le Docker-in-Docker est requis.

Durcir les runners cloud

• Lors de l’utilisation de runners managés dans le cloud, appliquer une isolation stricte et un périmètre d’identité, restreindre l’accès aux métadonnées afin d’éviter l’exposition d’identifiants depuis l’infrastructure sous-jacente, et s’assurer que les rôles CI/CD sont gouvernés par des politiques IAM strictes en moindre privilège afin d’éviter des permissions excessives.

Empoisonnement d’artefacts et attaques sur les dépendances

Dans les environnements de livraison logicielle, les systèmes de gestion d’artefacts stockent et distribuent les sorties générées par les pipelines CI/CD. Ces sorties, appelées artefacts, représentent les résultats packagés du processus de build, tels que des binaires compilés, des packages applicatifs ou des images de déploiement.

Les artefacts sont stockés de manière centralisée afin d’assurer le versioning, la traçabilité et la réutilisation à travers plusieurs pipelines. En plus des sorties spécifiques aux applications, ces dépôts hébergent souvent également des composants partagés tels que des golden images, des bibliothèques réutilisables ou des dépendances runtime communes. Comme ils proviennent de processus de build considérés comme fiables, les artefacts sont généralement supposés sûrs et largement consommés par les pipelines en aval sans validation supplémentaire.

Dans le scénario observé, l’attaquant utilise des identifiants précédemment obtenus pour s’authentifier au dépôt d’artefacts (Nexus dans cet exemple) avec des permissions excessives (lecture/écriture sur plusieurs catégories, plutôt que limitées à un périmètre applicatif unique), et obtient ainsi un accès à la fois aux artefacts de production et aux artefacts partagés.

Parmi ces derniers, l’attaquant identifie un binaire Terraform légitime utilisé dans le processus de déploiement d’infrastructure (appelé ici le binaire tofu), qui est couramment approuvé et consommé par les pipelines CI/CD pour provisionner et gérer les ressources cloud.

L’attaquant télécharge cet artefact localement et en modifie le contenu en injectant une logique malveillante tout en conservant sa fonctionnalité d’origine, et y intègre un comportement caché conçu pour interagir avec les services AWS Identity and Access Management (IAM) et AWS Security Token Service (STS) afin de récupérer des identifiants.

Le binaire modifié est ensuite téléversé de nouveau dans Nexus, remplaçant la version légitime par un artefact compromis.

À partir de ce moment, tout pipeline CI/CD consommant cet artefact récupère automatiquement le binaire compromis lors de la résolution des dépendances, car il est toujours considéré comme fiable.

Lors de son exécution, le binaire compromis active la charge malveillante intégrée, dont l’objectif est de récupérer le jeton d’accès AWS utilisé par le contexte d’exécution Terraform et de l’envoyer vers un serveur contrôlé par l’attaquant pour exfiltration. Il génère ensuite une sortie obfusquée encodée en Base32. Le décodage permet de reconstruire un objet JSON contenant des identifiants AWS (AccessKeyId, SecretAccessKey et SessionToken).

L’attaquant configure ensuite ces identifiants localement et utilise AWS STS (appel API GetCallerIdentity) pour confirmer l’usurpation d’identité du runner CI/CD.

Cette illustration montre la chaîne d’attaque : compromission d’artefact, injection de logique malveillante, propagation via les pipelines CI/CD et vol final d’identifiants AWS menant à la compromission de l’environnement.

En conséquence, l’attaquant obtient un accès non autorisé aux ressources AWS sous une identité légitime.

REMÉDIATION – Améliorer la gestion des accès à l’Artifactory

Les dépôts d’artefacts tels que Nexus sont des composants clés des pipelines CI/CD utilisés pour stocker et distribuer les dépendances et artefacts de build. Ce sont des cibles à forte valeur pour les attaques de chaîne d’approvisionnement.

La sécurité nécessite des contrôles d’accès forts, une gouvernance des dépendances et une surveillance continue de l’intégrité.

Durcir la plateforme d’artefacts

• Autoriser une large lecture du dépôt uniquement sous deux conditions : depuis le service nécessaire (CI/CD) et si une gestion de mots de passe dans les dépendances existe,
• Restreindre fortement les permissions d’écriture,
• Modifier les identifiants par défaut.

Analyse de composition logicielle (SCA)

• Appliquer une analyse de composition logicielle aux dépendances internes (stockées dans des dépôts locaux) ainsi qu’aux dépendances externes (récupérées depuis des dépôts distants ou proxy) afin de détecter les vulnérabilités connues et les composants obsolètes.

Restreindre les sources d’artefacts

• Maintenir une whitelist de dépôts de confiance afin de garantir que seules des sources approuvées sont utilisées,
• Appliquer des contrôles au niveau des dépôts pour exclure les versions non approuvées ou vulnérables, par exemple dans Nexus ou via des règles d’exclusion dans JFrog Artifactory,
• Empêcher les pipelines CI/CD d’accéder à des sources externes non fiables en imposant des frontières strictes entre dépôts.

Compromission cloud via abus des workloads CI/CD

Dans les environnements cloud, les runners CI/CD sont généralement associés à des rôles IAM privilégiés pour effectuer des opérations de déploiement, incluant la création, modification et suppression de ressources d’infrastructure. Ces rôles incluent souvent des permissions larges telles que AdministratorAccess ou des politiques personnalisées trop permissives, permettant au runner d’interagir avec un large ensemble de services AWS, incluant les services de calcul, le stockage et la gestion des identités.

Lorsqu’un runner CI/CD est compromis, un attaquant peut directement abuser de ces privilèges sans nécessiter d’escalade supplémentaire. Cela peut conduire à un accès immédiat à des ressources sensibles telles que des buckets S3 ou des bases de données RDS, permettant l’exfiltration de données. L’attaquant peut également exploiter les permissions IAM pour assumer d’autres rôles dans d’autres comptes ou projets AWS, facilitant les mouvements latéraux au sein de l’organisation. En outre, l’accès aux services de compute peut être utilisé pour déployer, modifier ou maintenir des charges malveillantes, aboutissant finalement à une compromission complète de l’environnement cloud.

De la compromission initiale du développeur à la prise de contrôle cloud : vue complète de la chaîne CI/CD

la chaîne d’attaque CI/CD commence par la compromission initiale du développeur jusqu’à la prise de contrôle complète de l’environnement cloud.

L’illustration suivante met en évidence les opportunités clés de détection et de surveillance à travers l’écosystème CI/CD. Elle montre comment les données de télémétrie de sécurité peuvent être collectées et corrélées tout au long des différentes étapes de la chaîne d’attaque CI/CD, depuis les activités de développement jusqu’aux runners CI/CD, aux dépôts d’artefacts et aux opérations IAM dans le cloud.

Dans l’ensemble, bien que les pipelines CI/CD élargissent significativement la surface d’attaque, ils offrent également de multiples points d’interception stratégiques où une journalisation centralisée et une surveillance de sécurité peuvent permettre une détection précoce et une réponse aux activités malveillantes.

En conclusion, pour obtenir un pipeline CI/CD sécurisé, la sécurité doit être pensée de bout en bout, des environnements développeurs jusqu’aux systèmes de production.

Les développeurs sont le premier maillon de la chaîne, et la sécurisation de leurs comptes est essentielle. Cela doit être complété par de bonnes pratiques telles que la gestion sécurisée des secrets et la sensibilisation régulière à la sécurité.

Il est également crucial d’assurer une bonne isolation entre environnements et d’appliquer strictement le principe du moindre privilège, aussi bien pour les utilisateurs que pour les comptes de service.

Les problèmes de sécurité ne peuvent pas être corrigés par de simples correctifs si la conception globale du pipeline est faible.

Enfin, les cas d’usage de déploiement doivent être définis clairement dès le départ, car ils influencent directement l’architecture et les choix IAM.

Au-delà des aspects techniques, la sécurité CI/CD doit être évaluée en continu via des audits techniques réguliers ainsi que des revues organisationnelles du cycle de développement afin de maintenir les risques sous contrôle.

Pour une perspective plus large et des recommandations de haut niveau sur le positionnement du CI/CD comme pilier du système d’information, voir l’article RiskInsight : « CI/CD: the new cornerstone of the information system ».

Cet article Sécurité CI/CD : attaque de chaîne d’approvisionnement depuis un développeur compromis est apparu en premier sur RiskInsight.

Le principe de tiering préconisé sur les infrastructures on-premise est-il applicable au cloud ?

Évolution du modèle de sécurité

Dans les environnements on-premise, en particulier Active Directory, la sécurité des infrastructures s’appuie généralement sur une segmentation stricte en trois niveaux (T0, T1 et T2) permettant d’isoler les systèmes d’administration critiques (T0), les serveurs (T1) et les postes utilisateurs (T2) afin de limiter les risques de propagation.

Cette organisation hiérarchique et périmétrique est inhérente au monde AD et ne peut être directement appliquée au cloud pour ces deux principales raisons :

• Les portails sont centralisés: une grande diversité d’administrateurs aux droits différents interagit avec la même URL.
• La frontière entre les niveaux d’administration est complexifiée: le principe de permission fine, par rôle (RBAC), par attribut de ressources (ABAC), selon certaines conditions (provenance, risque, conformité, méthode d’authentification…) permet de configurer des accès très précisément, mais complexifie et floute la vision globale des permissions.

Afin de proposer une réponse à ce nouveau paradigme, Microsoft a publié son Enterprise Access Model (décrit ici), mettant en évidence 3 principaux plans : le Control Plane, Management Plane et Data Plane.

Ce modèle reprend la criticité « en cascade », mais simplifiant :

• les 3 tiers en 2 accès : administrateur vs utilisateur ;
• les flux d’administration en accès au portail ;
• la criticité des serveurs en les centralisant dans le Data plane.

Une illustration de l’ancien et du nouveau modèle :

Ce nouveau modèle met particulièrement en valeur 3 éléments :

• L’identité de l’utilisateur : accès privilégié vs accès utilisateur ;
• La donnée et les services : au détriment des serveurs ;
• La méthode d’accès aux portails web d’administration.

L’inversion des importances entre « serveurs » et « portails web » abstrayant l’Active Directory est un changement radical.

Cependant, très peu (si ce n’est aucune) grande structure en est à ce niveau d’abandon de son SI « legacy », une grande partie sera dans un état transitoire où ce SI aura été virtualisé sur un Cloud afin de se séparer de ses datacenters, mais dont les modalités d’administration sont restées les mêmes.

Ces entreprises doivent donc traiter avec un tiering model désuet et un Enterprise Access Model décoléré des risques et besoins de sécurité actuels.

Pour la suite de cet article, nous prendrons comme exemple la société Tartampion, qui vient de terminer un programme Move-to-Cloud de 3 ans sur AWS. Le bilan est le suivant :

• Une Landing Zone a été créée, les applications déjà sur AWS y ont été intégrées
• Les Data Center ont été fermés
• Pris par le manque de temps et de moyens, une majeure partie du SI a été incorporé en lift and shift, incluant des solutions métiers, réseau, bastion et AD.

Un SI hybride et virtualisé qui pose problème

Selon l’EAM, les portails Azure et AWS sont affichés au même niveau (le management plane) au rang T1, sans autre forme de distinction. Or ces 2 environnements cloud sont à eux seuls le support de nombreux SI, utilisés par de multiples collaborateurs avec des niveaux de droits et d’impacts très variés.

Pour illustrer les précédents propos, mettons de côté l’aspect Digital Workplace (suite O365) et prenons 3 comptes AWS issus d’une Landing Zone de Tartampion, supportant différents services d’infrastructure :

En se fiant au référentiel proposé par Microsoft, ces trois comptes AWS devraient appartenir au Management plane avec un niveau de sécurité T1. Cependant, en cas de compromission d’un des 3 comptes par un attaquant, les impacts seraient très différents.

Si la Landing Zone est correctement implémentée, la compromission d’un compte de Sandbox n’aurait que très peu d’impact, tandis que celle du Master Account entrainerait celle de tous les comptes et ressources sous-jacentes.

Un exemple de découpage plus adéquat serait le suivant :

L’Enterprise Access Model par Microsoft est un framework macroscopique permettant d’initier une base de découpage des services cloud, mais qui reste à adapter selon la criticité des SI concernés.

Comment le rendre pertinent ? Pour répondre, il faut comprendre les scénarios d’attaque exploitant les services cloud.

Le Cloud vu de l’attaquant

5 principes du cloud favorisant les attaques

Premièrement, les infrastructures cloud sont par défaut exposées sur Internet, contrairement aux ressources sensibles d’un SI. Ainsi, un phishing réussi conduit très probablement à un accès sur le Cloud.

Deuxièmement, les entreprises ont aujourd’hui des organisations hybrides (on-premise et cloud) :

• Les infrastructures cloud sont reliées au reste du SI on-premise ;
• Les postes de travail peuvent également être hybrides et gérés par un service cloud comme Intune. Les permissions pour utiliser ce service sont gérées dans Entra ID ;
• Les identités sont souvent des comptes synchronisés, cela concerne également les comptes d’administration.

Les organisations hybrides peuvent faciliter les latéralisations entre le cloud et l’on-premise.

Troisièmement, la gestion des identités est très complexe avec différentes portées. Par exemple, Entra ID permet de gérer les accès à Azure et M365 aussi bien pour des utilisateurs, que des applications que des comptes de service.

Pour compléter, les notions de cybersécurité liées au Cloud sont encore relativement nouvelles et méconnues pour certaines équipes « legacy », comme le SOC/CERT, le réseau… Les ressources cloud les plus sensibles ne sont pas systématiquement identifiées, protégées et surveillées.

Enfin, même si des mécanismes de détection natifs sont présents, ils ne sont pas toujours interconnectés avec les SIEM/SOAR, ce qui ralentit les capacités d’intervention. Une récente opération Purple Team menée sur des infrastructures Azure et AWS a confirmé que les outils de détection natifs ont une capacité de détection limitée. Il s’agit d’un constat retrouvable dans les Red Team puisqu’avec une démarche « OpSec », les outils de détection cloud sont rarement capables d’identifier une attaque en cours.

REX de nos tests d’intrusion & Red Team

Issus des opérations de Red Team menées récemment, ces chemins d’attaques spécifiques aux environnements cloud sont témoin des impacts et des facilités qu’il est possible d’avoir pour s’élever en privilège jusqu’à obtenir des accès très permissifs :

Le premier scénario, effectué sur AWS, est décrit ci-dessous, les deux autres ont été analysés dans une série d’articles Risk Insight disponible ici.

Reconnaissance et Accès initial

Des catégories d’employés sont généralement ciblées afin de compromettre une personne avec des droits intéressants dans le SI (Développeur, Support, OPS…). Un moyen souvent utilisé est d’utiliser du phishing. Les mécanismes de phishing actuel sont capables de contourner l’usage de mots de passe complexe et la plupart des méthodes de MFA (Multi-Factor Authentication).

Escalade de privilèges et mouvements latéraux

Dans le premier scénario, un développeur compromis possédait des accès à une ferme Citrix. Les environnements Citrix ne sont pas simples à durcir complètement et quelques vulnérabilités d’échappement ont permis à la Red Team d’avoir un accès au serveur sous-jacent.

Les informations récoltées sur la machine ont indiqué que le serveur pouvait être hébergé sur AWS. Cela s’est vérifié en essayant d’accéder aux métadonnées AWS du serveur : l’instance avait des droits sur le compte AWS du client. La machine virtuelle du Citrix possédait le rôle « AmazonEC2FullAccess » lui permettant des actions de gestion sur les EC2 du même compte AWS.

À l’aide de la CLI AWS, les autres EC2 ont été listées. Un contrôleur de domaine du client était présent dans ce compte AWS. C’est une pratique courante de vouloir regrouper dans un même compte, généralement appelé « Shared Services », les services qui ont pour vocation d’être utilisés par plusieurs projets. Il est néanmoins recommandé de vérifier que la criticité des services partagés soit homogène de sorte à pouvoir appliquer un durcissement adéquat sur le compte, ou les séparer en plusieurs environnements.

Actions sur les trophées

À partir du rôle AWS du serveur Citrix, une sauvegarde instantanée du contrôleur de domaine a été faite puis téléchargée. Les sauvegardes d’un contrôleur de domaine contiennent tous les fichiers de la machine, y compris les fichiers les plus sensibles, comme la base ntds.dit, qui contient les informations et secrets de tous les utilisateurs du domaine. L’exfiltration de cette base se traduit en la compromission totale du domaine AD concerné.

Ce scénario illustre l’un des chemins d’attaques qui ont été exploités lors des opérations de redteam, facilité par le manque de visibilité sur les impacts que peuvent avoir une ressource compromise hébergée sur le cloud.

Des impacts plus rapides et plus forts

Les attaques déjà possibles sur un SI on-premise peuvent être reproduites et même accélérées grâce aux fonctionnalités du cloud. Par exemple, le chiffrement de buckets S3 (service de stockage de fichiers) à partir d’une clé KMS (de chiffrement) d’un autre compte AWS imite le chiffrement massif de données, ou l’utilisation de la fonctionnalité « lifecycle » permet une suppression de tous les objets en moins de 24 heures, peu importe la quantité de données.

De nouvelles attaques sont également apparues comme le « Hijack de souscription » qui permet de rattacher un abonnement d’une organisation Azure à une autre et ainsi de voler toutes les données qu’il contient et empêcher les actions de remédiation. Cette attaque est réalisable en quelques clics depuis l’interface web Azure.

Identification et protection du cœur de confiance cloud

Identification du Cœur de confiance

Le cœur de confiance adopte une approche centrée sur la priorisation des actifs, qui diffère du modèle de tiering ou de l’Enterprise Access Model de Microsoft. Contrairement à ces modèles qui proposent un découpage prédéfini, il n’existe pas de grille universelle : chaque organisation doit identifier elle-même quelles ressources méritent le plus haut niveau de protection. L’idée est d’établir un cercle restreint de ressources critiques (qu’elles soient cloud ou on-premise) puis de déployer des niveaux de protection dégressifs à mesure que l’on s’éloigne de ce cœur.

L’identification du cœur de confiance repose sur deux grands critères :

• Criticité métier: ce sont les ressources qui concentrent la valeur et la continuité des activités de l’entreprise. Si elles venaient à être perdues ou compromises, les conséquences seraient immédiates pour le fonctionnement quotidien et financièrement. Un environnement SharePoint contenant la donnée intellectuelle / brevets en est un exemple courant ;
• Criticité SI: il s’agit des ressources qui assurent l’administration du système d’information et qui disposent d’un niveau d’accès élevé. Leur compromission aurait un impact majeur sur l’ensemble du SI et permettrait d’avoir l’impact métier précédemment énoncé. On retrouve ici les contrôleurs de domaine ou encore les services d’IAM Cloud comme Entra ID et AWS Identity Center.

Cette cartographie n’est jamais totalement tranchée. Pour certains éléments, la posture à adopter reste plus floue, deux exemples l’illustrent bien :

• L’EDR: élément de sécurité évident d’un SI, systématiquement déployé tant sur les postes de travail que sur les serveurs cloud et on-premise, sa console d’administration est de plus en plus souvent exposée sur internet, et permet d’exécuter des commandes arbitraires sur les équipements qui en sont équipés.
• Les chaînes CICD: un savant, mais complexe agglomérat d’applications s’appelant entre elles, dont l’accès (le gestionnaire de code : GitLab, GitHub…) est offert à l’ensemble des collaborateurs et les droits sur le SI (manipulé par les runners de déploiement) sont bien souvent administrateur de l’ensemble des infrastructures cloud. Sur l’ensemble des Red Team effectués en 2024 & 2025, 80% ont exploité des vulnérabilités associées à ses solutions pour progresser dans leur opération, voire obtenir des trophées de compromission par ce biais.

Afin d’identifier le « noyau dur » du cœur de confiance, qu’on appellera socle de sécurité, on peut reprendre les préceptes de l’ancien T0 : la compromission d’un de ses éléments entrainerait probablement celles des autres, et par cascade de la majeure partie du SI.

En supposant que vos applications appliquent un correct cloisonnement interutilisateur (l’intégralité de vos sites SharePoint n’est pas accessible par tous, n’est-ce pas ?), les références aux prochaines applications seront à comprendre comme des accès administrateurs / super-utilisateurs à ces dernières, et non simple utilisateur.

Voici l’une des représentations possibles pour un cœur de confiance hybride :

Dans cette représentation, il y a côté on-premise :

• Le T0 avec ses contrôleurs de domaine, l’ADCS, et potentiellement la PKI, le bastion, la console EDR…
• Le T1 en intégrant en plus les applications métiers à fort impact.

Et côté Cloud, on retrouve :

• Au cœur le Control Plane (AWS Orga & Identity Center, Entra ID) ainsi que les modules de la Landing Zone supportant le T0 (si une partie du T0 est hébergée dans le Cloud) ;
• En s’éloignant, les diverses consoles d’administration des suites de bureautique, et de management des infrastructures ou des applications.

En établissant ce diagramme, il est important de garder à l’esprit que :

• L’IT sert au métier et quand bien même la zone centrale du cœur de confiance est principalement occupée par des briques techniques, il convient d’inscrire ses solutions critiques ;
• Les chaînes de dépendance / compromission ont beaucoup d’impact sur les choix d’architecture: positionner un AD sur AWS, ou déployer un EDR sur un AD peut soudainement créer de nombreux chemins de compromission et de rebond entre les 2 mondes.

Enfin, la construction d’un cœur de confiance ne peut pas se limiter à une logique de classification statique. Elle doit reposer sur une approche qui évalue la criticité de chaque actif et le risque qu’il introduit (une entreprise de développement de logiciel ne positionnera surement son Git au même niveau qu’une entreprise de travaux public).

Protection du cœur de confiance cloud

La sécurité du cœur de confiance va reposer sur les deux traditionnels facteurs de risques :

• Réduire l’impact: comment empêcher un utilisateur compromis ou malveillant de se connecter aux portails cloud sur un navigateur et de faire des actions sensibles en quelques clics, comme faire une sauvegarde d’un contrôleur de domaine hébergé sur une VM ou supprimer les sauvegardes de données de production ?
• Réduire la probabilité : comment réduire les risques d’accès illégitimes à partir d’un cookie de session volé par phishing, de la compromission d’un poste de travail ou de la réutilisation de mots de passe des utilisateurs ?

Protection du socle de sécurité cloud

Concernant le « socle de sécurité » cloud il est possible de hiérarchiser les environnements par criticité selon cette échelle macroscopique :

En fonction des équipes en charge et de la complexité de les inclure dans un niveau de protection particulièrement élevée, certaines organisations font le choix d’exclure des environnements dont la compromission ne permettrait pas une latéralisation dangereuse, telle que ceux de FinOps, de détection, le Digital Workplace…

La sécurisation du socle de sécurité cloud repose sur 2 principaux points :

• Une hygiène impeccable : configuration IAM épurée, respect du moindre privilège, procédure de déploiement, limitation des ressources au strict nécessaire…
• Une couche de sécurité passive / active : déploiement de politiques (SCP sur AWS, Policy sur Azure) interdisant explicitement certaines actions, ou la manipulation de certaines ressources, et règles de détection afin de lever une alerte en cas de modification d’une politique ou l’occurrence d’un de ses évènements protégés ;

Ces politiques peuvent efficacement être associées à une stratégie de tagging afin d’appliquer, en plus du modèle RBAC (Role Based Access Control) un modèle ABAC (Attribute Based Access Control).

Par exemple il est possible de tagger différentes ressources avec une clé « tiering » et une valeur entre « T0 », « T1 », « T2 » puis de déployer cet ensemble de stratégies :

• Interdire toute action visant une ressource taguée tiering par une identité dont la valeur de son propre tag tiering n’est pas équivalente ;
• Interdire la manipulation de tag tiering, sauf pour un rôle bien précis.

Et voilà comment, en quelques tags et 2 SCP, il est possible de répliquer le tiering model de Microsoft (quelques exceptions peuvent subvenir).

Protections des identités et des accès

Pour protéger les utilisateurs, 3 thématiques de durcissement peuvent être mises en place :

• Identité : avec quel compte l’utilisateur se connecte-t-il aux interfaces d’administration cloud ? Comment les droits sont-ils obtenus ?
• MFA : l’identité est-elle protégée avec une authentification multifactorielle résistante aux attaques de phishing ?
• Provenance: à partir de quelle plateforme l’utilisateur se connecte-t-il aux interfaces d’administration cloud ? La plateforme est-elle managée, et saine ?

Plusieurs niveaux de protection sont envisageables afin de protéger les administrateurs cloud :

Afin de protéger le cœur de confiance restreint, représenté par les triples cadenas, il est recommandé de mettre en œuvre les facteurs d’authentification les plus robustes. Cela inclut l’utilisation d’un compte dédié à l’administration cloud, l’activation d’une authentification multifactorielle physique (exemple : clé de sécurité FIDO2) et le recours à un poste de travail spécifiquement réservé aux opérations sur ce cœur de confiance.

Pour les ressources plus éloignées du centre du cœur de confiance, symbolisées par les doubles cadenas, un niveau de sécurité durci, mais proportionné peut être appliqué, afin de renforcer la protection pour maitriser les coûts et réduire les contraintes excessives aux utilisateurs concernés.

Finalement, les méthodes les plus sécurisées sont également celles qui impliquent le plus de contraintes aux personnes concernées. Il faut maitriser les usages et prendre en compte des situations d’urgence, comme une intervention en astreinte nécessitant des privilèges très élevés.

Répéter les opérations

À l’issue des phases d’identification et de protection, les ressources seront réparties dans les différentes couches du cœur de confiance.

Pour vérifier la bonne implémentation du cœur de confiance, un audit peut être conduit pour vérifier la bonne protection des ressources critiques qui le compose.

Un système d’information est toujours en évolution, mais les deux premières phases auront été faites à un instant t. De nouvelles ressources critiques peuvent être ajoutées, d’autres modifiées, voire supprimées. Il est primordial de refaire une évaluation régulière de son SI et de mettre à jour la répartition des ressources dans le cœur de confiance.

En conclusion, la sécurité des systèmes d’information s’inscrit désormais dans un contexte de complexité croissante et de forte diversification des composants et services d’infrastructures.

Dans ce contexte, il apparaît de plus en plus complexe de définir un modèle de sécurité universel. Certains cadres conservent toute leur pertinence sur des périmètres bien identifiés : le tiering reste une référence pour la sécurisation de l’Active Directory, tout comme l’EAM pour des environnements Cloud fortement centrés sur l’écosystème Microsoft. Néanmoins, ces modèles atteignent rapidement leurs limites dès lors que l’on s’éloigne de ces cas d’usage spécifiques.

Pour la majorité des systèmes d’information, une approche fondée sur l’analyse des risques s’impose donc comme la plus pertinente. Identifier un cœur de confiance, définir clairement les actifs critiques — les crown jewels — et décliner les mesures de sécurité à partir de ces éléments permet de construire une posture de sécurité plus pragmatique, adaptée à la réalité du SI et capable d’évoluer avec lui.

Cette logique, moins normative mais plus contextualisée, constitue sans doute l’un des leviers majeurs pour concilier sécurité, agilité et pérennité des systèmes d’information.

Cet article Sécurité orientée cloud : Adaptation à une nouvelle réalité est apparu en premier sur RiskInsight.

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.

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 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.

Tout d’abord, il faut savoir que la sécurité du cloud est particulièrement différente en fonction des types de cloud et de la manière de consommer des services cloud. Parmi ces services, on y retrouve trois grandes catégories : SaaS (Software as a Service), PaaS (Platform as a Service) et IaaS (Infrastructure as a Service).

Globalement la sécurité du cloud est bien distincte entre la partie PaaS / IaaS et la partie SaaS. Cela se matérialise par le principe de modèle de responsabilité partagée. Lors de la consommation d’un service cloud, le client aura accès à un certain périmètre avec un certain nombre de couches de données ou infrastructure suivant la catégorie de service cloud.

Ce modèle permet de déterminer sur quel périmètre du service la responsabilité du fournisseur de cloud ou celle du client est engagée. La partie sécurité va elle aussi être partagée sur les couches de données sur lesquelles le client va avoir la responsabilité, cela demande donc au client de s’assurer de la sécurité de son périmètre.

Dans le cadre du SaaS, pour donner un exemple, Microsoft Office 365 est un service où le client intègre ses données et n’a pas accès à toutes les couches basses du service. Le client ayant peu d’accès à la configuration du service et par conséquent sur la sécurité, il peut exiger contractuellement un niveau de sécurité auprès de son fournisseur qui aura la main sur la configuration du service.

Au contraire, sur des solutions PaaS ou IaaS, le client aura accès aux couches inférieures et aura donc la responsabilité de les configurer pour se garantir de leur sécurité si elles ne sont pas gérées par le fournisseur de services. Le client peut toujours exiger certains éléments mais la responsabilité du client sera engagée sur une partie importante de la configuration et de l’utilisation sécurisée du service cloud.

La sécurité du cloud soulève particulièrement un sujet contractuel puisque ce n’est pas le service du client lui-même mais celui d’un tiers. Cela amène des enjeux de sécurité à part entière et en particulier la question de ce que le client peut exiger à son fournisseur en termes de sécurité des données. Ces exigences sont amenées à évoluer en fonction de la nationalité du fournisseur.

Cet enjeu de sécurité induit également des changements d’organisation. La consommation de service cloud doit impliquer de repenser l’organisation de la DSI et sa manière de fonctionner au sens large avec une inclusion de la sécurité dans les nouveaux processus. Dans cette démarche d’agilité, la sécurité doit également l’être avec des pratiques type DevSecOps.

Quelles sont les tendances du marché du cloud et de sa sécurisation ?

Il y a encore quelques années les clients étaient retissant à s’orienter vers des solutions cloud alors qu’aujourd’hui, le sujet fait consensus, il s’impose de plus en plus. Un des facteurs majeurs à son développement est la solution Office 365 de Microsoft Azure.

La tendance du marché côté client est de lancer des grands programmes de migration cloud afin d’être accompagné dans cette démarche, notamment s’ils doivent faire appel à un seul ou plusieurs fournisseurs. Le sujet du multisourcing est particulièrement important en ce moment. Les clients se demandent également comment organiser leur DSI afin d’adopter des principes agiles et DevOps et ainsi réaliser leur transformation de manière intelligente. L’objectif n’est pas de réaliser du “lift and shift”, soit migrer une application on-premise existante sans effectuer de modification ou de refonte en l’intégrant directement dans le cloud.

Les clients se rendent compte que la gestion du système d’information suppose des coûts très importants et que cela ne correspond pas au cœur de leur métier. L’offre cloud permet de laisser les entreprises avec cette expertise, les fournisseurs de services, réaliser la migration de ces plateformes cloud. Cela permet au client de se concentrer sur ses processus métier et réduire le time to market, le temps nécessaire pour réaliser une idée initiale et livrer un produit fini aux consommateurs.

En termes de sécurité, une tendance pour les grands programmes est d’accompagner de manière sécurisée les migrations cloud. Cela passe par plusieurs éléments :

• Un accompagnement sur la contractualisation avec le fournisseur cloud concernant le modèle de responsabilité partagée et ce que le client peut migrer ou non ;
• Sur l’organisation de la DSI pour qu’elle devienne DevSecOps, approche qui permet d’intégrer la sécurité dans l’ensemble du cycle de vie des projets, du développement à la mise en œuvre, en utilisant des méthodes flexibles et l’approche DevOps ;
• Pour les clients plus avancés ayant déjà entamés une migration et qui possèdent déjà un multicloud, l’objectif est de les accompagner dans l’harmonisation de ces différentes plateformes cloud et en particulier en termes de sécurité.

Du côté des éditeurs de solution de sécurité pour le cloud, la tendance est de proposer des offres multicloud mais tout en cloisonnant les différents types de cloud (IaaS, PaaS, SaaS) afin de proposer des outils spécialisés. Les outils dits CSPM (Cloud Security Posture Management) qui permettent de réaliser des contrôles de conformité sur des plateformes multicloud sont la dernière tendance du marché. Sur le volet chiffrement qui est un sujet sensible pour nos clients, la dynamique d’accompagnement du multicloud s’articule autour d’offres de service type HSMaaS ou KMSaaS qui permettent de provisionner des clés, appartenant au client – de type BYOK, utilisables d’un cloud à l’autre.

D’un point de vue technologique, la tendance de fond reste le serverless. C’est un modèle de développement cloud qui permet aux développeurs de créer et d’exécuter des applications sans avoir à gérer des serveurs. La conteneurisation et les technologies Dockers ou Kubernetes sont en cours de déploiement à grande échelle chez nos clients entrainant des grands enjeux de sécurité.

Quelles sont les difficultés que nos clients rencontrent sur les sujets abordés ? En quoi cela constitue un réel challenge ?

Les clients ayant une faible maturité sur le sujet qui sont réticents à migrer dans le cloud sont généralement les entités qui traitent des données avec un très haut niveau de confidentialité (ex : prestataire de santé, armement, etc.). Ils se demandent notamment comment ils peuvent faire confiance à une entreprise américaine. Actuellement quand on parle cloud, on parle principalement d’acteurs américains : Microsoft, Amazon et Google, qui possèdent la quasi-totalité du marché du cloud public.

Pour répondre à cette interrogation, on met en avant que lorsque l’on fait appel à un fournisseur de cloud, il faut une totale confiance envers lui. L’objectif est de définir la partie contractuelle en amont de la migration du client pour s’assurer d’une total confiance envers le fournisseur sur l’accès aux données qu’on va lui transmettre. Cela peut notamment passer par une garantie contractuelle, des contrôles de sécurité, etc.  À noter que le chiffrement n’empêchera jamais le fournisseur d’accéder aux données, il faut donc s’assurer de sécuriser le cloud contre les vraies menaces.

Certes, on accepte un risque infime que le fournisseur puisse accéder à ses données, puisqu’elles lui sont transmises, mais le risque reste négligeable par rapport au risque en tant que client d’effectuer une mauvaise configuration du service cloud. Ainsi, les principaux incidents de sécurité du Cloud concernent le vol de données exposées publiquement au travers de services de stockage (S3 bucket, Azure storage, etc.). La responsabilité du fournisseur n’est pas engagée dans ces cas-là puisque c’est au client de garantir la bonne configuration des services PaaS qu’il utilise afin qu’ils soient utilisés en mode privé et non exposé.

Cela nécessite bien évidemment un effort sur les compétences pour consommer des services cloud de manière intelligente tout en le sécurisant.

Pour les clients plus avancés, le vendor locking est un sujet dominant. Si demain, le fournisseur de cloud avec qui le client collabore est amené à arrêter son activité ou est indisponible pour une durée définie, le client perd l’accès à son SI. C’est d’ailleurs pour cette raison que les clients se tournent vers des stratégies multicloud.

Comment répondre à ces problématiques et comment Wavestone peut intervenir ?

Notre conviction chez Wavestone, c’est que le cloud peut être un facilitateur pour la sécurité du SI. Une porte d’entrée pour construire un SI sur des bases saines et s’appuyer sur des technologies qui fonctionnent. Vous pouvez en profiter pour mettre la sécurité au bon endroit dès le début et une des clés pour y arriver est l’automatisation.

L’automatisation doit être mise en place dans le déploiement, les infrastructures mais également la sécurité afin d’obtenir une véritable plus-value. Si le client pose les bonnes règles de sécurité et que ces règles techniques sont traduites dans les chaines d’intégration et de déploiement (CI/CD), le client aura la garantie que le déploiement ses ressources et infrastructures seront sécurisées dès leur déploiement.

Wavestone accompagne également les clients à contractualiser avec des fournisseurs cloud. Nous aidons nos clients à construire des landings zones, c’est-à-dire les bases des architecteurs de sécurité qui vont être déployée dans le cloud. Nos équipes sont intégrées dans des centres d’excellence cloud chez nos clients et travaillent tous les jours à la sécurisation des infrastructures de cloud. Nous avons également la capacité d’aider nos clients dans leur transformation agile et notamment sur les sujets DevSecOps, afin d’apporter la sécurité au plus près de leurs projets.

Quel avenir pour la sécurité du cloud ?

La tendance émergente du moment est le Zéro Trust. C’est un nouveau modèle de sécurité qui répond aux enjeux cloud et usages actuels de mobilités des personnes et de la donnée. Le modèle Zero Trust a pour objectif d’accorder l’accès sur le besoin d’en connaitre et donc de remettre la sécurité au plus proche des ressources.

L’objectif est de remettre l’utilisateur au centre avec la garanti du moindre privilège et de contrôler l’accès à une ressource à chaque fois que quelqu’un en exprime le besoin. Cette vérification se fera quelle que soit son origine même si c’est un collaborateur interne. L’identité et l’authentification sont au centre, tout comme les moyens de détection et de contrôle.

La définition des algorithmes d’attribution des moindres privilèges et la vérification systématique à chaque nouvelle demande d’entrée drainent de vastes sujets autour de la gouvernance des identités pour nos clients. Leur traduction technologique, comme avec Azure AD pour citer la technologie de Microsoft, nécessite de solides connaissances techniques et un accompagnement au changement pour être en mesure d’identifier et configurer les bons moyens d’authentification (MFA, attribution de droits temporaire, etc.) et de contrôles (Conditional Access Policy, sign-logs, etc.) disponibles.

Ce modèle est particulièrement adapté à un usage cloud puisque la plupart des fournisseurs de cloud public permettent l’utilisation de technologies plus fiables et configurables qu’on-premise pour gérer les identités, l’authentification et la détection.

Cet article Les enjeux et les tendances de la sécurité du cloud, interview de Vincent Ferrie 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.

Microsoft fait partie de ces acteurs de l’IAM pour le cloud. En raison de son rôle déterminant dans le SI « On-Premises » des entreprises, nous allons nous pencher de plus près sur sa solution : Windows Azure Active Directory (WAAD).

WAAD : une solution IAM-as-a-Service pour le cloud

Contrairement à ce que pourrait indiquer son nom, la solution Windows Azure Active Directory n’est pas un Active Directory hébergé dans Azure, la plate-forme cloud de Microsoft.

Officiellement lancée le 8 avril 2013, WAAD est décrit par Microsoft comme « une solution complète et sécurisée pour la gestion des identités et des accès dans le cloud. Elle combine des services d’annuaires principaux, une gouvernance des identités avancée, une gestion et une sécurisation des accès aux applications ».

Microsoft propose donc WAAD comme solution d’IAM-as-a-Service permettant, entre autres, de couvrir les applications hébergées dans le cloud. Contrairement à son approche « brique à brique » traditionnelle pour les services IAM On-Premises, dans laquelle chaque service est fourni par un produit spécifique, Microsoft adopte là une approche plus globale comme le démontre le tableau suivant :

Windows Azure Active Directory permet ainsi aux entreprises de :

• Étendre au cloud les identités gérées localement au sein d’un Active Directory On-Premises ;
• Gérer les identités et accès depuis le cloud, à la fois pour les applications cloud de Microsoft (Office 365, Dynamics CRM Online, Windows Intune), pour un nombre important d’applications SaaS du marché, mais également pour toute application que l’entreprise raccorde à WAAD ;
• Apporter une connexion unique (SSO) aux applications hébergées dans le cloud, voire aussi, dans certains cas, aux applications On-Premises ;
• Protéger les applications les plus critiques avec une solution d’authentification forte.

Notons que certains services proposés sont antérieurs à la date de lancement officielle puisqu’ils ont été introduits dès 2010 pour offrir les fonctionnalités de gestions des identités et des accès à Office 365. C’est ainsi que Microsoft a pu afficher les chiffres de 265 milliards d’authentifications réalisées et de 2,9 millions d’organisations clientes à la date de lancement de la solution.

Comment mettre en œuvre WAAD ?

Deux modes d’implémentation sont envisageables en fonction des usages que l’entreprise souhaite couvrir.

La première possibilité est une implémentation en stand alone, sans aucun lien avec les annuaires ou briques d’identités présentes dans le SI de l’entreprise. Cette absence de lien avec les infrastructures de l’entreprise permet de bénéficier rapidement d’une solution IAM pour le cloud. Néanmoins, cela impose de gérer spécifiquement le cycle de vie des identités (créations, modifications, suppressions), des mots de passe (initialisations, réinitialisations) et des habilitations (affectations de groupes).

La seconde possibilité consiste à « étendre les identités locales vers le cloud ». Ce type d’implémentation permet de déployer simplement des applications cloud et ce de façon transparente pour les utilisateurs. Pour cela, une synchronisation unidirectionnelle entre un Active Directory géré localement et WAAD est mise en place (via l’outil DirSync). Dès lors, les processus de gestion du cycle de vie des identités déjà en place au sein de l’entreprise se retrouvent étendus au cloud.

Et afin de permettre un accès sans couture aux utilisateurs à la fois aux applications cloud et aux applications hébergées dans le SI de l’entreprise, il est nécessaire de disposer d’une infrastructure de fédération des identités On-Premises.

Par ailleurs, il est possible d’utiliser un module d’authentification forte. Un téléphone est alors indispensable quel que soit le mode d’authentification choisi : One-Time Password par SMS, OTP par appel téléphonique ou encore notifications sur smartphone. Notons que ces fonctionnalités reposent sur la solution de l’éditeur PhoneFactor, racheté par Microsoft en octobre 2012.

Rappelons que Windows Azure Active Directory reste une solution d’IAM pour le cloud parmi d’autres. Dans un marché où des mouvements sont à prévoir dans les mois qui viennent, on peut se demander quels sont les véritables bénéfices de ces solutions, et ce qui les distingue les unes des autres. Des questions qui seront abordées dans un prochain article…

Cet article Identité dans le cloud : le marché se structure, quid de l’approche de Microsoft ? est apparu en premier sur RiskInsight.

Des craintes à relativiser …

Disponibilité du Cloud

Chaque incident touchant l’un des grands acteurs du Cloud fait la « Une » de l’actualité, mettant sur le devant de la scène la question de sa disponibilité.

Il s’agit pourtant d’un faux problème : les taux de disponibilité des services Cloud sont souvent  supérieurs à ceux des systèmes internes des entreprises. La situation, d’un point de vue médiatique, est comparable à celle des accidents aériens : bien que rares, ils choquent l’opinion et intéressent les journalistes beaucoup plus que les accidents de voiture, qui font pourtant annuellement plus de victimes. La disponibilité n’est donc pas un risque inhérent au Cloud. Il reste néanmoins une spécificité à laquelle il faut prêter attention : la connectivité avec le fournisseur Cloud. Si celui-ci utilise internet comme unique moyen d’accès à ses datacenters, le risque d’indisponibilité de cet accès et d’internet en tant que tel doit être pris en compte.

 Confidentialité des données

Mes données sont-elles isolées de celles des autres clients ? Les administrateurs peuvent-ils y accéder ? Il est important de remettre ces craintes en perspective. D’une part, toutes les données de l’entreprise ne sont pas critiques en termes de confidentialité. D’autre part, si ces questions se justifient dans certains cas, elles ne sont pas nouvelles et ont trouvé leurs réponses il y a déjà plusieurs années, à l’heure des premiers contrats d’externalisation IT ou de l’emploi d’administrateurs prestataires. Les principales différences résident dans l’éloignement potentiel et le degré de contrôle possible du fournisseur.

La confidentialité des données vis-à-vis des Etats reste un sujet plus complexe à adresser. Ces derniers disposent en effet de textes leur permettant d’accéder aux données présentes dans les systèmes hébergés sur leur sol. Les USA font souvent figure d’épouvantail, leurs textes ayant en plus une portée extraterritoriale (Patriot Act, FISAA). Ces textes permettent à la justice et aux forces de l’ordre américaines d’accéder aux données manipulées par des sociétés de droit américain quel que soit le client et la localisation des données. Le risque est donc que des Etats aient accès aux données dans un objectif d’espionnage économique. Ce risque est réel comme l’illustrent les révélations sur les moyens dont dispose la NSA. Mais là encore, la portée du risque est à mesurer. Seules quelques données ont un niveau de sensibilité élevé : étatiques (administrations, défense, etc.), stratégiques pour l’entreprise dans un environnement à forts enjeux concurrentiels, géopolitiques, etc.

 Conformité réglementaire

La conformité réglementaire (PCI-DSS, LIL…) des offres Cloud, notamment en matière de protection des données à caractère personnel est également un sujet d’inquiétude. La situation reste très variable en fonction des acteurs, même si des réponses techniques (localisation des données, chiffrement…) ou juridiques (Safe Harbour, contrat type de la commission européenne…) existent aujourd’hui chez la plupart d’entre eux.

… car la sécurité est au cœur de la préoccupation des fournisseurs

Très visibles et régulièrement attaqués, les fournisseurs majeurs de Cloud mettent souvent en place des équipes dédiées pour assurer la sécurité de leurs services. La sécurité est même devenue pour certains d’entre eux l’un  des principaux arguments de vente.

Attention cependant : tous n’assurent pas le même niveau de sécurité. Il reste donc important de préciser avec le fournisseur les mesures incluses dès la signature du contrat, d’autant qu’il est difficile de faire évoluer les mécanismes de sécurité d’un fournisseur quand ceux-ci ne sont pas prévus initialement. Certains fournisseurs de solutions « SaaS métier » de taille petite et intermédiaire négligent parfois la sécurité : les audits et tests d’intrusion ont pour ce type d’offres une importance accrue.

Vers une coresponsabilité fournisseur / entreprise

Analyse de risque : passer de l’intention à l’action

Suivre une démarche d’analyse de risque est impératif pour lever les freins relatifs à l’adoption du Cloud. La finalité de l’analyse n’est pas d’interdire le Cloud par défaut mais plutôt d’identifier les données sensibles afin d’accompagner les projets de la manière la plus sûre et la plus pertinente. L’implication des responsables sécurité dès le démarrage des projets est donc essentielle. Ils doivent identifier les risques que l’on peut réduire par des moyens techniques et organisationnels, et ceux résiduels impossibles à couvrir. Aux Métiers et à la Direction de décider ensuite si ceux-ci sont acceptables ou non pour l’entreprise. Et de revoir si besoin le périmètre de la démarche Cloud.

Des contrôles à ne pas négliger…

Durant le projet ou en amont lors de la phase de choix des fournisseurs, il est recommandé de poser des questions précises sur les mesures de sécurité pour ne pas laisser place à des réponses ambiguës. Par exemple, beaucoup de fournisseurs mettent en avant leurs certifications.

Il convient de vérifier le type de certification et le périmètre concerné. Un certain nombre d’acteurs du Cloud acceptent d’ailleurs de fournir des détails sur l’architecture de leur solution, après signature d’un accord de non-divulgation. La capacité à répondre rapidement et de manière détaillée aux questions permet de se forger un avis sur la maturité de l’offre proposée.

En outre, la possibilité d’auditer le prestataire Cloud est un bonus à ne pas négliger. Accepter un audit est une preuve de transparence du fournisseur et de confiance en son niveau de sécurité. Même si les plus grands acteurs anglo-saxons s’y refusent, il est toujours utile de poser la question, notamment pour des acteurs de taille intermédiaire.

Des référentiels émergents

Un outillage commence à voir le jour pour aider les entreprises à évaluer les risques et le niveau de sécurité inhérent. En France, l’ANSSI (Agence Nationale de la Sécurité des Systèmes d’Information) a publié un guide pour accompagner les démarches de type Cloud computing. Au niveau européen, l’ENISA (European Network and Information Security Agency) fournit une analyse générique mais complète des risques liés au Cloud. Enfin, outre- Atlantique, l’association Cloud Security Alliance, qui regroupe les acteurs majeurs, a mis au point la Cloud Controls Matrix. Cette matrice permet de comparer de nombreux fournisseurs sur des critères de sécurité précis. Bien que fondée sur les seules déclarations desdits fournisseurs, elle peut s’avérer utile pour comparer les offres.

Le chiffrement : graal de la sécurité Cloud ?

Parmi les solutions techniques permettant de réduire les risques du Cloud, le chiffrement se positionne en tête. Et si aujourd’hui son utilisation nécessite souvent de donner les clés de déchiffrement au fournisseur, des innovations technologiques se profilent. Elles permettront de transférer et de traiter des données à distance sans jamais donner au fournisseur d’accès direct. Bien qu’encore expérimentales, ces techniques, rassemblées sous la bannière du chiffrement homomorphique, méritent qu’on les suive avec attention.

Ne pas mettre ses responsabilités dans les nuages

Contrairement à ce que trop d’entreprises pensent, leur responsabilité ne s’arrête pas une fois la solution Cloud mise en production. Si le fournisseur est tenu de respecter un certain nombre

de règles de sécurité, le maintien du niveau de protection dans le temps relève aussi de la  responsabilité de l’entreprise. Pour cela, les bonnes pratiques appliquées au SI d’entreprise doivent être transposées au Cloud : gouvernance de la sécurité (processus, sensibilisation des utilisateurs), administration fonctionnelle de la sécurité, configuration des options de sécurité avancées, restriction des droits requis par les utilisateurs, formation des administrateurs, revue régulière des paramètres de configuration… Ceci est particulièrement vrai pour la gestion des identités et des accès, élément clé pour garantir la confidentialité des données dans le Cloud.

Cet article Sécurité et Cloud, un mariage de raison est apparu en premier sur RiskInsight.

Pour autant, même une fois cette démarche menée à bout, plusieurs doutes persistent.

Si l’actualité récente a fait éclater l’affaire PRISM , la réalité des accès aux données est pourtant connue depuis de nombreuses années.

 Les risques d’accès aux données sont réels, depuis longtemps

Les quelques années de recul et d’expérience sur le Cloud montrent que les craintes quant à l’accès aux données hébergées à l’étranger sont justifiées.

L’exemple le plus souvent cité est celui du USA PATRIOT Act : sur requête du gouvernement américain et après contrôle par un juge, toute entreprise américaine, ou située sur le sol américain, ainsi que tout citoyen américain (où qu’il soit), se doivent de fournir aux autorités un accès aux données auxquelles ils ont accès. Dans le cas d’une entreprise de droit américain, l’obligation s’étend en dehors du territoire national : si ses infrastructures sont situées en Union Européenne, la loi s’applique.

Le Syntec Numérique a publié un éclairage intéressant sur le sujet en avril 2013. On y précise notamment  qu’un contrôle par un juge peut être réalisé avant la divulgation des données… Ou après, donc trop tard pour l’empêcher.

Cette loi pose donc  en théorie le problème de la confidentialité des données. Dans la réalité, ces craintes se justifient principalement si les données manipulées ont un niveau de sensibilité très élevé : étatiques (administrations, défense, etc.), stratégiques pour l’entreprise dans un environnement à forts enjeux concurrentiels, géopolitiques, etc.

Pour autant, et c’est un aspect moins connu, la majorité des gouvernements mondiaux disposent de prérogatives équivalentes. Le grand cabinet d’avocats Hogan Lovells a publié une étude à ce sujet en 2012, incluant notamment un comparatif des législations de 10 grands pays sur l’accès aux données Cloud : beaucoup (dont la France) disposent de prérogatives similaires, parfois plus larges et moins contrôlées.
Pourquoi alors se focalise-t-on généralement sur le USA Patriot Act ? Principalement car les acteurs majeurs du Cloud sont aujourd’hui américains,  donc soumis à la législation américaine.

Cependant, ne considérer que l’aspect strictement légal est encore trop réducteur : l’entreprise doit également se demander si le pays sur le sol duquel ses  données critiques sont hébergées a des intérêts allant dans le même sens que les siens.

Dans tous les cas, les conseils de juristes spécialisés sont indispensables pour avoir une position précise et adaptée.

 Les fournisseurs français de Cloud computing, solution du problème ?

Sur le papier, stocker ou traiter ses données chez un prestataire de droit français sur le sol français semble la solution idéale…  en théorie seulement.

En effet, de nombreuses fournisseurs français ont des centres de traitement et de stockage dans le monde entier… Même si vos données n’y sont ni stockées ni traitées, ceux-ci pourraient être connectés aux centres situés sur le sol français (et donc permettre d’y donner accès à distance).

Au-delà des données, se pose la question des équipes décentralisées : un Cloud hébergé en France, mais dont les équipes d’administration sont situées aux quatre coins du monde (par exemple pour fournir un support 24/7) doit également faire l’objet d’attentions.

Une fois encore, tous ces risques sont à relativiser : ils ne concernent que les données réellement sensibles.

Entre protections juridiques et solutions techniques, la bonne parade reste encore à trouver

Un moyen de se protéger des divulgations indésirables pourrait consister en l’ajout de clauses contractuelles interdisant à son fournisseur de le faire. Malheureusement, ce dernier risque de ne tenir aucun compte desdites clauses lorsqu’une demande officielle de son gouvernement lui parviendra. Pire, dans le cas des lois américaines, il peut lui être interdit d’avertir le propriétaire des données que celles-ci ont été transmises (il s’agit du principe de gag order).

Dans certains cas, il est possible de prendre certaines précautions très spécifiques. Nous conseillons parfois à nos clients de demander l’isolation de leurs données  dans le datacenter du fournisseur, dans une salle sous alarme dont seule l’entreprise détient la clé. Là encore, cela n’empêchera pas un accès aux données, mais permettra au moins à l’entreprise d’en avoir connaissance.

Une véritable solution pourrait provenir de la technologie : un chiffrement adéquat des données permettrait de s’assurer que même en cas d’accès aux données, celles-ci sont correctement protégées. Cela nécessite des technologies de chiffrement de confiance (par exemple en France, qualifiées par l’ANSSI), afin que les données soient sécurisées sur tout leur parcours : pendant leur transmission sur le réseau, au moment de leur utilisation, et lorsqu’elles sont stockées dans le Cloud.

À ce titre, le chiffrement dit « homomorphique » constitue une perspective d’avenir intéressante…

Cet article Cloud et sécurité : mythes et réalité (partie 2) est apparu en premier sur RiskInsight.

En particulier, la question de la protection des données transmises, traitées et sauvegardées apparaît comme cruciale. Ces points préoccupent aujourd’hui les experts techniques, les managers d’information, et parfois même les directions des entreprises.

Le Cloud est-il sûr ? Que risque-t-on en l’adoptant ? Comment y assurer la sécurité de ses données ?

Un service moins cher n’est pas forcément moins sécurisé

Il faut voir les risques liés au Cloud comme proches de ceux existants sur l’externalisation et la virtualisation avec en particulier la perte de contrôle de ses données et les risques liés aux technologies utilisées (virtualisation des systèmes et des réseaux, automatisation d’un certain nombre de tâches, etc.).

Pourtant, de manière générale, nous constatons en France que le niveau moyen de sécurité des services Cloud est au-dessus du niveau moyen de sécurité des entreprises. Plusieurs facteurs expliquent cela.

Le fait de fournir un service informatique à l’état de l’art (et donc sécurisé) est le métier des acteurs du Cloud. Chez la plupart d’entre eux, la mise en place et le respect des procédures de sécurité fait l’objet d’une attention particulière. Par ailleurs, ils proposent un service industrialisé à de nombreux clients : les bonnes pratiques exigées par l’un peuvent souvent être appliquées à tous.

Ces fournisseurs sont, enfin, plus exposés que la moyenne des entreprises, et ont de vrais enjeux en termes d’image : la découverte de faiblesses de sécurité amène en général à une correction rapide.

Inversement, si un mécanisme de sécurité n’est pas offert par un fournisseur (de base ou en option), il sera malheureusement difficile de l’obtenir : en sécurité comme pour les autres fonctionnalités, les offres Cloud manquent souvent de souplesse.

Attention cependant, contrairement à une idée répandue, toutes les offres Cloud ne se valent pas : de véritables différences peuvent exister d’un fournisseur à un autre.

Des outils dédiés existent pour évaluer ses risques de sécurité

D’un point de vue sécurité, la démarche est celle – classique – de l’analyse de risque. Le but est ici d’accompagner les projets de mise en œuvre ou de migration vers le Cloud, et pas de les interdire.

Dans le cas du Cloud, un outillage spécifique commence à apparaître pour réaliser cette analyse. En France, l’ANSSI (Agence Nationale de  la Sécurité des Systèmes d’Information) a publié  un guide¹ pour accompagner les démarches de type Cloud computing. Au niveau européen, l’ENISA (European Network and Information Security Agency) fournit une analyse² générique mais complète des risques liés au Cloud.

Outre-Atlantique, l’association Cloud Security Alliance regroupant les acteurs majeurs du Cloud a mis au point son outil Cloud Controls Matrix³, qui permet de comparer de nombreux fournisseurs sur des critères de sécurité très précis. Si elle est basée sur les seules déclarations desdits fournisseurs, cette matrice peut néanmoins s’avérer utile.

Les comparaisons théoriques  ne suffisent pas

Il est parfois difficile de distinguer ce qui est présenté de ce qui est fait en réalité en termes de sécurité. Plusieurs critères permettent d’évaluer les fournisseurs.

Ils peuvent tout d’abord se prévaloir de différentes certifications : ISO 27001 (très adoptée et quasiment obligatoire aujourd’hui) et ISAE 3402/SAE 16 (très adoptées également, requises pour les groupes cotés aux États-Unis, dans la ligne de SOX). Des démarches spécifiques existent aussi dans certains domaines, comme pour les données de santé en France, ou PCI-DSS pour les données de cartes bancaires.

Pour autant, ces certifications ne sont pas toujours une assurance d’un niveau de sécurité adapté. Lors de la phase de choix des fournisseurs ou durant le projet, il apparaît nécessaire de poser des questions très précises, sans laisser de place à des réponses trop larges ou ambiguës.

Un certain nombre d’acteurs du Cloud accepteront d’ailleurs de fournir des détails sur le fonctionnement de leur solution, après signature d’un accord de non-divulgation. Des visites de datacenters sont aussi toujours très instructives, et permettent parfois de se forger un avis sur la maturité du niveau de sécurité de l’offre proposée.

Certains fournisseurs sont réticents à fournir des informations très précises préalablement à la signature du contrat, ils peuvent alors proposer l’ajout d’une clause permettant de dénoncer le contrat ultérieurement. Mais attention à ce mécanisme, une fois la mise en œuvre démarrée, faire marche arrière est presque impossible…

Enfin, la possibilité de contrôler le prestataire Cloud est un critère intéressant. Sa capacité à accepter un audit diligenté par ses clients est en effet une preuve de transparence, voire de confiance en son propre niveau de sécurité.

¹ : ANSSI – Externalisation, Cloud Computing : maîtriser les risques pour les systèmes d’information (http://www.ssi.gouv.fr/externalisation/)  

² : ENISA  – Cloud Computing Security Risk Assessment (http://www.enisa.europa.eu/activities/risk-management/)

³ : Cloud Security Alliance – Cloud Controls Matrix (https://cloudsecurityalliance.org/research/ccm/)

Cet article Cloud et sécurité : mythes et réalités (partie 1) est apparu en premier sur RiskInsight.

Le chiffrement « classique » : une réponse partielle aux inquiétudes

Dans ce cadre, l’envie de conserver une mainmise sur les données de l’entreprise émerge rapidement, et les technologies de chiffrement font leur retour sur le devant de la scène. L’idée serait de traiter au niveau du cloud des données chiffrées afin de limiter les risques d’écoute. Ceci est possible par exemple pour un service de stockage en ligne. Les données sont chiffrées dans l’entreprise puis envoyées sur le serveur, lors de l’accès elles sont déchiffrées localement par l’utilisateur. Cependant se pose rapidement la question de la capacité à traiter les données, en effet les attentes métiers vis-à-vis du cloud vont bien au-delà d’un simple espace de stockage !

Il est alors possible d’envisager un chiffrement uniquement au moment du stockage chez le fournisseur. Lors d’un traitement interne au service cloud (recherche de données, édition de bulletin de paye, calcul scientifique…) le fournisseur pourrait déchiffrer les données, réaliser le traitement puis chiffrer à nouveau. Cette méthode fonctionne techniquement mais elle ne répond pas aux multiples interrogations. En effet, pour que ce mécanisme fonctionne, le fournisseur doit disposer des clés de chiffrement. Mais qui nous assure alors qu’elles ne sont pas utilisées à mauvais escient ? Et ceci aussi bien par des employés du fournisseur, que des tiers (autorités ou pirates par exemple) qui auraient accès aux systèmes de gestion de clés.

Une solution à suivre : le chiffrement homomorphique

Depuis des années, une solution à ce problème mûrit dans la tête des chercheurs : le chiffrement homomorphique. Derrière ce terme complexe se cache une idée simple : pouvoir réaliser des traitements directement sur des données chiffrées, sans avoir besoin de les déchiffrer ! Depuis 2009, de nombreuses avancées ont été réalisées dans ce domaine en particulier au MIT. Récemment, une équipe d’IBM a même mis à disposition une implémentation concrète (code source à l’appui) de cette méthode. Aujourd’hui, il existe encore un grand nombre de limitations, en particulier par rapport à la vitesse de traitement ou les opérations réalisables. Il faudra également que cette méthode et son implémentation soient analysées par des experts en chiffrement pour en garantir la robustesse.  D’autre part, il faudra toujours que l’entreprise fasse l’effort de gérer correctement ses clés de chiffrement. Le quotidien nous montre qu’aujourd’hui c’est encore rarement le cas !

Une avancée à suivre de près !

Le chiffrement homomorphique représente une avancée importante dans l’industrialisation de l’informatique. Les annonces récentes ont été largement saluées dans les différentes communautés sécurité. Sa mise en œuvre pourrait lever les nombreux freins qui existent encore aujourd’hui par rapport à la localisation des données ou encore aux fournisseurs. Même s’il faudra encore attendre quelques années avant une possible démocratisation, il s’agit clairement d’un sujet à garder dans le radar de la veille !

Cet article Chiffrement : la clé d’un cloud computing sécurisé ? est apparu en premier sur RiskInsight.

La sécurité, une question négligée après la phase de contractualisation

Les limites posées par le SaaS sont aujourd’hui bien connues : difficultés d’adaptation du service aux besoins de l’entreprise, absence de possibilités d’audit, questions réglementaires, etc.

Pourtant, de plus en plus de services cloud sont adoptés, sans que la sécurité ne soit nécessairement un frein. Pour cela, une démarche classique d’analyse de risque est menée en évaluant les contraintes légales / réglementaires,  les mécanismes de protection des données, la gestion de la sécurité par le fournisseur, ou encore les conditions de réversibilité de la donnée.

Cette démarche est de plus en plus maîtrisée : de nombreux retours d’expérience et un outillage qui se professionnalise* amènent à faire des choix éclairés, en toute connaissance de cause des risques encourus, et donc parfois acceptés.

Malheureusement, la démarche sécurité s’arrête souvent là : à partir du moment où le sujet a été traité lors de la contractualisation, on considère qu’un bon niveau est assuré, puisque l’on a exigé du prestataire de s’en occuper !

Le maintien de la sécurité dans le temps est un enjeu régulièrement oublié, alors même qu’il est en partie du ressort de l’entreprise, et pas seulement à la charge du fournisseur.

Des sujets à inscrire dans la durée

Pour s’assurer que la solution cloud est déployée avec le bon niveau de sécurité, et maintenir celui-ci dans le temps, quatre grands thèmes sont à aborder en priorité. S’il s’agit de bonnes pratiques habituelles sur un SI d’entreprise, il faut aujourd’hui les adapter, voire les renforcer pour le SaaS.

•  La gouvernance : les services SaaS doivent être intégrés aux procédures de sécurité et des processus liés au service fourni. Il peut par ailleurs être utile de mener des actions de sensibilisation dans certaines situations.

• L’administration fonctionnelle du service est bien du ressort de l’entreprise : le fournisseur n’est pas en mesure de faire les choix fonctionnels à votre place (et ce n’est souvent pas ce qu’on lui demande) ! Pour l’aspect sécurité plus encore, c’est à l’entreprise de définir  et mettre en œuvre les fonctionnalités avancées disponibles, de restreindre les services au minimum requis par l’utilisateur, de former ses administrateurs… Ces aspects sont souvent les plus négligés, comme nous le constatons lors des audits que nous réalisons.
• Des contrôles réguliers peuvent et doivent aussi être mis en œuvre sur les parties auditables des services. Il s’agit en particulier de vérifier que les paramètres de sécurité sont inchangés, d’exploiter les logs sécurité, et de revoir les habilitations. S’il le permet, enfin, ne pas hésiter à auditer son fournisseur (visites de site, voire tests d’intrusion).
• Il reste enfin à traiter le sujet de l’IAM, enjeu transverse du Cloud, souvent peu ou mal maîtrisé de par sa complexité. Même si cette voie est souvent suivie, il faut pourtant éviter de recréer un compte dans le Cloud pour chaque utilisateur. Pour « synchroniser » les identités de l’entreprise dans le Cloud, il faut également éviter la multiplication des connecteurs  (et notamment ne pas en redévelopper un par fournisseur), sous peine de créer une situation ingérable. Deux approches sont aujourd’hui à prioriser : soit l’utilisation d’un outil de fédération d’identités interne (qui réalise la connexion avec la majorité des fournisseurs de SaaS), soit l’externalisation de l’IAM… dans le Cloud (!) en « Identity as a Service »

Le RSSI, garant de la cohérence des projets

Dans le cas du SaaS, le rôle des responsables sécurité de l’information est double.

D’une part, il s’agit d’accompagner les projets, en leur apportant des solutions transverses : un certain nombre de points peuvent être mutualisés en amont. C’est tout particulièrement le cas des sujets tels que l’IAM, qui doivent faire l’objet d’une approche unifiée et cohérente –  et surtout pas projet par projet.  C’est également le cas des questions légales qui doivent faire l’objet d’une réflexion globale amont.

D’autre part, la SSI demeure la garante du niveau de sécurité dans le temps : la Gestion Opérationnelle de la sécurité devra faire l’effort de partir à la conquête des nuages !

* On peut citer notamment le guide publié par l’ANSSI et la « Cloud Control Matrix » maintenue par la Cloud Security Alliance

Cet article SaaS et sécurité : entreprises, ne mettez pas vos responsabilités dans les nuages ! est apparu en premier sur RiskInsight.

Des sinistres de cette ampleur ont permis d’alerter les DSI sur leur exposition face aux risques naturels. La régularité et la violence de ces évènements climatiques ont poussé les entreprises à prendre des mesures pour faire face à de futures tempêtes de la dimension de «Sandy». Les leçons du passé ont-elles pour autant été retenues ? Ont-elles toutes réussi ce test grandeur nature ? si oui, comment y sont- elles parvenues ?

Les conséquences de l’ouragan « Sandy »

Annoncé comme une catastrophe majeure dans l’histoire des États-Unis, l’ouragan « Sandy » a capté l’attention de la plupart des DSI des acteurs économiques de la côte Est qui ont mobilisé leurs efforts pour déclencher leurs plans de continuité informatique. Ces PCI, mis à niveau depuis les attentats du 11 Septembre 2001, sont fondés notamment sur des procédés de géo-réplication.

Les acteurs du web et plus largement du marché du cloud sont plus enclins à communiquer sur leur capacité de reprise et à faire des retours sur les incidents subis que les entreprises traditionnelles. Les informations disponibles proviennent donc essentiellement de ces acteurs.

De nombreuses pannes d’électricité causées par la tempête, ont entraîné une indisponibilité partielle ou totale de services (Huffington Post, Gawker, Cafemon, Gizmodo, Buzzfeed, etc.) dans bon nombre de datacenters. Les hébergeurs et fournisseurs de services cloud Datagram et 75 Broad ont été indisponibles à causes d’inondations ou réserves insuffisantes de carburant pour le fonctionnement des groupes électrogènes.

« Sandy » a ainsi rendu apparente la vulnérabilité des nombreux datacenters présents dans cette zone (New York, New Jersey, et Virginie) des États-Unis. En effet, plusieurs centres de données géo-répliqués n’étaient distants que d’une centaine de kilomètres (150 datacenters) et donc dans le rayon d’impact de Sandy.

Ces dysfonctionnements mettent en exergue la nécessité, même pour des PCI bien pensés comme ceux de Wall Street, d’être mis à l’épreuve dans des conditions proches de la réalité, avant d’être jugés comme fiables.

 Des PCI à l’épreuve des ouragans

Certains opérateurs de datacenter, comme Telx, ont résisté à Sandy car ils avaient appliqué précédemment des tests simulant jusqu’au bout un sinistre. Par cette initiative, Telx a pu identifier certaines insuffisances dans son PCI comme la surchauffe de ses générateurs en mode dégradé et a donc pu limiter l’impact de Sandy.

Un cas d’école est celui de Buzzfeed qui, malgré le crash de Datagram qui hébergeait ses serveurs primaires, a réussi à réduire considérablement le temps d’indisponibilité de ses services. Cette réussite s’explique par :

• la mise en cache de la plupart de ses pages chez Akamai, le gestionnaire et diffuseur de contenu
• l’hébergement dans un second datacenter des données répliquées en temps réel.

La réplication de ces données a permis le rétablissement des services de Buzzfeed chez Amazon Web services (AWS). Quelques heures ont suffi pour assurer la migration complète des données vers AWS et ainsi basculer leur service sur les infrastructures d’Amazon. Cet exploit est à relativiser car il a nécessité la configuration manuelle d’une bonne partie du socle technique de Buzzfeed et reste donc peu applicable en l’état à un SI complexe.

Les leçons de « Sandy »

Chaque incident majeur est une façon pour les Grands Comptes d’apprendre par le réel et d’anticiper les futures catastrophes. Au-delà d’une stratégie multi-datacenters, Sandy a  mis en exergue la nécessité d’anticiper, de tester et d’adapter le PCI.

Elle a aussi révélé le cloud comme une alternative envisageable pour réaliser un PCI. Alternative que les offreurs cloud commencent à mettre en avant par le biais de leurs offres packagées de Disaster Recovery As A Service.

Les entreprises européennes et notamment françaises, qui ont moins l’occasion de mettre à l’épreuve de la réalité leur PCI, devraient néanmoins s’inspirer des retours d’expériences plus nombreux acquis par les américains. D’autant plus que les hébergeurs de cloud ne rechignent pas à communiquer sur leur stratégie PCI gagnante afin d’en faire un argument marketing. En effet, même si moins fréquentes, l’Europe n’est pas à l’abri de catastrophes équivalentes en termes d’impact à « Sandy ».

Cet article Les plans de continuité informatique des cloud à l’épreuve de l’ouragan Sandy est apparu en premier sur RiskInsight.

Le RaaS : fer de lance des « Cloud Recovery Services »

Comme pour beaucoup de ce qui tourne autour du cloud, il est parfois difficile de donner une définition précise de ce dont on parle, tant une même appellation peut cacher des offres différentes. Nous utiliserons la définition suivante : « Cloud Recovery Service => secours d’un système d’information sur une infrastructure virtualisée, hébergée par un tiers, disponible à la demande et facturée à l’utilisation. »

L’éventail des possibilités est très large :

•  d’une sauvegarde externalisée des données critiques en mode cloud (« Backup-as-a-Service ») …
•  …en passant par la construction par le client lui-même de son secours sur la base d’une prestation de type « IaaS » [2] …
•   …jusqu’à une offre complètement managée intégrant le suivi du SI nominal et des mécanismes de bascule planifiés. C’est ce type de prestations que l’on retrouve sous l’appellation « Recovery-as-a-Service ».

 Quel est l’intérêt de passer au RaaS ?

L’utilisation du RaaS résulte avant tout d’un choix économique. Sur le papier du moins, le secours paraît adapté au modèle de facturation du cloud (pas de sinistre > allocation limitée de ressources > coût d’utilisation réduit), alors qu’un secours traditionnel implique de stocker, héberger et faire évoluer des infrastructures, des serveurs et des applications sur un site de secours.

Mais à y regarder de plus près, les économies ne sont pas toujours au rendez-vous et varient grandement en fonction des applications. Si certaines d’entre elles, peu consommatrices de données, sont les candidates idéales pour le RaaS (des études indépendantes font état d’environ 80% d’économies [3] pour leur secours par rapport à l’approche traditionnelle), le ROI pour les applications plus lourdes et/ou pour lesquels les exigences de continuité sont plus fortes s’avère discutable. En effet, plus les RTO et RPO seront exigeants, plus le niveau de service devra être élevé (allocation renforcée de ressources, mécanismes de réplication des données site-à-site, liens sécurisés, supervision 24/7, etc.) entraînant une envolée des coûts à la clef.

Le RaaS s’assimile, à ce stade de sa maturité, au mieux à du « warm recovery ». En effet, il est aujourd’hui illusoire de penser que les solutions proposées permettront de la haute-disponibilité : délais d’activation, délais relatifs aux opérations de bascule notamment au niveau du réseau, délais de restauration en cas de corruption des données, etc.

En outre, le RaaS repose essentiellement sur des mécanismes de virtualisation de serveurs (le plus souvent restreints aux architectures Intel x86, à l’exception de quelques fournisseurs), que ne supportent pas tous les progiciels du marché, a fortiori les applications propriétaires des clients.

Ainsi, le fait de vouloir tirer pleinement parti de la compétitivité économique du RaaS tout en répondant aux besoins Métiers réduit son utilisation à une certaine catégorie d’applications. Ce faisant, il cantonne le RaaS en tant que solution complémentaire à un secours traditionnel, ce qui peut paradoxalement devenir une source de complexité, du fait de la cohabitation de deux SI de secours. Néanmoins, deux cas d’usage du RaaS émergent pour les organisations concernées :

•  La couverture des applications virtualisées ou éligibles à la virtualisation à coût optimisé
•  L’extension du secours à des périmètres qui n’auraient pas pu être intégrés au Plan de Continuité Informatique de l’organisation, pour une meilleure couverture au meilleur coût.

A qui s’adressent les offres RaaS ?

Étant donné son modèle économique et sa structure technique, le RaaS semble plus adapté aux moyennes structures (qui n’ont pas souvent la surface financière pour mettre en œuvre et gérer en propre un site de secours) et notamment à celles qui ont opéré la virtualisation de leur SI. Les études prospectives [4] le montrent : ce sont elles qui tireront la croissance de ce marché dans les prochaines années.

Les grandes organisations déjà dotées de Plans de Continuité Informatique seront probablement moins intéressées mais pourront néanmoins trouver dans le RaaS des réponses ciblées à certains de leurs besoins.

Le RaaS : une offre mature ?

Comme pour nombre de cloud services, le RaaS n’a pas encore atteint sa pleine maturité : en témoigne le foisonnement des offres et des prestataires notamment aux États-Unis et au Royaume-Uni. Au-delà des acteurs historiques de la continuité informatique se positionnent des pure-players des cloud recovery services et de plus en plus des hébergeurs informatiques, convertis au cloud.

Le marché se structure, les offres évoluent en recherchant notamment de la complémentarité avec les cloud services : des initiatives d’interopérabilité entre services IaaS et RaaS se font jour pour assurer du secours « cloud-to-cloud » par exemple.

A ce stade et en terme de couverture de risques, le RaaS doit faire ses preuves. Concrètement les infrastructures dévolues au RaaS reposent sur encore peu de datacenters. Le client qui souhaitera se prémunir de sinistres affectant des zones géographiques particulières (ou étendues) devra se rapprocher du fournisseur de service RaaS qui l’intéresse pour vérifier que son ou ses sites ne sont pas exposés aux mêmes risques.

En France, le marché reste jeune et sans retour d’expérience significatif de déploiement. Les grands offreurs français s’appuient, aujourd’hui, sur les infrastructures anglo-saxonnes ou nord-américaines de leur maison-mère (ce qui potentiellement impacte la qualité de service, le niveau de sécurité, les engagements contractuels, etc.). Reste donc aux acteurs, anciens comme nouveaux, à démontrer toute la pertinence de leurs offres, en particulier sur la gamme des services managés, probablement les plus recherchés par les DSI.

[1] On rencontre également l’acronyme DRaaS (Disaster Recovery-as-a-Service)

[2] IaaS : Infrastructure-as-a-Service

[3] « Disaster Recovery as a Cloud Service : Economic Benefits & Deployment Challenges »

[4] « Gartner Says 30 Percent of Midsize Companies Will Use Recovery-as-a-Service by 2014 »

Cet article Recovery-as-a-Service (RaaS) : une révolution pour le secours informatique ? est apparu en premier sur RiskInsight.

Certifier le management de la sécurité, pas un niveau de sécurité

Tout d’abord, bref retour sur un point majeur trop souvent oublié : la norme ISO 27001 ne certifie pas un niveau de sécurité, mais son management. Cette norme, qui énonce les exigences à mettre en œuvre pour l’implémentation d’un Système de Management de la Sécurité de l’Information (SMSI), vise à mettre en place le management de la sécurité et à s’assurer de son amélioration continue sur le périmètre de la certification.

Le choix des mesures et du niveau de sécurité en place est donc fait en réponse aux risques et exigences identifiés par les parties prenantes : un choix nécessairement validé par le management ! Contrairement à un standard « catalogue » comme PCI-DSS où toutes les mesures doivent être implémentées pour arriver à la certification, l’audit ISO 27001 ne vérifiera que les mesures sélectionnées comme apportant une réponse aux risques. Une différence de taille, qui pousse vers une sécurité pragmatique mais en contrepartie nécessite une analyse des risques de sécurité de qualité et une attention particulière de l’auditeur externe.

Un périmètre solide

De nombreuses entreprises affichent des certifications, mais il est souvent nécessaire pour les clients de s’attarder sur la lecture du périmètre pour en connaître la valeur : un périmètre très limité par rapport à l’utilisation de leurs données peut être trompeur !

Ce n’est pas le cas ici, puisque Google présente une certification ISO 27001 qui couvre l’ensemble des systèmes, collaborateurs, processus et datacenters qui permettent de délivrer le service Google Apps. Cela inclut les services  GMail, Google Talk, Google Calendar, Google Docs (documents, spreadsheets, presentations), Google Sites, Control Panel (CPanel), Google Contacts, Google Video, Google Groups, mais aussi les briques support (Directory Sync, Provisioning API, SAML-Based SSO API, Reporting API, Audit API). C’est un périmètre impressionnant au vu de la couverture des services, tant sur le plan fonctionnel que géographique !

Développer la confiance et diminuer le nombre d’audits

A l’heure où de plus en plus d’entreprises se posent la question de l’opportunité d’externaliser les services de bureautiques comme la messagerie, l’édition de documents, etc., rassurer les responsables de la sécurité en garantissant les meilleures pratiques de management de la sécurité ne peut qu’être positif en termes marketing. Au-delà de l’apport de confiance, c’est également pour Google la garantie d’une reconnaissance externe, sanctionnée par un organisme de certification indépendant, qui pourra diminuer le nombre ou la charge d’audits des clients. Un bénéfice opérationnel non négligeable – même si Google n’était pas très enclin à se faire auditer !

Si Google a largement communiqué sur l’obtention de la certification, la firme de Mountain View n’a pas été la première à se lancer dans l’aventure : Amazon web services et Microsoft Office 365 ont déjà fait l’objet de la mise en place de SMSI certifiés. Après les infogérants, l’ISO 27001 serait donc en passe de devenir le standard de référence pour la sécurité des services dans le Cloud : on ne peut que se réjouir de ce mouvement qui rassurera les entreprises clientes de ces services. Celles-ci ne doivent cependant pas considérer la certification comme un niveau de sécurité « garantie » et rester attentive aux périmètres et aux mesures mises en place concrètement.

Cet article ISO 27001, un passage obligé pour les fournisseurs de services dans le cloud ? est apparu en premier sur RiskInsight.

En matière de disponibilité, les promesses du cloud n’engagent que ceux qui y croient !

L’Hyper Cycle 2011 du Gartner a positionné en août dernier le cloud dans sa phase de « désillusion ». Force est de constater que les incidents à répétition que rencontrent les grands noms du cloud depuis l’année passée ne font que confirmer cette état de « disgrâce ».  Petit rappel des deux faits marquants de ce début d’année.

Le 29 février à 1h45 (GMT), la plate-forme de cloud services Windows Azure tombe sur 4 de ses 6 plaques mondiales pendant une durée oscillant entre 12h et 48h. Cette interruption de services a son origine dans un bogue logiciel générant une erreur de calcul de dates sur les années bissextiles ; à la décharge de Microsoft,  il est vrai qu’Azure ouvert en 2010 n’a pas connu d’autre année bissextile que 2012. Cette panne a laissé sur le carreau plusieurs sites clés, dont la fameuse place de marché du gouvernement britannique, le « CloudStore ».

Ce 7 mars vers 5h (GMT), le service Facebook tombe en panne plus de 3 heures sur les plaques  Europe, Afrique et Moyen-Orient. Principale cause avancée, celle de la défaillance des serveurs DNS européens de Facebook entraînant l’inaccessibilité du site. Pointés du doigt, les Anonymous ont démenti être mêlés à cet incident. En tout état de cause, le communiqué officiel de Facebook ne laisse filtrer aucune explication. Rappelons-nous que Facebook avait déjà rencontré un problème de configuration BGP en août 2010.

Ces deux incidents majeurs font écho aux non moins médiatiques pannes rencontrées par les promoteurs du cloud computing ; remémorons-nous les incidents de Google (trois en 2009, celle de 05/2010, puis de 02/2011 et 09/2011), d’Amazon et de son service EC2 (12/2010, 04/2011, 08/2011), du précurseur Salesforce.com (02/2008, 01/2009, 01/2010) et du plus récent VMware Cloud Foundry (05/2011).

S’agissant de « résilience », les atouts du cloud ont maintes fois été présentés, on citera en substance :

• Taux de disponibilité avantageux (Salesforce.com affiche 99,9%)
• Répartition et duplication des ressources sur des lieux géographiques différents
• Accessibilité permanente, en tout point du globe
• Standardisation de l’offre technique, facilitant sa reproductibilité sur les datacenters

Pour autant, le cloud n’en reste pas moins une machinerie complexe par construction ; du fait de l’empilement des services qui le composent, du volume des ressources qui le constitue et, paradoxalement, de leur répartition sur le globe.

Au-delà de cette complexité qui impacte les gestes d’exploitation et de maintenance au quotidien s’ajoutent également les risques posés par le modèle de standardisation retenu. Les effets d’une erreur de manipulation, d’un bogue ou d’une vulnérabilité se font ressentir rapidement sur tout ou partie des infrastructures sous-jacentes.

Difficile dans ces conditions, face à des offres « boîtes noires » peu dissertes sur leur fonctionnement interne, d’accorder un crédit sans limite aux niveaux de disponibilité avancés. Du reste, le cloud public, universel dans son usage et par sa fréquentation, ne permet pas de préjuger de la manière et avec quelle priorité seront traitées, en cas de sinistre, les entreprises (grandes ou petites) en regard des individuels que nous sommes.

Des axes de progrès pour une meilleure résilience du cloud

Ces incidents à répétition témoignent d’une maturité encore insuffisante du marché et des fournisseurs, qui fonctionnent encore pour certains « au coup par coup ». Pour autant, le tableau n’est pas si noir, le modèle vertueux d’amélioration continue se met en place, sous l’impulsion notamment de l’alliance CSA (cloud security alliance)  qui promeut de bonnes pratiques en matière de sécurité et de résilience du cloud, des exigences d’acteurs clefs et /ou de gouvernements (PCI DSS, FISMA, HIPAA, etc.) et, il faut bien le dire, au gré des incidents vécus.

D’autant que la problématique de continuité tout comme de sécurité est au cœur des préoccupations des fournisseurs de service ; en affectant la confiance de leurs clients, présents et futurs, elle touche directement leur business model. Rappelons-nous enfin que l’une des promesses essentielles du cloud computing est d’améliorer la résilience du service rendu, parce qu’il est précisément « partout dans le nuage ».

A y regarder de plus près, le nombre d’incidents rencontrés par les acteurs du cloud est équivalent sinon inférieur à ce que rencontrent les entreprises. Le principal facteur aggravant tient au fait que la surface d’impact est sans commune mesure avec celles des SI des entreprises (ce sont des dizaines de milliers voire de millions d’usagers qui sont touchés).

Les fournisseurs de service entrent doucement dans la phase de maturation de leurs offres ; ils renforcent progressivement leurs dispositifs de continuité, prennent davantage en compte le facteur humain (source indéfectible d’erreur !) et apprennent aussi à mieux communiquer auprès de leurs clients.

Mais il ne faut pas croire au cloud « infaillible ». Aussi, les entreprises consommatrices de services cloud doivent-elles prévoir des processus de continuité de leurs métiers les plus sensibles et de préservation de leurs données les plus critiques.

C’est enfin le prochain challenge des fournisseurs que de prouver et démontrer les performances de leurs services cloud face à ceux des SI des grandes organisations !

Cet article Panne Facebook : symptomatique de la résilience du cloud computing ? est apparu en premier sur RiskInsight.

Une fois de plus les Assises sont un succès, un succès à la fois grâce à une organisation de grande qualité mais aussi du fait de la présence de l’ensemble de la communauté française. RSSI, responsables des risques, DSI, éditeurs, constructeurs et cabinets de conseil, tous étaient là dans une optique de partage et d’échange toujours aussi fructueuse.

Quels sont les sujets d’actualités et les nouveautés rencontrées ?

Les sujets ont tellement été diversifiés qu’il est quasiment impossible de tous les citer. Si je devais le résumer les 3 mots clés les plus rencontrés, je dirais : cloud, consumersation et cybercriminalité. Ils ont été largement débattus et ont fait l’objet de nombreuses annonces innovantes. A l’inverse, je noterais une  plus faible représentation des sujets attenant à la sécurité applicative, pourtant au cœur de la protection aujourd’hui. Enfin, des sujets plus atypiques et prospectifs comme l’IPv6, ont fait leur apparition.

Finalement la gestion de risques et l’évolution du rôle du RSSI ont, une fois de plus, été l’objet de nombreuses discussions dans plusieurs ateliers, dont celui animé par Solucom. Le débat s’est élargi, touchant alors à des problématiques hors « sécurité », avec notamment une intervention de premier plan de Luc Ferry sur la multiplication des peurs dans notre société. J’en retiendrai que la peur ne doit pas être le premier élément de nos réflexions et que la gestion du risque ne doit pas être un frein au développement ou à l’innovation !

L’ANSSI a animé une plénière pour alerter la communauté et lui demander de revenir aux fondamentaux de la sécurité, quelle est votre analyse ?

Je pense qu’aujourd’hui la communauté sécurité connaît bien ces fondamentaux (gestion d’identité, correctifs, antivirus, durcissement…), mais elle est confrontée depuis plus d’une dizaine d’année à la difficulté de les faire appliquer. Les équipes techniques et les métiers rechignent, les directions ne comprennent pas.

Cet état de fait a amené la communauté à s’orienter d’une part autour de la gestion des risques, afin de  concrétiser et d’expliciter en termes « métier » les impacts potentiels, mais aussi d’autre part dans la publication de nombreuses normes ou réglementations pour aider ou « forcer » l’application de ces mesures. Pourtant, cela n’a marché qu’un temps et la plupart de ces initiatives se sont transformées en sécurité « cache sexe » comme le disait Patrick Pailloux. Cela est un vrai drame car ces démarches pourtant de qualité sont trop souvent dévoyées !

A mon sens, aujourd’hui, la communauté sécurité manque de leviers pour convaincre les directions et les métiers. Elle manque également de support managérial pour réellement sanctionner et faire évoluer des pratiques déviantes souvent rencontrées. Les récents incidents médiatiques sont une aide mais la logique du « cela n’arrive qu’aux autres » est encore trop répandue

L’ANSSI, grâce à son message « back to basics », joue un rôle de premier plan. Mais elle pourrait aller plus loin en faisant part régulièrement de leur « thermomètre » du risque tel qu’évoqué durant la plénière afin de faciliter la sensibilisation des donneurs d’ordre.

Il faut arrêter de minimiser l’exposition de la France aux menaces cybercriminelles. L’illusion de sécurité est bien trop répandue aujourd’hui et j’espère que  les messages forts de la plénière aideront à changer cette situation.

Cet article Trois questions à Gérôme Billois sur les Assises 2011 est apparu en premier sur RiskInsight.

Une nouvelle bataille juridique s’ouvre entre les États-Unis et l’Europe. En jeu cette fois-ci, le Cloud Computing. L’’affiche ? USA Patriot Act Vs. Directive Européenne de protection des données à caractère personnel.

D’un côté, l’USA Patriot Act. Véritable épouvantail de l’externalisation et fer de lance de la lutte antiterroriste US, il autorise les écoutes et la capture de données par les autorités américaines, avec un encadrement judiciaire permettant de le faire à l’insu de leur propriétaire… Il constitue l’argument le plus précieux des opposants de l’hébergement de données aux Etats-Unis.

De l’autre, la Directive européenne pour la protection des données à caractère personnel. Mère européenne de la Loi Informatique et Libertés française, elle encadre fortement le traitement de données en dehors de frontières de l’Union et, plus généralement, leur accès non légitime et non autorisé par le responsable de traitement. Bien plus, elle le rend pénalement responsable de tout accès tiers non signalé aux propriétaires des données.

Au centre, Microsoft. Le géant de Redmond consent des efforts importants pour être en conformité avec les réglementations sur les données à caractère personnel. En particulier, leur adhésion aux principes du Safe Harbor , qui, en dépit de certaines limites, constitue une garantie jugée suffisante par l’Europe pour que soit autorisé le transfert de données à caractère personnel vers une entreprise américaine. D’autre part la mise en place d’un Cloud européen, aux serveurs dédiés et localisés strictement au sein des frontières de l’Union ensuite, offre une solution simple pour la conformité.

A l’origine de la bataille, une conférence dédiée au lancement d’Office 365. Le directeur Royaume-Uni de Microsoft a alors reconnu tout haut ce que bon nombre de spécialistes du secteur murmuraient déjà : son siège social étant domicilié aux Etats-Unis, Microsoft est soumis au droit national… et doit donc appliquer l’USA Patriot Act y compris sur le sol européen.

Et ceci est vrai pour l’ensemble des fournisseurs américains de services de Cloud computing ! Ils pourraient ainsi être amenés à communiquer aux autorités américaines des données de leurs clients européens, en dehors de tout cadre légal national ou communautaire.

Cette transparence soudaine signe-t-elle le début de la fin du Cloud computing made in USA ? ou s’agit-il d’une opportunité de croissance inespérée pour les fournisseurs européens ? Doit-on s’attendre à une migration massive des premiers vers les seconds ?

Ce qui est vécu comme une ingérence américaine sur le terrain législatif communautaire est aujourd’hui examiné par la Commission Européenne, qui s’est saisie du sujet.

Sans préjuger en rien des conclusions des débats d’ores et déjà très animés sur le sujet, cette bataille mérite d’être suivie avec attention.  Et permet de rappeler l’importance d’une analyse de risques, y compris juridiques, avant tout recours à un fournisseur externe…

Cet article La guerre des réglementations aura-t-elle raison du cloud computing? est apparu en premier sur RiskInsight.

De nombreux incidents ont rythmé l’année. Deux cas ressortent particulièrement : Stuxnet, premier virus ciblant spécifiquement des équipements industriels, Wikileaks et la fuite de données gigantesque qui a touché les Etats-Unis. 2010 a également été une année où de nouveaux usages se sont développés! La virtualisation, qui est maintenant définitivement entrée dans les datacenters, le cloud computing, qui fait ses premières preuves ou encore les smartphones et autres tablettes avec des premiers déploiements métiers mais également des premiers usages innovants d’utilisation d’équipements personnels.

Une nouvelle approche pour de nouveaux enjeux

L’ensemble de ces évènements a aussi montré la limite des approches sécurité classiques. Celles-ci sont basées avant tout sur une protection de l’infrastructure du SI. Nous ajoutons des mécanismes de sécurité sur les différentes briques que sont le poste de travail, le réseau d’entreprise, l’accès Internet, voir le datacenter. Mais cette approche ne permet plus de répondre aux nouveaux enjeux ! En effet l’information est de moins en moins traitée sur les infrastructures de l’organisation. Elle est de plus en plus partagée, avec des partenaires et des clients, accédées depuis des équipements mobiles voir personnels, parfois encore traitées sur des systèmes aux contours plus ou moins connus comme dans le cadre du cloud computing.
Une nouvelle stratégie de réponse doit être envisagée face à ces évolutions, une stratégie qui devra être basé sur un principe simple : protéger au plus près les informations les plus sensibles. En effet pour être efficace et pérenne la sécurité doit se rapprocher de l’information, voir être portée par l’information elle-même, pour pouvoir être mieux partagée tout en étant toujours sécurisée.

Quelles en sont les conséquences ?

Ceci nécessite de planifier des chantiers ambitieux, lié par exemple à la classification des informations les plus sensibles, à la mise en place de mécanismes de protections des données (chiffrement, DRM, DLP…) ou encore à l’inclusion des mesures de sécurité dans les applications (chiffrement, scellement, authentification, processus projet…). Bien entendu les fondamentaux de la gestion des identités jouent un rôle essentiel et devront être encore renforcés pour y ajouter la gestion des partenaires et des clients. Mais il faudra aussi faire évoluer les habitudes, en ayant un focus particulier sur les équipes en charge des applications au cœur de cette nouvelle problématique de protection.L’objectif de 2011 est de faire évoluer nos principes pour aller de la protection de l’infrastructure à une vraie protection des données. Voici une année qui s’annonce donc riche en projets et en challenge !

Cet article 2010 – 2011 : protéger les infrastructures ou protéger les données ? est apparu en premier sur RiskInsight.