원문: AWS Cloud Practitioner Essentials — Module 6: Security
출처: AWS E-Learning / Compiled by Kenneth Leung (2020)

한 줄 요약: AWS 보안의 출발점은 “클라우드의 보안은 AWS가, 클라우드 안의 보안은 고객이” 책임진다는 공동 책임 모델이며, IAM으로 접근을 통제하고, Shield·WAF·KMS 등으로 공격과 데이터 유출에 대비한다.

집은 건설사가 짓고, 문단속은 입주자가 한다 — 공동 책임 모델

AWS에서 EC2 인스턴스를 만들고, S3 버킷에 데이터를 올리고, RDS 데이터베이스를 운영한다고 하자. 이 리소스들의 보안은 누가 책임질까? 정답은 “둘 다”다.

AWS는 공동 책임 모델(Shared Responsibility Model)을 따른다. 건설사(AWS)가 집의 구조와 기초를 튼튼하게 짓고, 입주자(고객)가 문을 잠그고 귀중품을 관리하는 것과 같다.

책임 주체 범위 구체적 항목
AWS — “클라우드의 보안” (Security of the Cloud) 인프라 물리적 데이터 센터, 하드웨어/소프트웨어 인프라, 네트워크, 가상화 계층, 리전·AZ·엣지 로케이션
고객 — “클라우드안의 보안” (Security in the Cloud) 콘텐츠 & 설정 고객 데이터, 플랫폼·애플리케이션, OS 선택·패치, 보안 그룹 설정, 사용자 계정 관리, 암호화

AWS 데이터 센터를 직접 방문할 수는 없지만, AWS는 제3자 감사 보고서를 통해 보안 기준 준수를 증명한다.

누가 무엇에 접근할 수 있는가 — AWS IAM

AWS Identity and Access Management(IAM)는 AWS 서비스와 리소스에 대한 접근을 안전하게 관리하는 서비스다. IAM은 사용자(User), 그룹(Group), 역할(Role), 정책(Policy)이라는 네 가지 구성요소로 이루어진다.

루트 사용자 — 만능 열쇠는 금고에 넣어두자

AWS 계정을 처음 만들면 루트 사용자(root user)가 생성된다. 계정 내 모든 서비스와 리소스에 대한 완전한 접근 권한을 가진다. 커피숍의 오너에 해당한다.

루트 사용자로 해야 하는 일은 딱 두 가지 정도다: 루트 사용자 이메일 주소 변경, AWS 지원 플랜 변경. 그 외 일상적인 작업에는 절대 사용하지 말아야 한다. 대신 루트 사용자로 첫 번째 IAM 사용자를 만들고, 이후에는 그 IAM 사용자로 작업한다. 루트 사용자에는 반드시 다중 인증(MFA)을 활성화해야 한다.

IAM 사용자 — 기본은 “권한 없음”

IAM 사용자는 AWS와 상호작용하는 사람이나 애플리케이션을 나타내는 ID다. 새로 만든 IAM 사용자는 아무런 권한이 없다. 이것이 최소 권한 원칙(principle of least privilege)이다 — 필요한 권한만, 필요한 만큼만 부여한다.

같은 레벨의 권한이 필요한 직원이 여러 명이더라도, 각자 개별 IAM 사용자를 만드는 것이 보안 모범 사례다. 각 사용자가 고유한 자격 증명(credential)을 갖게 되기 때문이다.

IAM 정책 — JSON으로 쓰는 허가서

IAM 정책(Policy)은 AWS 서비스·리소스에 대한 권한을 허용(Allow) 또는 거부(Deny)하는 JSON 문서다. 정책에는 세 가지 핵심 요소가 있다.

요소 설명 예시
Effect 허용 또는 거부 "Allow" 또는 "Deny"
Action 어떤 API 호출을 "s3:ListObject"
Resource 어떤 리소스에 대해 "arn:aws:s3:::AWSDOC-EXAMPLE-BUCKET"

정책은 IAM 사용자, 그룹, 역할에 연결(attach)하여 적용한다.

