Au cours des dernières années, le world wide Web a connu une croissance exponentielle de pirates, malwares, rançongiciels et autres logiciels ou parties malveillants qui tentent constamment de trouver un moyen de voler nos données personnelles: compte tenu de ce scénario, il va sans dire que la sécurisation de vos données est devenue l’une des tâches les plus importantes que nous devrions prioriser, quel que soit le rôle que nous jouons habituellement. Le besoin général (et urgent) d’empêcher l’accès non autorisé à des informations personnelles, sensibles et / ou critiques est quelque chose qui devrait être reconnu par tous – utilisateurs finaux, propriétaires de services, administrateurs de serveurs, etc.: les différences sont principalement liées à ce que nous devons protéger et comment nous devons le faire.

Il va sans dire que le choix de la bonne façon de protéger nos données est souvent consécutif à une évaluation des risques bien exécutée suivie d’une analyse coûts-bénéfices, ce qui est une excellente approche pour nous aider à trouver les mesures techniques et organisationnelles appropriées à mettre en œuvre dans notre scénario spécifique. C’est également la manière appropriée d’agir conformément au Règlement Général sur la Protection des Données (RGPD), comme indiqué à l’art. 32 – Sécurité du Traitement:

Compte tenu de l’état de la technique, des coûts de mise en œuvre et de la nature, de la portée, du contexte et des finalités du traitement ainsi que du risque de probabilité et de gravité variables pour les droits et libertés des personnes physiques, le responsable du traitement et le sous-traitant mettent en œuvre des mesures techniques et organisationnelles appropriées pour assurer un niveau de sécurité adapté au risque

Voici une liste des mesures techniques et organisationnelles les plus courantes pour assurer la protection et la sécurité des données de nos jours:

  • Contrôle d’accès: Protégez tous les accès physiques à votre serveur, client et / ou salles de données avec des clés, des cartes à puce, des murs, des casiers, des alarmes et autres.
  • Minimisation: Assurez-vous que toutes les parties autorisées ne peuvent accéder qu’aux données spécifiquement liées à leurs tâches spécifiques et / ou à leur autorisation sans être autorisées à voir autre chose.
  • Intégrité: Protégez vos données contre la perte, la destruction ou les dommages accidentels à l’aide de contre-mesures appropriées (capteurs d’incendie / d’inondation, reprise après sinistre, etc.).
  • Pseudonymisation: Remplacez les données relatives à l’utilisateur par des blocs de texte aléatoires et anonymes, afin que le propriétaire puisse toujours conserver les entrées (à des fins statistiques) et, en même temps, les retirer de toute information personnelle.
  • Cryptage en transit: Assurez-vous que les données sont toujours transmises à l’aide de normes de cryptage en transit strictes (certificats SSL / TLS) et via des connexions sécurisées: cela s’applique également à tout type de site Web et de service Web contenant des formulaires, des écrans de connexion, des capacités de téléchargement / téléchargement, etc.
  • Chiffrement au repos: Protégez vos unités de stockage de données locales (y compris celles utilisées par les serveurs et les clients mobiles de bureau &) avec une norme de cryptage au repos solide ; assurez-vous que les données stockées dans des services SaaS et basés sur le cloud sont également cryptées au repos.
  • Confidentialité: Empêchez le traitement non autorisé ou illégal en mettant en œuvre des concepts tels que la séparation des préoccupations & séparation des tâches, l’application de politiques de mot de passe, etc.
  • Récupérabilité: Assurez-vous que toutes les données pertinentes font l’objet de sauvegardes régulières et assurez-vous également de les vérifier régulièrement pour vous assurer que les données peuvent être récupérées avec succès.
  • Évaluation: Soumettre l’ensemble du système à des examens techniques réguliers, à des audits tiers, adopter un ensemble efficace d’indicateurs de sécurité, etc.

Dans cet article, nous allons parler de deux de ces mesures techniques: le cryptage en transit et le cryptage au repos, laissant les autres sujets pour d’autres articles.

Introduction: les trois étapes des Données numériques

