[보안] 중소기업 Wazuh 도입 1년 회고: SIEM 구축 성공과 실패 사례

중소기업에서 Wazuh 도입을 고민하시는 분들은 대개 비슷한 지점에서 막히시더라고요. 보안 모니터링은 해야겠는데 상용 솔루션은 부담스럽고, 그렇다고 로그를 그냥 쌓아만 두자니 사고가 터졌을 때 아무것도 못 보는 상황이 생깁니다. 저도 홈랩과 실무 환경에서 비슷한 흐름을 여러 번 겪었습니다. 특히 SIEM 구축은 제품 하나 설치한다고 끝나는 일이 아니라, 로그 수집 범위, 경보 기준, 운영 인력의 습관까지 같이 바뀌어야 하거든요. 이번 글은 제가 1년 정도 오픈소스 SIEM 계열을 실제로 굴려보면서 느낀 점, 그리고 그중에서도 Wazuh를 중심으로 어떤 부분은 잘 됐고 어떤 부분은 삽질이었는지 정리한 회고입니다.

처음엔 저도 “이거 설치만 하면 보안 관제가 되는 건가?” 싶었는데요, 실제로 써보니까 그런 기대는 빨리 버리는 게 맞았습니다. 대신 기준만 잘 잡으면 중소기업에서도 꽤 현실적인 보안 모니터링 체계를 만들 수 있더라고요. 혹시 지금 사내 서버 로그가 각자 제자리에서만 돌고 있고, 장애나 이상 징후를 사람 감으로만 보고 계신가요? 그렇다면 이 글이 꽤 도움이 되실 겁니다.

중소기업 환경에서 Wazuh manager, agents, 로그 수집 대상 서버, 대시보드 흐름을 한눈에 보여주는 개요 이미지입니다.

1. 왜 중소기업에서 Wazuh 도입을 검토하게 되는가

현실적으로 중소기업은 보안팀이 따로 없거나, 있어도 인프라 담당자가 같이 보는 경우가 많습니다. 저도 비슷했거든요. 그러다 보니 가장 먼저 필요한 건 거창한 위협 인텔리전스보다 “무슨 일이 일어났는지 한곳에서 보는 능력”이었습니다.

• 서버마다 로그인 실패 로그가 흩어져 있음
• Windows 이벤트와 Linux syslog가 따로 놀음
• 파일 무결성 체크(FIM, File Integrity Monitoring)가 안 됨
• 에이전트(agent, 수집기) 배포 후 운영 기준이 없음
• 알림은 오는데 무엇이 중요한지 구분이 안 됨

이런 상황에서 Wazuh는 비교적 잘 알려진 오픈소스 기반 보안 플랫폼이고, 호스트 단위 가시성 확보에 강점이 있습니다. 특히 Linux와 Windows를 같이 보는 환경에서 시작점으로는 꽤 괜찮았습니다. 다만 여기서 중요한 포인트가 하나 있습니다. Wazuh 도입 자체가 목표가 되면 실패합니다. 목표는 도구 설치가 아니라, 운영 가능한 탐지 체계를 만드는 겁니다.

2. SIEM 구축을 쉽게 말하면 무엇인가

SIEM(Security Information and Event Management, 보안 정보 및 이벤트 관리)을 쉽게 말하면, 여러 시스템에서 나오는 로그와 이벤트를 한곳에 모아서 “이상 징후를 더 빨리 찾고, 나중에 추적도 할 수 있게 만드는 체계”입니다. 단순 로그 저장소하고는 조금 다릅니다.

예를 들어 보겠습니다. 어떤 사용자가 새벽 시간대에 VPN에 접속하고, 직후 Linux 서버에서 sudo 사용이 늘어나고, 그다음 애플리케이션 서버에서 특정 설정 파일이 바뀌었다고 해보죠. 개별 로그만 보면 각각 별일 아닐 수 있습니다. 그런데 SIEM 구축 관점에서는 이 흐름을 묶어서 볼 수 있어야 합니다. 그게 핵심입니다.

Wazuh 활용도 결국 여기로 연결됩니다. 에이전트를 깔고 대시보드만 띄우는 단계에서 멈추면 그냥 보기 좋은 로그 화면 하나 생긴 수준이에요. 반대로 자산 분류, 룰 튜닝, 알림 우선순위까지 잡아가면 중소기업에서도 쓸 만한 보안 모니터링 체계가 됩니다.

