Toutes les API REST Azure DevOps reçoivent désormais des jetons d’accès personnels (PAT) granulaires. L’objectif de ce changement, qui a été accueilli avec joie par la communauté de la cybersécurité, est de minimiser les dommages potentiels d’une fuite d’informations d’identification PAT.
Annonçant la nouvelle via un article de blog Azure DevOps, le chef de produit Barry Wolfson a déclaré qu’avant le changement, il y avait « un risque de sécurité important pour les organisations, étant donné la possibilité d’accéder au code source, à l’infrastructure de production et à d’autres actifs précieux ».
« Auparavant, un certain nombre d’API Azure DevOps REST n’étaient pas associées à une portée PAT, ce qui conduisait parfois les clients à consommer ces API à l’aide de PAT à portée complète. » Le large éventail d’autorisations associées à celles-ci était une source de préoccupation.
Déclencheur de prétorien
Bien que Wolfson n’ait pas mentionné de détails, d’autres ont émis l’hypothèse que le changement semble être survenu après que les chercheurs prétoriens ont utilisé les PAT API REST pour accéder aux réseaux d’entreprise d’autres entreprises.
L’un d’eux était le site Web GitHub appartenant à Microsoft, qui a été compromis grâce à une fuite de PAT. La société teste actuellement l’utilisation de PAT à grain fin dans sa version bêta publique pour remédier au problème.
Maintenant, Wolfson suggère aux équipes DevOps d’effectuer le changement le plus tôt possible. « Si vous utilisez actuellement un PAT à portée complète pour vous authentifier auprès de l’une des API Azure DevOps REST, envisagez de migrer vers un PAT avec la portée spécifique acceptée par l’API pour éviter tout accès inutile », a-t-il déclaré.
La ou les étendues PAT granulaires prises en charge pour une API REST donnée peuvent être trouvées dans la section Sécurité – Étendues des pages de documentation de l’API REST, a-t-il ajouté.
De plus, les modifications devraient permettre aux clients de restreindre la création de PAT à portée complète, via une politique de plan de contrôle.
« Nous sommes impatients de continuer à fournir des améliorations qui aideront les clients à sécuriser leurs environnements DevOps », a conclu Wolfson.
Via : Le Registre (s’ouvre dans un nouvel onglet)