Solution du scénario 2 - Application critique
Dans l’unité précédente, vous avez travaillé sur un scénario impliquant une haute disponibilité pour un système de répartition des appels aux services d’urgence. Dans cette unité, vous allez examiner une solution potentielle et certains autres é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 étape consiste souvent à identifier l’option de déploiement d’Azure SQL la plus adaptée. Si vous considérez seulement le contrat de niveau de service (SLA), la spécification est celle d’un contrat SLA de 99,995 %, que seul Azure SQL Database peut vous fournir. Pour obtenir ce contrat SLA, vous devez déployer le niveau de service Critique pour l’entreprise et activer l’utilisation des zones de disponibilité.
Un autre ensemble de décisions est lié à l’activation de la géoredondance et au maintien de la haute disponibilité en cas de sinistre. Bien que la géoréplication et les groupes de basculement automatique soient ici tous deux des options, les groupes de basculement automatique permettront au client d’effectuer un basculement si nécessaire, sans changer aucune chaîne de connexion. Cette configuration peut permettre de réduire les temps d’arrêt liés aux mises à jour des chaînes de connexion des applications, car elles ne seront pas nécessaires. Vous pouvez également configurer des requêtes de supervision pour vérifier l’état. Ainsi, en cas de problème, vous pouvez même forcer un basculement.
Dans cette configuration, il est également important de réfléchir au rôle joué par la colocation. Pour maintenir une haute disponibilité, votre application doit être le plus proche possible de votre base de données, et certainement dans la même région. Vous devez faire en sorte que votre application soit déployée dans les deux régions du groupe de basculement automatique, de sorte qu’il existe une copie redondante de l’application (par exemple une application web). En cas de basculement, vous pouvez utiliser Azure Traffic Manager pour rerouter le trafic vers l’application dans la région secondaire.
Administrateurs de bases de données et données sensibles
Les coordinateurs du système de répartition des appels aux services d’urgence ont exprimé leur souci de protéger les données sensibles (telles que l’historique médical et autres informations d’identification personnelle) tout en autorisant les administrateurs de bases de données à effectuer leur travail.
Pour garantir que les administrateurs de base de données ne peuvent pas voir les données sensibles stockées dans des colonnes spécifiques et que tout accès aux tables contenant des données sensibles est supervisé, vous pouvez utiliser quelques-unes des technologies d’Azure SQL. L’utilisation de l’audit SQL est une bonne pratique pour superviser l’accès, mais les administrateurs de bases de données pourront néanmoins toujours voir les données. La classification des données sensibles à l’aide de la fonctionnalité Classification des données aidera, car les données sensibles seront étiquetées et vous pourrez en effectuer le suivi avec l’audit SQL. Cependant, même si ces fonctionnalité sont implémentées, les administrateurs de bases de données pourront toujours voir les données sensibles. Vous pouvez utiliser le masquage dynamique des données pour masquer les données sensibles, mais il n’est pas possible d’empêcher un db_owner de visualiser des données utilisateur seulement avec des autorisations.
Si une base de données contient des données très sensibles, vous pouvez utiliser Always Encrypted pour empêcher les db_owners de les visualiser. Vous pouvez gérer les clés Always Encrypted avec la séparation des rôles, afin que l’administrateur de la sécurité n’accède pas à la base de données et que l’administrateur de base de données n’accède pas aux clés physiques en texte en clair. En appliquant cette stratégie conjointement avec la supervision via l’audit SQL, vous pouvez superviser, masquer et suivre l’accès aux données sensibles, même de la part des administrateurs de bases de données disposant de droits db_owner.
Les données sensibles doivent être masquées aux administrateurs de base de données, mais ils doivent néanmoins être en mesure de résoudre les problèmes de performances en utilisant le portail Azure, SQL Server Management Studio et Azure Data Studio. Ils doivent aussi pouvoir créer des utilisateurs de base de données autonome qui doivent être mappés à des principaux Microsoft Entra.
Une solution est de créer un groupe Microsoft Entra appelé « Administrateurs de bases de données SQL » pour les administrateurs de bases de données sur chaque instance. Ensuite, accordez à ce groupe le rôle RBAC Azure « Contributeur SQL Server ». Pour finir, vous pouvez définir le groupe en tant qu’administrateur Microsoft Entra sur le serveur logique.