Choisir un symptôme. Repartir avec un plan d’action.

[Incident] APIM interne retourne une erreur sur une API privée
Contexte : Corréler les logs Application Gateway/WAF et APIM, puis séparer DNS, TLS, policy, identité et joignabilité backend privée avant de modifier les policies ou rouvrir les accès.
Preuves à confirmer : Corréler les logs Application Gateway/WAF et APIM, puis séparer DNS, TLS, policy, identité et joignabilité backend privée avant de modifier les policies ou rouvrir les accès.
Contrôles immédiats : Vérifier si le WAF a bloqué la requête | Confirmer qu’APIM reçoit le même chemin | Valider DNS et TLS backend depuis le chemin APIM | Rejouer avec un identifiant de corrélation
Action proposée : Exécuter les premiers contrôles dans l’ordre : Vérifier si le WAF a bloqué la requête | Confirmer qu’APIM reçoit le même chemin | Valider DNS et TLS backend depuis le chemin APIM | Rejouer avec un identifiant de corrélation. Ouvrir les notes liées avant de modifier la production.
Rollback : Arrêter le changement, restaurer le dernier état sûr connu et conserver les preuves capturées pour comparaison.

Symptôme traité : APIM interne retourne une erreur sur une API privée
Hypothèse initiale : Corréler les logs Application Gateway/WAF et APIM, puis séparer DNS, TLS, policy, identité et joignabilité backend privée avant de modifier les policies ou rouvrir les accès.
Preuves utilisées : Corréler les logs Application Gateway/WAF et APIM, puis séparer DNS, TLS, policy, identité et joignabilité backend privée avant de modifier les policies ou rouvrir les accès.
Contrôles effectués : Vérifier si le WAF a bloqué la requête | Confirmer qu’APIM reçoit le même chemin | Valider DNS et TLS backend depuis le chemin APIM | Rejouer avec un identifiant de corrélation
Décision / action : Exécuter les premiers contrôles dans l’ordre : Vérifier si le WAF a bloqué la requête | Confirmer qu’APIM reçoit le même chemin | Valider DNS et TLS backend depuis le chemin APIM | Rejouer avec un identifiant de corrélation. Ouvrir les notes liées avant de modifier la production.
Plan de retour arrière : Arrêter le changement, restaurer le dernier état sûr connu et conserver les preuves capturées pour comparaison.
À améliorer : détection, runbook, garde-fou, ownership et délai de communication.

[Incident] Un nom Private Endpoint résout encore en public
Contexte : Confirmer la chaîne CNAME, l’association Private DNS Zone et le forwarding hybride depuis le réseau consommateur.
Preuves à confirmer : nslookup depuis le subnet workload, chaîne CNAME, liens Private DNS Zone, chemin de forwarding resolver et réponses en cache.
Contrôles immédiats : Lancer nslookup depuis le réseau workload | Vérifier le CNAME privatelink | Contrôler les liens Private DNS Zone et forwarders
Action proposée : Corriger d’abord association de zone ou forwarding, puis vider les caches et retester depuis le réseau consommateur.
Rollback : Restaurer l’ancien lien ou forwarder et documenter l’écart entre réponse publique et privée.

Symptôme traité : Un nom Private Endpoint résout encore en public
Hypothèse initiale : Confirmer la chaîne CNAME, l’association Private DNS Zone et le forwarding hybride depuis le réseau consommateur.
Preuves utilisées : nslookup depuis le subnet workload, chaîne CNAME, liens Private DNS Zone, chemin de forwarding resolver et réponses en cache.
Contrôles effectués : Lancer nslookup depuis le réseau workload | Vérifier le CNAME privatelink | Contrôler les liens Private DNS Zone et forwarders
Décision / action : Corriger d’abord association de zone ou forwarding, puis vider les caches et retester depuis le réseau consommateur.
Plan de retour arrière : Restaurer l’ancien lien ou forwarder et documenter l’écart entre réponse publique et privée.
À améliorer : détection, runbook, garde-fou, ownership et délai de communication.

