GoFAST-Sync — feasibility study: automatic file server replication to GoFAST

cpotter

Translation into English (formatting preserved as in the original):

CEO-Vision is currently studying the development of GoFAST-Sync, an automatic replication tool being considered for our new GoFAST-PCA/Sensitive Data offering: an always-operational backup system, which would be hosted on a GoFAST platform in SecNumCloud-qualified SaaS (or on-premise if the market calls for it), entirely independent of the existing infrastructure. The principle under consideration: one or more locations on the Windows file server (folders and their complete tree structures) would be automatically replicated to one or more GoFAST workspaces, with a maximum acceptable data loss of approximately one hour in the event of a disaster.

On the security side, a strong security requirement by design: the agent (on the file server) would never accept an inbound connection; all traffic would originate from the server towards GoFAST, never the other way round.

The direction of replication would also remain strictly unidirectional, at least for this initial version: files would travel only from the file server to GoFAST, never in the opposite direction.

If you still operate a file server today, this study also concerns you directly outside this backup context: the file server has historically been one of the preferred entry points for ransomware — a risk that GoFAST, by design, does not have. The file server is also very poor in terms of search, has no versioning, etc.

Finally, for our existing customers, in addition to providing a backup for key documents, this would enable a "gentle" and more comprehensive migration from the file server to GoFAST. Many customers have decommissioned their file server, but not all.

As part of this study, 3 three points have emerged as structuring choices:

A) How would the link be established between a GoFAST replication request in a GoFAST workspace and an actual location on the file server?

An important clarification: under no circumstances would the super-administrator profile be the originator of such a request — it does not have, and should never have, rights over the data itself. The profile envisaged for this authority is the workspace administrator, probably in combination with the ARDP profile (GoFAST 4.6, formerly DPO/CISO/Archivist) — or even the ARDP profile alone (i.e. without being a member of the target workspace), acting with full autonomy on this decision.

Note: In all cases, whatever the profile, it would never see the actual tree structure of the file server. It could only request that a location be linked, providing the full path on the file server — this indication would only ever be a starting point, never a value verified by GoFAST. A second validation, this time on the file server side, would remain necessary: it would always be someone with local access to your server who confirms the actual path.

On the file server side there would therefore be an explicit validation — each request would appear clearly as "pending", with its context (who is requesting it, for which workspace), and would have to be explicitly accepted or refused before the link becomes effective.
It could look like this:

# gofast-sync-admin list-pending          Requester ID          Target GoFAST workspace        Suggested path                Status 
                    liaison-042           jdupont@client.fr     Sites/.../Accounting           \\srv01\Compta (indication)   pending

B) A shared read account, or one account per perimeter?
In the version currently envisaged, a single technical account could read all the replicated folders on a given server. We could also (most likely in the longer term) consider separate accounts, each limited to a specific perimeter — more security (a compromised account would only expose a limited perimeter), at the cost of a slightly longer configuration.

C) What should happen if a replicated file is also modified directly in GoFAST?
Since replication would be unidirectional, a modification made directly in GoFAST to an already-replicated file raises a real question for the next synchronisation cycle:

The file server version always wins (the simplest option, but the modification made in GoFAST is then ignored, though retained as a previous version).
The GoFAST version wins once modified (that specific file would then stop being updated from the file server).
The conflict is flagged by creating a new file, but renamed ("conflict") so as not to overwrite the version modified in GoFAST.

Finally, even though the technical architecture would be somewhat different, one can imagine extending this replication beyond the file server to Nextcloud and/or SharePoint/OneDrive servers.

It goes without saying that this is a very complex project, currently at the feasibility stage, so implementation is not for the immediate future.