Sécurité Azure pour les applications natives cloud

Les applications natives cloud peuvent être plus faciles et plus difficiles à sécuriser que les applications traditionnelles. À l’inconvénient, vous devez sécuriser des applications plus petites et consacrer plus d’énergie à la construction de l’infrastructure de sécurité. La nature hétérogène des langages de programmation et des styles 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.

De l’autre côté, les services plus petits, chacun avec leur 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 contient uniquement 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, la même mentalité de sécurité holistique doit être suivie. La sécurité et la pensée sécurisée doivent faire partie de chaque étape du processus de développement et des opérations. Lors de la planification d’une application, posez des questions telles que :

• Quel serait l’impact de ces données perdues ?
• Comment limiter les dommages causés par les données incorrectes injectées 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 cherche à répondre à la question de savoir quelles sont les menaces pour le système, quelle est la probabilité des menaces, et les dommages potentiels qu'elles peuvent causer.

Une fois la liste des menaces établies, vous devez décider si elles valent la peine d’atténuer. Parfois, une menace est si peu probable et coûteuse à planifier pour qu’il ne vaut pas la peine de dépenser de l’énergie dessus. Par exemple, un acteur de niveau état peut injecter des modifications dans la conception d’un processus utilisé par des millions d’appareils. Maintenant, au lieu d’exécuter un certain morceau de code dans l’anneau 3, ce code est exécuté dans ring 0. Ce processus permet une attaque qui peut contourner l’hyperviseur et exécuter le code d’attaque sur les machines nues, ce qui permet d’attaquer toutes les machines virtuelles qui s’exécutent 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. Il est donc probable qu’aucun modèle de menace ne recommande de créer une protection contre les attaques.

Les menaces plus probables, telles que des contrôles d'accès défaillants permettant des attaques par incrémentation (remplaçant Id par Id=2 dans l'URL) ou des attaques par injection SQL, sont plus séduisantes pour lesquelles construire des protections. Les atténuations de ces menaces sont tout à fait raisonnables pour construire et empêcher les trous de sécurité embarrassants qui frappent la réputation de l’entreprise.

Principe du privilège minimum

L’une des idées fondatrices de la sécurité informatique est le principe du moindre privilège (POLP). C’est en fait une idée fondamentale dans la plupart des formes de sécurité qu’il soit numérique ou physique. En bref, le principe est que tout utilisateur ou processus doit avoir le plus petit nombre de droits possibles pour exécuter sa tâche.

Par exemple, pensez aux guichetiers d'une banque : accéder au coffre-fort est une activité rare. Donc, le caissier moyen ne peut pas ouvrir le coffre-fort seul. Pour obtenir l’accès, ils doivent remonter leur demande par le biais d’un responsable bancaire, qui effectue des vérifications de sécurité supplémentaires.

Dans un système informatique, un exemple fantastique est le droit d’un utilisateur se connectant à une base de données. Dans de nombreux cas, il existe un seul compte d’utilisateur 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 pouvoir mettre à jour les informations de schéma. Il doit y avoir plusieurs comptes qui fournissent différents niveaux de privilège. L’application doit utiliser uniquement le niveau d’autorisation qui accorde l’accès en lecture et écriture aux données des tables. Ce type de protection élimine les attaques visant à supprimer des tables de base de données ou à introduire des déclencheurs malveillants.

Presque toutes les parties de la création d’une application native cloud peuvent tirer parti de la mémorisation du principe des privilèges minimum. Vous pouvez l'observer lors de la configuration de pare-feux, de groupes de sécurité réseau, de rôles et d’étendues dans le cadre du contrôle d’accès en fonction du rôle (RBAC).

Test d’intrusion

À mesure que les applications deviennent plus complexes, le nombre de vecteurs d’attaque augmente à un rythme alarmant. La modélisation des menaces est défectueuse en ce qu’elle tend à être exécutée par les mêmes personnes qui construisent le système. De la même façon que de nombreux développeurs ont des difficultés à envisager des interactions utilisateur, puis à créer des interfaces utilisateur inutilisables, la plupart des développeurs ont des difficultés à voir chaque vecteur d’attaque. Il est également possible que les développeurs qui créent le système ne soient pas bien familiarisé avec les méthodologies d’attaque et manquent quelque chose de crucial.