[Incident] Un endpoint privé Azure Storage retourne 403, timeout ou aucun log de requête
Contexte : Séparer DNS du sous-service Storage, approbation Private Endpoint, règles firewall, identité runtime et logs Storage avant d’ouvrir l’accès public ou d’élargir RBAC.
Preuves à confirmer : Séparer DNS du sous-service Storage, approbation Private Endpoint, règles firewall, identité runtime et logs Storage avant d’ouvrir l’accès public ou d’élargir RBAC.
Contrôles immédiats : Résoudre le sous-service Storage exact depuis le réseau workload | Vérifier statut Private Endpoint et private DNS zone group | Rejouer avec un client request ID | Corréler les logs Storage pour 403, IP appelante et identité requérante
Action proposée : Exécuter les premiers contrôles dans l’ordre : Résoudre le sous-service Storage exact depuis le réseau workload | Vérifier statut Private Endpoint et private DNS zone group | Rejouer avec un client request ID | Corréler les logs Storage pour 403, IP appelante et identité requérante. Ouvrir les notes liées avant de modifier la production.
Rollback : Arrêter le changement, restaurer le dernier état sûr connu et conserver les preuves capturées pour comparaison.

Symptôme traité : Un endpoint privé Azure Storage retourne 403, timeout ou aucun log de requête
Hypothèse initiale : Séparer DNS du sous-service Storage, approbation Private Endpoint, règles firewall, identité runtime et logs Storage avant d’ouvrir l’accès public ou d’élargir RBAC.
Preuves utilisées : Séparer DNS du sous-service Storage, approbation Private Endpoint, règles firewall, identité runtime et logs Storage avant d’ouvrir l’accès public ou d’élargir RBAC.
Contrôles effectués : Résoudre le sous-service Storage exact depuis le réseau workload | Vérifier statut Private Endpoint et private DNS zone group | Rejouer avec un client request ID | Corréler les logs Storage pour 403, IP appelante et identité requérante
Décision / action : Exécuter les premiers contrôles dans l’ordre : Résoudre le sous-service Storage exact depuis le réseau workload | Vérifier statut Private Endpoint et private DNS zone group | Rejouer avec un client request ID | Corréler les logs Storage pour 403, IP appelante et identité requérante. Ouvrir les notes liées avant de modifier la production.
Plan de retour arrière : Arrêter le changement, restaurer le dernier état sûr connu et conserver les preuves capturées pour comparaison.
À améliorer : détection, runbook, garde-fou, ownership et délai de communication.

[Incident] Une probe synthétique échoue sur un chemin privé Azure
Contexte : Séparer DNS, TLS, health Application Gateway, blocages WAF et réseau du runner avant de modifier le routage ou le code applicatif.
Preuves à confirmer : Séparer DNS, TLS, health Application Gateway, blocages WAF et réseau du runner avant de modifier le routage ou le code applicatif.
Contrôles immédiats : Résoudre le hostname depuis le réseau de probe | Contrôler TLS/SNI avec le vrai hostname | Corréler le run de probe avec les logs WAF et gateway
Action proposée : Exécuter les premiers contrôles dans l’ordre : Résoudre le hostname depuis le réseau de probe | Contrôler TLS/SNI avec le vrai hostname | Corréler le run de probe avec les logs WAF et gateway. Ouvrir les notes liées avant de modifier la production.
Rollback : Arrêter le changement, restaurer le dernier état sûr connu et conserver les preuves capturées pour comparaison.

