Configurer les paramètres de pare-feu sur des ressources PaaS

Effectué

Développer des applications sécurisées sur Azure est un guide général des questions de sécurité et des contrôles que vous devez prendre en compte à chaque phase du cycle de vie du développement logiciel lors du développement d’applications pour le cloud.

Avantages du cloud en matière de sécurité

Il est important de comprendre la répartition des responsabilités entre vous et Microsoft. Localement, vous avez toute la responsabilité, mais, lorsque vous vous déplacez vers le cloud, certaines responsabilités sont transférées à Microsoft.

Le cloud offre certains avantages pour la sécurité. Dans un environnement local, les organisations ont probablement des obligations non respectées et des ressources limitées pour investir dans la sécurité, avec pour résultat un environnement où les pirates informatiques sont en mesure d’exploiter des vulnérabilités à tous les niveaux.

Les organisations peuvent améliorer la détection des menaces et leur temps de réponse à l’aide de fonctionnalités de sécurité basées sur le cloud d’un fournisseur et l’intelligence du cloud. En transférant les responsabilités au fournisseur de cloud, les organisations peuvent optimiser leur couverture de sécurité, ce qui leur permet de réaffecter des ressources de sécurité et leur budget à d'autres priorités de l’entreprise.

Avantages d'un modèle de service cloud PaaS en matière de sécurité

Passons en revue les avantages d’un déploiement PaaS Azure en termes de sécurité par rapport à un déploiement local.

Diagramme montrant un exemple d’avantages du modèle platform-as-a-service.

En commençant par le premier élément, l’infrastructure physique, Microsoft réduit les risques courants et les responsabilités. Comme le cloud Microsoft est monitoré en permanence par Microsoft, il est difficile à attaquer. Un attaquant n’a aucun intérêt à choisir le cloud Microsoft comme cible. À moins que le pirate informatique n'ait beaucoup d’argent et de ressources, il préfèrera passer à une autre cible.

Au milieu de la pile, il n’y a pas de différence entre un déploiement PaaS et un déploiement local. Les risques sont similaires dans les couches d'application et de gestion des accès et des comptes. Dans la section suivante de cet article, nous vous présentons les meilleures pratiques pour éliminer ou réduire ces risques.

En haut de l'infrastructure (gouvernance des données et gestion des droits), vous prenez un risque qui peut être limité par la gestion de clés (la gestion des clés est traitée dans les bonnes pratiques). Même si la gestion des clés est une responsabilité supplémentaire, vous n'avez plus à gérer certaines zones d'un déploiement PaaS, et vous pouvez donc transférer des ressources vers la gestion des clés.

La plateforme Azure offre également une protection DDoS renforcée à travers diverses technologies de réseau. Toutefois, tous les types de méthodes de protection contre le déni de service distribué (DDoS) basée sur le réseau ont leurs limites par lien et par centre de données. Pour éviter l’impact d’attaques DDoS de grande envergure, vous pouvez tirer parti des capacités cloud de base d’Azure afin de rapidement et automatiquement faire un scale-out qui vous protège contre les attaques DDoS. Nous aborderons la procédure plus en détail dans les articles sur les pratiques recommandées.

Moderniser l’état d’esprit de Defender pour le cloud

Avec les déploiements PaaS, votre approche globale de la sécurité évolue. Vous n'avez pas besoin de tout contrôler vous-même et partagez la responsabilité avec Microsoft.

Une autre différence importante entre les déploiements PaaS et les déploiements locaux traditionnels est une nouvelle définition du périmètre de sécurité principal. Historiquement, le périmètre de sécurité local principal était votre réseau et la plupart des conceptions de sécurité locales utilisent le réseau en tant que pivot de sécurité principal. Pour les déploiements PaaS, c’est l’identité qui sert de périmètre de sécurité principal.

Adopter une stratégie d‘identité en tant que périmètre de sécurité principal

L'une des cinq caractéristiques essentielles du cloud computing est un large accès au réseau, ce qui rend l'approche centrée sur le réseau moins pertinente. Le cloud computing a en grande partie pour but de permettre aux utilisateurs d’accéder à des ressources, quel que soit leur emplacement. Pour la plupart des utilisateurs, l'emplacement est quelque part sur Internet.

