Acceso de terceros (freelancers, agencias, consultoras): cuentas, MFA y controles para trabajar sin riesgo

Trabajar con terceros ya no es una excepción. El problema aparece cuando esa colaboración se gestiona de forma improvisada.

En muchas organizaciones, el acceso de terceros crece por acumulación de urgencias: se comparte una contraseña “solo por esta semana”, se crea una cuenta genérica y, al cabo de unos meses, nadie tiene claro quién accede a qué ni hasta cuándo. Ese patrón crea deuda operativa. No tiene por qué acabar en un incidente grave, pero sí puede traducirse en fricciones recurrentes: bloqueos, auditorías, dependencia de personas y pérdida de trazabilidad.

Desde negocio, esto impacta en tres frentes. Primero, productividad: sin un proceso claro, cada alta se negocia ad hoc. Segundo, continuidad: si cambia el proveedor o rota una persona del equipo externo, los accesos quedan desalineados con la realidad. Tercero, control: una cuenta compartida o un acceso privilegiado permanente dificultan saber qué pasó, quién actuó y si la exposición sigue abierta.

La buena noticia es que este problema no requiere una arquitectura compleja. Un modelo mínimo viable, bien definido y asumido por negocio y tecnología, reduce gran parte del riesgo de proceso sin añadir fricción innecesaria.

Acciones recomendadas

1. Prohibir las cuentas genéricas para acceso a sistemas corporativos y migrar a cuentas nominales individuales con MFA obligatorio.
2. Implantar un único formulario o ticket de alta de terceros con owner interno, sistemas solicitados, rol requerido, motivo de negocio y fecha fin obligatoria.
3. Definir entre tres y cinco roles estándar reutilizables, por ejemplo lectura, edición, administración limitada y elevación temporal.
4. Establecer revisiones periódicas de cuentas de terceros para detectar accesos sin uso, sin fecha fin o con privilegios superiores a los necesarios.
5. Separar, cuando aplique, producción y pruebas, limitando el acceso a datos y operaciones sensibles a casos expresamente aprobados.
6. Formalizar un checklist de salida al terminar contrato o proyecto: revocar accesos, transferir propiedad de activos, invalidar integraciones y rotar secretos compartidos si existieran.

La mayoría de escenarios se pueden cubrir con un marco común: qué es obligatorio, qué se puede delegar y qué excepciones requieren aprobación explícita.

Antipatrones que conviene eliminar cuanto antes

El primer antipatrón son las cuentas genéricas. Usuarios del tipo “agencia-marketing” o “externo-dev” parecen convenientes porque sobreviven a la rotación, pero rompen la trazabilidad: no se puede atribuir bien una acción ni revocar de forma granular. Además, cuando alguien sale del proveedor, la organización se ve forzada a cambiar y redistribuir credenciales.

El segundo antipatrón es compartir contraseñas por canales informales. Aunque haya prisa, pasar credenciales por correo o chat convierte un acceso corporativo en un secreto de equipo y dificulta su retirada ordenada.

El tercero es asignar permisos de administrador “por comodidad”. Si no hay roles intermedios, el atajo es dar permisos amplios. El coste llega después: más superficie de error, más dificultad de revisión y más impacto si ocurre una mala configuración.

El cuarto antipatrón es no poner fecha fin. Un acceso sin caducidad tiende a quedarse “para siempre”, incluso cuando la necesidad original ya no existe. Con muchos proveedores, esto acaba generando cuentas activas sin uso real.

Estos cuatro hábitos suelen presentarse como atajos para “no bloquear el proyecto”. En realidad, son sustitutos de un proceso que no se ha diseñado. El objetivo del modelo propuesto es reemplazar excepciones improvisadas por una mecánica simple, conocida y repetible.

Modelo de identidad recomendado: simple, nominal y trazable

El principio base es que cada tercero debe tener una identidad individual. No importa si trabaja para una gran consultora o como profesional independiente: si accede a un sistema corporativo, debe hacerlo con una cuenta nominal asociada a su persona, vinculada al proveedor y patrocinada por un owner interno.

Ese owner interno es clave. No basta con crear la cuenta; alguien debe validar la necesidad, revisar el alcance y responder si cambian las condiciones. Esto evita que IT sea el único guardián de una decisión que, en el fondo, es operativa.

El segundo elemento es el MFA obligatorio. Sin entrar en configuraciones concretas: si una credencial se filtra o se reutiliza, un segundo factor ayuda a reducir el riesgo de acceso indebido. En terceros es especialmente útil porque la organización no siempre controla el contexto de trabajo con el mismo nivel que en plantilla interna.

Cuando aplique, conviene añadir controles proporcionales en sistemas críticos (por ejemplo, requisitos más altos en accesos administrativos). Y, en esos sistemas, asegurar al menos trazabilidad básica de acceso y cambios. Un modelo agnóstico y razonable quedaría así: identidad individual, patrocinador interno, MFA, permisos por rol, fecha fin obligatoria y registros disponibles para actividades relevantes.

