Protocole de transfert de fichiers SSH 101 : de quoi s'agit-il ? Quand y recourir ?

Protocole de transfert de fichiers SSH 101 : de quoi s'agit-il ? Quand y recourir ?

Imaginez un peu votre étonnement en lisant ceci : « Une société d'hébergement Web perd au moins 13 millions de mots de passe en texte clair ». En caractères gras. En exergue, tout en haut d’un article. Ou d’un blog.

Rares sont les titres susceptibles de donner autant de sueurs froides à une team IT, mais celui-ci est l’un d’entre eux. Voilà en gros à quoi ressemble un film d'horreur pour une équipe de sécurité informatique, la trouille en moins.

Aussi longtemps que l'internet existera, le transfert de données entre deux voire plusieurs points de terminaison représentera toujours un défi. À partir du moment où un utilisateur se connecte, l’existence de vulnérabilités dans le transfert de fichiers est une réalité. Les noms d'utilisateur, les mots de passe, le cryptage et les données sont autant de cibles viables.

Détour par le FPS et le protocole Telnet

Un article sur SSH qui ne rendrait pas honneur à ses prédécesseurs serait incomplet. Vivent les protocoles FPS et Telnet, qui ont jeté les bases du transfert de fichiers sécurisé tel que nous le connaissons aujourd'hui, faut-il le rappeler.

Toutes les formes de transfert de données se font entre deux points de terminaison, à savoir un client et un serveur. Un protocole de transfert de fichiers, tel que FPS ou SFPS, facilite ce transfert. Parmi ses nombreux défauts, le non-cryptage est de loin le plus flagrant.

Lorsque des utilisateurs ont commencé à partager des informations plus sensibles et surtout plus confidentielles sur des points de terminaison client-serveur, un renforcement de la sécurité s'est avéré nécessaire. Ce besoin a fait émerger l'authentification symétrique par mot de passe à la faveur de protocoles de connexion tels que Telnet et RSH.

Les protocoles de connexion exigent qu'un client et un serveur aient une clé et un mot de passe identiques. Le client envoie la clé au serveur, et si les deux correspondent, un transfert de données bidirectionnel peut alors être effectué.

 

L'essor des protocoles SSH

L'authentification symétrique par mot de passe était censée garantir la protection des données, mais la fête n'a été que de courte durée. Une pléthore de problèmes n'a en effet pas tardé à émerger.

Il suffit de penser à l'usurpation d'adresses IP, DNS et de routage, au reniflage de paquets et aux attaques par déni de service, entre autres, pour prendre la mesure du caractère illimité qu’arboraient les possibilités de menaces.

Un utilisateur malveillant pouvait, par exemple, remplacer l'adresse IP d'un client par la sienne et recueillir ainsi des informations non cryptées, notamment des mots de passe en texte clair et autres données sensibles.

Un autre utilisateur malveillant pouvait ainsi accéder aux noms d'utilisateur et saisir intentionnellement des mots de passe erronés, ce qui entraînait à coup sûr un déni de service pour les clients clés.

Dès lors, les protocoles Telnet, RSH et FPS n'inspiraient plus réellement confiance. Une innovation était attendue depuis longtemps, et c’est en 1995 qu’un certain Tatu Ylönen a développé le protocole Secure Shell, d’abord pour son usage personnel.

Quinze ans plus tard, le protocole SSH est utilisé par des millions d'entreprises à travers le monde.

Le protocole de transfert de fichiers SSH réduit à sa plus simple expression

Secure Shell (SSH) est né de l'insécurité inhérente aux protocoles FTP et Telnet. Contrairement à Telnet qui utilisait deux canaux pour l'authentification client-serveur, SSH n’en utilisait qu’un seul. Un client envoie sa clé au serveur, et si la clé du serveur correspond, un transfert bidirectionnel de données peut alors avoir lieu.

Par ailleurs, SSH utilisait un cryptage standard tel que l'AES pour sécuriser les données. Grâce au cryptage, les utilisateurs malveillants ne pouvaient pas interpréter les données récoltées, même après une violation. Et ça ne s'arrête pas là.

SSH utilise des algorithmes de hachage tels que le SHA-2 pour s'assurer que les pirates ne corrompent pas les données pendant leur transfert bidirectionnel.

Cryptage conforme aux normes industrielles : oui, c’est validé. Algorithmes de hachage et mises à jour multiples : c’est validé aussi. L'identification asymétrique serait-elle donc la cerise sur le gâteau ?

Authentification SSH et identification asymétrique

SSH autorisait l'identification asymétrique. Dans ce cas, les serveurs pouvaient utiliser la cryptographie pour garantir que les clés du client et du serveur étaient différentes. Cette garantie rendait les attaques de type « man-in-the-middle » presque impossibles puisqu'un pirate pouvait obtenir l'un des deux mots de passe mais pas les deux.

Voici comment fonctionne le protocole SSH

Étape 1 : le client SSH initie la connexion en contactant le serveur SSH.

Étape 2 : le serveur SSH envoie la clé publique.

