L’ingénierie de sécurité transforme une exigence liée à une charge de travail en un contrôle pouvant être testé, surveillé et supprimé en toute sécurité. Dans Azure, ce travail s’étend au locataire Microsoft Entra, à Azure Resource Manager au sein d’un abonnement et au plan de données de chaque service ; ainsi, un paramètre apparemment correct peut en réalité protéger une portée inappropriée.
Nous utiliserons une charge de travail de développement délimitée au sein du groupe de ressources fictif rg-orders-dev. L’objectif est de présenter les décisions, les preuves et les limites qu’un ingénieur en sécurité cloud doit établir avant de considérer une configuration comme une mesure de protection.
Commencez par une exigence liée à un actif et à une menace. Par exemple, une API de traitement des commandes doit récupérer un secret sans l’exposer sur l’Internet public. Un contrôle est le mécanisme configuré pour satisfaire cette exigence, tandis qu’une preuve est un enregistrement observable étayant une affirmation spécifique concernant sa configuration ou son activité.
Notre flux de travail est cohérent. Nous identifions l’actif, la limite des données, l’identité et la menace ; nous choisissons le contrôle approprié le plus restreint ; nous définissons l’échec attendu si l’accès est refusé ou si le trafic emprunte un chemin non prévu ; enfin, nous vérifions le résultat escompté à l’aide de preuves issues de la configuration et de l’exécution. L’étape de nettoyage supprime les autorisations temporaires, les secrets de test ou les paramètres de diagnostic lorsqu’ils ne sont plus nécessaires, évitant ainsi que des artefacts de test ne deviennent des vecteurs d’exposition permanents.
Les preuves de configuration et les preuves d’exécution répondent à des questions différentes. Une attribution de rôle ou la configuration d’un point de terminaison privé démontre l’état souhaité du plan de contrôle. Un événement d’audit Key Vault, un journal de diagnostic de stockage ou une défaillance applicative témoigne d’une tentative observée au niveau du plan de données durant la période enregistrée. Aucun de ces éléments ne suffit à lui seul à garantir que tous les chemins sont sécurisés ou qu’un incident n’a pas d’autre cause.
Les recommandations permettent d’identifier les lacunes en matière de posture, mais l’application effective des mesures doit reposer sur une stratégie de refus ou sur le contrôle lui-même.
Microsoft sécurise l’infrastructure physique Azure sous-jacente, tandis que le client reste responsable des données de la charge de travail, du comportement de l’application, des identités et des choix en matière d’accès. Cette limite de responsabilité partagée ne signifie pas qu’un service géré par la plateforme ne nécessite aucune intervention du client en matière de sécurité. Elle implique d’identifier quelle partie est responsable de chaque couche avant de déterminer les éléments de preuve ou les mesures correctives à adopter.
L’annuaire Microsoft Entra authentifie les utilisateurs, les applications et les identités gérées. Azure Resource Manager (souvent appelé ARM) constitue le plan de contrôle d’Azure pour la création et la configuration de ressources au sein d’un abonnement ou d’un groupe de ressources. Les attributions de rôles Azure RBAC à ces niveaux d’étendue autorisent des actions sur le plan de contrôle, telles que la modification de la configuration réseau d’un compte de stockage.
Le plan de données d’un service correspond à l’interface spécifique au service permettant de lire, d’écrire ou d’utiliser des données protégées. La récupération de secrets dans Key Vault et l’accès aux données Blob s’effectuent sur leurs plans de données respectifs ; à ce niveau, les autorisations spécifiques au plan de données et les contrôles réseau s’appliquent indépendamment des autorisations ARM. Un utilisateur disposant du rôle « Contributeur » et pouvant configurer un coffre n’est pas pour autant autorisé à en lire les secrets.
Une règle applicable dans de nombreux cas consiste à identifier le principal, l’action, l’étendue et le plan concernés avant de déterminer si l’accès doit aboutir.
Notre charge de travail fictive est app-orders-api, une application Azure App Service située dans le groupe de ressources rg-orders-dev et l’abonnement fictif <subscription-id>. Elle s’exécute dans une région Azure donnée et utilise vnet-orders-dev pour l’intégration réseau virtuelle sortante. L’application nécessite des données de commande stockées dans stordersdev ainsi qu’un secret conservé dans kv-orders-dev, tandis que law-sec-01 désigne l’espace de travail Log Analytics utilisé par Microsoft Sentinel.
Le réseau virtuel constitue la limite réseau de l’application, et non l’emplacement de toutes les ressources des services Azure. stordersdev et kv-orders-dev demeurent des services de la plateforme Azure situés en dehors de vnet-orders-dev ; les points de terminaison privés placent des interfaces réseau privées pour ces services au sein du réseau virtuel. Le DNS privé et les paramètres réseau du service doivent diriger les requêtes sortantes de l’API vers les adresses de ces points de terminaison plutôt que vers un point de terminaison public.
L’identité gérée de l’application nécessitera ultérieurement des autorisations distinctes au niveau du plan de données pour les actions prévues sur Key Vault et le stockage. Sentinel s’exécute sur law-sec-01, où les connecteurs et les paramètres de diagnostic déterminent quels enregistrements sont transmis pour analyse. Un espace de travail ne permet d’effectuer des investigations que sur les données qui y ont été réellement collectées.
Délimitez le périmètre de la charge de travail, de l’API jusqu’à ses points de terminaison privés et son espace de travail de surveillance.