Amazon Web Services 한국 블로그

Amazon VPC 암호화 제어 기능 출시 – 리전 내 VPC 내부 및 VPC 간 통신에 전송 중 암호화 적용

오늘은 Amazon Virtual Private Cloud(Amazon VPC)의 새로운 기능인 가상 프라이빗 클라우드(VPC) 암호화 제어 기능을 발표합니다. 이 기능을 사용하면 리전 내 VPC 내부 및 VPC 간에 전송 중인 모든 트래픽을 감사하고 암호화를 적용할 수 있습니다.

금융 서비스, 의료, 정부 및 소매 분야의 조직은 클라우드 인프라 전반에서 암호화 규정 준수를 유지하는 데 있어 상당한 운영 복잡성에 직면하고 있습니다. 기존의 접근 방식에서는 여러 솔루션을 통합하고 복잡한 공개 키 인프라(PKI)를 관리하는 동시에 스프레드시트를 사용하여 여러 네트워크 경로에서 암호화를 수동으로 추적해야 합니다. 이 프로세스는 인적 오류가 발생하기 쉬우며 인프라가 확장됨에 따라 점점 더 어려워지고 있습니다.

AWS Nitro 기반 인스턴스는 성능에 영향을 주지 않고 하드웨어 계층에서 트래픽을 자동으로 암호화하지만, 조직은 전체 VPC 인프라로 이러한 기능을 확장하기 위한 간단한 메커니즘이 필요합니다. 이는 HIPAA(의료 보험 이전 및 책임에 관한 법), PCI DSS(지불카드 산업 데이터 보안 표준), FedRAMP(연방 위험 및 승인 관리 프로그램)과 같은 규제 프레임워크의 규정 준수를 입증하는 데 특히 중요합니다. 이러한 규제들은 환경 전반에 걸친 종단 간 암호화에 대한 증빙을 요구합니다. 조직은 성능 저하나 복잡한 키 관리 시스템을 직접 처리하지 않고도, 암호화 상태를 중앙에서 가시화하고 제어할 수 있는 기능이 필요합니다.

VPC 암호화 제어는 모니터링과 적용이라는 두 가지 운영 모드를 제공하여 이러한 문제를 해결합니다. 모니터링 모드에서 트래픽 흐름의 암호화 상태를 감사하고 일반 텍스트 트래픽을 허용하는 리소스를 식별할 수 있습니다. 이 기능은 VPC 흐름 로그에 새로운 암호화 상태 필드를 추가하여 트래픽이 Nitro 하드웨어 암호화, 애플리케이션 계층 암호화(TLS) 또는 둘 다를 사용하여 암호화되었는지 여부를 확인할 수 있습니다.

수정이 필요한 리소스를 식별한 후 암호화를 구현하기 위한 조치를 취할 수 있습니다. Network Load Balancer, Application Load Balancer 및 AWS Fargate 작업 등 AWS 서비스는 별도의 조치 없이 기본 인프라를 투명하게 Nitro 하드웨어로 자동 마이그레이션하며, 이 과정에서 서비스 중단도 발생하지 않습니다. 이전 세대의 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스와 같은 다른 리소스의 경우 최신 Nitro 기반 인스턴스 유형으로 전환하거나 애플리케이션 수준에서 TLS 암호화를 구성해야 합니다.

모든 리소스를 암호화 준수 인프라로 마이그레이션한 후 적용 모드로 전환할 수 있습니다. 암호화 호환 하드웨어 및 통신 프로토콜로의 마이그레이션은 적용 모드를 활성화하기 위한 필수 조건입니다. 트래픽이 VPC 또는 AWS 네트워크 외부로 이동하기 때문에 암호화를 지원하지 않는 인터넷 게이트웨이 또는 NAT 게이트웨이와 같은 리소스에 대해 특정 제외를 구성할 수 있습니다.

