클라우드 보안, 직접 털려보고 나서야 깨달은 AWS WAF와 IAM 핵심 설정 가이드

저는 30대 중반의 평범한 IT 기업 직장인입니다. 불과 6개월 전만 해도 "우리 회사처럼 작은 서비스에 누가 해킹을 하겠어?"라는 안일한 생각으로 클라우드를 운영하고 있었습니다. 그러던 어느 날 새벽, 갑자기 해외 IP로부터 수만 건의 비정상적인 트래픽이 몰려오면서 서버가 마비되는 대형 사고를 겪었습니다. 아침에 출근해 보니 수천만 원에 달하는 예상 요금 고지서와 서비스 먹통이라는 처참한 현실이 저를 기다리고 있었죠. 그날 이후 밤을 새워가며 클라우드 보안을 밑바닥부터 다시 공부했고, 대표적인 보안 서비스인 WAF와 IAM 설정을 뼈저리게 고쳤습니다. 저와 같은 뼈아픈 실수를 반복하지 않기를 바라는 마음으로, 클라우드 환경에서 반드시 구축해야 할 핵심 보안 설정 노하우를 공유합니다.

1. 웹 애플리케이션의 최전방 방패, WAF(Web Application Firewall) 완벽 이해

클라우드 보안의 시작은 외부에서 들어오는 악성 트래픽을 차단하는 것입니다. WAF는 일반적인 네트워크 방화벽과 달리 OSI 7계층(애플리케이션 계층)에서 동작하며, HTTP/HTTPS 프로토콜의 패킷을 상세히 분석합니다. 이를 통해 SQL 인젝션, 크로스 사이트 스크립팅(XSS), DDoS 공격 등 웹 취약점을 노린 공격을 효과적으로 방어할 수 있습니다.

실제 제가 경험해보니, WAF를 단순히 '켜두는 것'만으로는 아무런 효과가 없었습니다. AWS WAF를 예로 들면, 기본적으로 제공되는 AWS 관리형 규칙(Managed Rule Groups)을 반드시 활성화해야 합니다. 특히 핵심 취약점을 모아둔 Core Rule Set(CRS)과 익명 IP 및 봇 트래픽을 걸러내는 Amazon IP Reputation List는 무조건 적용하는 것을 추천합니다. 제 서비스의 경우, 이 두 가지 규칙만 먼저 켜두었어도 초기 새벽 공격의 90% 이상은 자동으로 방어할 수 있었다는 것을 나중에야 알게 되었습니다.

2. 최소 권한의 원칙을 실현하는 IAM(Identity and Access Management) 계정 관리

외부 공격만큼 무서운 것이 바로 '내부 통제 실패'입니다. IAM은 클라우드 자원에 대한 접근 권한을 관리하는 핵심 시스템입니다. 많은 주니어 엔지니어들이나 바쁜 스타트업에서는 편의상 모든 권한이 열려 있는 'Root 계정'을 공용으로 쓰거나, 개발자 전원에게 'AdministratorAccess' 권한을 부여하곤 합니다. 이는 언제 터질지 모르는 시한폭탄과 같습니다.

보안 사고 이후 저는 가장 먼저 모든 팀원의 개인 계정을 분리하고 '최소 권한의 원칙(Principle of Least Privilege)'을 적용했습니다. 개발자에게는 EC2 인스턴스를 수정할 수 있는 권한만 주고, 결제나 데이터베이스 삭제 권한은 철저히 격리했습니다. 또한, 아무리 권한이 낮은 계정이라 할지라도 MFA(멀티팩터 인증) 설정은 선택이 아닌 필수입니다. 스마트폰 앱(Google OTP 등)을 통한 2차 인증만 걸어두어도 계정 탈취로 인한 대형 클라우드 사고의 대부분을 원천 차단할 수 있습니다.

3. 보안 그룹(Security Group)과 NACL을 활용한 이중 네트워크 방어 전략

WAF가 애플리케이션 수준의 방어선이라면, 보안 그룹과 NACL(Network Access Control List)은 인프라 레벨의 울타리입니다. 이 둘의 가장 큰 차이점은 '상태 저장(Stateful)' 여부입니다. 보안 그룹은 상태 저장 방식으로 동작하므로 인바운드 규칙만 잘 설정하면 아웃바운드는 자동으로 허용됩니다. 반면 NACL은 상태 비저장(Stateless) 방식이기 때문에 들어오고 나가는 규칙을 모두 수동으로 제어해야 합니다.

당시 저는 보안 그룹의 22번(SSH) 포트를 0.0.0.0/0(모든 IP 허용)으로 열어두는 치명적인 실수를 저질렀습니다. 집이나 카페에서도 편하게 접속하겠다는 안일한 생각 때문이었죠. 해커들은 이 열려 있는 포트를 통해 Brute Force(무차별 대입) 공격을 시도했고, 결국 인스턴스 하나가 좀비 PC로 전락했습니다. 현재는 사내 고정 IP와 인벤토리 허용된 VPC 대역을 제외한 모든 외부 접근 포트를 완전히 차단한 상태입니다. 조금 불편하더라도 Bastion Host를 경유하거나 VPN을 통해서만 접근하도록 아키텍처를 전면 수정했습니다.

