Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Preparación de estrategias para la expansión global
Encuesta
Nos encantaría saber su opinión. Responda a una breve encuesta
Con frecuencia, el equipo de AWS Security Assurance Services
Las siguientes preguntas son habituales y solo usted puede responderlas para su caso de uso:
-
¿Dónde deben residir los datos personales de mis clientes?
-
¿Dónde se almacenan los datos de mis clientes?
-
¿Cómo y dónde pueden cruzar fronteras los datos personales?
-
¿El acceso humano o de los servicios a los datos entre regiones se considera una transferencia?
-
¿Cómo puedo estar seguro de que ningún gobierno extranjero pueda acceder a los datos personales de mis clientes?
-
¿Dónde puedo almacenar mis copias de seguridad y los sitios activos o inactivos?
-
Para mantener los datos locales, ¿debo mantener una zona de aterrizaje de AWS en cada región en la que preste servicios? ¿O puedo usar una zona de aterrizaje de AWS Control Tower existente?
En cuanto a los requisitos de residencia de datos, las diferentes implementaciones de arquitectura podrían funcionar mejor para diferentes organizaciones. Es posible que algunas organizaciones exijan que los datos personales de los clientes permanezcan en una región específica. Si es así, es posible que quiera saber cómo cumplir con las normativas en general y, al mismo tiempo, cumplir estas obligaciones. Independientemente de la situación, hay varias consideraciones que debe tener en cuenta a la hora de elegir una estrategia para implementar varias cuentas.
Para definir los componentes clave del diseño de la arquitectura, trabaje en estrecha colaboración con los equipos de cumplimiento y contratación para confirmar los requisitos sobre dónde, cuándo y cómo pueden cruzar las Regiones de AWS los datos personales. Determine qué se considera una transferencia de datos: moverlos, copiarlos o verlos. Además, comprenda si hay controles específicos de resiliencia y protección de datos que deban implementarse. ¿Las estrategias de copia de seguridad y recuperación ante desastres requieren una conmutación por error entre regiones? En caso afirmativo, averigüe qué regiones puede usar para almacenar sus datos de copia de seguridad. Determine si hay algún requisito para el cifrado de datos, como un algoritmo de cifrado específico o módulos de seguridad de hardware específicos para la generación de claves. Tras contactar con las partes interesadas en materia de cumplimiento en relación con estos temas, comience a valorar enfoques de diseño para su entorno de varias cuentas.
Los siguientes son tres enfoques que puede utilizar para planificar su estrategia de varias cuentas de AWS, en orden ascendente según la división de la infraestructura:
También debe recordar que el cumplimiento de la privacidad posiblemente no se limite únicamente a la soberanía de datos. Consulte el resto de esta guía para entender las posibles soluciones a muchos otros desafíos, como la administración del consentimiento, las solicitudes de los titulares de datos, la gobernanza de datos y los sesgos de la IA.
Zona de aterrizaje central con regiones administradas
Si desea expandirse a nivel mundial, pero ya ha establecido una arquitectura de varias cuentas en AWS, es habitual que quiera usar la misma zona de aterrizaje de varias cuentas (MALZ) para administrar más Regiones de AWS. En esta configuración, seguiría administrando los servicios de infraestructura como la creación de registros, el generador de cuentas y la administración general desde su zona de aterrizaje de AWS Control Tower actual, en la región en la que la creó.
Para las cargas de trabajo de producción, puede realizar implementaciones regionales si amplía la zona de aterrizaje de AWS Control Tower a una nueva región. De este modo, puede ampliar la gobernanza de AWS Control Tower a la nueva región. De esta forma, puede mantener los almacenes de datos personales en una región administrada específica; los datos seguirán en las cuentas que se beneficien de los servicios de infraestructura y la gobernanza de AWS Control Tower. En AWS Organizations, las cuentas que contienen datos personales se siguen agrupando en una UO de datos personales dedicada, en la que se han implementado todas las barreras de protección de soberanía de datos de AWS Control Tower. Además, las cargas de trabajo específicas de cada región se encuentran en cuentas dedicadas, en lugar de establecer cuentas de producción que pueden contener la misma carga de trabajo en varias regiones.
Esta implementación puede resultar la más rentable, pero debe tener en cuenta más aspectos para controlar el flujo de datos personales a través de las Cuenta de AWS y las fronteras regionales. Considere lo siguiente:
-
Los registros pueden contener datos personales, por lo que tal vez necesite alguna configuración adicional para contener o suprimir los campos confidenciales a fin de evitar la transferencia entre regiones durante la agrupación. Para obtener más información y las prácticas recomendadas para controlar la agrupación de registros entre regiones, consulte Almacenamiento de registros centralizado en esta guía.
-
En el diseño de AWS Transit Gateway, tenga en cuenta el aislamiento de las VPC y el flujo de tráfico de red bidireccional adecuado. Puede limitar qué conexiones de puerta de enlace de tránsito están permitidas y aprobadas, y puede limitar quién o qué puede cambiar las tablas de enrutamiento de la VPC.
-
Es posible que tenga que impedir que los miembros del equipo de operaciones en la nube accedan a datos personales. Por ejemplo, los registros de aplicaciones que contengan datos de transacciones de clientes pueden considerarse de mayor confidencialidad que otros orígenes del registro. Es posible que necesite más aprobaciones y barreras de protección técnicas, como el control de acceso basado en roles y el control de acceso basado en atributos. Además, los datos pueden estar sujetos a limitaciones de residencia en lo que respecta al acceso. Por ejemplo, solo se puede acceder a los datos de una región A desde esa región.
En el siguiente diagrama se muestra una zona de aterrizaje centralizada con implementaciones regionales.
Zonas de aterrizaje regionales
Tener más de una MALZ puede ayudarlo a cumplir los requisitos de cumplimiento más estrictos al aislar completamente las cargas de trabajo que procesan datos personales en comparación con las cargas de trabajo no materiales. La agrupación de registros centralizada de AWS Control Tower se podría configurar de forma predeterminada y, por lo tanto, se simplificaría. Con este enfoque, no es necesario que mantenga excepciones para el registro con flujos de registros separados que se tengan que suprimir. Incluso puede tener un equipo de operaciones en la nube local y dedicado para cada MALZ, lo que limita el acceso de los operadores a la residencia local.
Muchas organizaciones tienen implementaciones separadas en las zonas de aterrizaje de EE. UU. y la UE. Cada zona de aterrizaje regional tiene una postura de seguridad única y general y una gobernanza asociada para las cuentas de la región. Por ejemplo, el cifrado de datos personales mediante HSM dedicados puede no ser necesario en las cargas de trabajo de una MALZ, pero puede que sí lo sea en otra MALZ.
Si bien esta estrategia puede escalarse para cumplir con muchos requisitos actuales y futuros, es importante que comprenda los costos adicionales y los gastos operativos asociados al mantenimiento de varias MALZ. Para más información, consulte Precios de AWS Control Tower
En el siguiente diagrama se muestran zonas de aterrizaje separadas en dos regiones.
AWS European Sovereign Cloud
Algunas organizaciones necesitan una separación completa para las cargas de trabajo que operan en el Espacio Económico Europeo (EEE) y las cargas de trabajo que operan en otros lugares. En esta situación, considere la posibilidad de usar AWS European Sovereign Cloud
AWS European Sovereign Cloud está separada física y lógicamente de las Regiones de AWS existentes y, al mismo tiempo, ofrece la misma seguridad, disponibilidad y rendimiento. Solo los empleados de AWS que se encuentran en la UE tienen el control de las operaciones y la asistencia de AWS European Sovereign Cloud. Si su requisitos de residencia de datos son estrictos, AWS European Sovereign Cloud conserva todos los metadatos que cree (como los roles, los permisos, las etiquetas de los recursos y las configuraciones que se utilizan para ejecutar AWS) en la UE. AWS European Sovereign Cloud también cuenta con sus propios sistemas de facturación y medición del uso.
Para este enfoque, utilizaría un patrón similar al de la sección anterior, las zonas de aterrizaje regionales. Sin embargo, para los servicios que presta a clientes europeos, puede implementar una MALZ dedicada en AWS European Sovereign Cloud.
