[SK shieldus Rookies 29기] 30일차

오늘은 수업은 진행하긴 했는데 중간에 짜르면서 수업을 진행하셔서 내가 그냥 다 같이 붙여버린 내용들을 하필 해버렸다. 따라서 오늘 딱히 적을 말이 없다.... 실습을 진행하기는 했지만 혼자 뚜닥뚜닥 이것저것 만들어보는게 최고다.

그래서 그냥 내가 옛날에 했던 실습을 올리려고 한다.

AWS 콘솔 기반 다층 보안 인프라 구축 - Zero Trust 모델 구현

1. 프로젝트 개요 및 워크플로우 설계

1.1 프로젝트 선정 배경 및 목표

현대 사이버 위협 환경 분석: 클라우드 전환은 더 이상 선택이 아닌 필수지만, 이는 새로운 차원의 보안 위협을 동반합니다. 2024년과 2025년의 주요 보안 보고서들은 클라우드 침해 사고가 '증가'하는 수준을 넘어 '보편화'되고 있음을 명확히 보여줍니다.

• 클라우드 침해의 보편화: Exabeam의 2025년 보고서에 따르면, 지난 1년간 조직의 80%가 클라우드 보안 사고를 경험했습니다 [출처: Exabeam, 2025 Cloud Security Statistics]. 이는 더 이상 클라우드 보안이 일부 조직의 문제가 아님을 시사합니다.

이러한 침해 사고의 근본 원인은 두 가지 핵심 위협 벡터로 요약됩니다.

1. 클라우드 설정 오류 (Misconfiguration): 가장 치명적이며 빈번한 위협입니다. 클라우드 서비스 제공자(CSP)의 인프라가 아닌, 사용자의 설정 실수(Human Error)가 모든 문제의 근원입니다. 세계적인 리서치 기관 Gartner는 2025년까지 발생하는 클라우드 보안 사고의 99%가 고객(사용자)의 설정 오류로 인해 발생할 것이라고 예측했습니다 [출처: Gartner, 2024] . 이는 방화벽 포트 개방, IAM 권한 과다 부여, S3 버킷 공개 등 기본적인 보안 구성(CSPM) 관리가 얼마나 중요한지 강조합니다.
2. 공급망 및 제3자 공격 (Supply Chain Attack): 조직의 방어 체계를 직접 뚫는 대신, 신뢰할 수 있는 협력사나 서드파티 소프트웨어를 통해 침투하는 공격이 급증하고 있습니다. Verizon의 2024년 데이터 침해 조사 보고서(DBIR)에 따르면, 전체 침해 사고의 15%가 공급망과 같은 제3자 파트너를 통해 발생했으며, 이는 전년 대비 68% 증가한 수치입니다 [출처: Verizon, 2024 DBIR] .

• 국내 공공 부문의 명확한 기술 요구사항 (KISA 사례):
  이러한 글로벌 위협 동향은 국내 공공 부문에서도 가장 시급한 과제로 인식되고 있습니다. 특히, 2025년 9월 22일 자로 조달청 나라장터에 공고된 KISA(한국인터넷진흥원)의 30억 3천만 원 규모 '종합상황관제시스템 보안 강화 및 인프라 개선' 사업은 이러한 시장의 요구를 명확하게 보여줍니다 [[출처: 조달청 나라장터, 2025.09.22 공고]].

  본 사업 공고문에서 제시된 핵심 과업은 다음과 같습니다.

1. 보안관제 데이터 처리 효율성 강화 (Cloud-Native SIEM/SOC)
2. 클라우드 전환 안정성 확보 (CSPM & Secure Migration)
3. 재해복구 및 백업 체계 강화 (Multi-AZ & Resilience)
4. 위기 대응 자동화 구현 (SOAR)

이러한 경계 없는 위협 환경은 '절대 신뢰하지 않고, 항상 검증하는' Zero Trust 모델의 도입을 필수 과제로 만들고 있습니다.

개인 목표 및 시장 요구 매칭:

• 기술 확장: 본 프로젝트는 기존의 온프레미스(On-premise) 환경에서 Rocky Linux 기반 SIEM/IDS 랩을 구축(ELK Stack, Suricata)했던 경험을 확장하는 것을 목표로 합니다. KISA가 요구하는 '보안관제 데이터 처리 효율성'을 달성하기 위해, 인프라 관리 부담이 컸던 온프레미스 방식에서 벗어나, AWS 네이티브 보안 서비스를 활용한 클라우드 네이티브 SOC 아키텍처로 전문성을 전환합니다.
• 역량 증명:
  목표로 하는 '클라우드 보안 컨설팅' 직무에 필요한 역량을 증명합니다. 이는 Gartner가 지적한 '설정 오류' 문제를 해결하는 CSPM(클라우드 보안 형상 관리) 역량과, KISA가 추진하는 '클라우드 전환 안정성' 및 위기 대응 자동화'를 실제로 구현할 수 있는 다층 방어((VPC, 보안 그룹, 로드밸런싱, 모니터링, 자동화)) 설계 및 자동화 실무 역량입니다.