4. 데이터의 마지막 보루, KMS를 활용한 상시 암호화와 CloudTrail 로깅

만약 앞선 방어선들이 모두 뚫려 데이터베이스가 유출되는 최악의 상황이 오더라도, 데이터 자체를 읽을 수 없게 만드는 마지막 장치가 바로 암호화입니다. 클라우드에서는 AWS KMS(Key Management Service) 등을 통해 저장 데이터(Data at Rest)와 전송 중인 데이터(Data in Transit)를 손쉽게 암호화할 수 있습니다. S3 버킷이나 RDS 인스턴스를 생성할 때 암호화 체크박스 하나만 누르면 되는 간단한 작업임에도, 많은 사람들이 성능 저하를 우려해 건너뛰곤 합니다. 하지만 실제 벤치마크 결과, 최신 클라우드 환경에서 암호화로 인한 성능 저하는 사람이 체감하기 어려운 수준입니다.

이와 더불어 CloudTrail과 같은 감사 로그 서비스의 활성화는 필수적입니다. 클라우드 내에서 "누가, 언제, 어떤 API를 호출했는지"에 대한 모든 기록이 남기 때문에, 사고가 발생했을 때 원인을 추적하고 피해 범위를 파악하는 유일한 열쇠가 됩니다. 로그 데이터 자체를 해커가 변조하거나 삭제하지 못하도록 별도의 보안 S3 버킷에 저장하고 잠금(Object Lock)을 걸어두는 정교함이 필요합니다.

5. 뼈아픈 시행착오: 모니터링과 경보(Alarm) 시스템 부재의 대가

보안 설정을 아무리 완벽하게 해두어도, 시스템이 보내는 경고 시그널을 사람이 인지하지 못하면 무용지물입니다. 제가 당했던 해킹 사고가 수천만 원의 과금으로 이어졌던 결정적인 이유는 '비정상 요금 경보'를 설정하지 않았기 때문입니다. 해커들이 제 계정 권한을 탈취해 해외 리전에 최고 사양의 그래픽카드(GPU) 인스턴스 수십 대를 띄워 암호화폐를 채굴하는 동안, 저는 퇴근 후 잠을 자고 있었습니다.

사후 수습을 진행하며 AWS Budgets와 CloudWatch를 연동하여 평소 요금의 120%가 넘어가거나, 평상시 트래픽의 3배 이상이 치솟을 경우 즉시 제 개인 스마트폰과 사내 슬랙(Slack) 채널로 긴급 알림이 오도록 조치했습니다. 소 잃고 외양간 고친 격이었지만, 이 모니터링 체계를 구축한 덕분에 3개월 후 발생한 소규모 스캐닝 공격 때는 단 5분 만에 IP를 차단하여 추가 피해를 완벽히 막아낼 수 있었습니다.

안전한 클라우드 운영을 위한 필수 보안 체크리스트

  • Root 계정 사용 중단 및 MFA 설정: 루트 계정은 자물쇠로 잠그고, 모든 관리는 IAM 개별 계정과 2차 인증을 통할 것.
  • WAF 기본 규칙 그룹 활성화: OWASP Top 10 공격 방어를 위한 Core Rule Set 및 봇 제어 규칙 무조건 적용하기.
  • 원격 접속 포트(22, 3389) 오픈 제한: 0.0.0.0/0 개방은 자살 행위와 같음. 반드시 특정 IP 대역이나 VPN으로 제한할 것.
  • 클라우드 요금 및 트래픽 알람 설정: 일일 요금 임계치 초과 및 트래픽 급증 시 SMS/이메일 즉시 발송 구조 만들기.
  • 정기적인 액세스 키(Access Key) 로테이션: 소스코드나 깃허브(GitHub)에 실수로 키가 유출되는 사고를 막기 위해 최소 90일 주기로 갱신할 것.

마치며: 보안은 비용이 아니라 미래를 위한 가장 확실한 투자입니다

해킹 사고를 수습하는 몇 주 동안 극심한 스트레스로 탈모 증상까지 겪었고, 회사 경영진과 고객사들에게 고개 숙여 사과하며 엔지니어로서 깊은 자괴감에 빠졌었습니다. 하지만 이 고통스러운 경험을 통해 클라우드 보안은 '나중에 여유 있을 때 하는 것'이 아니라, '서비스 시작과 동시에 가장 먼저 구축해야 하는 주춧돌'이라는 진리를 깨달았습니다. 기술의 발전으로 해커들의 공격 방식은 날로 정교해지고 있습니다. 오늘 당장 여러분이 운영 중인 클라우드 콘솔에 로그인하여 IAM 설정과 WAF 규칙을 점검해 보세요. 지금 투자하는 단 10분의 시간이, 미래의 수천만 원과 회사의 신뢰도를 지키는 가장 현명한 선택이 될 것입니다.

본 글에 포함된 기술적 설정 및 아키텍처는 작성자의 개인적인 경험과 지식을 바탕으로 작성되었으며, 클라우드 서비스 제공사(CSP)의 업데이트 및 개별 시스템 환경에 따라 실제 적용 결과가 다를 수 있습니다. 시스템 적용 전 반드시 테스트 환경에서 검증을 거치시기 바랍니다.