La mayoría de los debates sobre la soberanía se centran en lo que los proveedores dicen sobre sus productos. El debate más útil se centra en lo que los proveedores han creado. La arquitectura es más difícil de simular que el marketing. Las decisiones de diseño que un proveedor tomó años antes de que la soberanía se convirtiera en un requisito de contratación suelen determinar si la soberanía se puede garantizar en la práctica o si solo queda descrita en un contrato.

Algunas decisiones de diseño preservan el control del cliente. Otras lo ceden. Una vez que un sistema se ha construido en torno a un conjunto concreto de decisiones, la postura de soberanía resultante no puede modificarse a posteriori mediante anexos contractuales o juegos de trileros jurisdiccionales. La arquitectura es la respuesta.

La pregunta sobre la clave criptográfica es la prueba más clara

La prueba arquitectónica más clara de la soberanía es quién posee las claves criptográficas. No se trata de quién se ha comprometido contractualmente a no utilizarlas ni de quién ha acordado no revelarlas en circunstancias normales, sino de quién las posee.

Dos arquitecturas dan lugar a dos posturas de soberanía sustancialmente diferentes.

Claves en poder del proveedor. El proveedor, en su calidad de operador del servicio, conserva las claves que protegen los datos de los clientes. El proveedor se compromete, por contrato, a no utilizar dichas claves para fines ajenos a la prestación del servicio. La protección del cliente recae en el contrato, las políticas del proveedor y la integridad operativa de este.

Claves en poder del cliente. El cliente conserva las claves en una infraestructura de gestión de claves controlada por él mismo. El proveedor, en su calidad de operador del servicio, carece de capacidad técnica para acceder a los datos protegidos, ni siquiera si así lo exige una autoridad legal, ni siquiera en caso de que se produzca una filtración interna, ni siquiera si se rescinde el contrato.

En el primer modelo, la confidencialidad de los datos del cliente depende de la cooperación continua del proveedor, de su integridad y de su resistencia a la coacción. En el segundo, depende de la gestión de claves por parte del propio cliente.

Esto cobra mayor importancia en situaciones conflictivas: coacción legal, compromiso de seguridad por parte del proveedor, litigio contractual o perturbaciones geopolíticas. En condiciones normales de funcionamiento, ambas arquitecturas parecen idénticas. Sin embargo, en situaciones de estrés, divergen notablemente. Un proveedor que posea las claves puede verse obligado a revelar datos por una orden judicial de su jurisdicción, por un régimen de coacción gubernamental o por una violación suficientemente sofisticada de su infraestructura de gestión de claves. Un proveedor que nunca haya tenido las claves no puede revelar aquello a lo que no tiene acceso.

Para los clientes a los que les preocupa la soberanía, esta única decisión arquitectónica contribuye más a la soberanía que la mayoría de las cláusulas contractuales juntas. Y es una decisión que debe tomarse en una fase temprana del diseño del sistema. Incorporar claves gestionadas por el cliente a una arquitectura basada en claves gestionadas por el proveedor no es una refactorización, sino una reescritura.

La topología de implementación determina la soberanía operativa

La segunda prueba arquitectónica consiste en comprobar si el sistema puede funcionar independientemente de la infraestructura en la nube del proveedor.

Una arquitectura exclusivamente SaaS, en la que el cliente se suscribe a un servicio en la nube gestionado por el proveedor, ofrece comodidad al cliente y otorga al proveedor autoridad operativa permanente. El cliente no puede gestionar el sistema; solo el proveedor puede hacerlo. La continuidad del cliente depende de la continuidad del proveedor. El cumplimiento normativo del cliente depende de la política de cumplimiento del proveedor. La ubicación geográfica de los datos del cliente depende de las opciones de configuración que ofrezca el proveedor dentro de su nube. El cliente es, estructuralmente, un inquilino y la soberanía operativa se ha transferido al proveedor.

Una topología de implementación que incluya configuraciones locales gestionadas por el cliente —en las que este pueda ejecutar el sistema en su propia infraestructura, con su propio equipo de operaciones, en su propia jurisdicción y en su propio hardware— da lugar a una postura de soberanía estructuralmente diferente. El cliente puede aislar el sistema por completo de la Internet pública. El cliente puede mantener el sistema en funcionamiento incluso durante periodos de interrupción de la conectividad. El cliente puede someter el sistema a su propia auditoría, a su propio control de cambios y a su propia gobernanza. El proveedor suministra el software. El cliente se encarga de su funcionamiento.

