Un identifiant partagé, c'est un compte dont personne ne répond

L'affirmation

Le compte admin partagé, dont le mot de passe vit dans un tableur ou une conversation de groupe et que connaît quiconque en a déjà eu besoin, est de loin la faiblesse de sécurité sérieuse la plus courante dans les petites entreprises — et son coût ne tient pas surtout à la faiblesse du mot de passe. Il tient à ce qu'un compte partagé détruit l'imputabilité : quand quelque chose tourne mal, les journaux disent « admin l'a fait », et admin, c'est six personnes, dont deux ne travaillent plus ici. On ne peut pas enquêter sur ce qu'on ne peut pas attribuer.

Les trois défaillances d'un compte partagé

Un identifiant partagé échoue de trois façons à la fois, et chacune est sérieuse en soi.

Il ne peut pas être attribué. Chaque action prise par le compte partagé est anonyme au sein même de votre organisation. Si un dossier client est modifié, un remboursement émis ou un réglage changé, la piste de vérification nomme le compte, pas la personne, et votre enquête bute sur un mur que vous avez construit vous-même.

Il ne peut pas être révoqué proprement. Quand une des personnes qui connaissaient le mot de passe part, la seule façon de révoquer son accès est de changer le mot de passe et de le redistribuer à tous les autres — assez perturbant pour qu'on ne le fasse habituellement pas, de sorte que les employés partis gardent l'accès des mois.

Il ne peut pas avoir de double authentification véritable. Si le second facteur est partagé aussi, ce n'est pas un second facteur ; c'est une seconde chose que tout le monde a. Une vraie double authentification exige un appareil lié à une seule personne, qu'un compte partagé ne peut pas fournir.

Le correctif : des comptes individuels avec des rôles

Chaque personne obtient son propre compte nominatif, et les permissions se rattachent à des rôles plutôt qu'à des individus. Cela paraît plus d'administration et en est en réalité moins, car la structure fait le travail :

-- les roles, pas les personnes, detiennent les permissions
CREATE ROLE billing_admin;
GRANT SELECT, UPDATE ON invoices TO billing_admin;

-- les personnes recoivent des roles, et sont revoquees individuellement
GRANT billing_admin TO alice;
GRANT billing_admin TO bob;

-- le depart tient en une ligne, et il est complet
REVOKE billing_admin FROM bob;
DROP ROLE bob;  -- ou desactiver

Désormais, chaque action est attribuable à une personne, révoquer l'accès d'une personne est une seule commande qui n'affecte personne d'autre, et chacun peut avoir son propre second facteur. Les permissions vivent sur le rôle ; accorder le bon accès à un nouvel employé tient donc en une ligne, et vous voyez d'un coup d'œil qui détient quel rôle.

Le moindre privilège, appliqué honnêtement

Les comptes individuels rendent pratique de ne donner à chacun que l'accès qu'exige son travail, ce qui est l'autre moitié du correctif. Le compte admin partagé était presque certainement surprivilégié — il avait le contrôle complet parce que c'était plus simple que de définir des rôles, donc quiconque l'utilisait avait le contrôle complet, sans égard au besoin. Avec des rôles, la personne qui émet les remboursements obtient le rôle de remboursement et non la capacité de changer les réglages système ; celle qui lit les rapports obtient l'accès en lecture et rien qui écrive.

Le test est simple : pour chaque personne, pourrait-elle faire son travail avec moins d'accès ? Là où la réponse est oui, l'excédent est du pur risque — c'est ce qu'obtient un attaquant si le compte de cette personne est compromis, et ce que cette personne peut briser par accident.

Les comptes les plus difficiles à individualiser

Deux catégories y résistent et exigent un traitement délibéré. Les comptes de service — les identifiants qu'une application utilise pour atteindre une base ou une API — ne sont pas des personnes et ne devraient pas être individuels, mais ils devraient être nommés selon leur usage, limités exactement à ce dont ils ont besoin, et leurs identifiants stockés dans un gestionnaire de secrets plutôt qu'un fichier de configuration. Les comptes de secours — l'accès d'urgence pour quand le système d'identité lui-même est en panne — sont légitimement partagés, mais ils devraient être rares, leurs identifiants scellés et stockés en lieu sûr, leur usage alertant immédiatement, et leur mot de passe changé après chaque usage. L'existence de ces exceptions n'est pas une raison de garder l'admin partagé du quotidien.

Par où commencer

Énumérez chaque identifiant partagé de l'entreprise — le compte admin, la boîte partagée, les identifiants de réseaux sociaux, les portails de fournisseurs à un seul jeu d'identifiants. Pour chacun, la question est de savoir s'il peut devenir des comptes individuels avec des rôles, et pour l'écrasante majorité la réponse est oui. Convertissez d'abord les plus privilégiés, car c'est là que l'absence d'attribution vous coûte le plus. L'identifiant partagé paraît commode jusqu'à l'après-midi où vous cherchez qui a changé les coordonnées bancaires d'un client et où la seule réponse honnête que vos systèmes peuvent donner est « quelqu'un qui connaissait le mot de passe » — c'est-à-dire, par conception, tout le monde.