Sécurité Azure pour des applications natives cloud
Conseil
Ce contenu est un extrait du livre électronique, Cloud Native .NET apps for Azure (Architecture d’applications .NET natives cloud pour Azure), disponible dans la documentation .NET ou au format PDF à télécharger gratuitement pour le lire hors connexion.
Les applications natives cloud peuvent être à la fois plus faciles et plus difficiles à sécuriser que les applications traditionnelles. En revanche, vous devez sécuriser des applications plus petites et consacrer plus d’énergie à la génération de l’infrastructure de sécurité. La nature hétérogène des langages et styles de programmation dans la plupart des déploiements de services signifie également que vous devez prêter plus d’attention aux bulletins de sécurité de nombreux fournisseurs différents.
D’un autre côté, les services plus petits, chacun avec son propre magasin de données, limitent l’étendue d’une attaque. Si un attaquant compromet un système, il est probablement plus difficile pour l’attaquant de passer à un autre système que dans une application monolithique. Les limites de processus sont des limites fortes. En outre, si une sauvegarde de base de données est exposée, les dommages sont plus limités, car cette base de données ne contient qu’un sous-ensemble de données et est peu susceptible de contenir des données personnelles.
Modélisation des menaces
Peu importe si les avantages l’emportent sur les inconvénients des applications natives cloud, le même état d’esprit de sécurité holistique doit être suivi. La sécurité et la réflexion sécurisée doivent faire partie de chaque étape de l’histoire du développement et des opérations. Lors de la planification d’une application, posez des questions telles que :
- Quel serait l’impact de la perte de ces données ?
- Comment pouvons-nous limiter les dommages causés par l’injection de données incorrectes dans ce service ?
- Qui doit avoir accès à ces données ?
- Existe-t-il des stratégies d’audit en place autour du processus de développement et de mise en production ?
Toutes ces questions font partie d’un processus appelé modélisation des menaces. Ce processus tente de répondre à la question de savoir quelles sont les menaces qui pèsent sur le système, quelles sont les probabilités des menaces et les dommages potentiels qu’elles peuvent causer.
Une fois la liste des menaces établie, vous devez décider si elles valent la peine d’être atténuées. Parfois, une menace est si peu probable et coûteuse à planifier qu’elle ne vaut pas la peine de dépenser de l’énergie dessus. Par exemple, un acteur au niveau de l’état peut injecter des changements dans la conception d’un processus utilisé par des millions d’appareils. Maintenant, au lieu d’exécuter un certain morceau de code dans laBoucle 3, ce code est exécuté dans la Boucle 0. Ce processus permet un code malveillant exploitant une faille de sécurité qui peut contourner l’hyperviseur et exécuter le code d’attaque sur les machines de matériel nu, ce qui autorise les attaques sur toutes les machines virtuelles s’exécutant sur ce matériel.
Les processeurs modifiés sont difficiles à détecter sans un microscope et une connaissance avancée de la conception en silicium de ce processeur. Ce scénario est peu probable et coûteux à atténuer. Par conséquent, aucun modèle de menace ne recommanderait probablement la génération d’une protection contre les attaques.
Les menaces plus probables, telles que les contrôles d’accès rompus autorisant Id des attaques incrémentielles (remplacement par Id=2Id=3 dans l’URL) ou l’injection SQL, sont plus intéressantes pour générer des protections. Les mesures d’atténuation de ces menaces sont tout à fait raisonnables pour générer et empêcher les failles de sécurité embarrassantes qui salissent la réputation de l’entreprise.
Principe du privilège minimum
L’une des idées fondatrices en matière de sécurité informatique est la Séparation des privilèges (POLP). Il s’agit en fait d’une idée fondamentale en matière de sécurité, qu’elle soit numérique ou physique. En bref, le principe est que tout utilisateur ou processus doit disposer du nombre minimal de droits pour exécuter sa tâche.
Par exemple, pensez aux caissiers dans une banque : l’accès au coffre-fort est une activité rare. Donc, le caissier moyen ne peut pas ouvrir le coffre-fort lui-même. Pour obtenir l’accès, il doit transmettre sa demande à son manager qui effectue des vérifications de sécurité supplémentaires.
Dans un système informatique, prenons l’exemple fantastique des droits d’un utilisateur qui se connecte à une base de données. Dans de nombreux cas, un seul compte d’utilisateur est utilisé pour générer la structure de base de données et exécuter l’application. Sauf dans les cas extrêmes, le compte exécutant l’application n’a pas besoin de mettre à jour les informations de schéma. Plusieurs comptes doivent fournir différents niveaux de privilège. L’application doit utiliser uniquement le niveau d’autorisation qui accorde l’accès en lecture et en écriture aux données dans les tables. Ce type de protection éliminerait les attaques visant à supprimer des tables de base de données ou à introduire des déclencheurs malveillants.
Presque toutes les parties de la génération d’une application native cloud peuvent tirer parti de la mémorisation du principe des privilèges minimum. Vous pouvez le trouver lors de la configuration de pare-feu, de groupes de sécurité réseau, de rôles et d’étendues dans le contrôle d’accès en fonction du rôle (RBAC).
Test d’intrusion
À mesure que les applications se compliquent, le nombre de vecteurs d’attaque augmente à un rythme alarmant. La modélisation des menaces présente des défauts car elle tend à être exécutée par ceux qui génèrent le système. De la même façon que de nombreux développeurs ont des difficultés à imaginer les interactions utilisateur et à générer ensuite des interfaces utilisateur inutilisables, la plupart des développeurs ont des difficultés à percevoir chaque vecteur d’attaque. Il est également possible que les développeurs qui génèrent le système ne connaissent pas bien les méthodologies d’attaque et manquent quelque chose d’essentiel.
Les tests d’intrusion ou « test de stylet » impliquent l’intervention d’acteurs externes tentant d’attaquer le système. Ces attaquants peuvent être une société de conseil externe ou d’autres développeurs ayant de bonnes connaissances en matière de sécurité d’une autre partie de l’entreprise. Ils ont carte blanche pour tenter de renverser le système. Ils trouveront souvent des failles de sécurité étendues qui doivent être corrigées. Parfois, le vecteur d’attaque est quelque chose de totalement inattendu, comme l’exploitation d’une attaque par hameçonnage contre le PDG.
Azure lui-même subit constamment des attaques d’une équipe de pirates informatiques au sein de Microsoft. Au fil des ans, ils ont été les premiers à trouver des dizaines de vecteurs d’attaques potentiellement catastrophiques et les ont fermés avant qu’ils ne soient exploités à l’extérieur. Plus une cible est tentante, plus les acteurs éternels essaieront de l’exploiter et il y a quelques cibles dans le monde plus tentantes qu’Azure.
Monitoring
Si un attaquant tente de pénétrer une application, un avertissement doit être déclenché. Souvent, les attaques peuvent être détectées en examinant les journaux des services. Les attaques laissent des signes révélateurs qui peuvent être repérés avant qu’elles ne réussissent. Par exemple, un attaquant qui tente de deviner un mot de passe effectue de nombreuses demandes à un système de connexion. Le monitoring autour du système de connexion peut détecter des modèles étranges qui ne sont pas conformes au modèle d’accès classique. Ce monitoring peut être transformé en une alerte qui peut, à son tour, alerter une personne chargée des opérations qui active une sorte de contre-mesure. Un système de monitoring hautement mature peut même prendre des mesures en fonction de ces écarts en ajoutant de manière proactive des règles pour bloquer les demandes ou limiter les réponses.
Sécurisation de la build
L’un des endroits où la sécurité est souvent ignorée concerne le processus de génération. Non seulement la build doit exécuter des vérifications de sécurité, telles que l’analyse du code non sécurisé ou des informations d’identification archivées, mais elle doit être elle-même sécurisée. Si le serveur de build est compromis, il fournit un vecteur fantastique pour introduire du code arbitraire dans le produit.
Imaginez qu’un attaquant cherche à voler les mots de passe des personnes qui se connectent à une application web. Il peut introduire une phase de génération qui modifie le code extrait pour mettre en miroir toute demande de connexion sur un autre serveur. La prochaine fois que le code passe par la build, il est mis à jour en mode silencieux. L’analyse des vulnérabilités du code source n’intercepte pas cette vulnérabilité car elle s’exécute avant la build. De même, personne ne l’interceptera dans une révision de code, car les phases de génération sont actives sur le serveur de génération. Le code exploité est mis en production et peut alors collecter les mots de passe. Il n’y a probablement aucun journal d’audit des modifications du processus de génération et presque personne ne surveille l’audit.
Ce scénario est un exemple parfait d’une cible apparemment faible qui peut être utilisée pour s’introduire dans le système. Une fois qu’un attaquant a enfreint le périmètre du système, il peut commencer à rechercher des moyens d’élever ses autorisations pour causer des dommages réels où qu’ils le souhaitent.
Génération d’un code sécurisé
.NET Framework est déjà une infrastructure assez sécurisée. Elle évite certains pièges du code non sécurisé, comme le fait de sortir des extrémités des tableaux. L’objectif est de corriger activement les failles de sécurité au fur et à mesure qu’elles sont découvertes. Il existe même un programme de primes aux bogues qui récompense les chercheurs pour la découverte des problèmes au sein de l’infrastructure et pour leur signalement avant toute exploitation.
Il existe de nombreuses façons de sécuriser le code .NET. Les directives suivantes, notamment l’article Directives de codage sécurisé pour .NET, constituent une étape raisonnable à prendre en compte pour s’assurer que le code est sécurisé à partir de zéro. Le top 10 OWASP est un autre guide précieux pour générer du code sécurisé.
Le processus de génération est l’endroit idéal pour mettre en place des outils d’analyse afin de détecter les problèmes dans le code source avant qu’il ne soit mis en production. La plupart des projets ont des dépendances sur d’autres packages. Un outil capable de rechercher des packages obsolètes intercepte les problèmes dans une build nocturne. Même lors de la création d’images Docker, il est utile de vérifier et de s’assurer que l’image de base n’a pas de vulnérabilités connues. Une autre chose à vérifier est que personne n’a accidentellement archivé les informations d’identification.
Sécurité intégrée
Azure est conçu pour équilibrer la facilité d’utilisation et la sécurité pour la plupart des utilisateurs. Les différents utilisateurs disposent d’exigences de sécurité différentes, ils doivent donc affiner leur approche de la sécurité du cloud. Microsoft publie de nombreuses informations de sécurité dans le Centre de confidentialité. Cette ressource doit être la première étape pour les professionnels qui souhaitent comprendre le fonctionnement des technologies intégrées d’atténuation des attaques.
Dans le Portail Azure, Azure Advisor est un système qui analyse constamment un environnement et fait des suggestions. Certaines de ces suggestions sont conçues pour faire économiser de l’argent aux utilisateurs, mais d’autres sont conçues pour identifier les configurations potentiellement non sécurisées, comme avoir un conteneur de stockage ouvert au monde et non protégé par un Réseau virtuel.
Infrastructure réseau Azure
Dans un environnement de déploiement local, une grande quantité d’énergie est consacrée à la mise en réseau. La configuration de routeurs, de commutateurs etc est compliquée. Les réseaux permettent à certaines ressources de communiquer avec d’autres ressources et d’empêcher l’accès, dans certains cas. Une règle de réseau fréquente consiste à restreindre l’accès à l’environnement de production à partir de l’environnement de développement en cas de risque qu’une partie de code semi-développée s’exécute mal et supprime une étendue de données.
Prêtes à l’emploi, la plupart des ressources Azure PaaS ont simplement la configuration réseau la plus basique et permissive. Par exemple, toute personne sur Internet peut accéder à un service d’application. Les nouvelles instances SQL sont généralement restreintes, de sorte que les parties externes ne peuvent pas y accéder, mais les plages d’adresses IP utilisées par Azure lui-même sont autorisées. Ainsi, alors que le serveur SQL est protégé contre les menaces externes, un attaquant doit uniquement configurer une tête de pont Azure à partir de laquelle il peut lancer des attaques contre toutes les instances SQL sur Azure.
Heureusement, la plupart des ressources Azure peuvent être placées sur un réseau virtuel Azure qui permet un contrôle d’accès affiné. À l’instar de la façon dont les réseaux locaux établissent des réseaux privés protégés du monde entier, les réseaux virtuels sont des îlots d’adresses IP privées qui se trouvent dans le réseau Azure.
Figure 9-1. Réseau virtuel dans Azure.
De la même façon que les réseaux locaux ont un pare-feu régissant l’accès au réseau, vous pouvez établir un pare-feu similaire à la limite du réseau virtuel. Par défaut, toutes les ressources d’un réseau virtuel peuvent toujours communiquer avec Internet. Il ne s’agit que de connexions entrantes qui nécessitent une forme d’exception de pare-feu explicite.
Une fois le réseau établi, les ressources internes telles que les comptes de stockage peuvent être configurées pour autoriser uniquement l’accès des ressources qui se trouvent également sur le Réseau virtuel. Ce pare-feu fournit un niveau de sécurité supplémentaire. Si les clés de ce compte de stockage sont divulguées, les attaquants ne seraient pas en mesure de se connecter à celui-ci pour exploiter les clés divulguées. Ce scénario est un autre exemple du principe des privilèges minimum.
Les nœuds d’un cluster Azure Kubernetes peuvent participer à un réseau virtuel comme d’autres ressources plus natives d’Azure. Cette fonctionnalité est appelée Azure Container Networking Interface. En effet, il alloue un sous-réseau au sein du réseau virtuel sur lequel les machines virtuelles et les images conteneur sont allouées.
En continuant à illustrer la séparation des privilèges, toutes les ressources au sein d’un Réseau virtuel n’ont pas besoin de parler à toutes les autres ressources. Par exemple, dans une application qui fournit une API web sur un compte de stockage et une base de données SQL, il est peu probable que la base de données et le compte de stockage doivent se parler. Tout partage de données entre eux passe par l’application web. Par conséquent, un groupe de sécurité réseau (NSG) peut être utilisé pour refuser le trafic entre les deux services.
Une stratégie de refus de communication entre les ressources peut être difficile à implémenter, en particulier dans un contexte d’utilisation d’Azure sans restrictions de trafic. Sur certains autres clouds, le concept de groupes de sécurité réseau est beaucoup plus répandu. Par exemple, la stratégie par défaut sur AWS est que les ressources ne peuvent pas communiquer entre elles tant que les règles n’ont pas été activées dans un groupe de sécurité réseau. Bien que le développement soit plus lent, un environnement plus restrictif fournit une valeur par défaut plus sécurisée. L’utilisation de pratiques DevOps appropriées, en particulier l’utilisation de Azure Resource Manager ou Terraform pour gérer les autorisations, peut faciliter le contrôle des règles.
Les Réseaux virtuels peuvent également être utiles lors de la configuration de la communication entre les ressources locales et cloud. Un réseau privé virtuel peut être utilisé pour attacher en toute transparence les deux réseaux. Cette approche permet d’exécuter un réseau virtuel sans aucune sorte de passerelle pour les scénarios où tous les utilisateurs sont sur site. Il existe un certain nombre de technologies qui peuvent être utilisées pour établir ce réseau. La plus simple consiste à utiliser un VPN site à site qui peut être établi entre de nombreux routeurs et Azure. Le trafic est chiffré et canalisé sur Internet au même coût par octet que tout autre trafic. Pour les scénarios où plus de bande passante ou plus de sécurité est souhaitable, Azure propose un service appelé Route Express qui utilise un circuit privé entre un réseau local et Azure. Il est plus coûteux et difficile à établir, mais aussi plus sécurisé.
Contrôle d’accès en fonction du rôle pour restreindre l’accès aux ressources Azure
RBAC est un système qui fournit une identité aux applications s’exécutant dans Azure. Les applications peuvent accéder aux ressources à l’aide de cette identité à la place ou en plus de l’utilisation de clés ou de mots de passe.
Principaux de sécurité
Le premier composant de RBAC est un principal de sécurité. Un principal de sécurité peut être un utilisateur, un groupe, un principal de service ou une identité managée.
Figure 9-2. Différents types de principaux de sécurité.
- Utilisateur : tout utilisateur disposant d’un compte dans Azure Active Directory est un utilisateur.
- Groupe : collection d’utilisateurs d’Azure Active Directory. En tant que membre d’un groupe, un utilisateur assume les rôles de ce groupe en plus des siens.
- Principal de service : identité de sécurité sous laquelle les services ou les applications s’exécutent.
- Identité managée : identité Azure Active Directory managée par Azure. Les identités managées sont généralement utilisées lors du développement d’applications cloud qui gèrent les informations d’identification pour l’authentification auprès des services Azure.
Le principal de sécurité peut être appliqué à la plupart des ressources. Cet aspect signifie qu’il est possible d’affecter un principal de sécurité à un conteneur s’exécutant dans Azure Kubernetes, ce qui lui permet d’accéder aux secrets stockés dans Key Vault. Une fonction Azure peut prendre une autorisation lui permettant de communiquer avec une instance Active Directory pour valider un JWT pour un utilisateur appelant. Une fois les services activés avec un principal de service, leurs autorisations peuvent être managées de manière granulaire à l’aide de rôles et d’étendues.
Rôles
Un principal de sécurité peut assumer de nombreux rôles ou, en utilisant une analogie plus sartoriale, porter de nombreux chapeaux. Chaque rôle définit une série d’autorisations telles que « Lire des messages à partir du point de terminaison Azure Service Bus ». Le jeu d’autorisations effectif d’un principal de sécurité est la combinaison de toutes les autorisations affectées à tous les rôles dont dispose un principal de sécurité. Azure dispose d’un grand nombre de rôles intégrés et les utilisateurs peuvent définir leurs propres rôles.
Figure 9-3. Définitions de rôles RBAC.
Azure est également intégré à un certain nombre de rôles de haut niveau, tels que Propriétaire, Contributeur, Lecteur et Administrateur de compte d’utilisateur. Avec le rôle Propriétaire, un principal de sécurité peut accéder à toutes les ressources et attribuer des autorisations à d’autres personnes. Un contributeur a le même niveau d’accès à toutes les ressources, mais il ne peut pas attribuer d’autorisations. Un lecteur peut uniquement afficher les ressources Azure existantes et un administrateur de compte d’utilisateur peut gérer l’accès aux ressources Azure.
Les rôles intégrés plus granulaires tels que Contributeur de zone DNS ont des droits limités à un seul service. Les principaux de sécurité peuvent prendre n’importe quel nombre de rôles.
Étendues
Les rôles peuvent être appliqués à un ensemble restreint de ressources dans Azure. Par exemple, en appliquant l’étendue à l’exemple précédent de lecture à partir d’une file d’attente Service Bus, vous pouvez restreindre l’autorisation à une seule file d’attente : « Lire des messages à partir du point de terminaison Azure Service Busblah.servicebus.windows.net/queue1»
L’étendue peut se restreindre à une ressource unique ou être appliquée à un groupe de ressources entier, un abonnement ou même un groupe d’administration.
Lors du test, si un principal de sécurité dispose d’une autorisation spécifique, la combinaison de rôles et d’étendues est prise en compte. Cette combinaison fournit un mécanisme d’autorisation puissant.
Deny
Auparavant, seules les règles « autoriser » étaient autorisées pour RBAC. Ce comportement a compliqué la génération de certaines étendues. Par exemple, autoriser un principal de sécurité à accéder à tous les comptes de stockage, à l’exception d’un, nécessite l’octroi d’autorisations explicites à une liste potentiellement infinie de comptes de stockage. Chaque fois qu’un compte de stockage est créé, il doit être ajouté à cette liste de comptes. Cela a ajouté une surcharge de gestion qui n’était certainement pas souhaitable.
Les règles de refus sont prioritaires sur les règles d’autorisation. Maintenant, la représentation de la même étendue « autoriser tous sauf un » peut être représentée par deux règles « autoriser tout » et « refuser cette règle spécifique ». Les règles de refus facilitent non seulement la gestion, mais autorisent également des ressources plus sécurisées en refusant l’accès à tout le monde.
Vérification de l'accès
Comme vous pouvez l’imaginer, le fait de disposer d’un grand nombre de rôles et d’étendues peut compliquer la recherche de l’autorisation effective d’un principal de service. En plus de cela, l’accumulation de règles de refus ne fait qu’accroître la complexité. Heureusement, il existe une calculatrice d’autorisations qui peut afficher les autorisations effectives pour n’importe quel principal de service. Il se trouve généralement sous l’onglet IAM du portail, comme illustré dans la figure 9-3.
Figure 9-4. Calculatrice d’autorisations pour un service d’application.
Sécurisation des secrets
Les mots de passe et les certificats sont un vecteur d’attaque courant pour les attaquants. Le matériel de craquage de mot de passe peut effectuer une attaque par force brute et essayer de deviner des milliards de mots de passe par seconde. Il est donc important que les mots de passe utilisés pour accéder aux ressources soient forts, avec une grande variété de caractères. Ces mots de passe sont exactement le type de mots de passe qui sont presque impossibles à mémoriser. Heureusement, les mots de passe dans Azure n’ont pas besoin d’être connus d’un humain.
De nombreux experts en sécurité suggèrent que l’utilisation d’un gestionnaire de mots de passe pour conserver vos propres mots de passe est la meilleure approche. Bien qu’il centralise vos mots de passe dans un emplacement unique, il permet également d’utiliser des mots de passe très complexes et de s’assurer qu’ils sont uniques pour chaque compte. Le même système existe dans Azure : un magasin central pour les secrets.
Azure Key Vault
Azure Key Vault fournit un emplacement centralisé pour stocker les mots de passe pour des éléments tels que les bases de données, les clés API et les certificats. Une fois qu’un secret est entré dans le coffre, il n’est plus jamais affiché et les commandes pour l’extraire et l’afficher sont délibérément compliquées. Les informations contenues dans le coffre-fort sont protégées à l’aide d’un chiffrement logiciel ou de modules de sécurité matériels FIPS 140-2 de niveau 2 validés.
L’accès au coffre de clés est fourni par le biais de RBAC, ce qui signifie que n’importe quel utilisateur ne peut pas accéder aux informations contenues dans le coffre. Supposons qu’une application web souhaite accéder à la chaîne de connexion de base de données stockée dans Azure Key Vault. Pour obtenir l’accès, les applications doivent s’exécuter à l’aide d’un principal de service. Sous ce rôle assumé, ils peuvent lire les secrets du coffre-fort. Il existe un certain nombre de paramètres de sécurité différents qui peuvent limiter davantage l’accès d’une application au coffre, de sorte qu’elle ne peut pas mettre à jour les secrets, mais uniquement les lire.
L’accès au coffre de clés peut être analysé pour s’assurer que seules les applications attendues accèdent au coffre. Les journaux peuvent être intégrés de nouveau dans Azure Monitor, ce qui permet de configurer des alertes lorsque des conditions inattendues sont rencontrées.
Kubernetes
Dans Kubernetes, il existe un service similaire pour la gestion de petits éléments d’informations secrètes. Les secrets Kubernetes peuvent être définis via l’exécutable kubectl type.
La création d’un secret est aussi simple que la recherche de la version base64 des valeurs à stocker :
echo -n 'admin' | base64
YWRtaW4=
echo -n '1f2d1e2e67df' | base64
MWYyZDFlMmU2N2Rm
Ensuite, en l’ajoutant à un fichier de secrets nommé secret.yml par exemple qui ressemble à l’exemple suivant :
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
username: YWRtaW4=
password: MWYyZDFlMmU2N2Rm
Enfin, ce fichier peut être chargé dans Kubernetes en exécutant la commande suivante :
kubectl apply -f ./secret.yaml
Ces secrets peuvent ensuite être montés dans des volumes ou exposés à des processus de conteneur via des variables d’environnement. L’approche de l’application à douze facteurs pour la génération d’applications suggère d’utiliser le plus petit dénominateur commun pour transmettre les paramètres à une application. Les variables d’environnement sont le plus petit dénominateur commun, car elles sont prises en charge quel que soit le système d’exploitation ou l’application.
Une alternative pour utiliser les secrets Kubernetes intégrés consiste à accéder aux secrets dans Azure Key Vault à partir de Kubernetes. La méthode la plus simple consiste à attribuer un rôle RBAC au conteneur qui cherche à charger des secrets. L’application peut ensuite utiliser les API Azure Key Vault pour accéder aux secrets. Toutefois, cette approche nécessite des modifications du code et ne suit pas le modèle d’utilisation de variables d’environnement. Au lieu de cela, il est possible d’injecter des valeurs dans un conteneur. Cette approche est en fait plus sécurisée que l’utilisation directe des secrets Kubernetes, car ils sont accessibles par les utilisateurs sur le cluster.
Chiffrement en transit et au repos
La sécurité des données est importante, que ce soit sur disque ou en transit entre différents services. Le moyen le plus efficace d’empêcher les fuites de données consiste à les chiffrer dans un format qui ne peut pas être facilement lu par d’autres personnes. Azure prend en charge un large éventail d’options de chiffrement.
En transit
Il existe plusieurs façons de chiffrer le trafic sur le réseau dans Azure. L’accès aux services Azure s’effectue généralement via des connexions qui utilisent le protocole TLS. Par exemple, toutes les connexions aux API Azure nécessitent des connexions TLS. De même, les connexions aux points de terminaison dans le stockage Azure peuvent être limitées pour fonctionner uniquement sur des connexions chiffrées TLS.
TLS est un protocole complexe et le simple fait de savoir que la connexion utilise TLS n’est pas suffisant pour garantir la sécurité. Par exemple, TLS 1.0 est chroniquement non sécurisé et TLS 1.1 n’est pas beaucoup mieux. Même dans les versions de TLS, il existe différents paramètres qui peuvent faciliter le déchiffrement des connexions. Le meilleur plan d’action consiste à vérifier et à voir si la connexion au serveur utilise des protocoles à jour et bien configurés.
Cette vérification peut être effectuée par un service externe tel que le test de serveur SSL de labo SSL. Une série de tests sur un point de terminaison Azure classique, dans ce cas un point de terminaison Service Bus, donne un score presque parfait de A.
Même les services tels que les bases de données Azure SQL utilisent le chiffrement TLS pour garder les données masquées. La partie intéressante du chiffrement des données en transit à l’aide de TLS est qu’il n’est pas possible, même pour Microsoft, d’écouter la connexion entre des ordinateurs exécutant TLS. Cela devrait rassurer les entreprises qui craignent que leurs données soient menacées par Microsoft ou même par un acteur d’État disposant de plus de ressources que l’attaquant standard.
Figure 9-5. Rapport de labo SSL montrant un score de A pour un point de terminaison Service Bus.
Bien que ce niveau de chiffrement ne soit pas suffisant pour tout le temps, il devrait inspirer confiance sur la sécurité relative des connexions Azure TLS. Azure va continuer à faire évoluer ses normes de sécurité à mesure que le chiffrement s’améliore. Il est agréable de savoir qu’il y a quelqu’un qui surveille les normes de sécurité et met à jour Azure à mesure qu’elles s’améliorent.
Au repos
Dans n’importe quelle application, les données se trouvent sur le disque, à plusieurs endroits. Le code d’application lui-même est chargé à partir d’un mécanisme de stockage. La plupart des applications utilisent également une sorte de base de données telle que SQL Server, Cosmos DB ou même le stockage Table incroyablement économique. Ces bases de données utilisent toutes un stockage fortement chiffré pour s’assurer que personne d’autre que les applications disposant des autorisations appropriées ne peut lire vos données. Même les opérateurs système ne peuvent pas lire les données chiffrées. Ainsi, les clients peuvent rester sûrs que leurs informations secrètes restent secrètes.
Stockage
Azure est particulièrement basé sur le moteur de stockage Azure. Les disques de machine virtuelle sont montés sur le stockage Azure. Azure Kubernetes Service s’exécute sur des machines virtuelles qui, elles-mêmes, sont hébergées sur le stockage Azure. Même les technologies serverless, telles que les applications Azure Functions et Azure Container Instances, manquent d’espace disque, qui fait partie du Stockage Azure.
Si le stockage Azure est correctement chiffré, il fournit une base pour que la plupart des autres éléments soient également chiffrés. Le Stockage Azure est chiffré avec un AES 256 bits conforme à FIPS 140-2. Il s’agit d’une technologie de chiffrement bien considérée qui a fait l’objet d’un examen académique approfondi au cours des 20 dernières années. À l’heure actuelle, il n’existe aucune attaque pratique connue qui permettrait à une personne sans connaissance de la clé de lire des données chiffrées par AES.
Par défaut, les clés utilisées pour chiffrer le stockage Azure sont managées par Microsoft. Des protections étendues sont mises en place pour empêcher l’accès malveillant à ces clés. Toutefois, les utilisateurs ayant des exigences de chiffrement particulières peuvent également fournir leurs propres clés de stockage managées dans Azure Key Vault. Ces clés peuvent être révoquées à tout moment, ce qui rendrait le contenu du compte de stockage inaccessible en les utilisant.
Les machines virtuelles utilisent le stockage chiffré, mais il est possible de fournir une autre couche de chiffrement à l’aide de technologies telles que BitLocker sur Windows ou DM-Crypt sur Linux. Ces technologies signifient que même si l’image disque a été divulguée hors du stockage, il resterait presque impossible de la lire.
Azure SQL
Les bases de données hébergées sur Azure SQL utilisent une technologie appelée Transparent Data Encryption (TDE) pour garantir le chiffrement des données. Il est activé par défaut sur toutes les bases de données SQL nouvellement créées, mais doit être activé manuellement pour les bases de données héritées. TDE exécute le chiffrement et le déchiffrement en temps réel non seulement de la base de données, mais également des sauvegardes et des journaux des transactions.
Les paramètres de chiffrement sont stockés dans la base de données master et, au démarrage, sont lus en mémoire pour les opérations restantes. Cela signifie que la base de données master doit rester non chiffrée. La clé réelle est managée par Microsoft. Toutefois, les utilisateurs ayant des exigences de sécurité précises peuvent fournir leur propre clé dans Key Vault de la même manière que pour le stockage Azure. Key Vault fournit des services tels que la rotation et la révocation des clés.
La partie « Transparent » de TDS provient du fait qu’aucune modification du client n’est nécessaire pour utiliser une base de données chiffrée. Bien que cette approche offre une bonne sécurité, la fuite du mot de passe de la base de données est suffisante pour que les utilisateurs puissent déchiffrer les données. Il existe une autre approche qui chiffre des colonnes ou des tables individuelles dans une base de données. Always Encrypted garantit qu’à aucun moment les données chiffrées n’apparaissent en texte brut à l’intérieur de la base de données.
La configuration de ce niveau de chiffrement nécessite l’exécution d’un Assistant dans SQL Server Management Studio pour sélectionner le tri de chiffrement et l’emplacement dans Key Vault pour stocker les clés associées.
Figure 9-6. Sélection de colonnes dans une table à chiffrer à l’aide de Always Encrypted.
Les applications clientes qui lisent les informations de ces colonnes chiffrées doivent prendre des autorisations spéciales pour lire les données chiffrées. Les chaînes de connexion doivent être mises à jour avec Column Encryption Setting=Enabled et les informations d’identification du client doivent être récupérées à partir de Key Vault. Le client SQL Server doit ensuite être amorcé avec les clés de chiffrement de colonne. Une fois cette opération effectuée, les actions restantes utilisent les interfaces standard pour le client SQL. Autrement dit, des outils comme Dapper et Entity Framework, qui reposent sur le client SQL, continueront de fonctionner sans changement. Always Encrypted n’est peut-être pas encore disponible pour chaque pilote SQL Server sur chaque langage.
La combinaison de TDE et de Always Encrypted, qui peuvent être utilisées avec des clés spécifiques au client, garantit que même les exigences de chiffrement les plus exigeantes sont prises en charge.
Cosmos DB
Cosmos DB est la base de données la plus récente fournie par Microsoft dans Azure. Il a été généré à partir de zéro avec la sécurité et le chiffrement à l’esprit. Le chiffrement AES-256 bits est standard pour toutes les bases de données Cosmos DB et ne peut pas être désactivé. Associée à l’exigence TLS 1.2 pour la communication, l’intégralité de la solution de stockage est chiffrée.
Figure 9-7. Le flux de chiffrement des données dans Cosmos DB.
Bien que Cosmos DB ne fournisse pas de clés de chiffrement client, l’équipe a effectué un travail important pour s’assurer qu’elle reste conforme à la norme PCI-DSS sans cela. Cosmos DB ne prend pas non plus en charge un type de chiffrement à colonne unique similaire au Always Encrypted de Azure SQL.
Assurer la sécurité
Azure dispose de tous les outils nécessaires pour publier un produit hautement sécurisé. Toutefois, une chaîne est aussi forte que son maillon le plus faible. Si les applications déployées sur Azure ne sont pas développées avec un état d’esprit de sécurité approprié et de bons audits de sécurité, elles deviennent le maillon faible de la chaîne. Il existe de nombreux outils d’analyse statique, bibliothèques de chiffrement et pratiques de sécurité qui peuvent être utilisés pour garantir que les logiciels installés sur Azure sont aussi sécurisés qu’Azure lui-même. Par exemple, les outils d’analyse statique, les bibliothèques de chiffrement et les pratiques de sécurité.
