Guide

Authentification d'identité hybride où les hachages de mots de passe doivent rester sur site, avec basculement.

→Azure AD Connect avec Pass-through Authentication (PTA) et Password Hash Sync (PHS) activé comme sauvegarde.

Pourquoi: PTA conserve les hachages sur site en les validant par rapport à l’AD local. PHS fournit un basculement d’authentification si l’AD sur site ou l’agent Connect n’est pas disponible.

Référence↗

Implémenter Zero Trust en appliquant un contrôle d’accès granulaire basé sur l’utilisateur, l’emplacement, l’état de l’appareil et le risque.

→Stratégies Microsoft Entra Conditional Access combinant les emplacements nommés (Named Locations), la conformité des appareils (Intune) et le risque de connexion (Identity Protection) avec des contrôles d’octroi comme la MFA.

Pourquoi: Conditional Access est le moteur d’application pour Zero Trust, évaluant plusieurs signaux par demande avant d’accorder l’accès. Une seule stratégie ne peut pas appliquer des contrôles différents à des conditions différentes.

Référence↗

Appliquer des stratégies cohérentes (par exemple, balisage, régions autorisées) sur des dizaines ou des centaines d’abonnements.

→Une hiérarchie de groupes d’administration avec des initiatives Azure Policy attribuées au niveau du groupe d’administration racine ou parent.

Pourquoi: Les groupes d'administration offrent un périmètre de gouvernance au-delà des abonnements, permettant l'héritage des stratégies. Les initiatives regroupent plusieurs stratégies pour une attribution simplifiée.

Référence↗

Fournir aux administrateurs un accès privilégié juste-à-temps (JIT) avec des flux de travail d’approbation et d’audit.

→Microsoft Entra Privileged Identity Management (PIM) pour rendre les utilisateurs éligibles aux rôles au lieu de les rendre actifs en permanence.

Pourquoi: PIM applique le principe du moindre privilège en exigeant des utilisateurs qu’ils activent les rôles pour une durée limitée, avec MFA, justification et approbation facultatives, créant une piste d’audit complète.

Référence↗

Collecter les journaux de toutes les ressources Azure sur plusieurs abonnements pour une analyse et une interrogation centralisées.

→Un seul espace de travail Log Analytics centralisé avec RBAC contextuel des ressources pour le contrôle d’accès.

Pourquoi: Un espace de travail centralisé permet des requêtes multi-abonnements, simplifie la gestion et évite la duplication des données. Le RBAC contextuel des ressources garantit que les utilisateurs n’interrogent que les journaux des ressources auxquelles ils ont accès.

Une ressource Azure (par exemple, App Service, Function, VM) doit accéder en toute sécurité à d’autres ressources Azure (Key Vault, SQL, Storage) sans informations d’identification stockées.

→Attribuer une identité managée (affectée par le système ou par l’utilisateur) à la ressource de calcul et lui accorder des rôles RBAC sur les ressources cibles.

Pourquoi: Les identités managées éliminent la gestion des informations d'identification (secrets, certificats), gérant automatiquement l'acquisition et la rotation des jetons. Utilisez les identités affectées par l'utilisateur pour partager une identité entre plusieurs ressources.

Référence↗

Corriger automatiquement les ressources Azure existantes et non conformes identifiées par une Azure Policy.

→Utilisez un effet de stratégie "DeployIfNotExists" ou "Modify". Pour les ressources existantes, une tâche de correction doit être créée pour l’attribution de la stratégie, ce qui nécessite une identité managée avec des autorisations suffisantes.

Pourquoi: Les stratégies avec ces effets ne s’appliquent par défaut qu’aux ressources nouvelles/mises à jour. Une tâche de correction est nécessaire pour scanner et réparer les ressources non conformes existantes.

Appliquer les balises requises sur toutes les ressources et hériter automatiquement des balises (par exemple, CostCenter) du groupe de ressources parent.

