Despliegues soberanos definidos para cada proyecto.

Un proyecto con el equipo de seguridad del cliente. No una descarga.

Un despliegue soberano se define, presupuesta y entrega como un proyecto de implantación: infraestructura y jurisdicción del cliente, sus controles de seguridad y un plan de refuerzo y verificación acordado con su equipo. No hay instalador de autoservicio ni entorno de prueba; para este comprador no serían adecuados.

Los límites se indican expresamente. No se comercializa como un sistema aislado de la red: en las configuraciones con sellado de tiempo conectado descritas abajo, una huella SHA-256 del registro sale del perímetro hacia una autoridad independiente. Esa salida es precisamente lo que permite acreditar la hora sin depender solo del operador. Si el cliente necesita aislamiento completo, puede desactivar el sello de tiempo independiente, y las afirmaciones sobre el registro se reducen en consecuencia, por escrito. Las implicaciones de cada configuración se explican desde el principio.

Cada dependencia externa se configura por separado. Cada opción tiene una consecuencia declarada.

Las funciones de la plataforma que pueden conectarse a servicios externos están separadas mediante interfaces comunes, adaptadores identificados y una selección configurable. En un despliegue soberano, cada una queda desactivada, la aporta el cliente o la opera Exedra Gate, según el acuerdo. La tabla explica qué significa cada opción para las afirmaciones sobre el registro: una configuración sin afirmaciones documentadas puede dejar de corresponder a lo que se comunica comercialmente en pocos meses.

Se declara para cada configuración, porque solo es cierto bajo sus condiciones: con la verificación, las comprobaciones y el correo en modo cliente o desactivados, y el sello de tiempo desactivado o local, ni documentos, ni claves, ni eventos salen del perímetro del cliente durante el funcionamiento ordinario. Cada módulo que pasa a un servicio operado añade exactamente la salida indicada en su fila.

El sello de tiempo independiente es la decisión central. Se toma de forma deliberada.

Todos los paquetes de evidencias están firmados y encadenados por hashes en las cuatro opciones. La diferencia es el sello de tiempo: quién lo emite, qué sale del perímetro para obtenerlo y qué puede afirmarse después. La opción se acuerda por escrito antes de poner nada en marcha. La configuración conectada es la predeterminada porque mantiene la afirmación de hora independiente sin exigir al cliente que contrate su propio servicio de confianza. Quien prefiera un proveedor cualificado propio elige la segunda opción.

• PREDETERMINADA

  Conectada: sello de tiempo de una autoridad designada por Exedra Gate. Es la opción predeterminada. La única salida es una huella SHA-256 enviada para obtener un sello de tiempo conforme a RFC 3161. Se mantiene íntegra la afirmación de hora independiente, y el despliegue se describe como conectado pero privado, nunca como aislado. La autoridad designada es independiente de Exedra Gate, que no es un prestador cualificado de servicios de confianza. Cuando un proyecto exige la presunción jurídica de un sello cualificado según el marco europeo, los sellos de la autoridad designada se contratan a un prestador cualificado en lugar de emitirse internamente. El acuerdo identifica al prestador y su condición.

• PRESTADOR CUALIFICADO DEL CLIENTE

  Sello de tiempo de una autoridad cualificada contratada por el cliente. La opción superior. Las huellas se envían al prestador de servicios de confianza del propio cliente. En el marco europeo, un sello de tiempo cualificado goza de una presunción jurídica que no corresponde a uno ordinario (eIDAS, Art. 41(2)); el cliente que ya tenga un prestador cualificado conserva esa ventaja en su propia relación contractual, sin que Exedra Gate forme parte de ella.

• LOCAL

  Sello de tiempo emitido dentro del perímetro. No sale nada. La afirmación se reduce por escrito y en el propio registro: quien emite el sello de tiempo es el mismo operador que controla el almacén de evidencias. Por ello, el registro tiene un sello interno cuyo formato puede verificarse externamente, pero nunca se presenta como sellado por una autoridad independiente.

• DESACTIVADO

  Sin sello de tiempo. Los paquetes siguen firmados y encadenados por hashes, y las afirmaciones se limitan a la integridad y el orden, con fechas de los relojes del propio operador. Se ofrece esta opción porque existen exigencias de aislamiento completo; se explica con claridad para que el cliente sepa qué propiedad de la evidencia deja de tener.

En un despliegue soberano rigen sus controles.

Las plataformas en la nube responden sobre seguridad con sus propias certificaciones porque alojan sus datos. Aquí la plataforma funciona dentro de su perímetro: las actualizaciones se entregan como artefactos firmados que su equipo de seguridad revisa y aprueba antes de implantarlas, y el alcance de la auditoría sigue siendo suyo. En la configuración predeterminada, la única salida habitual es una huella de documento enviada para sellado de tiempo independiente. Lo indicamos expresamente.

Un registro de auditoría ordinario puede ser una tabla que el administrador reescribe. Este registro permite detectar la reescritura.

Una pregunta que plantea todo equipo de seguridad sobre un sistema de evidencias es qué pueden hacer sus propios administradores con él. En muchas plataformas, el registro de auditoría son filas de una base de datos que una persona con control de la base puede editar a posteriori sin dejar rastro. Aquí cada acción se ordena en una cadena de hashes: cada entrada incorpora el hash de la anterior, el registro se firma con Ed25519 y, en las configuraciones conectadas, se vincula a sellos de tiempo RFC 3161 emitidos por una autoridad independiente. Modificar o eliminar una entrada después rompe la secuencia; una verificación permite detectar la ruptura, con independencia de quién hizo el cambio o de sus privilegios.

Es una promesa deliberadamente más limitada que el término habitual del sector y, por eso, más comprobable. Nada impide por completo que una persona con privilegios actúe; ningún sistema honesto puede prometerlo. Lo que el sistema de evidencias permite es detectar y atribuir alteraciones posteriores: puede comprobarse cómo estaba el registro, y uno alterado deja de verificarse. Lo detectable puede demostrarse. Lo inalterable solo puede afirmarse.

El sistema de evidencias permanece bajo control del cliente.

En todas las configuraciones: motor de firma propio, sin proveedor externo de firma electrónica; control de acceso por documento y persona con aislamiento de clientes a nivel de fila; registro de auditoría encadenado por hashes; paquetes de evidencias en formatos estándar, con SHA-256 para las huellas, Ed25519 para las firmas y tokens RFC 3161 cuando la configuración los incluya, comprobables sin conexión con herramientas estándar gratuitas; y un canal de actualización en el que el equipo de seguridad del cliente aprueba cada cambio antes de aplicarlo.

Nueve sectores en los que los marcos aplicables hacen concreto el caso.

Cada página presenta la situación normativa de su sector con fuentes primarias, qué cambiaría un despliegue soberano, la configuración plausible de sus módulos y lo que Exedra Gate no resuelve. Esta última sección aparece deliberadamente en todas las páginas.