Aprovechando API Gateway para la Soberanía de Datos y el Cumplimiento Normativo

Ming Wen

Ming Wen

November 28, 2022

Technology

Antecedentes y Desafíos

Con la creciente popularidad de los teléfonos inteligentes, el IoT y las redes móviles de alta velocidad, se ha generado una gran cantidad de datos sensibles, como fotos, transacciones financieras, ubicaciones geográficas, secuenciación de ADN, registros médicos y ensayos clínicos. El análisis estadístico basado en estos datos sensibles puede retratar con precisión las identidades de individuos, empresas o grupos de personas, amenazando la privacidad personal y la seguridad nacional.

Cada vez más cuerpos legislativos de diferentes países son conscientes de la gravedad y urgencia de este problema. Han introducido muchas leyes y regulaciones para regular la recopilación de datos y su transferencia transfronteriza. El Reglamento General de Protección de Datos (GDPR) en Europa y la Ley de Portabilidad y Responsabilidad de Seguros de Salud (HIPAA) en EE. UU. son pioneras en este ámbito. Muchos países en desarrollo también están avanzando:

Por lo tanto, los datos generados por los terminales y usuarios, almacenados y mantenidos por los fabricantes, están supervisados por múltiples agencias de aplicación de la ley. Así, las empresas, especialmente las grandes multinacionales, se enfrentan a muchos problemas nuevos y urgentes:

- ¿Qué datos se pueden recopilar? ¿Cuáles no?

- ¿Cómo y dónde se almacenan los datos?

- ¿Se pueden transferir los datos a través de las fronteras?

Será un proyecto masivo clasificar y formular soluciones para todos ellos. Aquí nos centraremos principalmente en un problema:

Para los datos del cliente transmitidos a través de la API, ¿cómo determinar la soberanía de los datos a nivel de la puerta de enlace de la API para garantizar que los datos se procesen y almacenen de manera legal?

Por ejemplo, un usuario estadounidense en un viaje de negocios a Europa utiliza su teléfono móvil para realizar una transferencia bancaria. En este caso, los datos de la transacción deben ser procesados y almacenados por un servidor más lejano en los Estados Unidos, no por un servidor europeo más cercano.

En la segunda mitad de este artículo, daremos una solución técnica específica para este ejemplo. Antes de eso, veamos primero qué son la soberanía de los datos y el cumplimiento normativo.

¿Qué son la Soberanía de los Datos y el Cumplimiento Normativo?

Soberanía de los Datos

Un país no solo tiene soberanía sobre el espacio físico, como el territorio, el espacio aéreo y las aguas territoriales, sino también sobre sus datos y el ciberespacio nacional.

Tomemos como ejemplo el Reglamento General de Protección de Datos (GDPR), que es una regulación de la UE para la privacidad y protección de datos personales. Hay uno de los requisitos más básicos en el GDPR: "Todas las acciones de recopilación de datos de los usuarios requieren el consentimiento del usuario, y este tiene derecho a eliminar y borrar sus datos personales almacenados en cualquier momento."

Por lo tanto, si una empresa desea transferir datos europeos a otras regiones, debe asegurarse de que los requisitos de soberanía de datos del tercer país cumplan con los de la UE. En cuanto a la necesidad de que los datos cumplan con las leyes locales, existen muchas preocupaciones en los negocios multinacionales.

Otra preocupación es la Ley PATRIOTA de EE. UU., que exige que todos los datos almacenados en EE. UU., o los datos almacenados por empresas estadounidenses, estén bajo la supervisión de los Estados Unidos. El Departamento de Justicia de EE. UU. y la Agencia Central de Inteligencia (CIA) tienen el derecho de solicitar a las empresas que proporcionen datos. En 2013, el Departamento de Justicia de EE. UU. le pidió a Microsoft que revelara cierta información de correo electrónico almacenada en sus servidores de Irlanda. Microsoft rechazó la solicitud del Departamento de Justicia porque violaría los requisitos regulatorios de la Unión Europea. Luego, el Departamento de Justicia llevó a Microsoft a los tribunales, pero Microsoft ganó el caso. Posteriormente, para evitar riesgos de soberanía de datos, muchas empresas en los Estados Unidos ubicaron sus centros de datos directamente en Europa, pensando que esto sería seguro. Sin embargo, recientemente ha habido algunos casos en los que los jueces dictaminaron que EE. UU. tiene la autoridad para solicitar datos a empresas estadounidenses en Europa. Esto es la jurisdicción de largo alcance de los Estados Unidos.

La soberanía de los datos ha traído desafíos significativos a los negocios globales de las empresas, y cómo manejar adecuadamente el problema de la soberanía de los datos en las empresas se ha vuelto particularmente importante.

Cumplimiento Normativo de los Datos

Para las empresas multinacionales, la sincronización de datos es relativamente simple si no hay requisitos de soberanía de datos. Los datos de un usuario en los Estados Unidos pueden sincronizarse fácilmente con servidores en Asia y el Reino Unido, como se muestra en el siguiente diagrama. De esta manera, cuando un estadounidense viaja a Asia, también puede acceder a varios datos generados cuando estaba en los EE. UU.

Sincronización de datos entre IDCs

Con los requisitos de cumplimiento de la soberanía de los datos, muchos datos no pueden sincronizarse y accederse entre países. Las empresas necesitan distinguir a los usuarios y aislar sus datos asociados. Un método estándar es dividir a los usuarios según las regiones.