1.2 기술 스택 선정 이유

본 프로젝트는 서드파티 솔루션의 운영 부담을 최소화하고, AWS 생태계 내에서 가장 강력한 통합 보안을 구현하기 위해 AWS 네이티브 서비스를 중심으로 기술 스택을 선정했습니다.

• 기반 인프라 (IaaS):
  • Amazon VPC, Subnets, NAT Gateway, ALB: 다중 AZ 고가용성, 명확한 네트워크 세분화(Segmentation), 안전한 트래픽 분산을 위한 핵심 구성요소입니다.
  • Amazon EC2: 워크로드(웹 서버) 및 안전한 접근 통로(배스천 호스트) 배포를 위한 유연한 컴퓨팅 리소스입니다.
• 보안 및 형상 관리 (CSPM / CWPP):
  • 보안 그룹 (Security Groups): 인스턴스 레벨에서 Zero Trust의 '최소 권한 원칙'을 구현하는 상태 저장 방화벽입니다. IP 하드코딩 대신 동적 ID 참조 방식을 사용하여 아키텍처의 유연성을 확보합니다.
  • Amazon GuardDuty: 별도 에이전트 없이 VPC Flow Logs, CloudTrail, DNS 로그를 분석하여 악성 행위를 탐지하는 지능형 위협 탐지(CWPP) 서비스입니다.
  • AWS Security Hub: 계정 전반의 보안 표준(예: CIS 벤치마크) 준수 여부를 확인하고, 여러 서비스의 보안 알림을 중앙에서 집계하는 CSPM의 핵심입니다. Gartner는 클라우드 보안 형상 관리(CSPM)를 클라우드 보안 지출의 핵심 동인으로 분석하며 [출처: Gartner, 2025.07.29] , 본 스택의 당위성을 뒷받침합니다.
• 감사 및 모니터링 (Logging & Monitoring):
  • AWS CloudTrail: 모든 API 호출을 기록하여 '누가, 무엇을, 언제' 수행했는지 추적하는 불변의 감사 로그입니다.
  • Amazon CloudWatch: 실시간 인프라 성능 지표를 모니터링하고 임계값 기반 경보를 생성하여 운영 안정성을 확보합니다.

1.3 전체 워크플로우 다이어그램

전체 구조도

)

2. Phase 1-3

2.1 Phase 1. 네트워크 기반

ⅰ) VPC 네트워크 아키텍처

전체 인프라 개요

주요 구성 요소:

• VPC: security-vpc (10.0.0.0/16)
• 다중 가용 영역: ap-northeast-2a, ap-northeast-2c
• 퍼블릭 서브넷 2개, 프라이빗 서브넷 2개
• 고가용성 NAT Gateway (각 AZ별 1개씩)

현재 구축된 인프라는 Zero Trust 보안 모델을 기반으로 하여 네트워크 레벨에서 완전한 격리와 세밀한 접근 제어를 구현하였습니다. 특히 다중 AZ 구성을 통해 99.9% 이상의 고가용성을 보장하며, 자연재해나 AZ 장애 시에도 서비스 연속성을 확보할 수 있습니다.

ⅱ) VPC 및 네트워크 설계 단계

• VPC: security-vpc (10.0.0.0/16)
• 설계 원칙: Zero Trust 보안 모델을 기반으로 네트워크 레벨에서 완전한 격리와 세밀한 접근 제어를 구현했습니다.

ⅲ) 서브넷 분할 및 가용성 구성

• 가용 영역: ap-northeast-2a, ap-northeast-2c (다중 AZ 고가용성)
• 서브넷: 퍼블릭 서브넷 2개, 프라이빗 서브넷 2개
• 고가용성 보장: 다중 AZ 구성을 통해 99.9% 이상의 가용성을 보장하며, 자연재해나 AZ 장애 시에도 서비스 연속성을 확보할 수 있습니다.
• public01-subnet-2a Set ScreenShot
  
  
  

• public02-subnet-2c Set ScreenShot
  
  
  

• private01-subnet-2a Set ScreenShot
  
  
  

• private02-subnet-2c Set ScreenShot
  
  
  