→Utilisez une Azure Policy avec un effet "Deny" pour les balises requises et une stratégie distincte avec un effet "Modify" pour hériter les balises du groupe de ressources si elles sont manquantes.

Pourquoi: Deny impose la conformité à la création. L’effet Modify automatise la propagation des balises, réduisant l’effort manuel et assurant la cohérence.

Surveiller une application multi-niveaux ou de microservices pour tracer les transactions de bout en bout et identifier les goulots d’étranglement de performance.

→Instrumenter tous les services avec Application Insights. Utilisez la carte d’application (Application Map) pour visualiser les dépendances et le traçage distribué pour l’analyse des requêtes de bout en bout.

Pourquoi: Application Insights est la solution APM native qui corrèle automatiquement la télémétrie entre les composants pour fournir une vue unifiée d’une transaction, en identifiant les problèmes de latence.

Gouverner l’accès pour les partenaires externes, y compris les demandes, les approbations, l’accès limité dans le temps et les examens périodiques.

→Gestion des droits d’accès Microsoft Entra ID Governance. Créez des packages d’accès qui regroupent les ressources, définissent des workflows d’approbation, définissent des stratégies d’expiration et planifient des révisions d’accès.

Pourquoi: Fournit un cycle de vie complet et automatisé pour l'accès externe, réduisant la charge administrative et le risque de sécurité par rapport à la gestion manuelle des comptes invités.

Un fournisseur de services managés ou une équipe informatique centrale doit gérer les ressources sur plusieurs locataires Azure AD clients/départementaux.

→Azure Lighthouse. Intégrez les abonnements clients pour accorder au locataire gérant un accès délégué avec des rôles RBAC spécifiques.

Pourquoi: Lighthouse fournit un plan de contrôle unique pour la gestion multi-locataire sans changer de répertoires ni gérer les comptes invités, tandis que le client conserve le contrôle total et la propriété.

Fournir un accès à distance sécurisé à une application web sur site pour des utilisateurs externes sans VPN ni exposition de l’application à l’internet.

→Microsoft Entra Application Proxy.

Pourquoi: Application Proxy utilise un connecteur léger sur site qui établit une connexion sortante vers Azure. Il agit comme un proxy inverse, permettant la pré-authentification Entra ID et un accès sécurisé sans règles de pare-feu entrantes ni adresse IP publique sur l’application.

Une application distribuée mondialement nécessite une base de données avec une latence de lecture/écriture inférieure à 10 ms, un schéma flexible et une disponibilité de 99,999%.

→Azure Cosmos DB avec écritures multi-régions activées. La clé de partition doit être choisie pour distribuer la charge de travail uniformément.

Pourquoi: Cosmos DB est spécialement conçu pour la distribution globale avec des écritures multi-régions clés en main, offrant une faible latence garantie et le SLA de disponibilité le plus élevé. D’autres bases de données nécessitent une réplication manuelle et ne peuvent pas égaler la latence d’écriture.

Ingérer une télémétrie IoT à volume élevé dans Cosmos DB, permettant des requêtes efficaces par appareil et l'archivage automatique des anciennes données.

→Utilisez `/deviceId` comme clé de partition. Configurez le TTL sur le conteneur pour la suppression automatique des anciens documents. Utilisez Change Feed pour capturer les données avant la suppression pour l'archivage dans un stockage froid (par exemple, Blob Storage).

Pourquoi: Le partitionnement par `deviceId` co-localise les données pour un seul appareil, rendant les requêtes efficaces. Le TTL permet une suppression gratuite et automatique. Change Feed active un pipeline d’archivage réactif.

Sélectionner un modèle de tarification Azure SQL DB rentable pour une charge de travail avec un trafic imprévisible et en rafales, et des périodes d’inactivité importantes.

→Utilisez le modèle basé sur vCore avec le niveau de calcul Serverless.

