Qualys

Security CommunityLa communauté des experts sécuritéen savoir plus

SecurityVibesQualys Community

Main Content

Left content

Cloud public, privé, hybride : le retour du périmètre ?

auteur de l'article Jerome Saiz , dans la rubrique Produits & Technologies

L’irruption de l’informatique dans les nuages vient troubler le vieux débat au sujet du périmètre du SI. Et les vieux réflexes reviennent : si le cloud fait peur, profitons alors de ses avantages, mais en interne s’il vous plaît. Et si cela revient trop cher, gardons-en donc une partie seulement à la maison et mettons le reste dehors. Cloud public, privé ou hybride : où est le périmètre dans tout ça ?


La question du périmètre vis-à-vis du Cloud Computing ne se posait pas franchement dans un premier temps : le nuage était nécessairement « à l’extérieur », quel que soit le périmètre en question, puisqu’il était non seulement physiquement « ailleurs » mais surtout géré par une entité extérieure à l’entreprise. La vie était simple en ce temps là.

Et puis au fur et à mesure que les services dans le Cloud ont commencés à être réellement exploités en production (via des applications en mode SaaS notamment), la perception des utilisateurs s’est modifiée : certes, l’application de CRM est hébergée en dehors du SI de l’entreprise, mais les données sont créées, saisies et utilisées en interne exactement comme auparavant, et surtout sans distinction entre ce qui peut être confidentiel et le reste.

Ce qui n’a rapidement pas manqué de soulever d’inévitables et désormais bien connues questions liées à la confidentialité des données (vis-à-vis du fournisseur ou des autres clients du service), à la disponibilité de la plate-forme et parfois même à la réglementation, lorsque par exemple les données manipulées sont soumises à des restrictions géographiques (interdiction d’export en dehors de la Communauté Européenne, par exemple).

Le marché, jamais en reste lorsqu’il s’agit de trouver une alternative au désamour de ses clients, propose alors le concept de « Cloud privé ». Un terme censé désigner alternativement et de manière encore un peu floue l’abstraction de ressources internes afin qu’elles puissent être utilisées on demand (on en simplifie alors notamment le provisionning et l’extension), ou le déploiement en interne d’une version « privatisée » de l’application en mode SaaS (mais toujours gérée à distance par le fournisseur) ou bien encore un datacenter privé exploité spécifiquement pour l’entreprise par un fournisseur tiers, et chargé de fournir une ressource informatique précise en mode Cloud ou SaaS. Problème réglé ?

Pas vraiment. Si l’argument de la confidentialité est peu ou prou adressé, et si les gains en terme d’administration, d’extensibilité et de provisionning peuvent être là, la perte de l’aspect mutualisé (« multi-tenants« ) du Cloud Computing est un handicap : les coûts peuvent être plus élevés que si le même service était simplement acheté à l’extérieur et confié à un spécialiste dont la plate-forme et les ressources sont mutualisées. Et cela sans que le gain en confidentialité ne se justifie pour toutes les données traitées sur la plate-forme interne.

L’idéal ne serait-il pas alors de bénéficier du meilleur des deux mondes ? Disposer en interne de ressources « cloudifiées » afin de traiter les données sensibles – et profiter ainsi de l’extensibilité et du provisionning simplifié apporté par le modèle – tout en confiant simultanément à un nuage public le tout-venant afin de bénéficier de ses ressources à un moindre coût ? Après tout, l’une des caractéristiques propre au Cloud Computing est bien la présence d’interfaces logicielles (API) permettant des échanges normalisés et transparents (par exemple l’API AWS d’Amazon).

Il serait alors tentant d’appeler cela un « Cloud hybride », mais ce serait aussi probablement un raccourci un peu rapide. D’ailleurs, la vision abordée jusque à présent est relativement simpliste : la distinction entre nuage public et nuage privé s’entendait jusqu’ici de manière géographique (derrière le pare-feu ou à l’extérieur), ce qui nous ramène au bon vieux concept du périmètre, alors que la tendance générale serait justement d’aller aujourd’hui vers quelque chose de beaucoup moins figé.

