La sécurité sur Windows Azure

  • Article

Les fondamentaux

 

Fiche pratique Azure

 

La sécurité constitue en informatique un élément sensible qu’il faut connaître et savoir utiliser. Le cloud computing accentue le besoin de sécurité surtout avec des applications et des données externalisées. Windows Azure propose de nombreux mécanismes de sécurité soit liés à la plate-forme, soit directement implémentés dans chaque service cloud.

La sécurité dans Windows Azure se fait à différents niveaux :

  • Sur la  plate-forme : gestion du compte, identification, cryptage, intégrité et disponibilité (données, instance…), effacement des données, etc.
  • Durant le développement : si le développement de l’application déployée sur le cloud computing n’inclut pas les mécanismes de sécurité préconisés par les bonnes pratiques, l’application aura des failles de sécurité exploitables
  • Dans les services : SQL Azure, AppFabric…

La sécurité « de base » de la plate-forme

Windows Azure, en qualité de plate-forme de cloud computing, expose de nombreuses fonctions qu’il est nécessaire de sécuriser : authentification des utilisateurs, gestion des identités et des comptes, cryptages des données, session utilisateur cryptée…

Ainsi, la gestion des identités doit à la fois simplifier le travail du développeur (via des frameworks) tout en étant transparente pour l’utilisateur. Le but est d’éviter l’accès non autorisé aux instances, comptes et données utilisateurs par une tierce personne ou par des logiciels tiers. Windows Azure s’appuie sur plusieurs composants pour cela : Windows Identity Foundation (WIF), Active Directory Federation Services et AppFabric Access Control.

Pour le développeur, il reste dans un modèle de développement connu. Par exemple, WIF s’emploie dans un projet ASP.Net et WCF SOAP, tout en apportant des protocoles ouverts et des standards du marché : WS-Security par exemple. Active Directory Federation Services est un rôle Windows Server qui étend l’annuaire Active Directory pour fournir une gestion d’identité. Surtout, il est interopérable avec les solutions IBM, Novell, SAP… Cette ouverture est importante car une entreprise possède souvent des logiciels et données hétérogènes. Et il faut être capable de l’intégrer, de s’interfacer avec, sans rompre la sécurité. 

Même sécurité sur Windows Azure que sur Windows

Il est préconisé d’avoir le même niveau de sécurité et les mêmes fonctions sur Windows Azure que sur Windows. Si ce n’est pas le cas, applications et données s’exposent à des attaques et à des problèmes d’intégrité et de disponibilité. Avant toute migration, vous devez lister les mécanismes de sécurité. N’hésitez pas à en discuter avec les architectes et les responsables sécurité de votre entreprise. Par exemple, le web role étant similaire à une application web, il est propice aux multiples attaques potentielles contre les sites web (injection de code, XSS, déni de service, usurpation d’identité, données en clair, etc.).

Sécurisez vos données

La donnée est au cœur du cloud et des applications. Windows Azure fournit plusieurs éléments. Shared Access Signature est peut-être le plus important. Il se place au niveau des échanges entre les web role de son application et le stockage Windows Azure. Il passe sur le protocole HTTPS. Il utilise la notion de token (fournissant une authentification et les accès), celui-ci doit avoir une vie courte pour éviter tout détournement non souhaité. Ce mécanisme se destine à l’accès à des blob non public. Sur la partie table de Windows Azure Storage, la surface d’attaque est réduite par le fait que SQL n’est pas supporté, donc pas de possibilité d’injection de code SQL ! Par contre, vous devez chiffrer les URL passant dans les requêtes REST, http. Windows Azure ne supporte pas encore Data Protection API (pour un cryptage persistant dans Windows Azure Storage).

D’une manière générale, il est vivement conseillé, si les applications communiquent avec des données localisées sur des serveurs internes ou sur des serveurs hébergés en dehors de Windows Azure, d’utiliser des sessions https pour sécuriser les transferts de données avec Windows Azure Storage.

