Les problèmes de sécurité propres –ou conséquence de- la virtualisation sont généralement difficiles à cerner. Nouvelle technologie, matraquage marketing des principaux vendeurs qui jurent leurs grands dieux de l’invulnérabilité de leurs produits (à tel point que virtualiser est parfois présenté comme une forme de protection absolue), effervescence de « solutions de sécurité » prétendant résoudre des problèmes que d’autres assurent ne pas exister (de l’antivirus au routeur) filtreur virtuel en passant par les outils de déploiement etc… il est difficile de s’y retrouver, même pour un administrateur chevronné.
Pour lui, et pour tous les DSI, CSO et RSSI en cours d’étude de faisabilité, l’Enisa vient de publier un document de plus de 120 pages, Cloud Computing, Benefits, risks and recommendations for information security. Comme d’habitude, une approche méthodologique précise, presque normative et chirurgicale de la gestion de risques dans une architecture Cloud. Les premiers chapitres s’attachent principalement à l’aspect virtualisation de la chose, puis à la notion de sous-traitance, de Saas, et même de coûts. C’est un document manifestement très important, qui permet à l’architecte d’un projet en « cloudification » d’établir une priorité des tâches et des fonctions selon une perception des risques « par tranche de travaux ».
Plus « léger », mais oh combien plus compréhensible lorsque l’on n’est pas un sorcier du virtuel, ce petit papier signé Tyler sur le blog de Neohapsys. « La virtualisation : où et quand ? » décrit en moins d’une page les principaux points névralgiques, une taxinomie des problèmes potentiels que l’on peut rencontrer dans une telle opération. Ainsi le manque d’attention que l’on peut porter aux serveurs-commodités (serveurs mail, DNS, back-office, ressources de fichiers …), qui disparaissent des listes de travaux d’entretien et de surveillance une fois qu’ils ont été « mis en boîte ». Ainsi encore la trop grande rapidité que l’on a à installer un serveur de virtualisation en mode « quick and dirty », sans que l’on ait eu la peine de durcir ledit serveur. Ainsi enfin les hiatus potentiels posés par les outils de développement, la quasi impossibilité sur certaines plateformes de poser des IDS ou des firewalls à l’intérieur du réseau virtuel reliant des serveurs tout aussi virtuels et hébergeant des applications métier qui exigent parfois certaine sécurité (l’auteur mentionne notamment des architectures contraintes par une homologation PCI-DSS).
