Développer des applications sécurisées sur Azure
Cet article présente les activités et contrôles de sécurité à prendre en compte lorsque vous développez des applications pour le cloud. Les questions et concepts de sécurité à prendre en compte pendant les phases d’implémentation et de vérification du Microsoft Security Development Lifecycle y sont abordées. L’objectif est de vous aider à définir les activités et services Azure que vous pouvez utiliser pour développer une application plus sécurisée.
Les phases de Microsoft Security Development Lifecycle suivantes sont traitées dans cet article :
- Implémentation
- Vérification
Implémentation
L’objectif de la phase d’implémentation est d’établir les meilleures pratiques en matière de prévention anticipée et de détecter et supprimer les problèmes de sécurité du code. Supposons que votre application soit utilisée d’une manière que vous ne souhaitiez pas. Cela permet de se prémunir contre une mauvaise utilisation accidentelle ou intentionnelle de votre application.
Effectuer des révisions de code
Avant d’archiver du code, révisez-le pour augmenter la qualité globale du code et réduire le risque de création de bogues. Vous pouvez utiliser Visual Studio pour gérer le processus de révision de code.
Effectuer une analyse du code statique
L’analyse du code statique (également appelée analyse du code source) est effectuée dans le cadre d’une révision du code. L’analyse du code statique consiste à exécuter des outils d’analyse du code statique pour rechercher les vulnérabilités potentielles dans le code qui n’est pas en cours d’exécution. L’analyse du code statique utilise des techniques telles que la vérification de teinte et l’analyse du flux de données.
Place de marché Azure propose des outils de développement qui permettent d’effectuer une analyse du code statique et de réviser le code.
Valider et nettoyer chaque entrée de votre application
Traitez toutes les entrées comme si elles n’étaient pas fiables pour protéger votre application des vulnérabilités d’applications web les plus courantes. Les données non fiables véhiculent les attaques par injection. Parmi les entrées de votre application figurent les paramètres d’URL, les saisies de l’utilisateur, les données issues de la base de données ou d’une API, et tout élément transmis qu’un utilisateur pourrait potentiellement manipuler. Une application doit confirmer la validité des données d’un point de vue syntaxique et sémantique avant que l’application ne les utilise de quelque manière que ce soit (y compris pour les réafficher pour l’utilisateur).
Validez les entrées au début du flux de données pour vous assurer que seules des données correctement formatées pénètre le flux de travail. Vous ne voulez pas que des données incorrectes demeurent dans votre base de données ou déclenchent une défaillance dans un composant en aval.
La mise en liste rouge et en mise en liste verte sont deux approches générales de la validation de la syntaxe d’entrée :
La mise en liste rouge tente de vérifier qu’une entrée utilisateur donnée ne contient pas de contenu « réputé malveillant ».
La mise en liste verte tente de vérifier qu’une entrée utilisateur donnée correspond à un ensemble d’entrées « réputées bonnes ». La mise en liste verte basée sur des caractères est une forme de mise en liste verte où une application vérifie que la saisie de l’utilisateur ne contient que des caractères « réputés bons » ou correspond à un format connu.
Par exemple, cela peut impliquer la vérification qu’un nom d’utilisateur contient uniquement des caractères alphanumériques ou qu’il contient exactement deux chiffres.
La mise en liste verte est la meilleure approche en matière de création de logiciels sécurisés. La mise en liste rouge est sujette à erreur, car il est impossible d’établir une liste exhaustive des entrées potentiellement incorrectes.
Faites ce travail sur le serveur, et non côté client (ou sur le serveur et côté client).
Vérifiez les sorties de votre application
Toute sortie présentée visuellement ou au sein d’un document doit toujours être encodée et placée dans une séquence d’échappement. L’échappement, également appelé encodage de sortie, permet de garantir que les données non fiables ne véhiculent pas d’attaque par injection de code. L’échappement, associé à la validation des données, offre des défenses multiniveau pour améliorer la sécurité du système dans son ensemble.
L’échappement garantit que tout s’affiche comme sortie. L’échappement informe également l’interpréteur que les données ne sont pas destinées à être exécutées, ceci empêchant la réussite des attaques. Il s’agit d’une autre technique d’attaque courants appelée script intersites (XSS).
Si vous utilisez une infrastructure web tierce, vous pouvez vérifier vos options pour l’encodage de sortie sur les sites Web à l’aide de l’aide-mémoire de prévention OWASP XSS.
Utiliser des requêtes paramétrables lorsque vous contactez la base de données
Ne créez jamais de requête de base de données en ligne « à la volée » dans votre code et envoyez-la directement à la base de données. Du code malveillant inséré dans votre application pourrait éventuellement provoquer le vol, la réinitialisation ou la modification de votre base de données. Votre application pourrait également être utilisée pour exécuter des commandes de système d’exploitation malveillantes sur le système d’exploitation hébergeant votre base de données.
Pour éviter cela, utilisez des requêtes paramétrables ou des procédures stockées. Lorsque vous utilisez des requêtes paramétrables, vous pouvez appeler la procédure à partir de votre code en toute sécurité et lui transmettre une chaîne sans vous préoccuper de savoir si elle sera traitée dans le cadre de l’instruction de la requête.
Supprimer des en-têtes de serveur standard
Les en-têtes tels que Server, X-Powered-By et X-AspNet-Version affichent des informations relatives au serveur et aux technologies sous-jacentes. Nous vous recommandons de supprimer ces en-têtes afin d’éviter la prise d’empreinte de l’application. Consultez Removing standard server headers on Windows Azure Web Sites (Supprimer les en-têtes de serveur standard des sites web Azure).
Séparer les données de production
Vos données de production, ou données « réelles », ne doivent pas servir au développement, au test ou à d’autres fins que celles liées à votre activité. Un jeu de données masqué (anonyme) doit être utilisé pour tout développement et test.
En d’autres termes, moins de personnes ont accès à vos données réelles, plus la surface d’attaque se trouve réduite. Cela signifie également qu’un nombre réduit d’employés a accès aux données personnelles, ce qui élimine une violation potentielle de la confidentialité.
Implémenter une stratégie de mot de passe forte
Pour se défendre contre les attaques en force brute et les vols basés sur le dictionnaire, vous devez implémenter une stratégie de mot de passe fort pour garantir que les utilisateurs créent des mots de passe complexes (par exemple, longueur minimale de 12 caractères, caractères spéciaux et alphanumériques).
Azure Active Directory B2C permet de gérer les mots de passe en proposant la réinitialisation du mot de passe en libre-service, la réinitialisation forcée de mot de passe, et bien plus encore.
Pour se défendre contre les attaques sur les comptes par défaut, vérifiez que toutes les clés et que tous les mots de passe sont remplaçables et qu’ils sont générés ou remplacés après l’installation des ressources.
Si l’application doit générer automatiquement des mots de passe, assurez-vous que les mots de passe générés sont aléatoires et ont une entropie élevée.
Valider des chargements de fichiers
Si votre application autorise les chargements de fichiers, envisagez les précautions que vous pouvez prendre pour cette activité à risque. La première étape de nombreuses attaques consiste à obtenir un code malveillant dans un système subissant une attaque. Un chargement de fichier permet aux personnes malveillantes d’accomplir cette étape. OWASP propose des solutions permettant de valider un fichier afin de garantir que le fichier chargé est sécurisé.
Une solution de protection contre les programmes malveillants permet d’identifier et de supprimer les virus, logiciels espions et autres logiciels malveillants. Vous pouvez installer Microsoft Antimalware ou une solution de protection des points de terminaison d’un partenaire de Microsoft (Trend Micro, Broadcom, McAfee, Microsoft Defender Antivirus dans Windows ou Endpoint Protection).
Le logiciel Microsoft Antimalware inclut des fonctionnalités telles que la protection en temps réel, l’analyse planifiée, la correction des logiciels malveillants, la mise à jour des signatures, la mise à jour des moteurs, des exemples de création de rapport et la collecte d’événements d’exclusion. Vous pouvez intégrer Microsoft Antimalware et des solutions de partenaires à Microsoft Defender pour le cloud pour bénéficier d’un déploiement simplifié et de fonctionnalités de détection intégrées (alertes et incidents).
Ne pas mettre en cache de contenu sensible
Ne mettez pas en cache de contenu sensible sur le navigateur. Les navigateurs peuvent stocker des informations à des fins de mise en cache et d’historique. Les fichiers mis en cache sont stockés dans un dossier, comme le dossier Fichiers Internet temporaires d’Internet Explorer. Lorsque ces pages sont de nouveau consultées, le navigateur les affiche à partir du cache. Si l’utilisateur peut voir des informations sensibles (par exemple, adresse, numéro de carte de crédit, numéro de sécurité sociale ou nom d’utilisateur), ces informations sont peut-être stockées dans le cache du navigateur et elles peuvent par conséquent être récupérées lors de l’examen du cache du navigateur ou en appuyant sur le bouton Précédent du navigateur.
Vérification
La phase de vérification implique un effort complet pour s’assurer que le code respecte les principes de sécurité et confidentialité établis au cours des phases précédentes.
Rechercher et corriger les vulnérabilités de vos dépendances d’application
Vous analysez votre application et ses bibliothèques dépendantes pour identifier tous les composants vulnérables connus. Les produits disponibles pour effectuer cette analyse sont les suivants : OWASP Dependency Check, Snyk, et Black Duck.
Tester votre application en fonctionnement
Le test de sécurité des applications dynamique (DAST) est un processus de test d’une application en fonctionnement permettant de rechercher les vulnérabilités de sécurité. Les outils DAST analysent les programmes en cours d’exécution à la recherche de vulnérabilités de sécurité, telles que l’altération de la mémoire, une configuration de serveur non sécurisée, les scripts intersites, les problèmes liés au privilège utilisateur, l’injection de code SQL et d’autres problèmes de sécurité critiques.
Les tests DAST sont différents des tests de sécurité d’application statiques (SAST). Les outils SAST analysent le code source ou les versions compilées de code lorsque le code n’est pas exécuté afin de détecter des failles de sécurité.
Effectuez les tests DAST de préférence avec l’aide d’un professionnel de la sécurité (un testeur d’intrusion ou un évaluateur des vulnérabilités). Si aucun professionnel de la sécurité n’est disponible, vous pouvez effectuer vous-même les tests DAST avec un scanneur de proxy web et une formation préalable. Connectez un scanneur DAST suffisamment tôt afin de vous assurer de ne pas introduire de problèmes de sécurité évidents dans votre code. Consultez le site OWASP pour obtenir la liste des scanneurs de vulnérabilité d’application web.
Effectuer un test à données aléatoires (fuzzing)
Au cours du test à données aléatoires (fuzzing), vous introduisez délibérément des données incorrectes ou aléatoires dans une application. Le fait d’induire l’échec du programme permet de révéler des problèmes potentiels de sécurité avant la publication de l’application.
La détection des risques de sécurité est le service de test à données aléatoires (fuzzing) unique Microsoft permettant de rechercher des bogues critiques de sécurité dans le logiciel.
Examiner la surface d’attaque
L’examen de la surface d’attaque après l’exécution de code permet de garantir que toute modification de conception ou d’implémentation apportée à une application ou un système a été prise en compte. Cela permet de s’assurer que les nouveaux vecteurs d’attaque créés à la suite de modifications, y compris les modèles de menace, on été examinés et atténués.
Vous pouvez créer une image de la surface d’attaque en analysant l’application. Microsoft propose un outil d’analyse de la surface d’attaque appelé Attack Surface Analyzer. Vous pouvez choisir parmi de nombreux outils d’analyse des vulnérabilités et de test dynamique commerciaux, notamment OWASP Attack Surface Detector, Arachni et w3af. Ces outils d’analyse parcourent votre application et mappent les parties de l’application accessibles via le web. Vous pouvez également effectuer des recherches dans Place de marché Azure pour trouver des outils de développement similaires.
Effectuer des tests d’intrusion sécurisés
La sécurité de votre application est aussi importante que le bon fonctionnement de ses fonctionnalités. Intégrez les tests d’intrusion aux 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.
Exécuter des tests de vérification de sécurité
Azure Tenant Security Solution (AzTS) de Secure DevOps Kit pour Azure (AzSK) contient des SVT pour plusieurs services de la plateforme Azure. Vous exécutez ces SVT régulièrement pour garantir que votre abonnement Azure et les différentes ressources qui composent votre application sont sécurisées. Vous pouvez également automatiser ces tests à l’aide de la fonctionnalité des extensions de déploiement/d’intégration continus (CI/CD) d’AzSK, qui rend les SVT disponibles sous forme d’extension Visual Studio.
Étapes suivantes
Dans les articles suivants, nous recommandons des contrôles et des activités de sécurité qui peuvent vous aider à concevoir et déployer des applications sécurisées.