ⅳ) 라우팅 테이블 및 NAT Gateway 구성

• 게이트웨이: 고가용성 NAT Gateway (각 AZ별 1개씩)
  • NAT Gateway 01 (ap-northeast-2a): EIP 52.79.231.1
  • NAT Gateway 02 (ap-northeast-2c): EIP 3.35.114.234
• 라우팅: 각 프라이빗 서브넷은 동일 AZ 내 NAT Gateway를 통해서만 인터넷에 접근하도록 라우팅 테이블을 구성하여 단일 장애점(SPOF)을 제거했습니다.
• public-rt Set ScreenShot
  
  

• private-rt-2a Set ScreenShot
  
  

• privat-rt-2c Set ScreenShot
  
  

• 탄력적 IP Set ScreenShot
  
  

• ngw-01 Set ScreenShot
  

• ngw-02 Set ScreenShot
  

ⅴ) 네트워크 연결성 검증

• 검증: 프라이빗 서브넷의 인스턴스에서 아웃바운드(e.g., OS 업데이트) 통신이 NAT Gateway를 통해 정상적으로 수행됨을 확인했습니다. 이는 엔터프라이즈 환경의 고가용성 설계 원칙을 정확히 준수한 것입니다.
  
  

2.2 Phase 2: Zero Trust 보안 계층 구현

ⅰ) 1차 방어선 (서브넷): 네트워크 ACL (NACL) 설계

• NACL은 서브넷 수준에서 동작하는 Stateless(상태 비저장) 방화벽입니다. 이는 서브넷의 '외부 성벽' 역할을 하며, 주로 광범위한 트래픽(e.g., 특정 악성 IP 대역 전체 차단)을 1차적으로 필터링합니다.
• 기술적 특징 (Stateless): Stateless 특성상, 인바운드 트래픽에 대한 아웃바운드 응답 트래픽을 명시적으로 허용해야 합니다. 예를 들어, 외부의 HTTP(80) 요청을 허용했다면, 내부에서 외부로 나가는 임시 포트(Ephemeral Ports, 1024-65535)도 아웃바운드 규칙으로 허용해야만 응답이 정상적으로 전달됩니다.
• 적용: 프라이빗 서브넷의 경우, NACL 인바운드 규칙에서 0.0.0.0/0로부터의 SSH(22) 접근을 DENY하여, 설령 2차 방어선(SG)에서 실수로 허용하더라도 1차에서 원천 차단하도록 설계했습니다.

ⅱ) 2차 방어선 (인스턴스): 보안 그룹 (SG) 설계 방법론

• 보안 그룹(SG)은 인스턴스 수준에서 동작하는 Stateful(상태 저장) 방화벽입니다. 이는 인스턴스의 '방문' 역할을 하며, NACL을 통과한 트래픽에 대해 세밀한 접근 제어를 수행합니다.
• 기술적 특징 (Stateful): NACL과 달리, 인바운드 요청(e.g, TCP/80)이 허용되면 해당 세션의 아웃바운드 응답 트래픽은 자동으로 허용됩니다.
• IP 하드코딩 지양: 동적 보안 그룹 ID 참조
  • 정적 IP 주소 대신 동적 보안 그룹 ID 참조 방식을 채택했습니다.
  • 기술적 의의: 이는 인스턴스의 IP가 변경되거나 Auto Scaling으로 확장/축소될 때도 보안 정책이 동적으로 유지되도록 합니다. 즉, 인프라의 확장성(Scalability)과 보안 정책의 유연성(Flexibility)을 동시에 확보하는 클라우드 네이티브 설계의 핵심입니다.

ⅲ) 동적 보안 구현 참조

두 방어선(NACL, SG)에 '최소 권한 원칙'을 적용하여, 각 계층(ALB, Web, DB, Bastion)은 명시적으로 허용된 트래픽 외에는 모든 접근을 차단합니다.

NACL (프라이빗 서브넷 기준)

• 인바운드:
  • ALLOW (Source: ALB 서브넷 CIDR, Port: 80, 443)
  • ALLOW (Source: Bastion 서브넷 CIDR, Port: 22)
  • DENY (Source: 0.0.0.0/0, Port: 22) - SG보다 우선 차단
• 아웃바운드:
  • ALLOW (Destination: 0.0.0.0/0, Port: 1024-65535) - Stateless 응답
  • ALLOW (Destination: 0.0.0.0/0, Port: 80, 443) - OS 패치용

보안 그룹 계층 구조:

• ALB 보안 그룹 (sg-0df5838e0bc80a371)

  • 인바운드: HTTP(80), HTTPS(443) ← 0.0.0.0/0
  • 아웃바운드: HTTP(80), HTTPS(443) → 웹서버 보안 그룹 ID

