Découvrez notre société Contactez-nous

e-Xpert Solutions Genève

109, chemin du Pont-Du-Centenaire
CH-1228 Plan-les-Ouates / Genève
SUISSE

Tel. : +41 22 727 05 55 Fax : +41 22 727 05 50

e-Xpert Solutions Lausanne

Avenue de Gratta-Paille 20
CH-1018 Lausanne
SUISSE

Tel. : +41 21 802 26 78 Fax : +41 22 727 05 50
Contactez notre support : +41 22 727 05 56
Envoyez votre message

Swiss Security Hackademy

Suivez notre blog bilingue en sécurité informatique !

Retour aux articles

Le « Cloud » maîtrisé….

C'est possible avec nos solutions dédiées !


Auteur : Yoann Le Corvic

Date de publication : 10 septembre 2018 - Dernière mise à jour : 10 septembre 2018


Des challenges multiples !!! En effet, pour atteindre un niveau de protection des données en ligne avec leur niveau de criticité, et pour répondre aux exigences imposées par les régulateurs, plusieurs éléments doivent être réunis :

  • Garantir l’authentification des utilisateurs : qui accède à la donnée,
  • Garantir que l’utilisateur soit habilité à accéder à une catégorie d’information donnée,
  • Garantir que l’échange des données soit sécurisé et ne puisse être intercepté par un tiers, tant en consultation qu’en modification,
  • Garantir que les données et applications bénéficient, à minima, d’un niveau de protection contre les menaces avancées identique à celui offert on-premises.

Adopter une stratégie « cloud » ne signifie pas obligatoirement que toutes les clés sont données au fournisseur. L’objectif de cet article est de décrire comment assurer l’authentification des utilisateurs, le contrôle d’accès, l’intégrité et confidentialité des données d’entreprise ainsi que leur protection contre des menaces avancées.

Garder le contrôle de l’authentification

Lorsqu’un service en ligne est mis à disposition la première défense pour le protéger est l’authentification. Et même si le service est hébergé hors des murs de l’entreprise, le contrôle de l’authentification peut en revanche être conservé, en s’appuyant en particulier sur les concepts de fédération d’identité (SAML).

A titre d’illustration, nous allons détailler un use case dans lequel le client souhaite profiter des services Cloud de Office 365, tout en conservant une authentification reposant sur leur Active Directory Local, mettant en œuvre un mécanisme de SSO.

Besoins :

  • Externalisation de l’hébergement de la plateforme Exchange sur la plateforme Office 365 de Microsoft,
  • Authentification des utilisateurs connectés au réseau local (SSO obligatoirement),
  • Authentification forte pour les utilisateurs connectés depuis l’externe.

Approche retenue

Utilisateurs internes :

La décision retenue consiste à garder le contrôle total de l’authentification au sein du SI de l’entreprise en reposant sur le concept de fédération des identités, et le protocole SAML.

Le rôle clé de cette fédération, l’Identity Provider (IDP) peut être assuré par le module F5 Access Policy Manager. D’autre part, l’Active Directory interne peut être maintenu comme référentiel d’authentification, cela ayant le double avantage de :

  • D'être présent et opérationnel sans avoir de migration lourde à réaliser,
  • Et de conserver les « clés » de l’authentification car les mots de passe n’ont pas à être transmis au fournisseur Cloud. C’est la principale force du protocole SAML.

Sans rentrer dans le détail du protocole SAML, voici la cinématique des échanges lorsque l’utilisateur interne lance son client « Outlook » :

Le « Cloud » maîtrisé….
  • Le client outlook se connecte au serveur Exchange dans le cloud,
  • Le service étant protégé par le Service Provider, l’utilisateur interne est redirigé vers son Identity provider (IdP),
  • Le client se connecte sur son IdP,
  • L’IdP demande une authentification,
  • Le poste de travail étant dans l’AD et l’utilisateur déjà authentifié, il envoi les données d’authentification Kerberos,
  • L’IdP, valide les données d’authenfication et si tout est en ordre, transmet le Jeton SAML au client,
  • Le client revient vers le serveur Exchange, cette fois avec le jeton SAML, et la session est alors ouverte.

Utilisateurs externes :

Un collaborateur en déplacement peut également utiliser le service dans le cloud, et son authentification est toujours validée en interne. Mais le contexte dans lequel un PC sur internet se trouve étant plus incertain, un niveau d'authentification supplémentaire est généralement exigé.

C’est d’ailleurs une recommandation forte. Par exemple, l’utilisation d’un certificat, d’un OTP, d’une notification Push … en plus des crédentiaux AD.

Dans l’illustration suivante, vous retrouvez en gras l’étape qui change dans le cas d’un utilisateur externe.

Le « Cloud » maîtrisé….
  • Le client Outlook se connecte au serveur Exchange dans le cloud,
  • Le service étant protégé par le Service Provider, l’utilisateur interne est redirigé vers son Identity provider (IdP),
  • Le client se connecte sur son IdP,
  • L’IdP demande une authentification,
  • Le poste de travail étant sur Internet, l’IdP exige :

- Un certificat d’authentification,
- Le login et mot de passe Active Directory de l’utilisateur,
- … et la liste peut être complétée si nécessaire par d’autres mécanismes.

  • L’IdP, valide les données d’authenfication et si tout est en ordre, transmet le Jeton SAML au client,
  • Le client revient vers le serveur Exchange, cette fois avec le jeton SAML, et la session est alors ouverte.

Dans ces exemples, nous parlons de Office 365, mais bien évidemment, cela reste vrai pour bien d’autres systèmes Saas.

