Partager via

Développer des applications sécurisées sur Azure

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 :

  • 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 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. Vous pouvez utiliser Visual Studio pour gérer le processus de révision du code.

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. L’analyse statique du code utilise des techniques telles que la vérification des teintes et l’analyse du flux de données.

La Place de marché Azure offre des outils de développement qui effectuent une analyse statique du code et aident à consulter le code.

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. Une application doit vérifier que les données sont syntactiques et sémantiquement valides avant que l’application utilise les données de quelque manière que ce soit (y compris l’afficher à l’utilisateur).

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. 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 est affiché sous forme de sortie. L’échappement informe également l’interpréteur que les données ne sont pas destinées à être exécutées pour éviter l’exécution des attaques. Il s’agit d’une autre technique d’attaque courante appelée script intersites (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. Un jeu de données masqué (anonymisé) doit être utilisé pour tous les tests et développement.

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

Si votre application autorise les chargements de fichiers, tenez compte des précautions que vous pouvez prendre pour cette activité risquée. 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. Vous pouvez installer Microsoft Antimalware ou la solution de protection des points de terminaison d’un partenaire Microsoft (Trend Micro, Broadcom, McAfee, Antivirus Microsoft Defender dans Windows et Endpoint Protection).

Microsoft Antimalware inclut des fonctionnalités telles que la protection en temps réel, l’analyse planifiée, la correction des programmes malveillants, les mises à jour de signature, les mises à jour du moteur, les exemples de création de rapports et la collecte d’événements d’exclusion. 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. Si des informations sensibles (adresse, détails de carte de crédit, numéro de sécurité sociale, nom d’utilisateur) sont affichées à l’utilisateur, les informations peuvent être stockées dans le cache du navigateur et être récupérables en examinant le 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 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é.

Effectuez DAST, de préférence avec l’aide d’un professionnel de la sécurité ( testeur d’intrusion ou évaluateur de vulnérabilité). 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. Consultez le site OWASP pour obtenir la liste des scanneurs de vulnérabilité d’application web.

Effectuer des tests approximatifs

Dans les tests flous, vous pouvez induire une défaillance du fonctionnement du programme en introduisant délibérément des données malformées ou aléatoires dans une 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. Vous pouvez également rechercher des outils de développement similaires dans la Place de marché Azure.

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é. Effectuez des tests d’intrusion dans une partie standard du processus de génération et de déploiement. 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.

Étapes suivantes

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.