{"id":2113,"date":"2018-03-27T23:01:54","date_gmt":"2018-03-27T21:01:54","guid":{"rendered":"https:\/\/blog.alwaysdata.com\/?p=2113"},"modified":"2018-03-27T23:01:54","modified_gmt":"2018-03-27T21:01:54","slug":"securiser-son-acces-distant-efficacement","status":"publish","type":"post","link":"https:\/\/blog.alwaysdata.com\/fr\/2018\/03\/27\/securiser-son-acces-distant-efficacement\/","title":{"rendered":"S\u00e9curiser son acc\u00e8s distant efficacement"},"content":{"rendered":"

Je vous ai r\u00e9cemment expliqu\u00e9 les choix qui vous reviennent<\/a> dans le choix de votre h\u00e9bergement. Dans les faits, ces choix concernent directement votre infrastructure technique, depuis votre OS et son param\u00e9trage jusqu\u2019\u00e0 l\u2019ensemble de votre architecture. Cela signifie que vous devez ajuster le curseur entre g\u00e9rer vous-m\u00eame certains aspects ou les confier \u00e0 un partenaire. Tout est affaire de confiance, et de co\u00fbts.<\/p>\n

S\u00e9curiser l\u2019acc\u00e8s \u00e0 distance est l\u2019un de ces \u00e9l\u00e9ments techniques \u00e0 prendre en compte. Certains points sont triviaux ; d\u2019autres n\u00e9cessitent des comp\u00e9tences importantes en s\u00e9curit\u00e9 et cryptographie. Cet article est ici pour vous donner un aper\u00e7u des mesures \u00e0 mettre en place pour bien s\u00e9curiser son acc\u00e8s distant. Il est parsem\u00e9 de liens vers des contenus plus avanc\u00e9s vers certaines techniques pour vous permettre d\u2019aller plus loin si vous le souhaitez1)<\/sup><\/a><\/span><\/span>2)<\/sup><\/a><\/span><\/span>.<\/p>\n

\"Cat<\/div>\n
\n

TL;DR<\/em> : la s\u00e9curit\u00e9 est un vaste domaine de connaissances o\u00f9 il est facile de se perdre. Si vous souhaitez seulement savoir comment bien configurer votre acc\u00e8s distant aux serveurs d\u2019alwaysdata<\/em>, int\u00e9ressez-vous simplement \u00e0 la section concernant la s\u00e9curisation des m\u00e9thodes d\u2019acc\u00e8s<\/a>.<\/p>\n

\n

Ne laissez pas n\u2019importe qui s\u2019introduire chez vous<\/h2>\n

Votre application s\u2019ex\u00e9cute sur des machines distantes, pour vous permettre d\u2019offrir un acc\u00e8s \u00e0 votre service de n\u2019importe o\u00f9. Vous n\u2019avez g\u00e9n\u00e9ralement pas d\u2019acc\u00e8s physique \u00e0 ces machines3)<\/sup><\/a><\/span><\/span>. Vous utilisez donc un acc\u00e8s distant pour y avoir acc\u00e8s. La plupart du temps, vous passerez par un shell<\/em> distant : SSH. SSH vous fournit un acc\u00e8s \u00e0 la fois \u00e0 une invite de commande et \u00e0 un navigateur de fichiers bas niveau sur la machine. Vous pouvez le voir comme une porte donnant sur votre salon. Ne pas vous en soucier est dangereux, voire inconscient.<\/p>\n

Un point important en mati\u00e8re de s\u00e9curit\u00e9 est la mani\u00e8re dont vous s\u00e9curisez cet acc\u00e8s \u00e0 vos serveurs de production. L\u00e0 encore, vous pouvez vouloir le faire par vous-m\u00eame, ou vous pouvez pr\u00e9f\u00e9rer vous appuyer sur l\u2019expertise d\u2019un partenaire qui saura le faire pour vous. Chez alwaysdata<\/em>, nous restons convaincus que cette seconde solution est presque toujours la meilleure, mais il reste malgr\u00e9 tout certains points que vous devrez g\u00e9rer seuls. Parce que ces points sont encore parfois obscurs, voici quelques conseils pour bien prot\u00e9ger votre acc\u00e8s distant.<\/p>\n