Les tests d'intrusion ou les « tests de pénétration » impliquent d’amener des acteurs externes à tenter d’attaquer le système. Ces attaquants peuvent être une société de conseil externe ou d’autres développeurs ayant une bonne connaissance de la sécurité d’une autre partie de l’entreprise. On leur donne la carte blanche pour tenter de subvertir le système. Souvent, ils trouveront des trous de sécurité étendus qui doivent être corrigés. Parfois, le vecteur d’attaque sera 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 à l’intérieur de Microsoft. Au fil des ans, ils ont été les premiers à trouver des dizaines de vecteurs d’attaque potentiellement catastrophiques, les fermant avant qu’ils puissent être exploités en externe. Plus une cible est tentante, plus les acteurs externes tenteront de l’exploiter, et il y a peu de cibles dans le monde plus tentants qu’Azure.

Supervision

Si un attaquant tente de pénétrer une application, il doit y avoir un avertissement. Souvent, les attaques peuvent être détectées en examinant les journaux d’activité des services. Les attaques laissent des signes d’identification qui peuvent être repérés avant qu’elles réussissent. Par exemple, un attaquant qui tente de deviner un mot de passe effectue de nombreuses demandes à un système de connexion. La surveillance autour du système de connexion peut détecter des modèles bizarres qui sont hors ligne avec le modèle d’accès classique. Cette surveillance peut être transformée en alerte qui peut, à son tour, alerter une personne d’opération pour activer une sorte de contre-mesure. Un système de surveillance 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 est dans le processus de construction. Non seulement la build doit-elle exécuter des vérifications de sécurité, telles que l’analyse du code non sécurisé ou des informations d’identification vérifiées, mais la build elle-même doit être 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. Ils pourraient introduire une étape de compilation qui modifie le code extrait pour rediriger toute demande de connexion vers 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 ne détecte pas cette vulnérabilité, car elle se déroule avant la compilation. De même, personne ne le découvrira lors d'une révision de code, car les étapes de construction résident sur le serveur de construction. Le code exploité va aller à la production où il peut récolter des mots de passe. Il est probable qu'il n'y ait pas de journal de l'audit des modifications du processus de construction, ou du moins que personne ne surveille l'audit.

Ce scénario est un exemple parfait d'une cible qui semble avoir peu de valeur mais qui peut être utilisée pour infiltrer le système. Une fois qu’un attaquant enfreint le périmètre du système, il peut commencer à trouver des moyens d’élever ses autorisations au point qu’il peut causer des dommages réels n’importe où.

Création d’un code sécurisé

.NET Framework est déjà un framework assez sécurisé. Il évite certains des pièges du code non géré, tels que le débordement des tableaux. Le travail est effectué activement pour corriger les trous de sécurité au fur et à mesure qu’ils sont découverts. Il y a même un programme de primes de bogues qui rémunère les chercheurs pour qu'ils trouvent des problèmes dans le système et les signalent au lieu de les exploiter.

Il existe de nombreuses façons de rendre le code .NET plus sécurisé. Les instructions suivantes, telles que les instructions de codage sécurisé pour l’article .NET , constituent une mesure raisonnable à prendre pour s’assurer que le code est sécurisé à partir de la base. Le top 10 d’OWASP est un autre guide précieux pour créer du code sécurisé.

Le processus de génération est un bon endroit pour placer les outils de scan pour détecter les problèmes dans le code source avant qu'ils n'entrent en production. La plupart des projets ont des dépendances sur d’autres packages. Un outil capable d’analyser les packages obsolètes détecte les problèmes dans une build de nuit. Même lors de la création d’images Docker, il est utile de vérifier et de vérifier que l’image de base n’a pas de vulnérabilités connues. Une autre chose à vérifier est que personne n’a accidentellement vérifié 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. Différents utilisateurs vont avoir des exigences de sécurité différentes, de sorte qu’ils doivent affiner leur approche de la sécurité cloud. Microsoft publie une grande quantité d’informations de sécurité dans le Centre de gestion de la confidentialité. Cette ressource doit être le premier arrêt pour les professionnels intéressés à comprendre comment fonctionnent les technologies d’atténuation des attaques intégrées.