La figure suivante montre comment le périmètre de sécurité a évolué d’un périmètre de réseau vers un périmètre d’identité. La sécurité se résume moins à la protection de votre réseau et plus à la défense de vos données, ainsi qu'à la gestion de la sécurité de vos applications et de vos utilisateurs. La principale différence est que vous pouvez axer la sécurité sur ce qui est important pour votre entreprise.

Diagramme montrant l’évolution du périmètre de sécurité d’un périmètre de réseau vers un périmètre d’identité.

Initialement, les services PaaS Azure (par exemple, les rôles web et Azure SQL) fournissaient peu ou pas de défenses du périmètre de réseau traditionnelles. Il était entendu que l’élément devait être exposé sur Internet (rôle web) et que l’authentification fournit le nouveau périmètre (par exemple, BLOB ou Azure SQL).

Les pratiques de sécurité modernes partent du principe que l’adversaire a violé le périmètre du réseau. Par conséquent, les pratiques de défense modernes sont axées sur l'identité. Les organisations doivent établir un périmètre de sécurité basé sur les identités avec forte hygiène d’authentification et d’autorisation (bonnes pratiques).

Les principes et modèles pour le périmètre du réseau existaient depuis des décennies. En revanche, l’approche basée sur l'identité comme périmètre de sécurité principal n'est pas répandue dans l'industrie. Cela étant dit, nous avons accumulé suffisamment d’expérience pour fournir des recommandations générales qui s'appliquent dans la pratique à presque tous les services PaaS.

Voici les bonnes pratiques en matière de gestion du périmètre d’identité.

Bonne pratique : sécurisez vos clés et informations d’identification pour sécuriser votre déploiement PaaS. Détail : La perte de clés ou d'informations d’identification est un problème courant. Vous pouvez utiliser une solution centralisée où les clés et les secrets peuvent être stockés dans des modules de sécurité matériels (HSM). Azure Key Vault sauvegarde vos clés et vos secrets en chiffrant les clés d’authentification, les clés de compte de stockage, les clés de chiffrement de données, les fichiers .pfx et les mots de passe à l’aide de clés protégées par des HSM.

Bonne pratique : ne placez pas vos informations d’identification et autres secrets dans le code source ni GitHub. Détail : la seule chose qui est pire que la perte de vos clés et informations d’identification serait qu’un tiers non autorisé y accède. Des pirates peuvent tirer parti de technologies de robot pour rechercher les clés et les secrets stockés dans des référentiels de code, tels que GitHub. Ne placez pas de clé ni de secrets dans ces référentiels de code publics.

Bonne pratique : protégez vos interfaces de gestion de machine virtuelle sur les services hybrides PaaS et IaaS à l’aide d’une interface de gestion qui vous permet de gérer directement à distance ces machines virtuelles. Détail : des protocoles de gestion à distance tels que SSH, RDP et communication à distance PowerShell peuvent être utilisés. En règle générale, nous vous recommandons de ne pas activer l’accès à distance direct aux machines virtuelles à partir d’Internet.

Si possible, utilisez d’autres approches, comme les réseaux privés virtuels dans un réseau virtuel Azure. Si aucune autre approche n‘est disponible, assurez-vous d’utiliser des phrases secrètes complexes et l’authentification à deux facteurs (comme l’authentification multifacteur Microsoft Entra).

Bonne pratique : utilisez une authentification forte et des plateformes d’autorisation. Détail : utilisez des identités fédérées dans Microsoft Entra ID au lieu des magasins d’utilisateurs personnalisés. Lorsque vous utilisez des identités fédérées, vous tirez parti d'une approche basée sur une plateforme et vous déléguez la gestion des identités autorisées à vos partenaires. Une approche d’identité fédérée est particulièrement importante quand le contrat de certains employés prend fin et que des informations doivent être répercutées sur plusieurs systèmes d’identité et d’autorisation.

Utilisez les mécanismes d‘authentification et d‘autorisation fournis par les plateformes au lieu d‘un code personnalisé. La raison est que le développement d'un code d’authentification personnalisé peut être sujet aux erreurs. La plupart de vos développeurs ne sont pas des experts en sécurité et ont peu de chance d’être conscients des subtilités et des derniers développements dans les domaines de l’authentification et de l’autorisation. Le code commercial (par exemple, de Microsoft) est souvent très contrôlé en ce qui concerne la sécurité.