Un bon niveau de s\u00e9curit\u00e9 est un niveau que vous comprenez, et que vous pouvez administrer seul\u00b7e. Pour \u00eatre certains que vous disposerez de l\u2019expertise de base n\u00e9cessaire \u00e0 la bonne compr\u00e9hension de ces enjeux, nous allons voir ensemble quelques bases. Mon objectif n\u2019est pas de faire de vous un expert en s\u00e9curit\u00e9, seulement de vous donner de bonnes bases.<\/p>\n

La plupart des serveurs SSH sont par d\u00e9faut configur\u00e9s avec un niveau de s\u00e9curit\u00e9 correct. C\u2019est le cas d\u2019OpenSSH<\/a>, qui est le serveur SSH le plus couramment utilis\u00e9. Cependant, distribuer une configuration par d\u00e9faut signifie que les mainteneurs des paquets sur les distributions doivent g\u00e9rer le plus de cas d\u2019usages possible, plut\u00f4t que de maintenir un niveau de s\u00e9curit\u00e9 maximal. Ces configurations par d\u00e9faut permettent probablement de rejeter 90% des intrusions. Consid\u00e9rez \u00e7a comme installer une porte robuste \u00e0 votre maison ; mieux que rien, mais pas une porte blind\u00e9e non plus. Voyons comment renforcer ce niveau par d\u00e9faut.<\/p>\n

Be Safe, Be Smart<\/em><\/h2>\n

S\u00e9curiser son acc\u00e8s distant implique de s\u2019occuper d\u2019hygi\u00e8ne num\u00e9rique, notamment pour la partie client, qui reste \u00e0 votre charge. M\u00eame si votre serveur est bien s\u00e9curis\u00e9, vous pouvez avoir des probl\u00e8mes si vous n\u2019avez pas une protection suffisante c\u00f4t\u00e9 client.<\/p>\n

Utilisez une clef SSH pour vous connecter<\/h3>\n

Nous vous recommandons d\u2019utiliser une clef SSH pour vous connecter plut\u00f4t qu\u2019un mot de passe. De cette fa\u00e7on, vous pourrez plus facilement g\u00e9rer qui se connecte \u00e0 votre serveur, depuis quel appareil, et r\u00e9voquer finement les acc\u00e8s en cas d\u2019urgence4)<\/sup><\/a><\/span><\/span>. Une bonne pratique consiste \u00e0 avoir une paire de clefs5)<\/sup><\/a><\/span><\/span> par utilisateur et par appareil. Cela vous donnera la flexibilit\u00e9 n\u00e9cessaire \u00e0 la r\u00e9vocation de l\u2019appareil si celui-ci est perdu, vol\u00e9, ou mis hors service, plut\u00f4t que r\u00e9voquer l\u2019acc\u00e8s complet de l\u2019utilisateur.<\/p>\n

Pour savoir comment g\u00e9n\u00e9rer une clef s\u00e9curis\u00e9e \u00e0 jour, reportez-vous \u00e0 la section concernant le format ed25519<\/a>.<\/p>\n

Ne vous connectez pas via<\/em> un mot de passe<\/h3>\n

Les mots de passe ne pr\u00e9sentent pas une robustesse de protection suffisante pour \u00e9viter \u00e0 vos acc\u00e8s distants une potentielle compromission. Vous devriez utiliser une authentification par clefs <\/sup><\/a>pour vous assurer que votre utilisateur distant est prot\u00e9g\u00e9 contre une attaque par force brute qui tentera de trouver le mot de passe de votre utilisateur.<\/p>\n

Chez alwaysdata<\/em>, la connexion SSH par mot de passe est d\u00e9sactiv\u00e9e par d\u00e9faut, et seules les connexions par clefs SSH sont autoris\u00e9es. Vous devez entrer vous-m\u00eame votre clef publique dans le fichier ~\/.ssh\/authorized_keys<\/code>6)<\/sup><\/a><\/span><\/span>. Si vous avez besoin d\u2019activer la connexion par mot de passe malgr\u00e9 tout (par exemple, pour transf\u00e9rer votre clef publique la premi\u00e8re fois), vous pouvez le faire en cochant la case idoine dans la section SSH de votre interface d\u2019administration. Gardez \u00e0 l\u2019esprit que cette m\u00e9thode est peu s\u00e9curis\u00e9e et ne devrait pas \u00eatre activ\u00e9e en permanence.<\/p>\n