Si nous prenons SQL Azure, nous retrouvons de nombreux mécanismes de sécurité disponibles sur SQL Server. Ainsi, l’administration de la sécurité reste identique sur de nombreux aspects même si des adaptations sont indispensables, cloud oblige : notion de base de données master quand on crée une base SQL Azure, par exemple. La base master sera indispensable pour plusieurs mécanismes (gestion des logins, création d’une nouvelle base, voir l’ensemble des bases…). Autre exemple, sur le pare-feu, il faut passer par le port TCP 1433. Toutes les communications entre une base SQL Azure et son application passent impérativement en SSL. Et il faut veiller à la bonne validation des certificats. En SQL Azure, le risque d’une injection SQL existe. Il est alors conseillé de passer par des requêtes paramétrées (quand c’est possible), limitant de facto la surface d’attaque.

Le niveau de sécurité des rôles

Une application Windows Azure est un ensemble de roles. Il est possible de donner, ou de refuser, des permissions d’accès à un rôle quand celui-ci est déployé dans Windows Azure. Les permissions dépendent du niveau de sécurité attaché à ce rôle. Deux niveaux sont disponibles : partial trust et full trust. Par défaut, un rôle déployé sera «full trust ».

Le partial trust délimite un environnement CAS (Code Access Security). Le CAS oblige à avoir un code de confiance et identifié comme tel par la plate-forme d’exécution. Le CAS peut avoir différents niveaux de restrictions d’accès au système, aux fichiers, aux données, à l’application. Si vous utilisez une confiance partielle dans votre Web Role ou Worker Role, vous devrez inclure certaines restrictions et une autorisation d’exécution manuelle dans le code. Ce niveau de sécurité évitera à un service corrompu de permettre un accès non autorisé à la gestion d’une instance Windows Azure, de récupérer des données.

C’est pour cela que le développeur doit isoler les rôles web et les fonctions web. Cette isolation améliore l’utilisation du partial trust de Windows Azure. Cependant, cela ne suffit pas. Le développeur doit aussi utiliser le design pattern Gatekeeper (gardien). Ce design pattern sépare les droits du rôle et les privilèges d’accès (au stockage). Ce problème de privilège d’accès aux services de stockage est particulièrement important dans une application ayant plusieurs rôles dont des rôles ayant un accès direct avec Internet et dont le niveau de confiance n’est pas assuré. Ces mécanismes doivent réduire la surface d’attaque contre les services de stockage. On pourra aussi mettre en place un design de multi clé de stockage bien que cette approche complexifie son architecture, son administration et le code. 

Windows Azure Connect : créer un « réseau privé » en toute sécurité

Nouvelle fonction de Windows Azure disponible courant 2011. L’objectif est de créer un « réseau privé » entre Windows Azure et des ordinateurs, par exemple, des postes de travail, un serveur. Que ce soient des PC physiques ou des machines virtuelles. Pratique quand vous avez besoin de communiquer, d’échanger entre votre cloud et un réseau local. Cette approche ressemble à la technologie DirectAccess de Windows 7 permettant de se passer d’un VPN. La sécurité est assurée par le protocole IPSec qui assure le cryptage et la sécurisation des connexions. Le poste client doit posséder un client spécifique « Windows Azure Connect connector ». D’autre part, pour les sessions, Windows Azure Connect s’appuie sur https (et le port 443, attention donc à la configuration des pare-feux).

Attention : Windows Azure Connect n’est pas encore disponible en production.

Windows Azure Connect

Les risques du web concernent aussi le cloud !

Les attaques les plus courantes restent les mêmes :

  • scanneur de port
  • Déni de Service : en Windows Azure, les machines virtuelles (instances) sont accessibles par le protocole Virtual IP Address, sécurisant les accès. En cas d’un déni de service, la supervision Windows Azure détecte l’attaque et bloque les instances et les comptes mis en cause.
  • Spoofing : les communications bas niveau de Windows Azure (Fabric Controller) sont chiffrées et utilisent des sessions https.
  • Injection de code (code, SQL…) : le développeur doit prévenir cette attaque en bordant strictement l’utilisation des champs de saisie.
  • Cross-site Scripting : attaque possible en web role. Dans ce cas, utilisez la parade : Librarie anti-XSS

Aller plus loin