기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
글로벌 확장을 위한 전략 수립
설문 조사
귀하의 의견을 듣고 싶습니다. 간단한 설문
AWS Security Assurance Services
다음 질문은 일반적인 질문이며 사용 사례에 대해서만 답변할 수 있습니다.
-
고객의 개인 데이터는 어디에 있어야 하나요?
-
고객 데이터는 어디에 저장되나요?
-
개인 데이터가 국경을 넘어갈 수 있는 방식과 위치는 무엇입니까?
-
리전 간 데이터에 대한 인적 또는 서비스 액세스가 전송을 구성하나요?
-
고객의 개인 데이터에 액세스하는 외국 정부가 없는지 확인하려면 어떻게 해야 하나요?
-
백업과 핫 사이트 또는 콜드 사이트를 어디에 저장할 수 있나요?
-
데이터를 로컬로 유지하려면 서비스를 제공하는 모든 리전에서 AWS 랜딩 존을 유지해야 합니까? 아니면 기존 AWS Control Tower 랜딩 존을 사용할 수 있나요?
데이터 레지던시 요구 사항의 경우 서로 다른 아키텍처 배포가 서로 다른 조직에 더 적합할 수 있습니다. 일부 조직에는 고객의 개인 데이터가 특정 리전 내에 있어야 하는 요구 사항이 있을 수 있습니다. 그렇다면 이러한 의무를 유지하면서 일반적으로 규정을 준수하는 방법에 대해 걱정할 수 있습니다. 상황에 관계없이 다중 계정 배포 전략을 선택할 때 여러 가지 고려 사항이 있습니다.
주요 아키텍처 설계 구성 요소를 정의하려면 규정 준수 및 계약 팀과 긴밀히 협력하여 개인 데이터가를 통과할 수 있는 위치, 시기 및 방법에 대한 요구 사항을 확인합니다 AWS 리전. 이동, 복사 또는 보기와 같이 데이터 전송에 적합한 항목을 결정합니다. 또한 구현해야 하는 특정 복원력 및 데이터 보호 제어가 있는지 이해합니다. 백업 및 재해 복구 전략에 교차 리전 장애 조치가 필요합니까? 그렇다면 백업 데이터를 저장하는 데 사용할 수 있는 리전을 결정합니다. 키 생성을 위한 특정 암호화 알고리즘 또는 전용 하드웨어 보안 모듈과 같은 데이터 암호화에 대한 요구 사항이 있는지 확인합니다. 이러한 주제에 대한 규정 준수 이해관계자와 조율한 후 다중 계정 환경의 설계 접근 방식을 고려하기 시작합니다.
다음은 인프라 분리의 오름차순으로 다중 계정 전략을 계획하는 데 사용할 수 있는 AWS 세 가지 접근 방식입니다.
또한 개인 정보 보호 규정 준수는 데이터 주권에서만 중단되지 않을 수 있다는 점을 기억해야 합니다. 이 가이드의 나머지 부분을 검토하여 동의 관리, 데이터 주체의 요청, 데이터 거버넌스, AI 편향과 같은 다른 여러 문제에 대한 가능한 솔루션을 이해합니다.
관리형 리전이 있는 중앙 랜딩 존
전역적으로 확장하고 싶지만 이미에서 다중 계정 아키텍처를 설정한 경우 동일한 다중 계정 랜딩 존(MALZ)을 사용하여 추가를 관리하는 AWS것이 일반적입니다 AWS 리전. 이 구성에서는 로깅, 계정 팩토리, 기존 AWS Control Tower 랜딩 존의 일반 관리와 같은 인프라 서비스를 생성한 리전에서 계속 운영합니다.
프로덕션 워크로드의 경우 AWS Control Tower 랜딩 존을 새 리전으로 확장하여 리전 배포를 운영할 수 있습니다. 이렇게 하면 거버넌스를 AWS Control Tower 새 리전으로 확장할 수 있습니다. 이렇게 하면 특정 관리형 리전 내에 개인 데이터 스토어를 유지할 수 있으며, 데이터는 여전히 인프라 서비스 및 AWS Control Tower 거버넌스의 이점을 활용하는 계정에 상주합니다. 에서 개인 데이터가 포함된 AWS Organizations계정은의 모든 데이터 주권 가드레일이 구현되는 전용 개인 데이터 OU 아래에 계속 롤업 AWS Control Tower 됩니다. 또한 리전별 워크로드는 여러 리전에서 동일한 워크로드를 포함할 수 있는 프로덕션 계정을 설정하는 대신 전용 계정에 포함됩니다.
이 배포는 가장 비용 효율적일 수 있지만, AWS 계정 및 리전 경계를 넘어 개인 데이터의 흐름을 제어하려면 추가 고려가 필요합니다. 다음을 고려하세요.
-
로그에는 개인 데이터가 포함될 수 있으므로 집계 중에 리전 간 전송을 방지하기 위해 민감한 필드를 포함하거나 수정하려면 몇 가지 추가 구성이 필요할 수 있습니다. 리전 간 로그 집계를 제어하는 방법에 대한 자세한 내용과 권장 사례는이 가이드중앙 집중식 로그 스토리지의 섹션을 참조하세요.
-
AWS Transit Gateway 설계에서 VPCs 격리 및 적절한 양방향 네트워크 트래픽 흐름을 고려합니다. 허용 및 승인되는 Transit Gateway 연결을 제한할 수 있으며 VPC 라우팅 테이블을 변경할 수 있는 사용자 또는 대상을 제한할 수 있습니다.
-
클라우드 운영 팀의 구성원이 개인 데이터에 액세스하지 못하도록 해야 할 수 있습니다. 예를 들어 고객 트랜잭션 데이터가 포함된 애플리케이션 로그는 다른 로그 소스보다 민감도가 높은 것으로 간주될 수 있습니다. 역할 기반 액세스 제어 및 속성 기반 액세스 제어와 같은 추가 승인 및 기술 가드레일이 필요할 수 있습니다. 또한 데이터에 액세스할 때 레지던시 제한이 적용될 수 있습니다. 예를 들어 한 리전 A의 데이터는 해당 리전 내에서만 액세스할 수 있습니다.
다음 다이어그램은 리전 배포가 있는 중앙 집중식 랜딩 존을 보여줍니다.
리전별 랜딩 존
MALZ가 두 개 이상 있으면 중요하지 않은 워크로드에 비해 개인 데이터를 처리하는 워크로드를 완전히 격리하여 더 엄격한 규정 준수 요구 사항을 달성하는 데 도움이 될 수 있습니다. AWS Control Tower 중앙 집중식 로깅 집계는 기본적으로 구성하여 간소화할 수 있습니다. 이 접근 방식을 사용하면 수정이 필요한 별도의 로그 스트림으로 로깅하기 위한 예외를 유지할 필요가 없습니다. 운영자 액세스를 로컬 레지던시로 제한하는 각 MALZ에 대한 로컬 및 전용 클라우드 운영 팀이 있을 수도 있습니다.
많은 조직에 별도의 미국 및 EU 기반 랜딩 존 배포가 있습니다. 각 리전 랜딩 존에는 리전의 계정에 대한 하나의 포괄적인 보안 태세와 관련 거버넌스가 있습니다. 예를 들어 전용 HSMs 사용한 개인 데이터 암호화는 한 MALZ의 워크로드에는 필요하지 않을 수 있지만 다른 MALZ에는 필요할 수 있습니다.
이 전략은 현재와 미래의 여러 요구 사항을 충족하도록 확장할 수 있지만 여러 MALZs 유지 관리와 관련된 추가 비용과 운영 오버헤드를 이해하는 것이 중요합니다. 자세한 내용은 AWS Control Tower 요금
다음 다이어그램은 두 리전의 별도의 랜딩 존을 보여줍니다.
AWS European Sovereign Cloud
일부 조직에서는 유럽 경제 지역(EEA)에서 운영하는 워크로드와 다른 지역에서 운영하는 워크로드를 철저히 분리해야 합니다. 이 경우 AWS European Sovereign Cloud
AWS European Sovereign Cloud는 기존와 물리적 및 논리적으로 분리되는 동시에 동일한 보안 AWS 리전, 가용성 및 성능을 제공합니다. EU에 위치한 AWS 직원만 AWS 유럽 주권 클라우드에 대한 운영 및 지원을 제어할 수 있습니다. 엄격한 데이터 레지던시 요구 사항이 있는 경우 AWS European Sovereign Cloud는 사용자가 생성한 모든 메타데이터(예: 실행하는 데 사용하는 역할, 권한, 리소스 레이블 및 구성 AWS)를 EU에 보관합니다. AWS European Sovereign Cloud에는 자체 결제 및 사용량 측정 시스템도 있습니다.
이 접근 방식의 경우 이전 섹션인 리전 랜딩 존과 유사한 패턴을 사용합니다. 그러나 유럽 고객에게 제공하는 서비스의 경우 AWS European Sovereign Cloud에 전용 MALZ를 배포할 수 있습니다.
