La auditoría de seguridad que encontró cero contraseñas compartidas

El cuestionario llegó como un archivo de hoja de cálculo adjunto con cuarenta y dos filas, y una de ellas dejó helado al director de cuenta: «Describa cómo se controla el acceso a nuestras cuentas publicitarias, incluida la gestión de credenciales y el proceso para conceder y revocar el acceso». Para la mayoría de las agencias con las que este cliente había trabajado alguna vez, esa única pregunta era donde la conversación se ponía incómoda. Esta es la historia de un desenlace distinto. En esta auditoría de seguridad de agencia, las contraseñas compartidas de cuentas publicitarias eran exactamente lo que los revisores fueron a buscar para escrutar, y no había ninguna. La agencia aprobó no por la fuerza de sus políticas, sino por la forma de su arquitectura.

Esta es una historia compuesta extraída de un patrón habitual en cuanto las agencias empiezan a vender a clientes de mediano mercado y empresa. Los nombres y los detalles exactos son ilustrativos; el modo de fallo —y la arquitectura que lo esquiva— son reales.

El cuestionario: compras pregunta quién puede tocar la cuenta

La agencia acababa de ganar un cliente más grande de lo habitual, una marca de consumo con financiación y una función de seguridad real. Antes de que se pudiera firmar el contrato, compras envió un cuestionario de seguridad de proveedores —el tipo de documento que antes se reservaba para proveedores de software y que ahora aterriza en cualquier agencia que toca las cuentas y datos de una marca regulada—. Enterradas en él estaban las preguntas que deciden si una agencia de anuncios parece un socio profesional o una responsabilidad: ¿quién de tu equipo puede acceder a nuestras cuentas publicitarias? ¿Cómo se concede ese acceso? ¿Cómo se revoca cuando alguien se va? ¿Se comparten credenciales? ¿Hay un registro de lo que tu equipo cambió?

El primer instinto del director de cuenta fue el instinto que la mayoría de los responsables de agencia tienen: empezar a redactar respuestas cuidadosas. Describir el gestor de contraseñas. Explicar la lista de baja. Tranquilizar al revisor de que el equipo es disciplinado. Pero la responsable de operaciones detuvo ese borrador, porque sabía algo que el director aún no apreciaba del todo: las respuestas honestas a esas preguntas, dada la forma en que la agencia trabajaba de verdad, no eran nada tranquilizadoras. Eran una lista de cosas que podían salir mal.

Por qué la mayoría de las agencias fallan esto por política, no por arquitectura

Esta es la trampa. La respuesta estándar de la agencia a «cómo se controla el acceso» es un conjunto de políticas superpuestas sobre credenciales compartidas. La agencia guarda el login de Meta del cliente en un gestor de contraseñas, documenta la semilla de doble factor para que más de una persona pueda pasar el aviso de 2FA, mantiene una regla de que las credenciales no se pegan en el chat, y mantiene una lista de baja para que cuando un comprador se va, alguien recuerde rotar la contraseña.

Cada una de esas es una promesa, y cada promesa es un lugar donde fallar. Un gestor de contraseñas solo es tan seguro como las personas con acceso a la entrada. Una semilla de 2FA documentada derrota todo el sentido de la 2FA en el momento en que sale del autenticador. Una lista de baja funciona hasta la única semana ocupada en que se salta. Ya hemos escrito antes sobre cómo los logins compartidos matan en silencio a una agencia operativamente; una revisión de seguridad es donde esos mismos logins compartidos matan a la agencia comercialmente, frente al cliente, sobre el papel.

La responsable de operaciones había visto a agencias perder tratos exactamente en este paso. El revisor pide la lista de personas que conocen la contraseña del cliente, la agencia la produce, y la conversación se convierte en una negociación sobre calendarios de rotación y permisos de bóveda, una negociación que la agencia solo puede perder, porque el hecho subyacente nunca cambia: hay humanos teniendo las credenciales del cliente.