IAM 그룹 — 한꺼번에 권한 관리

IAM 그룹은 IAM 사용자들의 모음이다. 그룹에 정책을 연결하면, 그룹 내 모든 사용자에게 해당 권한이 부여된다. 커피숍에서 캐셔 3명에게 일일이 권한을 주는 대신 “Cashiers” 그룹을 만들어 한 번에 관리하는 것과 같다. 직원이 부서를 옮기면 기존 그룹에서 빼고 새 그룹에 넣으면 된다.

IAM 역할 — 잠깐만 빌려 쓰는 권한

IAM 역할(Role)은 임시로 권한을 부여받기 위해 전환(assume)하는 ID다. 사용자와 비슷하지만 사용자명과 비밀번호가 없다. 커피숍 직원이 오전에는 캐셔, 오후에는 재고 관리를 맡을 때 각각의 역할로 전환하는 것과 같다. 역할을 전환하면 이전 역할의 모든 권한은 사라지고, 새 역할의 권한만 갖게 된다.

비밀번호만으로는 부족하다 — 다중 인증(MFA)

다중 인증(Multi-Factor Authentication, MFA)은 비밀번호 외에 추가 인증 수단(하드웨어 보안 키, MFA 앱의 일회용 코드 등)을 요구하는 방식이다. 비밀번호가 유출되더라도 두 번째 인증 없이는 접근할 수 없다.

루트 사용자와 모든 IAM 사용자에게 MFA를 활성화하는 것이 모범 사례다.

여러 계정을 하나로 — AWS Organizations

회사가 성장하면 개발팀, 회계팀, 법무팀 등이 각각 AWS 계정을 가질 수 있다. AWS Organizations는 이 여러 계정을 중앙에서 통합 관리하는 서비스다.

핵심 기능

기능 설명
서비스 제어 정책(SCP) 조직 루트, 개별 계정, 조직 단위(OU)에 적용하여 사용할 수 있는 AWS 서비스와 API를 제한
조직 단위(OU) 유사한 보안·비즈니스 요구를 가진 계정을 그룹으로 묶어 정책을 일괄 적용
통합 결제(Consolidated Billing) 모든 멤버 계정의 비용을 하나로 합산, 대량 할인 적용

SCP는 IAM 정책과 달리 루트 사용자에게도 적용된다는 점이 중요하다. 단, IAM 정책을 루트 사용자에게 직접 적용할 수는 없다.

규정 준수를 증명해야 한다면 — AWS Artifact

산업에 따라 특정 보안·규정 준수 기준을 충족해야 하는 경우가 있다. 직접 데이터 센터를 운영하지 않는 클라우드 환경에서 이를 어떻게 증명할까?

AWS Artifact는 AWS의 보안 및 규정 준수 보고서에 온디맨드로 접근할 수 있는 서비스다. 두 가지 주요 섹션으로 구성된다.

섹션 용도
AWS Artifact Agreements HIPAA, GDPR 등 규정에 대한 계약 체결·관리
AWS Artifact Reports 제3자 감사 기관의 규정 준수 보고서 열람 (ISO, SOC, PCI 등)

Customer Compliance Centre에서는 규정 준수 사례, 백서, 감사 체크리스트 등도 확인할 수 있다. AWS 리전을 선택할 때 해당 국가의 데이터 저장 규정을 고려하는 것도 중요하다 — AWS는 고객이 선택하지 않으면 데이터를 다른 리전으로 자동 복제하지 않는다.

서비스를 못 쓰게 만드는 공격 — DoS와 DDoS

서비스 거부 공격(Denial-of-Service, DoS)은 웹사이트나 애플리케이션에 과도한 트래픽을 보내 정상 사용자가 접속하지 못하게 만드는 공격이다. 커피숍에 장난 전화를 쉴 새 없이 걸어 진짜 고객의 주문을 받지 못하게 하는 것과 같다.