Si vous configurez votre serveur personnel, apr\u00e8s avoir copi\u00e9 votre clef publique sur le serveur<\/strong>, d\u00e9sactivez la connexion par mot de passe <\/sup><\/a> dans le fichier de configuration sshd<\/code>.<\/p>\n

# \/etc\/ssh\/sshd_config\n\nAuthenticationMethods public key\nPubkeyAuthentication yes\nChallengeResponseAuthentication no\nPasswordAuthentication no\nUsePAM no\n<\/code><\/pre>\n
Certains utilisateurs et administrateurs semblent croire que ne pas utiliser de mot de passe pour prot\u00e9ger l\u2019acc\u00e8s \u00e0 leur compte est une bonne pratique. Je pense personnellement que m\u00eame un mot de passe tr\u00e8s faible est une meilleure id\u00e9e que pas de mot de passe du tout. Quoi qu\u2019il en soit, interdisez \u00e0 ces utilisateurs sans mot de passe de se connecter \u00e0 distance sans aucune protection.<\/p>\n
# \/etc\/ssh\/sshd_config\n\nPermitEmptyPasswords no\n<\/code><\/pre>\n
Les mots de passe vides sont rejet\u00e9s en SSH chez alwaysdata<\/em>.<\/p>\n
Utilisez des phrases de s\u00e9curit\u00e9<\/h3>\n
Utiliser des clefs robustes est essentiel, mais vous ne pouvez garantir leur s\u00e9curit\u00e9 sans les prot\u00e9ger. Cela signifie que chaque clef SSH doit avoir une phrase de s\u00e9curit\u00e9 unique et solide. Cela s\u2019applique aussi \u00e0 vos mots de passe utilisateur, j\u2019utilise la m\u00eame technique pour les g\u00e9n\u00e9rer.<\/p>\n
Il existe (au moins) deux fa\u00e7ons de g\u00e9n\u00e9rer des phrases al\u00e9atoires en ligne de commande7)<\/sup><\/a><\/span><\/span> :<\/p>\n
$ openssl rand -base64 32\n$ gpg --gen-random --armor 1 32\n<\/code><\/pre>\n
Vous devriez disposer de openssl rand<\/code> ou de gpg<\/code> (voire des deux) sur votre syst\u00e8me d\u2019exploitation. Je vous conseille de tester la robustesse de votre mot de passe ainsi g\u00e9n\u00e9r\u00e9 avec l\u2019outil How Secure Is My Password<\/a>. Vous ne voudriez pas qu\u2019un mot de passe un peu faible compromette toute votre s\u00e9curit\u00e9, n\u2019est-ce pas ?<\/p>\n
Utilisez des clefs de chiffrement physique<\/h3>\n
Si vous \u00eates vraiment soucieux de la s\u00e9curit\u00e9 de votre acc\u00e8s distant, vous devriez consid\u00e9rer l\u2019utilisation d\u2019un certificat client pour vous connecter, coupl\u00e9 \u00e0 une clef physique. De cette fa\u00e7on, vous conserverez le certificat en s\u00e9curit\u00e9. Vous pouvez utiliser une clef de chiffrement physique comme les Nitrokey Pro<\/a> ou YubiKey 4<\/a> pour stocker vos clefs et certificats d\u2019authentification client.<\/p>\n
\"@Giphy\"<\/div>\n
Restez \u00e0 jour<\/h2>\n
Gardez votre serveur SSH \u00e0 jour<\/h3>\n
Des failles SSH sont r\u00e9guli\u00e8rement d\u00e9couvertes (personne n\u2019est jamais exempt de bogues) et corrig\u00e9es rapidement par les contributeurs des projets et distributions. C\u2019est donc toujours une bonne id\u00e9e de garder votre serveur \u00e0 jour. Ceci implique \u00e9galement de conserver votre client SSH<\/em> \u00e0 jour. Au moment o\u00f9 j\u2019\u00e9cris ces lignes, la derni\u00e8re version d\u2019OpenSSH<\/a> est la 7.6 sortie le 3 oct. 2017 en<\/sup><\/a>. Vous pouvez v\u00e9rifier votre version facilement :<\/p>\n
$ ssh -V\nOpenSSH_7.6p1, OpenSSL 1.1.0g  2 Nov 2017\n<\/code><\/pre>\n
Utilisez le protocole SSH v2<\/h3>\n
SSH dispose de deux versions de son protocole en<\/sup><\/a>. La version moderne courante est la v2. Elle est plus s\u00fbre, plus robuste, plus souple, et utilise des m\u00e9thodes de chiffrement plus r\u00e9centes et plus fiables. La plupart des clients supportent la v2 depuis un bon moment maintenant, donc pensez \u00e0 d\u00e9sactiver le support de la v1 sur votre propre serveur :<\/p>\n
# \/etc\/ssh\/sshd_config\n\nProtocol 2    # defaults to \"2,1\"\n<\/code><\/pre>\n
Pour des raisons de compatibilit\u00e9, nous proposions encore le support de la v1 chez alwaysdata<\/em>. Depuis la sortie d\u2019OpenSSH 7.6, celle-ci est d\u00e9sormais totalement retir\u00e9e du code source (elle n\u2019est plus activable m\u00eame par le biais d\u2019une compilation personnalis\u00e9e), v\u00e9rifiez donc que vous \u00eates \u00e0 jour.<\/p>\n
Utilisez des clefs SSH ED25519 robustes<\/h3>\n
Il existe plusieurs formats de clefs SSH. De pr\u00e9f\u00e9rence, utilisez un algorithme ED25519<\/code><\/a>, puisqu\u2019il pr\u00e9sente le meilleur choix actuellement en<\/sup><\/a> en termes de s\u00e9curit\u00e9 en<\/sup><\/a>. Il est relativement r\u00e9cent, mais assez bien support\u00e9 en<\/sup><\/a> en production \u00e0 pr\u00e9sent, et si vous g\u00e9rez votre serveur (ou passez par un prestataire de qualit\u00e9), assurer son support c\u00f4t\u00e9 serveur reste trivial.<\/p>\n
$ ssh-keygen -a 1000 -t ed25519 -C yourmail@yourmachine.name\n<\/code><\/pre>\n
Cette commande va :
 \u2013 g\u00e9n\u00e9rer une nouvelle paire de clefs
 \u2013 -a<\/code> en r\u00e9glant le nombre de cycles de la fonction de d\u00e9rivation employ\u00e9e \u00e0 1000, pour augmenter le niveau de s\u00e9curit\u00e9 et le temps de d\u00e9chiffrement. Si la vitesse d\u2019authentification est cruciale pour vous, vous pouvez diminuer cette valeur (par d\u00e9faut \u00e0 16 ; 100 offrant une protection suffisamment robuste contre des attaques de force brute)
 \u2013 -t<\/code> r\u00e9gler le format \u00e0 utiliser sur l\u2019algorithme ed25519<\/code>
 \u2013 -C<\/code> identifier cette clef sur le mod\u00e8le \u00ab nom d\u2019utilisateur \u00bb\/\u00ab appareil \u00bb<\/p>\n