Pourquoi: Serverless met automatiquement à l’échelle le calcul en fonction de la demande et se met en pause automatiquement pendant les périodes d’inactivité, ne facturant que le calcul utilisé par seconde. C’est beaucoup plus rentable pour les charges de travail intermittentes que les niveaux provisionnés.

Une solution de stockage pour une plateforme d’analyse de données à grande échelle nécessitant un espace de noms hiérarchique et des listes de contrôle d’accès (ACL) au niveau du répertoire.

→Azure Data Lake Storage Gen2 (un compte avec espace de noms hiérarchique activé).

Pourquoi: ADLS Gen2 est optimisé pour l’analyse de big data, combinant l’évolutivité du stockage d’objets avec un véritable système de fichiers hiérarchique et des ACL conformes à POSIX pour une sécurité granulaire.

Choisir la redondance du stockage en fonction des exigences hiérarchisées : durabilité maximale avec accès en lecture, reprise après sinistre uniquement, et protection contre les pannes de centre de données dans la région.

→1. Durabilité/lecture maximale : RA-GZRS. 2. Reprise après sinistre uniquement : GRS. 3. Dans la région : ZRS.

Pourquoi: Faites correspondre l’option de redondance aux besoins spécifiques en RPO/RTO et en accès. RA-GZRS est le niveau le plus élevé. GRS est uniquement pour le basculement. ZRS protège contre les pannes de centre de données au sein d’une région.

Interroger des données structurées volumineuses dans un entrepôt de données et des données semi-structurées dans un lac de données à l’aide d’une plateforme d’analyse unifiée.

→Azure Synapse Analytics. Utilisez un pool SQL dédié pour les données structurées et un pool SQL serverless pour les requêtes ad hoc sur le lac de données.

Pourquoi: Cette approche hybride optimise à la fois les performances et les coûts. Le pool dédié offre des performances élevées pour l’entrepôt de données géré, tandis que le pool serverless fournit un accès par requête aux données brutes du lac.

Une solution de mise en cache pour l’état de session et les données produit nécessitant plus de 100 Go de mémoire et une haute disponibilité.

→Azure Cache pour Redis Enterprise ou niveau Premium avec clustering activé.

Pourquoi: Le clustering dans les niveaux Premium/Enterprise permet au cache de dépasser les limites de mémoire d’un seul nœud en fragmentant les données sur plusieurs nœuds, améliorant également le débit.

Une architecture de base de données pour une application SaaS qui isole les locataires tout en optimisant les coûts pour de nombreuses petites charges de travail irrégulières.

→Azure SQL Elastic Pools. Regroupez les locataires dans des pools pour partager les ressources, avec des bases de données dédiées pour les grands locataires "bruyants".

Pourquoi: Les pools élastiques offrent les avantages économiques du partage de ressources tout en appliquant des limites de performance par base de données, offrant un équilibre entre le problème du "voisin bruyant" et le coût élevé d’une base de données par locataire.

Migrer une base de données SQL Server complexe sur site qui utilise des fonctionnalités comme SQL Agent, les requêtes inter-bases de données et CLR vers un service PaaS.

→Azure SQL Managed Instance.

Pourquoi: SQL Managed Instance offre une compatibilité quasi-100% avec le moteur SQL Server sur site, prenant en charge les fonctionnalités au niveau de l’instance qu’Azure SQL Database ne prend pas en charge. C’est idéal pour un "lift-and-shift" avec un minimum de modifications de code.

Assurer que toutes les données et les clés de chiffrement gérées par le client restent dans une zone géographique spécifique (par exemple, l’UE).

→Déployez toutes les ressources dans des régions situées dans la zone. Utilisez une Azure Policy avec l’effet "Allowed locations" pour appliquer cela. Stockez les clés gérées par le client (CMK) dans un Azure Key Vault également situé dans la zone.

Pourquoi: Une combinaison de l’emplacement de déploiement physique, de l’application basée sur des stratégies et de la résidence des clés est nécessaire pour respecter les réglementations strictes en matière de souveraineté des données.

