보안 서비스는 각자 막는 위협이 다르다. 이름을 외우기보다 "무슨 위협 담당인가"를 한 줄씩 잡는 것이 시험에 훨씬 유리하다.
WAF는 요청의 내용(SQL 인젝션·XSS 같은 L7 웹 공격)을, Shield는 요청의 물량(DDoS)을 막는다.
GuardDuty는 "지금 수상한 일이 벌어지는가"를 로그로 탐지하고, Inspector는 "공격당하기 쉬운 약점이 있는가"를 미리 점검한다.
Macie는 S3 안의 민감 데이터(개인정보 등)를 찾아 분류한다 — 데이터 자체가 대상인 유일한 서비스다.
Security Hub는 위 서비스들의 결과를 한 화면에 모으는 통합 대시보드다. 직접 탐지하는 서비스가 아니다.
어제 IAM으로 "누가 무엇을 할 수 있는가"를 정했다. 하지만 권한 관리만으로 모든 위협을 막을 수는 없다. 외부에서 들어오는 공격 트래픽, 몰래 숨어든 악성 행위, 패치되지 않은 취약점, 실수로 노출된 민감 데이터 — 각각을 전담하는 보안 서비스들이 따로 있다.
오늘 다룰 서비스는 여섯 개다. WAF, Shield, GuardDuty, Inspector, Macie, Security Hub. 이름이 비슷비슷해서 처음엔 헷갈리지만, "무슨 위협을 다루는가"를 한 줄씩 잡아두면 시험에서 시나리오만 봐도 답이 떠오른다. CLF 시험은 깊은 설정이 아니라 "이 상황엔 이 서비스"라는 매칭을 묻기 때문이다.
처음 목록을 보면 "하나로 통합해서 팔지, 왜 여섯 개로 쪼갰나" 싶다. 이유는 간단하다. 막아야 할 것이 서로 완전히 다른 종류이기 때문이다.
집 한 채를 지킨다고 생각해본다. 대문 앞에서 수상한 사람을 걸러내는 문지기가 필요하고, 한꺼번에 수백 명이 몰려와 대문을 막아버릴 때를 대비한 인파 통제도 필요하다. 집 안에는 평소와 다른 움직임을 살피는 CCTV가 있어야 하고, 창문 잠금장치가 헐거워지지 않았는지 확인하는 정기 점검도 해야 한다. 서랍 어딘가에 신분증 사본을 방치하지 않았는지도 살펴야 하고, 이 모든 알림을 한 화면에 모아줄 관제 모니터도 있어야 한다.
AWS 보안 서비스 여섯 개가 정확히 이 여섯 가지와 대응한다.
집을 지키는 장치
AWS 서비스
대문 문지기 (수상한 사람 걸러내기)
WAF
인파 통제 (한꺼번에 몰려올 때)
Shield
집 안 CCTV (평소와 다른 움직임)
GuardDuty
정기 안전 점검 (헐거운 잠금장치)
Inspector
방치된 개인정보 찾기
Macie
관제 모니터 (알림 통합)
Security Hub
보안 장치는 크게 예방(Preventive)과 탐지(Detective) 두 부류로 나뉜다. 예방은 나쁜 일이 벌어지기 전에 막는 것(문지기, 인파 통제)이고, 탐지는 이미 벌어졌거나 벌어지는 중인 일을 발견하는 것(CCTV, 안전 점검)이다. 예방만으로는 부족하다 — 모든 공격을 미리 알 수는 없기 때문이다. 그래서 두 부류를 함께 쓴다.
AWS WAF(Web Application Firewall)는 웹 애플리케이션을 노린 공격을 막는다. SQL 인젝션, 크로스 사이트 스크립팅(XSS) 같은 레이어 7(애플리케이션 계층) 공격을 필터링한다. 규칙을 정의해 특정 패턴의 요청을 차단하거나, 특정 IP·국가를 막을 수 있다.
흔히 CloudFront, Application Load Balancer, API Gateway 앞단에 붙여 들어오는 HTTP/HTTPS 요청을 검사한다.
SQL 인젝션 — 아이디 입력란에 아이디 대신 데이터베이스에게 보내는 명령을 적어 넣는 공격. 잘못 만든 웹사이트는 이걸 명령으로 알아듣고 회원 정보를 내주기도 한다.
크로스 사이트 스크립팅(XSS) — 댓글 자리에 글 대신 몰래 실행되는 스크립트를 심어두는 공격. 그 글을 읽은 사람의 브라우저에서 실행되어 정보가 새어 나간다.
둘 다 정상적인 입력창에 정상이 아닌 내용을 넣는다는 공통점이 있다. 그래서 WAF는 트래픽의 양이 아니라 요청 안에 적힌 내용을 뜯어본다.
[사용자 요청] ──▶ [WAF: 내용 검사] ──▶ [내 웹 서비스]
│
└─ 수상한 패턴이면 여기서 차단
WAF에는 미리 만들어 둔 규칙 묶음(관리형 규칙)이 있어서, 처음부터 규칙을 다 짜지 않아도 흔한 공격 유형은 켜기만 하면 걸러진다. 그 밖에 특정 IP나 국가에서 오는 요청 차단, 짧은 시간에 지나치게 많이 요청하는 대상 차단 같은 규칙도 만들 수 있다.
"SQL 인젝션/XSS 같은 웹 공격을 막아라", "특정 악성 요청 패턴을 필터링하라"가 보이면 WAF다. 핵심 키워드는 웹 애플리케이션 계층(L7) 공격이다.
소규모 쇼핑몰을 운영하는 팀이 로그인 페이지에 이상한 로그가 잔뜩 쌓이는 것을 발견했다. 확인해보니 자동화된 프로그램이 아이디 입력란에 온갖 문자열을 밀어 넣으며 취약점을 찾고 있었다. 이 팀은 애플리케이션 코드를 전부 뜯어고치는 대신, 우선 로드 밸런서 앞에 WAF를 붙이고 관리형 규칙을 켜서 명백한 공격 패턴부터 차단했다. 코드를 고치는 근본 대책은 그대로 진행하되, 그때까지 시간을 벌어주는 방패 — 실무에서 WAF가 자주 쓰이는 방식이다.
DDoS는 기술적으로 정교한 공격이 아니다. 그냥 사람이 너무 많이 몰려오게 만드는 것이다.
좌석 20개짜리 식당에 누군가 사람 1,000명을 동원해 동시에 몰려가 자리를 채우고 아무것도 주문하지 않는다고 해본다. 식당은 부서지지 않았고 요리사도 멀쩡하지만, 진짜 손님이 들어올 자리가 없다. 서버를 해킹하는 게 아니라 정상 이용자가 접속할 자리를 없애버리는 것, 그게 DDoS다.
"분산(Distributed)"이 붙은 이유는 이들이 전 세계 수많은 곳에서 동시에 몰려오기 때문이다. 한 곳에서 오면 그 주소만 막으면 되지만, 수만 곳에서 조금씩 오면 어디까지가 공격이고 어디부터가 진짜 손님인지 구분하기가 어려워진다.
구분
Shield Standard
Shield Advanced
이용 방식
모든 AWS 고객에게 기본 적용
별도 유료 구독
추가 비용
없음
있음
방어 범위
흔한 네트워크·전송 계층 공격 자동 방어
더 크고 정교한 공격까지 대응
전문가 지원
없음
AWS 대응팀 지원
요금 급증 보호
없음
공격 때문에 늘어난 사용량에 대한 보호 제공
⚠️ 함정: "DDoS 방어를 위해 무엇을 켜야 하는가"라는 문항에서 Shield Standard를 고르게 하려는 함정이 있다. Shield Standard는 따로 켜거나 신청하는 것이 아니라 이미 모든 고객에게 적용되어 있다. 그래서 "추가 비용 없이 기본 제공되는 DDoS 방어"라는 표현이 보이면 Shield Standard가 정답이고, "더 강력한 방어와 전문가 지원이 필요하다"면 Shield Advanced다.
"대량 트래픽으로 서비스를 마비시키는 공격(DDoS)을 막아라"가 보이면 Shield다. WAF가 "내용(요청 패턴)"을 본다면, Shield는 "물량(트래픽 폭주)"을 막는다고 구분하면 쉽다.
Amazon GuardDuty는 지능형 위협 탐지 서비스다. CloudTrail 로그, VPC 흐름 로그, DNS 로그 등을 머신러닝으로 분석해 비정상적이고 악의적인 활동을 자동으로 찾아낸다. 예를 들어 평소와 다른 위치에서의 API 호출, 암호화폐 채굴 행위, 손상된 인스턴스의 통신 등을 탐지한다.
별도 에이전트 설치 없이 켜기만 하면 동작하는 점이 특징이다.
GuardDuty를 이해하는 가장 쉬운 방법은 카드사의 이상 거래 감지를 떠올리는 것이다. 평소 서울에서만 쓰던 카드가 새벽 3시에 지구 반대편에서 결제되면 카드사가 문자를 보낸다. 도난당했다고 단정한 것이 아니라 "평소와 다르다"는 신호를 보낸 것이다. GuardDuty도 똑같이 한다 — 평소 쓰지 않던 지역에서 관리자 API를 호출하거나, 서버가 알려진 악성 주소와 통신을 시작하거나, 조용하던 인스턴스가 갑자기 채굴로 보이는 통신을 하면 탐지 결과(finding)로 알려주고 심각도까지 매겨준다.
특징이 하나 더 있다. 서버마다 프로그램을 설치할 필요가 없다는 점이다. 이미 AWS 안에 쌓이고 있는 기록을 읽어 분석하기 때문에 콘솔에서 켜기만 하면 동작한다.
⚠️ 함정: GuardDuty는 위협을 찾아서 알려주는 서비스이지, 공격을 막아주는 서비스가 아니다. "공격을 자동으로 차단한다"는 설명이 GuardDuty에 붙어 있으면 오답 신호다. 차단은 WAF·Shield·보안 그룹 같은 예방 장치의 몫이고, GuardDuty는 CCTV처럼 발견하고 알린다.
"계정·워크로드의 의심스러운/악의적인 활동을 자동으로 탐지하라"가 보이면 GuardDuty다. 키워드는 위협 탐지(threat detection)와 로그 기반 이상 분석이다.
Amazon Inspector는 취약점을 자동으로 점검한다. EC2 인스턴스, 컨테이너 이미지(ECR), Lambda 함수를 스캔해 알려진 소프트웨어 취약점(CVE)이나 네트워크 노출 문제를 찾아 우선순위와 함께 보고한다.
GuardDuty가 "지금 일어나는 악의적 행동"을 찾는다면, Inspector는 "공격당하기 쉬운 약점이 있는지"를 미리 점검하는 쪽이다.
비유하자면 Inspector는 자동차 정기 검사다. 사고가 났을 때 출동하는 것이 아니라, 사고가 나기 전에 브레이크 패드가 닳지는 않았는지, 타이어 홈이 남았는지를 미리 확인한다.
여기서 "알려진 취약점"이라는 말이 중요하다. 소프트웨어에서 보안 결함이 발견되면 전 세계가 공유하는 목록에 번호를 붙여 등록하는데, 이걸 CVE라고 부른다. 이 목록이 공개된다는 것은 곧 공격자도 같은 목록을 보고 있다는 뜻이다. 그래서 "우리 서버에 그 목록에 오른 낡은 소프트웨어가 있지 않은가"를 계속 확인해야 하고, 사람이 손으로 하기는 불가능하다. Inspector가 대신한다.
"EC2/컨테이너의 소프트웨어 취약점을 점검하라", "패치되지 않은 약점을 찾아라"가 보이면 Inspector다. 키워드는 취약점 평가(vulnerability assessment)다.
Amazon Macie는 S3에 저장된 민감 데이터를 찾아 보호한다. 머신러닝으로 S3 버킷을 스캔해 개인 식별 정보(PII), 신용카드 번호, 자격 증명 같은 민감 데이터가 어디에 있는지 자동으로 발견하고 분류한다.
Macie가 필요한 이유는 조금 의외의 곳에 있다. 대부분의 회사는 자기 회사에 어떤 민감 데이터가 어디에 있는지 정확히 모른다. 마케팅팀이 이벤트 응모자 명단을 임시 폴더에 올려두고 잊고, 개발자가 장애를 분석하려고 실제 회원 데이터를 테스트용 저장소에 복사해 두고, 옛 시스템에서 넘어온 백업 파일 안에 무엇이 들었는지는 아무도 모른다. 이 상태에서는 "우리 회사 개인정보는 안전한가?"라는 질문에 답할 방법이 없다. 어디에 있는지 모르면 지킬 수도 없기 때문이다.
Macie는 S3를 훑어서 "이 파일 안에 주민등록번호 형태의 값이 있다", "여기에 카드번호처럼 보이는 것이 있다"를 찾아 목록으로 보여준다. 그러면 그제서야 "이건 지워야겠다", "이 버킷은 암호화하고 접근 권한을 좁혀야겠다" 같은 판단을 할 수 있다.
함정: Macie의 대상은 S3다. "EC2 안의 파일에서 개인정보를 찾아라" 같은 시나리오에 Macie를 붙이려는 선택지가 나오면 의심해야 한다. 반대로 문항에 S3와 개인정보(PII)가 함께 등장하면 거의 Macie다.
"S3 안의 개인정보(PII)/민감 데이터를 찾아내라"가 보이면 Macie다. 키워드는 S3 + 민감 데이터 발견·분류다. 데이터 자체에 초점을 둔 서비스라는 점이 핵심이다.
AWS Security Hub는 여러 보안 서비스의 결과를 한 곳에 모아 보여주는 통합 대시보드다. GuardDuty, Inspector, Macie 등에서 나온 탐지 결과(findings)를 한 화면에 모으고, 모범 사례(예: CIS 벤치마크) 대비 보안 상태를 점수로 보여준다.
왜 이런 서비스가 따로 필요한지는 앞의 다섯 개를 다 켜본 회사를 상상하면 이해가 된다. GuardDuty가 알림을 보내고, Inspector가 취약점 목록을 만들고, Macie가 민감 데이터를 찾아낸다. 그런데 이 결과들이 각각 다른 화면에 따로 쌓인다. 담당자는 매일 아침 화면 다섯 개를 열어봐야 하고, 계정이 여러 개면 그 수만큼 곱해진다. 현실적으로 며칠이면 아무도 보지 않게 된다.
Security Hub는 이 결과들을 한 화면에 모아 심각도 순으로 줄 세워준다. 여기에 더해 "AWS가 권장하는 보안 모범 사례를 우리 계정이 얼마나 지키고 있는가"를 자동으로 점검해 점수 형태로 보여준다.
함정: Security Hub는 스스로 위협을 탐지하지 않는다. 다른 서비스가 찾아낸 결과를 모아 보여주는 역할이다. "S3의 민감 데이터를 발견하려면?" 같은 문항에 Security Hub가 답이 되는 일은 없다. Security Hub가 답인 문항에는 거의 항상 "여러", "통합", "한곳에서", "중앙" 같은 단어가 들어 있다.
"여러 보안 서비스의 결과를 한곳에서 통합 관리/모니터링하라"가 보이면 Security Hub다. 개별 탐지가 아니라 중앙 집중식 가시성(central view)이 키워드다.
여섯 개를 다른 각도로 한 번 더 묶어본다. 시험에서 "예방적 통제냐 탐지적 통제냐"를 구분하게 만드는 문항이 나올 때 도움이 된다.
성격
서비스
하는 일
예방(막는다)
WAF, Shield
나쁜 트래픽이 들어오기 전에 차단
탐지(찾는다)
GuardDuty, Inspector, Macie
이미 있는 위협·약점·민감 데이터를 발견
통합(모은다)
Security Hub
탐지 결과를 한곳에 모아 보여줌
여기에 어제 배운 IAM을 얹으면 그림이 완성된다. IAM이 들어올 수 있는 사람을 제한하고, WAF·Shield가 외부에서 들어오는 것을 막고, 나머지 셋이 놓친 것을 찾아낸다.
여섯 서비스는 문지기(WAF), 인파 통제(Shield), CCTV(GuardDuty), 안전 점검(Inspector), 서랍 정리(Macie), 관제 모니터(Security Hub)로 줄여 기억할 수 있다. 서비스마다 한 줄 정체성만 또렷하면 시나리오에서 이웃 서비스와 구분하기 쉽다.