Audit de sécurité et cloud computing

Depuis deux ans, la cinquième génération d’architecture (mainframe, client-serveur, web, SOA, cloud) est au cœur de toutes les discussions d’infrastructure. Un démarrage rapide des services, une évolutivité à la demande, peu de dépense en infrastructure sont toutes de bonnes raisons pour passer le pas ou y penser sérieusement.

Le modèle proposé par le NIST pour le « nuage » le décortique selon quatre modèles de déploiement :

  1. Privé,
  2. Mutualisé,
  3. Publique,
  4. Hybride.

Ainsi que trois modèles de services (du plus intégré au moins intégré) :

  1. SaaS (Sofware as a Service, ex : Google Apps),
  2. PaaS (Plateform as a Service, ex : Google App Engine),
  3. IaaS (Infrastructure as a Service, ex : Amazon EC2).

Hors du cloud privé hébergé en l’interne, dont les problèmes de sécurité sont semblables à une architecture classique, la problématique de l’audit de sécurité dans chacun des autres couples [modèle de déploiement – modèle de service] est différente.

Dans le cas d’un IaaS mutualisé, par exemple, comment faire pour auditer et se protéger des attaques suivantes :

  • Les attaques latérales venant des autres clients de l’infrastructure mutualisée ;
  • Une attaque sur le backoffice du cloud (zone d’administration privilégiée, etc.) ;
  • Une compromission de l’hyperviseur ou de la gestion du SAN.

Cette problématique ressemble à celle des DNS ou des messageries externes, qui est souvent mise de côté lors d’un audit ou d’un test de pénétration par manque de prévision (dans le contrat de location de service) ou, plus simplement, par impossibilité d’obtenir une clause concernant ce point. Cet état de fait qui existe depuis maintenant une bonne dizaine d’années risque peu de changer avec l’avènement du cloud computing.

Bien que le cloud permette une sécurité accrue du fait de l’importance de l’infrastructure gérée et donc – normalement – la mise en place d’une infrastructure de sécurité en proportion, le client final de ces solutions n’a que peu de moyens (certification dans le meilleur des cas, revue théorique ou extraction de configuration autrement) pour faire une véritable gestion de risque de ses données hébergées.

En conclusion, l’avancement des travaux issus des divers organismes (ENISA, CSA et NIST en tête) sur le cloud sont à surveiller attentivement dans les mois qui viennent. On peut d’ores et déjà s’aider de la matrice de contrôle de cloud du CSA afin d’affiner la prise de risque induite par un produit du cloud.

Thomas Rey