Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Dans cet article, nous présentons des activités et des 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 cycle de vie du développement de la sécurité Microsoft (SDL) sont abordés. L’objectif est de vous aider à définir des activités et des 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 :
- Implementation
- Verification
Implementation
L’objectif de la phase d’implémentation est d’établir les meilleures pratiques en matière de prévention précoce et de détecter et de supprimer les problèmes de sécurité du code. Supposons que votre application est utilisée de manière à ce que vous n’ayez pas l’intention de l’utiliser. Cela vous permet de vous protéger contre l’utilisation accidentelle ou intentionnelle de votre application.
Effectuer des révisions de code
Avant de vérifier le code, effectuez des révisions de code pour augmenter la qualité globale du code et réduire le risque de création de bogues. You can use Visual Studio to manage the code review process.
Effectuer une analyse de code statique
L’analyse statique du code (également appelée analyse du code source) est effectuée dans le cadre d’une révision de code. L’analyse statique du code fait généralement référence à l’exécution d’outils d’analyse de code statique pour rechercher des vulnérabilités potentielles dans le code non-en-cours. Static code analysis uses techniques like taint checking and data flow analysis.
Azure Marketplace offers developer tools that perform static code analysis and assist with code reviews.
Valider et nettoyer toutes les entrées de votre application
Traitez toutes les entrées comme non approuvées pour protéger votre application contre les vulnérabilités les plus courantes de l’application web. Les données non approuvées sont un vecteur d'attaques par injection. L'entrée de votre application inclut les paramètres dans l'URL, les saisies de l'utilisateur, les données de la base de données ou d'une API, ainsi que tout élément qu'un utilisateur pourrait potentiellement manipuler. An application should validate that data is syntactically and semantically valid before the application uses the data in any way (including displaying it back to the user).
Validez l’entrée tôt dans le flux de données pour vous assurer que seules les données correctement formées entrent dans le flux de travail. Vous ne souhaitez pas que des données malformées persistent dans votre base de données ou déclenchent un dysfonctionnement dans un composant en aval.
La liste de blocage et la liste d'autorisation sont deux approches générales pour effectuer la validation de la syntaxe des entrées.
La liste de blocage tente de vérifier qu’une entrée utilisateur donnée ne contient pas de contenu « connu pour être 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 comme 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 comme 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 nombres.
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.
Effectuez cette opération sur le serveur, et non sur le côté client (ou sur le serveur et côté client).
Vérifier 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. Escaping, also known as output encoding, is used to help ensure that untrusted data isn't a vehicle for an injection attack. 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.
Escaping makes sure that everything is displayed as output. Escaping also lets the interpreter know that the data isn't intended to be executed, and this prevents attacks from working. This is another common attack technique called cross-site scripting (XSS).
Si vous utilisez un framework web d’un tiers, vous pouvez vérifier vos options d’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 une requête de base de données inline « à la volée » dans votre code et envoyez-la directement à la base de données. Le code malveillant inséré dans votre application peut entraîner le vol, la réinitialisation ou la modification de votre base de données. Votre application peut également être utilisée pour exécuter des commandes de système d’exploitation malveillantes sur le système d’exploitation qui héberge votre base de données.
Utilisez plutôt 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 la transmettre à une chaîne sans vous soucier qu’elle sera traitée dans le cadre de l’instruction de requête.
Supprimer les en-têtes de serveur standard
Les en-têtes tels que Server, X-Powered-By et X-AspNet-Version révèlent des informations sur le serveur et les technologies sous-jacentes. Nous vous recommandons de supprimer ces en-têtes pour éviter l’empreinte digitale de l’application. Consultez la suppression des en-têtes de serveur standard sur les sites web Azure.
Séparer vos données de production
Vos données de production ou données « réelles » ne doivent pas être utilisées pour le développement, les tests ou tout autre objectif que ce que l’entreprise a prévu. A masked (anonymized) dataset should be used for all development and testing.
Cela signifie que moins de personnes ont accès à vos données réelles, ce qui réduit votre surface d’attaque. Cela signifie également que moins d’employés voient les données personnelles, ce qui élimine une violation potentielle de la confidentialité.
Implémenter une stratégie de mot de passe fort
Pour vous défendre contre l’estimation par force brute et par dictionnaire, vous devez implémenter une stratégie de mot de passe forte pour vous assurer que les utilisateurs créent un mot de passe complexe (par exemple, 12 caractères minimum et nécessitant des caractères alphanumériques et spéciaux).
L’ID externe Microsoft Entra dans les locataires externes vous aide à gérer les mots de passe en fournissant une réinitialisation de mot de passe en libre-service et bien plus encore.
Pour vous défendre contre les attaques sur des comptes par défaut, vérifiez que toutes les clés et mots de passe sont remplaçables et qu’elles sont générées ou remplacées 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 qu’ils ont une entropie élevée.
Valider les chargements de fichiers
If your application allows file uploads, consider precautions that you can take for this risky activity. La première étape de nombreuses attaques consiste à obtenir du code malveillant dans un système qui est en cours d’attaque. L’utilisation d’un chargement de fichiers permet à l’attaquant d’y parvenir. OWASP offre des solutions pour valider un fichier pour vous assurer que le fichier que vous chargez est sécurisé.
La protection anti-programme malveillant permet d’identifier et de supprimer les virus, les logiciels espions et d’autres logiciels malveillants. You can install Microsoft Antimalware or a Microsoft partner's endpoint protection solution (Trend Micro, Broadcom, McAfee, Microsoft Defender Antivirus in Windows, and Endpoint Protection).
Microsoft Antimalware includes features like real-time protection, scheduled scanning, malware remediation, signature updates, engine updates, samples reporting, and exclusion event collection. Vous pouvez intégrer Microsoft Antimalware et des solutions de partenaires avec 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 le contenu sensible
Ne ayez pas de contenu sensible en cache sur le navigateur. Les navigateurs peuvent stocker des informations pour la mise en cache et l’historique. Les fichiers mis en cache sont stockés dans un dossier tel que le dossier Fichiers Internet temporaires, dans le cas d’Internet Explorer. Lorsque ces pages sont référencées à nouveau, le navigateur affiche les pages de son cache. If sensitive information (address, credit card details, Social security number, username) is displayed to the user, the information might be stored in the browser's cache and be retrievable by examining the browser's cache or by pressing the browser's Back button.
Verification
La phase de vérification implique un effort complet pour s’assurer que le code répond aux principes de sécurité et de confidentialité établis dans les phases précédentes.
Rechercher et corriger les vulnérabilités dans vos dépendances d’application
Vous analysez votre application et ses bibliothèques dépendantes pour identifier les composants vulnérables connus. Les produits disponibles pour effectuer cette analyse incluent OWASP Dependency Check, Snyk et Black Duck.
Tester votre application dans un état d’exploitation
Le test de sécurité des applications dynamiques (DAST) est un processus de test d’une application dans un état d’exploitation pour rechercher des vulnérabilités de sécurité. Les outils DAST analysent les programmes pendant qu’ils s’exécutent pour rechercher des vulnérabilités de sécurité telles que la corruption de la mémoire, la configuration de serveur non sécurisée, le script intersites, les problèmes de privilège utilisateur, l’injection SQL et d’autres problèmes de sécurité critiques.
DAST est différent du test de sécurité des applications statiques (SAST). Les outils SAST analysent le code source ou les versions compilées du code lorsque le code n’est pas en cours d’exécution pour rechercher des failles de sécurité.
Perform DAST, preferably with the assistance of a security professional (a penetration tester or vulnerability assessor). Si un professionnel de la sécurité n’est pas disponible, vous pouvez effectuer DAST vous-même avec un scanneur proxy web et une formation. Connectez-vous rapidement à un scanneur DAST pour vous assurer que vous n’introduisez pas de problèmes de sécurité évidents dans votre code. See the OWASP site for a list of web application vulnerability scanners.
Effectuer un test à données aléatoires (fuzzing)
In fuzz testing, you induce program failure by deliberately introducing malformed or random data to an application. Provoquer un échec de programme aide à révéler des problèmes de sécurité potentiels avant la sortie de l’application.
La détection des risques de sécurité est le service de test fuzz unique Microsoft pour rechercher des bogues critiques en matière de sécurité dans les logiciels.
Effectuer un examen de la surface d’attaque
L’examen de la surface d’attaque après l’achèvement du code permet de s’assurer que toutes les modifications de conception ou d’implémentation apportées à une application ou à un système ont été prises en compte. Il permet de s’assurer que tous les nouveaux vecteurs d’attaque créés suite aux modifications, y compris les modèles de menace, ont é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 surface d’attaque appelé Attack Surface Analyzer. Vous pouvez choisir parmi de nombreux outils ou services commerciaux de test dynamique et d’analyse des vulnérabilités, notamment OWASP Attack Surface Detector, Arachni et w3af. Ces outils d’analyse analysent votre application et mappent les parties de l’application accessibles sur le web. You can also search the Azure Marketplace for similar developer tools.
Effectuer des tests d’intrusion de sécurité
S’assurer que votre application est sécurisée est aussi importante que de tester toute autre fonctionnalité. Make penetration testing a standard part of the build and deployment process. Planifiez des tests de sécurité réguliers et l’analyse des vulnérabilités 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) à partir du Secure DevOps Kit for Azure (AzSK) contient des SVT pour plusieurs services de la plateforme Azure. Vous exécutez régulièrement ces SVT pour vous assurer que votre abonnement Azure et les différentes ressources qui composent votre application sont dans un état sécurisé. Vous pouvez également automatiser ces tests à l’aide de la fonctionnalité d’intégration continue/de déploiement continu (CI/CD) d’AzSK, qui rend les SVT disponibles en tant qu’extension Visual Studio.
Next steps
Dans les articles suivants, nous vous recommandons de contrôler la sécurité et les activités qui peuvent vous aider à concevoir et déployer des applications sécurisées.