Symptôme traité : Une probe synthétique échoue sur un chemin privé Azure
Hypothèse initiale : Séparer DNS, TLS, health Application Gateway, blocages WAF et réseau du runner avant de modifier le routage ou le code applicatif.
Preuves utilisées : Séparer DNS, TLS, health Application Gateway, blocages WAF et réseau du runner avant de modifier le routage ou le code applicatif.
Contrôles effectués : Résoudre le hostname depuis le réseau de probe | Contrôler TLS/SNI avec le vrai hostname | Corréler le run de probe avec les logs WAF et gateway
Décision / action : Exécuter les premiers contrôles dans l’ordre : Résoudre le hostname depuis le réseau de probe | Contrôler TLS/SNI avec le vrai hostname | Corréler le run de probe avec les logs WAF et gateway. Ouvrir les notes liées avant de modifier la production.
Plan de retour arrière : Arrêter le changement, restaurer le dernier état sûr connu et conserver les preuves capturées pour comparaison.
À améliorer : détection, runbook, garde-fou, ownership et délai de communication.

[Incident] L’ingress privé Azure Container Apps échoue ou atteint la mauvaise révision
Contexte : Séparer DNS privé, passage Application Gateway, mode d’ingress Container Apps, trafic des révisions et logs console avant rollback ou changement de poids.
Preuves à confirmer : Séparer DNS privé, passage Application Gateway, mode d’ingress Container Apps, trafic des révisions et logs console avant rollback ou changement de poids.
Contrôles immédiats : Résoudre le hostname depuis le réseau appelant | Vérifier target port ingress et révisions actives | Corréler logs system et console
Action proposée : Exécuter les premiers contrôles dans l’ordre : Résoudre le hostname depuis le réseau appelant | Vérifier target port ingress et révisions actives | Corréler logs system et console. Ouvrir les notes liées avant de modifier la production.
Rollback : Arrêter le changement, restaurer le dernier état sûr connu et conserver les preuves capturées pour comparaison.

Symptôme traité : L’ingress privé Azure Container Apps échoue ou atteint la mauvaise révision
Hypothèse initiale : Séparer DNS privé, passage Application Gateway, mode d’ingress Container Apps, trafic des révisions et logs console avant rollback ou changement de poids.
Preuves utilisées : Séparer DNS privé, passage Application Gateway, mode d’ingress Container Apps, trafic des révisions et logs console avant rollback ou changement de poids.
Contrôles effectués : Résoudre le hostname depuis le réseau appelant | Vérifier target port ingress et révisions actives | Corréler logs system et console
Décision / action : Exécuter les premiers contrôles dans l’ordre : Résoudre le hostname depuis le réseau appelant | Vérifier target port ingress et révisions actives | Corréler logs system et console. Ouvrir les notes liées avant de modifier la production.
Plan de retour arrière : Arrêter le changement, restaurer le dernier état sûr connu et conserver les preuves capturées pour comparaison.
À améliorer : détection, runbook, garde-fou, ownership et délai de communication.

[Incident] L’ingress privé AKS retourne 502 ou ne trouve aucun endpoint de service
Contexte : Séparer DNS privé, health Application Gateway, routage ingress controller, selectors de service Kubernetes, endpoint slices et readiness des pods avant de rollback un déploiement.
Preuves à confirmer : Séparer DNS privé, health Application Gateway, routage ingress controller, selectors de service Kubernetes, endpoint slices et readiness des pods avant de rollback un déploiement.
Contrôles immédiats : Résoudre le hostname depuis le réseau appelant | Vérifier backend health Application Gateway et host header | Contrôler ingress, service et endpoint slices | Corréler logs controller et applicatifs
Action proposée : Exécuter les premiers contrôles dans l’ordre : Résoudre le hostname depuis le réseau appelant | Vérifier backend health Application Gateway et host header | Contrôler ingress, service et endpoint slices | Corréler logs controller et applicatifs. Ouvrir les notes liées avant de modifier la production.
Rollback : Arrêter le changement, restaurer le dernier état sûr connu et conserver les preuves capturées pour comparaison.

