Ce que cela signifie pour votre test
Suivez une identité de charge de travail depuis son attribution jusqu’aux opérations qu’elle peut effectuer. Distinguez les éléments exposés, les identifiants utilisables et les autorisations excessives. Définissez les ressources autorisées et les actions de preuve avant de valider le parcours.
La frontière à tester
Une application au périmètre restreint peut dépendre d’une identité de déploiement largement privilégiée. Les archives de build, les jetons de charge de travail et les rôles d’assistance des fournisseurs nécessitent des preuves des autorisations effectives et de leur durée de validité.
Une API marchande peut authentifier correctement l’appelant sans rattacher un objet à ce marchand. Un webhook peut être authentique et pourtant rejoué au mauvais état de transaction. Les tests doivent tenir compte des décisions métier attendues du produit, et pas seulement d’une liste d’URL de points de terminaison.
Ce que le périmètre peut inclure
- Accès aux artefacts CI/CD et identifiants d’amorçage
- Audience du jeton de service et principe du moindre privilège
- Rôles de gestion cloud et relations de confiance
- Administration de la récupération et révocation des sessions actives
La proposition finale identifie les applications, les comptes, les environnements et les interfaces concernés. Elle précise également les prérequis que votre équipe ou un prestataire doit fournir.
À quoi ressemble une preuve utile
Validez le parcours approuvé, de l’artefact ou du contexte fourni jusqu’à une opération API précise. Consignez les métadonnées du jeton et les décisions relatives aux rôles en masquant les secrets, puis vérifiez si la révocation s’applique aux sessions existantes.
Consignez l’heure UTC, l’identifiant de l’actif, le principal à l’origine de la requête, la décision attendue et la réponse observée. Les tests qui modifient l’état nécessitent une confirmation dans l’objet résultant ou dans un journal d’audit fiable. Les opérations refusées et les contrôles effectifs font également partie du résultat.
Mesures de sécurité et limites de l’évaluation
Le périmètre désigne les comptes cloud, les projets et les limites vis-à-vis des tiers. Aucune autorisation d’inventorier des infrastructures de clients sans lien avec le périmètre ni de modifier les contrôles de reprise en production n’est présumée.
Utilisez des locataires dédiés, des données clients synthétiques et des circuits de paiement de test avec le règlement réel désactivé. Convenez des autorisations des systèmes partenaires, des limites de transaction, de la procédure de retour arrière et des fenêtres de mise en production. Les activités en production doivent avoir des responsables explicitement désignés et un canal d’arrêt clairement défini.
Bouclez la démarche
Reliez chaque faiblesse à un responsable nommé, à une mesure de protection immédiate et à une correction pérenne. Définissez des cas de retest positifs et négatifs afin que la modification rétablisse la limite prévue tout en préservant les usages légitimes. Les points en suspens conservent leurs dépendances et leurs échéances.
Consultez l’exemple de rapport sectoriel pour découvrir le format des éléments probants et du plan de traitement.