Découvrir, classer et suivre la lignée des données sur un patrimoine de données hybride (Azure, sur site, autres clouds).

→Microsoft Purview.

Pourquoi: Purview offre une solution unifiée de gouvernance des données avec balayage automatisé, un glossaire métier, une classification et un suivi de la lignée sur un large éventail de sources de données.

Stocker des données (par exemple, des dossiers financiers) dans un état non effaçable et non modifiable (WORM) pendant une période de rétention définie.

→Azure Blob Storage avec une stratégie immuable basée sur le temps sur le conteneur, qui est ensuite verrouillée.

Pourquoi: Les stratégies immuables verrouillées empêchent la suppression ou la modification des objets BLOB par tout utilisateur, y compris les administrateurs, jusqu’à l’expiration de la période de rétention, répondant ainsi aux exigences strictes de conformité réglementaire.

Concevoir une solution de reprise après sinistre pour une application web (App Service + SQL DB) avec un RPO de quelques minutes et un RTO inférieur à une heure.

→Groupe de basculement automatique Azure SQL Database, un déploiement secondaire d’App Service et Azure Front Door ou Traffic Manager pour le routage.

Pourquoi: Ce modèle aborde la reprise après sinistre pour chaque niveau. Le groupe de basculement SQL gère la réplication des données et le basculement. L’App Service pré-déployé évite les retards de déploiement. Un routeur global (Front Door/Traffic Manager) dirige le trafic vers la région active.

Le SLA composite d’une application série (A -> B -> C) est trop faible. Comment l’améliorer ?

→Identifiez le composant avec le SLA individuel le plus bas (le "maillon faible") et rendez-le redondant en déployant des instances parallèles (par exemple, dans différentes régions ou zones avec un équilibreur de charge).

Pourquoi: Le SLA composite pour une chaîne série est calculé en multipliant les SLA (SLA_A * SLA_B * SLA_C). L’ajout d’instances parallèles à un composant améliore son SLA effectif, ce qui a le plus grand impact positif sur le composite.

Atteindre la plus haute disponibilité possible pour les VM au sein d’une même région Azure.

→Déployer plusieurs VM sur toutes les zones de disponibilité (Availability Zones) disponibles dans la région.

Pourquoi: Les zones de disponibilité sont des centres de données physiquement séparés avec une alimentation, un refroidissement et une mise en réseau indépendants. Cela protège contre les pannes au niveau du centre de données et offre le SLA le plus élevé dans la région de 99,99%.

Fournir une solution de reprise après sinistre pour les machines virtuelles VMware ou Hyper-V sur site vers Azure.

→Azure Site Recovery (ASR). Configurez la réplication vers Azure, créez des plans de récupération pour un basculement orchestré et utilisez des basculements de test pour des exercices de reprise après sinistre non perturbateurs.

Pourquoi: ASR est le service Azure spécialement conçu pour la réplication DR des VM sur site (et Azure), offrant une réplication continue, une récupération orchestrée et des capacités de test isolées.

Atteindre la plus haute disponibilité intra-région pour Azure SQL Database avec zéro perte de données (RPO=0) et une capacité de mise à l’échelle en lecture.

→Utilisez le niveau de service Business Critical avec la redondance de zone activée.

Pourquoi: Le niveau Business Critical utilise un groupe de disponibilité Always On avec réplication synchrone sur plusieurs réplicas, offrant un RPO de 0. La redondance de zone place les réplicas dans différentes AZs pour un SLA de 99,995%. Il comprend un réplica secondaire lisible.

Une application globale doit servir les utilisateurs depuis la région la plus proche et basculer automatiquement et instantanément.

→Utilisez un modèle de déploiement actif-actif sur plusieurs régions avec Azure Front Door pour le routage basé sur la latence et le basculement basé sur les sondes d’intégrité.

