Il y a au moins trois bonnes réponses, et quelques-unes qui le sont moins.
La stratégie, en particulier dans le domaine des technologies, relève souvent de la responsabilité des dirigeants. Lorsqu’il s’agit de stratégies liées à la sécurité, cette responsabilité incombe généralement au RSSI ou, si ce poste n’existe pas, au DSI.
Mais certaines organisations délèguent à d’autres fonctions la responsabilité de piloter les stratégies de sécurité des API. Les développeurs, les SRE et même les professionnels des réseaux peuvent aujourd’hui être chargés de définir la stratégie de sécurisation des API.
Cela tient peut-être au fait qu’aucune étude sérieuse n’a été menée sur les conséquences possibles de ces décisions. Après tout, il existe de bonnes raisons de confier aux développeurs le pilotage d’une stratégie de sécurité des API, tout comme il est légitime d’en faire porter la responsabilité à toutes les personnes susceptibles d’intervenir d’une manière ou d’une autre sur une API, que ce soit lors du développement, des tests ou de la mise en production.
Dans le cadre de notre récente étude approfondie sur la sécurité des API, nous avons demandé à chacun des répondants — tous décisionnaires en matière de sécurité des API — quels rôles étaient chargés de piloter la stratégie de sécurité des API au sein de leur organisation. Les réponses étaient variées, allant des développeurs aux professionnels des réseaux, en passant par des approches transversales à l’ensemble de l’organisation.
Mais nous avons également posé des questions très précises sur les types de services de sécurité utilisés par les organisations pour sécuriser les API. Il s’agit notamment de services de protection contre les attaques DDoS, de contrôle d’accès, de mTLS et de SSL. Nous avons considéré le déploiement de ces services comme une illustration concrète de la mise en œuvre de la stratégie, car ils font partie des contrôles nécessaires pour appliquer les politiques découlant d’une stratégie de sécurité. Nous avons ensuite examiné lesquels de ces services étaient déployés en fonction des personnes chargées de piloter la stratégie de sécurité des API.
Pour être tout à fait francs, les résultats nous ont stupéfaits.

Il s’avère que l’éventail de services le plus complet a été déployé lorsque la stratégie de sécurité des API relevait d’une responsabilité transverse à l’ensemble de l’organisation, suivie de près par l’organisation chargée de la sécurité au sens large et par la direction des systèmes d’information et de la sécurité des systèmes d’information (DSI/RSSI).
Plus préoccupant encore, lorsque les SRE pilotent la stratégie de sécurité, la sécurité des API n’est intégrée qu’à partir de la phase de test du cycle de vie des API. Lorsque la stratégie de sécurité des API est confiée à d’autres équipes, son intégration commence généralement dès la phase de conception ou de développement. Même lorsque les équipes réseau pilotent cette stratégie, elles indiquent que la sécurité des API doit être intégrée lors de la phase de développement.
La bonne nouvelle, c’est que la plupart des organisations confient la définition de leur stratégie de sécurité des API à l’une de ces trois équipes. Seules 8 % d’entre elles délèguent cette responsabilité aux développeurs, moins encore (3 %) aux professionnels des réseaux, et à peine 1 % aux SRE.
Cela correspond étroitement au domaine auquel la sécurité des API est rattachée. En effet, cette décision dépend en grande partie de l’entité qui pilote la stratégie. Lorsque la stratégie de sécurité des API est pilotée par la direction informatique ou la direction de la sécurité des systèmes d’information (DSI/RSSI), ou qu’elle est considérée comme transverse à l’organisation, la sécurité des API se répartit généralement entre quatre domaines : la gestion des API, la sécurité des applications, le réseau et la sécurité hors sécurité des applications. Cela paraît logique, puisque les services qui assurent la défense et la protection des API peuvent couvrir plusieurs domaines.
Ainsi, si votre organisation confie la stratégie de sécurité des API à la direction informatique ou à la direction de la sécurité des systèmes d’information (DSI/RSSI), à l’équipe Sécurité, ou si elle considère qu’il s’agit d’une responsabilité transverse, félicitations ! Votre approche stratégique permet de mettre en place des contrôles de sécurité complets grâce à des services de sécurité qui défendent et protègent les API contre une grande variété d’attaques.
Vous pouvez approfondir encore davantage les secrets de la vie des API en lisant notre communiqué de presse du jour et en téléchargeant notre dernier rapport. Vous y découvrirez d’autres statistiques inquiétantes, mais aussi davantage d’informations sur la manière dont les API sont réellement utilisées au sein des entreprises, ainsi que sur les fonctionnalités de sécurité que les organisations jugent importantes pour protéger leurs API.
À propos de l’auteur

Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.
Autres articles de Lori Mac VittieArticles de blog associés

Pourquoi devriez-vous vous intéresser à WebAssembly ?
WebAssembly (Wasm) est un jeu d’instructions binaires portable, rapide et sécurisé, qui permet d’exécuter des applications hautes performances sur n’importe quelle plateforme.
Trois choses à savoir sur les applications d’IA
Les applications d’IA sont des applications modernes, mais elles présentent certaines particularités. Découvrez les points essentiels à connaître sur les applications basées sur l’IA.
État des lieux de la stratégie applicative 2022 : il est temps de moderniser les opérations
Il est devenu évident que, pour maintenir la dynamique de leur transformation numérique, les organisations doivent recentrer leurs efforts sur les fonctions métier. Si les expériences destinées aux clients restent prioritaires, il est également indispensable de permettre la numérisation de fonctions telles que les services juridiques, les ressources humaines et la finance. Les DSI prennent donc les commandes, tandis que la transformation numérique passe de la modernisation des applications à celle des opérations.
Clouds multiples ou multicloud : faciliter la transition
La gestion et la sécurisation des charges de travail deviennent complexes à mesure que les entreprises adoptent une stratégie de cloud connecté. Découvrez comment F5 répond au besoin d’une nouvelle approche de la mise en réseau multicloud.
L’expérience client dépend de la visibilité
Une enquête menée par Dimensional Research auprès de plus de 3 000 utilisateurs d’applications mobiles a confirmé ce que beaucoup d’entre nous pensent des attentes actuelles des clients.
Transformation numérique et explosion du portefeuille d’applications
La transformation numérique stimule la croissance des portefeuilles d’applications et modifie la manière dont celles-ci sont développées, déployées, intégrées et, en définitive, utilisées.