Sécurité : dans les coulisses d’Azure

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."