Étape 3 : le serveur SSH et le client SSH négocient leurs protocoles et leurs contraintes.

Étape 4 : l'utilisateur peut alors se connecter et accéder à l'hôte du serveur.

Authentification SSH

Un autre avantage de l'utilisation du protocole SSH réside dans le fait qu'il propose différentes options d'authentification des utilisateurs. Un utilisateur peut les choisir en fonction du niveau de sécurité qu'il souhaite. Ces options sont les suivantes :

+ Authentification sur la base d'un mot de passe

Dans le cas de l'authentification par mot de passe, le serveur et le client utilisent un mot de passe et une clé pour authentifier la sincérité de la connexion.

+ Authentification par clé

L'authentification par clé s'applique à l'utilisation de clés publiques et privées. Un serveur possède une clé privée secrète et une clé publique qu'il envoie lorsqu'un client en fait la demande.

Les clés privées et publiques ne sont pas toujours semblables. Elles subissent cependant des modifications algorithmiques et des calculs qui donnent un résultat similaire. Si les algorithmes calculent une correspondance résultante entre les clés publiques et privées, le serveur accorde l'accès à l'utilisateur.

Quand utiliser le protocole SSH ?

Le protocole SSH a marqué une amélioration révolutionnaire. Ses nombreuses applications ont trouvé leur place dans les opérations quotidiennes de plusieurs entreprises B2B et B2C.  En voici quelques-unes :

+ Transfert de fichiers

Un seul mot : cryptage. Dans la mesure où SSH fait bon usage des algorithmes AES, il occupe une place particulière dans le cœur des dirigeants d’entreprise qui exigent le transfert sécurisé de données et de fichiers entre les points d'extrémité.

+ Livraison de mises à jour et de correctifs logiciels

L'utilisation de mots de passe pour authentifier les mises à jour ou les correctifs logiciels entre un serveur unique et des millions d'utilisateurs ne peut que mener au chaos. Pensez aux mises à jour de Tesla vers ses millions de voitures ou d'Apple vers ses milliards d'iPhones ! SSH vous permet d'automatiser l'authentification et de transmettre des mises à jour et des correctifs de manière transparente par le biais du transfert de données.

+ Automatisation du transfert de fichiers

Avec les systèmes existants, le transfert massif de fichiers entre vous-même et vos clients prendrait énormément de temps sans l'avantage d'un suivi et d'un contrôle centralisés. Demander aux clients de se souvenir de mots de passe pour recevoir correctement les fichiers serait tout aussi désastreux. Puisque le protocole SSH automatise l'authentification, le partage automatique de fichiers est beaucoup plus facile.

+ Entretien à distance de l'infrastructure réseau essentielle

L'époque où l'on gérait manuellement toute une infrastructure est révolue. De nos jours, vos équipes informatiques gèrent leurs systèmes d'exploitation, leurs routeurs et le matériel des serveurs à distance. Ce scénario rend nécessaire un système d'authentification sécurisé et automatisé pour le transfert de données, le meilleur étant SSH.

+ Réduire la dépendance à l'égard de la gestion des mots de passe

L'époque de l'authentification par mot de passe et clé symétrique a été un véritable enfer pour de nombreuses entreprises informatiques. De leur côté, le stockage de millions de mots de passe dans une base de données unique a toujours été une catastrophe en puissance. SSH et les clés privées et publiques permettent d'automatiser considérablement l'accès aux serveurs.

+ Processus automatisés de machine à machine

Les processus tels que les sauvegardes, les mises à jour de bases de données et les applications de surveillance de l'état du système sur des millions de machines peuvent être à la fois risqués et longs. L'authentification automatisée permet l'authentification des processus de machine à machine en transférant automatiquement les données et les clés sur des millions de machines.

+ SSH et authentification unique : un duo idéal

Ces dernières années, SSH a été largement utilisé. La capacité de SSH à automatiser l'authentification a donné naissance au Single Sign-On (SSO) et à l'accès sans mot de passe.

En d'autres termes, vos clients n'ont plus à saisir leur mot de passe chaque fois qu'ils accèdent à un serveur ou passent d'un serveur à l'autre. Cette fonctionnalité a permis de réduire le nombre de connexions et d'augmenter le nombre d'inscriptions puisque les clients empruntent le chemin de moindre résistance.

Bénéficiez dès aujourd'hui des avantages de SSH

En matière de sécurité des données, la frontière entre ce qui est satisfaisant et ce qui est excellent est ténue, et MOVEit est là pour vous aider à la franchir. Nous nous appuyons sur des protocoles de transfert sécurisés tels que SSH et SFPS ainsi que sur des années d'expérience pour vous proposer des capacités de partage de fichiers sécurisés inégalées. Si vous êtes prêt à passer de votre situation actuelle en matière de sécurité des données à un tout nouveau niveau de sécurité en matière de partage de fichiers, n’attendez plus, contactez-nous dès aujourd'hui.


Comments
Comments are disabled in preview mode.
Loading animation