Permisos por rol y por tiempo: menos fricción, no más

Uno de los motivos por los que proliferan los permisos excesivos es que no existen roles reutilizables. Si cada acceso se diseña desde cero, el proceso se vuelve lento y el atajo natural es conceder más de la cuenta. Por eso conviene acordar un pequeño catálogo de perfiles estándar.

En la práctica, suelen bastar tres a cinco niveles. Un rol de lectura para consulta y reporting. Un rol de edición para tareas operativas acotadas. Un rol de administración limitada para gestión funcional sin control total del sistema. Y, si la operación lo exige, un rol de elevación temporal para actuaciones extraordinarias con aprobación adicional.

La clave está en que esos roles sean entendibles por negocio, no solo por seguridad. Si el responsable del área no puede distinguir qué permite cada nivel, acabará pidiendo “lo máximo para no quedarse corto”. Los roles deben describirse con lenguaje operativo: qué puede ver, qué puede cambiar y qué no puede hacer.

El componente temporal es igual de importante. Muchos accesos no son permanentes por naturaleza: una campaña, una migración, una auditoría técnica, una implantación o un soporte de varias semanas. Si el proceso fuerza una fecha fin desde el alta, la organización deja de depender de la memoria o de la buena voluntad para revocar. Luego esa fecha podrá ampliarse por ticket y con motivo, pero el punto de partida ya es sano.

Cuando sea posible, conviene además separar acceso ordinario y acceso privilegiado. Una consultora puede necesitar operar a diario con permisos limitados y solicitar elevación puntual para un cambio concreto. Esa lógica reduce la exposición sin detener el trabajo. El acceso alto existe, pero no vive abierto todo el tiempo.

También es recomendable separar entornos. Si un tercero desarrolla, prueba o analiza, no debería asumir por defecto acceso a producción. Y si por razones de negocio necesita producción, conviene acotarlo a lo estrictamente necesario, revisar el alcance y registrar la actividad. Esta separación no siempre será perfecta, pero incluso una distinción mínima ya mejora mucho el control.

Datos y compartición: colaborar sin copiar todo

En el acceso de terceros, el riesgo no solo está en entrar a un sistema, sino en qué datos se pueden ver, descargar o replicar fuera de él. Muchas organizaciones controlan mejor el login que la compartición posterior. Dan acceso a una plataforma, pero no han decidido qué información debe estar realmente disponible para ese proveedor.

La primera pregunta útil es simple: ¿qué necesita ver el tercero para cumplir su trabajo? No qué podría serle útil en abstracto, sino qué requiere de forma realista. A partir de ahí, conviene preferir acceso controlado frente a copias completas. En vez de exportar bases enteras o compartir carpetas indiscriminadas, suele ser mejor habilitar vistas, subconjuntos, informes limitados o entornos preparados para la tarea.

Esto importa por dos razones. La primera es obvia: menos superficie de datos reduce exposición. La segunda es operativa: cuando la colaboración termina, revocar un acceso controlado es más fácil que perseguir archivos que ya circularon por múltiples canales.

Si hay datos personales o información sensible, la coordinación con legal, cumplimiento o DPO puede ser necesaria según el caso. El artículo no pretende fijar requisitos contractuales concretos, pero sí subrayar una idea: el control de acceso técnico debe ir alineado con el marco contractual y con la clasificación de la información. No son mundos separados.

Un criterio práctico consiste en clasificar los recursos que usan terceros en tres categorías: herramientas de trabajo colaborativo, sistemas operativos con impacto moderado y sistemas críticos o con datos sensibles. Cuanto más se sube en esa escala, más sentido tiene endurecer permisos, exigir evidencia de necesidad y limitar exportaciones.

Operación del ciclo de vida: alta, cambios y baja

La mayor parte de los problemas no nace en la tecnología, sino en el ciclo de vida mal gestionado. Por eso el proceso debe cubrir de principio a fin cómo entra, cambia y sale un tercero.

En el alta, el mínimo viable debería exigir cinco campos: owner interno, proveedor o razón social, sistema o recurso solicitado, rol requerido y fecha fin. Añadir un motivo de negocio también ayuda, porque obliga a justificar el acceso más allá de “lo necesita”. Si además se identifica si habrá acceso a datos sensibles o funciones privilegiadas, mejor aún.

La aprobación no tiene por qué ser pesada. De hecho, cuanto más estándar sea el modelo, más corta puede ser. Si el acceso solicitado encaja en un rol aprobado y en una duración razonable, el circuito puede resolverse rápido. Lo importante es que la excepción sea la excepción: cuando alguien pida un acceso fuera del catálogo, con privilegios elevados o sin fecha fin clara, entonces sí debe escalarse.

En los cambios, conviene evitar ampliaciones informales por mensaje o llamada. Cualquier aumento de privilegio, extensión de plazo o incorporación de nuevos sistemas debería pasar por ticket con motivo. No por burocracia, sino para que quede evidencia de quién lo pidió, quién lo aprobó y durante cuánto tiempo aplica.

