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