La protection r\u00e9seau<\/h2>\n
Cette section contient des m\u00e9thodes principalement \u00e0 destination des sysadmins qui souhaitent un haut niveau de s\u00e9curisation. Elles peuvent, ou pas, s\u2019appliquer selon vos contextes et votre mod\u00e8le de menaces. Dans les faits, les deux parties ci-dessus doivent suffire pour s\u00e9curiser proprement la plupart de vos acc\u00e8s distants. Mais vous pouvez avoir besoin d\u2019augmenter votre s\u00e9curit\u00e9 d\u2019un cran encore.<\/p>\n
Filtrez l\u2019acc\u00e8s au port TCP avec votre pare-feu<\/h3>\n
Si vous vous connectez toujours \u00e0 vos serveurs depuis un parc d\u2019IP d\u00e9di\u00e9, il est inutile (voire dangereux) de laisser n\u2019importe quelle connexion entrante tenter des authentifications. N\u2019h\u00e9sitez pas \u00e0 restreindre l\u2019authentification SSH aux adresses connues dans vos r\u00e8gles de pare-feu.<\/p>\n
$ iptables -A INPUT -p tcp -s 10.111.111.10 -d 192.168.1.12 --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT\n$ iptables -A OUTPUT -p tcp --sport 22 -m conntrack --ctstate ESTABLISHED -j ACCEPT\n<\/code><\/pre>\n
Ici, nous autorisons seulement l\u2019IP 10.111.111.10<\/code> (\u00e9videmment, substituez la v\u00f4tre) \u00e0 se connecter au port 22<\/code> en TCP sur l\u2019adresse locale de la machine (192.168.1.12<\/code>) en utilisant iptables en<\/sup><\/a>8)<\/sup><\/a><\/span><\/span>. La gestion d\u2019un pare-feu est souvent compliqu\u00e9e, mais c\u2019est une de vos d\u00e9fenses les plus robustes contre les attaques que vous aurez \u00e0 subir.<\/p>\n
Certaines de nos machines alwaysdata<\/em>, qui sont en charge de sections priv\u00e9es de notre architecture, ont leur acc\u00e8s public filtr\u00e9 de cette fa\u00e7on. Si vous avez un VPS<\/a> ou un serveur d\u00e9di\u00e9<\/a>, vous pouvez activer ce filtrage IP dans l\u2019interface d\u2019administration<\/a> pour vous assurer que seules vos IPs sont autoris\u00e9es \u00e0 se connecter \u00e0 vos serveurs.<\/p>\n
Rejetez les attaquants SSH<\/h3>\n
L\u2019un des probl\u00e8mes provoqu\u00e9s par des attaquants qui tenteraient de p\u00e9n\u00e9trer votre syst\u00e8me est le nombre important de requ\u00eates qu\u2019ils vont g\u00e9n\u00e9rer vers votre infrastructure. M\u00eame s\u2019ils ne parviennent pas \u00e0 obtenir un acc\u00e8s, ces tentatives vont surcharger votre serveur SSH, probablement ralentir votre syst\u00e8me, et peut-\u00eatre aboutir \u00e0 un DDoS. Pour \u00e9viter cela, vous pouvez utiliser votre pare-feu pour bloquer les IPs des machines attaquantes. Bien entendu, il n\u2019est pas question de les bloquer manuellement. Vous devriez plut\u00f4t vous appuyer sur des outils comme fail2ban<\/a>, DenyHosts<\/a>, ou sur des r\u00e8gles de pare-feu avec iptables ou ufw<\/a> pour un bannissement temporaire automatique.<\/p>\n
Chez alwaysdata<\/em>, les serveurs SSH sont prot\u00e9g\u00e9s par un filtrage fail2ban<\/em>.<\/p>\n
Modifiez le port SSH par d\u00e9faut<\/h3>\n
OpenSSH \u00e9coute sur le port 22<\/code> par d\u00e9faut. Ce r\u00e9glage le rend vuln\u00e9rable dans le sens o\u00f9 les attaquants vont d\u2019abord essayer ce port pour tenter de cibler des failles SSH. Si vous n\u2019avez pas besoin d\u2019une compatibilit\u00e9 avec des clients externes, vous devriez changer ce port par d\u00e9faut et les interfaces r\u00e9seau sur lesquelles le serveur SSH \u00e9coute pour r\u00e9duire sa surface d\u2019attaque.<\/p>\n
# \/etc\/ssh\/sshd_config\n\nPort 2002\nListenAddress 192.168.1.5\n<\/code><\/pre>\n
Port knocking<\/em><\/h3>\n
C\u2019est l\u2019une des techniques de pr\u00e9vention les plus amusantes.<\/p>\n
Cette m\u00e9thode consiste \u00e0 forcer l\u2019utilisateur qui souhaite se connecter au serveur SSH \u00e0 se connecter avant \u00e0 une s\u00e9rie de ports dans un ordre pr\u00e9cis pour d\u00e9clencher une r\u00e8gle de pare-feu qui ouvrira alors temporairement l\u2019acc\u00e8s au port SSH pour votre IP. En utilisant l\u2019outil d\u00e9di\u00e9 knock<\/em>, vous contacterez votre serveur sur une s\u00e9quence de ports. Si la s\u00e9quence est correcte, le pare-feu est mis \u00e0 jour et une nouvelle r\u00e8gle est ajout\u00e9e pour votre IP vers le port SSH. Vous pouvez alors vous connecter. Simple, sobre, \u00e9l\u00e9gant9)<\/sup><\/a><\/span><\/span>). Cette technique utilise knockd en<\/sup><\/a>.<\/p>\n
Divers<\/h2>\n
C\u2019est la derni\u00e8re section. F\u00e9licitations d\u2019avoir lu cet article jusqu\u2019ici ! Elle pr\u00e9sente des astuces pour augmenter encore un peu votre s\u00e9curit\u00e9. Elles sont souvent superflues, mais il est toujours bon de les conna\u00eetre.<\/p>\n
Validez les empreintes de clefs SSH du serveur<\/h3>\n
Pour s\u2019authentifier aupr\u00e8s du client, un serveur SSH pr\u00e9sente l\u2019empreinte de sa clef pour pouvoir \u00eatre reconnu. Cette clef est g\u00e9n\u00e9r\u00e9e automatiquement et appartient \u00e0 une unique instance de serveur SSH. Il y a une clef par algorithme support\u00e9, et elles sont toutes pr\u00e9sent\u00e9es au client selon ses pr\u00e9f\u00e9rences. Vous pouvez comparer cette empreinte de clef \u00e0 votre premi\u00e8re connexion avec celle indiqu\u00e9e dans votre interface d\u2019administration SSH<\/a> pour vous assurer que vous contactez bien le bon serveur.<\/p>\n
Les clients modernes supportant tous ED25519 en<\/sup><\/a>, vous pouvez uniquement servir cette clef serveur et d\u00e9sactiver les autres clefs \/ m\u00e9thodes sur votre serveur :<\/p>\n
# \/etc\/ssh\/sshd_config\n\n#HostKey \/etc\/ssh\/ssh_host_dsa_key\n#HostKey \/etc\/ssh\/ssh_host_rsa_key\n#HostKey \/etc\/ssh\/ssh_host_ecdsa_key\nHostKey \/etc\/ssh\/ssh_host_ed25519_key\n<\/code><\/pre>\n
Chez alwaysdata<\/em>, pour d\u2019\u00e9videntes raisons de compatibilit\u00e9, nous continuons de pr\u00e9senter tous les formats disponibles.<\/p>\n
D\u00e9sactivez l\u2019acc\u00e8s root<\/code><\/h3>\n
L\u2019utilisateur root<\/code> de votre machine est le super administrateur de votre syst\u00e8me Unix. Cet utilisateur a tous les droits sur votre machine, y compris l\u2019effacer compl\u00e8tement10)<\/sup><\/a><\/span><\/span>. La plupart du temps, vous n\u2019avez pas besoin d\u2019\u00eatre root\u00e9<\/em> pour vos actions courantes sur votre machine, et vos permissions syst\u00e8me sont l\u00e0 pour vous permettre d\u2019ex\u00e9cuter vos commandes en toute s\u00e9curit\u00e9. D\u00e9sactiver l\u2019acc\u00e8s distant \u00e0 l\u2019utilisateur root<\/code> est donc un bon r\u00e9flexe, tout comme le fait de le d\u00e9sactiver localement et toujours utiliser sudo<\/code> pour ex\u00e9cuter des commandes root<\/em>. Ainsi, m\u00eame si un utilisateur malveillant r\u00e9ussit \u00e0 avoir acc\u00e8s au serveur, il ne pourra pas s\u2019octroyer facilement les privil\u00e8ges root<\/em>.<\/p>\n
# \/etc\/ssh\/sshd_config\n\nPermitRootLogin no\n<\/code><\/pre>\n
Diminuez le temps de d\u00e9connexion en cas d\u2019inactivit\u00e9<\/h3>\n
Limiter le temps d\u2019inactivit\u00e9 d\u2019un utilisateur est un bon moyen de pr\u00e9venir l\u2019utilisation malicieuse qui pourrait \u00eatre faite de son compte. Diminuez le nombre maximum de connexions inactives simultan\u00e9es et le temps maximum d\u2019inactivit\u00e9 pour vous assurer que personne ne reste plus longtemps dans le syst\u00e8me que n\u00e9cessaire.<\/p>\n
# \/etc\/ssh\/sshd_config\n\nClientAliveInterval 300\nClientAliveCountMax 0\n<\/code><\/pre>\n
Enfermez les utilisateurs (chroot<\/em>)<\/h3>\n
Les utilisateurs authentifi\u00e9s via<\/em> SSH peuvent acc\u00e9der \u00e0 l\u2019int\u00e9gralit\u00e9 du syst\u00e8me de fichiers distant. Ils sont isol\u00e9s par les contraintes du syst\u00e8me et les permissions des fichiers. Les enfermer dans leur espace utilisateur peut \u00eatre une bonne id\u00e9e. Malheureusement, ce n\u2019est pas toujours facile \u00e0 mettre en pratique et cela requiert souvent de s\u2019appuyer sur des outils comme rssh en<\/sup><\/a>. C\u2019est une configuration complexe, mais si votre mod\u00e8le de menaces implique des risques de fuites de donn\u00e9es mal prot\u00e9g\u00e9es, c\u2019est sans doute \u00e0 consid\u00e9rer.<\/p>\n
\"wonder<\/div>\n
\n
J\u2019esp\u00e8re que ce long billet de blog vous a permis de mieux comprendre les enjeux li\u00e9s \u00e0 la protection des acc\u00e8s \u00e0 distance. G\u00e9rer l\u2019ensemble de la s\u00e9curit\u00e9 de sa pile technique n\u00e9cessite des comp\u00e9tences avanc\u00e9es, notamment en cryptographie. Les conseils de cet article sont destin\u00e9s \u00e0 mieux vous \u00e9quiper, mais ne sous-estimez pas la difficult\u00e9 de s\u00e9curiser tout votre syst\u00e8me. Travailler avec des partenaires ayant plus d\u2019expertise reste la meilleure fa\u00e7on d\u2019assurer votre protection. C\u2019est ce que nous faisons chez alwaysdata<\/em> : nous nous assurons de g\u00e9rer au mieux l\u2019arbitrage flexibilit\u00e9 \/ s\u00e9curit\u00e9.<\/p>\n
Si vous avez envie de discuter de cybers\u00e9cu, je serai au Breizhcamp de Rennes vendredi pour parler de cryptographie et de d\u00e9veloppement. Faites signe !<\/p>\n
 
