Sécurité : dans les coulisses d’Azure

L’édition 2013 du Microsoft Management Summit, qui se déroulait la semaine dernière à Las Vegas a été l’occasion de nombreuses plongées dans les coulisses des solutions de l’éditeurs. Et notamment dans celles liées à la sécurité d’Azure.

La sécurité du Cloud est une question qui préoccupe de nombreux décideurs informatiques. D’autant plus que l’opacité est souvent de mise en la matière. Lors de son événement MMS qui se déroulait la semaine dernière, Microsoft a levé le voile sur les mécanismes à l’oeuvre dans son Cloud, Azure. C’est Stevan Vidich, Directeur marketing d’Azure qui s’est livré à l’exercice avec exhaustivité. Il faut dire qu’avant d’occuper ce poste, il avait assuré les fonctions de planification de la sécurité et de la conformité d’Azure : «au cours des deux dernières années, nous avons consacré beaucoup de temps à discuter avec nos clients pour apprendre les principaux freins à l’adoption de notre plateforme dans cette catégorie.» C’est donc d’une certaine façon pour répondre directement à une audience plus vaste qu’il a animé une session dédiée à la sécurité d’Azure, «une première,» affirmait-il. L’occasion de dévoiler des informations «qui n’ont pas vocation à être publiques» et dont seulement une partie «figure dans nos audits de sécurité fournis aux clients après accord de non divulgation.» 

S’il encourage d’abord à consulter le Windows Azure Trust Center - largement méconnu à en juger par les réactions de l’audience -, Stevan Vidich ne s’en contente pas - même si l’outil permet de souligner que Microsoft a joué le jeu de la Cloud Security Alliance. 

Tout d’abord, Azure bénéficie de l’expertise des Trustworthy Computing Security Centers de Microsoft, qui interviennent notamment dans le processus d’alerte et de production de correctifs en cas de découverte de vulnérabilités sur les produits de l’éditeur - «ils sont également impliqués dans la lutte contre les logiciels malveillants et les virus dans Windows Azure,» explique Stevan Vidich. L’infrastructure d’Azure est quant à elle sous la responsabilité des Microsoft Global Foundation Services : ceux qui opèrent les services Cloud de l’éditeur. Des équipes «qui prouvent la qualité de leur travail au travers d’une longue liste de programmes de certification» : ISO 27001, SEC 1, 2 et 3, PCI DSS, autorisation FISMA, etc.

Avec Azure, Microsoft peut assumer la responsabilité depuis l’infrastructure physique jusqu’au middleware et au runtime ; le client n’est engagé que pour ses applications et ses données. Par exemple, «si vous décidez de monter vous-même une machine virtuelle avec un serveur SQL, vous pouvez le faire. Mais si vous souhaitez instancier un serveur SQL Server via Azure, vous obtenez directement deux copies de secours sans avoir à vous préoccuper de la redondance ou de la continuité de service.» 

Concrètement, sur le plan physique, Azure est produit dans des centres de calcul fortement sécurisés avec patrouilles, clôtures, caméras, alarmes, contrôle d’accès à deux facteurs - dont la biométrie. Mais de toute façon, «il n’est pas possible d’administrer Azure depuis ces centres de calcul; toute l’administration d’Azure est faite à distance, depuis notre NOC à Redmond.» Centre opérationnel qu’il est possible de visiter.

Une protection réseau très élaborée 

Au niveau réseau, Azure est isolé du réseau corporate de Microsoft et «il n’est possible d’entrer sur le réseau d’Azure en étant connecté à notre réseau corporate, y compris après authentification par notre annuaire Active Directory.» Surtout, «nous avons conçu Azure en estimant que des clients y viendraient avec l’intention de lancer des attaques sur la plateforme ou sur d’autres clients.» Dès lors, la plateforme est configurée pour éviter cela : «nous utilisons des VLAN - il y a en trois [...] il n’est pas possible de lancer des communications depuis le premier [qui abrite les VM des clients, NDLR] vers le contrôle d’infrastructure.» Une isolation assurée par des agents logiciels déployés sur les machines virtuelles des clients qui n’acceptent que des communications entrantes protégées par SSL et provenant du contrôleur. «Nous avons également élaboré ce que j’appelle une protection périmétrique d’hôte, basée sur les filtres de paquets IP de l’hyperviseur, et de la VM principale du noeud, ainsi que des pare-feu d’Azure, en place sur chaque VM, guest et hôte.» Tout le trafic issu des VM passe obligatoirement par les filtres de paquets pour prévenir les attaques par usurpation d’identité sur la plateforme, les communications depuis les VM vers des équipements de l’infrastructure, ou encore la réception de trafic qui ne leur est pas destiné ou s’avère inapproprié. Mais les clients peuvent eux-mêmes déployer des composants tiers de protection contre les intrusions ou des pare-feu pour applications Web. 

Azure est en outre doté d’une protection active contre les attaques par déni de service distribué (DDoS). «C’est une question majeure. [...] Nous appliquons des techniques standards de protection contre les DDoS [...] mais nous avons également déployé des systèmes de protection dédiés tiers qui fonctionnent en conjonction avec les équilibreurs de charge logiciels d’Azure.» Parmi eux, on compte notamment Arbor Networks. Azure est en outre capable de détecter les VM utilisées pour lancer des attaques DDoS et les désactiver. 

Tests d’intrusion, supervision... 

