GoFAST-Sync, l'étude d'une réplication automatique serveur de fichiers vers GoFAST

cpotter

CEO-Vision étudie actuellement le développement de GoFAST-Sync, un outil de réplication automatique envisagé pour notre nouvelle offre GoFAST-PCA/Données sensibles : un système de secours toujours opérationnel, qui serait hébergé sur une plateforme GoFAST en SaaS qualifié SecNumCloud (ou en on-premise si le marché le demande), totalement indépendant de l’infrastructure existante. Le principe envisagé : un ou plusieurs emplacements du serveur de fichiers Windows (dossiers et leurs arborescences complètes) seraient répliqués automatiquement vers un ou plusieurs espaces GoFAST, avec une perte de données maximale acceptable d'environ une heure en cas de sinistre.

Coté sécurité, une exigence de sécurité forte dès la conception : l'agent (sur le serveur de fichiers) n'accepterait jamais de connexion entrante, tout le trafic partirait de du serveur vers GoFAST, jamais l'inverse.

Le sens de la réplication resterait, en tout cas pour cette version initiale, par ailleurs strictement unidirectionnel : les fichiers circuleraient uniquement du serveur de fichiers vers GoFAST, jamais dans l'autre sens.

Si vous disposez encore d'un serveur de fichiers aujourd'hui, cette étude vous concerne aussi directement en dehors de ce contexte de secours : le serveur de fichiers est historiquement l'une des portes d'entrée privilégiées des rançongiciels — un risque que GoFAST, par construction, n'a pas, le serveur de fichiers est aussi très mauvais en terme de recherche, ne possède pas de versionning, etc...

Enfin, pour nos clients existants, en plus d’être un secours sur des documents clefs, cela permettrait une migration « douce » et plus globale du serveurs de fichiers vers GoFAST. De nombreux clients ont supprimé leur serveur de fichiers mais pas tous.

Dans le cadre de cette étude, 3 trois points sont ressortis comme des choix structurants :

A) Comment se ferait le rattachement entre une demande GoFAST de réplication dans un espace GoFAST et un emplacement réel du serveur de fichiers ?

Précision importante : ce ne serait en aucun cas le profil super-administrateur qui pourrait être à l'origine d'une telle demande — il ne dispose, et ne devrait jamais disposer, de droits sur les données elles-mêmes. Le profil envisagé pour cette autorité est l'administrateur d'espace, probablement en combinaison avec le profil ARDP (GoFAST 4.6, anciennement DPO/RSSI/Archiviste) — voire le profil ARDP seul (sans être dans l’espace cible donc), agissant en toute autonomie sur cette décision.

Note : Dans tous les cas, quel que soit ce profil, il ne verrait jamais l'arborescence réelle du serveur de fichiers. Il pourrait seulement demander qu'un emplacement y soit rattaché, donnant le chemin complet sur le serveur de fichiers — cette indication ne serait qu'un point de départ, jamais une valeur vérifiée par GoFAST. Une seconde validation, cette fois côté serveur de fichiers, resterait nécessaire : ce serait toujours quelqu'un ayant un accès local à votre serveur qui confirmerait le chemin réel.

Côté serveur de fichiers il y aurait donc une validation explicite — chaque demande apparaîtrait clairement "en attente", avec son contexte (qui la demande, pour quel espace), et devrait être explicitement acceptée ou refusée avant que le rattachement ne devienne effectif.
Ça pourrait ressembler à :

# gofast-sync-admin list-pending          ID_Demandeur          Espace GoFAST cible            Chemin suggéré                Statut 
                    liaison-042           jdupont@client.fr     Sites/.../Comptabilité         \\srv01\Compta (indication)   en attente

B) Un compte de lecture partagé, ou un compte par périmètre ?
Dans la version envisagée aujourd'hui, un seul compte technique pourrait lire l'ensemble des dossiers répliqués sur un serveur donné. Nous pourrions aussi (sûrement à terme) envisager des comptes distincts, limités chacun à un périmètre précis — plus de sécurité (un compte compromis n'exposerait qu'un périmètre limité), au prix d'une configuration un peu plus longue.

C) Que devrait-il se passer si un fichier répliqué est aussi modifié directement dans GoFAST ?
Puisque la réplication serait unidirectionnelle, une modification faite directement dans GoFAST sur un fichier déjà répliqué pose une vraie question au cycle de synchronisation suivant :

La version du serveur de fichiers l'emporte toujours (le plus simple, mais la modification faite dans GoFAST est alors ignorée mais conservé comme une ancienne version).
La version GoFAST l'emporte une fois modifiée (ce fichier précis arrêterait alors d'être mis à jour depuis le serveur de ficher).
Le conflit est signalé par la création d’un nouveau fichier mais renommé (« conflit ») pour ne pas écrasé la version modifiée sur GoFAST

Enfin, même si l’architecture technique serait un peu différente on peut imaginer après la réplication du serveur de fichiers de le faire pour des serveurs Nextcloud et/ou Sharepoint/OneDrive.

Il est bien évident que ceci est un projet très complexe pour l'instant en phase de faisabilité donc l'implémentation n'est pas pour tout de suite.

ebouchet

plutot intéressant comme principe.
L'utilisation duale me parait assez complexe, comment dans une organisation peut on avoir deux dépots actifs en meme temps. Je pense que ce cas est assez théorique.
Je plaide pour que l'utilitaire côté Windows etc... passe le dossier en readonly lors d'une migration vers gofast et que dans le cas d'un backup on ait hormis l'admin, uniquement des droits de lecture côté Gofast, sous forme de droits gérés par une liste d'accès , pour simplifier les raisonnements et eviter la complexité d'une resynchro post restauration suite a un crash.
Je verrais bien aussi dans un coin de gofast une petite option 'mapper en webdav' qui permettrait de générer les commandes bash/cmd/mac pour mapper nativement un noeud de type folder/espace dans un des OS du moment.
(cela pourrait être au niveau de l'annuaire d'espaces)