Descripción general de la residencia de datos

Descripción general

En esta página, se explica cómo usar Cloud SQL para aplicar los requisitos de residencia de datos.

La residencia de datos hace referencia a la ubicación física de los datos y a las regulaciones locales que rigen la forma en que se almacenan, encriptan y se accede a ellos. A medida que evolucionan las protecciones de datos y las normas de privacidad de los países, es cada vez más importante que comprendas cómo cumplir con los requisitos de residencia de datos locales y proteger los datos de los usuarios.

En un entorno local tradicional, varios componentes se integran y manejan la residencia de los datos. Por ejemplo, una empresa puede alojar una puerta de enlace de asignación de token como un agente de seguridad para el acceso a la nube (CASB) para proteger los datos de la aplicación antes de que se transmitan al extranjero.

Google Cloud y sus servicios, incluido Cloud SQL, se integran para ayudarte a administrar la residencia de datos mediante el control de la ubicación de tus datos y el acceso a ellos, por parte de Google o de cualquier persona.

Residencia de datos en computación en la nube

A continuación, se enumeran algunos problemas de residencia de datos que debes conocer:

  • Si los administradores de la nube de una empresa no conocen la ubicación física de los datos, no conocen las regulaciones locales. A fin de poder investigar las políticas de residencia de datos para cada ubicación, los administradores deben saber dónde están los centros de datos.
  • Los administradores y proveedores de servicios en la nube de la empresa pueden usar Acuerdos de Nivel de Servicio (ANS) para establecer ubicaciones permitidas. Sin embargo, ¿qué sucede si tienes que almacenar tus datos en una región diferente a la de los términos del ANS?
  • Los usuarios deben asegurarse de que sus datos, y todos los servicios y recursos que usan en sus proyectos en la nube, cumplan con las regulaciones de residencia de datos del país host.
    • ¿Qué debes hacer si quieres decidir dónde almacenar tus datos y claves de encriptación?
    • ¿Qué sucede si deseas determinar en qué ubicaciones los usuarios pueden acceder a tus datos?

Los servicios de Google Cloud, incluido Cloud SQL, abordan algunos de estos problemas, ya que permiten hacer lo siguiente:

  • Configura la ubicación de almacenamiento de tus datos. Puedes seleccionar la región cuando creas tu instancia de Cloud SQL o puedes editar la región si editas una instancia existente.
  • Usa la función de réplica de lectura entre regiones para Cloud SQL a fin de asegurarte de que cumples con los estándares de residencia de datos de una región designada.
  • Controla las ubicaciones de la red desde las que los usuarios pueden acceder a los datos y el acceso de los administradores de la nube a estos datos.

Cloud SQL puede ayudarte a enfrentar los desafíos de la residencia de datos en tres áreas:

Almacene datos

La residencia de datos implica almacenar información de identificación personal (PII) dentro de una región en particular, donde esos datos se procesan de acuerdo con las regulaciones de esa región.

Para almacenar datos, debes cumplir con las demandas legales y reglamentarias de un país, como las leyes de localidad de datos. Por ejemplo, un país puede exigir que los datos relacionados con el Gobierno se almacenen en ese país. O una empresa puede estar obligada, por contrato, a almacenar datos de algunos de sus clientes en otro país. Por lo tanto, una empresa debe cumplir con los requisitos de residencia de datos del país en el que se almacenan los datos.

Con Google Cloud, puedes configurar dónde se almacenan tus datos, incluso en las copias de seguridad. Esto te permite elegir las regiones en las que almacenas tus datos. Cuando elijas configurar recursos para Cloud SQL en esas regiones, Google almacenará los datos en reposo solo en esas regiones, de conformidad con nuestras Condiciones específicas del servicio. Puedes seleccionar la región cuando creas tu instancia o puedes editar la región si editas una instancia existente.

Para obtener más información sobre las ubicaciones de las copias de seguridad, consulta Ubicaciones de copias de seguridad personalizadas.

Puedes usar restricciones de políticas de la organización para aplicar los requisitos de residencia de datos a nivel de la organización, el proyecto o la carpeta. Estas restricciones te permiten definir las ubicaciones de Google Cloud donde los usuarios pueden crear recursos para servicios compatibles. Para la residencia de datos, puedes limitar la ubicación física de un nuevo recurso con la restricción de ubicaciones de recursos. También puedes ajustar las políticas de una restricción para especificar multirregiones, como asia y europe, o regiones como us-east1 o europe-west1 como ubicaciones permitidas o denegadas.

Si hay una interrupción en una región de Google Cloud, puedes evitar el impacto mediante la función réplica de lectura entre regiones para Cloud SQL. Como parte de la creación de una réplica de lectura, debes elegir la región de la réplica. Asegúrate de elegir una región que cumpla con las regulaciones de residencia de datos. Como resultado, los estándares de residencia de datos se cumplen en la región seleccionada.