Les équipes d’Azure réalisent en outre des tests d’intrusion ( Pentest), elles-mêmes comme avec l’aide de tiers - «cela fait partie de partie de notre certification Fisma. [...] Mais nous ne publions pas les résultats de ces tests ni ne les communiquons à des clients.» Reste que Microsoft autorise ses clients à réaliser des tests d’intrusion sur leurs propres applications déployées dans Azure. 

Microsoft a en outre déployé pour Azure son propre «Monitoring and Diagnosis System», qui consolide les données de supervision collectées par des agents déployés sur chaque noeud de la plateforme - «on parle d’une centaine de To de données» - dans un dépôt unique pour les mettre à disposition d’un système de corrélation et d’analyse caché derrière des outils de consultation développés en interne par Microsoft, «essentiellement pour produire des alertes en temps réel sur les événements anormaux.» A cela s’ajoute un dispositif d’alerte avancée sur les logiciels suspects détectés dans la plateforme. Et bien sûr, tout le code d’Azure est analysé par Forefront avant déploiement. 

Mais les équipes des Global Foundation Services disposent également de leurs outils de détection et de prévention des intrusions et peuvent intervenir pour répondre à des attaques extérieures. Et Stevan Vidich de souligner que Microsoft s’engage contractuellement à notifier ses clients en cas d’incident impliquant leurs données. 

Une gestion étroite des identités et des accès 

Au-delà, Azure offre tous les mécanismes de contrôle des identités et des accès d’Active Directory. Mais si Stevan Vidich renvoie à d’autres sessions pour plus de détails sur ce point, il n’en est pas moins très loquace sur certaines spécificités d’Azure. Pour commencer, «si vous utilisez les services d’IaaS d’Azure, on ne peut pas accéder à vos VMs. C’est comme ça, c’est tout. Avec le PaaS, un client peut autoriser ponctuellement à le service client de Microsoft à accéder à sa VM» - avec un compte utilisateur temporaire, d’une validité de 6h en général, et dont toutes les activités sont enregistrées afin de pouvoir fournir une trace d’audit complète. Mais par défaut, «on ne peut pas accéder aux données clients. Et il n’y a pas de compte administrateur sur les VMs des clients.» C’est au client de créer les comptes utilisateurs de ses VMs et, surtout, de les surveiller. 

Les hôtes eux-mêmes disposent de logiciels quelque peu spécifiques : l’hyperviseur est basé sur Hyper-V mais dans une version réduite. L’hôte abrite plusieurs VM dont une, basée Root VM avec une forte isolation. Tout le trafic des VM est filtré par l’hyperviseur puis par la Root VM. Accessoirement, en PaaS, les «VMs sont provisionnés à partir d’un nombre limité de configurations connues» et d’un état connu, maîtrisé et considéré comme sûr à l’instant du provisionnement. La gestion des images et des correctifs est donc assurée par Microsoft - mais pas question pour l’éditeur de procéder à des changements disruptifs sans notification préalable avec 12 mois d’avance et les clients peuvent choisir de renoncer à l’application automatique des correctifs «bien que je ne le recommanderais pas». En IaaS, cela relève de la responsabilité des clients. 

Chacun chez soi 

Au-dessus, données et applications relèvent de la responsabilité des clients d’Azure. Et Microsoft «n’inspecte pas, ni ne surveille ni n’approuve vos applications. Nous n’avons vraiment aucune idée de la manière dont vous concevez vos applications ni de ce qu’elles font.» Certaines activités suspectes peuvent être détectées - DDoS, tentatives répétées d’ouverture de session - et Microsoft peut intervenir sur certaines d’entre elles comme Stevan Vidich le soulignait plus tôt. Mais pour le reste, l’éditeur n’interviendra que sur demande explicite de son client. Et d’évoquer des solutions tierces, comme le pare-feu applicatif pour Azure PaaS annoncé par Barracuda Networks lors de la dernière édition de RSA Conference; entre autres. 

Stevan Vidich détaille également les mesures de redondance et de réplication géographique des données, de sauvegarde - à charge des clients en utilisant les API proposées par l’éditeur; «nous ne proposons pas de service de sauvegarde ou d’archivage à ce jour» -, mais également de chiffrement et d’effacement des données. «Lors vous supprimez des données, nous supprimons immédiatement l’entrée d’index correspondante dans la localisation principale puis dans ses copies. [...] Aucun client n’a accès aux ressources brutes de stockage.» En outre, l’espace de stockage dans Azure n’est alloué que virtuelle, à la manière d’un Thin provisionning, et «il est dès lors impossible de lire des données effacées car l’espace disque correspondant n’est plus adressable.» Mais il n’y a pas de garantie contractuelle sur réécriture sur des données effacées. Toutefois, Microsoft applique une procédure de destruction physique des disques qui ne sont plus utilisés. Reste qu’il serait très difficile de faire le lien entre un disque physique et les propriétaires des données présentes compte tenu de l’architecture du stockage d’Azure, précise Stevan Vidich. En IaaS, le chiffrement des données - stockées et en transit - est la charge du client. En PaaS, le chiffrement doit passer par les API de chiffrement d’Azure ou par des outils tiers. 

Enfin, Stevan Vidich est revenu sur un point qui pourra paraître clé à certains décideurs : la localisation géographique des données. Contractuellement, Microsoft peut s'engager à ce qu'elles restent dans une certaine région du monde et n'en sortent pas. Toutefois, lorsque le support de l'éditeur est sollicité, un technicien d'un autre région peut être amené à intervenir à distance sur ces données - "elles ne sont pas déplacées mais c'est une personne d'une autre région qui accède."

Pour approfondir sur Administration et supervision du Cloud

Close