Choisir le bon niveau de protection : chiffrer, masquer ou restreindre
TimeTonic propose plusieurs mécanismes pour protéger une donnée sensible. Ils ne font pas la même chose et ne se remplacent pas.
Cet article vous aide à choisir le bon, et surtout à comprendre ce que chacun ne protège pas.
La donnée doit-elle rester lisible par quelqu'un ?
Si personne dans l'équipe n'a besoin de la lire au quotidien, et qu'il s'agit d'un secret (mot de passe, clé, code d'accès), chiffrez-la.
2
Faut-il reconnaître la ligne sans lire la donnée entière ?
Si vos collaborateurs doivent identifier le bon enregistrement, mais pas connaître la valeur complète, masquez-la.
3
Est-ce une question de personne, de situation, ou de stabilité ?
Si la réponse dépend de qui regarde, restreignez les champs de la vue. Si elle dépend de l'état de la ligne, utilisez une condition. Si vous voulez surtout que rien ne bouge, verrouillez.
Ne dispense pas de restreindre les champs de la vue partagée.
Chiffrer : le champ crypté
Le type de colonne Champ crypté stocke une information chiffrée, y compris dans la base de données côté serveur. Son contenu n'est lisible qu'après saisie d'un mot de passe, défini à la création de la colonne et propre à celle-ci.
C'est le seul mécanisme de cette liste qui protège la donnée elle-même, et non son affichage. Utilisez-le pour tout ce qui est un secret : mots de passe d'outils externes, clés d'API de services tiers, codes d'accès.
Créer la colonne et définir son mot de passe → Champ crypté
Le prix du chiffrement. Une donnée chiffrée ne peut pas être recherchée, ni triée, ni utilisée dans une formule ou un filtre. Si vous avez besoin de retrouver la ligne par cette valeur, ce n'est pas le bon mécanisme.
Masquer : la formule APPLY_MASK()
APPLY_MASK() crée une version partiellement cachée d'une valeur, dans une colonne de formule. Le masque utilise @ pour afficher un caractère et X pour le masquer.
Un masque seul ne protège rien. APPLY_MASK() crée une colonne supplémentaire ; la colonne d'origine contient toujours la valeur complète. Le masque ne devient une protection qu'une fois la colonne source passée en Invisible dans les vues concernées.
Restreindre : les champs d'une vue
C'est le mécanisme central. La restriction se règle vue par vue, dans une fenêtre unique qui liste tous les champs de la table et leur niveau d'accès. Elle s'ouvre depuis la barre d'outils de la vue, ou depuis le menu d'une colonne avec Restreindre accès.
Lecture / Écriture
Le champ est visible et modifiable. C'est le niveau par défaut.
Lecture seule
Le champ reste visible mais ne peut plus être modifié depuis cette vue.
Invisible
Le champ disparaît complètement de la vue. Le niveau à utiliser pour les colonnes remplacées par une version masquée.
La fenêtre affiche en permanence le compte par niveau, par exemple 28 champs en Lecture / Écriture, 1 en Lecture seule et 34 Invisibles. C'est le moyen le plus rapide de vérifier qu'une vue destinée à l'extérieur n'expose que ce qui est prévu.
Pensez à cocher « Masquer également en mode fiche ». Sans cette case, un champ rendu invisible dans le tableau peut réapparaître lorsque l'utilisateur ouvre l'enregistrement en mode fiche. La colonne semble cachée, et elle ne l'est qu'à moitié.
Terminez par Sauvegarder avec la vue : la restriction est enregistrée dans la configuration de la vue et s'applique à tous ceux qui l'ouvrent, y compris via un partage externe.
Les mécanismes précédents dépendent de la vue, donc de qui regarde. Ces trois-là dépendent du contenu de la ligne, et se règlent depuis le menu de la colonne.
Visibilité conditionnelle
Le champ n'apparaît que si une condition est remplie. Utile pour n'afficher un champ de motif que lorsqu'un statut passe à « Refusé ».
Le champ reste visible mais devient non modifiable selon une condition. Pour geler des données une fois un dossier validé. Ce n'est pas une protection contre la lecture.
Impose la saisie d'un champ dès qu'une condition est remplie. C'est une protection de l'intégrité : elle empêche qu'un dossier parte sans la pièce ou le motif obligatoire.
Avant de modifier ou de supprimer un champ soumis à conditions, consultez Dépendance des champs : il montre ce qui repose dessus, formules et conditions comprises.
Restreindre décide de ce qui est visible. Verrouiller décide de ce qui peut être changé. Une protection soigneusement posée ne vaut rien si un utilisateur peut retirer un filtre ou réafficher une colonne : le verrouillage est ce qui la rend durable.
La fiche et les colonnes de lien : la fuite qu'on ne voit pas
Une vue parfaitement restreinte peut fuir par ses colonnes de lien. Une colonne de lien affiche les enregistrements d'une autre table à travers une vue de cette table. Si aucune vue n'y est sélectionnée, l'utilisateur atteint depuis la fiche des données que vous aviez masquées. Le réglage se fait colonne de lien par colonne de lien : il n'est pas automatique.
Sur chaque colonne de lien, choisissez la vue à utiliser, en pointant vers une vue elle-même filtrée et restreinte. Elle détermine quelles lignes et quelles colonnes de la table liée seront visibles depuis la fiche.
L'espace miroir : un espace de travail limité pour l'utilisateur final
Un client, un sous-traitant ou un intervenant externe n'a souvent aucune raison d'entrer dans votre espace de travail de production, même avec des vues restreintes.
La vue miroir répond à ce besoin : vous créez un espace dédié à cette personne, et vous y projetez uniquement les vues que vous avez configurées.
1
Préparez la vue dans votre espace de production
Filtres pour les lignes, Restriction sur les champs pour les colonnes, et sélection de la vue sur chaque colonne de lien.
2
Verrouillez les paramètres de cette vue
Pour que le destinataire ne puisse pas défaire les filtres ni réafficher les colonnes.
3
Créez l'espace de travail destiné à l'utilisateur final, et la vue miroir
Un espace par client ou par intervenant, qui ne contiendra que les vues miroir.
4
Invitez la personne sur ce seul espace
Avec le rôle le moins permissif qui lui permette de travailler. Elle n'a aucun accès à l'espace de production.
Le cas le plus courant, celui d'une donnée sensible que l'équipe doit pouvoir identifier sans la lire entièrement, se traite en quatre étapes.
1
Gardez la valeur complète dans sa colonne d'origine
Vous en aurez besoin pour les traitements, les rapprochements et les éditions.
2
Créez une colonne de formule avec APPLY_MASK()
C'est elle que verront vos collaborateurs.
3
Passez la colonne d'origine en Invisible
Dans les vues de travail concernées, en cochant Masquer également en mode fiche.
4
Verrouillez les paramètres de la vue
Sans cette étape, la restriction peut être défaite par celui qui ouvre la vue, et les trois premières ne servent à rien.
Ce schéma est l'application la plus concrète du principe de privacy by design : n'exposer que le strict nécessaire, dès la conception de la table, plutôt que d'ajouter une protection après coup.