Garder les données sur le Drive du client : la philosophie de conception de la rétention minimale des données

Plus on accumule de données clients sur les serveurs du prestataire, plus les dégâts sont importants en cas d'attaque.

À l'inverse, en réduisant les données conservées sur le serveur, on rend structurellement plus petit le périmètre d'impact en cas d'incident.

Moins il y a de choses à protéger, plus la protection peut être simple et moins les oublis de contrôle sont probables.

Le point de départ est de se demander, dès le début de la conception : « faut-il vraiment conserver cela sur le serveur ? »

Il y a le tableur situé dans le propre Google Drive de l'entreprise qui l'utilise, c'est-à-dire la vôtre.

Si l'on en fait la destination finale du rapport quotidien, la maîtrise des données revient du côté du client.

Le prestataire ne fait que relayer et ne conserve rien sur le long terme.

Le client décide lui-même, par ses propres réglages d'accès, qui peut consulter les données, et même s'il met fin au contrat, les données restent entre ses mains.

Une conception qui ne prend pas les données en otage rassure aussi au moment de l'adoption.

Le serveur ne garde que les données temporaires entre l'envoi et l'approbation. Elles sont effacées immédiatement à l'approbation.

Sans approbation, elles ne sont plus consultables au-delà de 24 heures.

Dans ce cas, elles sont supprimées automatiquement au plus tard le lendemain par la suppression planifiée quotidienne.

Pouvoir afficher clairement « consultables 24 heures au plus, supprimées au plus tard le lendemain » facilite aussi l'examen côté client.

L'important ici est que l'effacement se fasse automatiquement, sans dépendre d'une intervention humaine, et que la limite de rétention puisse s'expliquer en mots.

Avec un vague « nous effaçons dès que possible », celui qui examine ne peut pas se prononcer.

La rétention minimale est puissante, mais elle ne suffit pas à elle seule à assurer la sécurité.

Il y a des bases, telles que le chiffrement des communications, la séparation des droits d'écriture et l'enregistrement des opérations.

C'est seulement lorsqu'on y joint ces bases que l'on atteint un état sûr à utiliser.

Par exemple, penser en un seul ensemble les trois points suivants réduit les oublis. Ne pas être lisible par un tiers pendant la conservation.

Limiter la destination d'écriture au strict nécessaire. Pouvoir retracer après coup ce qui s'est passé.

Celui qui envisage l'adoption peut, comme repère, poser les questions suivantes au prestataire.

La première : « Où se trouvent les données proprement dites ? ». La deuxième : « Quelle est la durée maximale de conservation sur le serveur ? ».

La troisième : « L'effacement est-il automatique ou manuel ? ». La quatrième : « Si je veux retirer les autorisations, quelle est la marche à suivre ? ».

Plus les réponses sont concrètes et explicables comme un mécanisme, plus on peut juger que la conception est bien organisée.

À l'inverse, si la réponse dépend de la vigilance d'un responsable d'exploitation, c'est là que se trouve probablement le point faible.

Enfin, vérifiez aussi que l'explication de la conception existe par écrit : cela servira lors des validations internes et des réexamens.