Ne confondons plus sécurité du cloud et sécurité dans le cloud

de | 30 août 2017

La souscription à des services dans le cloud n’a jamais été aussi aisée. Cette simplicité permet à tout acteur de l’organisation de souscrire à ces services sur ses propres budgets, dans beaucoup de cas sans en référer à la direction du système d’information, sans se soucier de la responsabilité de l’organisation et notamment sur les services et les données de ses clients et de ses partenaires (exposition aux attaques, non-conformité légale et réglementaire, etc.)

Cet article a pour objectif de repositionner la sécurité liée aux usages dans le cloud.

Note : j’utilise le terme organisation pour adresser à la fois les entreprises du secteur privé et les administrations publiques.

Il est essentiel de comprendre que souscrire à un service dans le cloud n’exonère par l’organisation de sa responsabilité vis-à-vis de ses collaborateurs, de ses clients et des partenaires, du fait que c’est un tiers qui propose et héberge le service. Bien au contraire, la souscription engage bien plus la responsabilité de l’organisation, car il s’agit d’une prestation externalisée où une partie, voire l’ensemble du traitement, n’est plus maîtrisé par celle-ci. L’organisation devant s’assurer que son fournisseur présente suffisamment de garantie de sécurité dans son service afin de garantir la disponibilité, la confidentialité et l’intégrité des traitement et des données de, et pour le compte de ses clients et de ses partenaires : c’est ce que je désigne par « la sécurité du cloud »

Par ailleurs, le fournisseur ne peut être responsable de l’ensemble des usages de ses services. En effet, en fonction du type de service souscrit, que je détaillerai plus loin dans ce post, un certain nombre de composants dans le cloud ainsi que les données hébergées dans ces services restent sous la responsabilité de l’entreprise : c’est ce que je désigne par « la sécurité dans cloud ».

Afin d’illustrer le propos, prenons l’exemple d’une machine virtuelle instanciée dans une infrastructure dans le cloud, la sécurité de l’infrastructure qui héberge la machine virtuelle est sous la responsabilité du fournisseur. Par contre, la machine virtuelle est l’ensemble des composants qu’elle héberge (système d’exploitation, logiciels installés, données, etc.) sont sous la responsabilité de l’organisation cliente du service :

  1. En cas de fuite de données suite à un problème de sécurité sur la machine virtuelle : l’organisation est responsable ;
  2. En cas de fuite de données suite à un problème de sécurité sur l’infrastructure et qui a affecté la machine virtuelle : le fournisseur est responsable.

La sécurité du cloud

Voici une analyse du partage des responsabilités en fonction du type de souscription dans le cloud :

Les services d’infrastructures dans le Cloud (IaaS – Infrastructure As a Service) : comme précisé dans mon précédent exemple, il s’agit de mettre à disposition une machine virtuelle sur laquelle les acteurs de l’organisation qui souscrit au service est en charge du contenu de la machine virtuelle et non pas le fournisseur du service.

Dans ce cas, les activités de sécurité, généralement opérés par la direction du système d’information, restent valables sur ces machines virtuelles.

  • Réseaux : adressage, segmentation, filtrage et dépollution des flux, etc.
  • Serveurs : durcissement, antivirus, patch management, etc.
  • (Pro)logiciels et composants techniques (frameworks, bases de données, etc) : qualifications de sécurité, patch management, etc.
  • Développements : revue sécurité du code.

Par ailleurs, l’organisation doit adresser les problématiques d’authentification, de gestion des droits ainsi que l’administration des utilisateurs.

Le fournisseur est responsable de la sécurité de l’infrastructure qui héberge les machines virtuelles et les composants d’infrastructures.

Les plateforme dans le Cloud (PaaS – Platform As A Service) : le fournisseur propose, principalement, l’ensemble de la pile logicielle pour l’exécution d’une application ainsi que des services de persistance de données accessibles aux applications.

Dans ce modèle, la responsabilité du fournisseur s’arrête aux environnements d’exécution et les interfaces d’accès aux services. L’organisation reste responsable de la sécurité de l’application et du type de données qui seront hébergées chez le fournisseur. Exemple relatif à ce dernier point, si une réglementation, qui interdit l’hébergement de certaines données dans le cloud, n’est pas respectée : c’est bien l’organisation qui est responsable, le fournisseur de service jouant uniquement le rôle d’hébergeur dans ce cas.

La principale activité de sécurité qui reste valable dans la souscription à ce type de service est la revue sécurité du code de l’application. La correction des failles de sécurité, et donc leur détection en amont sur l’application, restent sous la responsabilité de l’organisation.

Par ailleurs, l’organisation reste responsable de la gestion des utilisateurs et la gestion des profils, ces derniers étant spécifique aux applications.

Les services dans le cloud (SaaS – Service As A Service) : le fournisseur propose une application clé en main avec, dans certains cas, des capacités de personnalisation. Le fournisseur est responsable de la sécurité du service et de l’ensemble des composants qui héberge le service. L’organisation reste responsable :

  • De la gestion des utilisateurs ;
  • De la gestion des droits ;
  • Du type de données traitées et stockées dans le service dans le cloud.

La sécurité du cloud

