Transcription

• Speaker #0

  Bonjour, aujourd'hui on s'attaque à un sujet vraiment central. Comment sécuriser la connexion Internet d'un système d'information ? C'est indispensable aujourd'hui, on est d'accord, mais c'est aussi une porte grande ouverte aux problèmes, aux menaces. On va s'appuyer sur un guide de l'ANSI, celui sur l'interconnexion sécurisée, pour voir un peu leurs recommandations clés. L'objectif, c'est de comprendre comment construire ce qu'ils appellent une passerelle Internet sécurisée. Protéger le réseau interne quoi.

• Speaker #1

  Tout à fait. Et c'est crucial de se rappeler pourquoi on fait tout ça. On parle de vol de données, d'intrusion, de blocage de services, même d'usurpation d'identité. Les risques ne sont pas théoriques. L'approche de Landsea est intéressante parce qu'elle dit bien, attention, il n'y a pas de boîtier miracle, c'est l'architecture d'ensemble qui compte. Alors c'est vrai, leur guide cible plutôt les systèmes avec des données, disons, moins sensibles. Mais franchement, les principes de base, ils s'appliquent partout. C'est le socle.

• Speaker #0

  D'accord. Donc, au cœur de cette architecture, si j'ai bien compris, l'idée maîtresse, c'est jamais de connexion directe entre le réseau interne et Internet. Et c'est là qu'intervient cette fameuse passerelle et la notion de DMZ, la zone démilitarisée.

• Speaker #1

  Un SAS, oui, c'est une bonne image. Elle est isolée d'Internet par un premier filtre et isolée aussi du réseau interne par un deuxième filtre. C'est une zone un peu neutre et surtout perservable. C'est là qu'on met les intermédiaires, les relais, typiquement les serveurs proxy, les relais mail, etc. Ils font le pont, mais ils ne sont pas dans le réseau interne.

• Speaker #0

  Logique. Et pour que ce sas soit efficace, il faut des gardiens solides. L'ANSI insiste beaucoup, beaucoup sur le filtrage périmétrique.

• Speaker #1

  Ah oui, c'est plus qu'une insistance, c'est vraiment fondamental. La recommandation la plus forte peut-être, c'est R13. Utilisez deux pare-feu distants. physiquement distincts. Un pare-feu externe entre internet et la DMZ et un pare-feu interne entre la DMZ et le réseau d'entreprise. Et surtout surtout, pas sur la même machine.

• Speaker #0

  Ah oui, pourquoi cette insistance sur la séparation physique ? C'est une question de coût, de complexité ?

• Speaker #1

  Ben oui, ça a un coût, c'est sûr, et c'est plus complexe à gérer, mais c'est la base de la défense en profondeur. Si le pare-feu unique est compromis, tout tombe. Là, l'attaquant doit passer deux barrières distinctes, c'est vraiment un point clé. non négociable pour l'ANSI, pour une bonne sécurité.

• Speaker #0

  D'accord, je vois. Et un autre point important, c'est que cette passerelle doit être le seul chemin, j'imagine. Pas de petite porte dérobée.

• Speaker #1

  Exactement. Recommandation R4. La passerelle doit être incontournable. Toute connexion directe sauvage qui la contourne, c'est à bannir absolument. Ça ruine tout l'édifice. Et il y a un autre concept important, c'est la rupture protocolaire. Recommandation R8.

• Speaker #0

  Rupture protocolaire. Ça sonne un peu technique. C'est quoi l'idée derrière ?

• Speaker #1

  Traversé directement de l'extérieur vers un serveur interne, on utilise un relais dans la DMZ, un proxy par exemple. Ce relais reçoit la connexion depuis Internet, l'analyse, la termine, et ensuite, lui, il initie une nouvelle connexion vers le serveur interne.

• Speaker #0

  Ah d'accord, c'est comme si on changeait de véhicule à la frontière ?

• Speaker #1

  C'est un peu ça, oui. Ça empêche une attaque sur le protocole lui-même de traverser directement, et ça permet aussi d'analyser le contenu qui passe. C'est la recommandation R9, l'analyse des flux. essentiels pour détecter des choses anormales, des malwares ou des fuites de données.

• Speaker #0

  Très clair. Parlons authentification. C'est souvent un point faible. Comment on fait pour vérifier qui accède à quoi sans mettre en danger l'annuaire centrale, l'Active Directory par exemple ?

• Speaker #1

  Alors la règle d'or de l'ANSI, R10, ne jamais exposer l'annuaire interne directement à la DMZ. Jamais. Si la DMZ tombe, vous ne voulez pas que les attaquants aient accès à toute votre base d'utilisateurs. Les solutions, c'est soit d'avoir un annuaire spécifique en DMZ, synchroniser avec l'interne, mais limité, soit d'utiliser des relais d'authentification, des proxys d'authentification, qui font le lien de manière sécurisée.

