Le Cloud public Microsoft

Introduction

Avant d’appréhender les différents concepts propres à Microsoft Azure, il est nécessaire de comprendre rapidement ce que sont un abonnement (ou subscription en anglais), un groupe de ressources et une ressource.

Un abonnement regroupe tous les services Cloud Microsoft, pour un client ou un projet précis, c’est donc la frontière d’administration de vos ressources, mais aussi la frontière de facturation. Il s’agit donc d’un contrat qui vous lie à Microsoft pendant une durée précise, vous donnant accès aux régions Azure, et à toutes les ressources hébergées dans celles-ci. Une entreprise peut posséder plusieurs abonnements, accessibles depuis un e-mail professionnel (votresociete.com) ou personnel (compte Microsoft hotmail.com, outlook.com, gmail.com, etc.). L’abonnement est représenté par une clé orange :

Un groupe de ressources est un conteneur, créé dans un abonnement, qui contient vos ressources Azure. Il représente généralement un projet (projetx), un environnement (production, préprod) ou bien les deux (projetxprod). Comme toute ressource Azure, un groupe de ressources est créé dans une région et tous les droits que vous définissez pour le groupe sont propagés aux ressources présentes.

Si vous supprimez un groupe de ressources, toutes les ressources en son sein seront automatiquement supprimées. Il n’est pas possible d’imbriquer les groupes de ressources, leur structure est uniquement horizontale. Ce groupe de ressources est représenté par l’icône...

Implantation géographique

Les centres de données Microsoft Azure sont disponibles dans plus d’une soixantaine de régions du globe à l’heure de la rédaction de cet ouvrage. L’Amérique, l’Europe et l’Asie sont bien entendu concernées, ainsi que la Corée du Sud. En Europe, des pays tels que l’Allemagne, le Royaume-Uni, l’Irlande et les Pays-Bas disposent d’infrastructures Cloud Microsoft. La France est aussi concernée avec des datacenters situés à Marseille et Paris, ce qui veut dire que les données des clients français peuvent être stockées en France et donc soumises à la loi française (mais pas seulement). Nous le verrons plus loin, cela peut avoir une incidence concrète vis-à-vis des contraintes légales propres à chaque pays.

La liste des régions Azure disponibles est visualisable depuis le lien ci-dessous : https://azure.microsoft.com/fr-fr/global-infrastructure/geographies/

En cliquant sur le bouton Explorez le globe, un globe affiche les régions possédant physiquement un centre de données Microsoft, et celles en cours de déploiement. 

Afin de vous donner une idée de l’ampleur des moyens mis en œuvre par Microsoft pour développer l’infrastructure Azure, voici quelques chiffres :

Le tableau ci-dessous...

Centre de données

En 1989, Microsoft concevait son premier centre de données à Redmond. Depuis, de nombreux autres datacenters ont été érigés pour supporter ses services à destination du plus grand nombre, tels que l’application de communication collaborative Teams, le stockage OneDrive ou encore le moteur de recherche Bing.

Face à ces services ayant des besoins gigantesques, plus de 100 datacenters, répartis dans près de 140 pays, hébergent des millions de serveurs, avec des équipes pour les administrer disponibles 7 jours sur 7 et 365 jours par an.

La conception d’une telle infrastructure repose sur des principes importants, tels que la résilience des services, la résolution des pannes matérielles grâce aux logiciels et des solutions capables de s’autoréparer en contournant les défaillances. 

Les centres de données Microsoft utilisent un concept modulaire à base de conteneurs ou ITPAC (IT Pre-Assembled Component), permettant une extension rapide des infrastructures Cloud en fonction des besoins des clients.

L’ajout des conteneurs supplémentaires se fait ainsi simplement, tout en permettant d’augmenter la place en construisant des étages supplémentaires. La génération 4 de cette technique date de 2012…

Du côté des dimensions, un datacenter Microsoft a approximativement la taille de dix-sept terrains de football. Et à titre d’exemple, il y en a trois à Paris.

La sélection d’un site pour y construire un centre de données prend en compte plus d’une trentaine de facteurs, dont la proximité des clients vis-à-vis des infrastructures internet, mais aussi les énergies disponibles pour son fonctionnement, ainsi que les liaisons fibre.

Un centre...

Sécurité de l’infrastructure Azure

Les clients souhaitant migrer tout ou partie de leur système d’information dans le Cloud se posent souvent les mêmes questions légitimes, parmi lesquelles :

Ces cinq questions, loin d’être exhaustives, montrent les préoccupations des responsables de la sécurité des systèmes d’information.

D’un point de vue juridique, héberger ses données dans le Cloud soulève un certain nombre de difficultés vis-à-vis du respect de la législation en vigueur sur la protection des données personnelles, particulièrement dans le cas du Cloud public.

Une analyse de risque est donc fortement recommandée, préalablement à tout transfert des données vers un prestataire de Cloud.

En France, la CNIL est chargée de publier régulièrement des recommandations sur les obligations d’un fournisseur de Cloud au regard de la loi informatique et libertés.

En règle générale, le niveau de sécurité des infrastructures Cloud est supérieur à celui des sociétés, le budget alloué n’étant...

Accès à Azure via un poste de travail

Comme nous l’avons vu, Microsoft utilise des moyens financiers considérables pour protéger les données de ses clients, via une sécurité physique des équipements, mais aussi à l’aide d’une sécurité logique.

Plutôt que d’attaquer les infrastructures Azure, les personnes malveillantes peuvent subtiliser un accès privilégié à la plateforme de Cloud en compromettant un compte utilisateur, via des attaques par force brute, hameçonnage ou en poussant l’administrateur à exécuter un code malveillant inséré dans une pièce jointe. La grande disponibilité d’Azure rend les infrastructures plus vulnérables aux violations de comptes.

Le poste de travail de l’administrateur de l’abonnement Azure doit donc respecter des règles strictes, dont :

Accès à Azure depuis l’entreprise

Il existe plusieurs possibilités pour accéder depuis l’entreprise à la plateforme de Cloud Azure. Un tunnel VPN est une méthode usitée, car elle offre une connexion permanente et permet de filtrer certains flux, tout en offrant un service garanti par Microsoft. De plus, l’accès à vos ressources sera possible via l’espace d’adressage privé attribué à celles-ci.

Même si quelques entreprises autorisent tous les flux sortant vers Internet, réduisant ainsi la sécurité globale, il est nécessaire, autant que possible, de faire valider l’ouverture d’un flux par l’équipe sécurité puis que l’équipe réseau l’implémente.

Azure est une plateforme qui évolue constamment, ce qui implique donc une gestion rigoureuse de ce qui entre sur la plateforme ou en sort.

Afin de filtrer les protocoles autorisés vers Azure, Microsoft publie une liste des plages d’adresses IP (par région) utilisées par les services Cloud. Actualisée chaque semaine, cette liste est en fait un fichier au format JSON (JavaScript Object Notation) téléchargeable depuis l’adresse internet : https://www.microsoft.com/en-us/download/details.aspx?id=56519

En voici un aperçu :

En fonction du type de filtrage supporté par le pare-feu de l’entreprise, il sera ainsi possible de filtrer certains protocoles d’administration distante, tels que le Bureau à distance sur le port TCP 3389 ou SSH (Secure Shell) sur le port TCP 22 via les adresses IP privées spécifiées dans le fichier JSON.

Les ressources Azure étant bien souvent accessibles depuis des noms de domaine déposés par Microsoft, il peut être intéressant...

Service Level Agreement

Le Service Level Agreement (SLA) est un document définissant la qualité de service requise entre un prestataire, tel que Microsoft, et un client. Le contenu de la prestation, les modalités d’exécution ainsi que les responsabilités des parties sont écrits noir sur blanc.

Bien souvent, le SLA désigne la performance du service attendue, sa disponibilité ainsi que les pénalités éventuelles en cas de défaillance supérieure à un temps prédéfini.

Dans Azure, les contrats SLA sont définis par service, et ne concernent que le temps d’activité et de connectivité. De plus, les pénalités financières que Microsoft pourrait avoir à verser suite à une panne dépassant le SLA répertorié s’effectuent sous la forme d’un avoir sur l’abonnement du client, allant jusqu’à 100 % du montant total du (ou des) service(s) indisponible(s).

Un autre point important à prendre en considération, est que bien souvent, la recherche d’une disponibilité proche de 100 % implique l’utilisation de services additionnels payants.

Par exemple, si des machines virtuelles accessibles depuis Internet font partie intégrante d’un groupe de haute disponibilité (cf. chapitre Concepts de base - Réseau virtuel ou VNet), donc si elles possèdent au moins deux instances, Microsoft garantit une connectivité externe mensuelle d’au moins 99,95 %, soit une indisponibilité maximum par année de 4,38 heures. L’avoir sur ce service serait de 25 % en cas de connectivité inférieure à 99 %. Le temps de disponibilité mensuel est égal aux minutes disponibles maximum moins le temps d’indisponibilité...

Support technique

Microsoft propose un large éventail d’outils à destination de ses clients afin qu’ils puissent trouver des réponses à leurs questions, que cela soit par l’intermédiaire d’un compte Twitter @AzureSupport (https://twitter.com/AzureSupport), de forums pour les programmeurs (http://stackoverflow.com/questions/tagged/azure) ou de flux RSS (https://azurecomcdn.azureedge.net/fr-fr/updates/feed/).

Le support technique est disponible 24h/24 et 7j/7 en anglais uniquement, et durant les heures de bureau de la plupart des pays, de 9h30 à 17h00, en huit autres langues : espagnol, français, allemand, italien, portugais, chinois traditionnel, coréen et japonais.

Microsoft définit trois niveaux de gravité sur l’infrastructure Azure qui ont pour conséquence un impact sur l’activité de ses clients :

Quatre plans de support sur incident sont proposés, avec un délai de réponse qui peut être inférieur à 15 minutes selon le plan choisi. Tous incluent une gestion des abonnements pour toutes les questions de facturation, d’augmentation des quotas, etc.

Voici un résumé des trois plans de support facturés mensuellement (durée d’engagement de six mois avec renouvellement automatique) :

Abonnement

Comme nous l’avons vu précédemment, utiliser Azure nécessite obligatoirement un abonnement (ou subscription en anglais) qui regroupe tous les services Cloud Microsoft, pour un client, un environnement (production, dev…) ou plus rarement pour un projet précis. Un utilisateur peut accéder à plusieurs abonnements avec son seul e-mail (professionnel ou Microsoft) et travailler sur l’un ou l’autre uniquement, afin d’éviter la propagation d’une erreur sur plusieurs clients.

Dans l’image ci-après, le compte philoucho06@hotmail.fr dispose de quatre abonnements :

Plusieurs abonnements peuvent avoir un nom identique, mais leurs ID seront toujours uniques.

À chaque abonnement est associée une consommation en euros reflétant l’utilisation des services Azure, comme nous le montre la capture d’écran ci-dessus.

Une seule entreprise peut être détentrice de plusieurs abonnements, chacun représentant un de ses clients ou un environnement propre à son fonctionnement. Plusieurs types d’abonnements existent, dépendant de la situation et des besoins : abonnement gratuit, pour les start-ups, pour les entreprises, pour les abonnés MSDN, etc. Microsoft couvre un large panel d’utilisations du Cloud public et hybride.

Azure ne nécessite aucun coût de démarrage, ni frais d’annulation et la facturation s’effectue généralement à la minute, extrapolée à l’heure.

L’accès à un abonnement Azure s’effectue à l’aide d’une adresse e-mail et d’un mot de passe. Plusieurs interfaces permettent de déployer et d’administrer des services Cloud Microsoft, dont Azure PowerShell (cf. chapitre Interfaces d’exploitation - Azure PowerShell) et les portails...

Modèles de déploiement

Dans les anciennes versions d’Azure, une seule interface graphique nommée ancien portail ou portail classique permettait d’administrer les ressources du Cloud Microsoft. Le déploiement de plusieurs services Azure dans un ordre imposé nécessitait la création d’un script. Les ressources ne pouvaient être regroupées simplement, même si les services Cloud ont pallié en partie cette problématique.

Il en était de même pour supprimer plusieurs ressources : il fallait le faire manuellement, une par une… Utiliser une balise pour étiqueter une ressource ou générer des rôles via le modèle RBAC n’était pas non plus possible dans ce modèle de déploiement dit classique.

En 2014, Microsoft a introduit le modèle Azure Resource Manager, ainsi que les groupes de ressources (conteneurs regroupant des ressources Azure, telles que des machines virtuelles, des bases de données, des réseaux virtuels, etc.).

Lorsque l’administrateur souhaitait déployer des ressources, il devait sélectionner le modèle de déploiement, classique ou ARM. Néanmoins, certains services n’étaient disponibles qu’en modèle classique (Azure Active Directory), d’autres dans le modèle ARM (Azure Active Directory B2C, Azure IoT Hub), d’autres dans les deux (machines virtuelles, comptes de stockage et réseaux virtuels)…

Ces services étaient ainsi gérés par deux langages PowerShell différents, deux portails différents, etc. Il fallait donc passer constamment de l’un à l’autre suivant les besoins.

Un des buts de Microsoft était de migrer ses anciens clients du service classique au modèle...