[reinvent 2025] AWS에서의 Zero Trust 아키텍처

들어가며

클라우드 환경이 복잡해지고 원격 근무가 일상화되면서, 기존의 경계 기반 보안 모델만으로는 충분하지 않은 시대가 되었습니다.

이번 세션에서 주목할 내용은 VPC Lattice를 활용한 마이크로서비스 간 제로트러스트 통신, Amazon Verified Permissions를 통한 세밀한 접근 제어, 그리고 Amazon Verified Access를 이용한 원격 접근 보안입니다. 실제 e-commerce 아키텍처를 개선하는 과정을 통해 Zero Trust 원칙을 단계적으로 적용하는 방법을 살펴보겠습니다.

Zero Trust란 무엇인가?

Zero Trust는 단순한 기술이 아니라 보안에 대한 근본적인 사고방식의 전환입니다. 전통적인 보안 모델은 “네트워크 내부에 있으면 신뢰할 수 있다”는 가정에 기반했지만, Zero Trust는 “어디에서 오든 모든 요청을 검증해야 한다”는 원칙을 따릅니다.

Zero Trust가 필요한 이유는 세 가지로 요약됩니다.

첫째, COVID-19 이후 원격 근무가 보편화되면서 사용자들이 태블릿, 모바일, 카페, 집, 사무실 등 다양한 위치와 기기에서 시스템에 접근하게 되었습니다. 접속 경로가 다양해질수록 위험도 증가하기 때문에, 모든 요청이 유효하고 인증된 것인지 확인해야 합니다.

둘째, 많은 기업들이 HIPAA, PCI-DSS와 같은 규정 준수를 요구받고 있으며, Zero Trust는 이러한 컴플라이언스 요구사항을 충족하고 더 나은 보안 태세를 구축하는 데 도움이 됩니다.

셋째, 공격이 점점 더 정교해지고 있는 상황에서, 정적 IP 기반의 접근 제어만으로는 충분하지 않습니다. 레거시 보안 시스템은 트래픽이 내부 네트워크에 들어오면 안전하다고 가정하지만, 실제로는 그렇지 않습니다. 사용자의 권한, 디바이스 위치, 디바이스 상태, 실시간 위협 신호 등을 종합적으로 고려하여 동적으로 접근 결정을 내려야 합니다.

Zero Trust 구현의 핵심 원칙

세션에서는 Zero Trust 아키텍처를 AWS에서 구현할 때 참고할 수 있는 세 가지 핵심 원칙을 제시했습니다.

Avoid a Binary Choice (이분법적 선택을 피하라)

Zero Trust는 네트워크 제어와 아이덴티티 제어 중 하나를 선택하는 것이 아닙니다. 두 가지는 서로를 보완하는 관계입니다. 중앙 집중식 랜딩 존을 구축하거나 규정 준수가 필요한 환경을 만들 때, 네트워크 제어만 추가하고 모든 사람에게 관리자 권한을 주는 일은 없어야 합니다. 여전히 세밀한 권한 제어가 필요하고, 최소 권한 원칙을 지향해야 합니다.

Work Backwards from Your Use Cases (유스케이스로부터 역방향 설계)

Human-to-Application, Human-to-Machine, Machine-to-Machine 등 각 상호작용 유형은 서로 다르며, 하나의 권한 제어 방식으로 모든 것을 해결할 수는 없습니다. 각 유스케이스의 특성에 맞는 제어 메커니즘을 선택해야 합니다. 모든 애플리케이션에 맞춤형 솔루션을 구축하기보다는, 조금 더 넓은 범위로 생각하되 모든 것을 하나의 컨테이너에 억지로 맞추려 해서는 안 됩니다.

One Size Doesn’t Fit All (하나의 크기가 모두에게 맞지 않는다)

모든 것을 한 번에 Zero Trust화하려 하면 분석 마비에 빠집니다. 의미 있는 하나의 워크로드를 선택하여 시작하고, 개발자들과 함께 제어를 확립한 후 검증합니다. 보안 운영 담당자나 플랫폼 엔지니어라면 개발자들도 이 여정에 함께 참여시켜야 합니다. 달성하고자 하는 기준선 보안 태세를 염두에 두고, 그로부터 역방향으로 작업해야 합니다.