Dans le portail Azure, Azure Advisor est un système qui analyse constamment un environnement et fait des recommandations. Certaines de ces recommandations sont conçues pour économiser des utilisateurs, mais d’autres sont conçues pour identifier des configurations potentiellement non sécurisées, telles que l’ouverture d’un conteneur de stockage au monde et non protégée par un réseau virtuel.

Infrastructure réseau Azure

Dans un environnement de déploiement local, une grande quantité d’énergie est dédiée à la configuration de la mise en réseau. La configuration de routeurs, de commutateurs et de ce type est complexe. 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 depuis l'environnement de développement par précaution qu'un morceau de code encore en développement fonctionne mal et supprime une grande quantité de données.

La plupart des ressources Azure PaaS ne disposent que de la configuration réseau la plus simple et permissive. Par exemple, toute personne sur Internet peut accéder à un service d’application. Les nouvelles instances SQL Server sont généralement limitées, afin que les parties externes ne puissent pas accéder à ces instances, mais les plages d'adresses IP qu'Azure utilise lui-même sont autorisées. Par conséquent, 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 ils peuvent lancer des attaques contre toutes les instances SQL sur Azure.

Heureusement, la plupart des ressources Azure peuvent être placées dans 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 îles d’adresses IP privées situées dans le réseau Azure.

Figure 9-1. Un réseau virtuel dans Azure.

De la même façon que les réseaux locaux disposent d’un pare-feu qui régit 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 s’agit uniquement de connexions entrantes qui nécessitent une forme d’exception de pare-feu explicite.

Avec le réseau établi, les ressources internes telles que les comptes de stockage peuvent être configurées pour autoriser uniquement l’accès par les 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 peuvent pas se connecter à celui-ci pour exploiter les clés divulguées. Ce scénario est un autre exemple du principe du privilège 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 Interface de mise en réseau de conteneurs Azure. 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 le principe du moindre privilège, chaque ressource au sein d'un réseau virtuel n'a pas besoin de communiquer avec toutes les autres. 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 communiquer entre elles. 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 ennuyeuse à implémenter, en particulier en provenance d’un arrière-plan d’utilisation d’Azure sans restrictions de trafic. Sur d’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 qu’elles ne sont pas activées par des règles dans un groupe de sécurité réseau. Bien que plus lent à développer cela, 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 d’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. Le plus simple consiste à utiliser un VPN de site à site qui peut être établi entre de nombreux routeurs et Azure. Le trafic est chiffré et tunnelisé 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é Express Route qui utilise un circuit privé entre un réseau local et Azure. Il est plus coûteux et difficile d’é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é plutôt que d’utiliser des clés ou des mots de passe.

Principaux de sécurité

Le premier composant dans 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 d'entités 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 prend les rôles de ce groupe en plus de ses propres rôles.
• Principal de service : identité de sécurité sous laquelle les services ou applications s’exécutent.
• Identité managée : identité Azure Active Directory géré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 que les services sont activés avec un principal de service, leurs autorisations peuvent être gérées de manière granulaire à l’aide de rôles et d’étendues.

Rôles

Un principal de sécurité peut prendre de nombreux rôles ou, à l’aide d’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 qu’un principal de sécurité possède. Azure a 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ôle RBAC.

Intégrés à Azure sont également 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 ne peut afficher que 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 la portée à 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 les messages depuis le point de terminaison Service Bus Azure blah.servicebus.windows.net/queue1 »

L’étendue peut être aussi étroite qu’une seule ressource, ou elle peut être appliquée à un groupe de ressources, un abonnement ou même un groupe d’administration.

Lorsque vous testez si un principal de sécurité dispose d’une certaine autorisation, la combinaison de rôle et d’étendue est prise en compte. Cette combinaison fournit un mécanisme d’autorisation puissant.

Refuser

Auparavant, seules les règles « autoriser » étaient autorisées pour RBAC. Ce comportement compliquait la construction de certaines étendues. Par exemple, permettre à un principal de sécurité l'accès à tous les comptes de stockage sauf un nécessitait d'accorder une permission explicite à une liste potentiellement infinie de comptes de stockage. Chaque fois qu’un nouveau compte de stockage a été créé, il doit être ajouté à cette liste de comptes. Cette surcharge de gestion ajoutée n’était certainement pas souhaitable.

