Acceso temporal para el técnico de mantenimiento: cómo gestionar proveedores externos en el sistema de la clínica

1. Cuándo un proveedor externo necesita acceso al sistema

Los proveedores externos no acceden al sistema clínico todos los días. Son intervenciones puntuales con un principio y un fin definidos.

1.1. Mantenimiento del sistema: actualizaciones y parches

El proveedor del sistema de gestión necesita acceso para instalar actualizaciones, corregir errores o ajustar la configuración. Suele ser un acceso técnico al servidor o al panel de administración, no a los datos clínicos de los pacientes. Pero si el sistema no separa el acceso técnico del acceso a datos, una cuenta de mantenimiento puede ver historiales clínicos aunque solo necesite ver la configuración.

1.2. Soporte técnico: resolución de incidencias

Cuando algo falla, el equipo de soporte del proveedor necesita acceso para diagnosticar y resolver el problema. A veces el diagnóstico requiere ver datos reales —por ejemplo, verificar que un registro se ha guardado correctamente—, pero en la mayoría de los casos el soporte se puede prestar sin acceder a datos de pacientes. La diferencia entre un soporte que necesita datos y uno que no la define el tipo de incidencia, no la comodidad del técnico.

1.3. Consultoría y auditoría externa

Un consultor que revisa la configuración del sistema o un auditor que verifica el cumplimiento de la normativa pueden necesitar acceso a pantallas de configuración, informes de actividad o registros de auditoría. Rara vez necesitan acceso a datos clínicos de pacientes individuales. Si el consultor necesita ver datos para su evaluación, se le proporcionan datos anonimizados o se le acompaña durante la consulta.

2. El riesgo de un acceso externo no controlado

Un proveedor externo que accede al sistema de la clínica es una persona que no está bajo el control organizativo directo de la clínica. Eso cambia el perfil de riesgo.

2.1. La cuenta que se olvidan de cerrar

El técnico viene, hace su trabajo y se va. La cuenta que se creó para él sigue activa. Nadie la cierra porque nadie se acuerda de que existe. Tres meses después, la revisión periódica encuentra una cuenta activa de un proveedor que ya no tiene contrato. Si en esos tres meses alguien usó esa cuenta, la clínica tiene un problema de acceso no autorizado.

2.2. La cuenta compartida entre técnicos

El proveedor tiene una cuenta genérica —«soporte_proveedor»— que usan distintos técnicos según quién esté de turno. Si algo pasa, la clínica sabe que fue «el proveedor» pero no sabe qué persona concreta accedió. La trazabilidad se rompe en el punto exacto donde más se necesita: cuando el acceso es externo.

2.3. El acceso excesivo «para que no tenga que pedir cada vez»

Para evitar solicitudes repetidas, se le da al proveedor un acceso amplio y permanente. Es cómodo para las dos partes, pero convierte un acceso puntual en un acceso abierto que ya nadie supervisa. El coste de gestionar solicitudes puntuales es menor que el coste de una brecha de seguridad a través de una cuenta de proveedor comprometida.

3. Temporal de verdad: fecha de inicio, fecha de fin

Un acceso temporal que no tiene fecha de fin no es temporal: es permanente con un nombre distinto.

3.1. La fecha de expiración automática

Si el sistema permite configurar una fecha de expiración en la cuenta, la cuenta se desactiva automáticamente cuando llega la fecha. No hay que acordarse, no hay que enviar una petición y no hay riesgo de olvido. La fecha de expiración se establece cuando se crea la cuenta, basándose en la duración prevista de la intervención. Si la intervención se alarga, se extiende la fecha con una nueva justificación.

3.2. La duración proporcional a la necesidad

Una actualización que lleva dos horas necesita un acceso de un día, no de un mes. Un proyecto de migración que dura tres semanas necesita un acceso de tres semanas, no de seis meses «por si hay que volver». La duración del acceso es proporcional a la necesidad: ni más corta —para no generar solicitudes innecesarias— ni más larga —para no dejar una puerta abierta más tiempo del necesario—.