Las implementaciones que mejor preservan la soberanía van aún más allá. Las configuraciones «air-gapped», en las que el sistema funciona en un entorno del cliente sin conexión alguna con la infraestructura del proveedor con fines operativos, representan el máximo control operativo que un proveedor puede ofrecer. El cliente es independiente desde el punto de vista operativo. Las actualizaciones se transmiten a través de canales controlados que gestiona el cliente. La telemetría, si la hay, circula por vías controladas por el cliente. La continuidad del proveedor no es una condición previa para que el cliente siga operando.

Este abanico de topologías de implementación, que va desde el SaaS puro en un extremo hasta un entorno totalmente aislado en el otro, constituye el eje de la soberanía operativa. La mayoría de los debates reales sobre la soberanía giran en torno a qué punto de este eje debe situarse un cliente concreto y si la arquitectura del proveedor permite esa posición.

Un proveedor cuya arquitectura solo admita SaaS, sin opción de implementación local, ha limitado de forma fundamental la soberanía operativa del cliente, independientemente del nivel de rigor de su nube. Un proveedor cuya arquitectura admita toda la gama —SaaS para los clientes que buscan comodidad, implementación local para los que necesitan control operativo y sistemas aislados físicamente para los que operan en entornos clasificados o críticos— ofrece al cliente la posibilidad de elegir su nivel de soberanía. La diferencia arquitectónica supone décadas de inversión, no un simple cambio de configuración.

La cuestión de la entidad operativa separa el marketing de la esencia

Más allá de la arquitectura técnica, existe una decisión de carácter organizativo que suele ser aún más decisiva: ¿quién es la entidad que realmente se encarga de la gestión operativa para los clientes con cuestiones de soberanía y qué grado de capacidad operativa tiene dicha entidad?

Antes de que esta cuestión cobre importancia, hay que responder a otra pregunta: ¿la jurisdicción de la empresa matriz del proveedor cumple con los requisitos mínimos legales del cliente? La evaluación de la soberanía la lleva a cabo alguna autoridad, una oficina de contratación pública, un organismo regulador o un consejo de administración, cuya jurisdicción define lo que se considera exposición jurídica extranjera. La prueba de la entidad operativa resulta más útil para aquellos proveedores cuya jurisdicción matriz sea aceptable para el marco normativo del cliente. Cuando la jurisdicción de la empresa matriz genera un riesgo jurídico que es extranjero para el cliente (el ejemplo más comentado es el de los proveedores con sede en EE. UU. que venden en contratos públicos de la UE, pero la misma lógica se aplica de forma simétrica en sentido contrario para cualquier contratación transfronteriza), la cuestión de la entidad operativa se plantea tras haber incumplido ya un umbral mínimo. La sustancia operativa no modifica el riesgo jurídico derivado de la jurisdicción extranjera que la empresa matriz conserva en virtud de su constitución.

La entidad operativa suele revelar si la soberanía existe en la práctica o solo sobre el papel. Una práctica habitual es que un proveedor con sede en una jurisdicción establezca una filial en una jurisdicción en la que la soberanía sea un factor sensible (normalmente la UE, aunque cada vez más otras regiones). La filial se presenta como el punto de referencia soberano local. Los clientes firman contratos con la filial. La filial es titular de las certificaciones locales. La filial aparece mencionada en los materiales de marketing.

La pregunta que distingue el fondo de la apariencia es: ¿a qué se dedica realmente la filial?

Las filiales con estructura mínima existen principalmente para la contratación y el cumplimiento normativo. Cuentan con una plantilla reducida, dedicada en su mayoría a funciones comerciales y de gestión de cuentas. La ingeniería se lleva a cabo en la empresa matriz. La construcción de la infraestructura se realiza en la jurisdicción de la empresa matriz. Las actualizaciones de software proceden de los canales gestionados por la empresa matriz. La filial firma el contrato. La empresa matriz gestiona el servicio. Si la empresa matriz no estuviera disponible, la filial no podría seguir operando. La filial es una estructura jurídica, no una entidad operativa.

Las filiales con gran peso operativo tienen una importancia significativa en el funcionamiento. Cuentan con personal de ingeniería que contribuye al código fuente que se entrega a los clientes locales. Gestionan la infraestructura de compilación en la jurisdicción local, con controles locales. Controlan los canales de implementación y actualización para las implementaciones de variantes locales. Cuentan con la capacidad técnica y contractual necesaria para seguir prestando el servicio a los clientes locales en caso de que la empresa matriz no estuviera disponible. La filial no se limita a subcontratar; lleva a cabo las operaciones.