Les règles de refus sont prioritaires sur les règles d’autorisation. Maintenant, la même étendue « autoriser tout mais un » peut être représentée sous la forme de deux règles « autoriser tout » et « refuser celle-ci spécifique ». Les règles de refus non seulement facilitent la gestion, mais permettent aussi de sécuriser davantage les ressources en refusant l'accès à tout le monde.

Vérification de l’accès

Comme vous pouvez l’imaginer, avoir un grand nombre de rôles et d’étendues peut rendre assez difficile de déterminer l’autorisation effective d’un principal de service. L’empilement des règles de refus en plus de cela ne sert qu’à augmenter 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 dans le 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 par 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, 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 des mots de passe pour des éléments tels que des bases de données, des clés API et des certificats. Une fois qu’un secret est entré dans le coffre, il n’est plus jamais affiché et les commandes à extraire et à afficher sont délibérément compliquées. Les informations contenues dans le coffre-fort sont protégées à l’aide du chiffrement logiciel ou des modules de sécurité matériel validés FIPS 140-2 de niveau 2.

L’accès au coffre de clés est assuré via RBACs, ce qui signifie que ce ne sont pas tous les utilisateurs qui peuvent accéder aux informations du 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 accéder, les applications doivent s’exécuter à l’aide d’un principal de service. Sous ce rôle supposé, 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 qu’une application doit au coffre, afin qu’elle ne puisse pas mettre à jour les secrets, mais uniquement les lire.

L’accès au coffre de clés peut être surveillé pour s’assurer que seules les applications attendues accèdent au coffre. Les journaux peuvent être intégrés à 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 conserver de petites informations secrètes. Les secrets Kubernetes peuvent être définis via l’exécutable classique kubectl .

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, ajoutez ceci à un fichier de secrets nommé secret.yml, 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 aux processus de conteneur par le biais de variables d’environnement. L’approche de l’application à douze facteurs pour créer des applications suggère l’utilisation du dénominateur commun le plus bas pour transmettre des paramètres à une application. Les variables d’environnement sont le dénominateur commun le plus bas, car elles sont prises en charge, quel que soit le système d’exploitation ou l’application.

Une alternative à l’utilisation des 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 d’utiliser directement les secrets Kubernetes, car elles sont accessibles par les utilisateurs sur le cluster.

Chiffrement en transit et au repos

Le maintien de la sécurité des données est important, qu’il s’agisse d’un disque ou d’un transit entre différents services. La méthode la plus efficace pour empêcher la fuite des données consiste à le chiffrer dans un format qui ne peut pas être facilement lu par d’autres utilisateurs. 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 est généralement effectué sur les connexions qui utilisent TLS (Transport Layer Security). 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 les connexions chiffrées TLS.

TLS est un protocole compliqué et il suffit de savoir que la connexion utilise TLS n’est pas suffisante 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 cours d’action consiste à vérifier si la connexion au serveur utilise up-to-date et des protocoles bien configurés.

Cette vérification peut être effectuée par un service externe, tel que le test de serveur SSL des laboratoires SSL. Une exécution de test sur un point de terminaison Azure classique, dans ce cas un point de terminaison Service Bus, génère un score quasi parfait d’A.

Même les services comme les bases de données Azure SQL utilisent le chiffrement TLS pour conserver 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 sur la connexion entre les ordinateurs exécutant TLS. Cela devrait rassurer les entreprises concernées par le risque que leurs données puissent être compromises par Microsoft lui-même ou même par un acteur étatique disposant de plus de ressources que l'attaquant habituel.

Figure 9-5. Rapport des laboratoires SSL montrant un score A pour un point de terminaison Service Bus.

Bien que ce niveau de chiffrement ne soit pas suffisant pour tout le temps, il doit inspirer confiance que les connexions TLS Azure sont assez sécurisées. Azure continuera à faire évoluer ses normes de sécurité au fur et à 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 au fur et à mesure qu’ils s’améliorent.

Au repos