Tomemos como ejemplo el Kindle de Amazon: los libros electrónicos comprados por usuarios en los EE. UU. no se pueden descargar a su Kindle con una cuenta china. Esto se debe a que los datos entre diferentes países (regiones) están completamente aislados. La arquitectura del sistema es la siguiente:

Solo accede a tu propio IDC

Entonces, ¿qué se debe hacer técnicamente si un usuario en el Reino Unido quiere acceder a Amazon UK con una cuenta de EE. UU.? Veamos el diagrama de arquitectura a continuación. La mayoría de los productos existentes de puertas de enlace de API proponen soluciones similares.

Solución Existente a Nivel de Puerta de Enlace de API

Solución de puerta de enlace de API para el cumplimiento de datos

Podemos resumir el núcleo de esta solución en una frase:

La puerta de enlace de API en el Reino Unido identifica al usuario. Si la API descubre que el usuario está registrado en los EE. UU., se enrutará a los servidores de EE. UU. para su procesamiento.

Sin embargo, también hay algunos desafíos técnicos ocultos detrás de esto, así como riesgos de cumplimiento:

  1. La puerta de enlace de API necesita capacidades de programación de rutas de grano fino, obtiene datos del encabezado HTTP, los argumentos de la solicitud y el cuerpo de la solicitud, y coopera con consultas a bases de datos externas para determinar qué servidor manejará al usuario.

  2. La red entre las regiones debe estar conectada para reenviar la solicitud. La sala de servidores del Reino Unido y la sala de servidores de EE. UU. deben estar conectadas.

  3. La puerta de enlace de API en la sala de servidores del Reino Unido podría haber descargado el certificado SSL, leído el contenido de la API y registrado los datos en el disco local u otros servicios a través de registros de acceso, registros de auditoría, sistemas de observabilidad, etc.

¿Existe alguna forma de resolver estos problemas?

Red Multinivel: La Solución de Apache APISIX para Garantizar el Cumplimiento de la Transmisión de Datos de la API

Aquí presentamos el concepto de una "red multinivel" en APISIX para garantizar el cumplimiento y la seguridad de los datos transmitidos por la API a nivel de la puerta de enlace de la API. Una red multinivel, como su nombre lo indica, divide la puerta de enlace de la API en dos capas, Nivel 1 y Nivel 2, como se muestra en la siguiente figura:

Puerta de enlace de API con red multinivel para el cumplimiento de datos

  • Puerta de enlace de API de Nivel 1: responsable de la descarga del certificado SSL, la programación de rutas de grano fino y decidir qué puerta de enlace de API de Nivel 2 debe manejar las solicitudes de la API.
  • Puerta de enlace de API de Nivel 2: Esta es la puerta de enlace de API original, que no necesita preocuparse por el cumplimiento de los datos.

Volviendo a la pregunta al comienzo del artículo: ¿cómo puede un usuario registrado en los Estados Unidos garantizar el cumplimiento de los datos de la API independientemente de la ubicación de su transacción?

Primero, la solicitud de la API se enviará a la puerta de enlace de API de Nivel 1, que es esencialmente Apache APISIX pero agrega el objeto multi-layer network, en el cual se pueden vincular complementos personalizados:

  1. La puerta de enlace de API de Nivel 1 define la dirección, el peso y otra información de los clústeres de la puerta de enlace de API de Nivel 2. Aquí configuramos el clúster de EE. UU. y el clúster del Reino Unido:
http://Layer-1-API-Gateway-IP/apisix/admin/multilayer_network/clusters/cluster-US
{
  "desc": "description",
  "http_port": 80,
  "https_port": 443,
  "gateways": [
    {"host": "IP1", "weight": 1},
    {"host": "IP2", "weight": 2}
  ]
}

http://Layer-1-API-Gateway-IP/apisix/admin/multilayer_network/clusters/cluster-UK
{
  "desc": "description",
  "http_port": 80,
  "https_port": 443,
  "gateways": [
    {"host": "IP1", "weight": 1},
    {"host": "IP2", "weight": 2}
  ]
}
  1. Definir las reglas de enrutamiento en la red multinivel y vincular con el complemento bar:
http://Layer-1-API-Gateway-IP/apisix/admin/multilayer_network/routes/bank-foo
{
  "desc": "bank API",
  "hosts": ["foo.com"],
  "uris": ["/*"],
  "plugin_id": "bar"
}
  1. Definir complementos personalizados:
http://***/apisix/admin/multilayer_network/plugins/bar
{
  "desc": "plugin",
  "plugins": {
    "jwt-auth": {
      ... ...
    },
    "foo-upstream-selector": {
      "scheme": "HTTPS"
      ... ...
    },
    ... ...
  }
}

Aquí vinculamos dos complementos. El complemento jwt-auth se utiliza para completar la autenticación de la solicitud. El foo-upstream-selector se utiliza para leer información como el ID del usuario, el país/región y el clúster al que pertenece el usuario desde la base de datos y especifica a qué clúster de puerta de enlace de API de Nivel 2 se enruta.

Esta arquitectura multinivel garantiza el cumplimiento de los datos en diferentes países.

Conclusión

En resumen, la programación de rutas de grano fino habilitada por la arquitectura multinivel de la puerta de enlace de API puede ayudar a las empresas a procesar los datos de la API de manera rápida y segura, al mismo tiempo que garantiza los requisitos de cumplimiento de datos. Ofrecemos esta funcionalidad lista para usar en API7 Cloud y API7 Enterprise. Bienvenido a completar el formulario para contactarnos.

Tags:
API Gateway Concept
Data Management