Un auditor no pregunta si tienes logs. Da por hecho que los tienes. Lo que pregunta es otra cosa: quién accedió a este sistema, cuándo, y por qué se le permitió. Y después pide que se lo demuestres con un documento que él pueda conservar.

Esa segunda parte es donde se cae la mayoría de despliegues de acceso remoto.

Por qué un log no es una evidencia

Un log registra que algo ocurrió. Una evidencia sostiene una afirmación ante alguien que no estaba delante y que no tiene por qué fiarse de ti.

Para que un registro de acceso sirva en una auditoría necesita cuatro cosas:

Quién: la identidad concreta, no una IP ni un usuario compartido.
Qué: el recurso al que se accedió, identificado sin ambigüedad.
Cuándo: marca temporal fiable, y durante cuánto tiempo se conserva.
Por qué se permitió: la regla que autorizó ese acceso. O, si se denegó, qué reglas estuvieron cerca de permitirlo y qué cláusula concreta falló.

La cuarta es la que casi nunca está. Un firewall te dice ALLOW. No te dice por qué. Y cuando el auditor pregunta "¿por qué este usuario podía llegar a esa base de datos?", la respuesta reconstruida a mano desde una tabla de reglas no es una evidencia: es una interpretación.

A eso hay que añadir una quinta condición, que es la que convierte el registro en algo defendible: que se pueda demostrar que no ha sido modificado. Un CSV exportado desde un panel es un archivo que cualquiera con acceso puede editar. Sin sellado ni encadenamiento, su valor probatorio es el que le quieras dar.

Qué exige el ENS en materia de trazabilidad

El Esquema Nacional de Seguridad trata la trazabilidad como un requisito propio, no como un efecto secundario del control de accesos. En la práctica, esto se traduce en tres exigencias que conviene leer literalmente:

Registrar quién hace qué sobre qué recurso, con identificación individual. Las cuentas compartidas rompen la trazabilidad antes de empezar.
Conservar esos registros durante un periodo determinado, coherente con la categoría del sistema. Un histórico de siete días no permite responder a un incidente detectado tres meses después.
Proteger los registros frente a modificación y borrado, incluido por parte de quien los administra.

Ese tercer punto es incómodo y es el que más se pasa por alto. Si el administrador de la plataforma puede editar el registro que lo audita, el registro no audita a nadie.

Por qué la ubicación de los datos deja de ser un detalle técnico

Mientras todo va bien, dónde están los servidores parece una cuestión de latencia. Deja de serlo en dos momentos: cuando hay una auditoría y cuando hay un requerimiento legal.

Un proveedor sujeto a jurisdicción estadounidense está sometido al CLOUD Act, que permite requerir datos bajo su control aunque estén almacenados fuera de Estados Unidos. No es una hipótesis sobre sus intenciones: es el marco legal que se le aplica, con independencia de lo que diga su política de privacidad.

Para el responsable de sistemas de una pyme española, o para un MSP que responde ante sus clientes, esto tiene una consecuencia concreta: hay una pregunta del cuestionario de proveedores que no puede contestar con un "sí" limpio.

En ConnectaSec los servidores están ubicados en territorio español. El cumplimiento del RGPD es nativo, no una capa contractual añadida, y la plataforma está alineada con el ENS. La gestión de la seguridad de la información está certificada en ISO 27001 por RINA e IQNet.

Cómo lo resuelve ConnectaSec

Sin rodeos, lo que hay:

Registro de decisiones, no solo de eventos. Cada acceso queda registrado junto con el motivo de la decisión: qué regla lo permitió, o qué reglas estuvieron cerca de permitirlo y qué cláusula concreta falló. Es la diferencia entre "denegado" y "denegado porque el dispositivo no cumplía la condición de postura exigida por la regla que, por lo demás, sí encajaba".

Retención de 365 días. Un año completo de historial disponible, sin depender de que alguien se acordara de exportar nada.

Informe de evidencia por cliente. Sellado y encadenado por hash, de forma que cualquier alteración posterior es detectable. Se entrega en PDF, para leerlo y adjuntarlo al expediente, y en CSV, para trabajarlo. Por cliente, no por infraestructura: el MSP entrega a cada uno el suyo, sin filtrar a mano.

Panel multicliente desde el diseño. La separación entre clientes no es una funcionalidad añadida después para encajar en el modelo MSP. Es como está construido el panel.

Qué cubre esto y qué no

Este apartado importa tanto como el resto.

Lo que cubre: las decisiones de acceso que pasan por ConnectaSec. Quién se conectó, a qué recurso, cuándo, y con qué regla se resolvió la decisión. Eso queda registrado, se conserva 365 días y se puede entregar sellado y verificable.

Lo que no cubre:

Lo que ocurre dentro de la sesión. Registramos que un usuario accedió a un servidor y por qué se le permitió. Lo que ejecute después dentro de ese servidor pertenece a la auditoría del propio sistema, no a la del acceso.
Los accesos que no pasan por la plataforma. Una consola de administración expuesta directamente, un acceso físico o un túnel paralelo quedan fuera. Cubrir el perímetro es una decisión de despliegue, no algo que se resuelva por contratar la herramienta.
La certificación de tu organización. Nuestra ISO 27001 acredita nuestra gestión, no la tuya. Ayuda como evidencia sobre un proveedor y reduce trabajo en tu auditoría, pero no certifica a nadie más.
El criterio. La plataforma registra fielmente las reglas que hayas definido. Si una regla está mal, el informe demostrará con precisión que se aplicó una regla mal definida.

Esa última es, en realidad, el resumen de todo: no vendemos que tus accesos sean correctos. Vendemos que puedas demostrar, con un documento verificable, exactamente cuáles fueron y por qué.

¿Quieres ver un informe de evidencia real sobre un entorno de prueba? Solicita una demo.