Car les mentalités semblent désormais évoluer vers une approche de la sécurité centrée sur l’information : qui a le droit de la traiter, pour en faire quoi, et dans quelles conditions. Peu importe finalement où se trouvent le stockage et la ressource chargée de traiter cette information. Ces considérations ne sont en effet plus que des paramètres parmi d’autres à prendre en compte au sein d’une politique de sécurité, afin d’appliquer des restrictions particulières à l’information en fonction de son contexte. Doit-elle chiffrée ou non, l’accès offert est-il en lecture seule ou également en écriture, est-il possible de voir tel ou tel type de document à partir de telle ou telle connexion / identifiant utilisateur / ressource distante ?

Les termes du jours pour le Cloud Computing pourraient alors être plutôt au nombre de quatre : public et privé, certes, mais aussi interne et externe. Et comme l’on peut s’y attendre, cela donne lieu à de multiples combinaisons qui n’aident pas à clarifier le débat, ni à mettre tout le monde d’accord !

A défaut de mieux, Cisco propose sa définition , selon laquelle l’axe interne / externe concerne où se trouvent les ressources elles-mêmes (physiquement, de quel côté du pare-feu), tandis que l’axe privé / public concerne plutôt qui contrôle et est responsable des ressources, de leur agencement, et décide des processus de communication entre elles.

Tout le monde n’est pas d’accord avec la définition de Cisco, et cela n’est guère étonnant considérant qu’aucune définition définitive n’a encore vu le jour. Mais la proposition a le mérite d’ouvrir vers de multiples scénarii.

Il est ainsi possible d’imaginer un cloud privé reposant en partie sur certaines ressources fournies par un cloud externe, et en partie sur d’autres fournies par un cloud interne. Ou encore un cloud public « tirant » certaines données ou ressources d’un cloud interne.

De façon plus pragmatique, il est également possible d’envisager un nuage privé et interne capable en cas de montée en charge de se délester à la demande sur une plate-forme externe, publique ou privée (louée par un vendeur de datacenter habituel, par exemple).

Concrètement, hélas, les choses sont toutefois moins simples. La bonne nouvelle, c’est que des offres de cloud interne existent déjà (Eucalyptus ou Enomaly par exemple). La mauvaise, c’est qu’aucune API vraiment standard n’existe afin de faire communiquer les Clouds internes et externes entre eux, et que cela n’aide pas au développement d’interfaces communes (bien que l’API d’Amazon semble s’imposer comme standard de fait, à défaut de mieux).

S’engager aujourd’hui sur cette voie (et c’est possible, Appistry propose par exemple son Cloud IQ Manager afin de gérer des applications et services a travers différents types de nuages), est donc probablement encore une aventure exotique. Mais il semble qu’à moyen terme le modèle associant des ressources internes et externes, publiques et privées, et surtout gérées de manière centralisée, à la demande et abstraite, devienne une réalité.

Et le périmètre, dans tout ça ? Il passe plus que jamais à la trappe. La transition vers un modèle de politiques de sécurité basées sur des critères tels que le contexte d’accès et d’utilisation de l’information demeure une tendance forte. Des projets tels que le DLP, IAM et même le NAC (dans l’acceptation la plus moderne du terme) participent tous à cette transition, et pourraient devenir des pré-requis qu’il ne serait pas idiot de mettre en place aujourd’hui afin de ne pas se fermer les portes du Cloud public demain.

 

Vous avez aimé cet article?

Cliquez sur le bouton J'AIME ou partagez le avec vos amis!

Notez L'article

1 Star2 Stars3 Stars4 Stars5 Stars
Soyez le premier à évaluer cet article!

Participez ou lancez la discussion!

Right content

En bref

Newsletter gratuite

Suivez-nous…

Outils gratuits

SSL Labs

SSL Labs

Testez votre implémentation de SSL.


Freescan

FreeScan

Scannez votre réseau pour détecter les vulnérabilités et les malwares.


BrowserCheck

BrowserCheck Business Edition

Evaluez la sécurité des navigateurs au sein de votre entreprise.


Malware Detection

Malware Detection

Scannez vos sites web pour détecter les malwares et les menaces web