분산 서비스 거부 공격(Distributed DoS, DDoS)은 여러 감염된 컴퓨터(봇)를 동원해 공격하는 방식이다. 출처가 다양하기 때문에 단순히 IP를 차단하는 것만으로는 막기 어렵다.

DDoS 공격의 예시

공격 유형 방식
UDP Flood 위조된 반환 주소로 대용량 응답을 유도하여 타겟 서버에 쏟아붓는 공격
HTTP Level Attack 정상 요청처럼 보이는 복잡한 쿼리를 봇 군단이 반복 전송
Slowloris 의도적으로 연결을 느리게 유지하여 서버의 동시 접속 용량을 소진

DDoS를 막는 방패 — AWS Shield

AWS Shield는 DDoS 공격으로부터 애플리케이션을 보호하는 서비스다.

등급 비용 기능
Shield Standard 무료 (모든 AWS 고객 자동 적용) 가장 흔한 DDoS 공격을 실시간 탐지·자동 완화
Shield Advanced 유료 정교한 공격에 대한 상세 진단, CloudFront·Route 53·ELB와 연동, AWS WAF와 통합하여 커스텀 규칙 작성

데이터를 잠그는 열쇠 — AWS KMS

데이터는 저장 중(at rest)이든 전송 중(in transit)이든 암호화해야 한다. 저장 중 암호화는 데이터를 디스크에 쓸 때 잠그는 것이고, 전송 중 암호화는 서비스 간 데이터 이동 시 SSL/TLS 등으로 보호하는 것이다.

AWS Key Management Service(AWS KMS)는 암호화 키를 생성·관리·사용할 수 있는 서비스다. 어떤 IAM 사용자와 역할이 키를 관리할 수 있는지 세밀하게 제어할 수 있으며, 키를 일시적으로 비활성화할 수도 있다. 키는 절대 AWS KMS 밖으로 나가지 않는다.

DynamoDB의 저장 중 암호화가 대표적인 사용 사례다 — 서버 측 암호화가 모든 테이블에 기본 적용되며, KMS와 연동하여 암호화 키를 관리한다.

웹 요청을 걸러내는 방화벽 — AWS WAF

AWS WAF(Web Application Firewall)는 웹 애플리케이션으로 들어오는 네트워크 요청을 모니터링하고, 웹 접근 제어 목록(web ACL)을 기반으로 트래픽을 허용하거나 차단한다.

Amazon CloudFront, Application Load Balancer와 함께 동작하며, 차단할 IP 주소 목록을 설정하면 해당 IP로부터의 모든 요청을 거부한다. 머신러닝 기능으로 새로운 위협 패턴도 선제적으로 탐지한다.

취약점을 자동으로 점검한다 — Amazon Inspector와 GuardDuty

서비스 역할 작동 방식
Amazon Inspector 자동 보안 평가 EC2 인스턴스의 오픈 접근, 취약한 소프트웨어 버전 등을 점검하고 심각도별 결과 목록 제공
Amazon GuardDuty 지능형 위협 탐지 VPC Flow Logs, DNS 로그 등을 지속적으로 분석하여 악성 IP, 이상 행동, 위협을 자동 탐지

두 서비스의 차이를 간단히 정리하면, Inspector는 “내 애플리케이션에 구멍이 없는지” 체크하는 것이고, GuardDuty는 “누군가 이미 침입하고 있지 않은지” 감시하는 것이다. GuardDuty는 별도의 소프트웨어 설치 없이 활성화만 하면 되며, 기존 인프라의 성능에 영향을 주지 않는다. Lambda를 연동하면 위협 발견 시 자동 대응도 가능하다.

마무리

AWS 보안은 하나의 서비스로 완성되지 않는다. 공동 책임 모델로 경계를 나누고, IAM으로 접근을 통제하고, KMS로 데이터를 암호화하고, Shield와 WAF로 공격을 방어하고, Inspector와 GuardDuty로 취약점과 위협을 감시한다. 핵심 원칙 두 가지만 기억하자: 최소 권한으로 접근을 제한하고, 모든 계층에서 데이터를 암호화하라.