Cet article a eu en primo-inspiration mon sentiment qu’IT et Cyber travaillent malheureusement de manière trop souvent silotées. Avec des contraintes de sécurité souvent mal abordées ou insuffisamment partagées. Inspiration également au travers de rencontres de personnes travaillant dans le Cyber, qui peut-être se reconnaîtront.
En effet, la sécurité des API, côté IT, est souvent perçue comme un sujet couvert à partir du moment ou l’on gère bien l’authentification, les droits, et qu’on utilise une API Gateway. Oui bien sûr cela est nécessaire. Mais penser sécurité des API, au regard de ce que ce sujet implique, c’est penser un gros pan de la sécurité de son SI.
Ne venant pas du monde du Cyber, cet article n’aura comme seule prétention d’essayer de se faire rencontrer ces deux mondes. En abordant tous les aspects que la sécurité des API peut couvrir. Et évidemment, cet article est une invitation à vous rapprocher de vos équipes Cyber ! Et de vous fournir une liste de courses aussi synthétique que possible pour échanger entre équipes IT et Cyber. Mais un peu longue quand même. D’où le formalisme très concis choisi pour cet article.
Pour se faire, nous allons dans un premier temps expliciter les risques que nous identifions, pour ensuite aborder la sécurisation des API sur toute leur chaîne de valeur, du DevSecOps aux WAF d’API (WAAP pour Web Application and API Protection). Pour ensuite offrir un panorama de technologies, et enfin finir avec des préconisations. Sur ce, on y va !
Pourquoi la sécurité des API est-elle cruciale ?
Les données exposées sont très souvent sensibles : Les API renvoient souvent des données confidentielles, rendant leur protection indispensable.
C’est un vecteur d’attaque privilégié : En tant que point d’entrée unique des données, les APIs sont des points d’attaque de choix.
Leur complexité est croissante : L’évolution des architectures (microservices, coud, service mesh, …) peut augmenter la surface d’attaque potentielle.
Les API doivent respecter le cadre réglementaire : RGPD, PCI DSS, PSD2, etc…, autant de réglementations qui exigent une exposition sécurisée des API.
Cela n’arrive qu’aux autres? Et bien non.
2019. Facebook. Fuite de données concernant 540 millions d’utilisateurs à cause de serveurs non sécurisés et accessibles via des API.
2018. Twitter. Une mauvaise gestion des autorisations d’accès a rendu disponibles les messages privés de certains utilisateurs.
Maintenant que ces enjeux sont rappelés, nous allons détailler les risques et solutions.
Source : StartUp Stock Photo, Pexels
I. Les risques majeurs liés à la sécurité des API
1.1 Vulnérabilités courantes des API
1.1.1 Injection de code
L’injection de code est l’une des menaces les plus connues, avec
L’injection SQL par exemple,
Mais aussi par commandes avec l’exemple pas si ancien de la faille Log4J.
1.1.2 Authentification et autorisation inadéquates
Il est primordial d’avoir une politique d’authentification et d’autorisation bien appliquée afin de bloquer au mieux les attaquants. On peut retenir comme principes :
Les sessions doivent être bien gérées : Sessions non expirées ou mal révoquées.
Les tokens d’accès doivent être bien sécurisés : Stockage ou transmission non sécurisée des tokens.
Les contrôles d’accès doivent être bien configurés: Permissions mal configurées permettant des accès non autorisés.
1.1.3 Exposition de données sensibles
Les API peuvent involontairement exposer des données sensibles et inutiles si elles ne sont pas correctement définies, configurées ou sécurisées. Les cas typiques sont :
Les réponses API sont trop verbeuses : Inclusion de données non nécessaires dans les réponses.
Les réponses API ne sont pas chiffrées : Transmission de données en clair.
Les erreurs sont mal gérées : Messages d’erreur révélant des informations sensibles sur l’infrastructure.
1.2 Menaces émergentes et sophistiquées
1.2.1 Attaques par force brute et credential stuffing
Stratégie largement connue, consistant à tester des combinaisons de noms d’utilisateur et de mots de passe. Elles sont aussi simples à parer que particulièrement dangereuses car :
Elles peuvent être automatisées à grande échelle.
Elles peuvent aussi exploiter des informations d’identification provenant de fuites de données (évitez d’avoir un seul mot de passe…).
1.2.2 Attaques « Man-in-the-Middle » (MITM)
Une attaque MITM consiste à ce que l’attaquant se place entre le client et l’API Gateway pour intercepter ou modifier les échanges. Les risques incluent :
Le vol de données sensibles : En interceptant des données non chiffrées.
La manipulation de requêtes : En altérant des données échangées entre le client et le serveur.
L’usurpation d’identité : En récupérant les certificats serveurs pour se faire passer pour le serveur légitime.
1.2.3 Attaques DDoS
Ces attaques consistent à avoir un très grand nombre d’appels, afin de rendre indisponible l’API. Elles peuvent prendre plusieurs formes :
Les attaques volumétriques : En saturant la bande passante.
Les attaques au niveau applicatif : En utilisant des vulnérabilités de l’API pour épuiser les ressources du serveur.
Les attaques lentes : Cela consiste à maintenir des connexions ouvertes pour épuiser les ressources du serveur.
1.3 Risques spécifiques aux architectures modernes
1.3.1 Microservices et conteneurisation
La conteneurisation et les microservices ajoutent de nouveaux défis de sécurité :
La complexité exponentielle de la gestion des accès : On doit gérer les exigences de sécurité par microservice.
Les risques liés à l’orchestration des conteneurs : Les outils d’orchestration peuvent avoir aussi leurs propres vulnérabilités.
L’exposition accrue des API internes : Les API internes ne doivent absolument pas être exposées en externe !
1.3.2 API dans le cloud
Le déploiement d’API dans des environnements cloud présente des risques spécifiques :
La mauvaise configuration des services cloud : Exposition involontaire d’API ou de données.
La gestion des identités et des accès complexifiés : Il est nécessaire d’intégrer les mécanismes de sécurité de son cloud provider avec ceux de son API.
La dépendance vis-à-vis de la sécurité du fournisseur cloud : Il est nécessaire de comprendre et de compléter les mesures de sécurité, selon la politique de son cloud provider.
1.3.3 Shadow API et API zombies
Les « shadow API » (non documentées ou non gérées) et les « API zombies » (obsolètes mais toujours actives) représentent des risques significatifs :
Le manque de visibilité : Ce qui engendre des difficultés à identifier et à sécuriser ces API.
Les vulnérabilités non corrigées : Les API obsolètes peuvent contenir des failles de sécurité connues.
Les Accès non contrôlés : Il ya alors un risque d’exploitation par des attaquants sur des systèmes ou des données sensibles.
II. Stratégies et solutions pour sécuriser efficacement les API
2.1 Approche globale de la sécurité des API
2.1.1 Sécurisation de l’API via DevSecOps
L’approche DevSecOps permet de sécuriser une API en amont de son déploiement, via :
Le Shift-left security : Qui intègre les tests de sécurité dès le début.
L’automatisation des tests de sécurité : Grâce à des outils d’analyse de code statique (SAST) et dynamique (DAST).
La gestion continue des vulnérabilités : Code, librairies, dépendances, etc… Tous ces éléments peuvent faillir ou contenir des failles découvertes après coup. Il faut donc les détecter et les corriger.
2.1.2 Gouvernance et politiques de sécurité des API
Que serait-on sans gouvernance ? C’est évidemment un point primordial, sur lequel on sera particulièrement vigilant sur les aspects suivants :
La définition de standards de sécurité : Via documents de bonnes pratiques de développement et de déploiement d’API sécurisées.
La gestion des accès et des identités (IAM) : Pour couvrir la définition de politiques strictes pour l’authentification et l’autorisation.
Des audits réguliers : Afin d’évaluer de manière continue la conformité des API aux politiques de sécurité.
2.1.3 Formation et sensibilisation des équipes
La sécurité des API repose en grande partie sur les compétences et la vigilance de toutes les équipes, qu’elles soient devops, cyber ou dev :
Des programmes de formation : Via des sessions dédiées sur les pratiques de sécurité des API.
Des exercices pratiques : Via des simulations d’attaques et de réponses aux incidents.
Une culture de la sécurité : En encourageant à signaler et à résoudre les problèmes de sécurité.
2.2 Technologies et outils de sécurisation des API
2.2.1 API Gateways et Web Application and API Protection (WAAP)
Les API Gateways (et leurs cousins service mesh et micro-gateway) et les WAAP (WAF pour API, si vous préférez) représentent la première ligne de défense :
En filtrant du trafic : Via blocage des requêtes malveillantes.
En gérant les authentifications : En centralisant et en renforçant les mécanismes d’authentification.
En faisant du rate limiting : En protégeant contre les attaques DDoS.
Et en analysant le trafic : En détectant et en bloquant les comportements suspects.
2.2.2 Solutions de gestion et de protection des API
D’autres outils spécialisés existent, qui ont des fonctionnalités avancées pour la sécurité des API :
Solutions de découverte automatique des API : Afin de détecter les fameuses Shadow API.
Solutions d’analyse comportementale : Afin de détecter les anomalies et des comportements suspects.
Solutions de gestion des versions : Afin de contrôler et de sécuriser les différentes versions d’API.
Solutions de conformité réglementaire : Afin de démontrer la conformité aux règlements de sécurité.
2.2.3 Outils d’analyse de la sécurité des API
Des outils dédiées existent également pour déterminer des failles spécifiques aux API :
Les scanners de vulnérabilités spécifiques aux API : Comme son nom l’indique.
Les solutions de fuzzing d’API : Le fuzzing est une technique de test envoyant des données aléatoires et/ou malformées pour identifier les failles.
Outils d’analyse statique et dynamique : Il existe des SAST et DAST adaptés aux API.
2.3 Meilleures pratiques de sécurisation des API
2.3.1 Authentification et autorisation robustes
Via utilisation de protocoles standards : OAuth 2.0, OpenID Connect.
Via gestion fine des autorisations : Via implémentation du principe du moindre privilège, au travers des API scope.
Via rotation régulière des clés et tokens : Pour limiter l’impact en cas de compromission.
2.3.2 Centralisation et découpage des API Gateway
Une API Gateway est à placer idéalement de manière centrale dans son architecture pour ne pas multiplier les points d’entrée. On peut néanmoins avoir deux API Gateway, une “publique” et une autre “privée” afin de mitiger les risques au mieux :
Point d’entrée unique : Centralisation du trafic API pour une meilleure visibilité et un contrôle accru.
Gestion des versions : Facilitation de la gestion des différentes versions d’API.
Transformation et médiation : Adaptation des requêtes et des réponses pour assurer la compatibilité et la sécurité.
2.3.3 Chiffrement et protection des données
Chiffrement en transit : En utilisant systématiquement le TLS (dans une version non dépréciée). Possiblement aussi signer les données échangées, comme le peut faire Stripe avec son API afin de garantir leur authenticité, intégrité et non-répudiation.
Chiffrement des données sensibles : Que ce soit des données au repos ou en transit.
Gestion sécurisée des clés : En gérant les clés de chiffrement tout au long de leur cycle de vie. Il s’agit notamment de :
l’utilisation de clés solides, générées de manière aléatoire.
la rotation régulière des clés afin de limiter l’impact des violations potentielles.
stocker les clés en toute sécurité dans des “Vault”, séparément des données qu’elles protègent.
mettre en place des contrôles d’accès.
gérer les identités numériques via des certificats grâce à une PKI, couplé à
un HSM pour sécuriser des clés cryptographiques dans un environnement matériel.
2.3.4 Gestion des logs et audit
La journalisation : En enregistrant tous les événements liés à la sécurité.
La conservation des logs : En conservant les logs pendant une période suffisante pour permettre des analyses dans le passé.
L’analyse régulière des logs : En mettant en place des processus d’analyse régulière des logs.
La protection des logs : En empêchant toute modification non autorisée pour garantir leur intégrité en cas d’audit.
2.3.5 Surveillance en temps réel
L’analyse comportementale : Pour détecter les anomalies dans le trafic API.
Les alertes en temps réel : Pour réagir rapidement aux incidents de sécurité.
Le monitoring continu : Pour surveiller en permanence la disponibilité des API et détecter rapidement les attaques.
2.3.6 Tests de pénétration et validation de la sécurité
Des tests réguliers.
Des scénarios réalistes qui s’inspirent de cas réels.
Une validation continue via la chaîne CI/CD.
Conclusion
Comme on peut le voir, la sécurité des API demandent des compétences dans diverses équipes, mais également un engagement de tous. Des solutions informatiques existent, mais elles ne sont rien sans une politique de sécurité partagée à tous et pour tous. Et aussi et surtout l’établissement des bonnes pratiques définies en interne, comme nous l’avons partagées dans cet article.
J’ai pu constater régulièrement que beaucoup de gens s’emmêlent les pinceaux quand il est question de définir et d’expliquer les différences entre Service Mesh, Event Mesh et Data Mesh.
Ces trois concepts, au-delà de l’utilisation du mot “Mesh”, n’ont pas grand chose de semblable. Quand d’un côté, nous avons :
Le Service Mesh qui est un pattern technique pour les microservices, qui se matérialise par la mise en place d’une plateforme qui aide les applications en ligne à mieux communiquer entre elles de manière fiable, sécurisée et efficace
L’Event Mesh, qui est un pattern technique d’échanges, afin de désiloter les différentes technologies de messaging
Et le Data Mesh qui lui, est un pattern général d’architecture de données, qui se matérialise par toute une série d’outils à mettre en place, et qui pousse le sujet de la productification de la donnée
On se dit déjà que comparer ces trois patterns ne fait pas sens ! Néanmoins, il y a peut-être un petit quelque chose, une évidence naturelle, qui peut découler de la comparaison.
Mais commençons donc d’abord par présenter nos trois protagonistes !
Le Service Mesh, ou la re-centralisation des fonctions régaliennes des microservices
Historiquement, l’approche microservice a été motivée, entre autres, par cette passion que nous autres informaticiens avons souvent, pour la décentralisation. Adieu horrible monolithe qui centralise tout, avec autant d’impacts que de nouvelles lignes de code, impossible à scaler en fonction des besoins fonctionnels réels. Sans compter qu’on peut quasiment avoir autant d’équipes de développement que de microservices ! A nous la scalabilité organisationnelle !
Cela a abouti, de manière simplifiée bien sûr, au schéma suivant :
Chaque microservice discute avec le micro service de son choix, indépendamment de toute considération. La liberté en somme ! Mais en y regardant de plus près, on voit bien une sous-brique qui est TRÈS commune à tous les microservices, ce que j’appelle ici la “Technical Logic”. Cette partie commune s’occupe des points suivants :
La découverte de services
La gestion du trafic
La gestion de tolérance aux pannes
La sécurité
Or quel intérêt à “exploser” cette partie en autant de microservices développés? Ne serait-ce pas plutôt une horreur à gérer en cas de mise à jour de cette partie? Et nous, les microserviciens (désolé pour le néologisme…), ne serions nous pas contradictoire dans nos souhaits de décentralisation? Oui! Car autant avoir une/des équipes dédiées à cette partie, qui travaillerait un peu de manière décentralisée, mais tout en centralisant sur elle-même ce point?
C’est ainsi qu’est apparu le pattern de Service Mesh, décrit dans le schéma suivant :
Dans ce pattern, les fonctions techniques sont définies de manière centralisée (Control Plane), mais déployées de manière décentralisée (Data Plane) afin de toujours plus découpler au final son architecture. Et cela se matérialise par des plateformes comme Consul ou Istio, mais aussi tout un tas d’autres plus ou moins compatibles avec votre clouder, voire propres à votre clouder.
Maintenant que nous avons apporté un premier niveau de définition pour le service mesh, allons donc voir du côté de l’Event Mesh !
L’Event Mesh, ou la re-centralisation pour désiloter
L’histoire informatique a eu l’occasion de voir tout un ensemble de solutions de messaging différentes, avec des origines différentes. Qu’on retourne à l’époque des mainframes, ou qu’on regarde de côté des technologies comme Kafka qui ont “nourri” les plateformes Big Data, les solutions se sont multipliées. Et c’est sans compter le fait de faire du messaging par dessus du http!
On obtient donc assez facilement des silos applicatifs qui sont freinés dans leur capacité à échanger, comme montré sur le schéma suivant :
Certes, les solutions de bridge existaient, mais elles permettaient souvent de faire le pont entre seulement deux technologies en même temps, le tout avec des difficultés à la configuration et l’exploitation.
Et si on rajoute le fait qu’un certain nombre d’entreprises se sont dit qu’il serait intéressant d’utiliser les technologies propriétaires de chacun de leurs clouders, on imagine bien les difficultés auxquelles elles font face.
Est donc apparu le pattern Event Mesh, imaginé entre autre, implémenté et popularisé par l’éditeur Solace, qui permet de centraliser sur une solution unique, capable entre autres d’avoir des “agents” locaux aux SI (selon la zone réseau, le datacenter, le clouder, le domaine métier, etc…). Digression mise à part, on notera que le terme Event Mesh a été repris aussi bien par le Gartner que par des solutions open-source.
Indépendamment des architectures de déploiement, cela nous donne l’architecture simplifiée suivante :
Son intérêt vient qu’on peut ainsi relier tout le monde, y compris du Kafka avec du JMS, ou avec des API.
Le Data Mesh, décentralisation ou relocalisation des compétences ?
Le Data Mesh, de son côté, vient de son côté en réaction d’une précédente architecture très centralisée, faite de Data Lake, de Datawarehouse, de compétences BI, d’intégration via ETL ou messaging, le tout géré de manière très centralisée.
En effet, il était coutume de dire que c’est à une même équipe de gérer tous ces points, faisant d’eux des spécialistes de la data certes, mais surtout des grands généralistes de la connaissance de la data. Comment faire pour être un expert de la donnée client, de la donnée RH, de la donnée logistique, tout en étant un expert aussi en BI et en intégration de la donnée?
Ce paradigme d’une culture centralisatrice, a du coup amené un certain nombre de grosses équipes Data à splitter leur compétences, créant toujours plus de silos de compétences. De l’autre côté, les petites équipes pouvaient devenir très tributaires des connaissances des sachants métiers. Si cela vous rappelle les affres de la bureaucratie, ce serait évidemment pur hasard!
Ci-joint une représentation simplifiée de l’architecture dont nous avons pu hériter :
C’est ainsi qu’est apparu le pattern Data Mesh. Dans ce pattern, ce sont aux équipes Domaine de :
Collecter, stocker, qualifier et distribuer les données
Productifier la donnée pour qu’elle ait du sens à tous
Fédérer les données
Exposer des données de manière normée
Ce qui impose en l’occurrence de :
Mettre en place un self-service de données
Participer activement à la gouvernance globale
Et d’avoir un nouveau rôle de Data Engineer, qui doit mettre en place la plateforme de données pour justement faciliter techniquement, et proposer des outils.
Nous avons donc en schéma d’architecture le suivant :
Mais alors quid des points communs ?
Et en réalité, le gros point commun de ces trois patterns, c’est leur histoire !
Les trois proviennent de cette même logique centralisatrice, et les trois cherchent à éviter les affres d’une décentralisation dogmatique. A quoi cela sert de décentraliser ce que tout le monde doit faire, qui est compliqué, et qui en vrai n’intéresse pas tout le monde?
Et à quoi cela sert de forcément tout vouloir centraliser, alors même que les compétences/appétences/expertises/spécialisations sont elles-même “explosées” en plusieurs personnes ?
Certes, la centralisation peut avoir comme intérêt de mettre tout le monde autour de la même table, ce qui peut être intéressant pour de gros projets qui ne vivront pas, ou quand on est dans des phases d’une maturité exploratoire…
Et cela pousse tout un ensemble de principes, dont entre autre (liste non exhaustive):
Découvrabilité : Il faut pouvoir retrouver les services et les données simplement, en les exposants via des « registry » dédiés simples d’accès
Flexibilité et évolutivité : Il faut qu’une modification dans l’infrastructure ou dans un domaine puisse être accueilli sans douleur
Sécurité : Les politiques de sécurité sont propres aux champs d’actions de ces patterns, et sont donc inclus dans ces patterns
Distribution et autonomie : On distribue les responsabilités, les droits et les devoirs, afin de construire un système robuste organisationnellement
Alors oui, je vous entend marmonner “Et oui, c’est toujours la même chose! C’est comme ça”.
Mais en fait pas forcément ! En ayant en tête :
Ces éternels mouvements de yoyo,
Le Domain Driven Design qui est aussi un point commun au Data Mesh et à l’Event Mesh,
Cet article est le troisième d’une série présentant les évolutions des rôles des différents architectes dans la nouvelle version 6 du framework SAFe.
Après avoir étudié le System Architect et le Solution Architect, rencontrons l’Enterprise Architect ! Avant de rentrer dans le vif du sujet, nous souhaitions vous faire part de nos impressions quant aux évolutions du rôle de l’Enterprise Architect.
Dans les versions précédentes, le rôle de l’architecte d’entreprise n’était pas très détaillé. Il était clair que celui-ci intervenait dans la définition de la stratégie et aidait à mettre en adéquation les évolutions du système d’information avec celles du métier de l’entreprise, mais cela s’arrêtait là.
Dans cette nouvelle version, le framework contient beaucoup plus de détails sur les responsabilités de l’architecte d’entreprise. Celui-ci gagne ses lettres de noblesse et récupère dans sa bannette des sujets qu’il aurait toujours dû avoir (par exemple la rationalisation du portefeuille technologique). Son rôle n’est plus dans la pure stratégie décorrélée du terrain, il devient plus concret.
En revanche, il a aussi tout un lot d’activités nouvelles, que nous détaillerons dans la suite, et qui nous font dire qu’il faut avoir les épaules très larges pour occuper ce poste. L’architecte d’entreprise semble être partout à la fois, il est devenu une sorte de couteau-suisse ou d’architecte tout terrain si vous me passez l’expression.
Serait-il devenu l’architecte de l’entreprise ? Celui qui cumule bon nombre de responsabilités et qui collabore très largement avec l’ensemble de l’entreprise ? C’est ce que nous allons découvrir dans la suite !
De nouvelles responsabilités : De la définition de la stratégie, aux mains dans le code.
L’entreprise Architect s’est ainsi beaucoup musclé au passage de la version 5 vers la version 6 du framework Safe. Il est certes toujours responsable, au mot près, de la stratégie. Mais d’un rôle de facilitateur semi-passif (« Collaborating », « Assisting », « Helping », « Participating », etc…), il bascule vers un rôle de prescripteur. Un regard critique dirait qu’il retrouve ses prérogatives naturelles… Ainsi les différents (et nouveaux) rôles définis par le framework Safe sont :
Aligning Business and Technical Strategies
Coeur de métier de l’entreprise architect, son rôle est avant tout d’aligner l’architecture avec la stratégie IT, le tout en partageant ainsi sa vision et la stratégie business. Il identifie également les value streams à mettre en place, entretient ses relations avec les différentes équipes et va même jusqu’à participer aux démos.
Establish the Portfolio’s Intentional Architecture
Il s’agit là de définir une architecture cible avec des technologies cibles, des patterns d’architecture, le tout en synchronisant toutes les équipes ensemble. Fait marquant, l’apparition de la démarche inverse de Conway, consistant à définir une architecture, puis à calquer l’organisation sur cette architecture. Le contraire de ce qui est fait en général somme toute. L’architecte d’entreprise devient donc le responsable de la définition de l’organisation des équipes, ce qui en soit est un gros shift!
Rationalizing the Technology Portfolio
Le grand classique de l’architecture d’entreprise. On mutualise, on réduit les coûts, on réduit la complexité, etc…
Fostering Innovative Ideas and Technologies
Le titre est presque trompeur. Il s’agit surtout de permettre d’avoir un environnement technologique moderne et “propre”, en supprimant les technologies obsolètes, apporter du support aux environnements de développements, mais aussi en alignant les choix technologiques avec les business models pressentis.
Guiding Enabler Epics
Il est epic owner sur les initiatives d’architecture, et participe aux réunions safe pour s’assurer du bon alignement des équipes.
L’architecte d’entreprise reprend donc son rôle d’architecte d’entreprise, du métier aux développeurs, en passant par l’organisation des équipes. Par contre, son rôle est beaucoup plus étendu que dans la version 5, se retrouvant ainsi au milieu de nombreux acteurs.
Un accent mis sur la collaboration : D’une tour d’ivoire à un lean-agile leader
En effet, dans la version précédente de Safe, l’architecte d’entreprise était vu comme gravitant surtout dans les hautes sphères et ne collaborait qu’avec les autres architectes et des acteurs de haut niveau ou très transverses (Lean Portfolio Management, Agile Program Management Office, et le Lean-Agile Center of Excellence par exemple).
Il était supposé maintenir des relations avec les personnes de chaque Train mais ses activités quotidiennes ne s’y prêtaient guère. A présent que son périmètre s’étend considérablement, il sera amené à croiser des acteurs beaucoup plus nombreux. Il intervient comme proxy des acteurs business et doit être capable de porter la vision et la stratégie business auprès des différentes parties prenantes.
Il participe également à tous les événements en lien avec les enablers epics et aura donc l’occasion d’interagir avec les acteurs opérationnels des différents Trains.
Ses responsabilités étant également plus distinctes de celles des autres architectes, leur complémentarité est d’autant plus mise en évidence. Une collaboration efficace entre l’Entreprise Architect, le Solution Architect et le System Architect garantit l’alignement.
Enfin, l’Entreprise Architect doit incarner le Lead Agile Leader par excellence. Il mentore les équipes agiles, contribue à la mise en place de nouveaux modes de fonctionnement, et montre l’exemple en continuant à apprendre et à évoluer. Une forme de super héros inspirant tout le monde sur son passage, facile non ?
Si ces sujets vous intéressent…
Pour plus d’informations sur ces sujets et sur le rôle d’architecte dans un environnement agile, n’hésitez pas à aller voir notre série d’articles sur l’architecture et l’agilité.
Les articles 4 et 6 peuvent en particulier se révéler utiles :
Dans l’article 6, intitulé “Les 7 formations de l’Architecte Agile”, nous avions évoqué le besoin de formation SAFE pour l’architecte, et nous avions également parlé de la posture de coach de l’architecte via la process communication et la PNL.
Parmi la littérature conseillée par le framework Safe, on ne peut que vous conseiller le fameux livre “Team Topologies” qui évoque le rapprochement des équipes technologies et business :
La question peut paraître saugrenue, car nous sommes habitués à dire que ce sont les chinois qui nous copient, et qu’en termes de libertés individuelles la Chine n’est pas nécessairement un modèle souhaité en France. Néanmoins, la Chine pense sur le temps long, avec une accumulation de plans quinquennaux qui au final peuvent s’étaler sur plus de 10 ans. Et le sujet de leur souveraineté numérique au sens large en fait clairement partie.
Pour revenir au sujet du cloud souverain, il est clairement d’actualité, avec l’amendement du député Philippe Latombe qui a été accepté, obligeant les opérateurs d’importance vitale pour la France à utiliser du cloud souverain plutôt que non souverain.
Mais avant de se comparer à la Chine, revenons aux basiques en retournant à l’étymologie du mot « souveraineté ».
Source : Pexels – Kevin Paster
La souveraineté, une proposition de définition.
Étymologiquement, et dans son sens premier, est souverain celui qui est au-dessus, qui est d’une autorité suprême.
Cela s’applique ainsi logiquement à un État, qui lui-même est chargé de défendre les intérêts français, que l’on parle de citoyens mais aussi d’entreprises. Citoyens, qui expriment leur souveraineté populaire (au sens rousseauiste du terme) dans le cadre d’élections.
Mais appliquons cela à ce qu’on entend alors par “cloud souverain”.
Ainsi, en déclinant cette idée de souveraineté au cloud, dont les clients potentiels sont l’état, les entreprises, les individus, il s’agit de placer l’état en garant des intérêts des citoyens et des entreprises, qui se mettent sous la coupe des lois françaises, lois assumés par tous par le mécanisme de souveraineté populaire.
Source : Pixabay – The DigitalArtist
Le cloud souverain, une proposition de liste de principes.
Dis comme ça, cela reste flou. Alors soyons plus pratico-pratiques :
Ni l’état, ni les entreprises, ni les citoyens ne souhaitent se faire espionner par une force étrangère, ou par des intérêts privés. Bonjour Edward Snowden.
Tout le monde souhaite que ses données privées, le restent. Bonjour les GAFAM. Bonjour Edward Snowden.
L’état, les citoyens, les entreprises souhaitent que les comportements délictueux exercés en France soient jugés en France. Bonjour les GAFAM. Bonjour Edward Snowden. Bonjour l’état de droit.
L’état, les citoyens, les entreprises souhaitent pouvoir avoir un accès sans soucis à un cloud sécurisé. Bonjour la liberté.
Une réalité éloignée de ces principes
Or, un certain nombre de points ne correspondent pas avec les acteurs étrangers.
Espionnage : Le Patriot act et le FISA, sont très clairs à ce sujet. Si votre clouder est américain, le piratage est légal et assumé. J’omets le Cloud Act, qui à mes yeux relève du « blanchiment » juridique.
Confidentialité : De même, les données considérées comme “privées” peuvent ainsi être récupérées. Sans compter les cookies traceurs et https://www.lebigdata.fr/donnees-anonymes-cnil-data-brokers). Et si vous ajoutez le fait que les protocoles “Internet” qui n’ont pas été créés comme sécurisés. Des palliatifs existent comme par exemple pour le protocole DNS (Protocoles DOH et DOT, DnsCrypt). Néanmoins, l’utilisation de HTTPS ne vous cache pas. Si vous allez sur https://siteinavouable.com, l’information que vous vous y connecter passe en clair, lors du handshake SSL. Il faudrait pour éviter cela que l’extension TLS d’”Encrypted Client Hello” soit généralisée.
Souveraineté aux yeux de la loi : L’extra territorialité des lois américaines n’est plus à prouver. Demandez à Frédéric Pierucci son avis.
Sécurisation : Et si nous passons tous par des routeurs fabriqués par des entreprises américaines, avec des ordinateurs utilisant des processeurs américains, avec un bios contenant des binaires américains pour les craintes, et pour un premier aperçu des possibilités, et le tout sur un système d’exploitation américain, la probabilité que des failles et autres backdoors “connues” seulement des américains existent n’est pas nulle. Et passons sur le simple fait que le trafic internet de votre tante vivant à Nice, se connectant à un site web hébergé à Strasbourg, ne va pas nécessairement longer les frontières françaises tel le nuage de Tchernobyl, laissant ainsi des « portes » d’écoute.
Alors quelle est la réponse de la Chine face à ces enjeux?
Espionnage : Mise en place d’un Great Firewall, perfectible par rapport à ses objectifs mais qui ne facilite pas le travail d’un espion étranger. Ecosystème “Chinese Only”, où aucune société américaine n’opère directement en chine (Voir Salesforce, Azure, Aws), mais par des intermédiaires 100% chinois.
Confidentialité : Pas le soucis majeur des chinois. Vous n’avez rien à cacher à l’état chinois, pas même vos secrets intimes.
Souveraineté aux yeux de la loi : Le fait de devoir passer par un intermédiaire chinois bloque les lois extra-territoriales américaines. Par exemple la société chinoise 21Vianet achète les “logiciels Azure” de Microsoft, pour après revendre de l’Azure en chine. Et comme dans la pratique l’état chinois a accès à tous les serveurs, c’est tout de suite plus pratique pour faire appliquerdes lois, et un “REX” extra-territorial sur TikTok : REX que votre serviteur avait précédemment pressenti.
Sécurisation : Le great firewall aide, transforme l’Internet Chinois en un quasi Intranet, mais n’est pas le seul vecteur de sécurisation. Comme énuméré précédemment, les vecteurs d’attaques sont :
Système d’exploitation : Diverses distributions linux chinoises, existence d’un linux fait par alibaba cloud
Serveur : Lenovo qu’on ne présente plus. De toute manière les fabricants étrangers ne sont pas les bienvenus.
Une utopie réaliste
Par rapport à cette liste à la Prévert, je n’invite pas à restreindre les libertés publiques mais à avoir une politique numérique très ambitieuse. Impossible n’est pas français comme je l’entendais dire dans ma jeunesse, et oui, un autre modèle est imaginable :
Espionnage : Renforcement très fort de l’ANSSI, pour aider encore plus les entreprises à se sécuriser, mais aussi pour sensibiliser. Promotion voir obligation d’utilisation de protocoles et de systèmes sécurisés, Travaux de recherche pour une sécurisation pour tous. Sécurisation des réseaux, y compris télécom afin d’éviter d’être géo-localisable par n’importe quelle agence étatique
Confidentialité : Interdiction des cookies traceurs. Généralisation des protocoles sécurisés. Amendes plus fortes et prisons en cas de négligence de confidentialité, voir de sécurité
Souveraineté aux yeux de la loi : Promotion du SecNumCloud et challenge perpétuelle de sa définition (ce qui est déjà le cas au vu des versions). Aides aux entreprises souhaitant passer la certification. Obligation pour l’état et les organismes d’importance vitales de passer par des clouders de droit et d’actionnariat français (bonjour les OIV)
Sécurisation :
Réseau : Promotion des acteurs français comme Stormshield, certifications de sécurité pour les acteurs qui communiquent leurs codes sources qui seront audités
Processeurs :
Fabrication dans un premier temps de processeurs sous license ARM (contenant quand même des brevets américains https://www.phonandroid.com/huawei-annonce-son-independance-aux-technologies-americaines-pour-2021.html) par une entreprise de droit français ou européen (ST MicroElectronics)
Travaux de recherche sur les plateformes Open Source RISC-V et Open Power et fonds d’investissement pour des startups
Système d’exploitation : Promotion et investissement sur la distribution linux française CLIP-OS, développé par l’ANSSI
Serveur : En soit un serveur consiste en une simple intégration de composants, qu’OVH fait lui même. Concernant le bios, avec un processeur français le problème sera directement résolu. Enfin concevoir des cartes mères n’est pas la chose la plus complexe (Si un ingénieur est capable d’en concevoir en solo…
Plus qu’un cloud souverain, un Internet de la confiance
Comme on peut le voir, je prends le contre pied de la Chine sur la vie privée et la confidentialité, et je cherche à démontrer que l’effort technologique n’est pas un mur infranchissable.
L’effort pour les DSI, RSSI, architectes, consiste à sensibiliser, mais aussi à promouvoir l’usage de solutions et de clouders certifiés secNumCloud, qui soient bien de droit français. La liste est régulièrement mise à jour.
Et oui, il faut « franciser » son SI. Et/où l' »open-sourcer ».
Sur le sujet de la sécurisation pour tous, être contre c’est être pour que n’importe qui dans la vie réelle puisse écouter ce que vous dites. On me rétorquera que la collecte d’adresse IP est nécessaire pour la lutte contre le harcèlement en ligne par exemple… Alors renforçons les pouvoirs et les moyens de la CNIL. Exigeons de nouvelles certifications plus sévères et plus contraignantes. Ce sujet de collecte d’ip pour des crimes graves (https://twitter.com/laquadrature/status/1658012087447085056) peut être la limite acceptable et contrôlable de notre vie privée et de notre sécurité. Car être contre notre sécurité et notre vie privée c’est être contre la protection de nos intérêts vitaux et économiques (https://twitter.com/amnestyfrance/status/1658449051296186369). La liberté individuelle et la liberté d’entreprendre sont ici parfaitement compatibles, elles vont même de pair. Croire l’inverse, c’est laisser la porte ouverte à tous vents, aux inconnus, aux belligérants. Et nous devons tous comprendre qu’il en va de l’intérêt général.