Cuando creas la réplica, creas una copia de tu instancia de base de datos principal que refleja los cambios de esta última casi en tiempo real. Si ocurre una falla, puedes ascender la réplica de lectura a una instancia principal.

Los Controles del servicio de VPC te ayudan a aplicar la residencia de los datos, ya que te permiten restringir el uso de las API de Cloud SQL para importar y exportar datos mediante la API de Administrador de Cloud SQL o la API de Cloud Storage. Esta restricción ayuda a garantizar que los datos permanezcan dentro de las ubicaciones de red que seleccionaste. Mediante los Controles del servicio de VPC, creas un perímetro de servicio que define los límites virtuales desde los que se puede acceder a un servicio, lo que evita que los datos se transfieran a esos límites. Puedes aplicar esta restricción incluso si el usuario está autorizado de acuerdo con tu política de IAM de Google Cloud.

Encripta datos

Los servicios de Google Cloud, incluido Cloud SQL, encriptan el contenido de los clientes en reposo y en tránsito mediante varios métodos de encriptación. La encriptación es automática y no requiere ninguna acción por parte de los clientes.

Cloud SQL también te permite agregar otra capa de encriptación a los datos mediante claves de encriptación administradas por el cliente (CMEK). Están diseñadas para organizaciones que tienen datos sensibles o regulados y, por lo tanto, necesitan administrar las claves de encriptación por su cuenta. La función CMEK te permite usar tus propias claves criptográficas para los datos en reposo en Cloud SQL. Después de agregar CMEK, Cloud SQL usa las claves para acceder a los datos cada vez que se realiza una llamada a la API.

Si deseas almacenar tu CMEK en las regiones en las que implementas tus servicios, puedes usar Cloud Key Management Service (Cloud KMS). Debes establecer la ubicación de la clave cuando la creas. También puedes usar Cloud HSM para almacenar esas claves dentro de un módulo de seguridad de hardware físico (HSM) ubicado en la región que elijas.

Otra forma de elegir dónde deseas almacenar tus CMEK es usar un producto de terceros. Para almacenar y administrar claves en un producto de administración de claves de terceros que se implementa fuera de la infraestructura de Google, puedes usar Cloud External Key Manager (Cloud EKM).

Accede a los datos

Con Cloud SQL, puedes controlar qué usuarios pueden acceder a tus datos.

La autenticación de bases de datos de Identity and Access Management (IAM) de Cloud SQL proporciona una interfaz única para ayudarte a supervisar y administrar mejor el acceso de los usuarios y las cuentas de servicio a las bases de datos. Como resultado, puedes administrar los datos en tus recursos de nube de forma centralizada.

Si configuras la autenticación de la base de datos de IAM de Cloud SQL, puedes controlar el acceso de los usuarios a tus datos en Cloud SQL si defines quién tiene qué tipo de acceso a tus datos. Configura la instancia de base de datos y, luego, otorga acceso a los usuarios. Para ello, agrega usuarios de IAM como usuarios en la instancia. Estos usuarios pueden acceder a las bases de datos de Cloud SQL mediante la autenticación de la base de datos de IAM de Cloud SQL.

A fin de habilitar o inhabilitar servicios para conjuntos de usuarios, puedes combinar restricciones de políticas de la organización mediante la configuración de la política de IAM. Esta función evita que tus empleados almacenen datos de forma accidental en la región incorrecta de Google Cloud.

Para controlar el acceso del personal de ingeniería y asistencia de Google, usa la aprobación de acceso. La aprobación de acceso te permite solicitar a los empleados de Google que obtengan tu aprobación explícita antes de que accedan a tus datos o configuraciones en Google Cloud (para conocer las exclusiones, consulta Exclusiones de la aprobación de acceso).

La aprobación de acceso complementa la visibilidad proporcionada por la Transparencia de acceso, que genera registros de auditoría casi en tiempo real cuando los administradores de Google interactúan con tus datos. Los registros de auditoría incluyen la ubicación de la oficina del administrador y el motivo del acceso. También puedes aplicar atributos específicos para los administradores que tienen acceso a tus datos o parámetros de configuración, incluida su región geográfica y otros atributos relevantes para el cumplimiento.

Key Access Justifications se integra en Cloud KMS y Cloud EKM. Cada vez que se solicita una de tus claves para encriptar o desencriptar datos, Key Access Justification proporciona una justificación detallada, junto con un mecanismo para que apruebes o rechaces el acceso a claves mediante una política automatizada que establezcas.

Mediante los permisos de IAM, la aprobación de acceso, la Transparencia de acceso y Key Access Justifications con Cloud KMS y Cloud EKM, puedes impedir que Google desencripte tus datos. Como resultado, eres el árbitro del acceso a tus datos.

¿Qué sigue?