3. 제가 잡았던 Wazuh 도입 목표와 범위

처음부터 모든 자산을 넣지는 않았습니다. 이건 진짜 중요합니다. 욕심내서 한 번에 다 넣으면 대시보드가 아니라 경보 쓰레기통이 되거든요. 제가 직접 해보니 1단계 목표는 아주 단순해야 했습니다.

1. 인터넷 노출 가능성이 있는 서버부터 우선 수집
2. 관리 계정 로그인, 권한 상승, 주요 파일 변경을 우선 탐지
3. 운영팀이 실제로 대응 가능한 수준까지만 알림 설정
4. 2주 단위로 오탐(false positive, 정상인데 경보 발생) 정리

범위는 Linux 서버 몇 대, Windows 서버 몇 대, 그리고 일부 웹 서비스 로그 정도로 시작했습니다. 네트워크 장비까지 한 번에 얹고 싶었는데, 예전 경험상 그렇게 하면 룰 정리도 안 되고 책임 범위만 넓어지더라고요. 결국 성공 포인트는 “작게 시작해서 운영에 녹이는 것”이었습니다.

4. 실전 구현: 중소기업 환경에서 Wazuh 활용 시작하기

여기서는 복잡한 HA(High Availability, 고가용성) 구성보다, 현실적으로 시작 가능한 단일 매니저 중심 구조를 기준으로 설명드리겠습니다. 운영 환경에서는 백업, 디스크 용량, 인덱스 보존 기간부터 먼저 계산하셔야 합니다.

4-1. 에이전트 연결 전 체크리스트

• 시간 동기화: NTP(Network Time Protocol) 확인
• 수집 대상 서버 자산 목록 정리
• 로그 보존 기간과 디스크 사용량 가늠
• 누가 경보를 보고, 누가 처리할지 역할 정의

4-2. Linux 에이전트 등록 예시

배포판에 따라 설치 방식은 조금 다르지만, 기본 흐름은 비슷합니다. 실무에서는 사내 패키지 저장소나 자동화 도구를 같이 쓰시는 편이 좋습니다.

# manager address example
sudo /var/ossec/bin/agent-auth -m 10.0.0.10

# agent service start example
sudo systemctl enable wazuh-agent
sudo systemctl start wazuh-agent

# status check
sudo systemctl status wazuh-agent

처음엔 에이전트가 붙기만 하면 끝인 줄 알았는데, 실제로는 여기서부터 시작입니다. 붙은 뒤에 어떤 로그를 더 읽을지, 파일 무결성 감시 대상을 어디까지 둘지 정해야 하거든요.

4-3. Linux 주요 로그 수집 예시

<localfile>
  <log_format>syslog</log_format>
  <location>/var/log/auth.log</location>
</localfile>

<localfile>
  <log_format>syslog</log_format>
  <location>/var/log/syslog</location>
</localfile>

Ubuntu 계열이면 <code>/var/log/auth.log가 중요했고, RHEL 계열은 경로나 로그 체계가 다를 수 있어서 환경별 확인이 필요했습니다. 이런 기본 로그만 잘 들어와도 계정 사용 패턴이 꽤 보입니다.

에이전트 설치, 매니저 등록, 인증, 로그 전달, 대시보드 반영 흐름을 단계별로 보여주는 구성 이미지입니다.

4-4. 파일 무결성 감시 설정 예시

FIM(File Integrity Monitoring, 파일 무결성 감시)은 생각보다 체감 효과가 컸습니다. 웹 서버 설정 파일이나 중요 스크립트가 바뀌었을 때 바로 보이니까요. 다만 범위를 넓히면 바로 시끄러워집니다.

<syscheck>
  <directories check_all="yes" realtime="yes">/etc</directories>
  <directories check_all="yes" realtime="yes">/usr/local/bin</directories>
  <ignore>/etc/mtab</ignore>
</syscheck>

제가 처음엔 /var 쪽까지 넓게 걸었다가 로그 회전과 임시 파일 변경 때문에 경보가 너무 많이 쏟아졌습니다. 삽질 좀 했습니다 ㅎㅎ 그래서 지금은 보안적으로 의미 있는 경로만 좁게 잡는 쪽을 권합니다.

4-5. 경보 레벨 운영 기준 정리

Wazuh 활용에서 정말 중요한 건 경보의 품질입니다. 경보가 너무 많으면 결국 아무도 안 봅니다. 저는 대략 이렇게 나눠서 운영했습니다.