Pourquoi: Azure Front Door fournit un routage anycast global vers le backend à la latence la plus faible. Ses sondes d’intégrité détectent les pannes régionales et redirigent automatiquement le trafic vers les régions saines en quelques secondes, permettant une architecture actif-actif transparente.

Sauvegarder les applications avec état sur AKS, y compris les définitions d’objets Kubernetes et les données des volumes persistants.

→Utilisez Azure Backup pour AKS.

Pourquoi: Azure Backup pour AKS est la solution native qui fournit une sauvegarde intégrée et basée sur des stratégies pour l’état du cluster (etcd) et les données des volumes persistants (via des instantanés CSI) dans un coffre de sauvegarde sécurisé et centralisé (Backup Vault).

Protéger les sauvegardes contre la suppression accidentelle ou malveillante, y compris par les administrateurs, pour la conformité réglementaire.

→Activez les coffres immuables sur le coffre Azure Backup ou Recovery Services.

Pourquoi: L'immutabilité est un paramètre au niveau du coffre qui garantit que les points de récupération de sauvegarde, une fois créés, ne peuvent être supprimés par personne avant leur date d'expiration, offrant le plus haut niveau de protection des sauvegardes.

Un App Service Environment v3 (ASEv3) héberge une application critique dans une région et nécessite une solution de reprise après sinistre dans une autre région.

→Déployez un second ASEv3 dans la région de reprise après sinistre. Utilisez Azure Front Door pour l’équilibrage de charge global et le basculement. Répliquez les données à l’aide de la technologie appropriée (par exemple, groupes de basculement automatique SQL).

Pourquoi: Les ASEv3 sont des déploiements régionaux. Pour la reprise après sinistre, vous devez déployer un second ASE et utiliser un routeur global comme Front Door pour gérer le trafic. ASR n’est pas utilisé pour la reprise après sinistre d’App Service.

Concevoir un réseau évolutif pour une entreprise avec connectivité centralisée (ExpressRoute/VPN), services partagés et isolation des charges de travail.

→Une topologie hub-and-spoke. Le VNet hub contient la passerelle, Azure Firewall et d’autres services partagés. Les VNets spoke contiennent les charges de travail applicatives et sont appairées au hub.

Pourquoi: C’est le modèle d’entreprise standard et recommandé. Il centralise la sécurité et la connectivité, réduisant les coûts et la complexité, tandis que les spokes offrent une forte isolation des charges de travail.

Une application web globale nécessite un équilibrage de charge de couche 7, un Web Application Firewall (WAF), le déchargement SSL et le routage basé sur l’URL.

→Azure Front Door (Standard ou Premium).

Pourquoi: Front Door est un CDN cloud moderne et un équilibreur de charge global qui intègre ces capacités dans un seul service, offrant de meilleures performances et une gestion plus simple que la combinaison de Traffic Manager avec des Application Gateways régionales.

Concevoir un cluster AKS de qualité production pour plusieurs équipes avec des types de charges de travail variés (CPU, GPU, gourmandes en mémoire).

→Utilisez un pool de nœuds système dédié et plusieurs pools de nœuds utilisateur avec différentes SKU de VM (par exemple, série F pour le CPU, série E pour la mémoire, série N pour le GPU). Utilisez l’autoscaler de cluster et activez le niveau Standard/Premium pour le SLA de disponibilité.

Pourquoi: Plusieurs pools de nœuds permettent de faire correspondre le bon matériel à la bonne charge de travail pour l’efficacité des performances et des coûts. La séparation des pods système améliore la stabilité. Le niveau Standard/Premium est requis pour un SLA soutenu financièrement.

Un workflow serverless basé sur les événements nécessite des temps d’exécution supérieurs à la limite de 10 minutes du plan de consommation Functions.

→Utilisez Azure Functions sur un plan Premium ou un plan App Service, ou utilisez Azure Durable Functions pour l’orchestration.