• Speaker #0

  Et la virtualisation ? On aime bien tout mettre sur les mêmes machines physiques maintenant.

• Speaker #1

  Oui, mais prudence ! L'NC R11 met en garde contre le fait de mélanger sur le même hyperviseur, sur le même matériel physique, des machines de zones de sécurité différentes, genre une VM du réseau interne à côté d'une VM de la DMZ. Si une VM est compromise, elle pourrait potentiellement attaquer les autres sur le même hôte. Donc l'idéal, même si c'est plus lourd, ça reste des machines physiques dédiées par zone R12. Séparation, séparation.

• Speaker #0

  Bon, passons à des exemples plus concrets. L'accès au web depuis l'entreprise. Tout le monde en a besoin.

• Speaker #1

  Oui, besoin universel et risque universel. Là, la rupture protocolaire est reine. Recommandation R22, mise en place obligatoire d'un serveur mandataire, un proxy web, dans la DMZ. Tout le trafic sortant doit passer par lui. Et point crucial, R23, il faut authentifier les utilisateurs sur ce proxy, pour savoir qui fait quoi, pour la traçabilité, pour pouvoir filtrer si besoin.

• Speaker #0

  Et le HTTPS, le trafic chiffré ? On en fait quoi ?

• Speaker #1

  Ah, l'inspection TLS R25. C'est un sujet complexe. C'est très utile pour la sécurité, car ça permet aux proxys de voir ce qui passe, même dans le trafic chiffré. Mais techniquement, c'est lourd. Ça veut dire que le proxy doit déchiffrer, analyser, puis rechiffrer. Ça consomme des ressources et surtout, ça soulève des questions importantes de respect de la vie privée et de confiance. Faut vraiment une étude sérieuse avant de se lancer là-dedans.

• Speaker #0

  D'accord. Autre gros morceau. La messagerie, l'email, toujours un vecteur d'attaque majeur.

• Speaker #1

  Absolument. Alors, principe numéro 1. Les boîtes au lait des utilisateurs, elles restent au chaud dans le SI interne. Jamais, au grand jamais, dans la DMZ. Dans la DMZ, on met quoi ? Des serveurs relais SMTP dédiés R35. Ce sont eux qui reçoivent les mails d'Internet et qui les envoient vers l'extérieur. L'idéal même, R36, c'est d'avoir des relais séparés pour l'envoi et la réception. Encore une fois, on cloisonne.

• Speaker #0

  Et pour lutter contre le phishing, l'usurpation d'identité par email ?

• Speaker #1

  Là, la NSSI insiste sur les mécanismes comme SPF, DKAIM et DMARC, R43 et R48. C'est un peu technique, mais en gros, ça permet de vérifier que l'email qui arrive vient bien du domaine qui prétend l'envoyer. C'est essentiel pour filtrer les faux emails, les tentatives d'arnaques. Il faut vraiment les mettre en place.

• Speaker #0

  Donc, pour résumer tout ça, cette passerelle Internet sécurisée, Avec sa DMZ, ses deux pare-feux bien séparés, ses relais spécialisés pour chaque service et un contrôle strict des accès et des identités. C'est vraiment le béabat d'une bonne posture de sécurité face à Internet.

• Speaker #1

  C'est exactement ça. C'est une approche structurée, en couche. Ça permet de contenir une attaque, si elle survient, de limiter sa propagation. Ça protège contre les menaces initiales qu'on évoquait, le vol de données, le sabotage. et ça aide aussi énormément pour la conformité réglementaire et pour avoir des traces en cas d'incident. C'est une hygiène de base, mais une hygiène indispensable.

• Speaker #0

  C'est très clair.

• Speaker #1

  Mais, et c'est là que ça devient intéressant pour la suite. Toute cette logique repose beaucoup sur un périmètre bien défini, l'entreprise et sa connexion. Or, aujourd'hui, avec le cloud, le SaaS, les applications qui sont partout, comment cette notion de périmètre évolue ? Est-ce que les protections fournies par les grands acteurs du cloud suffisent ? Est-ce qu'elle remplace vraiment le besoin de comprendre et d'appliquer ces principes fondamentaux de cloisonnement, de rupture protocolaire, de contrôle ? C'est une vraie question, je pense, pour la cybersécurité actuelle et future.

• Speaker #0

  Absolument. Une excellente question pour continuer la réflexion. Merci beaucoup pour cet éclairage basé sur les recommandations de l'ANSI. Pour celles et ceux qui veulent creuser, leurs guides sont vraiment très détaillés et disponibles en ligne. Fin de notre discussion pour aujourd'hui.