La première chose à faire est d’énumérer le nombre d ‘ »états » que les données numériques peuvent réellement avoir, et assurez-vous de comprendre chacune d’entre elles:

  • Au repos: c’est l’état initial de toute donnée numérique: en très bref, cela indique les données stockées quelque part sans être utilisées et / ou transmises à quiconque (y compris les logiciels, les tiers, les êtres humains, etc.). Des disques durs locaux aux Stockages connectés au réseau, des clés USB aux appareils mobiles, des dossiers système aux serveurs de bases de données, tout système, unité ou périphérique de stockage physique et logique est destiné à être utilisé pour contenir des données au repos… au moins pendant un certain temps.
  • En transit: également appelé « en mouvement ». Ceci est relatif aux données qui sont transmises quelque part à un autre endroit. Il convient de noter que le concept de « transfert de données » peut avoir lieu entre un nombre illimité de parties, ne se limitant pas à deux (l’expéditeur et un destinataire): par exemple, lorsque nous transférons un fichier de notre ordinateur de bureau vers notre ordinateur portable à l’aide de notre réseau local, nous effectuons essentiellement un transfert de données impliquant une seule partie (nous); inversement, lorsque nous soumettons une transaction à une base de données distribuée, telle qu’une blockchain, nous appliquons un transfert de données entre un nombre indéfini de parties (l’ensemble des nœuds blockchain).
  • En cours d’utilisation: chaque fois que les données ne sont pas simplement stockées passivement sur un disque dur ou un support de stockage externe, mais sont traitées par une ou plusieurs applications – et donc en cours de génération, de visualisation, de mise à jour, d’ajout, d’effacement, etc. – elles sont destinées à être « en cours d’utilisation ». Il va sans dire que les données utilisées sont sensibles à différents types de menaces, selon l’endroit où elles se trouvent dans le système et qui peut y accéder et/ou les utiliser. Cependant, le chiffrement des données en cours d’utilisation est assez difficile à réaliser, car il paralyserait, entraverait ou bloquerait probablement l’application qui y accède réellement : pour cette raison même, le meilleur moyen de protéger les données en cours d’utilisation est de s’assurer que l’application s’occupera de ce travail en adoptant les schémas de développement et d’implémentation les plus sécurisés dans son code source.

La somme des trois instructions expliquées ci-dessus s’appelle « les trois étapes des Données numériques »: maintenant que nous en avons compris l’essentiel, nous sommes prêts à approfondir les sujets de chiffrement.

Chiffrement des données au repos

D’après la définition de « au repos » donnée ci-dessus, nous pouvons facilement comprendre comment ce type de données est généralement dans un état stable: elles ne voyagent pas dans le système ou le réseau, et elles ne sont pas traitées par une application ou un tiers. C’est quelque chose qui a atteint une destination, au moins temporairement.

Raisons de l’utiliser

Pourquoi devrions-nous même chiffrer ces données, alors? Eh bien, il y a un certain nombre de bonnes raisons de le faire: jetons un coup d’œil aux plus importantes.

Vol physique

Si notre appareil est volé, le cryptage au repos empêchera le voleur d’accéder immédiatement à nos données. Bien sûr, il peut toujours essayer de le déchiffrer en utilisant la force brute ou d’autres méthodes de cryptage, mais c’est quelque chose qui prendra un temps raisonnable: nous devrions certainement être en mesure de retirer les contre-mesures adeguate avant que cela ne se produise, telles que: changer les informations de compte qu’il pourrait être en mesure de voir ou d’utiliser quelque peu via les gestionnaires de mots de passe des navigateurs existants, les cookies de connexion, les comptes de clients de messagerie, etc.; suivez notre appareil et/ou émettez un message  » effacer toutes les données  » à l’aide de nos services de gestion à distance des appareils Google ou Apple ; et ainsi de suite.

Vol logique

Si notre PC, notre site Web ou notre compte e-mail est piraté par un utilisateur ou un logiciel malveillant, le cryptage au repos empêchera le contrevenant d’accéder à nos données – même lorsqu’elles sont volées ou téléchargées: c’est fondamentalement le même scénario de vol physique, sauf que c’est beaucoup plus subtil car la plupart des utilisateurs (ou administrateurs) n’en seront même pas conscients.