Pourquoi: Le plan Premium prend en charge l’exécution jusqu’à 60 minutes (30 par défaut) et évite les démarrages à froid. Les Durable Functions sont idéales pour orchestrer des workflows avec état de longue durée qui peuvent impliquer une interaction humaine ou de longues attentes.

Choisir un service de messagerie pour un système de notification d’événements en "fan-out" versus un système de traitement de commandes fiable et ordonné.

→Utilisez Azure Event Grid pour le "fan-out" et l’événementiel réactif. Utilisez Azure Service Bus Queues (avec sessions pour l’ordonnancement) pour un traitement de commandes transactionnel et fiable.

Pourquoi: Event Grid est un service de routage d'événements léger, basé sur la poussée, optimisé pour la programmation réactive. Service Bus est un courtier de messages robuste avec des fonctionnalités telles que FIFO (sessions), la lettre morte et les transactions pour la messagerie d'entreprise.

Exposer en toute sécurité une API s’exécutant sur un VNet privé à des partenaires externes, avec des stratégies de limitation de débit et d’authentification.

→Déployez Azure API Management (APIM) en mode VNet interne, précédé d’une Azure Application Gateway avec WAF pour l’entrée publique.

Pourquoi: Ce modèle fournit une défense en profondeur. APIM dans le VNet peut accéder au backend privé. L’App Gateway termine le SSL, inspecte le trafic avec WAF et le transfère à l’instance APIM privée. Les stratégies APIM gèrent l’authentification, les limites de débit, etc.

Connecter des centaines de succursales et de VNets dans le monde entier avec une connectivité automatisée, de n’importe où à n’importe où.

→Azure Virtual WAN.

Pourquoi: Virtual WAN est la solution Microsoft gérée pour la mise en réseau de transit global à grande échelle. Il automatise le routage complexe et fournit un hub unifié pour connecter les spokes VPN, ExpressRoute et VNet.

Exécuter un travail par lots parallèle à grande échelle (par exemple, simulation CFD) nécessitant des milliers de cœurs et une communication MPI à faible latence.

→Azure Batch avec un pool de VM compatibles InfiniBand (par exemple, série HB) utilisant la tarification à faible priorité (Spot).

Pourquoi: Azure Batch est un planificateur de tâches conçu pour le HPC. Les VM compatibles InfiniBand fournissent la mise en réseau RDMA à haut débit et faible latence requise pour MPI. Les VM à faible priorité réduisent considérablement les coûts pour les charges de travail tolérantes aux pannes.

Une application dans un VNet doit accéder aux services PaaS (SQL, Storage) sans que le trafic ne traverse l’internet public.

→Créez des points de terminaison privés pour les services PaaS. Cela donne au service une adresse IP privée au sein de votre VNet.

Pourquoi: Les Private Endpoints sont la méthode la plus sécurisée pour la connectivité PaaS privée. Ils garantissent que le trafic reste sur le réseau dorsal de Microsoft et vous permettent de désactiver entièrement le point de terminaison public du service PaaS.

Héberger une application monopage (SPA) moderne avec un backend API serverless, une intégration CI/CD et un domaine personnalisé.

→Azure Static Web Apps.

Pourquoi: Il s’agit d’un service rationalisé et spécialement conçu pour ce modèle. Il combine l’hébergement de contenu statique, les Azure Functions intégrées pour l’API, l’intégration GitHub/Azure DevOps et les domaines personnalisés gérés avec des certificats SSL gratuits.

Gérer et appliquer la gouvernance (Azure Policy) aux serveurs s’exécutant sur site et dans d’autres clouds (par exemple, AWS) depuis Azure.

→Installez l’agent Azure Arc sur les serveurs non-Azure pour les projeter comme serveurs activés par Azure Arc.

Pourquoi: Azure Arc étend le plan de contrôle Azure à toute infrastructure. Une fois qu’un serveur est activé par Arc, il peut être géré avec Azure Policy, Monitor, Defender for Cloud, etc., tout comme une VM Azure native.