Nous voyons notamment les premières implémentations de solutions de mobilité comme VMWare Workspace One UEM dans le Cloud, qui peuvent également être authentifiés de cette manière.

Gérer les accès

La partie « Authentification » étant réglée, reste maintenant à gérer les contrôles d’accès. Comme toute solution hébergée, Microsoft donne accès à des consoles d’administration grâce auxquelles les droits d’accès peuvent être modifiés.

La mise en œuvre d’un Cloud Access Security Broker (CASB) peut être évaluée pour automatiser et gérer plus finement les contrôles d’accès.

Idem pour les questions de mobilité, afin de contrôler finement les accès venant des terminaux mobiles, l’utilisation d’outil comme VMWare Workspace One UEM permet de conditionner les accès aux ressources Office 365 au niveau de conformité des équipements.

Ce type d’implémentation devient relativement simple à mettre en œuvre, et est plutôt efficace.

Garantir la confidentialité

Garantir la confidentialité des échanges entre le poste client et les services « Cloud » est relativement aisé, en activant simplement le TLS sur les serveurs en question. Mais la problématique dans les implémentations SaaS n’est pas uniquement à ce niveau.

Dans les situations exigeant une garantie irréfutable de confidentialité des données (i.e. rendant impossible la lecture des données d’entreprise par des tiers), la seule solution réellement efficace est la mise en place d’un mécanisme de chiffrement utilisant des clés sous le contrôle exclusif de l’entreprise. De cette façon, même les administrateurs des plateformes Cloud hébergeant les données d’entreprise ne peuvent voire qu’une version inexploitable des données.

La mise en œuvre de tel système est plus complexe, et surtout bien plus critique : la perte des clés de chiffrement aurait à peu près les mêmes conséquences que la perte totale des données…

Comme pour le contrôle d’accès, l’utilisation de technologies CASB est nécessaire pour la mise en œuvre, et une étude poussée est plus que recommandée.

Le « Cloud » maîtrisé….

Le constat est sans appel, peu d'entreprises mettent en oeuvre ce niveau de sécurisation pour leur solution Cloud.
Pourtant, avec le renforcement des réglementations et la perpétuelle augmentation des vols des données, les entreprises devront se positionner pour sécuriser la protection de leurs données.

Garantir un niveau de protection adéquat contre les attaques avancées (APT)

L’adoption des services cloud par les grandes entreprises a également donné de nouvelles idées aux hackers. Que ce soit par l’extension d’attaques connues, de type phishing ou logiciels malveillants à destination des services cloud principaux mais également par le développement spécifique d’attaques ciblées sur ces services, comme c’est le cas du détournement de compte d’utilisateurs ou l’exploitation de failles inconnues (zero-day) inhérentes à la technologie sous-jacente de chacune des applications.

Jusqu’il y a peu, les solutions disponibles pour protéger les services cloud, de type Saas, se limitaient à celles présentées plus haut et ne permettaient pas de répondre de manière complète à l’ensemble des risques exposés. Avec l’arrivée de ces menaces, de nouvelles solutions de protection, spécifiques au cloud, font leur apparition, que ce soit par de nouvelles fonctionnalités offertes par les services CASB existants, ou à l’aide de solutions dédiées à ces vecteurs d’attaques, comme par exemple Check Point CloudGuard.

En ce qui concerne la composante technique, nous devrons faire face à 2 principaux challenges :

  • La méthode de déploiement de ces solutions : en général, elle s’articulera autour de 2 grands axes, soit via une intégration similaire aux services CASB (API, proxy, …), soit à l’aide d’un agent déployé sur les postes clients, ceci ayant pour inconvénient que le poste de travail devra être maîtrisé par l’entreprise. En fonction de la solution et de l’éditeur sélectionné, certaines méthodes ne seront peut-être pas disponibles. Il en va de même si d’autres solutions sont déjà en place dans le flux, l’une ou l’autre des méthodes sera à privilégier. Un exemple très concret : une solution DLP est déjà en place en mode Forward Proxy afin de détecter l’envoi de données sensibles à l’extérieur de l’entreprise, il conviendra dans ce cas, afin de ne pas complexifier la chaîne d’accès au Cloud, de mettre en place la solution de détection de menaces APT en mode API,
  • Le support des applications : afin de protéger efficacement une application ou un service, une connaissance approfondie de celui-ci, par la solution technique déployée, est indispensable. Ceci est d’autant plus vrai lorsque le mode de déploiement se fait via une intégration des API car il sera nécessaire de dialoguer avec l’application en question. À ce jour, les principales applications que sont Google G Suite, Office 365, Salesforce, ServiceNow, Box, ou encore Dropbox sont supportées par l’éditeur Check Point.

À ce jour, moins de 5% des entreprises ont franchi le pas dans cette direction mais nul doute que la tendance des prochains mois et années sera très certainement croissante… Dans un monde idéal, pourquoi même ne pas imaginer que les fournisseurs de services Cloud offrent ce genre de services nativement dans leurs applications ?

Les bonnes nouvelles sont... que c'est possible !

- S’appuyer sur un fournisseur « Cloud » pour héberger des applications (même sensibles) tout en conservant le contrôle de la protection des données,
- Garder le contrôle de l’authentification grâce à la fédération des identités,
- Et se protéger contre les attaques avancées à l’aide de solutions dédiées reste relativement simple.


Le challenge principal reste la confidentialité des données, qui nécessite que la gestion des clés de chiffrement (qui n’est pas un processus à prendre à la légère !) reste entre les mains de l’entreprise , et requiert l’implémentation de composants tiers (CASB) pour gérer les opérations de chiffrement / déchiffrement.