Il existe différentes « couches » de responsabilité dans le fonctionnement d’un réseau. Elles sont représentées dans l’Open Systems Interconnection model (OSI) (« modèle de référence d’interconnexion des systèmes ouverts » ou « modèle OSI » en français). Les voici :
La couche de réseau physique est la plus basse. Cette couche se charge de la transmission physique des données : elle s’assure que si l’émetteur envoie un « 1 », le destinataire reçoit bien un « 1 ». La couche physique envoie des données à partir de câbles (à fibre optique) légers, par exemple. Elle doit déterminer si le trafic peut être envoyé dans les deux sens en même temps, la façon dont la connexion est établie, etc.
La couche de liaison des données est chargée de détecter les erreurs et de les corriger, ainsi que de préparer les paquets de données, les « trames ». Elle contrôle les données qui entrent dans le réseau à proprement parler. Elle définit l’adresse matérielle à laquelle les données sont destinées : différentes interfaces réseau d’un même ordinateur, par exemple.
La couche réseau est responsable du routage des données vers la machine cible dans le réseau. Rappelez-vous que le réseau peut être connecté à un autre réseau et n’utilise peut-être pas le même protocole de communication. La couche réseau fait passer les données vers la couche de transport.
La couche de transport gère les connexions entre le nœud source (les éléments physiques qui composent un réseau) et le nœud de destination. Elle détermine également comment la connexion est gérée, que les paquets arrivent dans le bon ordre et qu’un paquet est retransmis dans le cas où sa livraison échouerait. La couche de transport gère également le débit afin que les nœuds plus rapides ne surchargent pas les plus lents.
La couche de session se charge de l’établissement et du maintien des connexions.
La couche de présentation gère notamment le chiffrement afin que des ordinateurs qui ne représentent pas les données de la même manière en interne puissent communiquer sous une forme compréhensible par tous. La couche de présentation gère également le chiffrement dans certains cas, notamment lorsque l’on navigue sur un site Web sécurisé.
La couche d’application gère la couche de protocole en tant que telle. Par exemple, dans un navigateur Web, le protocole HTTP définit la façon dont l’application demande une page Web.
Chaque bit de données envoyées – par exemple la page Web de ce cours – passe par les couches de réseau (on parle de pile de protocoles). Le site de ce cours utilise TLS (acronyme de transport layer security, littéralement « sécurité de la couche de transport » en français). C’est une méthode de chiffrement qui empêche les couches basses de « jeter un œil » dans les paquets pour observer des données (SSL, dans l’image ci-dessus, a été supplanté par TLS). Si ce cours n’utilisait pas TLS, vos données pourraient être envoyées en texte en clair à travers toutes les couches et tous les ordinateurs participants à la transmission des données. Cela peut représenter des dizaines de nœuds dans le pire des cas. Chacun de ces ordinateurs peut, en théorie, observer et voler ces données.
Sécuriser les connexions Web
Quand vous envoyez et recevez des données sur Internet, vous passez très souvent par un navigateur Web. Les navigateurs sécurisés utilisent le protocole TLS. Il protège le trafic entre le navigateur qui vous permet d’accéder à Internet (le client), et le serveur – à qui vous envoyez des données ou à partir duquel vous en recevez (p. ex. un serveur Web).
Vous pouvez vérifier que vous êtes bien protégé(e) par TLS en consultant la barre d’adresse de votre navigateur. Un cadenas doit y figurer, en plus du nom de domaine. Pas de cadenas, pas de protection par chiffrement.
En tant que couche de sécurité réseau, TLS utilise des protocoles cryptographiques pour authentifier, vérifier et assurer la sécurisation des échanges chiffrés de communication depuis le navigateur jusqu’au serveur cible en protégeant le contenu des paquets de données d’une exposition aux couches de réseau plus basses et aux nœuds tiers qui transmettent les données en transit.
Le protocole TLS gère l’échange des clés de chiffrement de façon sécurisée. Gardez bien cela à l’esprit : c’est la clé de chiffrement qui protège la confidentialité et confirme l’intégrité de la communication envoyée (le message).
Les navigateurs qui utilisent TLS vous protègent en vérifiant que le certificat du serveur du site Web est valide et qu’il correspond au nom de domaine du site (l’URL). Si le certificat du serveur n’est pas valide ou s’il est utilisé sur un autre site, le navigateur vous signale l’absence de protection. Un message s’affiche alors sur votre écran et vous met en garde contre l’invalidité de l’autorité de certification – c’est peut-être un(e) attaquant(e) qui insère son propre certificat au lien de Google.
Certains sites autorisent toujours des connexions par protocole HTTP non sécurisé. Cela signifie que toutes les données échangées entre votre navigateur et les serveurs de ces sites sont potentiellement espionnées par les personnes qui contrôlent les nœuds de transit des données.
Les attaques contre TLS
S’en remettre uniquement à l’icône de cadenas n’est toutefois pas suffisant. N’importe qui peut créer un certificat qui indique aux navigateurs le chiffrement à utiliser pour la connexion.
Un(e) attaquant(e) peut tenter de vous pousser à utiliser son site plutôt que l’original en utilisant des astuces simples – par exemple, en changeant l’adresse URL d’un site pour qu’elle ressemble fortement à celle du site authentique. Il/elle peut, par exemple, échanger la lettre minuscule « l » par le chiffre « 1 ». Dans la plupart des polices, ces deux caractères sont assez proches pour tromper les utilisateurs qui ne seraient pas suffisamment attentifs. Ces sites eux aussi peuvent utiliser un chiffrement – l’icône de cadenas ne signifie donc pas que vous vous trouvez sur un site sécurisé. Lorsque vous recevez un message contenant un lien, c’est peut-être un piège destiné à vous attirer sur un site. Pour éviter ces risques, saisissez l’adresse vous-même au lieu de cliquer sur le lien que vous recevez.
Quand un(e) attaquant(e) situé(e) entre le serveur et vous-même déchiffre, stocke et chiffre à nouveau votre trafic avant de le transmettre au serveur, on parle d’une « attaque de l’homme du milieu » (man-in-the-middle attack (MITM) en anglais). Si vous n’utilisez pas de chiffrement, ce type d’attaques est relativement facile à mettre en œuvre. La méthode TLS d’échange de clés et de vérification du serveur est censée vous protéger contre ces attaques. Toutefois, si vous ne tenez pas compte des messages d’alerte sur les sites non sécurisés, une attaque de l’homme du milieu est toujours possible.
Notez que TLS et d’autres protocoles de sécurité comme SSL ne servent pas uniquement à la communication entre navigateurs et serveurs de sites Web. Ils sont également utilisés dans d’autres types d’applications, notamment des logiciels de messagerie, des services de cloud et des applications mobiles. C’est quelque chose d’essentiel, car nous recevons et envoyons de plus en plus de données par l’intermédiaire des applications mobiles et du cloud. Comme nous allons le voir un peu plus loin, évaluer la sécurité de ces communications est toutefois un peu plus complexe.
Utiliser un VPN comme protection
Comment se protéger de l’espionnage des données ou des attaques de l’homme du milieu ? Un virtual private network (VPN) (« réseau privé virtuel » en français) peut constituer une très bonne solution. Un VPN chiffre vos données et les achemine de votre ordinateur à un nœud intermédiaire de confiance qui les déchiffre et les transmet vers le nœud de destination.
Un VPN est en quelque sorte une enveloppe additionnelle. Celle-ci chiffre le contenu (l’enveloppe de données d’origine) à partir du nœud de votre ordinateur, puis une fois au nœud de sortie, déchiffre l’enveloppe extérieure et laisse les données d’origine poursuivre leur chemin comme à l’ordinaire. Cela permet, par exemple, d’empêcher les réseaux Wi-Fi hostiles d’espionner vos communications.
Un VPN peut prendre la forme d’une application sur votre mobile ou sur un appareil à la limite de votre réseau de confiance (p. ex. le routeur interne d’une entreprise). Quand elles sont activées, ces deux options sécurisent et masquent les communications aux couches basses du réseau et donc aux nœuds qui gèrent le trafic.
Soyez néanmoins conscient(e) que lorsque le trafic chiffré par le VPN quitte le nœud du serveur du fournisseur de service VPN, il continue son trajet vers le nœud cible comme si de rien n’était. Si vous n’utilisez pas un protocole de réseau sécurisé comme TLS ou le chiffrement de bout en bout (voir chapitre 3.1), le trafic est accessible à chaque nœud sur le reste du trajet.
Un VPN peut également être utilisé pour masquer l’origine de votre trafic et ainsi donner l’impression que le VPN est le nœud de sortie. Vous pouvez avoir recours à cette fonctionnalité pour contourner les restrictions géographiques ou dissimuler votre trafic aux yeux des réseaux. Les VPN peuvent aussi être employés de sorte à dissimuler des communications à des gouvernements hostiles cherchant à espionner les citoyens de leur pays. Ils chiffrent et masquent la cible de la communication jusqu’à ce que la connexion aboutisse dans un nœud de sortie situé dans un autre pays.
On utilise aussi les VPN pour connecter des réseaux distincts. Le but est alors d’étendre un réseau entre les différentes branches d’une même entreprise, par exemple. Ces réseaux distincts ont beau ne pas être connectés physiquement, ils semblent n’en former qu’un grâce au VPN. Le trafic destiné au réseau interne est acheminé à travers la connexion VPN chiffrée vers le nœud de sortie qui se trouve dans ce cas à la frontière de l’autre réseau.
La sécurité des applications et des services de cloud
En règle générale, les données sont hébergées par un ordinateur nommé serveur. Une personne est spécifiquement chargée de la gestion et de la sécurité du serveur. Les origines des nombreuses pratiques de cybersécurité, comme le contrôle d’accès et l’ouverture de session, remontent aux premiers jours de l’informatique, quand les appareils étaient plus simples et toutes les données stockées en local.
Dans les années 1980 et 1990, la commercialisation et la « consumérisation » des ordinateurs personnels ont confié aux utilisateurs la responsabilité d’assurer la sécurité de leurs appareils (les « nœuds d’extrémité » ou « utilisateurs finaux », comme on les appelle dans le milieu professionnel). Cela passe généralement par l’installation d’un programme d’antivirus. Nous savons désormais que ce n’est pas suffisant, tout particulièrement dans le domaine de la cybersécurité des entreprises. Il convient d’organiser a minima des formations régulières sur les protocoles de cybersécurité quand les employés sont susceptibles de travailler à distance ou lors de déplacements professionnels.
Actuellement, les nœuds d’extrémité – les postes de travail, les mobiles, les tablettes – ne sont plus strictement réservés à un usage privé ou professionnel. Ces deux aspects sont brouillés, aussi bien en matière d’utilisation des appareils que de contenu stocké. Le lieu de stockage des données est également plus flou. Il est difficile de savoir où se trouvent les contrôles de sécurité des applications que vous utilisez au quotidien.
« Cloud » ou IaaS, PaaS et SaaS ?
Vous avez peut-être déjà entendu la phrase « le cloud est sécurisé par défaut ». À l’opposé, d’autres déclarent que « le cloud n’est jamais que l’ordinateur de quelqu’un d’autre ».
Bien qu’elles se rapprochent parfois de la réalité, ces affirmations font partie des nombreux mythes modernes de la cybersécurité. Pour comprendre la nature du « cloud », il est nécessaire de se poser quelques questions supplémentaires. Leurs réponses détermineront la nature des contrôles et des pratiques de cybersécurité.
Le terme cloud est aujourd’hui devenu quasi-synonyme de traitement de données géré par un tiers. Il existe toutefois des différences entre les types de clouds – IaaS, PaaS et SaaS :
Une infrastructure en tant que service ou IaaS (acronyme anglais d’Infrastructure as a Service) est un hébergeur de serveurs virtuels dans un environnement extensible (p. ex. AWS, Azure ou GCP). Dans ce cas, le client doit toujours assurer la sécurité des systèmes d’exploitation et des services.
Une plateforme en tant que service ou PaaS (acronyme anglais de Platform as a Service) est fournie par le même type de prestataire, mais elle offre également des services logiciels dans le domaine des bases de données ou de l’intelligence des données, par exemple. Dans ce cas, le client peut se concentrer sur les fonctionnalités de la plateforme, tout en la sécurisant à partir d’une configuration adéquate.
Salesforce, Office365 et Gmail sont des exemples de logiciels en tant que services ou SaaS (acronyme anglais de Software as a Service). Dans ce cas, le client a peu de contrôle sur la sécurité du service. Cependant, il est toujours de sa responsabilité de gérer l’identité utilisée sur le service et d’adopter de bonnes pratiques « d’hygiène de sécurité » sur le réseau, comme nous l’avons appris dans ce cours.
« Puis-je installer cette application sans danger ? »
Voilà une question très fréquente. Comprendre les descriptions d’application n’aide pas particulièrement à appréhender les méthodes de sécurisation du traitement des données dans l’application en elle-même ou dans le back end (« arrière-plan » en français).
Il faut plutôt se poser les questions suivantes pour analyser la cybersécurité d’une application :
Qui édite l’application ? Est-ce le magasin du constructeur ou une entité inconnue ? Les magasins d’application (Google Play, Apple store) mettent des veto aux applications qui contiennent des fonctionnalités dangereuses (logiciels d’espionnage, logiciels malveillants, portes dérobées).
Quelles informations l’application recueille-t-elle sur ses utilisateurs, avec ou sans leur consentement ?
Comment les informations sont-elles sécurisées entre l’application et le back end ? (Pour en savoir plus à ce sujet, voir le chapitre 3)
Comment l’information est-elle sécurisée entre l’émetteur et le destinataire (chiffrement de bout en bout) ?
Quid de la sécurité du protocole de chiffrement et de la gestion des clés ? L’application a-t-elle un certificat TLS, par exemple ?
Comment l’éditeur traite-t-il techniquement vos données ?
L’éditeur opère-t-il dans un cadre légal rendant obligatoire la transmission de vos données aux autorités locales (p. ex. en Chine) ?
L’éditeur intercepte et altère-t-il le contenu de l’information en transit (p. ex. WeChat en Chine) ?
Contrôler ces informations demande beaucoup de temps, même pour un professionnel. Vous pouvez donc consulter ce que d’autres personnes ont découvert à ce sujet. Vous pouvez d’abord vous demander si une évaluation du code et une analyse de sécurité indépendante ont été conduites récemment.
L’une des analyses publiques les plus faciles à trouver n’est autre que la comparaison des fonctionnalités de sécurité et de confidentialité des différentes applications de messagerie instantanée (Signal, Telegram, WhatsApp, Facebook Messenger).
Afin de comparer des applications, vous pouvez par exemple vous tourner vers l’EFF (Eletronic Frontier Foundation) (page en anglais). Cette évaluation est néanmoins un peu ancienne. Une version plus récente et plus détaillée est consultable sur Securemessagingapp.com (page en anglais).