Migrer progressivement les fonctionnalités d’une application monolithique héritée vers de nouveaux microservices sans une bascule "big bang".

→Appliquez le modèle Strangler Fig en utilisant un proxy inverse comme Azure API Management ou Application Gateway.

Pourquoi: Le proxy inverse intercepte les appels vers le monolithe et achemine sélectivement le trafic pour des fonctionnalités spécifiques vers les nouveaux microservices. Au fil du temps, le proxy "étrangle" le monolithe en redirigeant de plus en plus de trafic jusqu’à ce que l’ancien système puisse être retiré.

Les VM se trouvent dans un VNet avec tunnellisation forcée (tout le trafic internet est routé sur site), mais elles ne peuvent pas accéder aux services Azure PaaS.

→La tunnellisation forcée bloque l’accès direct aux points de terminaison publics d’Azure. Utilisez des points de terminaison de service ou des points de terminaison privés pour l’accès PaaS. Alternativement, ajoutez des UDR pour des balises de service Azure spécifiques avec un "Internet" comme saut suivant pour contourner le tunnel.

Pourquoi: Les services PaaS ont des points de terminaison publics. La tunnellisation forcée envoie ce trafic sur site. Vous devez créer un chemin d’exception, soit en rendant le service PaaS privé (points de terminaison), soit en créant des exceptions de routage spécifiques (UDR avec balises de service).

Un réseau hub-spoke doit résoudre les noms DNS sur site depuis Azure, et les zones DNS privées Azure depuis sur site.

→Déployez Azure DNS Private Resolver dans le VNet hub. Configurez un point de terminaison entrant pour que le sur site résolve le DNS Azure, et un point de terminaison sortant avec des jeux de règles de redirection pour résoudre le DNS sur site depuis Azure.

Pourquoi: C’est la solution PaaS moderne pour la résolution DNS hybride, remplaçant la nécessité de gérer des VM de serveurs DNS personnalisés. Elle s’intègre nativement aux zones DNS privées et aux redirecteurs DNS sur site.

Plusieurs VNets ont besoin d’une IP publique prévisible et statique pour tout le trafic sortant, pour la mise en liste blanche par des services externes.

→Dans une topologie hub-spoke, routez tout le trafic sortant (0.0.0.0/0) des spokes via un Azure Firewall ou une NAT Gateway dans le VNet hub.

Pourquoi: La centralisation de la sortie dans le hub garantit que tout le trafic sortant utilise les IP publiques du pare-feu/NAT Gateway du hub, simplifiant la gestion et la mise en liste blanche externe. La NAT Gateway est plus simple pour le SNAT pur, tandis que le Firewall ajoute l’inspection de sécurité.

Traiter des données hautement sensibles de manière à ce qu’elles soient chiffrées même lorsqu’elles sont utilisées en mémoire, les protégeant de l’opérateur cloud.

→Utilisez des VM Azure Confidential Computing (séries DCsv3/ECsv3) avec Intel SGX ou AMD SEV-SNP pour exécuter du code dans un environnement d’exécution de confiance (TEE) basé sur le matériel ou une mémoire chiffrée.

Pourquoi: Le Confidential Computing aborde le pilier de sécurité "données en cours d’utilisation", ce que le chiffrement traditionnel au repos et en transit ne fait pas. Il offre une isolation vérifiable au niveau matériel.

Un fournisseur SaaS doit exposer son service, s’exécutant dans son VNet, à un client dans le VNet du client, entièrement sur le réseau privé Azure.

→Le fournisseur crée un Azure Private Link Service sur son Standard Load Balancer. Le client crée un Private Endpoint dans son VNet qui se connecte au service.

Pourquoi: Private Link est le modèle définitif pour une exposition de service sécurisée, privée et multi-locataire. Il évite l’exposition à l’internet public, les problèmes de chevauchement d’IP et les configurations complexes d’appairage de VNet.