L'audit de sécurité qui n'a trouvé aucun mot de passe partagé

Le questionnaire est arrivé sous forme de pièce jointe tableur de quarante-deux lignes, et l'une d'elles a glacé le directeur de compte : « Décrivez comment l'accès à nos comptes publicitaires est contrôlé, y compris la gestion des identifiants et le processus d'octroi et de révocation des accès. » Pour la plupart des agences avec lesquelles ce client avait travaillé, cette seule question était l'endroit où la conversation devenait inconfortable. Voici l'histoire d'une issue différente. Dans cet audit de sécurité d'agence, les mots de passe de comptes ads partagés étaient exactement ce que les examinateurs cherchaient à scruter — et il n'y en avait aucun. L'agence a réussi non pas grâce à la force de ses politiques, mais grâce à la forme de son architecture.

Ceci est une histoire composite tirée d'un schéma courant dès que les agences commencent à vendre à des clients mid-market et entreprise. Les noms et les détails exacts sont illustratifs ; le mode d'échec — et l'architecture qui le contourne — sont réels.

Le questionnaire : les achats demandent qui peut toucher au compte

L'agence venait de gagner un client plus grand que d'habitude, une marque grand public financée avec une vraie fonction sécurité. Avant que le contrat ne puisse être signé, les achats ont envoyé un questionnaire de sécurité fournisseur — le genre de document jadis réservé aux éditeurs de logiciels et qui atterrit désormais sur toute agence qui touche aux comptes et aux données d'une marque réglementée. Enfouies dedans se trouvaient les questions qui décident si une agence ads ressemble à un partenaire professionnel ou à une responsabilité : qui dans votre équipe peut accéder à nos comptes ads ? Comment cet accès est-il accordé ? Comment est-il révoqué quand quelqu'un part ? Des identifiants sont-ils partagés ? Existe-t-il une trace de ce que votre équipe a modifié ?

Le premier réflexe du directeur de compte a été celui de la plupart des responsables d'agence : commencer à rédiger des réponses soignées. Décrire le gestionnaire de mots de passe. Expliquer la checklist d'offboarding. Rassurer l'examinateur sur la discipline de l'équipe. Mais la responsable des opérations de l'agence a stoppé ce brouillon, car elle savait une chose que le directeur n'appréciait pas encore pleinement — les réponses honnêtes à ces questions, vu la façon dont l'agence travaillait réellement, n'étaient pas du tout rassurantes. C'était une liste de choses qui pouvaient mal tourner.

Pourquoi la plupart des agences échouent sur la procédure, pas l'architecture

Voici le piège. La réponse d'agence standard à « comment l'accès est-il contrôlé » est un ensemble de politiques superposées à des identifiants partagés. L'agence détient le login Meta du client dans un gestionnaire de mots de passe, documente la clé à deux facteurs pour que plus d'une personne puisse passer l'invite 2FA, maintient une règle selon laquelle les identifiants ne sont pas collés dans le chat, et tient une checklist d'offboarding pour que, quand un buyer part, quelqu'un se souvienne de faire tourner le mot de passe.

Chacune de ces choses est une promesse, et chaque promesse est un endroit où échouer. Un gestionnaire de mots de passe n'est aussi sûr que les personnes qui ont accès à l'entrée. Une clé 2FA documentée détruit tout l'intérêt de la 2FA au moment où elle quitte l'authentificateur. Une checklist d'offboarding fonctionne jusqu'à la semaine chargée où elle est sautée. Nous avons déjà écrit sur la façon dont les logins partagés tuent en silence une agence sur le plan opérationnel ; une revue de sécurité est l'endroit où ces mêmes logins partagés tuent l'agence sur le plan commercial, devant le client, sur le papier.

La responsable des opérations avait vu des agences perdre des contrats exactement à cette étape. L'examinateur demande la liste des personnes qui connaissent le mot de passe du client, l'agence la produit, et la conversation tourne en négociation sur les calendriers de rotation et les permissions du coffre — une négociation que l'agence ne peut que perdre, parce que le fait sous-jacent ne change jamais : des humains détiennent les identifiants du client.

