--- title: "" tags: - meeting type: "meeting" univers: PRO projects: - "[[02_DOMAINES/PRO-INFORMATIQUE]]" date: "2026-07-30" heure: "14h00/15h30" lieu: "visio" priority: 10 --- # 20260730 - 14h00/15h30 - [[02_DOMAINES/PRO-INFORMATIQUE]] - Réunion avec Opteos sur évolution serveur FTP :abandon FTP, sécurisation, sauvegarde ## Participants - BCH - SAR - JPR - GRK ## Notes Personnelles ### Sujets abordés: 1. Connexion SSH avec clé 2. Abandon du protocole FTP 3. Double authentification pour les applications fonctionnant sur le serveur 4. Sauvegarde du serveur ### 1. Connexion SSH avec clé Nécessité que chacun crée une clé privée et publique (format ED25519). Transmettre clé publique à Sylvain pour la configuration. Action à mener: - [x] [[02_DOMAINES/PRO-INFORMATIQUE]] - Créer clé SSH au format ED25519 et transmettre la clé publique à SAR [date: 2026-08-11] Cf. https://www.datagrandest.fr/portal/g/:spaces:appuie_technique_a8_dge28_opteos/home/notes/1740 Les clés sont créées. Il faut les tester sous OMV (besoin de retrouver le mot de passe...) Mot de passe de réinitialisation : wBK6gN@rU^%w@Q6kQn3ah&K6!r ### 2. Abandon du protocole FTP Le protocole HTTP est privilégié pour le téléchargement. Le protocole SFTP est privilégié pour le dépôt. Pour le téléchargement HTTP voir si des solutions type JDownloader sont intéressantes. Faire un benchmark rapide de téléchargement de données. Benjamin contacte Géo2France pour savoir s'ils ont déjà eu des problèmes de téléchargement HTTP. Nécessité de mettre en place un support/tuto pour la création des clés SSH. Privilégier le **format ED25519** plus sécurisé que RSA. Putty utilise un format PSK spécifique. Volume : 5 utilisateurs à accompagner par an. Gestion des utilisateurs dans OMV: * Informer les utilisateurs de la démarche et les accompagner dans la création d'une clé SSH. * Ajouter les clés publiques d'utilisateurs dans OMV * Prévoir de désactiver les comptes temporaires et de gérer les dates de période. Action amener: * Lister les utilisateurs actuels. * Supprimer les utilisateurs si nécessaires. * Rédiger une documentation pour la création des clés * Informer les utilisateurs qui ont déjà un compte. * Accompagner les utilisateurs dans la création de leurs clés SSH. * Mettre à jour les comptes avec les clés SSH pour la connexion SFTP. * Mettre à jour la documentation du serveur FTP Q: Faut-il créer une clé unique ou une clé pour chaque application ? R: Si je la recommande, utilisez plutôt une clé unique. Echéance : octobre 2026 Question : Faut-il trouver un nouveau nom au serveur FTP ? ;-) ### 3. Double authentification pour les applications fonctionnant sur le serveur Privilégier le système de double authentification TOTP. **Open Media Vault:** La version actuelle de OMV ne permet pas la double authentification. La nouvelle version installée sur le serveur de dev le permet. Attendre la mise à jour pour la mise en place de la mouvement. **Forgejo:** Sylvain a mis en place les éléments pour la double authentification. - [x] [[02_DOMAINES/PRO-INFORMATIQUE]] - Activer la double authentification sur Forgejo [date: 2026-08-11] **Zabbix:** La double authentification reste à mettre en place sur Zabbix. La question de la gestion des mots de passe partagés reste posée. Une solution centralisée est à prévoir. Que faut-il privilégier ? À la région, certains utilisent Keepass. Sylvain utilise BitWarden. Echéance : septembre 2026 ### 4. Sauvegarde du serveur Trois questions sont posées: Quoi, où, comment ? **Quoi ?** * Le système * l'environnement Docker (avec configuration et données) * Les données stables partagées, traitement et validation. Volume : * 35 To mais du ménage à faire (attention au micro-management) * Faut-il tout garder ? (ex.: JPEG2000 + COG) * Si oui, données sources à mettre éventuellement sur le serveur Région. * Rappelez que DataGrandEst ne constitue pas un service de sauvegarde pour les partenaires, uniquement de partage. * Évaluation actuelle : 40 à 50 To **Où ?** * L'intérêt de faire une sauvegarde d'un serveur sur l'autre est limité. * Guillaume peut se renseigner pour disposer d'un serveur interne à la Région => Nécessite une estimation des volumes nécessaires. * Avantages du serveur Région : respecte le principe du “3, 2, 1” (3 sauvegardes sur 2 support dont 1 hors réseau ou facilement déconnectable). **Comment ?** Solutions de backup envisagées: * Rsync : uniquement une copie complète (mirroring) * Rsnapshot : Rsync + historique * Restic : chiffrement + compression + déduplication En ligne de commande. Sylvain connaît bien: utilisé chez Pâquerette * Kopia : chiffrement + compression + déduplication Avantage : interface web pour la gestion et la restauration des fichiers. * Borg Backup : chiffrement + compression + déduplication Facile à mettre en place : intégré directement à OMV. Semble très complet. Approche CLI + Web Solution retenue : Borg Backup Action à mener: * Faire du nettoyage sur le serveur * Évaluer plus finement le volume nécessaire pour la sauvegarde. * Préciser l'architecture et processus de ce sauvegarde. * Installer Borg Backup sur OMV et tester la synchronisation serveur de PROD vers serveur de DEV Echéance : septembre 2026 --- --- Synthèse IA à partir de la transcription de la réunion. ## Compte Rendu - Réunion Sécurisation FTP & Sauvegarde **Sujet principal :** Réflexion sur la sécurisation des services FTP et choix des solutions de sauvegarde **Date et heure :** 31 juillet 2026 (14:06 - 15:21) **Participants identifiés :** Guillaume, Benjamin, Jean-Pierre, Sylvain **Objectif de la réunion :** Discuter de la sécurisation du serveur FTP (passage à SFTP) et valider le choix de la solution de sauvegarde Borg pour Open MediaVol. --- ### Sujets abordés - Sécurisation du serveur FTP : passage à SFTP avec authentification par clé (et non par mot de passe). - Impact de cette migration sur les utilisateurs (besoin de support pour la création de clés). - Validation de l’utilisation de **Borg** comme solution de sauvegarde pour Open MediaVol. - Nettoyage préalable des données avant la première sauvegarde. --- ### Synthèse exécutive - **Migration FTP → SFTP** : Décision de basculer vers SFTP pour renforcer la sécurité, malgré la perte de la connexion FTP anonyme (remplaçable par HTTP/navigateur). - **Support utilisateurs** : Anticipation d’un besoin d’accompagnement pour la création de clés (format RSA/Ed25519) et la configuration des comptes. - **Sauvegarde** : Borg est retenu pour sa rapidité de déploiement et son efficacité. Priorité au nettoyage des données avant la première sauvegarde. - **Public concerné** : Une dizaine d’utilisateurs (2 à 5 par an) pour des dépôts/téléchargements de fichiers sensibles (ex. : dalles, orthophotos). --- ### Décisions actées - Remplacement du FTP par SFTP avec authentification par clé publique. - Création de comptes SFTP pour les utilisateurs concernés, avec dépôt de leur clé publique par l’équipe technique. - Déploiement de Borg pour les sauvegardes Open MediaVol, avec nettoyage préalable des données inutiles. - Ouverture d’un compte dédié chez Data Grantesse si besoin pour gérer la création des comptes SFTP. --- ### Plan d'Action Opérationnel | Tâche / Action | Responsable | Échéance | Statut / Livrable attendu | | :------------------------------------------------------------- | :---------------- | :---------------------------- | :-------------------------------------------------------- | | Préparer un document explicatif sur la migration FTP → SFTP | \[Non précisé\] | \[Non précisé\] | Document partagé avec les utilisateurs | | Configurer les comptes SFTP et déposer les clés publiques | Équipe technique | \[Non précisé\] | Compte SFTP fonctionnel pour chaque utilisateur concerné | | Nettoyer les données inutiles sur le serveur avant sauvegarde | \[Non précisé\] | Avant la première sauvegarde | Serveur prêt pour la sauvegarde | | Déployer Borg pour les sauvegardes Open MediaVol | \[Non précisé\] | \[Non précisé\] | Solution Borg opérationnelle | | Former/supporter les utilisateurs à la création de clés | Équipe technique | \[Non précisé\] | Utilisateurs autonomes pour SFTP | --- ### Questions en suspens & Risques identifiés - **Sujets non tranchés :** - Format des clés à privilégier (RSA vs Ed25519) : à clarifier pour les utilisateurs. - Modalités précises de nettoyage des données avant sauvegarde (qui fait quoi ?). - **Points de blocage / Risques :** - Charge supplémentaire de support pour les utilisateurs non familiers avec les clés SSH. - Risque de retard si le nettoyage des données n’est pas fait à temps. - **Prochaine étape :** Aucune date de réunion suivante mentionnée.