Azure APIM : diagnostiquer une clé d'abonnement avant rotation en production

Incident
Hostname: api.internal.example.com
API: orders-api
Product: partner-standard
Subscription: partner-fulfillment-prod
Consumer: partner-orders-worker
Header attendu: Ocp-Apim-Subscription-Key
Symptome: 401 Access denied ou 403 Forbidden
Fenetre: apres rotation planifiee ou regeneration d'urgence
Backend: sain sur probe controlee

Questions avant action
Quelle cle est utilisee: primary ou secondary ?
La subscription est-elle active ?
Le produit contient-il encore l'API appelee ?
Le consumer a-t-il deploye la nouvelle valeur ?
Une policy change-t-elle le nom d'en-tete ou exige-t-elle JWT, mTLS ou IP allowlist ?
Le rollback remet-il une cle ou seulement une configuration applicative ?

Lecture par couche
APIM 401
  Cle absente, mauvaise cle, mauvais nom d'en-tete, subscription inactive ou API hors produit

APIM 403
  Subscription valide mais refus policy, produit ferme, quota, rate limit, IP restriction ou validation JWT/mTLS

Backend 401 ou 403
  APIM a accepte la requete, mais le backend refuse l'identite, le token, la cle applicative ou l'adresse source

WAF ou gateway 403
  La requete peut ne jamais atteindre APIM: verifier logs Application Gateway ou Front Door avant APIM

Aucun log APIM
  Mauvais hostname, route, DNS, listener, certificat, WAF ou chemin client

RG="rg-shared-api-prod"
APIM="apim-prod-core"
SUBSCRIPTION_ID="partner-fulfillment-prod"
PRODUCT_ID="partner-standard"
API_ID="orders-api"

az apim subscription show --resource-group "$RG" --service-name "$APIM" --sid "$SUBSCRIPTION_ID" --query "{state:state,scope:scope,ownerId:ownerId,displayName:displayName,createdDate:createdDate,expirationDate:expirationDate}" --output json

az apim product api list --resource-group "$RG" --service-name "$APIM" --product-id "$PRODUCT_ID" --query "[].{apiId:name,displayName:displayName,path:path}" --output table

az apim api show --resource-group "$RG" --service-name "$APIM" --api-id "$API_ID" --query "{path:path,protocols:protocols,subscriptionRequired:subscriptionRequired}" --output json

let Window = 2h;
let ApiPath = "/orders";
AzureDiagnostics
| where TimeGenerated > ago(Window)
| where ResourceProvider == "MICROSOFT.APIMANAGEMENT"
| where tostring(Url) has ApiPath or tostring(RequestUri) has ApiPath
| project TimeGenerated,
        ServiceName=tostring(Resource),
        ApiId=tostring(ApiId),
        OperationId=tostring(OperationId),
        ProductId=tostring(ProductId),
        SubscriptionId=tostring(SubscriptionId),
        CallerIp=tostring(CallerIPAddress),
        Status=toint(ResponseCode),
        Error=tostring(ErrorMessage),
        CorrelationId=tostring(CorrelationId),
        Url=tostring(Url)
| where Status in (401, 403, 429, 500)
| order by TimeGenerated desc

Sequence de rotation controlee
1. Identifier la cle actuellement utilisee par le consumer
2. Distribuer la cle secondaire si la primaire est active, ou l'inverse
3. Rejouer une requete controlee avec x-correlation-id
4. Verifier APIM logs: subscriptionId, productId, apiId, status 2xx ou erreur attendue
5. Basculer le consumer vers la nouvelle valeur
6. Attendre la fenetre d'observation convenue
7. Regenerer uniquement l'ancienne cle
8. Garder un rollback applicatif documente jusqu'a validation complete

Interdit
Regenerer primary et secondary dans la meme fenetre
Tourner une cle sans savoir quel consumer l'utilise
Corriger un 403 backend par regeneration de subscription key
Supprimer l'ancienne valeur avant preuve APIM et applicative

HOST="api.internal.example.com"
PATH_TO_TEST="/orders/health"
CORRELATION_ID="apim-key-$(date +%Y%m%d%H%M%S)"
SUBSCRIPTION_KEY="<candidate-key>"

curl -sS -D - "https://${HOST}${PATH_TO_TEST}" -H "Ocp-Apim-Subscription-Key: ${SUBSCRIPTION_KEY}" -H "x-correlation-id: ${CORRELATION_ID}" -o /tmp/apim-response.json

echo "correlation_id=${CORRELATION_ID}"
cat /tmp/apim-response.json

Tourner la cle
La subscription est active
Le produit expose toujours l'API
Le consumer a valide la cle de remplacement
APIM logs prouvent le bon subscriptionId
Le rollback applicatif est pret

Corriger le consumer
Mauvais en-tete ou ancienne valeur
Mauvaise variable Key Vault ou App Configuration
Deploiement partiel sur un seul worker
Cache applicatif non rafraichi

Corriger APIM
API retiree du produit par erreur
Subscription desactivee ou expiree
Policy a change le contrat d'authentification
Quota ou rate-limit bloque le consumer legitime

Rollbacker ou bloquer
Les deux cles ont ete invalidees
Impossible d'identifier les consumers reels
Les logs ne distinguent pas APIM et backend
La rotation masque un incident de securite non qualifie

apim_subscription_rotation:
api: orders-api
product: partner-standard
subscription: partner-fulfillment-prod
consumer: partner-orders-worker
active_key_after_change: secondary
old_key_regenerated: primary
evidence:
  - apim_logs_show_expected_subscription_id
  - controlled_replay_correlation_id_attached
  - consumer_deployment_version_identified
  - backend_errors_checked_separately
rollback:
  restore_consumer_secret_version: kv://kv-prod/api/apim-key/previous
  do_not_regenerate_secondary_until: 2026-07-15T18:00:00Z
  owner: platform-operations
follow_up:
  - document consumers for the subscription
  - alert on APIM 401/403 by product and subscription
  - avoid shared subscriptions for unrelated consumers