클라우드 보안 아키텍처
- 클라우드 환경에서 데이터, 애플리케이션 및 인프라를 보호하는 방법을 정의하는 청사진. 여기에는 신원관리, 암호화, 네트워크 제어 및 모니터링 시스템이 함께 작동함.
- 액세스 제어부터 위협 탐지까지 다양한 보안 계층을 구축하는 것과 유사함.
- 비즈니스 운영을 유지하며 사이버 공격 및 무단 액세스로부터 클라우드 리소스를 보호
클라우드 보안 아키텍처의 핵심 계층
심층 방어(Defense in Depth) 전략: 다중 레이어 보안 체계
1. 신원 및 접근 권리(IAM: Identify and Access Management)
- 다중 인증(MFA) 및 SSO: Credential Stuffing 등을 방어하기 위한 필수 통제 수단
- 최소 권한의 원칙(Least Privilege): 사용자 및 서비스(EC2, Lambda)에 업무 수행에 필요한 최소한의 권한만 부여해 피해 범위 축소
- Zero Trust 모델: 아무것도 신뢰하지 않고 항상 검증한다. 는 원칙하에 내부망에 접속해 있더라도 철저한 인증과 권한 검증을 거치도록 설계
2. 네트워크 보안(Network Security)
- 네트워크 세분화(Segmentation): VPC 및 서브넷(Public/Private)을 논리적으로 분리하여 인터넷에 노출되는 자원과 내부 자원을 엄격히 격리함.
- 접근 제어(Access Control): 상태 저장(Stateful) 기반의 Security Group(보안 그룹)과 상태 비저장(Stateless) 기반의 NACL을 교차 적용하여 트래픽 인바운드/아웃바운드 제어
- 경계 방어: 웹 애플리케이션 방화벽을 통해 L7 애플리케이션 공격(SQLi, XSS 등)을 차단하고 DDoS 방어 솔루션을 적용하여 가용성을 확보.
3. 데이터 보호 (Data Protection)
- 저장 데이터 암호화 (Data at Rest): KMS(Key Management Service)를 활용하여 디스크 볼륨(EBS), 데이터베이스(RDS), 오브젝트 스토리지(S3)의 데이터를 암호화함.
- 전송 데이터 암호화(Data in Transit): 클라이언트와 서버 또는 서버 간 내부 통신 구간에 TLS 1.2 이상의 프로토콜을 적용하여 스니핑을 방지함.
- 데이터 분류(Data Classification): 민감 데이터(개인정보, 금융정보 등)를 식별하고, 비인가된 접근이나 외부 유출을 방지하는 통제 정책(DLP)을 적용.
4. 애플리케이션 및 워크로드 보안(App & Workload Security)
- 인프라 위에 배포되는 코드와 애플리케이션 자체의 취약점을 식별하고 조치함
- DevSecOps 통합(Shift-Left): CI/CD 파이프라인에 보안 점검(SAST, DAST, SCA)을 자동화해 서비스 배포 전 코드 레벨의 취약점을 사전 조치
- Secure Coding 관행: OWASP Top 10 을 준수하여 로직 상의 취약점을 원천적으로 차단
- 컨테이너/서버리스 보안: 도커 이미지 취약점 스캐닝, 런타임 행위 모니터링, 쿠버네티스(Kubernetes) 오케스트레이션 보안 설정을 강화
5. 모니터링 및 위협 탐지(Monitoring & Threat Detection)
- 통합 로깅(Centralized Logging): API 호출 로그(CloudTrail), 네트워크 플로우 로그(VPC Flow Logs), OS 및 애플리케이션 로그를 변조 불가한 중앙 저장소로 수집
- SIEM 및 행위 기반 탐지: 수집된 로그를 바탕으로 비정상적인 행위 패턴을 실시간으로 분석하고 Alert 발생
- CSPM(Cloud Security Posture Management): 클라우드 인프라의 설정 오류나 컴플라이언스 위반사항을 지속적으로 자동 진단하고, 발견 시 자동 복구(Auto-Remediation) 파이프라인을 동작시킴.
NAT Gateway Traffic Flow
서칭하다가 https://aws-hyoh.tistory.com/184 해당 링크의 실무자 인터뷰를 보게 되었고, 정리하고 가면 좋을 것 같은 내용이라 정리함.
EC2 → NAT Gateway → Internet Gateway → Public Internet
- NAT G/W: 공인 IP를 갖지 않는 Private Subnet에 속한 EC2 등이 공인 인터넷에 접근 가능하도록 EC2의 사설 IP를 공인 IP로 Source IP NAT하는 역할을 함.
- 여기서 Source IP NAT가 무엇일까?
- NAT G/W 를 사용할 때 사설 IP를 공인 IP로 NAT 해주는 것은 Internet G/W.
- Internet G/W: AWS 내부에 실질적으로 공인 IP를 보유하고 이를 일대일 NAT하는 존재
1. Outbound 패킷 생성 (Private EC2)
- 출발지 IP: EC2의 사설 IP (ex. 10.0.1.5)
- 목적지 IP: 외부 웹서버의 공인 IP (ex. 8.8.8.8)
2. NAT Gateway 통과 (NAPT 기반 1차 SNAT)
- 라우팅 테이블에 따라 패킷이 NAT G/W에 전달되면, NAT G/W는 출발지 IP를 NAT G/W 자신의 사설 IP(ex. 10.0.0.10)로 변환
- 다수의 EC2가 하나의 NAT G/W를 공유해야 하므로 IP뿐 아니라 Source Port 도 임의의 포트로 변경하여 NAT State Table에 세션 정보를 기록. 이를 NAPT(Network Address Port Translation) 또는 PAT(Port Address Translation)이라고 부름.
3. Internet Gateway 통과 (1:1 Static NAT 기반 2차 SNAT)
- 패킷(출발지 IP: NAT G/W 사설 IP)이 IGW로 전달
- IGW는 내부적으로 매핑된 테이블을 확인하여 NAT G/W 사설 IP를 NAT G/W에 할당되어 있는 Elastic IP(공인 IP)로 1:1 주소 변환함
- 최종 출발지 IP: Elastic IP/ 목적지 IP: 8.8.8.8 형태로 Public Internet망을 타게 됨.
4. Inbound 응답 패킷 처리 (Stateful 기반 역변환)
- 통신은 양방향이기에 외부 서버에서 응답 패킷이 돌아올 때는 역순의 변환(DNAT) 발생
- IGW가 목적지 IP(Elastic IP)를 NAT G/W 사설 IP로 변환하여 내부로 들여보냄
- NAT G/W는 기존에 기록해둔 NAT State Table을 참조해, 목적지 IP와 포트를 원래 요청을 보냈던 EC2의 사설 IP와 원본 포트로 다시 변환해 인스턴스에 전달함.
서비스 모델에 따른 클라우드 보안 아키텍처
- IaaS(Infrastructure as a Service)
아파트를 임대하는 것. (구조는 제공되지만, 인테리어는 사용자가 직접 꾸밈)
저장소, 서버, 네트워크 같은 원자재 제공하지만 자산을 보호하는 것은 사용자의 책임.- Cloud SA에는 데이터 보호, 접근 제어 관리, 가상 네트워크 보호 등 포함됨
- PaaS(Platform as a Service)
가구가 갖춰진 아파트.
클라우드 공급자는 스택의 많은 부분 관리하며, 사용자는 애플리케이션과 데이터에 집중.- Cloud SA는 애플리케이션 계층 보안과 사용자 액세스 관리를 포함.
- SaaS(Software as a Service)
호텔 객실에 머무는 것.
클라우드 공급자가 보안의 상당 부분 처리- Cloud SA는 데이터 보안과 사용자 접근 제어에 집중.
클라우드 보안 아키텍처의 원칙
- 다중 계층 보안
- 심층 방어(defense in depth): 한 계층이 무너지더라도 바로 뒤에 다른 계층이 있어 방어 체계를 유지함. 이는 공격자가 클라우드 방어망을 뚫는 것을 어렵게 함.
- 방화벽, IDS, 데이터 암호화 프로토콜까지 여러 계층이 함께 작동함.
- 이런 계층적 접근 방식은 클라우드 내 데이터의 보안을 강화하고, 클라우드 보안 아키텍처의 핵심 부분을 구성함.
ex. 외부에서 웹 서버를 통해 DB로 접근하려는 공격
해결방안
1. L7: AWS WAF를 통해 SQL Injection 및 XSS 공격 페이로드 차단.
2. L3/L4(Network): Public 서브넷의 로드밸런서(ALB)에서 Private 서브넷의 EC2로만 트래픽이 흐르도록 보안 그룹(SG) 설정.
3. Data(Storage): RDS에 접근하는 EC2의 IAM Role을 검증하고, 저장된 데이터는 KMS로 암호화. 한 계층(ex. WAF 우회)이 뚫리더라도 SG나 IAM 정책에서 공격이 차단되도록 설계.
- 최소 권한 원칙(Least Privilege)
- 내용물에 접근할 특정 필요성이 있는 가장 신뢰할 수 있는 개인만이 열쇠를 가지게끔 할 것.
- 사용자가 자신의 업무를 수행하는 데 필요한 최소한의 접근 권한만을 부여하도록 권장함.
- 이를 통해 피해 가능성을 최소화할 수 있게 됨.
ex. 특정 애플리케이션 서버가 S3 버킷에 이미지를 업로드해야 하는 상황
해결방안
-> EC2 인스턴스에 AWS 액세스 키를 하드코딩하지 않고, IAM Role을 부여하여 임시 자격 증명을 사용하도록 설계. 정책 작성 시 리소스를Resource: "*"로 두지 않고,Resource: "arn:aws:s3:::specific-image-bucket/*"으로 한정하며s3:PutObject액션만 허용하도록 JSON 정책을 엄격하게 튜닝
- 업무 분리(Segregation of Duties)
- 견제와 균형 시스템과 유사하게 작동함.
- 어떤 개인이나 프로세스도 클라우드 환경의 어느 측면에 대해서도 절대적 통제권을 가지지 않도록 보장함.
- ex. 개발자가 그 코드를 검토하거나 승인하는 사람이 되어선 안됨. ⇒ 이런 분리는 잠재적인 오용을 방지하고 객관성을 부여할 수 있게 됨.
ex. 인프라를 코드로 배포(IaC)하는 개발자가 스스로 방화벽 정책까지 마음대로 변경하여 0.0.0.0/0 (Any) 포트를 여는 상황
해결방안
-> AWS Organizations SCP(Service Control Policy)를 적용하여, 개발 계정에서는 인프라 리소스 생성만 가능하게 하고, CloudTrail 로그 비활성화나 GuardDuty 설정 변경 등 핵심 보안 기능에 대한 통제권은 중앙 보안 계정(Security Account)에서만 다루도록 권한을 물리적/논리적으로 분리.
- 책임성 및 추적성
- 클라우드 내 모든 작업은 흔적을 남기고 특정 주체와 연결되어야 함.
- 철저한 감사, 책임성 강화, 신속성 사고 대응을 할 수 있게 됨.
ex. 랜섬웨어 감염 또는 내부자에 의한 대량의 고객 데이터 삭제(S3 버킷 삭제 등) 발생
해결방안
-> 인프라 설계 단계부터 모든 API 호출 로그(CloudTrail), 네트워크 트래픽 흐름(VPC Flow Logs), 시스템 로그를 중앙 집중형 로그 아카이브(Log Archive) 전용 계정의 S3 버킷으로 실시간 전송. 이 버킷은 Object Lock(Worm) 기능을 활성화하여 루트 관리자라도 로그를 위변조하거나 삭제할 수 없도록 구성하여 포렌식 조사 시 무결성을 보장.
- 설계 단계부터 고려된 보안(Security by Design)
- 보안은 사후 고려 사항이 아닌 시스템 설계 초기 단계부터 필수 요소로 포함.
- 클라우드 아키텍처에도 보안 조치가 처음부터 내재됨
- 이를 통해 포괄적이고 견고한 방어 체계를 구축 가능하며, 관리가 용이하고 오류 발생 가능성도 낮아짐.
ex. 런타임 환경에서 504 Gateway Timeout 같은 통신 장애나 보안 그룹 설정 누락이 발생하여 뒤늦게 디버깅하는 비용 낭비
해결방안
-> CI/CD 파이프라인에 보안 통제(DevSecOps) 통합. 예를 들어, Terraform으로 인프라를 배포하기 전, 파이프라인 내에서 정적 분석 도구(Checkov, tfsec 등) 실행. “SSH 포트가 전체 개방되어 있음” 혹은 “DB 암호화가 비활성화됨” 같은 룰 위반이 탐지되면, 배포 프로세스(빌드) 자체를 강제로 중단시켜 안전한 구조만 클라우드에 올라가도록 통제.
