Un proveedor puede necesitar entrar en una aplicación, consultar una carpeta, conectarse a una VPN o administrar un servicio concreto para prestar soporte. El problema aparece cuando ese acceso se crea con prisa, se comparte entre varias personas o permanece activo cuando termina el trabajo. No basta con pedir al proveedor que use una contraseña segura: la empresa debe poder explicar quién accede, para qué, durante cuánto tiempo y cómo se retira el permiso.
Este artículo está dirigido a responsables de IT, seguridad y operaciones que trabajan con proveedores de soporte, implantación, mantenimiento o servicios gestionados. El objetivo es diseñar un ciclo de acceso de terceros que permita trabajar sin convertir una necesidad puntual en un privilegio permanente.
Empiece por separar el acceso del proveedor de la relación contractual
Un contrato vigente no implica que todas las personas del proveedor deban conservar acceso técnico. Tampoco un acceso técnico demuestra por sí solo que exista una autorización comercial o de seguridad. Conviene tratar ambos planos por separado: el responsable de la relación valida que el trabajo sigue siendo necesario; el responsable del sistema decide el alcance técnico y revisa la evidencia de uso.
Antes de crear una cuenta, registre una ficha mínima:
- proveedor, servicio contratado y responsable interno;
- persona o identidad nominal que usará el acceso; evite cuentas compartidas;
- sistema, entorno y datos a los que necesita llegar;
- tarea concreta, periodo previsto y franja de intervención si aplica;
- permisos solicitados, aprobador y condiciones de uso;
- método para retirar el acceso y evidencia que confirmará la retirada.
Si no se puede completar esta ficha, la solicitud aún no está preparada para automatizarse. El flujo puede pedir los datos que faltan, pero no debería inferir el alcance a partir del nombre del proveedor o de un correo informal.
Diseñe accesos por tarea y con fecha de caducidad
El punto de partida es el mínimo privilegio aplicado a una actividad concreta. Un proveedor que revisa registros de una integración no necesita administrar usuarios; quien actualiza un equipo no necesita navegar por el repositorio documental de la empresa. Cuando la plataforma lo permita, limite el acceso por rol, proyecto, carpeta, activo, red o API, en lugar de entregar un permiso global.
Elija una duración explícita
La mayoría de accesos de terceros debería tener una fecha de finalización. Para una intervención puntual, puede ser una ventana de horas; para un mantenimiento recurrente, una vigencia corta que requiera renovación documentada. La fecha no sustituye a la revocación: sirve para que una excepción no quede abierta por olvido.
Si un proveedor necesita disponibilidad continuada, documente por qué el acceso permanente es necesario, qué controles compensatorios existen y quién revisará esa decisión. Un acceso indefinido solo por comodidad dificulta distinguir la operación normal de una excepción.
Use identidades nominales y autenticación reforzada
Cada técnico debería usar una identidad propia, vinculada al proveedor y, cuando sea posible, protegida con autenticación multifactor. Las cuentas genéricas impiden saber quién realizó una acción y complican la baja cuando cambia el equipo del proveedor. Las cuentas técnicas pueden ser necesarias para integraciones automáticas, pero deben tener propietario interno, permisos limitados y un proceso separado de rotación de credenciales.
Un flujo práctico para solicitudes de acceso externo
La automatización puede reducir correos y tareas manuales sin decidir por sí sola qué privilegios conceder. Un flujo razonable puede seguir estos pasos:
- Recibir y validar la solicitud. Comprobar proveedor, persona, sistema, finalidad, periodo y responsable interno.
- Clasificar el riesgo con reglas visibles. Distinguir, por ejemplo, lectura de documentación, acceso a producción, administración de identidades o acceso a datos personales.
- Asignar una ruta de aprobación. La solicitud de bajo riesgo puede ir al propietario del sistema; una que afecte a producción, red o datos sensibles debe escalar al responsable correspondiente.
- Crear el acceso con alcance limitado. Aplicar el rol aprobado y registrar el identificador de la cuenta, no contraseñas ni secretos.
- Notificar condiciones y vencimiento. Indicar qué se ha concedido, cuándo caduca y cómo solicitar una ampliación justificada.
- Revisar uso y retirar. Confirmar que la tarea terminó, revocar grupos, sesiones, tokens o reglas temporales y guardar la evidencia.
La IA puede ayudar a extraer datos de una solicitud, detectar campos ausentes o preparar un resumen para quien aprueba. La asignación de privilegios, las reglas de criticidad y la aprobación de acciones sensibles deben permanecer en controles deterministas y revisables.
Ejemplo: soporte de un proveedor sobre una aplicación de negocio
Una empresa necesita que un proveedor investigue un error en una aplicación de atención al cliente. La solicitud indica el incidente, los registros que debe consultar y una ventana de un día. El flujo comprueba que el contrato y el responsable interno están vigentes, propone un rol de solo lectura en el entorno afectado y lo envía a aprobación del propietario de la aplicación.
Al aprobarse, se crea una cuenta nominal con fecha de caducidad y autenticación multifactor. El proveedor recibe las condiciones de acceso, mientras que el equipo interno conserva el enlace al ticket y el registro de concesión. Al cierre del incidente, el flujo solicita confirmación al responsable, revisa la actividad y desactiva la cuenta. Si el proveedor necesita más tiempo, debe existir una nueva aprobación: no basta con prolongar la cuenta sin revisar el motivo.
Este diseño no sirve para todas las situaciones. Si la intervención implica una operación física, un sistema crítico o conectividad inestable, puede requerirse una ventana de mantenimiento, supervisión local o una ruta de emergencia específica.
Revise tanto los accesos sin uso como los que siguen activos
La revisión periódica evita que un acceso otorgado para un proyecto termine siendo permanente. Agrupe las cuentas de terceros por proveedor, propietario interno, sistema y fecha de última actividad. Después, plantee preguntas concretas: ¿la relación sigue activa?, ¿la persona continúa asignada al servicio?, ¿el permiso sigue siendo el mínimo necesario?, ¿ha caducado una justificación o un contrato?, ¿se han usado credenciales técnicas fuera del flujo previsto?
Un informe de revisión útil no necesita ser complejo. Para cada excepción debe mostrar el acceso, la finalidad, el aprobador, la fecha de concesión, el vencimiento, la actividad observada y la decisión de mantener, reducir o revocar. Si el propietario no responde, defina una ruta de escalado y una política clara para suspender accesos no confirmados.
Qué evidencias deben quedar
Para poder investigar una incidencia o responder a una auditoría, conserve referencias a la solicitud, la aprobación, el rol concedido, el periodo autorizado, los eventos relevantes de acceso y la confirmación de retirada. Proteja esos registros: pueden revelar sistemas, usuarios o actividad sensible. La evidencia debe ser suficiente para reconstruir una decisión, no un repositorio indiscriminado de sesiones y secretos.
También conviene probar la baja. Revocar un grupo en un directorio no garantiza que un token, una sesión activa, una regla de VPN o una cuenta local hayan desaparecido. La comprobación debe cubrir los mecanismos que realmente se usaron para dar acceso.
Límites y criterios de decisión
No automatice la concesión directa si no existe un catálogo de roles, un propietario de cada sistema o una forma fiable de revocar. En ese caso, el primer paso es ordenar el inventario y acordar las reglas. Tampoco use un agente IA para aprobar su propio acceso, interpretar libremente un permiso administrativo o modificar políticas sin una barrera humana.
Es buen momento para implantar este proceso cuando se repiten altas urgentes de proveedores, hay cuentas compartidas, nadie sabe qué accesos siguen activos o se gestionan varias herramientas sin una vista común. Empiece por un proveedor y un sistema de riesgo acotado; mida solicitudes incompletas, accesos vencidos sin retirar y tiempo de cierre. Amplíe el alcance cuando pueda demostrar que la autorización y la revocación funcionan de extremo a extremo.
En KMOOPS ayudamos a diseñar automatizaciones, integraciones y controles de seguridad adaptados al proceso real de cada organización. Consulte nuestros servicios o contacte con el equipo para revisar un caso concreto.