Esta distinción apenas se aprecia en el ámbito del marketing. Ambos tipos de filiales se describen a sí mismas de la misma manera. La distinción se hace patente en cuestiones operativas: dónde trabajan los ingenieros, por dónde discurre el proceso de compilación, cuál es la fuente de información fiable para las actualizaciones que se envían a los clientes del sector público y qué pasaría si la empresa matriz dejara de estar disponible.

Para los clientes que se toman en serio la soberanía, estas son las preguntas que distinguen a un proveedor con una entidad operativa verdaderamente soberana de uno que solo tiene una fachada con estructura corporativa. Y esto no se consigue de la noche a la mañana. Crear una filial con solidez real requiere años de inversión en capacidad de ingeniería, infraestructura de fabricación, procesos de certificación y autonomía operativa. Un proveedor que no haya realizado esa inversión para cuando la soberanía se convierta en un criterio de contratación no podrá fabricarla según las condiciones del contrato.

El alcance de la certificación como prueba de la integridad operativa

A menudo se habla de las certificaciones en términos de marketing como una lista de logotipos que dan a entender legitimidad. La cuestión importante no es cuántas certificaciones tiene un proveedor, sino qué es lo que esas certificaciones validan realmente.

Las certificaciones de validación de operaciones constituyen la categoría más interesante para la evaluación de la soberanía. Entre ellas se incluyen las siguientes.

Certificaciones que avalan la integridad operativa en entornos clasificados. Cuando una autoridad de seguridad nacional acredita un sistema para su uso clasificado, la acreditación se extiende al contenido operativo, no solo al diseño arquitectónico. Abarca el sistema tal y como está implementado, con sus procedimientos operativos, su modelo de actualización, sus controles de acceso y su cadena de suministro operativa. La acreditación «Restringida» de la OTAN, las directrices de la NSA sobre «Soluciones comerciales para información clasificada», las certificaciones del BSI a nivel federal y las acreditaciones equivalentes de los aliados tienen este peso.

Certificaciones que avalan la continuidad de las operaciones. Los marcos de supervisión continua, como FedRAMP Clase D (Alta), exigen pruebas continuas de la seguridad operativa, no una evaluación puntual. La norma SOC 2 Tipo 2 certifica que los controles funcionan de manera eficaz durante un periodo de evaluación, no solo que existen sobre el papel. La norma ISO 22301 certifica específicamente las operaciones de continuidad del negocio.

Certificaciones que avalan la seguridad criptográfica y de la plataforma. La evaluación según los Criterios Comunes en niveles de garantía de evaluación más altos valida las declaraciones de seguridad criptográfica y de la plataforma de un producto mediante pruebas realizadas por laboratorios independientes.

El número de certificaciones que posee un proveedor es menos relevante que la cuestión de qué certificaciones tiene y qué acredita cada una de ellas. Un proveedor con una larga lista de certificaciones exclusivamente relacionadas con la arquitectura es estructuralmente diferente de un proveedor con una lista más reducida de certificaciones que acreditan operaciones en múltiples jurisdicciones.

El modelo más relevante en materia de soberanía es la certificación operativa multijurisdiccional: certificaciones de varios gobiernos aliados que validan operaciones en despliegues clasificados o sensibles, mantenidas simultáneamente en una plataforma integrada. Este modelo es poco frecuente y difícil de alcanzar. Requiere una colaboración operativa continua con múltiples autoridades de seguridad nacional, cada una con sus propios procesos de evaluación, modelos de amenaza y normas operativas. Un proveedor que cuente con acreditación operativa a nivel de la OTAN, certificación de grado clasificado de EE. UU. y certificaciones federales de gobiernos aliados en una misma plataforma de producto ha demostrado su integridad operativa de una forma que ninguna certificación por sí sola podría lograr.

Una cartera de certificaciones de este tipo rara vez surge por casualidad. Es el reflejo de años de colaboración con clientes del ámbito de la seguridad nacional, de repetidos ciclos de evaluación y de una arquitectura lo suficientemente estable como para satisfacer simultáneamente a múltiples autoridades.

La transparencia de la cadena de suministro como propiedad estructural

El objetivo de soberanía con mayor peso en los marcos normativos actuales es la cadena de suministro. La razón es que la cadena de suministro constituye la prueba más duradera de la soberanía. El estatuto jurídico puede modificarse mediante un tratado. La presencia operativa puede trasladarse. Las declaraciones de marketing pueden actualizarse. Sin embargo, el lugar desde donde se diseña, se desarrolla y se distribuye el software es más difícil de modificar.