La réponse d'architecture : un token System-User, aucun login partagé à auditer

L'agence a répondu à la question du contrôle d'accès en un paragraphe, et le paragraphe décrivait l'architecture plutôt que la procédure. L'agence ne détient ni ne partage le login Meta du client. Elle connecte le business du client une seule fois via un token System-User — un identifiant serveur-à-serveur — et à partir de ce token la couche opérationnelle découvre automatiquement les comptes ads connectés via l'identifiant business. Les media buyers ne reçoivent jamais le mot de passe du client, parce qu'il n'y a aucun moment où un buyer se connecte au compte du client avec un identifiant personnel ou partagé. Ils travaillent via la propre couche d'accès interne de l'agence.

Ce seul choix architectural dissout toute la catégorie de questions que le questionnaire était bâti pour sonder. Il n'y a aucun mot de passe partagé à stocker, donc rien à fuiter d'un coffre. Il n'y a aucune clé 2FA documentée, donc aucun second facteur détruit. Il n'y a aucun identifiant à faire tourner quand un buyer part, parce qu'aucun buyer n'en a jamais détenu. L'examinateur est allé chercher le risque d'identifiant partagé que la réponse de chaque autre fournisseur révélait, et chez cette agence il n'y avait tout simplement rien à trouver — non pas parce que l'agence était prudente, mais parce que l'objet risqué n'existait pas dans son workflow. C'est la contrepartie architecturale du point opérationnel de notre guide sur les logins séparés contre une vraie couche opérationnelle : la couche opérationnelle est ce qui permet à une seule connexion de servir de nombreux buyers sans jamais distribuer l'identifiant.

RBAC interne : accès accordé par rôle, révocable, cantonné, journalisé

Sans mot de passe partagé à gérer, la question de l'accès s'est déplacée là où les équipes sécurité la veulent vraiment : à l'intérieur du propre contrôle d'accès basé sur les rôles de l'agence. Chaque buyer, stratège et responsable de compte avait un siège nommé avec un rôle défini. L'accès était accordé en assignant un rôle, cantonné pour qu'un rôle ne puisse atteindre que les comptes et actions dont il avait besoin, et révoqué dès que le siège était retiré — sans rotation de mot de passe, sans précipitation, sans dépendance à la mémoire de qui que ce soit.

C'est l'opposé structurel des modes d'échec catalogués dans notre article sur les erreurs de permissions des agences. Quand l'accès est un mot de passe partagé, vous ne pouvez pas l'accorder de manière étroite, vous ne pouvez pas le révoquer proprement, et vous ne pouvez pas prouver qui l'avait. Quand l'accès est un rôle sur un siège nommé, les trois deviennent triviaux. L'examinateur a demandé comment l'accès d'un employé partant est retiré ; la réponse a été « on retire son siège, et son accès s'arrête avec » — une phrase qui ne demande aucune relance parce qu'il n'y a aucun secret partagé encore en circulation après son départ.

La piste d'audit comme preuve : qui a changé quoi, quand

La dernière question d'accès du questionnaire était celle que les agences redoutent le plus : existe-t-il une trace de ce que votre équipe a modifié sur nos comptes ? Sur des logins partagés, la réponse honnête est non — les historiques natifs estampillent chaque modification de la même identité de propriétaire partagée, alors il n'y a aucun moyen d'attribuer une édition à une personne. La réponse de cette agence a été un écran. Comme chaque lancement, changement de budget, mise en pause et édition de créa passait par la couche opérationnelle, chacun était capturé automatiquement et attribué au siège nommé qui l'avait fait, avec un horodatage, sur chaque plateforme du client.

Cette piste d'audit faisait double emploi. Pour la revue de sécurité, elle répondait directement à la question de la trace des modifications : oui, chaque modification est attribuée et horodatée, voici la chronologie. Pour les propres opérations de l'agence, c'était le même registre de responsabilité que nous décrivons dans pourquoi les comptes ads ont besoin d'un vrai journal d'audit — la chose qui transforme « on pense que quelqu'un a ajusté l'enchère » en « ce buyer a fait cette modification à cette heure ». L'examinateur a traité un journal des modifications propre et attribué comme le signe d'un fournisseur mature, parce que c'en est un. Une agence qui peut montrer exactement qui a fait quoi, quand, est une agence qui a pensé à la responsabilité avant qu'on le lui demande.