Comme vu dans la section précédente, le fournisseur de services est responsable de la sécurité d’une partie plus ou moins grande des composants qui hébergent ses services. La sécurité de ces services est primordiale pour la sécurité des traitements et des données des organisations qui y souscrivent. Il est donc nécessaire que chaque organisation s’assure de la sécurité de son fournisseur lors du choix de celui-ci et tout au long de la souscription. Probablement, que la validation de sécurité n’est pas nécessaire pour les grands fournisseurs et historiques de cloud qui repose leur crédibilité sur la sécurité des services qu’ils proposent. Par contre, elle est nécessaire pour les fournisseurs de moindre importance ou plus récents sur le marché, des fournisseurs capables de mettre la sécurité de côte afin d’accélérer la mise à disposition de nouveaux services. Des certifications comme proposées par le Cloud Security Alliance (CSA STAR – Security, Trust & Assurance Registry) sont également une façon pour les fournisseurs de services dans le cloud d’homologuer la sécurité des services. Je ne considère pas les certifications ISO 2700* comme suffisante pour un fournisseur de solution dans le cloud, car celles-ci peuvent être biaisées par le marketing des offres : un fournisseur peut faire certifier un périmètre restreint ex. son siège et son SI de gestion, et afficher la certification… sans préciser le périmètre. Il est nécessaire de regarder un peu plus dans le détail de la certification pour comprendre son périmètre !

Afin d’évaluer la sécurité d’un fournisseur de cloud, je recommande de démarrer avec le référentiel du Cloud Security Alliance : Cloud Controls Matrix (CCM) et l’enrichir au fur et à mesure pour prendre en compte les spécificités de l’organisation et sa montée en maturité sur le cloud. Le référentiel est à soumettre au(x) futur(s) fournisseur(s) de service dans le cloud afin qu’il(s) positionne(nt) les mesures de sécurité, organisationnelles et techniques, qu’il(s) a(ont) mis en place. Cette approche est purement déclarative, donc dépendante de la compétence et l’expérience de la(les) personne(s) dans l’organisation qui analyse(nt) les réponses.

Le référentiel CCM est décomposé en 16 thématiques et chaque contrôle est décliné pour les trois types de souscription IaaS, PaaS et SaaS. Pour ne pas perdre les experts en sécurité : chaque contrôle est mappé aux exigences des principaux référentiels de sécurité du marché : ISO 27002 / 27017 / 27018, PCI DSS, COBIT, NIST SP800-53, Jericho Forum, etc.

Voici la liste des thématiques du référentiel CSA CCM :

Il est également important de se garder une option afin de réaliser un audit de sécurité complet du service proposé par le fournisseur, en particulier, si le service souscrit est critique pour l’organisation. L’audit permettra, en cas de doute, d’évaluer réellement les déclarations du fournisseur par rapport au référentiel de sécurité. Tout au long de la souscription, il permettra également de s’assurer que le fournisseur entretient bien la sécurité de son service à un niveau acceptable. Ceci se matérialise par l’intégration dans le contrat d’une option qui permet de réaliser un audit annuel, libre à l’organisation d’activer ou pas cette option.

Comme toute prestation externalisée, les aspects juridiques ne sont pas à négliger lors de la souscription à un service dans le cloud. Il est nécessaire d’adresser des sujets tels que :

  • la souveraineté des données (leur localisation géographique), en particulier si elles comportent des données à caractère personnel ;
  • la restitution des données dans un format lisible ainsi que leur suppression à la fin du contrat (il y aura un débat sur la propriété des logs des services qui peuvent contenir des données de l’entreprise…).

J’espère avoir adressé les différentes facettes, qui auraient pu être un peu plus détaillées, liées à la sécurité du et dans le cloud pour structurer vos actions.

7 réflexions au sujet de « Ne confondons plus sécurité du cloud et sécurité dans le cloud »

  1. Salim BECHIRI

    Merci, Post extrêmement intéressant.
    J’ajouterai que dans plusieurs cas, c’est les termes du contrat qui seront décisifs en cas d’incident de sécurité.
    Si le contrat est mal fait ou contient des zones d’ombres, c’est tout le monde qui va se renvoyer la balle 🙂

    Merci encore.

    Répondre
    1. Sabri Khemissa Auteur de l’article

      Merci pour le commentaire.

      Le problème avec les contrats de services dans le cloud :
      – pour les souscriptions aux services des grands fournisseurs : la négociation des termes du contrat est très très complexe, A mon sens, seuls les entreprises du CAC40 peuvent « essayer » et encore ce n’est pas gagné !
      – pour les souscriptions aux services des moyens et des petits fournisseurs : je ne pense pas que les entreprises disposent de suffisamment de recul sur ce type de services pour proposer un contrat « type » et pertinente

      Réflexion : probablement que c’est aux clients des services dans le cloud de se regrouper dans une sorte de « club des utilisateurs » pour travailler sur, par exemple, un contrat « type ».

      Répondre
  2. Ping : Ne confondons plus sécurité du cloud et sécurité dans le cloud | Cybercriminalité

  3. nasrallah

    très bon article, très concis et surtout pratique. pour la partie security dans le cloud qui relève du ressort de l’organisation, j’ajouterai qu’il existe des solutions qui peuvent ramener le niveau de sécurité dans le cloud à celui de on-premise, il s’agit de ce que GARTNER appel les CASBs ou cloud access security broker.

    Répondre
  4. Ping : Veille Cyber N145 – 4 septembre 2017 |

  5. Ping : Le Gartner publie son “hype cycle” 2017 des technologies de sécurisation des usages du cloud – Cybersécurité, confiance numérique, sécurité des nouveaux usages, objets connectés, etc.

  6. Ping : L’actualité cyber sécurité de la semaine dernière (du 11 au 17 septembre 2017) – Alerte Sécurité

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *