Isolation dans le cloud public Azure

Azure vous aide à exécuter des applications et des machines virtuelles (VM) sur une infrastructure physique partagée. L’un des principaux avantages économiques de faire tourner des applications dans un environnement cloud est la possibilité de répartir le coût des ressources partagées entre plusieurs locataires. Cette pratique de multitenance améliore l’efficacité en multipliant les ressources entre différents locataires à faible coût. Cependant, cela introduit aussi le risque de partager des serveurs physiques et d’autres ressources d’infrastructure pour faire tourner vos applications et VM sensibles qui pourraient appartenir à un utilisateur arbitraire et potentiellement malveillant.

Cet article décrit comment Azure offre une isolation contre les utilisateurs malveillants et non malveillants. Il sert de guide pour l’architecture de solutions cloud en proposant plusieurs options d’isolation aux architectes.

Isolation au niveau du locataire

L’un des principaux avantages de l’informatique en nuage est le concept d’infrastructure partagée et commune entre de nombreux locataires simultanément, ce qui conduit à des économies d’échelle. Ce concept est appelé multitenance. Microsoft travaille en continu pour garantir que l’architecture multi-locataire de Microsoft Azure supporte des normes de sécurité, de confidentialité, de confidentialité, d’intégrité et de disponibilité.

Dans le lieu de travail activé par le cloud, un locataire est un client ou une organisation qui possède et gère une instance spécifique de ce service cloud. Dans la plateforme d’identités fournie par Microsoft Azure, un locataire est une instance dédiée de Microsoft Entra ID que votre organisation obtient et possède lorsqu’elle s’inscrit à un service cloud de Microsoft.

Chaque répertoire Microsoft Entra fonctionne de manière distincte et séparée des autres répertoires Microsoft Entra. Comme un immeuble de bureaux d’entreprise, un annuaire Microsoft Entra est un actif sécurisé réservé à votre organisation. Par son architecture, Microsoft Entra isole les données et les informations d’identité des clients, ce qui évite tout risque de brassage. Cette isolation signifie que les utilisateurs et administrateurs d'un répertoire Microsoft Entra ne peuvent pas accéder accidentellement ou malicieusement aux données d'un autre répertoir.

Location Azure

La notion de tenant Azure (abonnement Azure) désigne une relation client et de facturation, ainsi qu’un tenant unique dans Microsoft Entra ID. Microsoft Entra ID et son contrôle d’accès basé sur les rôles Azure offrent une isolation au niveau du locataire dans Microsoft Azure. Chaque abonnement Azure est associé à un annuaire Microsoft Entra.

Les utilisateurs, les groupes et les applications de ce répertoire peuvent gérer les ressources dans l’abonnement Azure. Attribuez ces droits d’accès en utilisant le portail Azure, les outils en ligne de commande Azure et les API de gestion Azure. Les limites de sécurité isolent logiquement un locataire Microsoft Entra afin qu'aucun client ne puisse accéder ou compromettre les autres locataires, de manière malveillante ou accidentelle. Microsoft Entra ID s’exécute sur des serveurs « bare metal » isolés sur un segment réseau séparé, où le filtrage des paquets au niveau de l’hôte et le Pare-feu Windows bloquent les connexions et le trafic indésirables.

• Access aux données dans Microsoft Entra ID nécessite l’authentification de l’utilisateur par le biais d’un service de jeton de sécurité (STS). Le système d’autorisation utilise les informations sur l’existence de l’utilisateur, son état activé et son rôle pour déterminer si cet utilisateur a autorisé l’accès au locataire cible dans cette session.

• Les locataires sont des conteneurs discrets et il n’existe aucune relation entre ces conteneurs.

• Aucun accès n’existe entre les locataires, sauf si un administrateur de locataire l’accorde via la fédération ou en provisionnant des comptes d'utilisateur provenant d'autres locataires.

• Microsoft limite l'accès physique aux serveurs qui composent le service Microsoft Entra ainsi qu'à l'accès direct aux systèmes back-end de Microsoft Entra ID.

• Les utilisateurs Microsoft Entra n'ont pas accès aux actifs physiques ni aux emplacements, ils ne peuvent donc pas contourner les vérifications logiques de la politique RBAC d'Azure indiquées ci-dessous.

Pour les besoins de diagnostic et de maintenance, utilisez un modèle opérationnel qui s’appuie sur un système d’élévation de privilèges juste-à-temps. Microsoft Entra Privileged Identity Management (PIM) introduit le concept d’administrateur éligible. Les administrateurs éligibles sont des utilisateurs qui ont besoin d’un accès privilégié occasionnellement, mais pas tous les jours. Le rôle est inactif jusqu’à ce que l’utilisateur ait besoin d’accéder. L’utilisateur termine alors un processus d’activation et devient administrateur actif pendant une durée prédéterminée.

Microsoft Entra ID héberge chaque locataire dans son propre conteneur protégé, avec des stratégies et des autorisations pour et au sein du conteneur uniquement détenu et géré par le locataire.

Le concept de conteneurs client est profondément ancré dans le service de répertoire à toutes les couches, des portails jusqu’au stockage permanent.

Même si les métadonnées de plusieurs locataires Microsoft Entra sont stockées sur le même disque physique, il n’existe aucune relation entre les conteneurs autres que ce que définit le service d’annuaire, qui à son tour est dictée par l’administrateur du locataire.

Azure contrôle d'accès basé sur les rôles (Azure RBAC)

Le contrôle d’accès basé sur les rôles Azure (Azure RBAC) vous aide à partager plusieurs composants disponibles dans un abonnement Azure en fournissant une gestion d’accès détaillée pour Azure. Azure RBAC vous permet de séparer les tâches au sein de votre organisation et d’accorder access en fonction des besoins des utilisateurs pour effectuer leurs travaux. Au lieu de donner à tout le monde des autorisations illimitées dans un abonnement ou des ressources Azure, vous ne pouvez autoriser que certaines actions.

Azure RBAC a trois rôles de base qui s’appliquent à tous les types de ressources :

• Owner dispose d’un accès complet à toutes les ressources, y compris le droit de déléguer des accès à d’autres.

• Contributor peut créer et gérer tous les types de ressources Azure, mais ne peut pas accorder de access à d'autres personnes.

• Reader peut afficher les ressources Azure existantes.

Le reste des rôles Azure dans Azure permet la gestion de ressources Azure spécifiques. Par exemple, le rôle Contributeur de machine virtuelle permet à l’utilisateur de créer et de gérer des virtual machines. Il ne leur donne pas access au Réseau virtuel Azure ou au sous-réseau auquel la machine virtuelle se connecte.

Rôles intégrés d'Azure répertorient les rôles disponibles dans Azure. Ils spécifient les opérations et l’étendue que chaque rôle intégré accorde aux utilisateurs. Si vous souhaitez définir vos propres rôles pour un contrôle encore plus grand, découvrez comment générer des rôles Custom dans Azure RBAC.

Voici d’autres fonctionnalités pour Microsoft Entra ID :

• Microsoft Entra ID permet l’authentification unique (SSO) vers les applications SaaS, quel que soit leur lieu d’hébergement. Certaines applications sont fédérées avec Microsoft Entra ID, et d’autres utilisent l’authentification unique par mot de passe. Les applications fédérées peuvent également prendre en charge l’approvisionnement d’utilisateurs et la mise au coffre des mots de passe.

• Microsoft Entra ID fournit Identity as a Service via la fédération à l’aide de Services ADFS, de la synchronisation et de la réplication avec des répertoires locaux.

• L’authentification multifacteur Microsoft Entra demande aux utilisateurs de vérifier les connexions à l’aide d’une application mobile, d’un appel téléphonique ou d’un SMS. Utilisez-le avec Microsoft Entra ID pour sécuriser les ressources sur site grâce au serveur d’authentification multi-facteur, ainsi qu’avec des applications et répertoires personnalisés en utilisant le SDK.

• Microsoft Entra Domain Services vous aide à relier des machines virtuelles Azure à un domaine Active Directory sans avoir à déployer de contrôleurs de domaine. Vous pouvez vous connecter à ces virtual machines avec vos informations d’identification de Active Directory d’entreprise et administrer des virtual machines joints à un domaine à l’aide de Group Policy pour appliquer les bases de référence de sécurité sur tous vos Azure virtual machines.

• ID externe Microsoft Entra est un service de gestion d’identité mondial hautement disponible pour les applications destinées aux consommateurs, qui peut atteindre des centaines de millions d’identités. Vous pouvez l’intégrer sur les plateformes mobiles et web. Vos consommateurs peuvent se connecter à toutes vos applications par le biais d’expériences personnalisables en utilisant leurs comptes de réseaux sociaux existants ou en créant des informations d’identification.

Isolation des administrateurs microsoft et suppression des données

Microsoft prend des mesures fortes pour protéger vos données contre les access inappropriés ou l’utilisation par des personnes non autorisées. Les Online Services Terms offrent des engagements contractuels qui régissent l'accès à vos données et sauvegardent ces processus et contrôles opérationnels.

• Les ingénieurs Microsoft n'ont pas de access par défaut à vos données dans le cloud. Il leur est accordé l'accès, sous contrôle de la direction, uniquement lorsque cela est nécessaire. Cet accès est soigneusement contrôlé et enregistré, et révoqué lorsqu'il n'est plus nécessaire.
• Microsoft peut faire appel à d’autres sociétés pour fournir des services limités en son nom. Les sous-traitants peuvent access données client uniquement pour fournir les services pour lesquels Microsoft les a embauchés, et ils sont interdits de l'utiliser à d'autres fins. De plus, elles sont liées contractuellement à la confidentialité des informations des clients.

Microsoft et les cabinets d’audit accrédités vérifient régulièrement les services d’entreprise avec des certifications auditées telles que ISO/IEC 27001. Ces auditeurs effectuent des audits d'échantillons pour attester que l'accès est uniquement à des fins commerciales légitimes. Vous pouvez toujours accéder à vos propres données clients à tout moment et pour toute raison.

Si vous supprimez des données, Microsoft Azure supprime les données, y compris les copies mises en cache ou de sauvegarde. Pour les services concernés, cette suppression se produit dans les 90 jours suivant la fin de la période de rétention. (La section Conditions de traitement des données des Conditions des services en ligne définit les services concernés.)

Si un lecteur de disque utilisé pour storage subit une défaillance matérielle, Microsoft érase ou détruit le lecteur avant de le renvoyer au fabricant pour remplacement ou réparation. Microsoft écrase les données sur le disque pour s’assurer que personne ne puisse les récupérer par quelque moyen que ce soit.

Isolation du calcul

Microsoft Azure fournit différents services informatiques basés sur le cloud qui incluent une large sélection d’instances de calcul et de services qui peuvent effectuer un scale-up et un scale-down automatiquement pour répondre aux besoins de votre application ou de votre entreprise. Ces instances et services de calcul offrent une isolation à plusieurs niveaux pour sécuriser les données sans sacrifier la flexibilité de configuration exigée par les organisations.

Tailles de machines virtuelles isolées

Azure Compute offre des tailles de machines virtuelles isolées à un type de matériel spécifique et dédiées à un seul client. Les tailles isolées fonctionnent sur des générations matérielles spécifiques. Azure déprécie ces tailles lorsque la génération de matériel est retirée ou que de nouvelles générations de matériel sont disponibles.

Les tailles isolées de machines virtuelles conviennent mieux aux charges de travail nécessitant un fort degré d’isolation par rapport aux charges d’autres locataires. Cet isolement est parfois nécessaire pour répondre aux exigences de conformité et réglementaires. Utiliser une taille isolée garantit que votre machine virtuelle est la seule à fonctionner sur cette instance serveur spécifique.

Comme les VM de taille isolée sont grandes, vous pouvez choisir de subdiviser leurs ressources en utilisant le support support Azure pour les machines virtuelles imbriquées.

Les offres actuelles de machines virtuelles isolées incluent :

• Standard_E192is_v6
• Standard_E192ids_v6
• Standard_E104i_v5
• Standard_E104id_v5
• Standard_E104is_v5
• Standard_E104ids_v5
• Standard_E112ias_v5
• Standard_E112iads_v5
• Standard_E80is_v4
• Standard_E80ids_v4
• Standard_E96ias_v4
• Standard_E112ibs_v5
• Standard_E112ibds_v5
• Standard_EC96ias_v5
• Standard_EC96iads_v5
• Standard_HB120rs_v3
• Standard_HB176rs_v4
• Standard_HB368rs_v5
• Standard_HX176rs
• Standard_M832is_16_v3
• Standard_M832ids_16_v3
• Standard_M192is_v2
• Standard_M192ids_v2
• Standard_M192ims_v2
• Standard_M192idms_v2
• Standard_NC64as_T4_v3
• Standard_NC96ads_A100_v4
• Standard_NC80adis_H100_v5
• Standard_ND128isr_NDR_GB200_v6
• Standard_ND128isr_NDR_GB300_v6
• Standard_ND96isr_H100_v5
• Standard_ND96isr_H200_v5
• Standard_ND96isr_MI300X_v5
• Standard_NG32ads_V620_v1
• Standard_NG32adms_V620_v1
• Standard_NV72ads_A10_v5

Dépréciation des tailles de machines virtuelles isolées

Les tailles de VM isolées ont une durée de vie matérielle limitée. Azure publiera des rappels 12 mois avant la date officielle de dépréciation des tailles et fournira une offre isolée mise à jour à votre intention. Azure a annoncé la mise hors service des tailles suivantes.

Pour subdiviser davantage les ressources de ces machines virtuelles isolées, voir support Azure pour les machines virtuelles imbriquées.

Hôtes dédiés

Outre les hôtes isolés décrits dans la section précédente, Azure propose également des hôtes dédiés. Azure Dedicated Host est un service qui fournit des serveurs physiques pouvant héberger une ou plusieurs machines virtuelles et sont dédiés à un seul abonnement Azure. Les hôtes dédiés assurent l’isolation matérielle au niveau du serveur physique. Aucune autre machine virtuelle n’est placée sur vos hôtes. Vous déployez des hôtes dédiés dans les mêmes centres de données et partagent le même réseau et l’infrastructure storage sous-jacente que d’autres hôtes non isolés. Pour plus d’informations, consultez la vue d’ensemble détaillée des hôtes dédiés Azure.

Hyper-V et l’isolation du système d’exploitation racine entre la machine virtuelle racine et les machines virtuelles invitées

la plateforme de calcul de Azure est basée sur la virtualisation des machines. Tout le code client s’exécute dans une machine virtuelle Hyper-V. Sur chaque nœud Azure (ou point de terminaison réseau), un hyperviseur s’exécute directement sur le matériel et divise le nœud en un nombre variable de machines virtuelles invitées (VMs).

Chaque nœud a également une machine virtuelle racine spéciale qui exécute le système d’exploitation hôte. L’hyperviseur et le système d’exploitation racine gèrent l’isolation de la machine virtuelle racine des machines virtuelles invitées et l’isolation des machines virtuelles invitées les unes des autres. Cette association d'hyperviseur et de système d'exploitation racine utilise les décennies d'expérience de Microsoft en matière de sécurité des systèmes d'exploitation et les leçons plus récentes tirées de la Hyper-V de Microsoft pour offrir une forte isolation des machines virtuelles invitées.

La plateforme Azure utilise un environnement virtualisé. Les instances utilisateur fonctionnent en tant que virtual machines autonomes qui n'ont pas de access sur un serveur hôte physique.

L’hyperviseur Azure agit comme un microkernel. Il transmet toutes les requêtes d'accès matériel des machines virtuelles invitées à l’hôte pour qu'il les traite à l’aide d’une interface de mémoire partagée appelée VM Bus. Cette architecture empêche les utilisateurs d'obtenir un accès brut de lecture, d'écriture ou d'exécution sur le système et atténue le risque de partage des ressources du système.

Algorithme avancé de placement de VM et protection contre les attaques par canal latéral

Toute attaque inter-VM implique deux étapes : placer une VM contrôlée par l’adversaire sur le même hôte qu’une des VM victimes, puis franchir la frontière d’isolement pour voler des informations sensibles de la victime ou affecter ses performances en cas de vol ou de perturbation de ressources. Microsoft Azure offre une protection aux deux étapes à l’aide d’un algorithme de placement de machine virtuelle avancée et d’une protection contre toutes les attaques de canal côté connus, y compris les machines virtuelles voisines bruyantes.

Contrôleur de structure Azure

Le contrôleur de structure Azure alloue des ressources d’infrastructure aux charges de travail client et gère les communications unidirectionnelles de l’hôte vers virtual machines. L’algorithme de placement des VM est très sophistiqué et presque impossible à prédire au niveau physique de l’hôte.

Le contrôleur Azure Fabric

Dans Azure, la machine virtuelle racine exécute un système d’exploitation renforcé appelé système d’exploitation racine qui héberge un agent de structure (FA). Les FAs gèrent les agents invités (GA) au sein des systèmes d'exploitation invités sur les machines virtuelles clientes et gèrent également les nœuds de stockage.

La collection de l'hyperviseur Azure, de l'OS/FA racine et des VM/GA clientes comprend un nœud de calcul. Un contrôleur de structure (FC) gère les FA. Le FC existe en dehors des nœuds de calcul et de stockage. Des FC distincts gèrent les clusters de calcul et de stockage. Si un client met à jour le fichier de configuration de son application pendant qu'elle tourne, le FC communique avec le FA. Le FA contacte les GA, qui notifient l’application du changement de configuration. En cas de défaillance matérielle, le FC trouve automatiquement le matériel disponible et redémarre la machine virtuelle.

La communication entre un contrôleur de structure et un agent est unidirectionnelle. L’agent implémente un service protégé par SSL qui répond uniquement aux demandes du contrôleur. L’agent ne peut pas initier de connexions au contrôleur ou à d’autres nœuds internes privilégiés. Le contrôleur de structure traite toutes les réponses comme si elles n’étaient pas approuvées.

L’isolation s’étend de la machine virtuelle racine aux machines virtuelles invitées et d’une machine virtuelle invitée à une autre. Les nœuds de calcul sont également isolés des nœuds storage pour une protection accrue.

L’hyperviseur et le système d’exploitation hôte fournissent des filtres de paquets réseau. Ces filtres permettent de s'assurer que les virtual machines non approuvés ne peuvent pas générer de trafic usurpé ou recevoir le trafic qui ne leur est pas adressé. Ils dirigent le trafic vers des points de terminaison d’infrastructure protégés et empêchent l’envoi ou la réception d’un trafic de diffusion inapproprié.

Autres règles configurées par un agent de contrôleur de fabric pour isoler la VM

Par défaut, Azure bloque tout le trafic lorsque vous créez une machine virtuelle. Ensuite, l’agent du contrôleur de structure configure le filtre de paquets pour ajouter des règles et des exceptions pour autoriser le trafic autorisé.

L’agent fabric controller programme deux catégories de règles :

• Règles de configuration ou d’infrastructure de la machine : Par défaut, Azure bloque toute communication. Ajoutez des exceptions pour permettre à une machine virtuelle d’envoyer et de recevoir le trafic DHCP et DNS. Les machines virtuelles peuvent également envoyer du trafic vers l’Internet « public » et envoyer du trafic à d’autres machines virtuelles au sein du même réseau virtuel Azure et vers le serveur d’activation du système d’exploitation. La liste des destinations sortantes autorisées pour les machines virtuelles n'inclut pas les sous-réseaux de routeurs Azure, la gestion Azure et d'autres propriétés Microsoft.
• fichier de configuration Role : Ce fichier définit les listes de Access Control entrantes (ACL) en fonction du modèle de service du locataire.

Isolation du réseau local virtuel

Chaque cluster contient trois réseaux locaux virtuels :

isolation de

• Le VLAN principal : Interconnecte les nœuds clients non fiables.
• Le VLAN FC : Contient des FC de confiance et des systèmes de support.
• Le VLAN des appareils : contient des équipements réseau et d’autres équipements d’infrastructure de confiance.

Le VLAN FC peut communiquer avec le VLAN principal, mais le VLAN principal ne peut pas initier la communication avec le VLAN FC. Le VLAN principal ne peut pas non plus communiquer avec le VLAN de l’appareil. Cette architecture VLAN garantit que même si un nœud exécutant du code client est compromis, il ne peut pas attaquer les nœuds ni sur les VLANs FC ni sur les VLANs des appareils.

Isolation du stockage

Isolation logique entre le calcul et le stockage

Dans le cadre de sa conception fondamentale, Microsoft Azure sépare le calcul basé sur les machines virtuelles de storage. Cette conception permet au calcul et au stockage de s’étendre indépendamment, facilitant la multitenance et l’isolement.

Par conséquent, stockage Azure s’exécute sur du matériel distinct sans connectivité réseau à Azure Calcul, à l’exception de la connectivité logique. Cette conception de stockage signifie que lorsque vous créez un disque virtuel, le système n’alloue pas d’espace disque pour toute sa capacité. Au lieu de cela, le système crée une table qui mappe des adresses sur le disque virtuel aux zones du disque physique. Cette table est initialement vide. La première fois que vous écrivez des données sur le disque virtuel, le système alloue de l’espace sur le disque physique et place un pointeur vers celui-ci dans la table.

Isolation à l’aide du contrôle d'accès au stockage

Access control dans stockage Azure utilise un modèle de access control simple. Chaque abonnement Azure peut créer un ou plusieurs comptes storage. Chaque compte de stockage a une clé secrète unique utilisée pour contrôler l'accès à toutes les données de ce compte de stockage.

Vous pouvez contrôler l'accès aux données stockage Azure (y compris les tables) via un jeton SAS (Signature d'Accès Partagé), qui accorde un accès restreint. Vous créez le SAS via un modèle de requête (URL) et vous le signez avec la clé de compte de stockage (SAK). Vous pouvez attribuer l’URL signée à un autre processus (délégué). Le processus délégué peut ensuite renseigner les détails de la requête et effectuer la demande au service de stockage. En utilisant un SAS, vous pouvez accorder des accès basés sur le temps aux clients sans révéler la clé secrète du compte de stockage.

Avec le SAS, vous pouvez accorder à un client des permissions limitées aux objets de votre compte de stockage pendant une période de temps spécifiée et un ensemble précis d’autorisations. Vous accordez ces autorisations limitées sans partager les clés d'accès de votre compte.

Isolation du stockage niveau IP

Vous pouvez activer des pare-feu et définir une plage d’adresses IP pour vos clients approuvés. En utilisant une plage d’adresses IP, seuls les clients disposant d’une adresse IP au sein de la plage définie peuvent se connecter à stockage Azure.

Utilisez un mécanisme réseau qui alloue un tunnel dédié de trafic vers le stockage IP afin de protéger les données de stockage IP contre les utilisateurs non autorisés.

Chiffrement

Azure propose les types de chiffrement suivants pour protéger les données :

• Chiffrement en transit
• Chiffrement au repos

Chiffrement en transit

Le chiffrement en transit protège les données lorsqu’elles sont transmises sur plusieurs réseaux. À l’aide de stockage Azure, vous pouvez sécuriser les données à l’aide de :

• Chiffrement au niveau du transport, tel que HTTPS lorsque vous transférez des données vers ou hors d'stockage Azure.
• Le chiffrement câblé, par exemple le chiffrement SMB 3.0 pour les partages de fichiers Azure.
• Chiffrement côté client, pour chiffrer les données avant leur transfert dans storage et pour déchiffrer les données après leur transfert hors de storage.

Chiffrement au repos

Pour de nombreuses organisations, le chiffrement au repos des données est une étape obligatoire vers la confidentialité, la conformité et la souveraineté des données. Azure fonctionnalités qui fournissent le chiffrement des données au repos sont les suivantes :

• Le chiffrement des services de stockage chiffre automatiquement les données lors de leur écriture sur stockage Azure.
• Le chiffrement côté client chiffre les données avant qu’elles ne soient transférées en stockage.
• Encryption sur l’hôte fournit un chiffrement de bout en bout pour les données de machine virtuelle.

Chiffrement sur l’hôte

Encryption sur l’hôte fournit un chiffrement de bout en bout pour vos données de machine virtuelle en chiffrant les données au niveau de l’hôte de la machine virtuelle. Par défaut, il utilise des clés gérées par la plateforme, mais vous pouvez éventuellement utiliser des clés gérées par le client stockées dans Azure Key Vault ou Azure Key Vault HSM managé lorsque vous avez besoin d’un contrôle plus important.

Le chiffrement sur l’hôte fournit un chiffrement côté serveur au niveau de l’hôte de machine virtuelle à l’aide du chiffrement AES 256, qui est conforme à FIPS 140-2. Ce chiffrement se produit sans consommer de ressources d’UC de machine virtuelle et fournit un chiffrement de bout en bout pour :

• Disques temporaires
• Caches de disque de données et de système d’exploitation
• Flux de données vers stockage Azure

Principaux avantages du chiffrement sur l’hôte :

• Aucun impact sur les performances : Le chiffrement se produit au niveau de l’hôte sans utiliser les ressources CPU de la VM.
• Support large des VM : pris en charge sur la plupart des séries et tailles de VM.
• Clés gérées par le client : Intégration optionnelle avec Azure Key Vault ou Managed HSM pour le contrôle des clés.
• Clés gérées par la plateforme par défaut : aucune configuration supplémentaire requise pour le chiffrement.

Pour plus d’informations, consultez Encryption sur l’hôte et Overview des options de chiffrement de disque managé.

Isolation de la base de données SQL

Azure SQL Database est un service de base de données relationnelle basé sur le cloud construit sur le moteur Microsoft SQL Server. Azure SQL Database est un service de base de données multilocataire, évolutif et très disponible, offrant une isolation prévisible des données aux niveaux du compte, de la géographie, de la région et du réseau. Le service offre cette isolation de base de données avec une administration quasi nulle.

Modèle d’application SQL Database

Du point de vue de l’application, SQL Database fournit la hiérarchie suivante, où chaque niveau a un-à-plusieurs niveaux de confinement inférieur.

Le compte et l’abonnement sont des concepts de plateforme Microsoft Azure pour associer la facturation et la gestion.

Les serveurs et bases de données SQL logiques sont des concepts spécifiques à la base de données SQL. Vous les gérez en utilisant les interfaces OData et T-SQL fournies par la base de données SQL ou le portail Azure.

Les serveurs dans la base de données SQL ne sont pas des instances physiques ou VM. Ce sont plutôt des collections de bases de données qui partagent des politiques de gestion et de sécurité stockées dans une base de données dite maîtresse logique.

base de données

Les bases de données master logiques comprennent :

• Les connexions SQL utilisées pour se connecter au serveur
• Règles de pare-feu

Les informations de facturation et d’utilisation des bases de données provenant du même serveur ne sont pas garanties d’être sur la même instance physique dans le cluster. Les applications doivent fournir le nom de la base de données cible lors de la connexion.

De votre point de vue, vous créez un serveur dans une région géographique, mais Azure crée le serveur dans l’un des clusters de cette région.

Isolation via la topologie de réseau

Lorsque vous créez un serveur et enregistrez son nom DNS, ce nom DNS pointe vers l’adresse VIP de la passerelle dans le centre de données spécifique où vous placez le serveur.

Derrière l’adresse IP virtuelle, nous avons une collection de services de passerelle sans état. En général, les passerelles sont impliquées lorsque la coordination est nécessaire entre plusieurs sources de données (base de données master, base de données utilisateur, etc.). Les services de passerelle implémentent les fonctions suivantes :

• Proxy de connexion TDS. Cette fonction inclut la localisation de la base de données utilisateur dans le cluster backend, l’implémentation de la séquence d’authentification, puis le transfert des paquets TDS vers le backend et retour.
• Gestion de base de données. Cette fonction inclut l’implémentation d’une collection de flux de travail pour gérer les opérations de base de données CREATE, ALTER et DROP. Le service peut invoquer des opérations de base de données en détectant soit des paquets TDS, soit des API OData explicites.
• OPÉRATIONS D'AUTHENTIFICATION ET D'UTILISATEUR : CRÉER, MODIFIER ET SUPPRIMER
• Opérations de gestion de serveur via l’API OData

Le niveau derrière les passerelles est appelé back-end. Le niveau back-end stocke toutes les données de manière très disponible. Chaque élément de données appartient à une partition ou à une unité de basculement, et chaque partition a au moins trois réplicas. Le moteur SQL Server stocke et réplique les réplicas, et un système de basculement, souvent appelé structure en assure la gestion.

En règle générale, le système back-end ne communique pas en sortie avec d’autres systèmes pour des raisons de sécurité. Azure réserve la communication sortante aux systèmes du front-end (passerelle). Les machines de niveau passerelle disposent de privilèges limités sur les machines back-end. Cette contrainte minimise la surface d’attaque en tant que mécanisme de défense en profondeur.

Isolation par accès et fonction de machines

La base de données SQL comprend des services fonctionnant sur différentes fonctions de la machine. SQL Database répartit ces services en un environnement de base de données cloud back-end et un environnement de passerelle et de gestion front-end, selon le principe général que le trafic entre uniquement dans le back-end et n’en sort pas. L’environnement front-end peut communiquer avec le monde extérieur et avec d’autres services et, de manière générale, ne dispose que d’autorisations limitées dans le back-end (suffisantes pour appeler les points d’entrée qu’il doit invoquer).

Isolation réseau

Les déploiements Azure comportent plusieurs couches d’isolation réseau. Le diagramme suivant montre les différentes couches d’isolation réseau fournies par Azure. Ces couches incluent des fonctionnalités natives de la plateforme Azure et des fonctionnalités définies par le client. Entrant à partir d’Internet, Azure DDoS protection offre une isolation contre les attaques à grande échelle contre Azure. La couche suivante d’isolation est les adresses IP publiques définies par le client (points de terminaison), que vous utilisez pour déterminer quel trafic peut passer par le service cloud au virtual network. L’isolation des réseaux virtuels Azure natif assure une isolation complète de tous les autres réseaux. Le trafic ne circule que par des chemins et méthodes configurés par l’utilisateur. Ces chemins et méthodes constituent la couche suivante, où les NSG, l’UDR et vous pouvez utiliser des appliances virtuelles réseau pour créer des frontières d’isolation afin de protéger les déploiements d’applications dans le réseau protégé.

Isolation du trafic : Un réseau virtuel constitue la limite d'isolation du trafic sur la plateforme Azure. Les machines virtuelles (VMs) dans un réseau virtuel ne peuvent pas communiquer directement avec les machines virtuelles d'un autre réseau virtuel, même si les deux réseaux virtuels sont créés par le même client. L’isolation est une propriété essentielle qui garantit que les machines virtuelles et communications clients restent privées au sein d’un réseau virtuel.

Un sous-réseau offre une couche supplémentaire d’isolation au sein d’un réseau virtuel basée sur la plage IP. Vous pouvez diviser un virtual network en plusieurs sous-réseaux pour l’organisation et la sécurité. Les machines virtuelles et les instances de rôle PaaS déployées sur des sous-réseaux (identiques ou différents) au sein d’un virtual network peuvent communiquer entre elles sans aucune configuration supplémentaire. Vous pouvez également configurer des groupes de sécurité réseau (NSG) pour autoriser ou refuser le trafic réseau vers une instance de machine virtuelle en fonction des règles de sécurité. Vous pouvez associer des NSG (groupes de sécurité réseau) à des sous-réseaux ou à des interfaces réseau individuelles attachées aux machines virtuelles. Lorsque vous associez un groupe de sécurité réseau à un sous-réseau, les règles de sécurité s’appliquent à toutes les instances de machine virtuelle de ce sous-réseau.

Étapes suivantes

• Découvrez les groupes de sécurité réseau. Les groupes de sécurité réseau filtrent le trafic réseau entre les ressources Azure dans un virtual network. Vous pouvez restreindre le trafic vers des sous-réseaux ou des virtual machines en fonction de la source, de la destination, du port et du protocole à l’aide de règles de sécurité.

• Découvrez l'isolation des machines virtuelles dans Azure. Azure Compute offre des tailles de machines virtuelles isolées à un type de matériel spécifique et dédiées à un seul client.