Sécurité des applications dans le cloud : une situation encore… nébuleuse

Si la protection des réseaux et des infrastructures permettant de déployer des services de Cloud Computing est aujourd'hui l'un des points clés auxquels prestataires et clients prêtent particulièrement attention, il n'en va pas forcément de même pour la sécurité des applications qui y sont hébergées.

A qui incombe la responsabilité de cette protection ? Comment la mettre en œuvre ? Il y a encore un peu de flou autour de ces questions.
Il y a quelque temps, IBM a publié sur Twitter une infographie concernant la sécurité. En étudiant de près les statistiques (dont la plupart, soit dit en passant, proviennent d’une étude datant de 2011), j’ai noté l’affirmation suivante : « une entreprise moyenne subit 60.000 attaques par jour. »
IBM précise que le terme « moyenne » doit être compris dans le contexte de son enquête, laquelle portait principalement sur des grands comptes. Et même si je suis convaincue que certains experts ne manqueront pas d’exprimer leur désaccord (« c’est plus ! », « non, c’est moins ! », « ce n’est qu’une moyenne d’un sous-ensemble d’une sélection d’entreprises », etc.), cette affirmation soulève une question intéressante à propos des attaques et des applications basées sur le Cloud : si votre application est déployée sur le Cloud, comment savoir si — ou quand — elle fait l’objet d’une attaque ? Il est peut-être encore plus important de savoir si vous devez connaître la réponse. Après tout, le Cloud gère lui-même cette infrastructure et tous ces « machins » qu’elle englobe, n’est-ce pas ? Et parmi tous ces « machins », il y en a forcément un qui se charge de ces attaques, non ?

Réseau contre application

Bien sûr, bon nombre d’entreprises déclarent que leur fournisseur de services de Cloud se charge de contrer les attaques au niveau de la couche réseau.
Nous pourrions consacrer la totalité d’un billet à détailler les attaques (les exemples ne manquent pas) mais ce n’est pas le sujet. En règle générale, les attaques que les fournisseurs de services Cloud sont en mesure de détecter et de traiter (même de façon réactive, sinon proactive) sont menées au niveau de la couche réseau, et non de la couche applicative.
Je fais allusion aux attaques qui visent la vulnérabilité de vos applications ou de la plate-forme (serveur web ou d’applications) et parfois de la pile réseau (je pense notamment aux dénis de service de type SYN Flood). Les fournisseurs de services Cloud vous diront logiquement — et à juste titre — qu’ils ne maîtrisent en aucun cas les applications ou la plate-forme applicative (sauf dans le cas des fournisseurs de services PaaS ou SaaS) et que ce n’est par conséquent pas à eux de surveiller les attaques visant ces composantes.
Et ils ont (presque) raison. Même sur le Cloud, vous êtes responsable de la sécurité de vos applications, tout simplement parce que ce sont vos applications. C’est à vous, et non aux fournisseurs de services Cloud, de prendre les mesures nécessaires contre les vulnérabilités potentielles de la couche applicative –  qu’elles concernent les données, la logique, le comportement ou le code. Les choses se compliquent au niveau des couches de protocole (HTTP et TCP), où des ressources relativement réduites sont suffisantes pour lancer avec succès une attaque DDoS contre vos applications. Et pourtant, il n’existe pratiquement aucun moyen pour que l’instance d’une application se rende compte d’une telle attaque.

Ceci est dû au fait que pour détecter certaine attaques sur la couche applicative, il est nécessaire de disposer d’une certaine visibilité des caractéristiques du client, ainsi que de son comportement. Un client qui se connecte à partir d’un réseau local dont le débit peut atteindre 100 Mbits/s et qui tente volontairement d’utiliser une petite fenêtre TCP, ou semble recevoir des données à un débit nettement inférieur à ce qui est possible, peut très bien être victime d’une offensive visant à consommer et mobiliser les ressources applicatives. Une telle technique étendue à un nombre de clients suffisamment important provoquera un déni de service pour les autres clients.
De telles attaques qui s’inscrivent généralement dans le cadre d’une approche holistique de plus grande envergure (pour ne pas dire « coordonnée ») dans le but de distraire les entreprises de leur véritable objectif ne peuvent être détectées par l’instance d’une application, à moins qu’elle dispose d’une visibilité totale, de bout en bout. Sur le Cloud, c’est tout simplement impossible. La visibilité des caractéristiques des clients ne va généralement pas plus loin que leur adresse IP intégrée dans une en-tête HTTP personnalisée. Il est difficile de conclure à une attaque à partir d’une adresse IP, et le débit de transfert n’est guère significatif sans d’autres variables permettant de mesurer si un comportement est normal ou pas.
Même le déploiement de services traditionnels (pare-feu d’applications Web, pare-feu de type Application Delivery Firewall) n’apporte pas la visibilité requise, car ces services sont mis en œuvre par-dessus l’infrastructure abstraite - à base de services - et sont traités davantage comme des instances d’applications plutôt que des services d’infrastructure qui doivent disposer d’une visibilité dans le réseau. Certes, ces services minimiseront l’impact de nombreuses attaques menées contre la couche applicative et qui visent l’exploitation de la logique, de la plate-forme ou des données, mais ils ne sont pas nécessairement capables d’analyser entièrement la couche des protocoles en raison des nombreux niveaux d’abstraction qui les séparent des variables dont ils ont besoin.
Ainsi, alors que certains aspects de la sécurité des applications dans le Cloud incombent sans équivoque aux développeurs (ou à l’entreprise), d’autres nécessitent l’assistance du fournisseur, que ce soit sous la forme de services pouvant accéder aux informations requises ou d’un moyen de partager ces mêmes informations avec les services superposés à l’infrastructure.
Ce qui nous ramène à la situation présente : la sécurité des applications sur le Cloud reste pour le moins nébuleuse, et ce domaine présente à n’en pas douter un potentiel considérable pour de nouveaux services et de nouvelles solutions.