La residencia de datos indica dónde se alojan sus datos. La soberanía de datos
indica quién puede ser obligado a entregarlos. El debate sobre soberanía
digital suele quedarse en la ubicación del centro de datos, y muchos
cuestionarios de proveedores comprueban lo primero y dan por supuesto lo
segundo. En ese hueco es donde un despliegue aparentemente conforme falla
sin que nadie lo advierta.
Una implementación que parece cumplir con los requisitos falla sin que nadie se dé cuenta.
El mecanismo en cuestión es la CLOUD Act estadounidense. Un proveedor sujeto a la jurisdicción de Estados Unidos puede verse obligado a entregar los datos que estén en su posesión, custodia o control ante un requerimiento legal estadounidense, aunque esos datos se almacenen fuera del país. La obligación recae sobre el proveedor, no depende de dónde esté el servidor. Ya desarrollamos en otro artículo el argumento completo de soberanía para el sector público, y se aplica igual a un banco, una aseguradora, un hospital o un despacho de abogados.
Lo fácil es ver la diferencia. Determinar si un proveedor concreto de su lista de preseleccionados supera realmente esa prueba es más difícil, porque el proveedor, su matriz, su proveedor de nube, su socio de alojamiento y su proveedor de soporte pueden estar sujetos cada uno a una jurisdicción distinta. Estas cinco preguntas permiten comprobarlo. Inclúyalas por escrito en la solicitud de propuestas (RFP) y trate una respuesta vaga o parcial como un hallazgo, no como un trámite.
Las cinco preguntas
1. ¿Qué entidades jurídicas intervienen realmente en la cadena?
La ubicación de la sede no es una respuesta jurisdiccional. Pida el nombre de la entidad contratante, el de su sociedad matriz última y el de cualquier filial que almacene, procese o pueda acceder a los datos del cliente, junto con el país de constitución de cada una. Un proveedor con sede fuera de Estados Unidos puede seguir sujeto a un requerimiento de entrega de datos si una sociedad matriz o filial estadounidense posee o controla los datos. Pida a cada proveedor de su lista de preseleccionados que declare su posición jurisdiccional a nivel de entidad, no solo de marca. La entidad de Inuvika que firma el contrato está establecida en Canadá o en el Reino Unido, y no está sujeta a la jurisdicción estadounidense. Ese es el nivel de claridad, entidad por entidad, que debe ofrecer la respuesta.
Cómo es una mala respuesta: una dirección comercial, el nombre de un país sin una entidad detrás, o el silencio sobre la sociedad matriz.
2 ¿Quién más en la cadena puede ser obligado a entregar los datos?
Esta es la pregunta que detecta un riesgo que la primera pasa por alto. El proveedor de software es solo un eslabón. El proveedor de nube, el socio de alojamiento, el proveedor de servicios gestionados y cualquier subcontratista de soporte se rigen cada uno por su propia jurisdicción, y cada uno puede tener posesión, custodia o control de datos que podrían tener que entregarse. Un despliegue en un hyperscaler estadounidense, o un soporte prestado a través de un proveedor estadounidense, puede reintroducir la exposición que la situación jurisdiccional del proveedor parecía haber evitado. Si esa parte tiene posesión, custodia o control de datos relevantes, hay riesgo. Un proveedor puede estar completamente fuera de la jurisdicción estadounidense y aun así prestar su servicio a través de partes que no lo están.
Identifique cada parte de la cadena y la jurisdicción que rige a cada una. Como Inuvika OVD Enterprise es agnóstico respecto al hipervisor y a la nube, usted puede mantener esa cadena en la infraestructura y con los socios que elija, en lugar de heredar la huella jurídica de una única nube global.
Cómo es una mala respuesta: una respuesta que solo cubre la entidad del propio proveedor, o una región de nube presentada como si la región fuera la jurisdicción.
3. ¿A qué puede acceder cada parte y quién custodia las claves?
«Datos del cliente» no son solo documentos. Para cada parte de la cadena, pregunte a qué contenidos, registros, copias de seguridad, datos de telemetría y archivos de soporte puede acceder, y pregunte quién custodia las claves de cifrado. La custodia de claves es una cuestión de jurisdicción, no solo de seguridad. Quien posee las claves puede estar en condiciones de entregar datos legibles. En despliegues on- premises, OVD Enterprise no recopila datos del cliente (más allá de la fecha de vencimiento de la suscripción y los datos agregados de uso, facilitados de forma voluntaria). Esto reduce considerablemente lo que podríamos llegar a tener que entregar. OVD Enterprise también puede utilizarse en un entorno totalmente aislado («air-gapped»). Cuando el cliente opta por un servicio gestionado, lo prestamos a través de socios de alojamiento locales e independientes, en su país, y no de un único operador global.
Cómo es una mala respuesta: «los datos están cifrados», sin decir quién custodia las claves, o un alcance limitado a documentos que no menciona registros, copias de seguridad ni telemetría.
4. ¿Qué datos salen del entorno durante el soporte remoto?
Ni siquiera una instalación on-premises queda sellada automáticamente. Pregunte qué datos salen del entorno para actualizaciones, diagnósticos y soporte, y si las sesiones de soporte remoto crean accesos temporales a información del cliente. Estos son los canales que pueden reintroducir una exposición que una revisión de residencia haya dado por cerrada. Confirme qué se transmite, si se trata de metadatos operativos o contenido del cliente, quién lo recibe y qué jurisdicción se aplica al destinatario.
Cómo es una mala respuesta: «no sale nada del entorno», afirmado sin una lista de lo que transmiten realmente los canales de licenciamiento, actualización y diagnóstico.
5. ¿Cómo gestiona el proveedor un requerimiento gubernamental?
En última instancia, la jurisdicción se refiere a lo que ocurre cuando se recibe realmente una solicitud. Pide a cada proveedor que te facilite su proceso documentado. ¿Cuestiona o limita las solicitudes excesivamente amplias? ¿Notifica al cliente cuando la ley lo permite? ¿Informa del volumen de solicitudes que recibe? Un proveedor que no cuente con un proceso documentado corre el riesgo de tener que improvisar con tus datos si se recibe una solicitud. Aquí tienes un ejemplo de una búsqueda en Google.
Cómo es una mala respuesta: la garantía de que nunca se ha recibido ninguno, ofrecida en lugar de un proceso para los que lleguen en el futuro.
Es en las preguntas dos a cinco donde se vienen abajo muchas promesas de soberanía, y son las que un proveedor no puede responder con una sola línea sobre su sede.
Dónde encaja en su matriz de evaluación
Para las organizaciones cuyas obligaciones de soberanía prohíben quedar sujetas a una orden de entrega de datos emitida por una autoridad extranjera, la jurisdicción es un criterio eliminatorio: una solución que no lo supera debería descartarse antes de comparar funcionalidades y precio. Para las demás organizaciones sujetas a regulación, entra en la matriz como un factor relevante de riesgo jurídico, ponderado frente a la sensibilidad de sus datos, lo que exija su regulador, su modelo de despliegue y lo que ya cubran sus contratos, en lugar de quedar relegado a las notas al pie. En cualquier caso, es un criterio que debe evaluarse expresamente, con preguntas que usted escribió de antemano.
Creamos OVD Enterprise para compradores que hacen estas preguntas. Vea cómo OVD Enterprise está diseñado para un despliegue soberano y seguro, o solicite una prueba gratuita.
Preguntas frecuentes
¿Puede un socio de alojamiento local reintroducir la exposición extranjera?
Sí, y es una de las formas más habituales en que una revisión de soberanía acaba fallando. Si el socio de
alojamiento, su matriz o el proveedor de nube subyacente están sujetos a una jurisdicción extranjera y tienen posesión, custodia o control de datos relevantes, la exposición puede volver, con independencia de dónde esté constituido el proveedor y de dónde residan físicamente los datos. La prueba de jurisdicción debe aplicarse a
todas las partes de la cadena, no solo al nombre que figura en el contrato.
¿Qué debe contener realmente el proceso de un proveedor ante un requerimiento gubernamental?
Como mínimo: un proceso documentado para revisar la validez legal del requerimiento, el compromiso de
impugnar o acotar los requerimientos excesivos, la notificación al cliente siempre que la ley lo permita, y
alguna forma de informe de transparencia sobre el número de requerimientos recibidos. Pídalo por escrito. Un
proveedor que no tenga ya ese proceso difícilmente logrará crear uno creíble bajo la presión de una licitación.
¿Un despliegue on-premises cierra la cuestión por sí solo?
No automáticamente. El despliegue on-premises elimina una categoría importante de exposición, pero por sí
solo no cubre las comprobaciones de licencia, los canales de actualización y diagnóstico ni las sesiones de
soporte remoto, y cualquiera de estos mecanismos puede provocar la salida de información del entorno. Pida a
cualquier proveedor que documente exactamente qué transmiten esos canales, a quién y qué jurisdicción se
aplica al destinatario. Esos canales siguen existiendo incluso en un despliegue on-premises, y por eso deben
evaluarse por separado.