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 concerne uniquement 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é managés, les cabinets de conseil et les équipes rouges) peuvent également tester, à condition qu’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 outils de test d’intrusion ou de red team depuis des machines virtuelles Azure ou Azure Functions contre des systèmes hébergés ailleurs), les ROE s’appliquent toujours à vous, et votre utilisation d’Azure reste soumise aux conditions de votre abonnement. Le ROE interdit spécifiquement l’utilisation de services Microsoft pour effectuer des attaques par hameçonnage ou d’autres attaques d’ingénierie sociale contre d’autres personnes.

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 des machines virtuelles Azure
  • applications d’Azure App Service (Web Apps, API Apps, Mobile Apps)
  • Azure Functions et points de terminaison API
  • Sites web Azure
  • Tous les autres services Azure où vous possédez ou disposez d’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é pour 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 entre comptes ou entre locataires, la génération de trafic pour tester la capacité à absorber les pics de charge au sein de vos propres applications, le test des systèmes de surveillance et de détection de sécurité de votre locataire, l’évaluation des stratégies d’Accès conditionnel ou de gestion des applications mobiles (MAM) d’Intune, les tentatives d’évasion hors de conteneurs de services partagés comme Azure Websites ou Azure Functions (avec divulgation responsable et cessation immédiate en cas de réussite), ainsi que les tentatives de franchissement des 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 informations d’identification ou d’autres secrets qui ne sont pas vos propres, y compris les informations d’identification divulguées publiquement. Dans votre propre environnement, attaquer des comptes que vous possédez est acceptable ; réutiliser des identifiants de 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 ressources Microsoft, y compris l’énumération des réseaux internes, le dumping des secrets, l’exécution de code supplémentaire, le mouvement latéral ou la rotation au-delà de la preuve initiale de concept, sont interdites.
  • 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 de l’équipe rouge IA de Microsoft.

Tests interdits

Les activités suivantes ne sont pas autorisées, quelle que soit l’autorisation. Cette liste est illustrée ; 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.
  • L’accès à des locataires Azure, systèmes, journaux, données ou comptes de stockage, ainsi que leur analyse ou leur test, qui ne vous appartiennent pas ou pour lesquels vous n’avez pas l’autorisation explicite de les tester.
  • 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 contre les services en ligne de Microsoft au-delà de la preuve de concept initiale — par exemple, l’énumération des réseaux internes, l’extraction de secrets, l’exécution de code supplémentaire, le mouvement latéral 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 :

  • BreakingPoint Cloud : un générateur de trafic en libre service à l’aide duquel vos clients peuvent générer du trafic sur les points de terminaison publics dotés de DDoS Protection à des fins de simulation.
  • MazeBolt : La plateforme RADAR™ identifie et active en permanence l’élimination des vulnérabilités DDoS , de manière proactive et sans interruption 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 Tester avec des 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. Les tests légitimes sont parfois signalés, et le ROE note que Microsoft peut, à sa discrétion, interrompre une activité en cours, même s'il s'agit d'un test valide. 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. La conservation des documents d’autorisation facilement accessibles raccourcit considérablement ce processus.

Étapes suivantes

  • Last updated on