3.3. El acceso recurrente: el proveedor que viene cada mes

Si un proveedor tiene un contrato de mantenimiento mensual, hay dos opciones: una cuenta permanente con alcance restringido y supervisión, o una cuenta temporal que se activa cada mes durante la ventana de mantenimiento. La segunda es más segura pero más costosa de gestionar. La primera es aceptable si el alcance está bien limitado, la actividad se registra y la revisión periódica verifica que el proveedor sigue teniendo contrato.

4. Limitar el alcance: solo lo que necesita

El principio de mínimo privilegio aplica con más razón a los accesos externos que a los internos.

4.1. Acceso técnico, no acceso clínico

Un técnico que viene a actualizar el sistema necesita acceso al panel de administración, no a las historias clínicas. Un técnico que viene a reparar el servidor necesita acceso al servidor, no a la base de datos de pacientes. Si el sistema no permite esa separación, el riesgo se gestiona con supervisión presencial: el técnico trabaja con alguien de la clínica al lado que verifica que no accede a datos que no necesita.

4.2. Acceso a un módulo, no a todo el sistema

Si el proveedor mantiene un módulo específico —la agenda, la facturación, el módulo de informes—, su acceso debería estar limitado a ese módulo. No hay razón para que el proveedor de la agenda pueda ver la configuración de facturación o los parámetros del módulo clínico. El sistema de permisos por pantalla permite dar acceso granular si el rol se configura correctamente.

Un acceso temporal sin fecha de caducidad no es temporal: es un acceso permanente con otro nombre.

4.3. Acceso de solo lectura cuando basta con diagnosticar

Si el técnico viene a diagnosticar un problema, no necesita modificar nada: necesita ver la configuración, los registros de error y el estado del sistema. Un acceso de solo lectura limita el riesgo de que una operación de diagnóstico se convierta en una modificación no autorizada. Si el diagnóstico concluye que hay que cambiar algo, se amplía el permiso con justificación para la modificación concreta.

5. Cuenta dedicada, nunca compartida

Cada persona que accede al sistema tiene su propia cuenta. Esa regla aplica al personal interno y aplica con más razón al personal externo.

5.1. Una cuenta por técnico, no por proveedor

Si el proveedor envía a dos técnicos distintos a lo largo del año, cada uno tiene su propia cuenta. No una cuenta «soporte» que usan los dos. La cuenta nominal permite saber quién hizo qué: si el técnico A modificó la configuración y el técnico B accedió a un informe, el registro lo refleja. Con una cuenta compartida, los dos accesos son indistinguibles.

5.2. Nunca usar la cuenta de un empleado

El técnico no debería usar la cuenta de un empleado de la clínica para acceder al sistema. Lo que hace el técnico aparecería atribuido al empleado, y cualquier anomalía sería inexplicable en una auditoría. Además, el empleado estaría compartiendo sus credenciales, lo que en sí mismo es una práctica prohibida por la mayoría de las políticas de seguridad.

5.3. Credenciales que no se reutilizan

Cada acceso temporal tiene credenciales propias que se generan al crear la cuenta y se invalidan cuando se cierra. No se reutilizan las credenciales de un acceso anterior, aunque el técnico sea el mismo. Si el técnico vuelve tres meses después, se le crea una cuenta nueva con credenciales nuevas. Eso evita que unas credenciales olvidadas en un correo electrónico o en un post-it sirvan para acceder al sistema meses después.

6. Supervisión durante el acceso

El acceso temporal no es un acceso desatendido. Mientras el técnico está trabajando, alguien de la clínica debería saber qué está haciendo.

6.1. Supervisión presencial para accesos sensibles

Si el técnico necesita acceder a datos sensibles —por ejemplo, para verificar que un dato se ha migrado correctamente—, la supervisión debería ser presencial. Alguien de la clínica acompaña al técnico y verifica que solo accede a lo que necesita. No es desconfianza: es procedimiento. El técnico competente lo entiende y lo valora.

6.2. Registro de actividad del acceso temporal