La baja merece un checklist propio. Cuando termina el contrato, la campaña o la participación de una persona concreta del proveedor, hay que revocar cuentas, retirar grupos o roles, invalidar sesiones si procede y verificar si existen activos o integraciones bajo su control. También conviene revisar la propiedad de dashboards, automatizaciones, cuentas de servicio patrocinadas o documentos compartidos que pudieran quedar huérfanos.

Si durante la relación se usaron secretos compartidos, claves de integración o accesos a repositorios, la baja puede implicar rotación o sustitución de esos elementos. No siempre será necesario, pero debe evaluarse. El objetivo no es castigar la salida, sino asegurar que el conocimiento y el control vuelven a la organización o a su nuevo proveedor sin dejar puertas abiertas.

Señales de control y métricas que sí sirven

Muchas organizaciones intentan medir demasiado tarde, cuando ya sospechan desorden. Es mejor definir pocas métricas útiles desde el principio. No hacen falta paneles sofisticados para empezar.

La primera métrica es el porcentaje de cuentas de terceros con fecha fin informada. Si ese dato es bajo, el proceso está fallando en lo más básico. La segunda es el tiempo de revocación desde la finalización contractual o desde la comunicación de baja. Cuanto más se alarga, mayor es la exposición innecesaria.

La tercera es la proporción entre accesos privilegiados temporales y permanentes. Si casi todo privilegio elevado acaba siendo estable, probablemente el modelo de roles está mal diseñado o el proceso de elevación es tan incómodo que la organización prefiere dejar los permisos abiertos.

La cuarta es la revisión de cuentas sin actividad. Un acceso que no se usa durante periodos prolongados merece revisión, porque puede indicar trabajo finalizado, mala asignación o simple abandono administrativo. La quinta es el porcentaje de terceros vinculados a un owner interno activo y claramente identificado. Cuando esa relación se pierde, la cuenta suele quedar en tierra de nadie.

Estas métricas tienen valor porque conectan control con operación. No son indicadores abstractos para auditoría; ayudan a detectar dónde el proceso genera fricción o dónde la fricción ha sido sorteada con malas prácticas.

Cómo implantarlo sin bloquear a los equipos

El principal temor de negocio suele ser que formalizar el acceso de terceros ralentice proyectos. Para evitarlo, la implantación debe diseñarse como un sistema de autoservicio gobernado. Es decir: pedir acceso debe ser fácil, pero no ambiguo.

Una forma pragmática de empezar es seleccionar primero los sistemas donde el problema duele más: herramientas corporativas, entornos críticos y plataformas con información sensible. Después se define el formulario único, el catálogo de roles y el checklist de salida. Con eso ya puede arrancar una primera versión.

No hace falta resolver todos los casos especiales desde el día uno. Es mejor lanzar un estándar suficiente para la mayoría y recoger excepciones reales que seguir meses diseñando una política perfecta que nadie usa. Cuando exista una función de compras o vendor management, integrar ahí los mínimos (cuentas nominales, MFA, fecha fin y baja) suele reducir fricciones posteriores.

Por último, conviene comunicar que el objetivo no es prometer riesgo cero. Ningún modelo lo consigue. Lo que sí logra un buen estándar es reducir exposición, mejorar trazabilidad y bajar el coste de gestionar colaboración externa. En términos de negocio, eso significa menos tiempo apagando fuegos administrativos y más capacidad para trabajar con terceros de forma profesional y sostenible.

Errores comunes al poner orden

Tres errores habituales: intentar resolverlo solo desde seguridad (sin dueño de negocio), diseñar una política demasiado sofisticada para la madurez real y posponer el offboarding “para cuando toque”. La fecha fin, el owner y el checklist de salida deben existir desde el alta, o el ciclo acaba quedando abierto.

Glosario mínimo

Cuenta nominal: identidad individual asignada a una persona concreta, no compartida con otras.

MFA: mecanismo de autenticación con más de un factor, útil para reducir el riesgo derivado de credenciales comprometidas.

Mínimo privilegio: principio por el que cada usuario recibe solo los permisos necesarios para su función.

Elevación temporal: acceso privilegiado concedido por un tiempo limitado para una tarea específica.

Owner interno: persona o área de la organización que patrocina y justifica el acceso del tercero.

Offboarding: proceso de retirada ordenada de accesos, permisos, activos y dependencias al finalizar una relación o proyecto.

En resumen, dar acceso a terceros de forma segura no exige convertir cada colaboración en un proyecto de seguridad. Exige dejar de improvisar. Cuando la organización define identidades nominales, MFA, roles simples, fechas fin y una salida obligatoria, el acceso de terceros deja de ser una colección de excepciones eternas y pasa a ser un proceso manejable. Ahí está el verdadero beneficio: menos deuda, más continuidad y una colaboración externa que escala sin perder control.