요약: Amazon Inspector는 EC2의 취약한 패키지와 네트워크 노출을 찾고, Wazuh는 호스트에서 발생하는 로그·파일 변경·행위를 탐지한다. 둘은 대체재라기보다 서로 다른 시점을 보는 보완재다.
EC2 보안을 구성하다 보면 같은 질문이 생긴다. “Wazuh에도 취약점 탐지가 있는데 Inspector를 왜 함께 써야 할까?” 이 글에서는 두 도구가 데이터를 수집하는 방식, 겹치는 영역과 사각지대, 함께 사용할 때의 흐름을 간단히 정리한다.
작성 기준: Amazon Inspector v2, Wazuh 4.x 계열. 콘솔 화면을 게시할 때는 실제 Wazuh 버전과 검사 시각을 함께 적는다.
한눈에 보는 차이
구분 | Amazon Inspector | Wazuh |
핵심 질문 | 무엇이 취약한가? | 지금 무슨 일이 일어나는가? |
수집 방식 | SSM·VM Scanner 또는 EBS Snapshot | EC2 내부 Agent |
주요 탐지 | 패키지 CVE·네트워크 도달성 | 로그·FIM·SCA·취약점·행위 |
결과 | Finding·심각도·수정 버전 | Alert·이벤트·Active Response |
운영 | AWS 관리형 | Manager·Indexer·Dashboard 운영 |
Inspector는 EC2를 어떻게 검사할까?
Inspector는 EC2 안에서 공격 코드를 실행하는 제품이 아니다. 인스턴스의 패키지 인벤토리 또는 SBOM을 수집한 뒤 AWS 측 취약점 정보와 대조한다. Security Group·NACL·Route도 분석해 외부에서 도달 가능한 경로를 찾는다.
검사 방식은 세 가지로 이해하면 쉽다.
- Agent-based: SSM 관리 대상에서 인벤토리를 수집한다.
- Agentless: SSM을 사용할 수 없을 때 EBS Snapshot을 분석한다.
- Hybrid: SSM 여부에 따라 두 방식을 자동 선택한다.
대표 평가 간격은 네트워크 도달성 약 12시간, SSM 인벤토리 기본 30분, Agentless 약 24시간으로 알려져 있다. 다만 이는 보장 SLA가 아닌 일반 동작 참고치이므로 실제 화면의
last scanned 시각을 기준으로 판단해야 한다.Wazuh는 무엇이 다를까?
Wazuh Agent는 EC2 내부에서 로그와 상태를 지속적으로 Manager에 보낸다. 따라서 취약 패키지뿐 아니라 다음과 같은 런타임 단서까지 다룰 수 있다.
- 파일 생성·수정·삭제를 감지하는 FIM
- 보안 설정을 점검하는 SCA
- 로그·규칙 기반 행위 탐지와 Active Response
즉 Inspector가 “공격 가능한 상태인가?”를 묻는다면, Wazuh는 “지금 수상한 일이 발생했는가?”에 더 가깝다.
두 도구를 함께 쓰는 파이프라인
그림 1. 같은 EC2를 Inspector와 Wazuh가 서로 다른 관점에서 분석하고, 결과를 통합하는 흐름
Inspector Findings는 EventBridge와 S3를 거쳐 Wazuh의
aws-s3 모듈로 수집할 수 있다. 이 구조에서는 Inspector가 취약 상태를 만들고, Wazuh가 호스트 이벤트와 함께 분석하는 형태가 된다.프로젝트에서 선택한 구성
우리는 Inspector Hybrid 스캔과 Wazuh 취약점 탐지를 함께 유지하는 구성을 선택했다.
- SSM 관리 EC2는 Agent-based로 검사하고, 예외 대상은 Agentless로 보완한다.
- Inspector만 쓰면 로그·FIM·실행 중 행위·자동 대응 영역이 비게 된다.
- Wazuh만 쓰면 AWS 관리형 평가와 네트워크 도달성 비교가 빠진다.
따라서 두 제품의 겹침은 불필요한 중복이 아니라 계층 분리와 결과 교차검증을 위한 의도된 설계다.
어디가 겹치고, 어디서 갈릴까?
항목 | Inspector | Wazuh | 예상 차이 |
패키지 인벤토리 | 수집 | 수집 | 대체로 유사 |
CVE 피드 | AWS 큐레이션 | Wazuh CTI / NVD | 심각도·수정 버전 차이 |
소스 빌드 바이너리 | 미탐 가능 | 미탐 가능 | 공통 사각지대 |
네트워크 도달성 | 탐지 | 기본 미탐 | Inspector 영역 |
실행 중 악용 행위 | 기본 미탐 | 규칙·로그로 탐지 | Wazuh 영역 |
수집 시점 | 주기적 평가 | 준실시간 | 대조 시 시차 |
Log4j로 보면 더 명확하다
그림 2. Log4j 취약점에서 상태 탐지와 행위 탐지가 나뉘는 예
- Inspector는 취약한 Log4j 버전이 설치된 상태를 Finding으로 보여준다.
- Wazuh는 관련 로그와 후속 행위를 바탕으로 취약점 악용 정황을 Alert로 보여준다.
두 결과를 합치면 “취약한가?”와 “실제로 악용됐는가?”를 한 흐름에서 판단할 수 있다.
실습에서는 이렇게 검증한다
- Inspector EC2 Coverage와 Wazuh Agents에서 같은 EC2가 관리되는지 확인한다.
- Inspector Finding에서 CVE, 패키지, 현재 버전, 심각도와 검사 시각을 기록한다.
- Wazuh에서 동일 패키지의 취약점 결과 또는 전용 테스트 파일의 FIM 이벤트를 확인한다.
- 양쪽 수집이 끝난 뒤 동일 EC2·동일 패키지·동일 시간대를 기준으로 비교한다.
- 화면에는 계정번호·공인 IP·ARN·키·토큰이 보이지 않도록 마스킹한다.
결과가 다르면 곧바로 오탐으로 보지 않는다. CVE 피드, 패키지 식별자, 심각도 기준, 검사 시각 순서로 원인을 확인한다.
비용과 주의점
- 월 USD 1~2는 소규모 EC2의 일반 추정치다. 게시 전 ap-northeast-2의 실제 단가와 실행 시간으로 다시 계산한다.
- Agentless는 EBS Snapshot 비용과 정리 여부를 확인한다.
- CIS Benchmark 평가는 기본 취약점 스캔과 별도 과금될 수 있다.
- 취약점이 0건이면 억지로 오래된 패키지를 설치하지 말고 정상 검사 상태와 0건 결과를 남긴다.
자주 나오는 질문
Wazuh도 취약점을 찾는데 Inspector는 중복 아닌가?
일부 패키지 탐지는 겹친다. 그러나 Inspector는 AWS 관리형 평가와 네트워크 도달성, Wazuh는 런타임 탐지와 대응에 강점이 있다.
왜 Agentless만 사용하지 않는가?
기존 SSM 관리 EC2는 Agent-based를 이용하면 Snapshot 운영 부담을 줄일 수 있다. Hybrid는 예외 대상만 Agentless로 보완한다.
결과가 다르면 어느 쪽이 맞는가?
둘 중 하나를 즉시 틀렸다고 볼 수 없다. 피드와 수집 시점이 다르므로 동일 조건으로 맞춘 뒤 차이를 분석해야 한다.
마무리
Inspector와 Wazuh는 같은 취약점 정보를 일부 사용하지만 관찰 시점이 다르다. Inspector는 공격 전 취약 상태를 줄이고, Wazuh는 운영 중 발생한 이벤트를 탐지·대응한다. 함께 사용하면 예방과 탐지를 한 파이프라인으로 연결할 수 있다.
용어 간단 정리
- SBOM: 소프트웨어 구성요소 명세서
- FIM: 파일 무결성 모니터링
- SCA: 보안 설정 평가
- 도달성(Reachability): SG·NACL·Route 기준의 네트워크 접근 가능성
