- Speaker #0
Bonjour mamie ! Bonjour et bienvenue dans la cybersécurité expliquée à ma grand-mère, le podcast pour expliquer la cybersécurité à des gens qui n'y comprennent rien. Sébastien de Vauban, né en 1633 et mort en 1707, était l'architecte et l'ingénieur militaire de Louis XIV. Il a révolutionné l'art des fortifications en inventant le principe de l'échelonnement dans la profondeur. Avant Vauban, une fortenesse imprenable se définissait par d'épais murs dessinant une frontière nette entre le dehors et le dedans. C'était la défense périmétrique. Mais l'invention du canon et du boulet métallique a tout changé. Ces boulets pouvaient faire tomber n'importe quelle épaisseur de mur. Vauban a alors révolutionné l'architecture militaire. Les fortifications ne reposaient plus sur la hauteur, mais sur la profondeur et l'horizontalité du dispositif. Pour amortir l'effet déboulé, il a créé d'épais remparts de terre revêtus de pierre, avec des bastions pentagonaux remplaçant les tours vulnérables. Vauban ne cherchait pas à construire des fortenesses imprenables. Il savait qu'une place assiégée finit toujours par tomber. Son objectif était d'organiser la défense de façon à ce que l'offensive coûte à l'ennemi un prix prohibitif. Il a conçu un réseau de fortifications se soutenant mutuellement, obligeant l'ennemi à mener une attaque dont le coût en hommes et en moyens était hors d'atteinte des puissances européennes. Vous l'avez compris, c'est exactement la même problématique à laquelle nous devons faire face pour rendre résilients nos systèmes d'information. Concrètement, comment concevoir des systèmes résilients face aux menaces ? Quels sont les principaux fondamentaux à respecter ? C'est ce que nous allons découvrir ensemble. C'est un sujet que nous avons déjà abordé dans l'épisode Inception, mais aujourd'hui nous allons plus dans le détail. Pour comprendre pourquoi la sécurité doit être intégrée dès la conception, faisons un voyage dans le temps. Dans les années 90 et au début des années 2000, l'informatique d'entreprise était relativement simple. On avait des serveurs dans un data center, des postes de travail connectés au réseau, et un pare-feu à l'entrée. La sécurité était souvent perçue comme une contrainte, quelque chose qu'on ajoutait une fois que l'application fonctionnait. C'était l'époque de « on développe d'abord et on sécurise ensuite » . Cette approche, qu'on pourrait appeler la sécurité périmétrique traditionnelle, reposait sur une idée simple, créer une forteresse avec des murs épais et un pont-levis. Ce qui était à l'intérieur était considéré comme sûr, tout ce qui était à l'extérieur était suspect. On installait donc un pare-feu performant, un antivirus sur chaque poste, et on pensait, la main sur le cœur, avoir fait le nécessaire. La sécurité était vue comme un produit qu'on achetait, qu'on installe, Un peu comme une alarme qu'on pose dans une maison déjà construite. Mais le monde a changé. Il a changé de manière radicale. Plusieurs révolutions technologiques sont venues bouleverser ce modèle simple et rassurant. Et le dernier en date est l'utilisation massive de l'IA par les attaquants. Mais quels sont les problèmes auxquels nous devons faire face ? Premièrement, l'explosion de la connectivité. Nous ne sommes plus dans un monde où quelques serveurs communiquent entre eux dans un réseau fermé. Aujourd'hui, une application d'entreprise moyenne peut faire appel à des dizaines d'APIs externes Se connecter à des services cloud, communiquer avec des partenaires via des plateformes d'échange et être accessible depuis n'importe quel point du globe. Le périmètre s'est dissous. Il n'y a plus vraiment d'intérieur et d'extérieur. Vos employés travaillent depuis des cafés, des aéroports. Vos données ne sont plus seulement dans votre data center. Elles sont répliquées dans trois régions de cloud différentes. Vos applications ne tournent plus sur des serveurs physiques que vous pouvez toucher, mais dans des containers éphémères qui apparaissent et disparaissent selon la charge. Deuxièmement, la sophistication des attaques. Les cybercriminels d'aujourd'hui n'ont plus rien à voir avec le hacker solitaire dans sa chambre qu'on imaginait autrefois. Nous parlons désormais d'organisations criminelles structurées, parfois soutenues par des États, avec des budgets de plusieurs millions d'euros et des équipes spécialisées. Si le sujet vous intéresse, je vous conseille la lecture du dernier rapport de l'ENISA sur l'état des menaces en Europe. Je vous laisse le lien dans la description de cet épisode. Aujourd'hui, les groupes de pirates ont le temps... les ressources et les expertises nécessaires pour étudier votre architecture, identifier les faiblesses et mener des attaques ciblées et persistantes sur plusieurs mois. Ils ne cherchent pas seulement à exploiter une vulnérabilité connue dans un logiciel. Ils analysent la façon dont vos systèmes sont conçus, comment ils comiquent entre eux, quelles sont les hypothèses d'architecture que vous avez faites et qui pourraient être exploitées. Troisièmement, la complexité exponentielle des systèmes. Une application moderne n'est pas qu'un bloc monolithique. C'est un écosystème complexe composé de dizaines, parfois de centaines de microservices utilisant des bases de données variées, des fils de messages, des systèmes d'orchestration et j'en passe. Chaque composant, chaque connexion, chaque point d'intégration est une surface d'attaque potentielle. Si vous n'avez pas pensé à la sécurité lors de la conception de cette architecture, vous vous trouvez avec des milliers de points de vulnérabilité potentiels. Prenons un exemple concret pour illustrer le coût de l'approche qu'on sécurise après. Imaginons une entreprise de commerce électronique qui développe sa nouvelle plateforme. Les développeurs se concentrent sur les fonctionnalités, le catalogue de produits, le panier d'achat, le paiement, la gestion des stocks. Ils font du bon travail, l'application est rapide, l'expérience utilisateur est fluide, le produit est lancé avec succès. Six mois plus tard, lors d'un bon test, On découvre plusieurs problèmes majeurs. La communication entre les microservices ne se font pas de manière chiffrée, parce que les développeurs ont supposé que le réseau interne était sûr. Les clés d'API sont stockées en dur dans le code, parce qu'il n'y avait pas de solution de gestion de secrets prévues dans l'architecture. Les logs contiennent des données sensibles, parce que personne n'a pensé à définir ce qui devait ou pas être enregistré. La base de données contient des informations personnelles non chiffrées, parce que le chiffrement n'était pas dans les spécifications initiales. Maintenant, que faut-il faire ? Il faut réécrire une partie significative du code pour implémenter le chiffrement des communications. Il faut mettre en place un système de gestion des secrets et modifier toutes les applications pour l'utiliser. Il faut revoir les mécanismes de logging. Il faut migrer les données vers une base de données avec chiffrement, ce qui nécessite une maintenance longue et risquée. Et pendant tout ce temps, l'entreprise continue de fonctionner avec un système vulnérable. en espérant qu'aucun attaquant ne découvre ces failles. Le coût ? Des centaines d'heures de développement, des tests complexes pour s'assurer de ne rien casser, une migration de données délicate, et surtout un risque réputationnel énorme si une faille est exploitée avant que ces corrections soient en place. Sans parler du coût d'opportunité. Pendant que vos équipes corrigent ces problèmes de sécurité, elles ne développent pas de nouvelles fonctionnalités pour les clients. Maintenant, imaginons le même scénario, mais avec une approche Security by Design. Dès la phase de conception, un architecte sécurité est impliqué dans l'équipe. Les questions de sécurité sont posées en même temps que les questions fonctionnelles. Où seront stockées les données sensibles ? Comment les services ont-ils s'authentifié entre eux ? Quel sera le modèle de gestion des identités et des accès ? Comment allons-nous gérer les secrets ? Que sera notre stratégie de chiffrement ? Ces questions trouvent des réponses qui s'intègrent naturellement dans l'architecture. Un service de gestion des secrets est prévu Dès le début, les développeurs l'utilisent dès la première ligne de code. Le chiffrement TLS entre les services est configuré dès le déploiement du premier environnement de développement. Les politiques de logging sont définies dans un guide de développement que tous les développeurs suivent. La base de données est configurée avec le chiffrement dès sa création. Le résultat, lorsque l'application est lancée, est déjà sécurisé par conception. Il n'y a pas de dette de sécurité à rembourser plus tard, pas de migration risquée, pas de réécriture coûteuse. Et surtout, l'entreprise dort tranquille en sachant que ses systèmes respectent les meilleures pratiques de sécurité. Les études montrent que corriger une vulnérabilité de sécurité coûte en moyenne 10 fois plus cher en production qu'en phase de conception, et 100 fois plus cher si elle est découverte après une exploitation par un attaquant. Mais ce n'est pas seulement une question de coût financier direct, c'est aussi une question de coût caché. Quand une faille de sécurité est découverte en production, il y a une pression immense pour la corriger rapidement. Cette pression conduit souvent à des solutions de contournement rapides plutôt qu'à des corrections propres et durables. On met un pansement sur le problème plutôt que de traiter la root cause. Et ces pansements s'accumulent, créent une date technique qui rendra les évolutions futures encore plus difficiles et coûteuses. Il y a aussi le coût de l'anxiété et du stress pour les équipes. Travailler sur des systèmes qu'on sait vulnérables, en espérant qu'ils ne soient pas compromis avant qu'on ait le temps de les corriger, crée une tension permanente. Et puis il y a le coût réputationnel d'une faille de sécurité exploitée. Dans notre ère numérique, la confiance est le capital le plus précieux d'une entreprise. Une violation de données fait les gros titres, effraie les clients, attire l'attention des régulateurs. Certaines entreprises ne s'en remettent jamais complètement. La réalité, c'est que la sécurité n'est pas une fonctionnalité qu'on peut activer et désactiver. Ce n'est pas un module qu'on peut brancher sur une architecture existante. C'est une propriété émergente qui résulte de milliers de décisions prises tout au long de la conception et du développement d'un système. Chaque choix architectural a des implications en termes de sécurité. Le choix d'une architecture monolithique versus microservices. Le choix d'une base de données SQL versus NoSQL. Le choix d'un modèle de déploiement cloud versus... Tout ces choix créent des opportunités et des défis en matière de cybersécurité. Intégrer la sécurité dès la conception, ce qu'on appelle le security by design ou parfois le secure by design, c'est reconnaître cette réalité. C'est accepter que la sécurité n'est pas un département séparé qui intervient à la fin du processus, mais une dimension essentielle qui doit être prise en compte à chaque étape. Cela demande un changement de culture. Dans beaucoup d'organisations, il existe une tension entre les équipes de développement qui veulent aller vite et livrer des fonctionnalités, et les équipes de sécurité qui sont vues comme celles qui disent non et qui ralentissent les projets. Le Security by Design cherche à dépasser cette opposition en faisant de la sécurité une responsabilité partagée. Les développeurs doivent acquérir une compétence en sécurité, non pas devenir des experts, mais comprendre les principes fondamentaux, connaître les vulnérabilités les plus courantes, savoir utiliser les outils et les frais noirs qui facilitent le développement sécurisé. Les équipes de sécurité, de leur côté, doivent comprendre les contraintes de développement, être capables de proposer des solutions pragmatiques plutôt que de seulement pointer les problèmes, et s'intégrer dans les équipes de développement dès le début du projet. Les architectures IT jouent un rôle crucial dans cette transformation. Ce sont eux qui prennent les décisions structurantes qui détermineront la posture de sécurité globale du système. Ils doivent avoir une vision panoramique qui intègre la sécurité comme une contrainte fondamentale, au même titre que la performance. la scalabilité ou la maintenabilité. Mais intégrer la sécurité dès la conception ne veut pas dire que tout doit être parfait dès le premier jour. Cela serait impossible et contre-productif. Il s'agit plutôt de créer des fondations solides et une architecture qui pourra évoluer de manière sécurisée.
- Speaker #1
Vous faites 200 pas sur le chemin et vous montez la garde, au cas où quelqu'un approche.
- Speaker #2
Approche sur le chemin,
- Speaker #1
vous faites 200 pas sur le chemin et vous montez la garde.
- Speaker #3
Et s'il n'y a personne qui approche, on revient ?
- Speaker #1
Non, vous montez la garde. Au cas où quelqu'un approche.
- Speaker #2
Et s'il n'y a personne ?
- Speaker #1
S'il n'y a personne, tant mieux, vous montez la garde.
- Speaker #2
Ça ne change rien.
- Speaker #3
S'il n'y a personne, on remonte la garde ici, non ?
- Speaker #1
Non. Vous faites 200 pas sur le chemin d'abord.
- Speaker #3
Ah oui, je croyais que c'était au cas où quelqu'un approche.
- Speaker #2
Et si on a un de nous deux qui reste là ? On fait comment ? Non,
- Speaker #1
il n'y a personne qui reste là. Vous faites 200 pas sur le chemin.
- Speaker #2
Ah oui.
- Speaker #1
Et vous montez la garde.
- Speaker #3
Au cas où quelqu'un approche.
- Speaker #1
Au cas où, oui, mais de toute façon, vous montez la garde. Si personne n'approche, vous montez la garde quand même, vous revenez pas.
- Speaker #3
D'accord.
- Speaker #1
Allez-y. Eh ben,
- Speaker #2
vous préférez que je commence ? Moi, ça m'est égal, hein !
- Speaker #1
Vous faites 200 pas sur le chemin. Ah,
- Speaker #2
mais en même temps ! Une fois qu'on a fait les 200 pas...
- Speaker #1
Voilà !
- Speaker #2
On revient.
- Speaker #0
C'est prévoir dès le début les mécanismes qui permettront d'ajouter des couches de sécurité supplémentaires au fur et à mesure que les besoins évoluent. Par exemple, même si votre application ne traite pas de données extrêmement sensibles au début, Concevez-la de manière à pouvoir facilement ajouter du chiffrement plus tard si nécessaire. Même si vous n'avez pas besoin d'authentification multifacteur aujourd'hui, assurez-vous que votre système de gestion d'identité pourra l'intégrer demain sans tout réécrire. C'est ce qu'on appelle l'évolutivité sécurisée. En fin de compte, la question n'est pas de savoir si vous allez être attaqué, mais quand et comment vous y répondez. Les systèmes conçus avec la sécurité au cœur sont plus résilients. Ils ne sont pas invulnérables, aucun système ne l'est. mais ils sont capables de contenir une attaque, de limiter les dégâts et de récupérer plus rapidement. Voilà pourquoi le Security by Design est devenu un impératif dans l'architecture IT moderne. Ce n'est pas une mode passagère, ni un luxe, qu'on peut s'offrir quand on a le temps et le budget. C'est une nécessité stratégique dans un monde où la cybersécurité est devenue un enjeu majeur pour toutes les organisations, quelle que soit leur taille et leur secteur d'activité. Maintenant que nous comprenons pourquoi la sécurité doit être intégrée dès la conception, Parlons des principes fondamentaux qui doivent guider toute architecture IT sécurisée. Ces principes ne sont pas simplement des recommandations théoriques, ce sont des lignes directives approuvées, forgées par des décennies d'expérience et malheureusement par de nombreuses violations des sécurités dont nous avons collectivement tiré les leçons. Commençons par le principe de défense en profondeur. L'idée centrale est simple mais puissante. Ne jamais compter sur une seule ligne de défense, mais sur une approche militaire transposée au monde numérique. Imaginez un château médiéval, il n'y a pas qu'un seul mur d'enceinte, il y a d'abord un fossé rempli d'eau, puis un premier mur avec des tours et des guets, ensuite une cour fortifiée, puis un second mur, et enfin le donjon, au centre de ses propres défenses. S'il passe le premier mur, il se trouve dans une cour où il sera exposé, autour du second mur, et ainsi de suite. En architecture haïti, c'est exactement le même principe. Vous ne devez pas vous dire « j'ai un excellent pare-feu et je suis protégé » parce que tôt ou tard... Un attaquant trouvera un moyen de contourner ce pare-feu. C'est peut-être une vulnérabilité zéro-d dans le logiciel du pare-feu lui-même, ou un attaquant sur la chaîne d'approvisionnement qui compromet le fournisseur de confiance. Concrètement, la défense en profondeur se traduit par des couches multiples et variées de sécurité. Au niveau du réseau, vous avez des pare-feux, mais aussi des systèmes de détection et de prévention d'intrusion, qui analysent le trafic de manière plus fin. Au niveau applicatif, vous avez des WAF, des Web Application Firewall, qui analysent le protocole HTTP et peuvent bloquer des attaques spécifiques comme les injections SQL ou le cross-site scripting. Mais vous avez aussi la segmentation du réseau, qui crée des zones de sécurité distinctes. Vous avez des contrôles d'accès à plusieurs niveaux. Authentification pour accéder au réseau, puis authentification pour accéder à une application, puis autorisation pour effectuer une action spécifique dans cette application. Vous avez le chiffrement qui protège vos données, même si un attaquant parvient à y accéder physiquement. Vous avez des systèmes de surveillance et de détection qui peuvent identifier un comportement anormal, même si tous les autres défenses ont été franchies. Vous avez des mécanismes de sauvegarde et de récupération qui permettent de restaurer vos systèmes, même en cas de compromission totale. L'importance, c'est la diversité des couches. Si toutes vos défenses reposent sur le même principe ou le même fournisseur, une seule vulnérabilité peut tout compromettre. C'est ce qu'on appelle un point de défaillance unique. La défense en profondeur cherche précisément à éliminer ces points de défaillance uniques en multipliant les couches hétérogènes. Un autre aspect crucial de la défense en profondeur c'est qu'elle ralentit l'attaquant. Même si une couche est franchie, chaque couche supplémentaire demande du temps et des efforts pour être compromise. Ce temps est précieux. Il donne à votre système de détection l'opportunité d'identifier l'intrusion, il vous donne le temps de réagir, d'isoler les systèmes compromis, de bloquer l'attaquant avant qu'il n'atteigne son objectif. Passons maintenant au deuxième principe fondamental, le principe du moindre privilège. C'est l'un des concepts les plus anciens et les plus importants de la cybersécurité. formulé dès les années 70. Le principe est élégant dans sa simplicité. Chaque utilisateur, chaque application, chaque processus, chaque service ne doivent avoir accès qu'aux ressources strictement nécessaires pour accomplir sa fonction légitime, rien de plus. Pas un bit de données supplémentaire, pas une seconde de temps de processeur en trop, pas un octet de mémoire au-delà du nécessaire. Pourquoi est-ce si important ? Parce que chaque privilège supplémentaire est un risque supplémentaire. Si un compte est compromis, l'attaquant hérite de tous les privilèges de ce compte. Si ce compte avait accès à l'ensemble de la base de données, alors qu'il n'avait besoin que d'une seule table, l'attaquant peut maintenant exfiltrer toute la base. Si une application tourne avec des privilèges d'administrateur, alors qu'il n'en a pas besoin, une variété dans cette exploitation donne un accès route à l'attaquant. Prenons un exemple concret. Si vous avez une application web de commerce électronique, cette application a besoin d'accéder à une base de données pour lire le catalogue de produits et enregistrer les commandes. Une implémentation qui ne respecte pas le principe du moindre privilège donnerait à cette application un compte de base de données avec tous les droits lecture, écriture, modification de la structure des tables, suppression des tables, création de nouveaux utilisateurs. Mais pourquoi ? L'application n'a pas besoin de modifier la structure des tables. Elle n'a pas besoin de supprimer des tables. Elle n'a pas besoin de créer de nouveaux utilisateurs de base de données. Si elle est compromise, pourquoi donner à l'attaquant ses capacités ? Une implémentation qui respecte le principe du moindre privilège créera un compte de base données spécifique pour cette application, avec uniquement les droits de lecture sur la table des produits et des droits d'écriture sur la table des commandes. Même pas de droit de modification de suppression sur la table des commandes, juste l'insertion. Comme ça, si l'application est compromise, le pire que l'attaquant puisse faire, c'est lire les produits et insérer de fausses commandes. Il ne peut pas supprimer toutes les commandes existantes, il ne peut pas modifier les prix dans la base. Il ne peut pas créer une backdoor dans la base de données elle-même. Ce principe s'applique à tous les niveaux. Au niveau des utilisateurs humains, pourquoi donner à tous les développeurs un accès administrateur sur les serveurs en production ? Ils ont besoin de déployer du code, pas de redémarrer des serveurs ou de modifier la configuration du réseau. Créer des rôles spécifiques avec juste les permissions nécessaires. Au niveau du système d'exploitation, pourquoi faire tourner des processus avec le control to system ? La plupart des applications n'ont pas besoin de ces privilèges. Créer des comptes de services dédiés avec des permissions minimales. Le défi, bien sûr, c'est la complexité. Appliquer le principe du moindre privilège demande du travail. Il faut analyser précisément ce dont chaque composant a besoin. Il faut créer et maintenir des rôles granulaires. Il faut documenter qui a accès à quoi et pourquoi. Il faut régulièrement réviser ses accès parce que les besoins évoluent. Mais cette complexité est un investissement qui en vaut la peine. Chaque fois qu'une généralité est exploitée, Chaque fois qu'un compte est compromis, le principe du moindre privilège limite l'ampleur des dégâts. C'est une forme d'assurance contre la catastrophe. Il y a aussi les bénéfices secondaires, souvent sous-estimés. Le principe du moindre privilège améliore la traçabilité et la responsabilité. Quand chaque compte, chaque service a des permissions spécifiques et limitées, il devient plus facile de savoir qui a fait quoi. Les logs deviennent plus significatifs, les anomalies sont plus faciles à détecter. Le troisième principe fondamental est la segmentation. Ne mettez jamais tous vos œufs dans le même panier. Divisez votre infrastructure en zones spécifiques, avec des niveaux de confiance et des politiques de sécurité différentes. La segmentation est intimement liée à la défense en profondeur, mais elle mérite qu'on s'y attarde spécifiquement, car elle touche à l'architecture même de vos systèmes d'information. Historiquement, beaucoup de réseaux d'entreprise étaient ce qu'on appelle des réseaux plats. Chaque fois qu'on se connectait au réseau, on pouvait accéder à peu près à n'importe quelle ressource. C'est simple à gérer, mais catastrophique en termes de sécurité. Si un attaquant parvient à compromettre un seul poste de travail, il pouvait se déplacer latéralement dans tout le réseau et accéder aux serveurs, aux bases de données et aux systèmes de contrôle. La segmentation consiste à diviser ce réseau plat en sous-réseaux isolés, qu'on appelle souvent des segments ou des zones. Entre ces segments, on place des contrôles stricts. Le trafic réseau entre segments doit passer par des pare-feux et des serveurs de rebonds qui appliquent des règles précises. Un serveur web, dans le segment DMZ, peut recevoir une connexion depuis l'Internet, mais il ne peut se connecter qu'à des serveurs d'applications spécifiques dans un autre segment. Ces serveurs d'applications peuvent à leur tour se connecter à des serveurs de base de données dans un troisième segment, mais pas directement depuis Internet, dit depuis le segment DMZ. Cette approche permet de créer ce qu'on appelle une architecture en couches ou en tiers. Le monde extérieur ne peut accéder qu'à la première couche. Pour atteindre les données sensibles, dans la dernière couche, Un attaquant devrait compromettre successivement plusieurs systèmes dans différents segments, ce qui multiplie les difficultés. La segmentation ne se limite pas au réseau, elle s'applique aussi logiquement. Vous devez séparer vos environnements de développement, de test et de production. Les développeurs travaillent sur des systèmes de développement avec des données de test. Même s'ils introduisent une vulnérabilité ou une backdoor accidentellement, ils ne compromettent pas le système de production. Quand le code est déployé en production, il passe par un processus contrôlé avec des validations de sécurité. Vous devez aussi segmenter par fonction métier. Le réseau du département de ressources humaines qui traitent des données personnelles sensibles, devrait être séparé du réseau de l'équipe commerciale. Le système de contrôle industriel d'une usine devrait être sur un réseau complètement séparé, sans aucune connexion directe au réseau corporate ni à l'Internet. Une forme avancée de segmentation est la micro-segmentation, où vous créez des politiques de sécurité extrêmement granulaires, potentiellement jusqu'au niveau de chaque container ou de chaque machine virtuelle. Avec la micro-segmentation, même si un attaquant est dans votre réseau, Il ne peut se déplacer que très difficilement car chaque communication est explicitement autorisée ou bloquée selon des règles fines. La segmentation a aussi l'avantage de faciliter la conformité réglementaire. Si vous devez respecter le RGPD pour des données personnelles ou la norme PCI DSS ou DORA, vous pouvez créer des segments spécifiques qui contiennent ces données sensibles et appliquer des contrôles renforcés uniquement sur ces segments plutôt que sur toute votre infrastructure. Mais attention ! La segmentation mal faite peut créer de faux sentiments de sécurité. Il ne suffit pas de créer des VLAN ou des sous-réseaux. Il faut vraiment appliquer des contrôles stricts entre les segments et surveiller le trafic intersegment. Il faut aussi régulièrement revoir les règles pour s'assurer qu'elles sont toujours pertinentes et qu'elles n'ont pas été assouplies au fil du temps pour faciliter le travail au quotidien. Enfin, parlons du quatrième principe, peut-être le plus révolutionnaire, le Zero Trust ou Confiance Zéro en français. C'est un changement de paradigme complet dans notre façon de penser la cybersécurité. Elle est malheureusement trop souvent mise en avant pour des raisons purement marketing, ce qui donne l'illusion d'une stratégie complexe et surtout coûteuse, car on cherche à vous vendre toute la suite d'outils. Le modèle traditionnel de sécurité reposait sur la notion de périmètre de confiance. A l'intérieur du réseau d'entreprise, derrière le pare-feu, on faisait confiance. A l'extérieur, on se méfiait. C'était le modèle du château fort dont nous avons parlé. Le Zero Trust. renverse complètement cette logique. Son principe fondamental est « Ne faites confiance à personne par défaut, jamais, nulle part, ni à l'intérieur du réseau, ni à l'extérieur. Chaque accès, chaque connexion, chaque requête doit être vérifiée, authentifiée et autorisée explicitement en temps réel. » Pourquoi ce changement ? Parce que la notion de périmètre n'a plus de sens dans le monde moderne. Vos employés travaillent depuis chez eux, depuis des cafés, depuis des hôtels. Vos applications tournent dans le cloud public. accessible depuis n'importe où. Vos partenaires doivent accéder à certains de vos systèmes. Vos clients se connectent à vos services. Où est le périmètre dans tout ça ? Il n'y en a plus. Et puis, même quand il y a un périmètre, il n'est jamais aussi efficace qu'on ne le pense. De nombreuses attaques venaient de l'intérieur, d'employés malveillants ou négligents, ou d'attaquants qui avaient réussi à franchir le périmètre et qui ensuite se déplaçaient librement à l'intérieur parce qu'on leur faisait confiance. Le 013 dit « Peu importe d'où vient la requête, Il faut toujours vérifier. Un utilisateur veut accéder à un fichier ? On vérifie son identité. On vérifie qu'il a le droit d'accéder à ce fichier spécifique. On vérifie que l'appareil qu'il utilise respecte les politiques de sécurité. On vérifie que le contexte de la demande est normal. Et seulement après toutes ces vérifications, on autorise l'accès. Pour ce fichier précis, pour cette session, si 5 000 plus tard, il veut accéder à un autre fichier, on refait toutes les vérifications.
- Speaker #4
Bonjour, bienvenue chez Mastercard, mon nom est Chantal, comment je peux vous aider ?
- Speaker #5
Oui, bonjour ! J'appelle parce que je viens juste de recevoir mon relevé de carte de crédit, puis il y a une erreur.
- Speaker #4
D'accord, alors on va regarder ça ensemble, mais avant, je vais avoir besoin de votre nom, s'il vous plaît.
- Speaker #5
Yvon Gagnon.
- Speaker #4
D'accord, M. Gagnon. Alors, pouvez-vous me donner votre date de naissance ainsi que le nom de jeune fille dans votre amal, s'il vous plaît ?
- Speaker #5
13 mars, j'en ai 12, Jocelyne Guindon.
- Speaker #4
Parfait. Et par mesure de sécurité optimale ? Pouvez-vous me dire à caramau de votre dernier gastro-entérite ?
- Speaker #5
Hein ? C'est quoi ces questions-là, là ?
- Speaker #4
Ben là, écoutez, monsieur Gagnon, depuis le 11 septembre, on n'a pas plus de chance. On se doit de confirmer, hors de tout doute, votre identité.
- Speaker #5
Ben là, je ne sais pas, moi, je dirais deux, trois mois.
- Speaker #4
Oui, effectivement, deux mois et dix-sept jours.
- Speaker #5
Mais comment vous faites pour savoir ça, vous ?
- Speaker #4
Ben, j'ai accès à votre dossier médical, on est branché sur tout, nous. Et d'ailleurs, c'est pas joli joli, je vois que... Oh, vous faites de l'examen sous les aisselles, vous, hein ? Mais revenons à nos métaux, nous les égarons. Qu'est-ce que je peux faire pour vous, monsieur gagnant ?
- Speaker #5
Ben, c'est parce que sous mon relevé, il y a une transaction de 600 $ faite à la boutique érotique La Bisounerie de Longueuil.
- Speaker #4
Je vois, je vois.
- Speaker #5
Ben, c'est pas moi. J'aimerais rien acheter à la bisounerie, mais... Je me tiens pas dans l'insecte-chope, moi, là, y'a une erreur, j'ai jamais été à la bisounerie.
- Speaker #4
Vous êtes sain ? C'est parce que ça fait pas mal dans votre profil, là.
- Speaker #5
Mais quel profil ? De quoi vous parlez, là ?
- Speaker #4
Écoutez, M. Gagnon, écoutez, là, c'est parce que je vois dans votre dossier que vous avez déjà loué Emmanuel 4 à votre club vidéo.
- Speaker #5
Mais comment vous pouvez savoir tout ça ?
- Speaker #4
On sait tout, M. Gagnon, on sait tout.
- Speaker #0
Si un service A veut appeler une API sur le service B, même logique, le service A doit s'authentifier, prouver son identité, et le service B vérifier que le service A a bien le droit d'appeler cette API spécifique avec ses paramètres spécifiques à cet instant. Le Zero Trust implique plusieurs choses concrètement. D'abord, une authentification forte et continue. Pas seulement au login au début de la journée, mais une vérification continue de l'identité tout au long de la session. Si quelque chose semble anormal, on peut demander une réauthentification. Ensuite, une autorisation granulaire et contextuelle. On ne donne pas accès global à une application, mais un accès à des ressources spécifiques, basées non seulement sur qui est l'utilisateur, mais aussi le contexte, d'où il se connecte, Quel appareil il utilise ? Quelle heure est-il ? Et s'il y a eu des tentatives d'accès suspect récemment ? Le Zero Trust nécessite aussi une visibilité complète. Pour pouvoir prendre des décisions d'autorisation, il faut connaître les états de tous vos actifs, de tous vos utilisateurs, de toutes vos applications. Il faut monitorer en permanence pour détecter les anomalies. Enfin, le Zero Trust demande un chiffrement systématique. Si on ne fait confiance à aucun réseau, on chiffre toutes les communications TLS partout. Et pas seulement pour des données en transit sur internet, mais aussi pour les communications internes entre vos services. Mettre en place une architecture Zero Trust n'est pas simple, c'est un processus qui prend du temps. Vous ne pouvez pas appuyer sur un bouton et passer du jour au lendemain d'une architecture traditionnelle à du Zero Trust. Et ceci même si beaucoup de commerciaux veulent vous le faire croire. Mais c'est une direction dans laquelle toutes les organisations devraient se diriger. Les bénéfices sont considérables. Le 0.13 réduit drastiquement les surfaces d'attaque. Il limite les mouvements latéraux des attaquants, il améliore la visibilité et la détection, il facilite le support du travail à distance et du cloud, il crée une architecture plus résiliente, mieux préparée pour l'avenir incertain de la cybersécurité. Ces quatre principes, la défense en profondeur, le moindre privilège, la segmentation et le Zero Trust, ne sont pas indépendants. Ils se renforcent mutuellement. La segmentation crée des zones dans lesquelles vous appliquez les principes du moindre privilège. Le Zero Trust appuie sur la segmentation pour créer des micro-périmètres autour de chaque ressource. La défense en profondeur intègre ces principes comme autant de couches de protection. Ensemble, ils forment les fondations d'une architecture IT véritablement sécurisée. Une architecture où la sécurité n'est pas une réflexion à pré-coût, mais un élément constitutif de chaque décision de conception. Maintenant que nous avons posé les principes fondamentaux, entrons dans le concret. Quels sont les composants techniques ? Les briques essentielles que vous devez intégrer dans votre architecture pour la rendre véritablement sécurisée. Ces composants sont l'implémentation pratique des principes que nous venons de discuter. Commençons par l'authentification, qui est véritablement la pierre angulaire de toute sécurité. Si vous ne savez pas avec certitude qui accède à votre système, tous les autres contrôles de sécurité deviennent fragiles. L'authentification répond à une question simple mais cruciale. Êtes-vous vraiment qui vous prétendez être ? Pendant des décennies, L'authentification reposait presque exclusivement sur les mots de passe. Un identifiant et un mot de passe. Et voilà, vous étiez dans le système. Mais les mots de passe ont montré leur faiblesse de manière éclatante. Les utilisateurs choisissent des mots de passe faibles, parce qu'ils sont plus faciles à retenir. Ils réutilisent les mots de passe sur plusieurs sites, si bien qu'une fuite sur un site compromet tous les autres comptes. Les attaquants ont développé des techniques sophistiquées pour craquer les mots de passe. Attaque par brute force, rempotable et même le phishing. Même les mots de passe complexes, avec des caractères spéciaux, des chiffres, des majuscules et des minuscules, peuvent être compromis. Un keylogger sur une machine infectée capturera le mot de passe le plus complexe sans difficulté. Une attaque de phishing bien conçue amène l'utilisateur à saisir lui-même son mot de passe sur un faux site. C'est pourquoi l'authentification forte, et plus particulièrement l'authentification multifacteur, ou MFA, est devenue absolument incontournable. L'idée du MFA est de ne plus se reposer sur un seul facteur d'authentification. et d'en combiner plusieurs de natures différentes. On parle généralement de trois catégories de facteurs. Quelque chose que vous savez, c'est le mot de passe ou un code PIN. Quelque chose que vous possédez, c'est votre téléphone mobile, une clé de sécurité physique ou une carte à puce. Et quelque chose que vous êtes, c'est votre empreinte digitale, votre reconnaissance faciale ou rétinienne. L'authentification multifacteur combine au moins deux de ces facteurs. L'exemple le plus courant aujourd'hui, c'est la combinaison du mot de passe avec un code temporaire. reçu sur votre téléphone mobile. Vous saisissez votre mot de passe, puis le système vous envoie un SMS avec un code à 6 chiffres valable quelques minutes. Vous devez saisir ce code pour vous connecter. Pourquoi est-ce tellement plus sûr ? Parce qu'un attaquant qui a récupéré votre mot de passe, que ce soit par phishing, par fuite de données ou par n'importe quel autre moyen, ne peut toujours pas se connecter s'il n'a pas aussi votre téléphone. Il devrait compromettre deux choses différentes, ce qui multiplie considérablement la difficulté. Bien sûr, toutes les formes de MFA ne se valent pas. Les codes par SMS sont pratiques, mais pas les plus sûres. Il existe des attaques de SIM swapping où l'attaquant convainc votre opérateur téléphonique de transférer votre numéro sur sa carte SIM. Les applications d'authentification comme Google Authenticator ou Microsoft Authenticator sont plus sûres car elles génèrent des codes localement sans passer par le réseau téléphonique. Encore mieux, des clés de sécurité physiques comme les YubiKey utilisent des protocoles cryptographiques robustes comme Fido2. Elles sont résistantes au phishing car elle vérifie le domaine du site ayant fourni les credentials. Elles ne peuvent pas être clonées à distance. La biométrie, quant à elle, est pratique et de plus en plus répandue, mais soulève des questions spécifiques. Votre empreinte digitale ne peut pas être changée si elle est compromise. Elle doit donc être stockée de manière extrêmement sécurisée, idéalement dans une enclave sécurisée du hardware qui ne permet jamais d'extraire l'empreinte elle-même. Dans une architecture IT moderne, le multifactor authentication ne peut pas être une option mais un pré-requis pour les accès sensibles. Accès aux systèmes de production, accès aux consoles d'administration, au cloud, au VPN et aux IT DevOps. Tout devrait être protégé par le MFA. Idéalement, on devrait tendre vers le MFA adaptatif qui ajoute des niveaux d'authentification requis selon le contexte d'où l'utilisateur se connecte, à quelle heure, depuis quel appareil et quel niveau de sécurité détecté. Le deuxième composant essentiel est le chiffrement. Le chiffrement transforme vos données en format illisible pour quiconque qui n'a pas la clé de déchiffrement. C'est votre dernier rempart. Même si toutes vos défenses ont échoué, même si un attaquant accède physiquement à vos disques durs en interceptant vos communications, le chiffrement rend les données inutilisables. Le chiffrement doit être omniprésent dans une architecture moderne. On parle souvent des trois états des données, au repos, en transit et en cours d'utilisation. Le chiffrement des données au repos concerne les données stockées. Dans vos bases de données, sur vos disques, dans vos systèmes de fichiers, dans vos sauvegardes, toutes données sensibles doivent être chiffrées au repos. Cela veut dire que si quelqu'un vole un disque dur, ou accède aux sauvegardes, ou même obtient un accès non autorisé au système de fichiers, il ne peut pas lire les données sans la clé de chiffrement. La plupart des systèmes de bases de données modernes offrent du chiffrement transparent. MySQL, SQL Server, Oracle, tous supportent le chiffrement au repos. Les systèmes de fichiers comme Luxe, sur Linux et BitLocker sur Windows, permettent de chiffrer des volumes entiers. Dans le cloud, tous les grands fournisseurs proposent du chiffrement par défaut pour leur stockage. Le chiffrement en transit protège les données pendant qu'elles circulent sur le réseau. C'est ici que le TLS, Transport Layer Security, entre en jeu. TLS est le protocole qui sécurise HTTP, mais il ne devrait pas se limiter au trafic web externe. Toutes les communications entre vos services, même à l'intérieur de votre réseau interne, devraient utiliser TLS. Pourquoi ? Parce que dans un modèle Zero Trust, vous ne faites jamais confiance au réseau. Un attaquant qui a accès à votre réseau interne ne devrait pas pouvoir écouter les communications entre vos services. Le TLS Mutuel ou MTLS va plus loin en demandant aux deux parties de communication de s'authentifier mutuellement avec des certificats, assurant ainsi non seulement la confidentialité mais aussi l'authentification. Le chiffrement en cours d'utilisation est la frontière la plus récente. Traditionnellement, pour traiter les données, il fallait les déchiffrer en mémoire, ce qui les rend vulnérables pendant le traitement. Des technologies émergentes comme les enclaves sécurisées, Intel SGX et AMD SEV, ou le calcul homomorphe, permettent des traitements de données chiffrées sans jamais devoir les déchiffrer complètement. Ces technologies sont encore relativement nouvelles et ont des limitations de performance, mais elles ouvrent les possibilités fascinantes. Notamment pour traiter des données sensibles dans des environnements dont on ne contrôle pas complètement le hardware. comme le cloud public par exemple. Un aspect crucial du chiffrement est la gestion des clés. Le chiffrement n'est sûr que si les clés sont sûres. Si vous chiffrez vos données avec un algorithme inviolable, mais que vous stockez les clés en clair dans un fichier de configuration à côté, vous n'avez rien gagné. C'est pourquoi les systèmes de gestion de clés, ou KMS, sont essentiels. Un KMS stocke les clés de chiffrement de manière sécurisée, souvent dans un hardware spécialisé appelé HSM, pour Hardware Security Module. Les clés ne quittent jamais le HSM. Quand vous avez besoin de chiffrer ou de déchiffrer des données, vous envoyez des données au HSM qui effectue l'opération et renvoie le résultat, sans jamais exposer les clés elles-mêmes. Les KMS permettent aussi la rotation régulière des clés, essentielle pour limiter l'impact d'une compromission éventuelle. Ils fournissent un audit rail de toutes les utilisations des clés. Ils facilitent la révocation. Si une clé est compromise, vous pouvez la révoquer et rechiffrer les données avec une nouvelle clé. Dans le cloud, tous les grands fournisseurs offrent des services de KMS, AWS KMS, Azure Key Vault ou Google Cloud KMS. Ils sont intégrés avec les autres services et facilitent grandement le chiffrement. Le troisième composant essentiel est l'IAM, Identity and Access Management, la gestion des identités et des accès. C'est véritablement le système nerveux central de votre sécurité. L'IAM détermine qui peut faire quoi, quand et où et dans quelles conditions. Une solution IAM moderne gère plusieurs aspects. D'abord, l'authentification, dont nous avons déjà parlé, mais aussi l'autorisation. Une fois que je sais qui vous êtes, quels sont vos droits ? Pouvez-vous lire ce fichier ? Modifier cette base de données ? Déployer ce service ? Accéder à cette API ? L'IAM gère aussi le cycle de vie de l'identité. Quand un nouvel employé arrive, son compte doit être créé avec les accès appropriés selon son rôle. Quand il change de poste, ses accès doivent être ajustés. Quand il quitte l'entreprise, son compte doit être désactivé immédiatement. Un IAM efficace automatise ses processus et les intègre avec le système RH. Une conception clé dans l'IAM moderne est le RBAC, Role Based Access, le contrôle d'accès basé sur les rôles. Plutôt que d'attribuer des permissions individuellement à chaque utilisateur, ce qui devient ingérable dans une grande organisation, vous définissez des rôles. Un rôle développeur, par exemple, a certaines permissions. Un rôle administrateur système en a d'autres. Un rôle auditeur a encore d'autres permissions. Vous assignez ensuite des utilisateurs à des rôles. C'est beaucoup plus facile à gérer. Quand vous devez modifier les permissions d'un rôle, cela s'applique automatiquement à tous les utilisateurs de ce rôle. Quand un nouvel employeur arrive, vous lui assignez simplement les rôles appropriés plutôt que de configurer manuellement toutes ces permissions. Une évolution du AirBac est l'ABAC, Attribute Based Access Control, le contrôle d'accès basé sur les attributs. Avec l'ABAC, les décisions d'autorisation ne se basent pas seulement sur le rôle utilisateur, mais sur un ensemble d'attributs contextuels. Qui est l'utilisateur ? Quelle est la ressource demandée ? Quelles sont les conditions environnementales ? Par exemple, une politique à bac pourrait dire un utilisateur avec les rôles développeur peut accéder au log de production seulement pendant les heures ouvrables et seulement depuis le réseau d'entreprise ou un VPN approuvé. Cette granularité permet des politiques de sécurité très fins et contextuelles. L'IM doit aussi fournir une authentification unique ou pour Single Sign-On, plutôt que d'obliger les utilisateurs à avoir un compte et un mot de passe différent pour chaque application. Le Single Sign-On permet de s'authentifier une fois et d'accéder ensuite à toutes les applications autorisées. C'est plus pratique pour les utilisateurs et plus sûr car cela réduit le nombre de mots de passe à gérer et à sécuriser. Les protocoles modernes comme SAML, WOTANT2 et OpenID Connect facilitent l'implémentation du Single Sign-On. Ils permettent aussi la fédération d'identité. Ou vous pouvez utiliser votre identifiant système pour vous identifier à un autre système, même géré par un organisme différent. Un aspect souvent négligé mais crucial de l'IM est la gouvernance des accès. Il ne suffit pas de donner des accès, il faut régulièrement les réviser. Les accès ont tendance à s'accumuler au fil du temps. Un utilisateur change de rôle, mais garde ses accès au cas où. Quelqu'un a besoin temporairement d'un accès pour un projet spécifique, mais l'accès n'est jamais révoqué une fois le projet terminé. Un bon système IAM permet des campagnes de régularisation de certification des accès. Les managers reçoivent la liste des accès de leurs équipes et doivent valider que chaque accès est toujours nécessaire. Les accès non validés sont automatiquement révoqués. C'est fastidieux mais essentiel pour appliquer réellement le principe de moindre privilège au fil du temps. Le quatrième et dernier composant essentiel est la surveillance et la détection. Vous pouvez avoir toutes les défenses du monde, si vous ne savez pas ce qui se passe dans votre système, vous êtes aveugle. La surveillance, c'est vos yeux et vos oreilles pour votre infrastructure. Au cœur de la surveillance se trouvent les logs. Chaque système, chaque application, chaque équipement réseau génère des logs. Qui s'est connecté ? Quand ? Depuis où ? Quelle action a été effectuée ? Est-ce que ça a réussi ou échoué ? Combien de temps ça a pris ? Ces logs sont une mine d'or d'informations. Mais les logs seuls ne suffisent pas. Dans une infrastructure moderne, vous pouvez générer des millions de logs par jour. Aucun humain ne peut tout lire. C'est là qu'intervient le système SIEM, pour Security Information and Invent Management. Un SIEM collecte les logs de toutes vos sources, serveurs, applications, bases de données, équipements réseaux, pare-feu, systèmes d'authentification. Il les centralise dans un endroit unique où ils peuvent être analysés. Il les corrèle pour identifier des patterns. Il applique des règles pour détecter des comportements suspects. Il génère des alertes quand quelque chose d'anormal est détecté. Par exemple, votre SIEM peut détecter qu'un compte utilisateur s'est connecté depuis Paris à 10h du matin, puis depuis New York à 10h05. C'est physiquement impossible, donc c'est probablement un signe de compromission. Ou il peut détecter qu'un utilisateur télécharge soudainement des volumes massifs de données alors qu'il ne le faisait jamais habituellement. Ou qu'il y a des tentatives de connexion échouée répétées sur un compte administrateur. Les CIEM modernes intègrent de plus en plus d'intelligence artificielle et de machine learning. Plutôt que de se reposer uniquement sur des règles prédéfinies, ils apprennent le comportement normal de vos systèmes et de vos utilisateurs. Ils peuvent alors détecter des anomalies même pour des patterns d'attaques qu'il n'aura jamais vu auparavant. Un système complémentaire du CIEM est l'IDS ou l'IPS, pour Intrusion Detection System ou Intrusion Prevention System. Un IDS analyse le trafic réseau en temps réel pour détecter des signatures d'attaques connues et des comportements anormaux. Un IPS va plus loin et peut automatiquement bloquer le trafic suspect. La détection ne doit pas se limiter au réseau. Les systèmes EDR, pour Endpoint Detection and Response, Surveille ce qui se passe sur les postes de travail et les serveurs individuels. Ils peuvent détecter des malwares, des tentatives d'exploitation de vulnérabilité, des modifications suspectes de fichiers système et de processus anormaux. Toute cette surveillance génère des alertes, beaucoup d'alertes, trop d'alertes. C'est un problème connu dans l'industrie, l'alerte fatigue. Quand vous recevez 100 alertes par jour, vous commencez à les ignorer et vous risquez de manquer les vraies attaques noyées dans le bruit. A l'inverse, ne recevra pas. Aucune alerte n'est pas bon signe non plus. C'est pourquoi la qualité de la détection est aussi importante que la quantité. Il faut affiner les règles pour réduire les faux positifs. Il faut prioriser les alertes selon leur sévérité et leur contexte. Il faut automatiser la réponse aux alertes de bas niveau pour que les analystes puissent se concentrer sur les menaces sérieuses. La surveillance doit aussi inclure la gestion des vulnérabilités. Des scanners réguliers identifient les vulnérabilités connues dans votre système. Logiciels non patchés, configurations faibles, certificats expirés, etc. Un processus de remédiation priorise et corrige ces vulnérabilités avant qu'elles ne soient exploitées. Enfin, il est crucial d'avoir une capacité de réponse aux incidents. La détection ne sert à rien si vous ne pouvez pas réagir rapidement. Il faut des procédures documentées, des équipes formées, des outils permettant d'isoler rapidement des systèmes compromis, de collecter des preuves pour l'analyse Forensics et de restaurer les services. Ces quatre composants, l'authentification forte, le chiffrement omniprésent, L'IAM robuste et la surveillance continue ne fonctionnent pas isolément. Ils s'intègrent et se renforcent mutuellement pour créer une défense en profondeur. L'IAM s'appuie sur l'authentification forte. Le chiffrement protège les données que l'IAM autorise à accéder. La surveillance détecte des tentatives de contournement de l'authentification et les abus d'autorisation. Ensemble, ils forment l'ossature technique d'une architecture sécurisée. Ils ne garantissent pas une sécurité absolue, qui n'existe pas. Mais ils créent une posture de sécurité robuste. capables de résister aux menaces actuelles et de s'adapter aux menaces futures. L'architecturité moderne apporte de nouveaux défis. Le cloud, par exemple, introduit un modèle de responsabilité partagé. Vos fournisseurs cloud sécurisent l'infrastructure, mais vous restez responsable de la sécurité de vos données, de vos applications et de vos configurations. Les architectures microservices et les containers multiplient les surfaces d'attaque. Chaque API, chaque container devient un point d'entrée potentiel. Il faut donc sécuriser les communications, entre services, gérer les secrets comme les clés d'API de manière centralisée et scanner régulièrement les images des containers. Le télétravail a pulvérisé le périmètre traditionnel du réseau d'entreprise. Les employés se connectent depuis n'importe où ou sur des réseaux non sécurisés. D'où l'importance d'approches comme le SASE, qui combine sécurité réseau et accès cloud en un seul service. Mais la technologie ne suffit pas. La sécurité est avant tout une question humaine. Les architectes IT doivent collaborer étroitement avec les équipes de sécurité dès le début du projet. Les développeurs doivent être formés aux bonnes pratiques de code sécurisé et les utilisateurs doivent devenir des acteurs de la sécurité. Il faut accepter qu'aucun système n'est infaillible. C'est pourquoi la résilience est essentielle. Plan de réponse aux incidents, sauvegarde régulière, capacité à restaurer rapidement des services. La question n'est pas si vous serez attaqué, mais quand et comment vous allez réagir. Pour conclure, concevoir une architecture IT sécurisée demande une vision holistique. Il ne s'agit pas seulement d'empiler des solutions de sécurité, mais de penser à la sécurité comme une propriété intrinsèque de votre infrastructure. au même titre que la performance ou de la disponibilité. Les menaces évoluent constamment, et votre architecture doit pouvoir s'adapter. C'est un processus continu d'évaluation, d'amélioration et de vigilance. Mais aujourd'hui, en plus de la menace cyber, il faut aussi prendre en compte les aspects réglementaires, qui deviennent de plus en plus présents dans les discussions. De fait, au-delà des discussions Secure by Design, il va falloir maintenant travailler à Compliance by Design. Mais ça, c'est une autre histoire. Encore merci d'avoir écouté cet épisode de la cybersécurité expliquée à ma grand-mère. N'hésitez pas à le liker, à le partager avec d'autres et à en parler autour de vous. Si vous êtes sur Spotify, vous pouvez aussi donner votre avis et proposer des sujets qui vous semblent pertinents. Mais surtout n'oubliez pas, pour certains, la cybersécurité est un enjeu de vie ou de mort. C'est bien plus sérieux que ça.