El modelo arquitectónico que sustenta la soberanía de la cadena de suministro es la transparencia estructurada. En concreto:

Crear la infraestructura en la jurisdicción pertinente para el cliente. En el caso de implementaciones para un cliente con requisitos de soberanía, el proceso de compilación que genera el software que se ejecuta en el entorno de dicho cliente debe ejecutarse en una infraestructura adecuada a la jurisdicción correspondiente. Se trata de una cuestión independiente de la jurisdicción de la sede central, que es un requisito mínimo legal que se aborda en otra parte de cualquier evaluación rigurosa. La cuestión del proceso de compilación se refiere a dónde se producen y firman los artefactos de compilación, quién tiene acceso a dicho proceso y qué protección jurisdiccional se aplica a los propios artefactos. Ambas cuestiones son imprescindibles. Un proveedor que cumpla una sin la otra ofrece una respuesta parcial.

Soberanía de hardware para anclajes criptográficos. Los HSM (módulos de seguridad de hardware) que sirven de base a la infraestructura criptográfica de las implementaciones en las que la soberanía es un factor crítico deben proceder de proveedores cuya propia jurisdicción respalde los requisitos de soberanía del cliente. Los HSM sujetos a la jurisdicción de la UE (Thales en Francia, Utimaco en Alemania y similares) son estructuralmente diferentes de los HSM sujetos a jurisdicciones no pertenecientes a la UE, incluso cuando las especificaciones técnicas sean equivalentes.

Depósito del código fuente y acceso para auditorías. Los clientes con implementaciones de nivel clasificado suelen exigir la posibilidad de inspeccionar o depositar el código fuente como condición para establecer la confianza. Un proveedor cuya arquitectura admita el depósito del código fuente en el marco de programas gubernamentales para clientes certificados ofrece al cliente la opción de una verificación independiente. Un proveedor cuya arquitectura no admita esto —normalmente porque el código está demasiado integrado con una infraestructura de nube propietaria como para poder depositarlo de forma significativa— limita las opciones del cliente.

Cumplimiento de OpenChain o de un estándar equivalente en materia de cadena de suministro. El cumplimiento de OpenChain (ISO/IEC 5230) es un marco estructurado para la transparencia de la cadena de suministro de software. Los proveedores que cumplen con OpenChain han demostrado, mediante una auditoría externa, que sus prácticas en la cadena de suministro cumplen con una norma definida. Esto constituye una prueba estructural de la disciplina en la cadena de suministro.

Estos patrones son de carácter arquitectónico, no contractual. Un proveedor o bien ha diseñado su cadena de suministro de forma que sea susceptible de inspección, o bien no lo ha hecho. Si lo ha hecho, los clientes para los que la soberanía es un aspecto sensible pueden colaborar con él. Si no lo ha hecho, ningún contrato puede garantizar una transparencia en la cadena de suministro que no exista en la arquitectura.

La cuestión de la salida de los proveedores que pocos abordan

Los debates sobre la soberanía suelen centrarse en el punto de entrada de una relación con un proveedor: cómo se selecciona al proveedor, cómo se evalúa su postura en materia de soberanía y qué medidas de protección se establecen en el momento de la firma. El punto de salida rara vez se aborda con el mismo rigor, pero es estructuralmente igual de importante para la soberanía a largo plazo del cliente.

Las cuestiones arquitectónicas que determinan el coste de salida son las siguientes.

¿Los protocolos son abiertos o propietarios? Un proveedor que utilice protocolos abiertos basados en estándares ha facilitado estructuralmente al cliente la migración a otro proveedor que admita los mismos estándares. Un proveedor que utilice protocolos propios ha atado estructuralmente al cliente en la medida en que dichos protocolos estén integrados en las operaciones de este.

¿Son portables los formatos de datos? Los datos de los clientes almacenados en formatos propios de los proveedores, sin una ruta de exportación documentada ni un equivalente estándar, resultan inaccesibles en la práctica. Los datos de los clientes almacenados en formatos abiertos, o con rutas de exportación documentadas, son portables.

¿Son sustituibles las integraciones? Un proveedor cuyo valor para el cliente dependa de integraciones estrechamente vinculadas con otros productos del propio proveedor ha creado, de forma estructural, un coste de cambio que aumenta con el tiempo a medida que se añaden más integraciones. Un proveedor cuyo producto sea interoperable con alternativas de terceros no lo ha hecho.

