Solution du scénario 1 - Concevoir une mise à l’échelle mondiale et un accès sécurisé
Dans l’unité précédente, vous avez travaillé sur un scénario impliquant une mise à l’échelle mondiale pour un réseau de distribution de contenu. Dans cette unité, vous allez examiner une solution potentielle et certains éléments à prendre en compte.
Ce faisant, vous devrez comparer la solution fournie à celle que vous avez développée dans l’unité précédente. Il existe souvent plusieurs solutions correctes à un problème, mais il y aura toujours des compromis à faire. Quels éléments de votre solution diffèrent de ceux proposés ? Existe-t-il quelque chose dans votre solution que vous pourriez repenser ? Existe-t-il quelque chose dans la solution fournie qui, selon vous, est traité de manière plus adéquate dans votre solution ?
Option de déploiement et configuration
La première décision à prendre concerne l’option de déploiement d’Azure SQL à sélectionner. Même si SQL Server dans une machine virtuelle Azure fonctionnerait, une offre PaaS peut s’avérer mieux adaptée et moins lourde en matière de gestion.
Le client utilise le common language runtime (CLR), qui est une fonctionnalité délimitée à une instance. Azure SQL Managed Instance est la seule option de déploiement PaaS qui prend en charge des fonctionnalités délimitées à une instance, comme CLR, Service Broker et Database Mail. Pour cette raison, Azure SQL Managed Instance peut lui permettre de passer à une offre PaaS sans devoir réécrire ses applications CLR dans une solution compatible avec Azure SQL Database (comme les travaux de base de données élastique).
La décision suivante à prendre concerne le niveau de service. Comme le client veut isoler ses charges de travail de lecture et d’écriture, l’utilisation du niveau de service Critique pour l’entreprise est la façon la plus simple d’y parvenir. Le niveau de service Critique pour l’entreprise a un groupe de disponibilité Always On déployé en arrière-plan. Un de ces réplicas secondaires peut être utilisé pour les charges de travail en lecture seule.
Le niveau Critique pour l’entreprise n’est qu’une moitié de la configuration permettant ici de séparer les charges de travail de lecture et d’écriture. Le scénario stipule que le client doit pouvoir effectuer une mise à l’échelle sur plusieurs régions avec plusieurs requêtes qui se produisent en même temps, tout en isolant les charges de travail de lecture et d’écriture.
Les deux options susceptibles de répondre à ces exigences sont la géoréplication et les groupes de basculement automatique. Toutefois, la géoréplication n’est pas prise en charge dans Azure SQL Managed Instance pour l’instant. L’utilisation d’un groupe de basculement automatique est par conséquent la seule option susceptible de fournir une échelle lecture globale dans ce scénario.
Comme le client utilise des groupes de basculement automatique, le besoin d’avoir ou pas le niveau de service Critique pour l’entreprise dépendra du nombre de points de terminaison en lecture seule dont sa charge de travail analytique a besoin. Avec un groupe de basculement automatique dans le niveau de service Critique pour l’entreprise, le client obtient trois points de terminaison où effectuer les lectures :
- Un réplica secondaire dans le groupe de disponibilité de la région primaire
- Le réplica secondaire du groupe de basculement (qui est le réplica principal de la base de données dans la région secondaire)
- Le réplica secondaire dans le groupe de disponibilité de la région secondaire
Si la charge de travail analytique n’a pas besoin de tous ces réplicas lisibles, le niveau Usage général peut être une solution plus économique.
Sélection des méthodes d’authentification les plus appropriées
L’autre partie de ce scénario implique la détermination de la meilleure façon pour chaque application ou personne de se connecter à la solution, étant donné la nécessité de créer et d’utiliser les technologies les plus sécurisées possibles. Si vous décomposez le scénario, vous voyez que quatre clients distincts auront besoin d’accéder à Azure SQL Managed Instance :
- Application exécutée sur une machine virtuelle Azure
- Application exécutée sur une machine non-Azure jointe à un domaine
- Administrateurs de base de données ou d’autres utilisateurs d’outils d’administration SQL (SQL Server Management Studio, Azure Data Studio, PowerShell) à partir d’une machine non-Azure non jointe à un domaine
- Applications plus anciennes exécutées sur une machine non-Azure où vous ne pouvez pas changer le pilote ou la chaîne de connexion
Examinons pour chacun ces clients comment choisir la méthode d’authentification, ainsi que d’autres considérations et contraintes supplémentaires.
Application exécutée sur une machine virtuelle Azure
Les identités managées pour les ressources Azure sont généralement la forme recommandée d’authentification sans mot de passe pour les applications qui s’exécutent sur des machines virtuelles Azure.
Application exécutée sur une machine non-Azure jointe à un domaine
Pour les machines non-Azure, l’utilisation d’identités managées n’est pas une option. L’authentification intégrée via Microsoft Entra ID est la méthode d’authentification recommandée pour les applications qui s’exécutent sur des ordinateurs joints à un domaine en dehors d’Azure, en supposant que le domaine a été fédéré avec Microsoft Entra ID.
Si l’ordinateur non-Azure n’est pas joint à un domaine, vous pouvez :
- Créer une identité d’application pour votre application dans Microsoft Entra ID.
- Associer un certificat à l’identité de l’application.
- Modifier votre application afin d’obtenir un jeton pour Azure SQL Database en fournissant un ID client et un certificat.
Même si le certificat doit contenir une clé privée et être déployé sur la machine hébergeant votre application, vous évitez au moins de devoir coder en dur un secret d’application dans le code ou la configuration de l’application. (Vous devrez configurer l’application avec l’empreinte numérique du certificat.)
Administrateurs de base de données ou autres utilisateurs des outils d’administration SQL à partir d’une machine non-Azure non jointe à un domaine
Pour les utilisateurs en dehors d’Azure, il est recommandé d’éliminer dans la mesure du possible l’utilisation de mots de passe. Vous pouvez éliminer l’utilisation des mots de passe avec les outils SQL en utilisant l’authentification intégrée Microsoft Entra. Cependant, les outils doivent s’exécuter sur un ordinateur joint à un domaine, et le domaine doit avoir été fédéré avec Microsoft Entra ID, ce qui n’est pas le cas dans ce scénario.
Étant donné que l’environnement ne satisfait pas les prérequis pour l’authentification intégrée, nous vous recommandons d’utiliser l’authentification interactive Microsoft Entra avec l’authentification multifacteur, que la plupart des outils SQL prennent en charge.
Applications plus anciennes exécutées sur une machine non-Azure où vous ne pouvez pas changer le pilote ou la chaîne de connexion
Dans les scénarios où la chaîne de connexion ou le pilote ne peut pas être modifié, il n’existe aujourd’hui aucune option pour éliminer les mots de passe. Ces applications plus ancienne doivent continuer à utiliser l’authentification SQL. Vous pourriez examiner les restrictions de façon plus approfondie, et réfléchir à la manière dont elles pourraient être levées afin de mettre en place une approche plus sécurisée pour l’authentification des applications.