Test d’intrusion

Le test de pénétration de vos applications est une partie importante de leur exécution sur Azure. Vous n'avez pas besoin de l'approbation préalable de Microsoft pour le faire, mais vous devez suivre les règles publiées. Cet article récapitule ces règles et vous pointe vers les sources faisant autorité.

Depuis le 15 juin 2017, une approbation préalable n’est plus exigée par Microsoft pour réaliser un test d’intrusion sur les ressources Azure. Ce processus ne s'applique qu'à Microsoft Azure et ne s'applique à aucun autre Microsoft Cloud Service.

Important

La notification n’est plus nécessaire, mais les clients et les tiers autorisés doivent se conformer aux Microsoft Cloud règles unifiées d’engagement des tests d’intrusion. Les règles d’engagement (ROE) sont la source faisant autorité ; cet article est un résumé.

Qui peut tester

Vous pouvez effectuer des tests d’intrusion sur Azure ressources que vous possédez. Les tiers (tels que les fournisseurs de services de sécurité gérés, les cabinets de conseil et les équipes rouges) peuvent également tester, s’ils disposent d’une autorisation écrite explicite du propriétaire de la ressource. Documentez cette autorisation dans votre contrat de service avant le début des tests. Microsoft n'accorde pas d'autorisation au nom du client.

Si vous utilisez Azure comme source de l’activité de test (par exemple, en exécutant des tests d’intrusion ou des outils de red team à partir de machines virtuelles Azure ou d’Azure Functions contre des systèmes hébergés ailleurs), le ROE continue de s’appliquer, et votre utilisation d’Azure reste soumise aux conditions de votre abonnement. Le ROE interdit spécifiquement l’utilisation des services services Microsoft pour effectuer du phishing ou d’autres attaques d’ingénierie sociale contre autrui.

Tests autorisés

Vous pouvez effectuer des tests d’intrusion sur les applications et services hébergés par Azure sans approbation préalable. Voici quelques exemples :

  • Vos points de terminaison hébergés sur Machines virtuelles Azure.
  • Azure App Service applications (Web Apps, API Apps, Mobile Apps).
  • Azure Functions et points de terminaison API.
  • Azure App Service
  • Tout autre service Azure où vous possédez ou avez une autorisation explicite pour tester les ressources déployées.

Vous avez la possibilité d’effectuer plusieurs tests :

Cette liste est illustrante, pas exhaustive. Les Règles d’engagement sont la source faisant autorité sur ce qui est autorisé.

Le ROE encourage également explicitement des activités telles que la création de comptes de test ou de locataires d'essai pour des scénarios de test inter-comptes ou interlocataires, la génération de trafic pour tester la capacité de surtension au sein de vos propres applications, le test des systèmes de surveillance et de détection de sécurité de vos locataires, l'évaluation des politiques de gestion d'applications mobiles (MAM) Conditional Access ou Intune, et la tentative de déverrouillage des conteneurs de services partagés comme Azure App Service ou Azure Functions (avec divulgation responsable et cessation immédiate en cas de succès), et tenter de franchir les limites des systèmes d’IA.

Activités d’équipe rouge

Les exercices de red team menés sur vos propres ressources Azure (ou sur celles d’un client, avec son autorisation écrite explicite) sont régis par le même ROE. Dans le cadre autorisé, le ROE n’énumère pas quelles techniques adverses sont permises ; le texte de référence est donc la liste des activités interdites. Portez une attention particulière à ces contraintes, qui affectent directement les tactiques, techniques et procédures de la red team :

  • Vous ne pouvez pas utiliser, accéder ou récupérer des identifiants ou d’autres secrets qui ne vous appartiennent pas – y compris ceux qui ont fuité publiquement. Dans votre propre environnement, attaquer les comptes que vous possédez est acceptable ; Réutiliser des identifiants tiers ne l’est pas.
  • Si vous détectez une vulnérabilité dans les services en ligne de Microsoft lors d'un test, vous devez l'arrêter et le signaler via le Centre d'intervention en matière de sécurité Microsoft (MSRC). Les actions post-exploit contre les actifs Microsoft sont interdites, y compris l’énumération des réseaux internes, le dumping de secrets, l’exécution de plus de code, les mouvements latéraux ou le pivot au-delà de la preuve de concept initiale.
  • Les tests DDoS sont interdits dans toutes les circonstances. Utilisez plutôt les partenaires de simulation DDoS répertoriés ci-dessous.
  • Les tests flous ou automatisés gourmands en réseau qui génèrent un trafic excessif ne sont pas autorisés.

Pour le red teaming spécifique à l’IA pour les charges de travail d’IA Azure (y compris les déploiements Azure OpenAI et Microsoft Foundry), consultez Planification du red teaming pour les grands modèles de langage (LLM) et leurs applications et la série de formations sur le red teaming IA de Microsoft.

Tests interdits

Les activités suivantes ne sont pas autorisées, quelle que soit l’autorisation. Cette liste est illustrative. Le ROE est la source faisant autorité.

  • Test de déni de service (DoS) de tout type, y compris les tests qui déterminent, illustrent ou simulent DoS. Les attaques DDoS sont strictement interdites dans toutes les circonstances.
  • Accès, analyse ou test de locataires, systèmes, journaux, données ou comptes de stockage Azure que vous ne possédez pas ou pour lesquels vous ne disposez pas d’une autorisation explicite de test.
  • Utilisation, accès ou récupération d’informations d’identification ou d’autres secrets qui ne sont pas vos propres.
  • Fuzzing ou test automatisé très consommateur en ressources réseau, générant un trafic excessif.
  • Attaques d’hameçonnage ou d’ingénierie sociale ciblant Microsoft employés, ou en utilisant services Microsoft (y compris Azure) pour effectuer un hameçonnage ou une ingénierie sociale contre d’autres personnes.
  • Actions après compromission ou après exploitation visant les services en ligne de Microsoft au-delà de la preuve de concept initiale, telles que l’énumération des réseaux internes, l’extraction de secrets, l’exécution de code supplémentaire, les déplacements latéraux ou le rebond.

Test de simulation DDoS

Si vous devez tester votre résilience DDoS, vous pouvez utiliser des partenaires de simulation approuvés par Microsoft. Ces partenaires fournissent des services de simulation DDoS contrôlés qui ne respectent pas les règles de test d’intrusion :

  • MazeBolt : La plateforme RADAR™ identifie en continu et aide à éliminer les vulnérabilités DDoS de manière proactive et sans aucune perturbation des opérations commerciales.
  • Red Button : collaborez avec une équipe dédiée d’experts pour simuler des scénarios d’attaque DDoS réels dans un environnement contrôlé.
  • RedWolf : un fournisseur de test DDoS libre-service ou guidé avec un contrôle en temps réel.

Pour en savoir plus sur ces partenaires de simulation, consultez Test avec les partenaires de simulation.

Si votre test est marqué d’un indicateur

Azure exécute la détection automatisée des abus sur le trafic sortant et entrant. Un test légitime est parfois signalé, et le ROE précise que Microsoft peut, à sa discrétion, interrompre une activité en cours, qu'il s'agisse d'un test valide ou non. Si vous recevez un signalement d’abus concernant une activité conforme au ROE, répondez à cette notification en joignant l’autorisation de votre client et une description de l’activité entrant dans le périmètre. Gardez les documents d’autorisation à portée de main pour raccourcir considérablement ce processus.

Étapes suivantes

  • Last updated on