¿Es posible extraer la arquitectura? En las implementaciones en las que más se valora la soberanía, los clientes pueden necesitar la capacidad de extraer todo el sistema —software, datos, configuraciones y procedimientos operativos— y seguir gestionándolo de forma independiente. Los proveedores cuya arquitectura permite esto (mediante acuerdos de licencia, cesión del código fuente o arquitecturas abiertas) ofrecen al cliente una verdadera soberanía de salida. Los proveedores cuya arquitectura no permite esto conservan, de forma estructural, la autoridad sobre la continuidad de las operaciones del cliente.

Un proveedor que haya optimizado su modelo de negocio para garantizar la soberanía del cliente concibe la salida como una opción de primer orden. Un proveedor cuyo modelo de negocio se base en la dependencia del cliente no lo hace. La soberanía a largo plazo del cliente depende del tipo de proveedor con el que haya contratado sus servicios.

El patrón estructural, en resumen

Los clientes que llevan más tiempo adquiriendo sistemas de nivel de soberanía —agencias de seguridad nacional, ministerios de defensa y operadores de comunicaciones clasificadas— han ido definiendo, con el paso del tiempo, un patrón estructural que determina cómo se plasma la soberanía real en la arquitectura. El patrón parte de un «umbral jurisdiccional» y se desarrolla a partir de ahí. La cuestión del «umbral jurídico» plantea si la jurisdicción de origen del proveedor genera una exposición a obligaciones legales ajenas a la propia jurisdicción del cliente. Si es así, los puntos fuertes arquitectónicos que se describen a continuación quedan subordinados a un umbral que ya no se cumple según la evaluación específica de ese cliente. Dentro de ese umbral, el modelo incluye:

• Claves criptográficas en poder del cliente según la arquitectura, no según lo prometido

• Topología de implementación multimodal que incluye opciones locales y con aislamiento físico

• Entidades operativas en jurisdicciones relevantes para los clientes que cuentan con una verdadera presencia en materia de ingeniería y operaciones

• Certificaciones operativas multijurisdiccionales que avalan el sistema en fase de implantación

• Cadenas de suministro verificables con transparencia en el proceso de compilación, soberanía sobre el hardware para los anclajes criptográficos, disposiciones sobre el código fuente y marcos de cumplimiento de la cadena de suministro

• Protocolos abiertos y formatos de datos portables que preservan la soberanía de los clientes a la hora de cambiar de proveedor

Los proveedores que cumplen con los requisitos legales mínimos del cliente y han diseñado sus productos en torno a este modelo pueden hacer de la soberanía una realidad operativa. Los proveedores que no cumplen los requisitos legales mínimos no pueden garantizar la soberanía a ese cliente, independientemente de la solidez arquitectónica en las demás dimensiones, ya que dichos requisitos se sitúan por encima de la capa arquitectónica. Los proveedores que cumplen los requisitos legales mínimos pero han diseñado sus productos en torno a modelos alternativos —como claves en poder del proveedor, implementación exclusivamente como SaaS, filiales locales sin sustancia real, certificaciones limitadas a una sola jurisdicción, cadenas de suministro opacas y dependencia de soluciones propietarias— tampoco pueden garantizar la soberanía como una realidad operativa, por mucho que la promocionen en su estrategia de marketing.

Las decisiones arquitectónicas se tomaron hace años. El debate sobre la soberanía que ahora se está introduciendo en el ámbito de la contratación pública está, en efecto, sacando a la luz tanto las posiciones jurisdiccionales de los proveedores como las decisiones arquitectónicas que tomaron mucho antes de que el término «soberanía» formara parte del vocabulario de la contratación pública. Los clientes que se toman en serio la soberanía cada vez más van más allá del discurso comercial y plantean las preguntas estructurales de forma secuencial: ¿cuál es la jurisdicción matriz con respecto a la nuestra?, ¿quién tiene las claves?, ¿dónde puede ejecutarse el sistema?, ¿quién gestiona realmente la entidad local?, ¿qué valida cada certificación?, ¿dónde se encuentra el proceso de desarrollo? y ¿podemos retirarnos?

Los clientes que se toman en serio la soberanía plantean cada vez más una serie de preguntas diferentes: ¿quién tiene las claves?, ¿dónde puede ejecutarse el sistema?, ¿quién lo gestiona realmente?, ¿qué validan las certificaciones?, ¿dónde se encuentra el proceso de compilación? y ¿podemos abandonarlo? Las respuestas revelan mucho más que cualquier afirmación sobre soberanía que aparezca en una página web.

Relacionado:
La soberanía recibe una puntuación: qué es SEAL y por qué es importante más allá de la nube
La soberanía deja de ser opcional: cómo deben plantearse el control los gobiernos y las empresas