다른 리소스는 암호화를 준수해야 하며 제외될 수 없습니다. 활성화 후 적용 모드에서는 향후 모든 리소스가 호환되는 Nitro 인스턴스에서만 생성되며, 잘못된 프로토콜이나 포트가 탐지되면 암호화되지 않은 트래픽은 차단됩니다.

시작하는 방법을 보여드리겠습니다.

이 데모를 위해 EC2 인스턴스 3개를 시작했습니다. 한 인스턴스는 포트 80에 Nginx를 설치해 평문 HTML 페이지를 제공하는 웹 서버로 구성했습니다. 다른 두 개의 인스턴스는 서버에 지속적으로 HTTP GET 요청을 보내고 있습니다. 이렇게 하면 VPC에 평문 트래픽이 생성됩니다. 웹 서버와 두 클라이언트 중 하나에 m7g.medium 인스턴스 유형을 사용합니다. 이 인스턴스 유형은 기본 Nitro System 하드웨어를 사용하여 인스턴스 간 전송 중인 트래픽을 자동으로 암호화합니다. 다른 웹 클라이언트에 t4g.medium 인스턴스를 사용합니다. 해당 인스턴스의 네트워크 트래픽은 하드웨어 수준에서 암호화되지 않습니다.

시작하려면 모니터링 모드에서 암호화 제어를 활성화합니다. AWS Management Console의 왼쪽 탐색 창에서 VPC를 선택한 다음 VPC 암호화 제어 탭으로 전환합니다. 암호화 제어 생성을 선택하고 제어를 생성하려는 VPC를 선택합니다.

각 VPC에는 단 하나의 VPC 암호화 제어만 연결할 수 있으며, 이에 따라 VPC ID와 VPC 암호화 제어 ID 간에 일대일 관계가 생성됩니다. VPC 암호화 제어를 생성할 때 리소스 구성 및 관리에 도움이 되는 태그를 추가할 수 있습니다. 새 VPC를 생성할 때 VPC 암호화 제어를 활성화할 수도 있습니다.

VPC 암호화 제어 - EC 1 생성

이 제어의 이름을 입력합니다. 제어하려는 VPC를 선택합니다. 기존 VPC의 경우 모니터링 모드에서 시작해야 하며 암호화되지 않은 트래픽이 없다는 것이 확실하면 적용 모드를 활성화할 수 있습니다. 새 VPC를 생성할 때 암호화를 강제 적용할 수 있습니다.

선택적으로 기존 VPC에 대한 암호화 제어를 생성할 때 태그를 정의할 수 있습니다. 그러나 VPC 생성 중에 암호화 제어를 활성화하면 VPC 암호화 제어에 대해 별도의 태그를 생성할 수 없습니다. VPC와 동일한 태그를 자동으로 상속하기 때문입니다. 준비가 되면 암호화 제어 생성을 선택합니다.

VPC 암호화 제어 - EC 2 생성 또는 AWS Command Line Interface(AWS CLI)를 사용할 수도 있습니다.

aws ec2 create-vpc-encryption-control --vpc-id vpc-123456789

다음으로 콘솔, 명령줄 또는 흐름 로그를 사용하여 VPC의 암호화 상태를 감사하겠습니다.

aws ec2 create-flow-logs \
  --resource-type VPC \
  --resource-ids vpc-123456789 \
  --traffic-type ALL \
  --log-destination-type s3 \
  --log-destination arn:aws:s3:::vpc-flow-logs-012345678901/vpc-flow-logs/ \
  --log-format '${flow-direction} ${traffic-path} ${srcaddr} ${dstaddr} ${srcport} ${dstport} ${encryption-status}'
{
    "ClientToken": "F7xmLqTHgt9krTcFMBHrwHmAZHByyDXmA1J94PsxWiU=",
    "FlowLogIds": [
        “fl-0667848f2d19786ca”
    ],
    "Unsuccessful": []
}

몇 분 후 로그에 다음과 같은 트래픽이 표시됩니다.

