Sécuriser votre environnement Azure
Maintenant que vous savez comment contrôler vos environnements et sécuriser vos pipelines de déploiement, vous pouvez envisager de désactiver l’accès humain à vos environnements contrôlés. Dans cette unité, vous découvrez comment structurer les autorisations de vos utilisateurs sur les environnements Azure. Ceci inclut comment autoriser l’accès dans les situations d’urgence et comment auditer les modifications apportées dans votre patrimoine Azure.
Bloquer l’accès humain
En bloquant l’accès humain à vos environnements contrôlés, vous garantissez qu’aucune modification accidentelle ou malveillante ne peut contourner les processus de revue et de déploiement automatisé de votre équipe. Si vous ne bloquez pas l’accès humain, quelqu’un peut contourner par inadvertance les contrôles que vous avez passé tant de temps à planifier et à implémenter dans votre dépôt et vos pipelines.
De plus, sans le blocage des contrôles, quelqu’un peut facilement endommager quelque chose sans le faire exprès. Prenons l’exemple d’un utilisateur avec deux copies du portail Azure ouvertes : une pour un environnement de test et l’autre pour l’environnement de production. Quand l’utilisateur passe d’un onglet à l’autre dans le navigateur, il peut accidentellement apporter des modifications destinées à un environnement de test à l’environnement de production.
Pour bloquer l’accès humain, vous pouvez utiliser le contrôle d’accès en fonction du rôle (RBAC) Azure. Dans RBAC, vous créez des attributions de rôles pour définir :
- les utilisateurs, groupes ou principaux de service qui peuvent accéder à un ensemble défini de ressources Azure (l’étendue) ;
- ce que ces utilisateurs, groupes ou principaux de service peuvent faire quand ils accèdent aux ressources (le rôle).
Azure RBAC fournit de nombreux types de rôles intégrés, notamment :
- Lecteur, qui permet d’accéder en lecture seule à l’environnement.
- Contributeur, qui permet de modifier des ressources.
- Propriétaire, qui permet de modifier des ressources et d’accorder l’accès à d’autres personnes.
Il est important d’accorder l’accès à une étendue appropriée. Si votre organisation suit la pratique recommandée consistant à utiliser des abonnements Azure dédiés pour chaque environnement, envisagez d’utiliser des groupes d’administration Azure pour simplifier l’étendue de vos attributions de rôles. Si votre organisation utilise un seul abonnement Azure pour tous vos environnements, évitez d’accorder aux utilisateurs humains l’accès à l’intégralité de l’abonnement, car toutes les ressources, y compris vos environnements contrôlés, héritent de cette autorisation.
Conseil
Les attributions de rôles sont des ressources Azure Resource Manager (ARM). Cela signifie que vous pouvez configurer vos attributions de rôles RBAC Azure dans du code, par exemple avec Bicep.
Quand vous planifiez vos attributions de rôles, vous devez décider de ce qui convient à votre organisation. Par exemple, supposons que votre organisation crée des abonnements distincts pour chacun de vos environnements. Vous pouvez choisir d’accorder à vos administrateurs et développeurs l’accès Lecteur à vos environnements contrôlés. Avec ce rôle, ils peuvent accéder à l’environnement de production dans le portail Azure pour passer en revue la configuration de vos ressources, consulter les métriques et les journaux, et investiguer les problèmes ou bogues sans modifier l’environnement.
Voici comment configurer vos attributions de rôles pour les environnements de votre entreprise de jouets, à la fois pour vos administrateurs Azure et les développeurs qui écrivent votre code et vos scripts :
| Nom de l’environnement | Niveau de contrôle | Autorisation administrateur | Autorisation développeur |
|---|---|---|---|
| Développement | Contrôlée | Lecteur | Lecteur |
| Test | Contrôlée | Lecteur | Lecteur |
| Staging | Contrôlée | Lecteur | Lecteur |
| Production | Contrôlée | Lecteur | Lecteur |
| Démonstration | Non contrôlé | Propriétaire | Contributeur |
| Tests de performances | Non contrôlé | Propriétaire | Aucun |
| Test d’intrusion | Non contrôlé | Propriétaire | Aucun |
| Revues des PR | Non contrôlé | Propriétaire | Propriétaire |
| Bacs à sable de développement | Non contrôlé | Propriétaire | Propriétaire |
Quand vous planifiez vos attributions de rôles, veillez à les tester minutieusement. Parfois, les opérations de gestion peuvent nécessiter des autorisations qui ne sont pas évidentes. Donnez aux membres de votre équipe la possibilité de tester toutes leurs tâches quotidiennes avec les autorisations que vous prévoyez d’utiliser. Passez en revue les problèmes qu’ils rencontrent.
Auditez régulièrement vos attributions de rôles. Vérifiez que vous n’avez pas accidentellement accordé l’accès aux mauvaises personnes ou un accès trop large.
Accès au plan de données
Il existe deux types d’opérations dans Azure :
- Opérations de plan de contrôle, pour gérer les ressources de votre abonnement.
- Opérations de plan de données, pour accéder aux fonctionnalités exposées par une ressource.
Par exemple, vous utilisez une opération de plan de contrôle pour créer un compte de stockage. Vous utilisez une opération de plan de données pour vous connecter au compte de stockage et accéder aux données qu’il contient.
Quand vous bloquez l’accès direct des utilisateurs à vos ressources Azure, réfléchissez également à la façon dont cette restriction s’applique aux opérations du plan de données. Par exemple, votre processus de déploiement peut stocker la clé d’un compte de stockage à un emplacement auquel un administrateur peut accéder. Cet administrateur peut potentiellement utiliser la clé pour contourner vos contrôles et accéder directement au plan de données du compte de stockage.
Un nombre croissant de ressources Azure prennent en charge la configuration du contrôle d’accès au plan de données avec Microsoft Entra ID. Cette prise en charge réduit le risque de fuite de clés ou d’octroi involontaire de l’accès au plan de données. Nous vous recommandons d’utiliser Microsoft Entra ID pour accéder au plan de données chaque fois que cela est possible.
Accès d’urgence
Parfois, des urgences surviennent et quelqu’un doit accéder rapidement à un environnement de production pour investiguer ou résoudre un problème. Il est important de planifier et de faire des exercices répétés quant à la façon dont vous voulez répondre à ces situations d’urgence bien avant qu’elles ne se produisent. Vous ne voulez pas prendre le risque de vous retrouver dans une course effrénée pour trouver une solution en plein milieu d’une panne.
Parmi les approches à considérer figure l’utilisation d’un compte de secours. Il s’agit d’un compte d’utilisateur spécial doté de niveaux d’autorisations plus élevés que ceux dont disposent normalement les utilisateurs. On parle de compte de secours (« break-glass ») parce qu’il nécessite une action inhabituelle pour accéder à ses informations d’identification, un peu comme l’utilisation d’un brise-vitre sur un panneau d’alarme incendie. Vous pouvez fournir à vos opérateurs un moyen sécurisé d’accéder aux informations d’identification du compte de secours. Ces opérateurs peuvent ensuite se connecter avec ce compte pour apporter les modifications d’urgence.
La séquence des étapes d’utilisation d’un compte de secours est la suivante :
- L’utilisateur tente d’effectuer une modification d’urgence avec son compte normal, mais l’opération est bloquée car le compte d’utilisateur normal ne dispose pas d’autorisations suffisantes.
- L’utilisateur accède aux informations d’identification du compte de secours et se connecte avec ce compte.
- L’utilisateur se connectant avec le compte de secours est autorisé à effectuer l’opération.
L’utilisation de comptes de secours nécessite un niveau élevé de discipline. Leur utilisation doit être réservée aux vraies situations d’urgence. Vous devez gérer et protéger soigneusement les informations d’identification de ces comptes, car ils possèdent des privilèges élevés. Il est recommandé de modifier fréquemment les informations d’identification des comptes de secours afin de minimiser le risque d’exposition et de compromission.
Les comptes de secours étant souvent partagés au sein d’une équipe, il est donc difficile de savoir qui les a utilisés et ce que les utilisateurs ont fait. Une autre approche des comptes d’urgence est d’adopter la fonctionnalité Microsoft Entra Privileged Identity Management (PIM). Celle-ci permet d’octroyer temporairement au compte d’un utilisateur un niveau d’autorisation plus élevé.
La séquence des étapes d’utilisation de PIM est la suivante :
L’utilisateur tente d’effectuer une modification d’urgence avec son compte normal, mais l’opération est bloquée car le compte d’utilisateur normal ne dispose pas d’autorisations suffisantes.
L’utilisateur contacte PIM et demande une élévation temporaire des autorisations.
PIM peut effectuer une validation supplémentaire de l’identité de l’utilisateur ou demander l’approbation de quelqu’un, selon la façon dont il est configuré pour l’organisation.
Si la demande est autorisée, PIM met à jour temporairement les autorisations de l’utilisateur.
L’utilisateur est autorisé à effectuer l’opération.
Une fois la période définie écoulée, PIM révoque les autorisations élevées accordées à l’utilisateur.
PIM et Azure écrivent des journaux d’audit complets pour vous aider à comprendre qui a demandé des autorisations élevées et pourquoi. Les journaux suivent également ce qu’ils ont fait dans votre environnement quand les autorisations ont été accordées.
Remarque
PIM nécessite une licence Premium pour Microsoft Entra ID.
Une fois l’urgence terminée
Au terme d’une situation d’urgence, il est important d’avoir un processus pour revenir aux opérations normales. Vous devez suivre ce processus sans laisser trop de temps s’écouler, au risque d’oublier des informations importantes ou de laisser des configurations dans un état non sécurisé.
Examinez attentivement les journaux d’audit Azure et PIM pour comprendre les modifications effectuées dans vos environnements contrôlés, en particulier dans votre environnement de production.
Important
Quelqu’un qui utilise PIM ou un compte de secours peut accorder à son compte d’utilisateur normal un niveau d’accès plus important que prévu. Il peut également utiliser les autorisations temporaires pour accéder aux clés de plan de données et continuer à s’en servir une fois les autorisations révoquées.
Auditez soigneusement toutes les utilisations de vos comptes de secours ou de PIM. Révoquez ou permutez les clés qui ont pu être exposées pendant l’urgence.
Peu après l’urgence, resynchronisez les ressources de votre infrastructure en tant que code avec toutes les modifications apportées pendant l’urgence. Par exemple, supposons que, dans le cadre de la résolution d’un problème urgent, un administrateur augmente manuellement la référence SKU d’un plan Azure App Service. Mettez à jour vos modèles de déploiement pour inclure la nouvelle référence SKU dans la configuration des ressources. Sinon, lors du prochain déploiement normal à partir de votre pipeline, la valeur précédente de la référence SKU peut être rétablie et provoquer une autre panne.
Auditer les modifications apportées à votre environnement Azure
Il est également recommandé de configurer l’audit et la journalisation dans l’ensemble de votre environnement Azure, et de monitorer des événements ou des menaces spécifiques.
Envisagez d’utiliser un outil SIEM (Gestion des informations et des événements de sécurité), comme Microsoft Sentinel. Vous pouvez utiliser cet outil pour collecter et analyser les journaux de votre patrimoine Azure, et même d’Azure DevOps, de GitHub et d’autres systèmes. Vous pouvez utiliser Sentinel pour monitorer les modifications inattendues ou non autorisées apportées à vos ressources Azure. Vous pouvez également importer les journaux d’audit de votre pipeline et déclencher des alertes lorsque certains événements se produisent, par exemple quand un administrateur modifie une stratégie de protection de branche dans votre dépôt.