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. Proporcione sus comentarios sobre la AWS PRA mediante una breve encuesta
AWS
A medida que se expande a nivel mundial, 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 AWS landing zone en cada región en la que ofrezco servicios? ¿O puedo usar una AWS Control Tower landing zone 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 quieres expandirte a nivel mundial pero ya has establecido una arquitectura multicuenta AWS, es habitual que desees utilizar la misma zona de landing multicuenta (MALZ) para gestionar más. Regiones de AWS En esta configuración, seguirías gestionando servicios de infraestructura como el registro, la fábrica de cuentas y la administración general desde tu AWS Control Tower landing zone actual, en la región en la que la creaste.
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 gestionada específica; los datos seguirán residiendo en cuentas que se benefician de los servicios de infraestructura y la AWS Control Tower gobernanza. En el caso de las cuentas que contienen datos personales AWS Organizations, se siguen agrupando en una unidad organizativa dedicada a los datos personales, en la que se AWS Control Tower implementan todas las barreras de soberanía de los datos. 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 ser la más rentable, pero es necesario tener más en cuenta para controlar el flujo de datos personales a través de las fronteras Cuenta de AWS 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 AWS Transit Gateway diseño, tenga en cuenta el aislamiento VPCs 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 un MALZ puede ayudarle a cumplir requisitos de conformidad más estrictos, ya que aísla completamente las cargas de trabajo que procesan datos personales en comparación con las cargas de trabajo no materiales. AWS Control Tower La agregación de registros centralizada podría configurarse de forma predeterminada y, por lo tanto, simplificarse. 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 los datos personales mediante una MALZ específica HSMs 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 ampliarse para cumplir con muchos requisitos actuales y futuros, es importante comprender los costos adicionales y los gastos operativos asociados con el mantenimiento de varios MALZs. Para obtener más información, consulte Precios de AWS Control Tower
En el siguiente diagrama se muestran zonas de aterrizaje separadas en dos regiones.
AWS Nube soberana europea
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
La nube soberana AWS europea está separada física y lógicamente de la existente y Regiones de AWS, al mismo tiempo, ofrece la misma seguridad, disponibilidad y rendimiento. Solo AWS los empleados que se encuentran en la UE tienen el control de las operaciones y el soporte de la nube soberana AWS europea. Si tiene requisitos estrictos de residencia de datos, la Nube Soberana AWS Europea conserva todos los metadatos que cree (como las funciones, los permisos, las etiquetas de los recursos y las configuraciones que utilizan para ejecutarse AWS) en la UE. La nube soberana AWS europea 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, en el caso de los servicios que presta a clientes europeos, puede implementar un MALZ dedicado en la nube soberana AWS europea.
