🔒Sécuriser les accès

Récapitulons ce que vous avez construit : une machine qui tourne 24/7, joignable depuis votre téléphone, qui expose des services sur Internet, et qui exécute des commandes proposées par une IA. C’est génial. C’est aussi une surface d’attaque qu’il faut prendre au sérieux, pas par paranoïa, par hygiène.

La bonne nouvelle : 90 % de la sécurité tient en quelques gestes simples, faits une fois. Cette fiche, c’est ces gestes. Aucun n’est compliqué. Les sauter, en revanche, peut transformer votre atelier en relais de spam ou pire.

1. SSH : des clés, jamais de mot de passe

L’accès à distance passe par SSH. Un mot de passe SSH exposé, c’est l’attaque numéro un sur Internet, des bots testent des millions de combinaisons par jour. La parade est définitive : on désactive l’authentification par mot de passe et on passe aux clés.

Une clé SSH, c’est une paire : une partie privée qui reste sur votre laptop (jamais ailleurs), une partie publique que vous déposez sur la machine. Sans la clé privée, impossible d’entrer, même en connaissant votre nom d’utilisateur.

# Sur votre laptop. Ed25519 = moderne, court, solide.
ssh-keygen -t ed25519 -C "laptop-vers-minipc"

ssh-copy-id ulrich@adresse-de-la-machine

PasswordAuthentication no
PermitRootLogin no

2. Le pare-feu : tout fermé, sauf l’essentiel

Par défaut, on bloque tout ce qui entre, et on ouvre au compte-gouttes. ufw rend ça trivial.

sudo ufw default deny incoming      # on refuse tout par défaut
sudo ufw default allow outgoing     # la machine peut sortir
sudo ufw allow 22/tcp               # SSH (ou rien si vous passez par Tailscale)
sudo ufw enable
sudo ufw status verbose             # vérifie

3. Les secrets : jamais en clair, jamais dans le code

Clés API, jetons, mots de passe de service : ce sont des secrets. La règle est absolue : un secret ne vit jamais en clair dans le code, ni dans un fichier versionné par git.

# Un fichier .env à la racine du projet
echo "ANTHROPIC_API_KEY=sk-..." >> .env
# Et SURTOUT, on l'exclut de git
echo ".env" >> .gitignore

chmod 600 .env ~/.ssh/id_ed25519   # lisible par vous seul

Où stocker vos clés, vraiment

Le fichier .env suffit pour démarrer, mais dès que vous accumulez des clés (API d’IA, tokens GitHub, accès à des services), posez-vous la question du bon coffre. Il y a une petite hiérarchie, du plus simple au plus solide :

• Le fichier .env par projet : le point de départ. Hors de git, en chmod 600. Parfait pour un projet perso. Sa limite : le secret est en clair sur le disque, et il se duplique de projet en projet.
• Le trousseau / gestionnaire de mots de passe : pour votre réserve personnelle de clés (la source de vérité), un vrai gestionnaire (Bitwarden, 1Password, KeePassXC…) chiffré vaut mille fichiers texte éparpillés. Vous y piochez pour remplir un .env quand vous en avez besoin.
• Un coffre chiffré au repos : pour stocker des secrets dans un dépôt sans les exposer, des outils comme sops + age ou pass chiffrent les valeurs : le fichier peut être versionné, seul celui qui a la clé de déchiffrement le lit. L’étape pro quand un projet grandit ou se partage.
• Un gestionnaire de secrets dédié : pour du sérieux multi-machines (Vault, Infisical, Doppler…), un service centralise, audite et fait tourner les secrets. Probablement au-delà de vos besoins au début, mais c’est là que mène le chemin.

4. Encadrer l’agent : il exécute, vous décidez

C’est la partie spécifique à notre setup, et la plus importante. Un agent de code est puissant **parce qu’**il peut lancer des commandes. C’est aussi ce qui le rend dangereux s’il file sans surveillance. Quelques règles de bon sens :

• Jamais d’agent en root, jamais en sudo automatique. Il tourne sous votre utilisateur normal. Quand une commande a besoin de sudo, vous voulez la voir et l’approuver à la main. Une commande destructrice lancée en root ne pardonne pas.
• Le mode « auto-approve » se mérite. Les agents proposent souvent un mode où ils exécutent sans vous demander. Génial pour itérer sur des tests ; à proscrire pour tout ce qui touche au réseau, aux secrets, aux suppressions de fichiers (rm), ou à la prod.
• Travaillez dans un dossier de projet, pas dans ~ ou /. Limitez le rayon d’action de l’agent au dossier du projet. S’il déraille, les dégâts restent confinés.
• Le code généré se relit avant de tourner en prod. Un agent peut introduire une faille sans le vouloir (une requête SQL mal échappée, une permission trop large). Une relecture, par vous, ou par un second agent en « revue », n’est pas un luxe.
• git est votre filet. Commits fréquents. Vous pouvez toujours revenir en arrière si l’agent a fait une bêtise. Un projet sans historique git, c’est un trapéziste sans filet.

5. Tenir la machine à jour (sans y penser)

Une faille corrigée n’en est plus une, à condition d’installer le correctif. On automatise les mises à jour de sécurité :

sudo apt install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades   # réponds "Oui"

La machine applique désormais seule les correctifs de sécurité. Pour le reste (montées de version), un sudo apt update && sudo apt upgrade de temps en temps suffit, votre agent peut vous le rappeler.

6. Le filet de sécurité : les sauvegardes

La sécurité, ce n’est pas que bloquer les intrus. C’est aussi survivre à votre propre erreur, à un disque qui lâche, à un agent trop zélé. Sauvegardez ce qui compte (vos projets, vos configs, vos .env, chiffrés) ailleurs que sur la machine : un autre disque, un NAS, un stockage distant. Une sauvegarde que vous n’avez jamais testé de restaurer n’est pas une sauvegarde.