Utilisez une authentification à deux facteurs. L’authentification à deux facteurs est la norme actuelle pour l’authentification et l’autorisation, car elle évite les failles de sécurité inhérentes aux types d’authentification par nom d’utilisateur et mot de passe. L'accès aux interfaces de gestion Azure (portail / PowerShell à distance) et aux services orientés client doit être conçu et configuré pour utiliser l’authentification multifacteur Microsoft Entra.

Utilisez des protocoles d’authentification standard, tels qu'OAuth2 et Kerberos. Ces protocoles ont été largement contrôlés et sont probablement implémentés dans le cadre de vos bibliothèques de plateforme pour l’authentification et l’autorisation.

Utiliser la modélisation des menaces lors de la conception d’une application

Microsoft Security Development Lifecycle spécifie que les équipes doivent s’engager dans un processus appelé modélisation des menaces pendant la phase de conception. Pour faciliter ce processus, Microsoft a créé l’outil SDL de modélisation des menaces. La modélisation de la conception de l’application et l’énumération des menaces STRIDE (usurpation d’identité, falsification, répudiation, divulgation d’informations, déni de service DoS et élévation de privilèges) sur toutes les limites d’approbation peuvent comprendre dès le début les erreurs de conception.

Le tableau suivant répertorie les menaces STRIDE et donne des exemples d’atténuation des risques que les fonctionnalités Azure utilisent. Ces atténuations ne fonctionnent pas dans tous les cas.

Menace Propriété de sécurité Atténuations potentielles pour la plateforme Azure
Usurpation d’identité Authentification Exigez des connexions HTTPS.
Falsification Intégrité Validez des certificats TLS/SSL.
Répudiation Non-répudiation Activez la surveillance et les diagnostics Azure.
Divulgation d’informations Confidentialité Chiffrez les données sensibles au repos à l’aide de certificats de service.
Denial of service (déni de service) Disponibilité Surveillez les mesures de performances pour des conditions potentielles de déni de service. Implémentez des filtres de connexion.
Élévation de privilège Autorisation Utilisez Privileged Identity Management.

Développer sur Azure App Service

Azure App Service est une offre PaaS qui vous permet de créer des applications mobiles et web pour tout type d’appareil ou de plateforme, et de vous connecter à des données en tout lieu, dans le cloud ou localement. App Service inclut les fonctionnalités web et mobiles qui étaient précédemment fournies séparément dans Sites Web Azure et Azure Mobile Services. Il inclut également de nouvelles fonctionnalités d’automatisation des processus d’entreprise et d’hébergement d’API cloud. App Service est un service intégré unique qui apporte un ensemble complet de fonctionnalités pour les scénarios web, mobiles et d’intégration.

Voici les bonnes pratiques relatives à l’utilisation d’App Service.

Meilleure pratique : S’authentifier via Microsoft Entra ID. Détail : App Service fournit un service OAuth 2.0 pour votre fournisseur d’identité. OAuth 2.0 privilégie la simplicité du développement client tout en fournissant des flux d’autorisation spécifiques pour les applications web, les applications de bureau et les téléphones mobiles. Microsoft Entra ID utilise OAuth 2.0 pour vous permettre d’autoriser l’accès aux applications mobiles et web.

Bonne pratique : Restreindre l’accès en fonction des principes du besoin de connaître et du privilège minimum. Détail : La restriction de l’accès est indispensable pour les organisations qui veulent appliquer des stratégies de sécurité portant sur l’accès aux données. Vous pouvez utiliser la fonction de contrôle d’accès en fonction du rôle Azure (RBAC Azure) pour affecter des autorisations à des utilisateurs, groupes et applications dans une certaine étendue. Pour en savoir plus sur l’octroi aux utilisateurs du droit d’accès aux applications, consultez Prise en main de la gestion des accès.

Bonne pratique : Protégez vos clés. Détail : Azure Key Vault permet de protéger les clés de chiffrement et les secrets utilisés par les services et les applications cloud. Avec Key Vault, vous pouvez chiffrer les clés et les secrets (tels que les clés d’authentification, les clés de compte de stockage, les clés de chiffrement de données, les fichiers .PFX et les mots de passe) à l’aide de clés protégées par des modules de sécurité matériels (HSM). Pour une meilleure garantie, vous pouvez importer ou générer des clés HSM. Pour en savoir plus, consultez Azure Key Vault. Vous pouvez également utiliser Key Vault pour gérer vos certificats TLS avec renouvellement automatique.