La respuesta de arquitectura: un token de System-User, sin logins compartidos que auditar

La agencia respondió a la pregunta de control de acceso con un párrafo, y el párrafo describía arquitectura en lugar de política. La agencia no tiene ni comparte el login de Meta del cliente. Conecta el negocio del cliente una vez a través de un token de System-User —una credencial servidor a servidor— y a partir de ese token la capa operativa descubre las cuentas publicitarias conectadas automáticamente vía el identificador de negocio. Los compradores de medios nunca reciben la contraseña del cliente, porque no hay ningún punto en el que un comprador entre en la cuenta del cliente con una credencial personal o compartida. Trabajan a través de la propia capa de acceso interna de la agencia.

Esa única elección arquitectónica disuelve toda la categoría de preguntas que el cuestionario fue construido para sondear. No hay contraseña compartida que almacenar, así que no hay nada que filtrar de una bóveda. No hay semilla de 2FA documentada, así que no hay segundo factor derrotado. No hay credencial que rotar cuando un comprador se va, porque ningún comprador tuvo nunca una. El revisor fue a buscar el riesgo de credencial compartida que la respuesta de todos los demás proveedores revelaba, y en esta agencia simplemente no había nada que encontrar, no porque la agencia fuera cuidadosa, sino porque el objeto arriesgado no existía en su flujo de trabajo. Esta es la contraparte arquitectónica del punto operativo en nuestra guía sobre logins separados frente a una capa operativa real: la capa operativa es lo que permite que una conexión sirva a muchos compradores sin distribuir nunca la credencial.

RBAC interno: acceso concedido por rol, revocable, acotado, registrado

Sin contraseña compartida que gestionar, la pregunta de acceso se movió a donde los equipos de seguridad realmente la quieren: dentro del propio control de acceso basado en roles de la agencia. Cada comprador, estratega y responsable de cuenta tenía un asiento nominal con un rol definido. El acceso se concedía asignando un rol, acotado para que un rol solo pudiera alcanzar las cuentas y acciones que necesitaba, y revocado en el instante en que se quitaba el asiento, sin rotación de contraseñas, sin carrera, sin depender de la memoria de nadie.

Este es el opuesto estructural de los modos de fallo catalogados en nuestra pieza sobre los errores de permisos que cometen las agencias. Cuando el acceso es una contraseña compartida, no puedes concederlo de forma estrecha, no puedes revocarlo limpiamente, y no puedes demostrar quién lo tenía. Cuando el acceso es un rol en un asiento nominal, los tres se vuelven triviales. El revisor preguntó cómo se retira el acceso de un empleado que se va; la respuesta fue «le quitamos su asiento, y su acceso termina con él», una frase que no necesita seguimiento porque no hay secreto compartido aún circulando después de que se ha ido.

El registro de auditoría como evidencia: quién cambió qué y cuándo

La última pregunta de acceso del cuestionario era la que las agencias más temen: ¿hay un registro de lo que tu equipo cambió en nuestras cuentas? Con logins compartidos, la respuesta honesta es no: los historiales nativos sellan cada cambio con la misma identidad de propietario compartida, así que no hay forma de atribuir una edición a una persona. La respuesta de esta agencia era una pantalla. Como cada lanzamiento, cambio de presupuesto, pausa y edición creativa pasaba por la capa operativa, cada uno se capturaba automáticamente y se atribuía al asiento nominal que lo hizo, con una marca de tiempo, en cada plataforma que el cliente usaba.

Ese registro de auditoría hizo doble función. Para la revisión de seguridad, respondía la pregunta del registro de cambios de plano: sí, cada cambio está atribuido y con marca de tiempo, aquí está la cronología. Para las propias operaciones de la agencia, era el mismo registro de responsabilidad que describimos en por qué las cuentas publicitarias necesitan un registro de auditoría real: lo que convierte «creemos que alguien ajustó la puja» en «este comprador hizo este cambio a esta hora». El revisor trató un registro de cambios limpio y atribuido como señal de un proveedor maduro, porque lo es. Una agencia que puede mostrar exactamente quién hizo qué, y cuándo, es una agencia que ha pensado en la responsabilidad antes de que se lo pidieran.