Notes<\/span>[+<\/a>]<\/span><\/p><\/div> 
 \n\n
Notes<\/caption> 
 \u2191<\/span>1<\/a><\/th> duckduckgoing<\/a>\/qwanting<\/a> les ressources qui vous manquent est \u00e9galement une bonne option<\/td><\/tr>\n\n
 \u2191<\/span>2<\/a><\/th> n\u2019h\u00e9sitez pas \u00e0 poser vos questions dans les commentaires \u00e9galement :) <\/td><\/tr>\n\n
 \u2191<\/span>3<\/a><\/th> et heureusement : vous ne voulez courir le monde pour mettre \u00e0 jour vos machines une par en vous y connectant physiquement<\/td><\/tr>\n\n
 \u2191<\/span>4<\/a><\/th> ou quand vos collaborateurs partent<\/td><\/tr>\n\n
 \u2191<\/span>5<\/a><\/th> publique et priv\u00e9e<\/td><\/tr>\n\n
 \u2191<\/span>6<\/a><\/th> nous vous permettrons bient\u00f4t de saisir dans votre interface d\u2019administration votre clef publique directement<\/td><\/tr>\n\n
 \u2191<\/span>7<\/a><\/th> veillez \u00e0 bien les stocker ensuite dans un gestionnaire de<\/a> mots de passe<\/a><\/td><\/tr>\n\n
 \u2191<\/span>8<\/a><\/th> vous pouvez jeter un \u0153il \u00e0 ufw en<\/sup><\/a> \u00e9galement pour \u00e9crire vos r\u00e8gles de pare-feu<\/td><\/tr>\n\n
 \u2191<\/span>9<\/a><\/th> because we can<\/em> :<\/td><\/tr>\n\n
 \u2191<\/span>10<\/a><\/th> pour rappel, on ne rm \u2011fr \/ jamais \u00e0 l\u2019aveugle<\/td><\/tr>\n\n <\/tbody> <\/table> <\/div><\/div>