Bonne pratique : Limitez les adresses IP source entrantes. Détails : App Service Environment propose une fonctionnalité d’intégration de réseau virtuel qui vous permet de limiter les adresses IP sources entrantes par le biais de groupes de sécurité réseau. Les réseaux virtuels vous permettent de placer des ressources Azure dans un réseau routable non-Internet auquel vous contrôlez l’accès. Pour en savoir plus, consultez Intégrer une application à un réseau virtuel Azure.

Bonne pratique : supervisez l’état de sécurité de vos environnements App Service. Détails : Utilisez Microsoft Defender pour le cloud pour surveiller vos environnements App Service. Lorsque Defender pour le cloud identifie des failles de sécurité potentielles, il crée des recommandations qui vous guident tout au long du processus de configuration des contrôles nécessaires.

Services cloud Azure

Azure Cloud Services est un exemple de PaaS. Tout comme Azure App Service, cette technologie est conçue pour prendre en charge des applications évolutives, fiables et dont l’exploitation est peu coûteuse. Comme App Service, Azure Cloud Services est hébergé sur des machines virtuelles. Toutefois, vous avez davantage de contrôle sur les machines virtuelles. Vous pouvez installer votre propre logiciel sur des machines virtuelles utilisant Azure Cloud Services, et y accéder à distance.

Installer un pare-feu d’application web

Les applications Web sont de plus en plus la cible d’attaques malveillantes qui exploitent des vulnérabilités connues. Les types d’attaques les plus courantes sont l’injection de code SQL, les attaques de script site à site, entre autres. Empêcher ces attaques dans le code d’application peut se révéler difficile et nécessiter une maintenance rigoureuse, des mises à jour correctives ainsi que la surveillance au niveau d’un grand nombre de couches de la topologie de l’application. Un pare-feu d’applications web centralisé facilite grandement la gestion de la sécurité et offre une meilleure garantie de protection aux administrateurs de l’application contre les menaces ou les intrusions. Une solution WAF peut également réagir plus rapidement à une menace de sécurité en exécutant la mise à jour corrective d’une vulnérabilité connue dans un emplacement central plutôt que de sécuriser individuellement chacune des applications web.

Le pare-feu d’applications web (WAF) permet de centraliser la protection de vos applications web contre les vulnérabilités et les attaques courantes.

Protection contre le déni de service distribué (DDoS)

Azure DDoS Protection, combiné aux bonnes pratiques de conception d’application, offre des fonctionnalités d’atténuation des attaques DDoS améliorées pour une meilleure défense contre les attaques DDoS. Vous devez activer Azure DDOS Protection sur tout réseau virtuel de périmètre.

Surveiller les performances de vos applications

La surveillance consiste à collecter et analyser des données afin de déterminer les performances, l’intégrité et la disponibilité de votre application. Une stratégie de surveillance efficace permet d’identifier le fonctionnement détaillé des composants de votre application. Elle vous permet d’augmenter votre temps d’activité en vous avertissant des problèmes critiques afin que vous puissiez les résoudre avant qu’ils ne deviennent effectifs. Elle vous aide également à détecter les anomalies susceptibles d’être liées à la sécurité.

Utilisez Azure Application Insights pour surveiller la disponibilité, les performances et l’utilisation de votre application, qu’elle soit hébergée dans le cloud ou localement. En utilisant Application Insights, vous pouvez rapidement identifier et diagnostiquer les erreurs dans votre application sans attendre qu’un utilisateur ne les signale. Grâce aux informations recueillies, vous pouvez prendre des décisions avisées quant à la maintenance et à l’amélioration de votre application.

Application Insights dispose d’outils complets pour interagir avec les données qu’il collecte. Application Insights stocke ses données dans un référentiel commun. Il peut tirer parti des fonctionnalités partagées telles que les alertes, les tableaux de bord et une analyse approfondie grâce au langage de requête du service Kusto.

Effectuer des tests d’intrusion sécurisés

Le fait de valider les défenses de sécurité est aussi important que de tester toute autre fonctionnalité. Intégrez les tests d’intrusion à vos processus de génération et de déploiement. Planifiez régulièrement des tests de sécurité et des analyses de vulnérabilité sur les applications déployées, et surveillez les ports ouverts, les points de terminaison et les attaques.

Les tests à données aléatoires (fuzzing) sont une méthode de recherche des défaillances de programmes (erreurs de code) permettant de fournir les données d’entrée incorrectes aux interfaces de programme (points d’entrée) qui analysent et utilisent ces données.