flow-direction traffic-path srcaddr dstaddr srcport dstport encryption-status
ingress - 10.0.133.8 10.0.128.55 43236 80 1 # <-- HTTP between web client and server. 하드웨어 수준에서 암호화됨
egress 1 10.0.128.55 10.0.133.8 80 43236 1
ingress - 10.0.133.8 10.0.128.55 36902 80 1
egress 1 10.0.128.55 10.0.133.8 80 36902 1
ingress - 10.0.130.104 10.0.128.55 55016 80 0 # <-- HTTP between web client and server. 하드웨어 수준에서 암호화되지 않음
egress 1 10.0.128.55 10.0.130.104 80 55016 0
ingress - 10.0.130.104 10.0.128.55 60276 80 0
egress 1 10.0.128.55 10.0.130.104 80 60276 0
  • 10.0.128.55는 하드웨어 암호화된 트래픽을 사용하는 웹 서버이며, 애플리케이션 수준에서는 평문 트래픽을 제공합니다.
  • 10.0.133.8은 하드웨어 암호화된 트래픽을 사용하는 웹 클라이언트입니다.
  • 10.0.130.104는 하드웨어 수준에서 암호화가 적용되지 않은 트래픽을 사용하는 웹 클라이언트입니다.

암호화-상태 필드는 소스 주소와 대상 주소 간의 트래픽에 대한 암호화 상태를 알려줍니다.

  • 0은 해당 트래픽이 평문 상태임을 나타냅니다.
  • 1은 트래픽이 Nitro 시스템에 의해 네트워크 계층(레벨 3)에서 암호화되었음을 의미합니다.
  • 2는 애플리케이션 계층(레벨7, TCP 포트 443 및 TLS/SSL)에서 트래픽이 암호화되었음을 의미합니다.
  • 3은 트래픽이 애플리케이션 계층(TLS)과 네트워크 계층(Nitro) 모두에서 암호화되었음을 의미합니다.
  • “-”은 VPC 암호화 제어가 활성화되지 않았거나 AWS Flow Logs에 상태 정보가 없음을 의미합니다.

Nitro 기반(10.0.130.104)이 아닌 인스턴스의 웹 클라이언트에서 발생하는 트래픽은 0으로 플래그가 지정됩니다. Nitro 기반 인스턴스(10.0.133.8)의 웹 클라이언트에서 시작된 트래픽에는 1로 플래그가 지정됩니다.

또한 콘솔을 사용하여 수정이 필요한 리소스를 식별합니다. 두 개의 암호화되지 않은 리소스, 즉 인터넷 게이트웨이와 Nitro 기반이 아닌 인스턴스의 탄력적 네트워크 인터페이스(ENI)를 보고합니다.

VPC 암호화 제어 - 제어 목록또한 CLI를 사용해 암호화되지 않은 리소스를 확인할 수도 있습니다.

aws ec2 get-vpc-resources-blocking-encryption-enforcement --vpc-id vpc-123456789

암호화를 지원하도록 리소스를 업데이트한 후 콘솔이나 CLI를 사용하여 적용 모드로 전환할 수 있습니다.

콘솔에서 VPC 암호화 제어를 선택합니다. 그런 다음 작업과 모든 전환을 선택합니다.

VPC 암호화 제어 - 모든 전환 또는 이에 해당하는 CLI:

aws ec2 modify-vpc-encryption-control --vpc-id vpc-123456789 --mode enforce

비암호화로 식별된 리소스는 어떻게 수정하나요?

모든 VPC 리소스는 하드웨어 계층 또는 애플리케이션 계층에서 트래픽 암호화를 지원해야 합니다. 대부분의 리소스에 대해서는 별도의 조치를 취할 필요가 없습니다.