5. 성공 사례: 작게 시작했더니 운영이 굴러갔습니다

성공했던 부분은 의외로 화려한 탐지가 아니었습니다. 기본기였어요. 예를 들면 다음과 같습니다.

• 관리 계정 로그인 실패 반복 확인이 쉬워짐
• 주요 설정 파일 변경 이력 가시성 확보
• Windows와 Linux 이벤트를 같은 관점에서 보기 시작
• 보안팀이 없어도 운영팀이 최소한의 이상 징후를 확인 가능

특히 계정 관련 이벤트는 체감이 컸습니다. 예전에는 “누가 언제 어디서 실패했는지”를 서버별로 따로 봤는데, 이제는 한 화면에서 흐름이 이어지니까 조사 시간이 줄더라고요. 드디어 됐다 싶은 순간이 이런 데서 나왔습니다. 엄청 첨단 기능이 아니라도, 찾아야 할 로그를 덜 헤매는 것만으로 운영 품질이 달라졌습니다.

또 하나 좋았던 건 내부 커뮤니케이션입니다. 장애냐, 보안 이슈냐 애매한 상황에서 로그 근거를 바로 보여줄 수 있으니 논의가 빨라졌습니다. 인프라 팀과 개발팀 사이에서도 “느낌상 그런 것 같다”가 아니라 이벤트 기준으로 이야기하게 되더라고요.

6. 실패 사례: Wazuh 도입 후 오히려 피곤해졌던 순간들

반대로 실패도 분명히 있었습니다. 솔직히 말씀드리면, 도입 초반 2개월은 시스템이 아니라 사람이 먼저 지칩니다. 이유는 대부분 비슷합니다.

6-1. 오탐이 많아서 아무도 안 보기 시작함

가장 흔한 실패입니다. 룰을 많이 켠다고 좋은 게 아니더라고요. 시스템 업데이트, 배치 작업, 운영자의 정상 작업이 전부 경보로 올라오면 며칠 안 가서 무감각해집니다. 이 상태가 제일 위험합니다. 진짜 중요한 이벤트가 섞여도 묻히거든요.

6-2. 자산 분류 없이 에이전트만 늘림

중요 서버와 덜 중요한 서버가 같은 우선순위로 들어오면 분석 리소스가 분산됩니다. 제가 처음엔 “일단 많이 붙이자” 쪽이었는데 완전히 잘못된 접근이었습니다. 자산 등급이 먼저고, 수집은 그다음입니다.

6-3. 저장 정책을 가볍게 봄

로그는 쌓이는 속도가 생각보다 빠릅니다. 특히 웹 접근 로그나 상세 시스템 이벤트까지 같이 보면 보존 정책이 금방 문제 됩니다. 디스크만의 문제가 아니라 검색 성능도 같이 내려갑니다. 이 부분은 SIEM 구축에서 꽤 현실적인 비용 포인트입니다.

오탐이 많던 초기 상태와 룰 튜닝 이후 상태를 시각적으로 비교해 주는 대시보드 개념 이미지입니다.

7. ⚠️ 실제 겪은 트러블슈팅과 해결 방법

여기서는 제가 실제로 많이 부딪힌 문제 위주로 적어보겠습니다. 비슷한 상황이 정말 자주 나옵니다.

7-1. 에이전트는 붙었는데 기대한 로그가 안 들어오는 문제

원인은 대체로 세 가지였습니다. 로그 파일 경로를 잘못 잡았거나, 권한 문제이거나, 애플리케이션 로그 포맷이 기대와 다른 경우입니다. 특히 커스텀 애플리케이션은 syslog 형식이 아니라서 별도 파싱 전략이 필요할 때가 있습니다.

# recent agent logs example
sudo tail -n 50 /var/ossec/logs/ossec.log

# auth log check example
sudo tail -n 50 /var/log/auth.log

이럴 때 저는 무조건 에이전트 로그부터 봤습니다. 대시보드에서만 찾으려고 하면 시간 더 걸립니다.

7-2. 파일 무결성 감시가 너무 시끄러운 문제

해결은 단순했습니다. 감시 경로를 줄이고, 변동이 잦은 경로는 과감히 제외했습니다. 모든 변경을 다 잡겠다는 욕심보다 중요 변경만 놓치지 않는 것이 낫습니다.

7-3. 경보는 오는데 누가 볼지 정해지지 않은 문제