Symptôme traité : L’ingress privé AKS retourne 502 ou ne trouve aucun endpoint de service
Hypothèse initiale : Séparer DNS privé, health Application Gateway, routage ingress controller, selectors de service Kubernetes, endpoint slices et readiness des pods avant de rollback un déploiement.
Preuves utilisées : Séparer DNS privé, health Application Gateway, routage ingress controller, selectors de service Kubernetes, endpoint slices et readiness des pods avant de rollback un déploiement.
Contrôles effectués : Résoudre le hostname depuis le réseau appelant | Vérifier backend health Application Gateway et host header | Contrôler ingress, service et endpoint slices | Corréler logs controller et applicatifs
Décision / action : Exécuter les premiers contrôles dans l’ordre : Résoudre le hostname depuis le réseau appelant | Vérifier backend health Application Gateway et host header | Contrôler ingress, service et endpoint slices | Corréler logs controller et applicatifs. Ouvrir les notes liées avant de modifier la production.
Plan de retour arrière : Arrêter le changement, restaurer le dernier état sûr connu et conserver les preuves capturées pour comparaison.
À améliorer : détection, runbook, garde-fou, ownership et délai de communication.

[Incident] Un endpoint HTTP privé Azure Functions retourne 403, 503 ou aucun log de requête
Contexte : Séparer DNS privé, joignabilité Private Endpoint, restrictions d’accès, état runtime Functions, storage privé et preuves Application Insights avant de redéployer le code ou rouvrir l’accès public.
Preuves à confirmer : Séparer DNS privé, joignabilité Private Endpoint, restrictions d’accès, état runtime Functions, storage privé et preuves Application Insights avant de redéployer le code ou rouvrir l’accès public.
Contrôles immédiats : Résoudre le hostname depuis le réseau appelant | Rejouer avec un identifiant de corrélation | Vérifier access restrictions et statut Private Endpoint | Corréler requests, traces et exceptions
Action proposée : Exécuter les premiers contrôles dans l’ordre : Résoudre le hostname depuis le réseau appelant | Rejouer avec un identifiant de corrélation | Vérifier access restrictions et statut Private Endpoint | Corréler requests, traces et exceptions. Ouvrir les notes liées avant de modifier la production.
Rollback : Arrêter le changement, restaurer le dernier état sûr connu et conserver les preuves capturées pour comparaison.

Symptôme traité : Un endpoint HTTP privé Azure Functions retourne 403, 503 ou aucun log de requête
Hypothèse initiale : Séparer DNS privé, joignabilité Private Endpoint, restrictions d’accès, état runtime Functions, storage privé et preuves Application Insights avant de redéployer le code ou rouvrir l’accès public.
Preuves utilisées : Séparer DNS privé, joignabilité Private Endpoint, restrictions d’accès, état runtime Functions, storage privé et preuves Application Insights avant de redéployer le code ou rouvrir l’accès public.
Contrôles effectués : Résoudre le hostname depuis le réseau appelant | Rejouer avec un identifiant de corrélation | Vérifier access restrictions et statut Private Endpoint | Corréler requests, traces et exceptions
Décision / action : Exécuter les premiers contrôles dans l’ordre : Résoudre le hostname depuis le réseau appelant | Rejouer avec un identifiant de corrélation | Vérifier access restrictions et statut Private Endpoint | Corréler requests, traces et exceptions. Ouvrir les notes liées avant de modifier la production.
Plan de retour arrière : Arrêter le changement, restaurer le dernier état sûr connu et conserver les preuves capturées pour comparaison.
À améliorer : détection, runbook, garde-fou, ownership et délai de communication.

[Incident] Azure WAF bloque une requête légitime
Contexte : Partir des requêtes bloquées, du ruleId et de l’URI avant de choisir exclusion, custom rule ou correction applicative.
Preuves à confirmer : URI bloquée, ruleId, variable matchée, client IP, hostname, request ID et fenêtre temporelle exacte.
Contrôles immédiats : Lister les URI bloquées en KQL | Identifier ruleId et champ matché | Valider le périmètre du faux positif
Action proposée : Créer la plus petite exclusion ou custom rule possible sans désactiver la règle globalement.
Rollback : Supprimer l’exclusion/custom rule et vérifier que le blocage attendu revient sur la même famille de règles.