Voici une autre bonne occasion de se souvenir des mots formidables prononcés par John T. Chambers, ancien PDG de Cisco, Inc.:

Il existe deux types d’entreprises : celles qui ont été piratées et celles qui ne savent pas qu’elles ont été piratées.

Compte tenu de l’état actuel d’Internet de nos jours et de la surabondance de malwares et de tentatives de piratage mesurables, la même affirmation peut être formulée pour tout utilisateur final possédant un appareil compatible avec le Web: 100% garanti.

Erreurs humaines

Sans parler des vols physiques et/ ou logiques, il existe de nombreux autres scénarios où le cryptage des données au repos pourrait être une bouée de sauvetage: par exemple, si nous avons perdu notre smartphone (et que quelqu’un le trouve); ou si nous commettons une erreur en attribuant des autorisations, en accordant à des utilisateurs non autorisés (ou à des clients) l’accès à des fichiers / dossiers / données qu’ils ne devraient pas pouvoir voir; ou si nous oublions notre mot de passe local de PC ou de courrier électronique à la vue de tous, permettant ainsi à quiconque n’ayant pas envie de respecter notre vie privée de jeter un œil à nos affaires; et la liste pourrait durer un moment.

Comment cela peut-il nous aider

Pour résumer tout cela, nous pourrions répondre à nos questions précédentes d’une seule ligne en disant que le cryptage de nos données au repos pourrait nous aider à mieux faire face à une éventuelle violation de données.

Cela ne nous aidera pas à empêcher cela de se produire – ce qui est principalement une tâche pour les pare–feu, les antivirus, les bonnes pratiques et les protocoles de sécurité – mais nous donnera certainement la chance (et le temps) de mettre en place les contre-mesures appropriées, en minimisant, espérons-le, les dommages globaux causés par une éventuelle fuite.

Comment l’implémenter

La mise en œuvre d’un protocole de sécurité de chiffrement des données au repos peut être facile ou difficile, en fonction des facteurs suivants:

  • quelles sources/stockages de données physiques et logiques nous voulons (ou devons) protéger : les sources physiques incluent les disques durs, les éléments NAS, les smartphones, les clés USB, etc., tandis que les sources logiques incluent des bases de données locales ou distantes, des actifs basés sur le cloud, des périphériques virtualisés, etc. ;
  • qui doit avoir accès à ces données: des êtres humains (utilisateurs locaux ou distants ou d’autres tiers se connectant à nous), des logiciels pilotés par des humains (comme MS Word) ou des processus ou services automatiques (comme une tâche de sauvegarde nocturne) ;
  • combien sommes-nous prêts à sacrifier en termes de performance globale et / ou de facilité d’accès pour accroître la sécurité : pouvons-nous demander à tous nos utilisateurs locaux (et distants) de décrypter ces données avant de pouvoir y accéder ? Faut-il utiliser un mot de passe, un jeton physique ou un code OTP ? Pouvons-nous rendre le cryptage suffisamment transparent pour ne pas gêner nos utilisateurs externes et permettre à nos applications et outils logiciels de traiter les données cryptées chaque fois qu’ils en auront besoin ?

Heureusement, ces facteurs sont bien connus de la plupart des outils de chiffrement au repos, qui ont été conçus pour protéger nos données sans compromettre la fonctionnalité globale de notre environnement:

  • si nous voulons chiffrer des disques durs physiques (ou logiques), nous pouvons utiliser d’excellents outils logiciels tels que VeraCrypt (100% gratuit) ou AxCrypt (version gratuite disponible);
  • si nous avons besoin de protéger nos clés USB, nous pouvons soit utiliser les outils susmentionnés, soit acheter un lecteur Flash crypté par matériel implémentant des mécanismes de déverrouillage basés sur des empreintes digitales ou des mots de passe (à partir de 20 à 30 dollars);
  • si nous souhaitons chiffrer les données stockées dans un Système de gestion de base de données, la plupart des SGBD disponibles aujourd’hui fournissent des techniques de cryptage natives (cryptage de l’espace de table InnoDB pour MySQL et MariaDB, Cryptage transparent des données pour MSSQL, etc.);
  • si nous cherchons un moyen de stocker en toute sécurité nos messages électroniques, nous pouvons facilement adopter une norme de cryptage sécurisé des messages électroniques telle que S / MIME ou PGP (les deux sont gratuits): bien que ces protocoles soient principalement liés au cryptage en transit, car ils protègent les données principalement destinées à être transférées à des parties distantes, ils sont en fait couramment utilisés pour effectuer un cryptage côté client, ce qui signifie qu’ils protègent les messages électroniques lorsqu’ils sont encore au repos. Inutile de dire que ces messages seront très probablement envoyés, nos destinations devront également adopter la même norme pour pouvoir les lire.