Réussir la revue sans réécrire la moindre politique d'accès

La partie la plus frappante de l'issue est ce que l'agence n'a pas eu à faire. Elle n'a pas écrit de nouvelle politique de contrôle d'accès pour la mission. Elle n'a pas monté de processus spécial pour ce seul client soucieux de sécurité. Elle n'a pas promis de faire tourner les identifiants plus souvent ni de restreindre qui détenait l'entrée du coffre. Elle a répondu au questionnaire en décrivant sa façon de travailler déjà existante — la connexion System-User, les sièges basés sur les rôles, le journal des modifications attribué — et la description était la conformité.

C'est l'effet de levier discret d'être sécurisé par architecture plutôt que par procédure. La sécurité procédurale doit être exécutée, documentée et ré-exécutée pour chaque audit, et elle se dégrade au moment où l'attention faiblit. La sécurité architecturale est une propriété du système qui tient, que quelqu'un regarde ou non. L'agence a réussi la revue dans le temps qu'il a fallu pour écrire quelques paragraphes et partager une capture de la couche d'accès, parce que le travail de réussite avait été fait des années plus tôt, le jour où elle a choisi de ne pas distribuer d'identifiants au départ.

Ce que « sécurisé par architecture » gagne au-delà du questionnaire

Le contrat signé était le prix évident, mais l'architecture a continué de payer après la conclusion du contrat. Le même dispositif qui a satisfait l'équipe achats d'un client a satisfait le suivant sans travail supplémentaire, ce qui signifiait que l'agence pouvait poursuivre les comptes soucieux de sécurité comme un marché plutôt que de traiter chacun comme un cas particulier. Chaque futur questionnaire rencontrait la même réponse préparée.

Cela a aussi changé la posture de risque interne de l'agence. Le départ d'un buyer était un non-événement — on retire le siège, c'est fait — au lieu d'un exercice d'urgence de rotation d'identifiants sur une douzaine de comptes clients. Le journal des modifications attribué signifiait que les transferts internes arrivaient avec une carte complète des changements récents. Et l'absence de secrets partagés signifiait que la plus grande surface de brèche de l'agence, un coffre rempli de logins clients, n'existait tout simplement pas pour être compromise. L'architecture qui a gagné le questionnaire était la même qui rendait l'agence plus difficile à endommager n'importe quel jour ordinaire, sur les six plateformes publicitaires qu'elle gérait pour ses clients.

La leçon : la réponse de sécurité la plus forte est de n'avoir rien de risqué à avouer

Interrogée après coup sur ce qui avait fait la différence, la responsable des opérations l'a dit clairement : l'agence n'a pas réussi la revue de sécurité en étant meilleure dans la gestion des choses risquées. Elle a réussi en n'ayant pas les choses risquées à gérer. Il n'y avait aucun mot de passe partagé à protéger, aucune clé 2FA à contrôler, aucun identifiant à faire tourner, parce que la façon dont les buyers atteignaient les comptes clients n'en impliquait aucun.

C'est le principe que toute agence vendant à des clients sérieux devrait absorber. À mesure que vous montez en gamme, le questionnaire de sécurité cesse d'être une surprise occasionnelle et devient une porte de routine, et la question qu'il pose vraiment est toujours la même : où est le risque dans votre façon de gérer notre compte ? Une agence bâtie sur des logins partagés doit répondre à cette question par une liste de mesures d'atténuation, chacune un endroit où elle pourrait échouer. Une agence bâtie sur un token System-User, un accès interne basé sur les rôles et une piste d'audit attribuée peut y répondre par l'architecture — et la réponse la plus forte possible à « où est le risque » s'avère être celle qui n'a rien de risqué à avouer. Pour le reste du playbook sur la gestion d'une agence ainsi, voir le hub outils d'agence.