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.
Elaboración de estrategias para la expansión global
Encuesta
Nos encantaría saber de ti. Envíe sus comentarios sobre la AWS PRA mediante una breve encuesta
AWS
Con frecuencia, Security Assurance Services
Las siguientes preguntas son frecuentes 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 los datos personales cruzar las fronteras?
-
¿El acceso humano o de los servicios a los datos entre regiones constituye una transferencia?
-
¿Cómo puedo asegurarme de que ningún gobierno extranjero acceda a los datos personales de mis clientes?
-
¿Dónde puedo almacenar mis copias de seguridad y los sitios calientes 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 los datos, las implementaciones de diferentes arquitecturas podrían funcionar mejor para diferentes organizaciones. Es posible que algunas organizaciones exijan que los datos personales de sus clientes permanezcan en una región específica. Si es así, es posible que le preocupe saber cómo cumplir con las normas en general y, al mismo tiempo, cumplir con estas obligaciones. Independientemente de la situación, hay varias consideraciones a la hora de elegir una estrategia de despliegue de varias cuentas.
Para definir los componentes clave del diseño de la arquitectura, colabore estrechamente con sus equipos de cumplimiento y contratación para confirmar los requisitos sobre dónde, cuándo y cómo se pueden cruzar Regiones de AWS los datos personales. Determine qué se considera transferencia de datos, como 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 respaldo y recuperación ante desastres requieren una conmutación por error entre regiones? Si es así, determine qué regiones puede usar para almacenar sus datos de respaldo. 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 dedicados para la generación de claves. Tras ponerse en contacto con las partes interesadas en materia de cumplimiento en relación con estos temas, comience a considerar enfoques de diseño para su entorno de cuentas múltiples.
Los siguientes son tres enfoques que puede utilizar para planificar su estrategia de AWS cuentas múltiples, en orden ascendente según la segregación de la infraestructura:
También es importante recordar que es posible que el cumplimiento de la privacidad no se limite únicamente a la soberanía de los datos. Consulta el resto de esta guía para entender las posibles soluciones a muchos otros desafíos, como la gestión del consentimiento, las solicitudes de los interesados, la gobernanza de los datos y los sesgos de la IA.
Landing zone central con regiones gestionadas
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, puedes realizar despliegues regionales extendiendo la AWS Control Tower landing zone a una nueva región. De este modo, puede extender la AWS Control Tower gobernanza 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 incluyen 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 es posible que se requiera alguna configuración adicional para contener o redactar los campos confidenciales a fin de evitar la transferencia entre regiones durante la agregación. Para obtener más información y las prácticas recomendadas para controlar la agregación de registros en todas las regiones, consulta esta Almacenamiento de registros centralizado 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é archivos adjuntos de Transit Gateway están permitidos y aprobados, y puede limitar quién o qué puede cambiar las tablas de rutas de la VPC.
-
Es posible que tengas que impedir que los miembros de tu equipo de operaciones en la nube accedan a los datos personales. Por ejemplo, los registros de aplicaciones que contienen datos de transacciones de clientes pueden considerarse de mayor confidencialidad que otras fuentes de registro. Es posible que se requieran aprobaciones y barreras técnicas adicionales, 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.
El siguiente diagrama muestra una landing zone centralizada con despliegues regionales.
Zonas de aterrizaje regionales
Tener más de un MALZ puede ayudarle a cumplir requisitos de conformidad más estrictos al aislar 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 mantener excepciones para el registro con flujos de registros separados que requieren ser redactados. Incluso podría tener un equipo de operaciones en la nube local y dedicado para cada MALZ, lo que limita el acceso del operador a la residencia local.
Muchas organizaciones tienen despliegues separados en las zonas de landing zone en EE. UU. y en la UE. Cada landing zone regional tiene una postura de seguridad única y general y una gobernanza asociada para las cuentas de la región. Por ejemplo, es HSMs posible que no sea necesario cifrar los datos personales mediante una MALZ específica en las cargas de trabajo de una MALZ, pero sí 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
El siguiente diagrama muestra zonas de aterrizaje separadas en dos regiones.
AWS Nube soberana europea
Algunas organizaciones requieren una separación completa entre sus 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, consideremos la nube soberana AWS europea
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, 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.