Cryptage des données en transit

Comme son nom l’indique, les données en transit doivent être considérées comme un flux de transmission: un excellent exemple de données en transit est une page Web typique que nous recevons d’Internet chaque fois que nous surfons sur le Web. Voici ce qui se passe sous le capot en un mot:

  1. Nous envoyons une requête HTTP (ou HTTPS) au serveur hébergeant le site Web que nous visitons.
  2. Le serveur Web accepte notre requête, la traite en trouvant le contenu (statique ou dynamique) que nous avons demandé, puis nous l’envoie sous forme de réponse HTTP (ou HTTPS) sur un port TCP donné (généralement 80 pour HTTP et 443 pour HTTPS).
  3. Notre client, généralement un navigateur web tel que Google Chrome, Firefox ou Edge, reçoit la réponse HTTP(s), la stocke dans son cache interne et nous la montre.

Comme nous pouvons le voir, il y a clairement une transmission de données entre le serveur et le client: au cours de cette transmission, les données demandées (le code HTML de la page Web) deviennent un flux qui traverse au moins cinq états différents:

  1. il commence au repos (stockage serveur),
  2. puis passe en utilisation (mémoire serveur web),
  3. puis en transit (en utilisant le protocole de transfert hypertexte sur un port TCP donné),
  4. puis à nouveau en utilisation (navigateur web),
  5. et enfin au repos (cache client).

Raisons de l’utiliser

Maintenant, prenons pour acquis que le serveur et le client ont mis en œuvre un fort niveau de cryptage des données au repos: cela signifie que le premier et le cinquième état sont sûrs en interne, car toute tentative d’intrusion serait faite contre des données chiffrées. Cependant, le troisième état – où les données sont en transit – peut être crypté ou non, en fonction du protocole que le serveur et le client utilisent réellement pour transmettre les données.

Voici ce qui se passe généralement sous le capot lorsque le protocole HTTP est utilisé:

 Chiffrement en transit et Chiffrement au repos - Définitions et Bonnes pratiques

Comme nous pouvons le constater, le problème de sécurité est assez évident : lorsque le serveur Web traite la demande entrante et déchiffre de manière transparente les données demandées, le canal utilisé pour la transférer au client Web (HTTP) n’est pas crypté : par conséquent, toute partie fautive qui parvient à réussir une attaque appropriée (voir ci-dessous) pourrait avoir un accès immédiat à nos données non cryptées .

Comment cela peut-il nous aider

Si vous êtes curieux de savoir quel type d’attaque peut être utilisé contre un protocole de transmission TCP non chiffré tel que HTTP, voici quelques menaces dont vous devez être conscient:

  • Écoute clandestine: une attaque de couche réseau qui se concentre sur la capture de petits paquets du réseau transmis par d’autres ordinateurs et la lecture du contenu des données à la recherche de tout type d’information (plus d’informations ici).
  • Homme du milieu: une attaque basée sur la falsification où l’attaquant relaie et / ou modifie secrètement la communication entre deux parties pour leur faire croire qu’elles communiquent directement entre elles (plus d’informations ici).

La mise en œuvre de protocoles de cryptage en transit appropriés pour sécuriser nos points de terminaison de transfert de données critiques nous aidera certainement à prévenir ce type de menaces.

Comment l’implémenter