• 웹서버 보안 그룹 (sg-047377d25f792b4b4)

  • 인바운드: HTTP(80), HTTPS(443) ← ALB 보안 그룹 ID
  • 인바운드: SSH(22) ← 관리자 IP
  • 아웃바운드: MySQL(3306) → 데이터베이스 보안 그룹 ID

• 배스천 호스트 보안 그룹 (sg-05023f58fd5e65a5d)

  • 인바운드: SSH(22) ← 관리자 IP
  • 아웃바운드: SSH(22) → 데이터베이스 보안 그룹 ID

• 데이터베이스 보안 그룹 (sg-0c473f19b03ba48e0)

  • 인바운드: MySQL(3306) ← 웹서버 보안 그룹 ID
  • 인바운드: SSH(22) ← 배스천 보안 그룹 ID

• public-nacl-secure Set ScreenShot
  ))

• private-nacl-secure Set ScreenShot
  ))

• ALB-Security-group Set ScreenShot
  )

• bastion-sg-secure Set ScreenShot
  )

• Web-Server-Security-group Set ScreenShot
  )

• database-sg-secure Set ScreenShot
  )

• wev-server-sg-secure Set ScreenShot
  )

ⅳ) 테스트

)))

2.3 Phase 3: 애플리케이션 계층 및 로드밸런싱

ⅰ) EC2 인스턴스 배포 전략

• Web Server: Amazon Linux 2 (t2.micro)
• Bastion Host: Amazon Linux 2 (t2.micro)
• Database Server: Amazon Linux 2 (t2.micro)
• 자동화: 모든 인스턴스는 사용자 데이터 스크립트(User Data)를 통해 자동화된 초기 설정을 구현하였으며, 이는 Infrastructure as Code의 기초 단계로서 향후 Terraform 전환 시 중요한 기반이 됩니다.
• 인스턴스 Set ScreenShot
  )))

ⅱ) Application Load Balancer 구성

• 인터넷(0.0.0.0/0)으로부터의 HTTP(80), HTTPS(443) 트래픽을 수신하여 웹서버 보안 그룹으로 전달하도록 리스너 및 라우팅 규칙을 구성했습니다.
• ALB Set ScreenShot
  

ⅲ) 대상 그룹 및 헬스체크 설정

• ALB가 웹서버 인스턴스의 상태를 주기적으로 점검하도록 대상 그룹 및 헬스체크 경로(e.g., /index.html)를 설정했습니다.
• Set ScreenShot
  

4.4 문제 해결 과정 (ALB Unhealthy → Healthy)

• 프로젝트 진행 중 발생한 ALB 대상 그룹 Unhealthy 상태는 실제 실무에서 빈번히 발생하는 문제로, 이를 체계적으로 해결한 과정은 포트폴리오의 핵심 차별화 요소입니다.

• 문제 진단 과정:

  1. AWS CLI를 통한 대상 그룹 상태 확인 (Request timed out 확인)
  2. 보안 그룹 규칙 상세 분석 (ALB 아웃바운드, 웹서버 인바운드)
  3. 보안 그룹 ID 불일치 문제 발견 (ALB가 잘못된 SG ID를 참조)
  4. 정확한 웹서버 보안 그룹 ID (sg-047377d25f792b4b4)로 참조 수정
  5. Healthy 상태 달성 및 검증

• 이러한 문제 해결 과정은 실무에서 요구되는 체계적 분석 능력과 AWS CLI 활용 역량을 구체적으로 입증합니다.

• Healthy Set ScreenShot
  

3. Phase 4: 보안 모니터링 및 감사 체계

ⅰ) GuardDuty 위협 탐지 활성화

• GuardDuty를 활성화하여 12개 데이터 소스를 통한 포괄적 위협 탐지를 수행합니다:
  • CloudTrail 이벤트 로그 분석
  • VPC Flow Logs 네트워크 트래픽 분석
  • DNS 쿼리 로그 악성 도메인 탐지
  • S3 데이터 이벤트 로그 분석

ⅱ) CloudTrail 감사 로깅 구성

• 모든 AWS API 호출에 대한 완전한 감사 추적을 활성화했습니다.
• 로그 파일의 무결성 보장 및 장기 보관을 위해 S3 버킷을 통한 안전한 로그 저장을 구성했습니다.
• CloudWatch Logs와의 통합을 통해 특정 이벤트(e.g., 보안 그룹 변경)에 대한 실시간 분석 및 알림 기반을 마련했습니다.

