La residencia de datos indica d\u00f3nde se alojan sus datos. La soberan\u00eda de datos\nindica qui\u00e9n puede ser obligado a entregarlos. El debate sobre soberan\u00eda\ndigital suele quedarse en la ubicaci\u00f3n del centro de datos, y muchos\ncuestionarios de proveedores comprueban lo primero y dan por supuesto lo\nsegundo. En ese hueco es donde un despliegue aparentemente conforme falla\nsin que nadie lo advierta.
\nUna implementaci\u00f3n que parece cumplir con los requisitos falla sin que nadie se d\u00e9 cuenta.<\/p>\n
El mecanismo en cuesti\u00f3n es la CLOUD Act estadounidense. Un proveedor sujeto a la jurisdicci\u00f3n de\nEstados Unidos puede verse obligado a entregar los datos que est\u00e9n en su posesi\u00f3n, custodia o control\nante un requerimiento legal estadounidense, aunque esos datos se almacenen fuera del pa\u00eds. La\nobligaci\u00f3n recae sobre el proveedor, no depende de d\u00f3nde est\u00e9 el servidor. Ya desarrollamos en otro\nart\u00edculo el argumento completo de soberan\u00eda para el sector p\u00fablico, y se aplica igual a un banco, una\naseguradora, un hospital o un despacho de abogados.<\/p>\n
Lo f\u00e1cil es ver la diferencia. Determinar si un proveedor concreto de su lista de preseleccionados supera\nrealmente esa prueba es m\u00e1s dif\u00edcil, porque el proveedor, su matriz, su proveedor de nube, su socio de\nalojamiento y su proveedor de soporte pueden estar sujetos cada uno a una jurisdicci\u00f3n distinta. Estas\ncinco preguntas permiten comprobarlo. Incl\u00fayalas por escrito en la solicitud de propuestas (RFP) y trate\nuna respuesta vaga o parcial como un hallazgo, no como un tr\u00e1mite.<\/p>\n
La ubicaci\u00f3n de la sede no es una respuesta jurisdiccional. Pida el nombre de la entidad contratante, el de\nsu sociedad matriz \u00faltima y el de cualquier filial que almacene, procese o pueda acceder a los datos del\ncliente, junto con el pa\u00eds de constituci\u00f3n de cada una. Un proveedor con sede fuera de Estados Unidos\npuede seguir sujeto a un requerimiento de entrega de datos si una sociedad matriz o filial estadounidense\nposee o controla los datos. Pida a cada proveedor de su lista de preseleccionados que declare su posici\u00f3n\njurisdiccional a nivel de entidad, no solo de marca. La entidad de Inuvika que firma el contrato est\u00e1\nestablecida en Canad\u00e1 o en el Reino Unido, y no est\u00e1 sujeta a la jurisdicci\u00f3n estadounidense. Ese es el\nnivel de claridad, entidad por entidad, que debe ofrecer la respuesta.<\/p>\n
C\u00f3mo es una mala respuesta<\/strong>: una direcci\u00f3n comercial, el nombre de un pa\u00eds sin una entidad detr\u00e1s, o el silencio sobre la sociedad matriz.<\/em><\/p>\n Esta es la pregunta que detecta un riesgo que la primera pasa por alto. El proveedor de software es solo un eslab\u00f3n. El proveedor de nube, el socio de alojamiento, el proveedor de servicios gestionados y\ncualquier subcontratista de soporte se rigen cada uno por su propia jurisdicci\u00f3n, y cada uno puede tener posesi\u00f3n, custodia o control de datos que podr\u00edan tener que entregarse. Un despliegue en un hyperscaler estadounidense, o un soporte prestado a trav\u00e9s de un proveedor estadounidense, puede reintroducir la exposici\u00f3n que la situaci\u00f3n jurisdiccional del proveedor parec\u00eda haber evitado. Si esa parte tiene posesi\u00f3n, custodia o control de datos relevantes, hay riesgo. Un proveedor puede estar completamente fuera de la jurisdicci\u00f3n estadounidense y aun as\u00ed prestar su servicio a trav\u00e9s de partes que no lo est\u00e1n.<\/p>\n Identifique cada parte de la cadena y la jurisdicci\u00f3n que rige a cada una. Como Inuvika OVD Enterprise es\nagn\u00f3stico 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\u00eddica de una \u00fanica nube global.<\/p>\n C\u00f3mo es una mala respuesta<\/strong>: una respuesta que solo cubre la entidad del propio proveedor, o una regi\u00f3n de nube presentada como si la regi\u00f3n fuera la jurisdicci\u00f3n.<\/em><\/p>\n \u00abDatos del cliente\u00bb no son solo documentos. Para cada parte de la cadena, pregunte a qu\u00e9 contenidos,\nregistros, copias de seguridad, datos de telemetr\u00eda y archivos de soporte puede acceder, y pregunte qui\u00e9n\ncustodia las claves de cifrado. La custodia de claves es una cuesti\u00f3n de jurisdicci\u00f3n, no solo de seguridad.\nQuien posee las claves puede estar en condiciones de entregar datos legibles. En despliegues on-\npremises, OVD Enterprise no recopila datos del cliente (m\u00e1s all\u00e1 de la fecha de vencimiento de la\nsuscripci\u00f3n y los datos agregados de uso, facilitados de forma voluntaria). Esto reduce considerablemente\nlo que podr\u00edamos llegar a tener que entregar. OVD Enterprise tambi\u00e9n puede utilizarse en un entorno\ntotalmente aislado (\u00abair-gapped\u00bb). Cuando el cliente opta por un servicio gestionado, lo prestamos a\ntrav\u00e9s de socios de alojamiento locales e independientes, en su pa\u00eds, y no de un \u00fanico operador global.<\/p>\n C\u00f3mo es una mala respuesta<\/strong>: \u00ablos datos est\u00e1n cifrados\u00bb, sin decir qui\u00e9n custodia las claves, o un alcance limitado a documentos que no menciona registros, copias de seguridad ni telemetr\u00eda.<\/em><\/p>\n Ni siquiera una instalaci\u00f3n on-premises queda sellada autom\u00e1ticamente. Pregunte qu\u00e9 datos salen del entorno para actualizaciones, diagn\u00f3sticos y soporte, y si las sesiones de soporte remoto crean accesos temporales a informaci\u00f3n del cliente. Estos son los canales que pueden reintroducir una exposici\u00f3n que una revisi\u00f3n de residencia haya dado por cerrada. Confirme qu\u00e9 se transmite, si se trata de metadatos operativos o contenido del cliente, qui\u00e9n lo recibe y qu\u00e9 jurisdicci\u00f3n se aplica al destinatario.<\/p>\n C\u00f3mo es una mala respuesta<\/strong>: \u00abno sale nada del entorno\u00bb, afirmado sin una lista de lo que transmiten realmente los canales de licenciamiento, actualizaci\u00f3n y diagn\u00f3stico.<\/em><\/p>\n En \u00faltima instancia, la jurisdicci\u00f3n se refiere a lo que ocurre cuando se recibe realmente una solicitud. Pide a cada proveedor que te facilite su proceso documentado. \u00bfCuestiona o limita las solicitudes excesivamente amplias? \u00bfNotifica al cliente cuando la ley lo permite? \u00bfInforma 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\u00ed tienes un ejemplo de una b\u00fasqueda en Google.<\/a><\/p>\n C\u00f3mo es una mala respuesta<\/strong>: la garant\u00eda de que nunca se ha recibido ninguno, ofrecida en lugar de un proceso para los que lleguen en el futuro.<\/em><\/p>\n Es en las preguntas dos a cinco donde se vienen abajo muchas promesas de soberan\u00eda, y son las que un proveedor no puede responder con una sola l\u00ednea\nsobre su sede.<\/strong><\/p><\/blockquote>\n Para las organizaciones cuyas obligaciones de soberan\u00eda proh\u00edben quedar sujetas a una orden de entrega de datos emitida por una autoridad extranjera, la jurisdicci\u00f3n es un criterio eliminatorio: una soluci\u00f3n que no lo supera deber\u00eda descartarse antes de comparar funcionalidades y precio. Para las dem\u00e1s organizaciones sujetas a regulaci\u00f3n, entra en la matriz como un factor relevante de riesgo jur\u00eddico, 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\u00f3 de antemano.<\/p>\n Creamos OVD Enterprise para compradores que hacen estas preguntas. Vea c\u00f3mo OVD Enterprise est\u00e1 dise\u00f1ado para un despliegue soberano y seguro<\/a>, o solicite una prueba gratuita<\/a>.<\/p>\n \u00bfPuede un socio de alojamiento local reintroducir la exposici\u00f3n extranjera? \u00bfQu\u00e9 debe contener realmente el proceso de un proveedor ante un requerimiento gubernamental?<\/strong> \u00bfUn despliegue on-premises cierra la cuesti\u00f3n por s\u00ed solo?<\/strong> Residency is where your data sits. Sovereignty is who can be compelled to hand it over. Many vendor questionnaires test the first and assume the second, and the gap between […]<\/p>\n","protected":false},"author":532,"featured_media":37718,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"brizy-blank-template.php","format":"standard","meta":{"footnotes":"","_members_access_role":[],"_members_access_error":""},"categories":[141,380,358,367],"tags":[],"class_list":["post-37714","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-vmware-alternative","category-desktop-virtualization","category-linux-virtualization-software","category-virtual-desktop-solutions"],"blocksy_meta":[],"yoast_head":"\n2 \u00bfQui\u00e9n m\u00e1s en la cadena puede ser obligado a entregar los datos?<\/h5>\n
3. \u00bfA qu\u00e9 puede acceder cada parte y qui\u00e9n custodia las claves?<\/h5>\n
4. \u00bfQu\u00e9 datos salen del entorno durante el soporte remoto?<\/h5>\n
5. \u00bfC\u00f3mo gestiona el proveedor un requerimiento\ngubernamental?<\/h5>\n
D\u00f3nde encaja en su matriz de evaluaci\u00f3n<\/h3>\n
Preguntas frecuentes<\/h3>\n
\n<\/strong>S\u00ed, y es una de las formas m\u00e1s habituales en que una revisi\u00f3n de soberan\u00eda acaba fallando. Si el socio de\nalojamiento, su matriz o el proveedor de nube subyacente est\u00e1n sujetos a una jurisdicci\u00f3n extranjera y tienen posesi\u00f3n, custodia o control de datos relevantes, la exposici\u00f3n puede volver, con independencia de d\u00f3nde est\u00e9 constituido el proveedor y de d\u00f3nde residan f\u00edsicamente los datos. La prueba de jurisdicci\u00f3n debe aplicarse a\ntodas las partes de la cadena, no solo al nombre que figura en el contrato.<\/p>\n
\nComo m\u00ednimo: un proceso documentado para revisar la validez legal del requerimiento, el compromiso de\nimpugnar o acotar los requerimientos excesivos, la notificaci\u00f3n al cliente siempre que la ley lo permita, y\nalguna forma de informe de transparencia sobre el n\u00famero de requerimientos recibidos. P\u00eddalo por escrito. Un\nproveedor que no tenga ya ese proceso dif\u00edcilmente lograr\u00e1 crear uno cre\u00edble bajo la presi\u00f3n de una licitaci\u00f3n.<\/p>\n
\nNo autom\u00e1ticamente. El despliegue on-premises elimina una categor\u00eda importante de exposici\u00f3n, pero por s\u00ed\nsolo no cubre las comprobaciones de licencia, los canales de actualizaci\u00f3n y diagn\u00f3stico ni las sesiones de\nsoporte remoto, y cualquiera de estos mecanismos puede provocar la salida de informaci\u00f3n del entorno. Pida a\ncualquier proveedor que documente exactamente qu\u00e9 transmiten esos canales, a qui\u00e9n y qu\u00e9 jurisdicci\u00f3n se\naplica al destinatario. Esos canales siguen existiendo incluso en un despliegue on-premises, y por eso deben\nevaluarse por separado.<\/p>","protected":false},"excerpt":{"rendered":"