La mise en œuvre d’un modèle de cryptage en transit efficace consiste principalement à s’en tenir à une série de recommandations et de bonnes pratiques largement connues lors de la conception du transfert de données réel : quels protocoles utiliser (ne pas) utiliser, quels logiciels adopter (ne pas) adopter, etc. Par exemple:

  • Chaque fois que le périphérique de transmission est accessible via une interface Web, le trafic Web ne doit être transmis que via SSL (Secure Sockets Layer) à l’aide de protocoles de sécurité puissants tels que TLS (Transport Layer Security): ceci s’applique à tout site Web et/ou service accessible par WAN, y compris les serveurs de messagerie électronique et autres. À ce jour, le meilleur moyen (et le plus simple) d’implémenter la sécurité TLS et d’implémenter le cryptage en transit pour n’importe quel site Web est d’obtenir un certificat SSL / TLS HTTPS: ceux-ci peuvent être achetés auprès des autorités de certification enregistrées (Comodo, GlobalSign, GoDaddy, DigiCert et leur énorme liste de revendeurs / sous-vendeurs) ou générés automatiquement via un processus d’auto-signature, comme nous l’avons brièvement expliqué dans cet article. Bien que les certificats auto-signés accordent le même niveau de cryptage que leurs homologues signés par une autorité de certification, les utilisateurs ne leur feront généralement pas confiance car leurs clients navigateurs ne pourront pas vérifier la bonne foi de l’identité de l’émetteur (vous), signalant votre site Web comme « non fiable »: pour cette raison même, ils ne doivent être utilisés que sur des serveurs / services non en production (ou non accessibles au public).
  • Toutes les données transmises par e-mail doivent être sécurisées à l’aide d’outils de cryptage des e-mails cryptographiquement puissants tels que S / MIME ou PGP, que nous avons déjà couverts lorsque nous avons parlé du cryptage des données au repos: bien que ces protocoles effectuent leur cryptage au niveau du client (et donc au repos), ils sont également parfaits pour protéger le flux de transit asynchrone d’un message électronique.
  • Toutes les données binaires doivent être cryptées à l’aide d’outils de cryptage de fichiers appropriés avant d’être jointes au courrier électronique et / ou transmises de toute autre manière. La plupart des protocoles de compression, y compris ZIP, RAR et 7Z, prennent en charge un niveau décent de cryptage protégé par mot de passe de nos jours: leur utilisation est souvent un excellent moyen d’ajouter un niveau de sécurité supplémentaire et de réduire la taille des pièces jointes en même temps
  • La transmission non web de texte et / ou de données binaires doit également être cryptée via un cryptage au niveau de l’application, en tenant compte des scénarios suivants:
    • Si la base de données d’application réside en dehors du serveur d’applications, la connexion entre la base de données et l’application doit être cryptée à l’aide d’algorithmes cryptographiques conformes à la norme FIPS.
    • Lorsque le cryptage au niveau de l’application n’est pas disponible, implémentez un cryptage au niveau du réseau tel que le tunneling IPSec ou SSH et/ ou assurez-vous que la transmission elle-même est effectuée à l’aide de périphériques autorisés fonctionnant dans des sous-réseaux protégés avec des contrôles de pare-feu puissants (VPN et autres).

Le tableau suivant montre quelques exemples des protocoles réseau non sécurisés que vous devez éviter et de leurs homologues sécurisés que vous devez utiliser à la place:

Transfer Type What to avoid (insecure) What to use (secure)
Web Access HTTP HTTPS
E-Mail Servers POP3, SMTP, IMAP POP3S, IMAPS, SMTPS
File Transfer FTP, RCP FTPS, SFTP, SCP, WebDAV over HTTPS
Remote Shell telnet SSH2
Remote Desktop VNC radmin, RDP

Chiffrement de bout en bout

Le chiffrement en transit est vraiment utile, mais il présente une limitation majeure : il ne garantit pas que les données seront cryptées à leur point de départ et ne seront pas déchiffrées tant qu’elles ne seront pas utilisées. En d’autres termes, nos données pourraient encore être prédatées par des écoutes occasionnelles et / ou malveillantes, y compris des fournisseurs d’accès Internet, des fournisseurs de services de communication et quiconque pourrait accéder aux clés cryptographiques nécessaires pour déchiffrer les données en transit.