Symptôme traité : Azure WAF bloque une requête légitime
Hypothèse initiale : Partir des requêtes bloquées, du ruleId et de l’URI avant de choisir exclusion, custom rule ou correction applicative.
Preuves utilisées : URI bloquée, ruleId, variable matchée, client IP, hostname, request ID et fenêtre temporelle exacte.
Contrôles effectués : Lister les URI bloquées en KQL | Identifier ruleId et champ matché | Valider le périmètre du faux positif
Décision / action : Créer la plus petite exclusion ou custom rule possible sans désactiver la règle globalement.
Plan de retour arrière : Supprimer l’exclusion/custom rule et vérifier que le blocage attendu revient sur la même famille de règles.
À améliorer : détection, runbook, garde-fou, ownership et délai de communication.

[Incident] Le state lock Terraform reste bloqué
Contexte : Prouver qu’aucun apply n’est encore actif avant force-unlock, puis repartir sur un plan propre.
Preuves à confirmer : Lock ID, propriétaire du lock, run CI, backend ciblé, plan en attente et preuve qu’aucun apply n’est actif.
Contrôles immédiats : Identifier le propriétaire du lock | Contrôler le statut du job CI | Relancer un plan après unlock
Action proposée : Déverrouiller seulement après avoir prouvé qu’aucun apply ne tourne, puis repartir sur un plan frais avant tout apply.
Rollback : Revenir au commit précédent ou restaurer la dernière version de state validée si une dérive a été introduite.

Symptôme traité : Le state lock Terraform reste bloqué
Hypothèse initiale : Prouver qu’aucun apply n’est encore actif avant force-unlock, puis repartir sur un plan propre.
Preuves utilisées : Lock ID, propriétaire du lock, run CI, backend ciblé, plan en attente et preuve qu’aucun apply n’est actif.
Contrôles effectués : Identifier le propriétaire du lock | Contrôler le statut du job CI | Relancer un plan après unlock
Décision / action : Déverrouiller seulement après avoir prouvé qu’aucun apply ne tourne, puis repartir sur un plan frais avant tout apply.
Plan de retour arrière : Revenir au commit précédent ou restaurer la dernière version de state validée si une dérive a été introduite.
À améliorer : détection, runbook, garde-fou, ownership et délai de communication.

[Incident] Une rotation de secret ou un changement d’identité managée casse un consommateur applicatif ou CI
Contexte : Séparer préparation, bascule, révocation et diagnostic d’identité managée ; valider l’identité réelle d’exécution, le chemin privé et les erreurs d’authentification avant de supprimer l’ancienne valeur ou d’élargir l’accès.
Preuves à confirmer : Séparer préparation, bascule, révocation et diagnostic d’identité managée ; valider l’identité réelle d’exécution, le chemin privé et les erreurs d’authentification avant de supprimer l’ancienne valeur ou d’élargir l’accès.
Contrôles immédiats : Lister les consommateurs réels | Vérifier l’identité runtime et la lecture du coffre | Contrôler DNS privé et réseau source | Surveiller les 401/403/500 ou refus Key Vault
Action proposée : Exécuter les premiers contrôles dans l’ordre : Lister les consommateurs réels | Vérifier l’identité runtime et la lecture du coffre | Contrôler DNS privé et réseau source | Surveiller les 401/403/500 ou refus Key Vault. Ouvrir les notes liées avant de modifier la production.
Rollback : Arrêter le changement, restaurer le dernier état sûr connu et conserver les preuves capturées pour comparaison.

