[SCS-C02 심층 분석] AWS 컴퓨팅 서비스(EC2, Lambda, 컨테이너) 보안 아키텍처 핵심 가이드: IAM, 네트워크, 런타임 보호 전략
작성자: aws | 작성일: 2026년 07월 05일 | 조회: 0 | 좋아요: 0
AWS 클라우드 환경에서 애플리케이션을 실행하는 핵심은 컴퓨팅 서비스입니다. AWS Security – Specialty (SCS-C02) 자격증 시험에서 컴퓨팅 서비스의 보안은 매우 중요하게 다뤄지며, 실제 운영 환경에서도 가장 빈번하게 보안 위협에 노출될 수 있는 영역입니다. 이 강의에서는 AWS의 주요 컴퓨팅 서비스인 EC2, Lambda, ECS, EKS, Fargate, Elastic Beanstalk에 걸쳐 공통적으로 적용되는 보안 원칙과 각 서비스별 특성을 고려한 보안 아키텍처 전략을 깊이 있게 다룹니다. 특히 IAM 역할(IAM Role), 네트워크 보안, 데이터 보호, 런타임 보안 및 모니터링 관점에서 핵심 개념을 정리하여, 시험 합격은 물론 실제 클라우드 보안 설계 역량을 강화하는 데 도움을 드리고자 합니다.
1. IAM Role을 통한 최소 권한 원칙(Least Privilege) 구현
AWS 컴퓨팅 서비스에서 가장 기본적인 보안 원칙은 최소 권한 원칙(Least Privilege)을 적용하는 것입니다. 이는 각 서비스 또는 애플리케이션이 자신의 기능을 수행하는 데 필요한 최소한의 권한만을 부여해야 한다는 의미입니다. AWS에서는 IAM Role(IAM 역할)을 사용하여 이를 구현합니다.
- EC2 인스턴스 프로파일(EC2 Instance Profile): EC2 인스턴스가 AWS API를 호출하거나 다른 AWS 서비스(예: S3, DynamoDB)에 접근해야 할 때, IAM Role이 연결된 인스턴스 프로파일을 사용합니다. 이는 액세스 키(Access Key)를 인스턴스 내부에 저장하는 위험을 제거하며, 임시 자격 증명(Temporary Credentials)을 자동으로 관리합니다. IMDSv2(Instance Metadata Service Version 2)를 사용하여 메타데이터에 대한 접근 보안을 강화하는 것이 권장됩니다.
- Lambda 실행 역할(Lambda Execution Role): Lambda 함수가 실행될 때 필요한 권한(예: CloudWatch Logs에 로그 기록, DynamoDB 테이블 접근)을 정의하는 IAM Role입니다. 함수에 할당된 이 역할을 통해 Lambda는 다른 AWS 서비스와 안전하게 상호 작용합니다.
- ECS/EKS 태스크/파드 역할(Task/Pod IAM Role): 컨테이너 서비스에서는 개별 태스크(Task) 또는 파드(Pod) 단위로 IAM Role을 부여할 수 있습니다. ECS Task IAM Role은 ECS 태스크 내의 컨테이너에 필요한 권한을 제공하며, EKS Pod IAM Role (IRSA: IAM Roles for Service Accounts)은 EKS 클러스터 내의 파드가 AWS API를 호출할 때 IAM Role을 직접 사용할 수 있게 합니다. 이는 컨테이너 간의 권한 분리 및 최소 권한 적용에 필수적입니다.
2. 네트워크 보안 계층(Network Security Layers) 강화
컴퓨팅 리소스는 네트워크를 통해 외부 또는 내부 리소스와 통신하므로, 강력한 네트워크 보안 설정은 필수입니다.
- VPC(Virtual Private Cloud) 기본 및 서브넷 설계: 모든 컴퓨팅 리소스는 AWS VPC 내에 격리되어 생성됩니다. Public Subnet(퍼블릭 서브넷)과 Private Subnet(프라이빗 서브넷)으로 나누고, 인터넷에 직접 노출될 필요가 없는 EC2 인스턴스, Lambda 함수, 컨테이너 등은 Private Subnet에 배치해야 합니다. Public Subnet의 리소스는 인터넷 게이트웨이(Internet Gateway)를 통해, Private Subnet의 리소스는 NAT 게이트웨이(NAT Gateway)나 VPC 엔드포인트(VPC Endpoint)를 통해 외부와 통신하도록 구성합니다.
- 보안 그룹(Security Group)과 네트워크 ACL(Network ACL):
- 보안 그룹: 인스턴스 수준에서 작동하는 스테이트풀(Stateful) 방화벽입니다. 허용 규칙만 설정 가능하며, 트래픽의 Ingress(인바운드)와 Egress(아웃바운드)를 제어하여 특정 포트, 프로토콜, IP 주소/보안 그룹으로부터의 접근을 제한합니다. EC2, ECS 태스크, EKS 파드 등 개별 컴퓨팅 리소스에 적용됩니다.
- 네트워크 ACL: 서브넷 수준에서 작동하는 스테이트리스(Stateless) 방화벽입니다. 허용 및 거부 규칙을 모두 설정할 수 있으며, 규칙 번호에 따라 트래픽이 처리됩니다. 더 광범위한 트래픽 제어에 사용되지만, 보안 그룹에 비해 세밀한 제어는 어렵습니다.
- VPC 엔드포인트(VPC Endpoints) 및 PrivateLink: 인터넷 게이트웨이를 통하지 않고 VPC 내에서 AWS 서비스(예: S3, DynamoDB, SSM)에 안전하게 비공개로 접속할 수 있도록 합니다. 인터페이스 엔드포인트(Interface Endpoint)와 게이트웨이 엔드포인트(Gateway Endpoint) 두 가지 유형이 있으며, 이를 통해 데이터 유출 위험을 줄이고 네트워크 트래픽을 프라이빗하게 유지할 수 있습니다. AWS PrivateLink는 VPC 내에서 프라이빗 서비스 공급자와 소비자 간의 연결을 제공합니다.
- Lambda의 VPC 접근성: Lambda 함수가 Private Subnet 내의 RDS 데이터베이스나 EC2 인스턴스 같은 리소스에 접근해야 할 경우, Lambda 함수를 VPC 내부에서 실행하도록 구성해야 합니다. 이때 Lambda는 해당 VPC의 ENI(Elastic Network Interface)를 사용하여 통신하며, 적절한 보안 그룹과 서브넷 설정이 필요합니다.
3. 데이터 보호 및 비밀 관리(Data Protection & Secret Management)
애플리케이션이 처리하는 데이터의 보안은 매우 중요합니다. 데이터는 저장 시(at Rest)와 전송 시(in Transit) 모두 암호화되어야 합니다.
- 저장 데이터 암호화(Encryption at Rest):
- EC2: EBS 볼륨은 AWS KMS(Key Management Service)를 사용하여 쉽게 암호화할 수 있습니다. 암호화된 볼륨에서 생성된 스냅샷도 자동으로 암호화됩니다.
- ECS/EKS/Fargate: 컨테이너 스토리지는 주로 EBS, EFS(Elastic File System) 또는 S3를 사용하며, 이들 모두 KMS 기반 암호화를 지원합니다. EFS는 마운트된 파일 시스템의 모든 데이터를 암호화할 수 있습니다.
- 전송 데이터 암호화(Encryption in Transit):
- API 호출 시 HTTPS/TLS를 기본으로 사용하고, Load Balancer (ELB)를 사용하여 SSL/TLS를 종료(Terminate)하거나 재암호화(Re-encrypt)할 수 있습니다. AWS Certificate Manager (ACM)를 활용하여 SSL/TLS 인증서를 손쉽게 프로비저닝하고 관리합니다.
- AWS Secrets Manager 및 SSM Parameter Store: 데이터베이스 자격 증명, API 키 등 민감한 정보를 하드코딩하거나 평문으로 저장하는 것은 보안 취약점을 만듭니다. AWS Secrets Manager는 이러한 비밀 정보를 안전하게 저장하고 자동으로 순환(Rotate)시켜 관리하는 데 최적화되어 있습니다. SSM Parameter Store는 일반적인 구성 데이터를 포함한 매개변수를 안전하게 저장하고 관리하는 데 사용될 수 있으며, Secure String 유형으로 민감 정보를 암호화하여 저장할 수 있습니다.
4. 런타임 보안 및 모니터링(Runtime Security & Monitoring)
컴퓨팅 리소스가 운영 중인 동안 발생하는 위협을 감지하고 대응하는 런타임 보안 및 지속적인 모니터링은 보안 상태를 유지하는 데 필수적입니다.
- 패치 관리(Patch Management) 및 구성 관리(Configuration Management): AWS Systems Manager (SSM)의 Patch Manager는 EC2 인스턴스의 운영체제 및 애플리케이션에 대한 패치를 자동화하여 보안 취약점을 줄입니다. State Manager는 인스턴스의 구성을 일관되게 유지하는 데 도움을 줍니다. 또한, Session Manager를 통해 SSH 키 없이 인스턴스에 안전하게 접근하여 관리할 수 있습니다.
- 로그 및 모니터링(Logging & Monitoring):
- AWS CloudTrail: 계정 내 모든 AWS API 호출을 기록하여 누가, 언제, 어디서, 무엇을 했는지에 대한 감사 로그를 제공합니다. 모든 컴퓨팅 서비스에 걸쳐 활성화하고 중앙화된 S3 버킷에 저장하며, 무결성 검증을 설정하는 것이 중요합니다.
- Amazon CloudWatch: EC2, Lambda, ECS, EKS 등 모든 컴퓨팅 서비스의 지표(Metric)와 로그(Log)를 수집하여 모니터링하고 경보(Alarm)를 설정합니다. 비정상적인 활동이나 성능 저하를 감지하여 신속하게 대응할 수 있도록 합니다.
- Amazon GuardDuty: 지능형 위협 탐지 서비스로, AWS 계정 및 워크로드에서 잠재적인 위협을 지속적으로 모니터링합니다. EC2 인스턴스, EKS 런타임, S3 버킷 등에 대한 악성 활동을 탐지하는 데 탁월합니다.
- AWS Config: AWS 리소스의 구성 변경 사항을 지속적으로 기록하고, 정의된 규칙(예: 모든 EC2 인스턴스는 특정 보안 그룹에 속해야 함)에 따라 규정 준수 여부를 평가합니다.
- 컨테이너 런타임 보안:
- 이미지 보안: 신뢰할 수 있는 소스에서 컨테이너 이미지를 가져오고, Amazon ECR(Elastic Container Registry)에 저장하기 전에 취약점 스캔(Vulnerability Scanning)을 수행하여 악성 코드를 제거합니다.
- Pod Security Standards (EKS): EKS에서는 Pod Security Standards를 통해 파드의 보안 컨텍스트(Security Context)를 정의하고, 최소 권한으로 컨테이너를 실행하도록 강제할 수 있습니다.
- Fargate: 서버리스 컨테이너 엔진인 Fargate는 호스트 OS 수준의 패치 및 관리를 AWS가 대신하므로, 사용자는 컨테이너 이미지 및 애플리케이션 코드 보안에 집중할 수 있습니다.
5. Elastic Beanstalk 보안 고려사항
AWS Elastic Beanstalk는 애플리케이션 배포 및 관리를 자동화하지만, 그 아래에는 EC2 인스턴스, 로드 밸런서, RDS 등 다양한 AWS 리소스가 통합되어 있습니다. 따라서 Elastic Beanstalk 환경의 보안은 이들 개별 리소스의 보안 설정에 크게 의존합니다.
- 기본 EC2 인스턴스 보안: Elastic Beanstalk 환경을 생성할 때 사용되는 EC2 인스턴스에 대한 보안 그룹, IAM Role을 적절히 구성해야 합니다. SSM을 통한 패치 관리 및 OS 수준의 보안 강화도 고려해야 합니다.
- 환경 설정 및 네트워크 분리: 애플리케이션에 필요한 포트만 개방하고, 내부 통신은 Private Subnet을 통해 이루어지도록 VPC 설정을 최적화해야 합니다. 데이터베이스와 같은 민감한 백엔드 리소스는 항상 Private Subnet에 위치시켜야 합니다.
- 웹 티어(Web Tier)와 워커 티어(Worker Tier)의 보안 차이: Elastic Beanstalk는 웹 티어와 워커 티어를 지원합니다. 웹 티어는 외부 트래픽을 처리하며 주로 퍼블릭 서브넷에 배치될 수 있지만, 워커 티어는 SQS 큐에서 메시지를 처리하는 백엔드 프로세스로, 인터넷에 직접 노출되지 않는 프라이빗 서브넷에 두는 것이 보안상 권장됩니다.
SCS-C02 시험에서는 특정 서비스의 기능 자체보다는 '어떻게' 해당 서비스가 보안 요구사항을 충족시키는지, 그리고 여러 서비스 간의 보안 연동 방식을 묻는 문제가 자주 출제됩니다. 예를 들어, EC2 인스턴스가 S3 버킷에 접근할 때 어떤 보안 메커니즘(IAM Role vs. Access Key)이 권장되며 그 이유는 무엇인지, Lambda가 VPC 내 리소스에 접근할 때 필요한 설정은 무엇인지 등을 깊이 이해하는 것이 중요합니다. 최소 권한 원칙(Least Privilege), 다중 계층 방어(Defense in Depth)의 관점에서 각 서비스를 재해석하는 연습을 하세요.