Dans n’importe quelle application, il existe plusieurs endroits où les données reposent sur le disque. Le code d’application lui-même est chargé à partir d’un mécanisme de stockage. La plupart des applications utilisent également un type de base de données tel que SQL Server, Cosmos DB, ou même le stockage table incroyablement économique. Ces bases de données utilisent tous un stockage fortement chiffré pour s’assurer que personne d’autre que les applications disposant d’autorisations appropriées peuvent 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 confiants que leurs informations secrètes restent secrètes.

Stockage

La fondation de la majeure partie d’Azure est 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 stockage Azure. Même les technologies serverless, telles qu’Azure Functions Apps et Azure Container Instances, s’exécutent sur disque qui fait partie du stockage Azure.

Si le stockage Azure est bien chiffré, il fournit une base pour la plupart des autres pour être également chiffré. Le stockage Azure est chiffré avec AES 256 bits conforme à FIPS 140-2. Il s’agit d’une technologie de chiffrement bien considérée ayant 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 à quelqu’un sans connaissance de la clé de lire les données chiffrées par AES.

Par défaut, les clés utilisées pour chiffrer le stockage Azure sont gérées par Microsoft. Des protections étendues sont 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 gérées dans Azure Key Vault. Ces clés peuvent être révoquées à tout moment, rendant ainsi le contenu du compte de stockage qui les utilise effectivement inaccessible.

Les machines virtuelles utilisent un 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 le 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 que les données restent chiffrées. Elle est activée par défaut sur toutes les bases de données SQL nouvellement créées, mais doit être activée manuellement pour les bases de données héritées. TDE exécute le chiffrement et le déchiffrement en temps réel de non seulement la base de données, mais également les sauvegardes et les journaux des transactions.

Les paramètres de chiffrement sont stockés dans la master base de données et, au démarrage, sont lus en mémoire pour les opérations restantes. Cela signifie que la master base de données doit rester non chiffrée. La clé réelle est gérée par Microsoft. Toutefois, les utilisateurs qui ont des exigences de sécurité exactes peuvent fournir leur propre clé dans Key Vault de la même façon que pour le stockage Azure. Key Vault fournit des services tels que la rotation et la révocation de clés.

La partie « Transparente » de TDS provient du fait qu’il n’y a pas de modifications client nécessaires 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 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 type de chiffrement et déterminer l'emplacement dans Key Vault où stocker les clés associées.

Figure 9-6. Sélection de colonnes dans une table à chiffrer à l’aide d’Always Encrypted.

Les applications clientes qui lisent des informations de ces colonnes chiffrées doivent prendre des dispositions 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 du coffre de clés. Le client SQL Server doit ensuite être préparé avec les clés de chiffrement de colonnes. Une fois cela terminé, les actions restantes utilisent les interfaces standard pour SQL Client. Autrement dit, les outils tels que Dapper et Entity Framework, basés sur SQL Client, continueront de fonctionner sans modification. Always Encrypted n’est peut-être pas encore disponible pour chaque pilote SQL Server sur chaque langue.

La combinaison de TDE et 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 exactes sont prises en charge.

Cosmos DB (base de données)

Cosmos DB est la base de données la plus récente fournie par Microsoft dans Azure. Il a été construit depuis zéro avec la sécurité et la cryptographie à l’esprit. Le chiffrement AES-256bit est standard pour toutes les bases de données Cosmos DB et ne peut pas être désactivé. Couplé à l’exigence TLS 1.2 pour la communication, la solution de stockage entière est chiffrée.

Figure 9-7. Flux de chiffrement des données dans Cosmos DB.

Bien que Cosmos DB ne fournit pas de clés de chiffrement client, l’équipe a effectué des travaux importants pour s’assurer qu’il reste PCI-DSS conforme sans cela. Cosmos DB ne prend pas non plus en charge un type de chiffrement à colonne unique similaire à Celui d’Azure SQL Always Encrypted.

Maintenir la sécurité

Azure dispose de tous les outils nécessaires pour libérer un produit hautement sécurisé. Toutefois, une chaîne est aussi forte que son lien 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 lien faible dans la chaîne. Il existe de nombreux excellents outils d’analyse statique, bibliothèques de chiffrement et pratiques de sécurité qui peuvent être utilisés pour s’assurer que le logiciel installé sur Azure est aussi sécurisé qu’Azure lui-même. Les exemples incluent des outils d’analyse statique et des bibliothèques de chiffrement.