Symptôme traité : Une rotation de secret ou un changement d’identité managée casse un consommateur applicatif ou CI
Hypothèse initiale : Séparer préparation, bascule, révocation et diagnostic d’identité managée ; valider l’identité réelle d’exécution, le chemin privé et les erreurs d’authentification avant de supprimer l’ancienne valeur ou d’élargir l’accès.
Preuves utilisées : Séparer préparation, bascule, révocation et diagnostic d’identité managée ; valider l’identité réelle d’exécution, le chemin privé et les erreurs d’authentification avant de supprimer l’ancienne valeur ou d’élargir l’accès.
Contrôles effectués : Lister les consommateurs réels | Vérifier l’identité runtime et la lecture du coffre | Contrôler DNS privé et réseau source | Surveiller les 401/403/500 ou refus Key Vault
Décision / action : Exécuter les premiers contrôles dans l’ordre : Lister les consommateurs réels | Vérifier l’identité runtime et la lecture du coffre | Contrôler DNS privé et réseau source | Surveiller les 401/403/500 ou refus Key Vault. Ouvrir les notes liées avant de modifier la production.
Plan de retour arrière : Arrêter le changement, restaurer le dernier état sûr connu et conserver les preuves capturées pour comparaison.
À améliorer : détection, runbook, garde-fou, ownership et délai de communication.

[Incident] Une automatisation ressemble à une console distante
Contexte : Borner les entrées, templates et dépôts avant d’exposer des opérations à plus d’utilisateurs.
Preuves à confirmer : Entrées acceptées par le template, permissions, périmètre d’inventaire, branche dépôt et trace d’audit.
Contrôles immédiats : Lister les entrées acceptées | Supprimer les champs de commande arbitraire | Revoir les permissions des job templates
Action proposée : Remplacer les entrées arbitraires par des choix bornés et isoler les job templates par intention opérationnelle.
Rollback : Désactiver le template exposé ou revenir à la version de template précédemment approuvée.

Symptôme traité : Une automatisation ressemble à une console distante
Hypothèse initiale : Borner les entrées, templates et dépôts avant d’exposer des opérations à plus d’utilisateurs.
Preuves utilisées : Entrées acceptées par le template, permissions, périmètre d’inventaire, branche dépôt et trace d’audit.
Contrôles effectués : Lister les entrées acceptées | Supprimer les champs de commande arbitraire | Revoir les permissions des job templates
Décision / action : Remplacer les entrées arbitraires par des choix bornés et isoler les job templates par intention opérationnelle.
Plan de retour arrière : Désactiver le template exposé ou revenir à la version de template précédemment approuvée.
À améliorer : détection, runbook, garde-fou, ownership et délai de communication.

[Incident] Un agent IA privé peut agir sans que l’action soit explicable
Contexte : Relier sources, identités, appels d’outils, journaux et validation humaine avant d’augmenter l’autonomie.
Preuves à confirmer : Documents sources, identité, appels d’outils, contexte de prompt, logs et point de validation humaine.
Contrôles immédiats : Lister les sources approuvées | Tracer les appels d’outils | Définir les points d’approbation humaine
Action proposée : Réduire le périmètre des outils, exiger une approbation sur les actions sensibles et relier chaque appel d’outil à une source.
Rollback : Désactiver l’intégration outil ou imposer une validation humaine tant que le chemin d’action n’est pas explicable.

Symptôme traité : Un agent IA privé peut agir sans que l’action soit explicable
Hypothèse initiale : Relier sources, identités, appels d’outils, journaux et validation humaine avant d’augmenter l’autonomie.
Preuves utilisées : Documents sources, identité, appels d’outils, contexte de prompt, logs et point de validation humaine.
Contrôles effectués : Lister les sources approuvées | Tracer les appels d’outils | Définir les points d’approbation humaine
Décision / action : Réduire le périmètre des outils, exiger une approbation sur les actions sensibles et relier chaque appel d’outil à une source.
Plan de retour arrière : Désactiver l’intégration outil ou imposer une validation humaine tant que le chemin d’action n’est pas explicable.
À améliorer : détection, runbook, garde-fou, ownership et délai de communication.