Aprobar la revisión sin reescribir una sola política de acceso

La parte más llamativa del resultado fue lo que la agencia no tuvo que hacer. No escribió una nueva política de control de acceso para el encargo. No montó un proceso especial para este único cliente consciente de la seguridad. No prometió rotar credenciales más a menudo ni restringir quién tenía la entrada de la bóveda. Respondió el cuestionario describiendo la forma en que ya trabajaba —la conexión de System-User, los asientos basados en roles, el registro de cambios atribuido— y la descripción era el cumplimiento.

Esa es la palanca silenciosa de ser seguro por arquitectura en lugar de por procedimiento. La seguridad procedimental hay que realizarla, documentarla y volver a realizarla para cada auditoría, y se degrada en el momento en que la atención decae. La seguridad arquitectónica es una propiedad del sistema que se mantiene esté o no alguien mirando. La agencia aprobó la revisión en el tiempo que tardó en escribir unos párrafos y compartir una captura de la capa de acceso, porque el trabajo de aprobar se había hecho años antes, cuando eligió no distribuir credenciales en primer lugar.

Qué gana «seguro por arquitectura» más allá del cuestionario

El contrato firmado era el premio obvio, pero la arquitectura siguió pagando después de cerrar el trato. El mismo montaje que satisfizo al equipo de compras de un cliente satisfizo al siguiente sin trabajo adicional, lo que significaba que la agencia podía perseguir cuentas conscientes de la seguridad como un mercado en lugar de tratar cada una como un caso especial. Cada cuestionario futuro encontró la misma respuesta preparada.

También cambió la postura de riesgo interna de la agencia. Que un comprador se fuera era un no-evento —quitar el asiento, hecho— en lugar de un simulacro de rotación de credenciales en una docena de cuentas de cliente. El registro de cambios atribuido significaba que los traspasos internos venían con un mapa completo de cambios recientes. Y la ausencia de secretos compartidos significaba que la mayor superficie de brecha de la agencia, una bóveda llena de logins de clientes, simplemente no existía para ser comprometida. La arquitectura que ganó el cuestionario era la misma que hacía a la agencia más difícil de dañar en cualquier día ordinario, en las seis plataformas publicitarias que gestionaba para clientes.

La lección: la respuesta de seguridad más fuerte es no tener nada arriesgado que confesar

Preguntada después qué marcó la diferencia, la responsable de operaciones lo expuso con claridad: la agencia no aprobó la revisión de seguridad por ser mejor gestionando cosas arriesgadas. Aprobó por no tener las cosas arriesgadas que gestionar. No había contraseña compartida que proteger, ni semilla de 2FA que controlar, ni credencial que rotar, porque la forma en que los compradores alcanzaban las cuentas de cliente nunca involucraba ninguna de ellas.

Ese es el principio que cualquier agencia que venda a clientes serios debería absorber. A medida que subes de mercado, el cuestionario de seguridad deja de ser una sorpresa ocasional y se convierte en una puerta rutinaria, y la pregunta que realmente hace es siempre la misma: ¿dónde está el riesgo en cómo manejas nuestra cuenta? Una agencia construida sobre logins compartidos tiene que responder esa pregunta con una lista de mitigaciones, cada una un lugar donde podría fallar. Una agencia construida sobre un token de System-User, acceso interno basado en roles y un registro de auditoría atribuido puede responderla con arquitectura, y la respuesta más fuerte posible a «dónde está el riesgo» resulta ser la que no tiene nada arriesgado que confesar. Para el resto del playbook sobre gestionar una agencia de este modo, ve al hub de herramientas de agencia.