세션에서는 실제 e-commerce 애플리케이션 아키텍처를 개선하는 사례를 다뤘습니다. 초기 아키텍처는 ReactJS 프론트엔드가 CloudFront와 S3에 호스팅되어 있고, API Gateway를 통해 Cognito 인증을 수행하며, 백엔드에는 Inventory 서비스(Lambda), Order 서비스(ECS), User 서비스가 있는 구조였습니다.

이 아키텍처의 주요 문제점들이 확인되었습니다

첫째는, Order 서비스가 Inventory Lambda 함수를 직접 호출하여, 두 서비스가 독립적으로 배포되거나 확장될 수 없었습니다. Inventory 서비스에 문제가 생기면 Order 서비스도 영향을 받는 구조였습니다.

둘째는, 마이크로서비스 간 명확한 API 경계가 없어 로깅, 관찰성(observability), 추적성(traceability)이 떨어졌습니다.

셋째는, 한 서비스가 침해되면 공격자가 같은 VPC 내의 다른 서비스로 쉽게 이동할 수 있는 구조였습니다.

이러한 문제를 해결하기 위해 VPC Lattice를 도입했습니다. VPC Lattice는 AWS 관리형 애플리케이션 네트워킹 서비스로, 마이크로서비스 간 연결을 단순화하고 서비스 디스커버리를 제공합니다.

VPC Lattice의 핵심 장점은 다음과 같습니다.

구현 예시를 보면, Lambda 실행 역할이 VPC Lattice 서비스를 호출할 권한을 가지고 있고, VPC Lattice Auth Policy에서는 특정 Principal(Lambda 실행 역할)만 특정 리소스(Inventory 서비스)에 접근할 수 있도록 정의합니다. 이렇게 논리적 이름을 사용하여 IP 주소가 아닌 서비스 기반 통신이 가능합니다.

또한 Cognito는 그룹 기반의 기본적인 접근 제어는 가능하지만, 리소스별 소유권이나 복잡한 조건(Context)이 필요한 세밀한 인가(Fine-grained Authorization) 로직을 구현하기에는 한계가 있습니다. 이를 해결하기 위해 Amazon Verified Permissions(AVP)를 도입했습니다.

AVP는 Cedar 프레임워크를 기반으로 작동하며, 다음과 같은 이점을 제공합니다.

• 외부화된 권한 관리: 권한 관리를 애플리케이션 외부로 분리하면, 애플리케이션이 침해되더라도 권한 정보는 AVP 내에 안전하게 보관됩니다. 공격자가 사용자 권한을 상승시키거나 애플리케이션 내에서 지속성을 확보하기 어려워집니다.

• 운영 간소화: 여러 Lambda 함수를 트리거하는 복잡한 커스텀 인증 플로우를 구축하는 대신, Lambda Authorizer를 API Gateway에 연결하고, 이 Authorizer가 AVP와 통신하도록 구성할 수 있습니다. Cedar 정책 언어로 리소스, 액션, 조건을 쉽게 정의할 수 있습니다.

• 컨텍스트 기반 의사결정: 사용자 아이덴티티뿐만 아니라 애플리케이션 컨텍스트(요청 시간, 위치, 디바이스 정보 등)를 고려하여 인가 결정을 내릴 수 있습니다.

• 권한 캐싱: AVP 호출 시 추가 지연이 발생할 수 있지만, 권한 스키마는 자주 변경되지 않기 때문에 캐싱을 통해 이를 완화할 수 있습니다. JWT 토큰 검증은 AVP에서 수행하되, 전체 권한 세트는 일정 시간(예: 20분) 동안 캐싱하여 성능을 유지합니다.

또한 COVID-19 이후 분산된 업무 환경에서 원격 사용자가 내부 애플리케이션에 안전하게 접근하도록 하는 것은 중요한 과제가 되었습니다. 전통적으로는 VPN을 사용했지만, 얼마나 많은 ISP IP 주소를 화이트리스트에 추가해야 할지, IAM 정책 한도에 도달하지는 않을지 등의 문제가 있었습니다.

Amazon Verified Access(AVA)는 소프트웨어 기반 네트워킹 제어를 통해 이러한 문제를 해결합니다. VPN과 유사하게 접근 패턴을 구성하지만, 이제는 IAM 정책을 기반으로 각 요청을 검증하고 인증합니다.

