Aller au contenu
BYC Data & Performance

Conformité

Masquer un bouton ne protège pas la donnée

par

Retour de terrain

En bref

  • Cacher un écran ou un bouton laisse la donnée accessible à qui sait chercher.
  • Dans ce canal de signalement, la règle « chaque déclarant ne lit que ses propres signalements » est appliquée par les permissions de la plateforme, au niveau de la donnée.
  • Même en contournant l'interface, un utilisateur ne peut pas lire le signalement d'un autre.

Un canal de signalement, dans un groupe international. La règle de confidentialité est simple : chaque déclarant ne lit que ses propres signalements. Reste à savoir où cette règle vit.

La fausse sécurité de l'interface

La solution la plus rapide, c'est l'interface. On cache l'écran de traitement aux déclarants. On rend invisible le bouton qui ouvre les dossiers des autres. À l'écran, tout a l'air protégé.

Le problème, c'est que la donnée, elle, n'a pas bougé. Elle est toujours là, derrière l'écran. Elle reste accessible à qui sait chercher.

Masquer un bouton ne retire pas un droit. Ça retire un chemin. Et un chemin masqué n'est pas un chemin fermé.

Il y a pire. Une protection posée écran par écran doit être refaite à chaque nouvel écran. Le jour où l'on ajoute un rapport, un export ou une nouvelle page, il faut penser à la reposer. Il suffit d'un oubli.

Comment j'ai inversé la logique

Dans cet outil, la règle « chaque déclarant ne lit que ses propres signalements » n'est pas écrite dans l'interface. Elle est appliquée par les permissions de la plateforme, au niveau de la donnée.

Concrètement, quand un déclarant demande des dossiers, la plateforme ne lui renvoie que les siens. Les autres ne sont pas cachés. Ils ne lui sont tout simplement pas transmis.

L'application, elle, ne décide rien. Elle constate ce que les droits autorisent, et affiche ce qu'elle reçoit.

Le test qui compte est celui-ci : même en contournant l'interface, un utilisateur ne peut pas lire le signalement d'un autre. Ce n'est pas l'écran qui l'en empêche. C'est la donnée elle-même, protégée là où elle est stockée.

L'interface n'est qu'une politesse

Je résume l'idée ainsi : la sécurité doit vivre dans les données, l'interface n'est qu'une politesse.

L'interface reste utile. Elle évite d'afficher un bouton qui ne mènerait à rien. Elle rend l'outil plus clair, plus agréable. Mais elle ne protège pas.

Cette logique a un autre avantage. Le rôle de chacun se déduit des mêmes droits. L'équipe centrale lit tout, chaque déclarant lit ses signalements, et l'application en tire les écrans à afficher. Une seule règle, au même endroit, pour la sécurité et pour l'affichage.

Il n'y a donc pas deux systèmes à tenir alignés, un pour les droits et un pour les écrans. Il n'y en a qu'un. Les écrans suivent les droits, jamais l'inverse.

Pourquoi c'est important en conformité

Dans un canal de signalement, la confidentialité est au cœur du dispositif. Un déclarant doit pouvoir compter dessus.

Le jour d'un contrôle, la question ne sera pas « est-ce que le bouton est caché ? ». Elle sera « qui peut lire quoi, et comment le prouvez-vous ? ».

Avec une sécurité d'interface, la réponse est fragile. Elle dépend de chaque écran, de chaque bouton, de chaque oubli possible.

Avec des permissions au niveau de la donnée, la réponse tient en une règle. Et cette règle s'applique partout, y compris là où personne n'a pensé à mettre un écran.

C'est aussi plus simple à faire vivre. Un nouvel écran n'a rien à reposer : il lit la même donnée, avec les mêmes droits, et n'affiche que ce qu'ils autorisent.

Ce que ça change pour vous

Si vos outils contiennent des données sensibles, posez une question simple à votre équipe technique : « si quelqu'un contourne l'écran, que voit-il ? »

  • Si la réponse est « rien, ses droits l'en empêchent », la sécurité vit dans les données.
  • Si la réponse est « il ne trouvera pas le bouton », la sécurité vit dans l'interface. Elle tient jusqu'au jour où quelqu'un cherche.
  • Si personne ne sait répondre, c'est déjà une réponse.

Les données de paie, les dossiers disciplinaires, les signalements, les contrats : tout ce qui est confidentiel mérite la même question. La réponse ne doit pas dépendre d'un écran.

Le même outil déduit le rôle de chacun de ses droits, sans liste à tenir : aucune liste d'administrateurs. Il surveille aussi ses délais tout seul : les délais réglementaires surveillés par l'outil. Le projet complet est dans la réalisation Un canal de signalement qui surveille ses propres délais. Ce type d'outil est décrit sur la page Une application à la place de l'Excel.

Une donnée confidentielle se protège là où elle est stockée. Pas là où elle est affichée.

Vos questions

Parce que la donnée reste accessible à qui sait chercher. Le bouton masqué retire un chemin, il ne retire pas le droit.

Dans les permissions, au niveau de la donnée. L'application se contente de constater ce que les droits autorisent.

En posant la question : si quelqu'un contourne l'écran, que voit-il ? Avec des permissions au niveau de la donnée, la réponse est : rien de plus que ce que ses droits autorisent.

Sur le même sujet

Vous voulez l'appliquer chez vous ?

Applications métier

Une application à la place de l'Excel

Vos équipes saisissent, valident et signent depuis leur téléphone. Fini les versions qui s'écrasent.

Un exemple réel : Un canal de signalement qui surveille ses propres délais

Un process qui vous coûte cher ? Un Excel qui déborde ? Une équipe qui perd du temps ?

Décrivez-le en cinq lignes. Réponse sous 24 h avec une estimation chiffrée.