Todo lo que el técnico hace con su cuenta temporal queda registrado en el sistema: qué pantallas abrió, qué configuraciones modificó, qué datos consultó. Ese registro es la evidencia de que el acceso se usó para lo que se autorizó. Si el registro muestra algo inesperado, la clínica puede investigarlo con el proveedor.

7. El cierre: verificar que el acceso se ha revocado

El cierre del acceso temporal es tan importante como su apertura. Si no se cierra, todo lo anterior —la limitación de alcance, la fecha de expiración, la supervisión— pierde su valor.

7.1. Cerrar el mismo día que termina la intervención

Cuando el técnico termina su trabajo, la cuenta se desactiva. No al día siguiente, no cuando alguien se acuerde: el mismo día. Si el sistema tiene expiración automática, se verifica que ha funcionado. Si no la tiene, el administrador desactiva la cuenta manualmente y lo registra.

7.2. Verificar qué hizo el técnico antes de cerrar

Antes de cerrar la cuenta, se revisa el registro de actividad. ¿Accedió a lo que se esperaba? ¿Modificó algo fuera del alcance autorizado? ¿Consultó datos de pacientes? Si todo es coherente con la intervención, se cierra. Si hay algo inesperado, se investiga antes de cerrar y se documenta.

7.3. Documentar el acceso completo

El acceso temporal genera un expediente: quién solicitó el acceso, para qué, cuándo se abrió, cuándo se cerró, qué hizo el técnico y si se detectó alguna anomalía. Ese expediente se conserva como parte de la gestión de proveedores y como evidencia ante una posible auditoría. Si un día alguien pregunta qué accesos externos tuvo el sistema, la respuesta está en el expediente.

8. Lo que la normativa exige a los accesos de terceros

Los accesos de proveedores externos son tratamientos de datos por cuenta del responsable, y la normativa los regula de forma específica.

8.1. El contrato de encargado del tratamiento

Si el proveedor accede a datos personales —aunque sea de forma incidental—, la clínica necesita un contrato de encargado del tratamiento conforme al artículo 28 del RGPD. Ese contrato define qué datos puede tratar el proveedor, para qué finalidad, con qué medidas de seguridad y qué pasa cuando el contrato termina. Sin ese contrato, el acceso del proveedor es un tratamiento sin base legal.

8.2. La obligación de minimizar el acceso

El contrato de encargado del tratamiento debería limitar el acceso del proveedor a lo estrictamente necesario para la prestación del servicio. Si el proveedor necesita actualizar el software, su acceso se limita al panel de administración. Si necesita diagnosticar un error, se limita a los registros de error. La clínica es responsable de que el acceso concedido sea proporcional a la necesidad, y el contrato es la herramienta legal que lo formaliza.

8.3. El deber de confidencialidad del proveedor

El proveedor y sus técnicos están sujetos a un deber de confidencialidad sobre los datos a los que acceden. Ese deber no nace de la buena fe: nace del contrato y de la ley. Si un técnico del proveedor utiliza datos a los que accedió durante un mantenimiento para cualquier otro fin, tanto el técnico como el proveedor responden, y la clínica también si no puso las medidas razonables para evitarlo.

9. Qué aporta obeliOmed

obeliOmed permite crear cuentas temporales con fecha de expiración automática, alcance limitado y registro completo de actividad.

9.1. Cuentas temporales con expiración automática

El administrador crea una cuenta para el técnico, le asigna un rol limitado a las pantallas que necesita y establece una fecha de expiración. Llegada la fecha, la cuenta se desactiva sola. No hay un paso manual que olvidar ni una petición pendiente que procesar. El técnico puede trabajar durante la ventana autorizada y el sistema se cierra cuando termina.

9.2. Registro de actividad separado para cuentas externas

El informe de accesos puede filtrarse para mostrar solo la actividad de cuentas externas. Eso permite al DPO revisar todos los accesos de proveedores en un período determinado sin tener que buscarlos entre los accesos del personal interno. La separación facilita tanto la supervisión durante la intervención como la revisión posterior.