ⅲ) CloudWatch 모니터링 및 알림

• CloudWatch 알림: 배스천 호스트의 CPU 사용률이 30%를 초과할 경우, 즉시 SNS(Simple Notification Service)를 통해 이메일 알림이 발송되도록 구성했습니다.

ⅳ) 실시간 보안 이벤트 검증

• CPU 스트레스 테스트 결과:

  • 테스트 명령: stress --cpu 1 --timeout 600
  • 모니터링 결과: 배스천 호스트 CPU 사용률 35% 급증
  • 알림 수신: 임계값 초과 즉시 설정된 이메일로 실제 알림 수신 확인

• 이는 실무 환경에서의 실시간 모니터링 및 알림 체계가 정상적으로 작동함을 검증하는 중요한 증거입니다.

• GuardDuty
  

• CloudWatch
  

• 이메일 알림
  

3. 문제 해결(Troublshooting)

문제 1: ALB 대상 그룹 Unhealthy 상태

1. 증상 (Symptom):

• ALB 대상 그룹 상태: Unhealthy
• 세부 정보: Request timed out
• 의미: ALB가 웹 서버 인스턴스로 헬스 체크 요청을 보냈으나, 응답을 받지 못해 연결 시간이 초과되었습니다.

2. 1차 진단 (일반적인 함정 - Human Error):

• 초기 가설 (Human Error): 가장 흔한 실수인 웹 서버의 인바운드(Inbound) 규칙 오류로 판단했습니다.
• 1차 검증: web-server-sg(sg-047...)의 인바운드 규칙을 확인.
• 1차 결과: alb-sg(sg-048...)로부터 TCP/80 포트를 허용하는 규칙이 정상적으로 설정되어 있었습니다.
• 분석: 이 '휴먼 에러'는 보안 그룹의 Stateful(상태 저장) 특성만 고려하고, 헬스 체크가 "새로운 연결"이라는 사실을 간과한 데서 비롯되었습니다.

3. 2차 진단 (Root Cause 식별):

• 새로운 가설: 헬스 체크는 ALB가 인스턴스로 "새로운 연결을 시작(Initiate)"하는 행위입니다. 따라서, 웹 서버의 인바운드 규칙뿐만 아니라, ALB 보안 그룹의 아웃바운드(Outbound) 규칙이 이 연결을 허용해야 합니다.
• 2차 검증: alb-sg(sg-048...)의 아웃바운드(Egress) 규칙을 확인.
• 원인 발견: 초기 구성 시의 '휴먼 에러'로 인해, alb-sg에서 web-server-sg로 나가는 TCP/80 아웃바운드 규칙이 누락되어 있었습니다.

4. 해결 (Resolution):

• 조치: alb-sg가 web-server-sg로 TCP/80 헬스 체크 요청을 보낼 수 있도록 아웃바운드(Egress) 규칙을 명시적으로 추가했습니다.

원인 요약:

• ALB 아웃바운드 규칙이 잘못된 보안 그룹 참조
• 실제 웹서버 보안 그룹: sg-047377d25f792b4b4
• ALB 아웃바운드 대상: sg-0489552e6ab999eaf (잘못된 그룹)

해결 과정:

# 기존 잘못된 아웃바운드 규칙 제거
aws ec2 revoke-security-group-egress \
  --group-id sg-0489552e6ab999eaf \
  --protocol tcp \
  --port 80 \
  --destination-group sg-0489552e6ab999eaf \
  --region ap-northeast-2

# 올바른 웹서버 보안 그룹으로 규칙 추가
aws ec2 authorize-security-group-egress \
  --group-id sg-0489552e6ab999eaf \
  --protocol tcp \
  --port 80 \
  --destination-group sg-047377d25f792b4b4  \
  --region ap-northeast-2

# 대상 그룹 상태 재확인
aws elbv2 describe-target-health \
  --target-group-arn arn:aws:elasticloadbalancing:ap-northeast-2:449476173376:targetgroup/web-server-target-group/a27e4f055d5d9077 \
  --region ap-northeast-2
# 결과: "TargetHealth": {"State": "healthy"}

5. 검증 (Verification):

• 위 명령어 실행 후 약 1~2분 뒤, ALB 대상 그룹의 모든 인스턴스가 Healthy 상태로 전환되었습니다.
• 핵심 교훈(Takeaway): 이 '휴먼 에러' 해결 과정은, 보안 그룹의 Stateful/Stateless 특성(새로운 연결은 Egress 규칙 필요)을 명확히 이해하고, AWS CLI를 통해 체계적으로 인프라 문제를 진단 및 수정할 수 있는 역량을 경험했습니다.