pile·
보안·스캐터랩스캐터랩 (이루다)·

개발자를 위한 AWS 클라우드 보안 (3) - 인프라 보안과 사고 대응

AWS Well-Architected Framework의 보안 원칙을 실제 인프라에 적용한 시리즈 마지막 편이다. VPC와 서브넷 분리, 방화벽, IaC, 컨테이너 이미지 스캔을 거쳐 침해사고 대응 조직과 프로세스까지 연결한다. 개별 AWS 기능보다 네트워크 설계와 운영 절차를 하나의 방어 체계로 묶는 방법이 핵심이다.

핵심 포인트
  • Public·Private·DB 서브넷을 분리하고 여러 AZ에 백엔드를 배치해 외부 노출과 단일 장애 영역의 영향을 줄인다.
  • Network ACL은 서브넷 단위 stateless 방화벽이고 Security Group은 인스턴스 단위 stateful 방화벽이므로 적용 범위와 응답 규칙이 다르다.
  • VPC가 적을 때는 Peering이 단순하고, 4개 이상으로 연결 관리가 복잡해지면 Transit Gateway를 검토하되 트래픽 비용을 계산해야 한다.
  • WAF, Network Firewall, Shield는 각각 애플리케이션 공격, 네트워크 계층 위협, DDoS를 다른 수준에서 방어한다.
  • Terraform으로 VPC 관련 수백 개 리소스를 약 50줄의 모듈 코드로 관리했고, ECR 스캔 결과는 EventBridge와 Lambda를 거쳐 Slack으로 알렸다.
  • 사고 대응은 탐지 도구만이 아니라 의사 결정 조직, 담당자, 초기 대응 시나리오, 복구와 재발 방지 절차까지 준비해야 한다.
상세 정리
  • VPC 설계: 팀 간 통신, 다중 계정, 다중 리전, 예상 인스턴스 수, 망 분리 요구를 먼저 확인한다. VPC와 서브넷은 변경 비용이 커서 현재 구성만 보고 결정하면 안 된다.
  • 가용성: 서로 다른 AZ의 서브넷에 백엔드를 두고 ALB로 분산해 한 AZ 장애 시 다른 AZ가 트래픽을 처리하도록 했다.
  • 노출 최소화: 외부 진입점은 Public 서브넷에 두고 서비스는 Private 서브넷에 배치한다. Private 자원의 외부 요청은 NAT Gateway를 통하며, 민감 DB는 Private을 통해서만 닿는 별도 DB 서브넷에 둘 수 있다.
  • 접근 제어: Network ACL은 inbound와 outbound를 모두 명시해야 한다. Security Group은 응답 트래픽을 자동 허용하며, 공통 80·443 규칙처럼 재사용 가능한 그룹으로 수를 통제한다.
  • 중앙 관리: 보안 담당자가 Security Group을 미리 만들고 IAM이나 Control Tower Guardrails로 생성을 제한하는 것이 이상적이다. 작은 조직은 일부 담당자만 생성하게 하고 변경 내역을 문서화하는 방식으로 균형을 잡을 수 있다.
  • VPC 연결: Peering은 VPC 사이를 각각 연결해야 하지만 Transit Gateway는 허브에 붙은 VPC를 연결한다. Peering은 일반 네트워크 요금, Transit Gateway는 통과 트래픽 요금이 적용된다.
  • 다중 계정: Resource Access Manager로 중앙 계정의 서브넷을 다른 계정에 공유한다. 공유받은 계정은 서브넷 설정을 바꿀 수 없게 하고 VPC 생성 권한도 제한하는 구조를 권장한다.
  • 계층별 방어: AWS WAF의 관리형 규칙으로 SQL Injection과 XSS를 막고, Network Firewall로 IP 차단 같은 낮은 계층 규칙을 적용한다. Shield Standard는 기본 제공되며 Advanced는 월 3,000달러에 대응팀 지원과 비용 보호를 더한다.
  • IaC: 계정마다 VPC, 라우팅 테이블, NAT·Internet Gateway, RAM 공유를 수작업으로 만들지 않고 Terraform 모듈로 재현했다. 리전 변경이나 신규 서비스에도 같은 구성을 빠르게 적용할 수 있었다.
  • 컨테이너 보안: ECR scan on push로 알려진 취약점을 검사하고 EventBridge·Lambda로 결과를 Slack에 전송했다. 설정이 빠진 저장소는 Guardrails나 AWS Config로 탐지한다.
  • 사고 대응: 정보보호위원회, 보안 조직, 실제 대응팀, 교육 담당을 구분한다. 준비 단계에서 자산 중요도와 사고 유형별 담당자를 정하고, 탐지 후 조직에 전파·전략 수립·원인 분석·복구·모니터링 보강 순으로 진행한다.
왜 읽나AWS에서 네트워크와 보안 서비스를 나열하는 수준을 넘어 예방·탐지·복구가 이어지는 운영 체계를 설계하려는 인프라 엔지니어에게 유용하다.
스캐터랩
스캐터랩 (이루다) 블로그
원문은 여기서 이어서 읽을 수 있어요
원문 읽기
읽음 (0)

이 글과 비슷한

  1. 보안·cloudflare-blogCloudflare Blog·

    오리진 서버 포스트 퀀텀 인증 지원 — ML-DSA mTLS 구현기

    Cloudflare가 오리진 서버와의 TLS 연결에 포스트 퀀텀 인증(ML-DSA)을 도입했다. 2023년 이미 포스트 퀀텀 암호화(encryption)가 배포됐지만, 인증(authentication)은 여전히 양자 공격에 취약한 상태였다. Authenticated Origin Pulls(AOP)와 Custom Origin Trust Store(COTS) 두 제품을 통해 완전한 상호 인증 TLS를 구현했으며, FIPS 204(ML-DSA) 표준을 오리진 연결에 적용한 첫 번째 마일스톤이다.

    #mtls#tls#post-quantum+2