AWS PrivateLink 및 게이트웨이 엔드포인트를 통해 액세스한 AWS 서비스는 애플리케이션 계층에서 자동으로 암호화를 적용합니다. 이러한 서비스는 TLS로 암호화된 트래픽만 허용합니다. AWS는 애플리케이션 계층에서 암호화되지 않은 모든 트래픽을 자동으로 차단합니다.

모니터링 모드를 활성화하면 Network Load Balancer, Application Load Balancer, AWS Fargate 클러스터 및 Amazon Elastic Kubernetes Service(Amazon EKS) 클러스터가 기본적으로 암호화를 지원하는 하드웨어로 자동으로 점진적으로 마이그레이션됩니다. 이 마이그레이션은 사용자의 별도 조치 없이 투명하게 이루어집니다.

일부 VPC 리소스의 경우 최신 Nitro 하드웨어 계층 암호화를 지원하는 기본 인스턴스를 선택해야 합니다. 여기에는 EC2 인스턴스, Auto Scaling 그룹, Amazon Relational Database Service(Amazon RDS) 데이터베이스(Amazon DocumentDB 포함), Amazon ElastiCache 노드 기반 클러스터, Amazon Redshift 프로비저닝 클러스터, EKS 클러스터, EC2 용량을 갖춘 ECS, MSK 프로비저닝, Amazon OpenSearch Service 및 Amazon EMR 등이 포함됩니다. Redshift 클러스터를 마이그레이션하려면 스냅샷에서 새 클러스터 또는 네임스페이스를 생성해야 합니다.

최신 세대 인스턴스를 사용한다면 이미 암호화 준수 인프라를 갖추고 있을 가능성이 높습니다. 최신 인스턴스 유형은 모두 암호화를 지원하기 때문입니다. 전송 중 암호화를 지원하지 않는 이전 세대 인스턴스의 경우 지원되는 인스턴스 유형으로 업그레이드해야 합니다.

AWS Transit Gateway를 사용할 때 알아야 할 사항

VPC 암호화가 활성화된 상태로 AWS CloudFormation을 통해 Transit Gateway를 생성하려면 두 개의 AWS Identity and Access Management(IAM) 권한이 추가로 필요합니다. ec2:ModifyTransitGateway 및 ec2:ModifyTransitGatewayOptions가 해당 IAM 권한입니다. 이 권한이 필요한 이유는 CloudFormation이 Transit Gateway를 생성할 때 두 단계의 프로세스를 사용하기 때문입니다. 먼저 기본 구성으로 Transit Gateway를 생성한 다음 ModifyTransitGateway를 직접적으로 호출하여 암호화 지원을 활성화합니다. 이 권한이 없으면, 생성 작업만 수행하는 것처럼 보이더라도 암호화 구성을 적용하는 단계에서 CloudFormation 스택 생성이 실패하게 됩니다.

요금 및 가용성

이제 VPC 암호화 제어를 다음 AWS 리전에서 사용을 시작할 수 있습니다. 미국 동부(오하이오, 버지니아 북부), 미국 서부(캘리포니아 북부, 오리건), 아프리카(케이프타운), 아시아 태평양(홍콩, 하이데라바드, 자카르타, 멜버른, 뭄바이, 오사카, 싱가포르, 시드니, 도쿄), 캐나다(중부), 캐나다 서부(캘거리), 유럽(프랑크푸르트, 아일랜드, 런던, 밀라노, 파리, 스톡홀름, 취리히), 중동(바레인, UAE), 남미(상파울루).

VPC 암호화 제어는 2026년 3월 1일까지 무료로 제공됩니다. 해당 시점이 가까워지면 VPC 요금 페이지가 세부 정보와 함께 업데이트될 예정입니다.

자세히 알아보려면 VPC 암호화 제어 설명서를 참조하거나 AWS 계정에서 직접 사용해 보세요. 보안 태세를 강화하고 규정 준수 표준을 충족하는 데 이 기능이 어떻게 도움이 되는지 알려주시면 좋겠습니다.

– seb