이건 기술 이슈 같지만 사실 운영 이슈입니다. Slack이든 메일이든 알림 채널만 만들면 끝날 줄 알았는데 아니었습니다. 근무시간 내 확인 담당, 야간 긴급 기준, 주간 리포트 담당을 정해야 실제 운영이 됩니다. 도구보다 프로세스가 먼저라는 말을 괜히 하는 게 아니더라고요.

7-4. 업데이트 이후 룰 동작이 달라졌다고 느껴질 때

버전 업그레이드는 항상 검증 환경에서 먼저 보는 게 맞습니다. 저는 홈랩에서 비슷한 구성을 따로 돌려보면서 룰 변화, 에이전트 연결, 주요 대시보드 동작을 먼저 확인했습니다. 중소기업 환경일수록 운영 서버가 곧 테스트 서버가 되는 경우가 있는데, 보안 시스템은 그렇게 다루면 피곤해집니다.

8. 검증과 결과: 1년 운영 후 무엇이 남았나

정량 수치를 과하게 들이밀고 싶진 않습니다. 환경마다 다르거든요. 대신 운영 체감 기준으로는 확실한 변화가 있었습니다.

1. 이상 로그인이나 권한 상승 흔적을 찾는 시간이 줄었습니다.
2. 주요 서버의 변경 이력을 더 빨리 추적하게 됐습니다.
3. 인프라 운영과 보안 모니터링 사이의 경계가 조금 정리됐습니다.
4. 무엇보다 “문제 발생 후 로그를 찾는 문화”에서 “평소에 보는 문화”로 조금 이동했습니다.

완벽하진 않았습니다. 여전히 룰 튜닝은 계속해야 하고, 애플리케이션 레벨 가시성은 부족한 부분이 있습니다. 하지만 Wazuh 도입으로 최소한의 기준선은 만들 수 있었습니다. 이게 꽤 큽니다. 아무것도 없는 상태와, 조금이라도 지속 가능한 보안 모니터링 체계가 있는 상태는 정말 다르거든요.

운영 1년 후 주요 이벤트 분류, 우선순위, 대응 흐름이 정리된 상태를 보여주는 결과 시각화 이미지입니다.

9. 마무리: 중소기업에서 오픈소스 SIEM을 성공시키는 기준

정리해보면, Wazuh 도입은 “무료니까 일단 깔아보자”로 접근하면 금방 지칩니다. 대신 아래 기준으로 접근하면 훨씬 낫습니다.

• 작게 시작할 것
• 중요 자산부터 붙일 것
• 오탐을 줄이는 운영 시간을 반드시 확보할 것
• 경보를 누가 볼지 먼저 정할 것
• 보안 모니터링 목표를 기술보다 운영 기준으로 정의할 것

제가 직접 해보니 오픈소스 SIEM의 핵심은 기능 수보다 지속 가능성이었습니다. 멋진 룰셋보다, 팀이 실제로 매주 볼 수 있는 대시보드와 알림이 더 중요하더라고요. 혹시 지금 Wazuh 활용을 검토 중이시라면, 처음부터 거대한 청사진보다 “이번 달에 무엇을 탐지할 것인가”부터 적어보시면 좋겠습니다.

다음 글에서는 Wazuh 룰 튜닝과 알림 우선순위 설계를 좀 더 실무적으로 다뤄볼 예정입니다. 이전 글에서 다뤘던 로그 보존 전략이나 syslog 수집 구조와도 연결되는 주제라, 같이 보시면 흐름이 더 잘 잡히실 겁니다.

중소기업 관점에서 Wazuh 도입 성공 기준, 실패 패턴, 다음 단계 체크리스트를 한 장으로 정리한 요약 이미지입니다.

자주 묻는 질문

Wazuh는 중소기업 SIEM 구축 시작점으로 괜찮은가요?

네, 시작점으로는 괜찮았습니다. 다만 설치보다 운영 기준 정의가 더 중요합니다.

보안 전담 인력이 없어도 운영 가능한가요?

가능은 합니다. 대신 자산 범위를 좁게 시작하고, 경보 우선순위를 명확히 나눠야 합니다.

오픈소스 SIEM이면 비용이 아예 없나요?

라이선스 비용이 없을 수는 있어도, 저장소 비용과 운영 시간 비용은 분명히 듭니다. 이걸 과소평가하면 실패 확률이 높습니다.