Surmonter cette limitation est possible grâce au chiffrement de bout en bout (E2EE), un paradigme de communication où seules les parties terminales communicantes – par exemple, les utilisateurs – peuvent déchiffrer et donc lire les messages. Les données chiffrées de bout en bout sont chiffrées avant leur transmission et le resteront jusqu’à leur réception par la partie finale.

Raisons de l’utiliser

Pour mieux comprendre comment le chiffrement de bout en bout remplace le chiffrement en transit en termes de résilience aux écoutes, imaginons les scénarios suivants.

  1. Supposons qu’un tiers parvienne à implanter son propre certificat racine sur une autorité de certification de confiance : une telle action pourrait théoriquement être effectuée par un acteur étatique, un service de police ou même un opérateur malveillant/corrompu d’une Autorité de certification. Toute personne capable de le faire pourrait opérer avec succès une attaque man-in-the-middle sur la connexion TLS elle-même, en écoutant la conversation et peut-être même en la falsifiant. Les données chiffrées de bout en bout résistent nativement à ce type d’attaque, car le cryptage n’est pas effectué au niveau du serveur.
  2. Le chiffrement de bout en bout peut également augmenter le niveau de protection parmi les processus utilisateur générés par un système d’exploitation. Vous souvenez-vous des récents défauts du processeur appelés SPECTRE et MELTDOWN? Les deux ont permis à un tiers malveillant (tel qu’un processus malveillant) de lire les données de la mémoire sans être autorisé à le faire. Le chiffrement de bout en bout pourrait éviter un tel scénario tant que le chiffrement est effectué entre les processus utilisateur (par opposition au noyau), empêchant ainsi toute donnée non cryptée d’être mise en mémoire.

Comment cela peut nous aider

Le cryptage de bout en bout est la forme de communication la plus sécurisée qui puisse être utilisée de nos jours, car il garantit que seuls vous et la personne avec qui vous communiquez pouvez lire ce qui est envoyé, et personne entre les deux, pas même le service qui effectue réellement la transmission entre pairs. Diverses implémentations de chiffrement de bout en bout sont déjà efficaces sur la plupart des applications et services de messagerie (y compris Whatsapp, LINE, Telegram, etc.). Dans une « application de communication » typique, les messages sont sécurisés avec un verrou, et seuls l’expéditeur et le destinataire disposent de la clé spéciale nécessaire pour les déverrouiller et les lire: pour une protection accrue, chaque message est automatiquement envoyé avec son propre verrou et sa clé uniques.

Comment l’implémenter

Le cryptage de bout en bout peut être utilisé pour protéger n’importe quoi: des messages de chat, des fichiers, des photos, des données sensorielles sur des appareils IoT, des données permanentes ou temporaires. Nous pouvons choisir les données que nous voulons chiffrer de bout en bout. Par exemple, nous pourrions vouloir conserver les informations bénignes liées à une application de chat (comme les horodatages) en texte clair, mais chiffrer de bout en bout le contenu du message.

  • Chaque utilisateur dispose d’une clé publique privée & que le logiciel doit générer sur l’appareil des utilisateurs lors de leur inscription ou lors de leur prochaine connexion.
  • La clé publique de l’utilisateur est publiée dans un lieu public (tel qu’un service de gestion de clés basé sur REST) : cela est nécessaire pour que les utilisateurs puissent trouver les clés publiques de l’autre et pouvoir chiffrer les données entre eux.
  • La clé privée de l’utilisateur reste sur l’appareil de l’utilisateur, protégée par le magasin de clés natif du système d’exploitation (ou d’autres magasins sécurisés).
  • Avant d’envoyer un message de discussion ou de partager un document, l’application crypte le contenu à l’aide de la clé publique du destinataire (côté client).

Conclusion

Notre parcours à travers les différents paradigmes de chiffrement est terminé : nous espérons sincèrement que cet aperçu aidera les utilisateurs et les administrateurs système à mieux connaître les différents types de chiffrement disponibles aujourd’hui.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.

lg