주요 특징은 다음과 같습니다.

• 세밀한 접근 제어: 기업 네트워크를 사용한다고 해서 모든 애플리케이션에 접근할 수 있는 것이 아닙니다. 예를 들어, 재무 부서 직원이 기업 네트워크를 사용하더라도 CRM 시스템이나 e-commerce 플랫폼의 관리자 서비스에는 접근하지 못하도록 제한할 수 있습니다.

• 디바이스 포스처 평가: CrowdStrike, Jamf 등 엔드포인트 보호 솔루션과 통합하여 사용자의 디바이스가 최신 보안 패치를 적용했는지, 멀웨어가 없는지, 취약점이 없는지 평가한 후 네트워크 접근을 허용합니다.

• HTTP 및 비HTTP 접근 지원: HTTPS 기반 애플리케이션뿐만 아니라, SSH나 RDP를 통한 서버 접근도 AVA를 통해 보안을 강화할 수 있습니다. 정적 SSH 키를 관리할 필요가 없어지고, 온보딩/오프보딩 프로세스가 단순해집니다.

• OIDC 통합: Okta 등 아이덴티티 프로바이더와 OIDC를 통해 통합하여 Workforce Identity를 관리할 수 있습니다.

AVA는 Systems Manager(SSM)와 비교할 때, SSM은 주로 플랫폼 엔지니어나 운영자가 AWS 계정에 접근할 수 있을 때 유용합니다. 반면 AVA는 개발자가 프로덕션 환경 전체에 접근할 필요 없이 특정 점프 박스나 로그만 확인하고 싶을 때 유용합니다. 각 유스케이스에 맞는 도구를 선택하는 것이 중요합니다.

예방 제어(Preventative Controls)만으로는 충분하지 않으며 탐지 제어 또한 필요합니다.

그리고 세션을 마무리하며 다음과 같은 핵심 실천 사항들에 대해서도 알려주었습니다.

모든 접근에 대해 아이덴티티를 검증하고, 네트워크 위치만으로는 절대 신뢰하지 않아야 합니다. 예외 없이 최소 권한 원칙을 적용하며, 사용자에게 필요한 권한만 제한적으로 부여해야 합니다. CloudWatch와 GuardDuty를 활용하여 행동을 지속적으로 모니터링하고, 이상 징후를 탐지해야 합니다. 강력한 세분화를 통해 침해를 제한하고 횡적 공격 확산을 방지하며, VPC Lattice를 활용한 마이크로세그멘테이션으로 네트워크 포트 노출 없이 안전한 서비스 간 통신을 구성해야 합니다.

세션에서는 “보안은 결코 완료되지 않는다”는 점을 강조했습니다. Zero Trust는 반복적으로 개선해야 하며, Security is Job Zero는 “아무도 하지 않는 일”이 아니라 “모두가 해야 하는 일”이라는 의미입니다.

AWS WAF이번 세션에서 가장 인상적이었던 부분은 AWS 네이티브 서비스만으로도 실질적인 Zero Trust 환경을 구축할 수 있다는 점이었습니다.

특히 VPC Lattice는 마이크로서비스 간 통신에서 겪는 타이트 커플링과 보안 문제를 동시에 해결하는 강력한 솔루션이었습니다. 네트워크 포트를 열지 않고도 IAM 정책으로 서비스 간 통신을 제어할 수 있고, 직접적인 네트워크 경로가 없어 횡적 이동을 원천적으로 차단합니다. 모든 요청이 자동으로 로깅되어 관찰성까지 확보할 수 있다는 점도 매력적이었습니다.

Amazon Verified Permissions는 Cognito의 단순 인증을 넘어 복잡한 비즈니스 로직 기반의 세밀한 인가를 구현할 수 있게 해주며, 권한 관리를 애플리케이션 외부로 분리하여 보안을 한층 강화합니다. Amazon Verified Access는 VPN 대비 훨씬 유연한 원격 접근 제어를 제공하면서도, 디바이스 보안 상태까지 평가할 수 있어 분산 업무 환경에 최적화된 솔루션이라는 생각이 들었습니다.