Datadog 란, 호스트 취약점 스캐너를 Agent 기반으로 전환한 이유와 방법
한마디로
Datadog이 별도 스캐너 대신 이미 깔려있던 Agent로 수만 대 서버 취약점을 99% 이상 최신 상태로 점검하게 바꾼 과정이에요
한눈에
Datadog은 관측용으로 이미 깔아둔 Datadog Agent를 호스트 취약점 스캐닝에도 쓰도록 구조를 바꿨습니다. 별도 원격 스캐너가 SSH 인증서 만료 때문에 전체 호스트를 다 점검하지 못하던 문제를, Agent가 수집한 패키지 목록을 Cloud Security가 분석하는 방식으로 풀었어요. 6개월 병행 운영 끝에 전환했고 지금은 스캔 신선도가 99% 이상을 유지합니다.
AS-IS: 원격 스캐너의 한계
Datadog은 전 세계 수만 명 사용자를 지원하면서 호스트 수도 같이 늘었습니다. 기존 원격 스캐너로 전체 호스트를 점검하는 데 18시간 넘게 걸렸는데, 스캐너의 SSH 인증서는 12시간 만에 만료됐어요. 인증서가 만료되면 남은 호스트에 인증할 수 없고, 인증이 안 되면 로컬 소프트웨어와 패키지 버전을 확인할 수 없어서 취약점 탐지 자체가 불가능해집니다. 인증서 수명을 늘리거나 스캐너 수를 더 늘리는 방법도 있었지만, 둘 다 Security 팀이 전용 스캐너와 자격 증명, 네트워크 접근 권한을 계속 관리해야 한다는 부담은 그대로였어요.
전환: 이미 깔려있던 Agent를 활용
Datadog Agent는 관측 목적으로 이미 전체 호스트에 배포돼 있었습니다. 이걸 설정하면 Agent가 설치된 패키지 목록과 버전을 수집해서 기존 데이터 경로로 Datadog에 전송하고, Cloud Security가 그 인벤토리로 알려진 취약점을 식별하는 방식이 가능해졌어요. Security 팀은 Customer Zero로서 Cloud Security 제품팀과 직접 협업해 운영 요건과 감사 요건을 기준으로 이 방식을 평가했습니다. 핵심 평가 기준은 네 가지였는데, 호스트가 들어오고 나가도 커버리지를 최신으로 유지할 수 있는지, 프로덕션 컨텍스트로 발견 사항의 우선순위를 매길 수 있는지, 기존 인프라 워크플로우로 바로 조치할 수 있는지, 내부 리스크 리뷰와 컴플라이언스 감사 근거를 제공할 수 있는지였어요.
6개월 병행 운영에서 드러난 차이
6개월 동안 기존 스캐너와 Cloud Security를 병행 운영하면서 어느 호스트를 커버하는지, 패키지를 어떻게 식별하는지, 발견 건수가 얼마나 나오는지, 결과를 어떻게 보고하는지를 비교했습니다. 두 시스템이 같은 소프트웨어를 다르게 분류하는 경우도 있었는데, 예를 들어 containerd의 한 포크를 서로 다르게 식별해서 단순 발견 건수 비교로는 어느 쪽이 취약점을 놓쳤는지 알 수 없었어요. 그래서 자산별 고유 CVE 기준으로 비교하는 방식을 썼습니다. 설치는 됐지만 로드되지 않은 커널 버전을 Cloud Security가 처음엔 취약점으로 보고했는데 기존 스캐너는 제외하던 차이도 발견돼서, 커트오버 전에 Cloud Security 제품팀이 이 부분의 보고 방식을 수정했어요. 또 기존 스캐너는 여러 CVE를 하나의 플러그인으로 묶어 보고했지만 Cloud Security는 CVE를 개별로 보고해서 총 발견 건수가 달라지기도 했습니다.
실무 적용 포인트
전환 후 스캔 신선도는 전체 대상 호스트 중 지난 24시간 내 최신 스캔이 완료된 비율 기준으로 99% 이상을 유지하고 있습니다. SOC 2 Type II, ISO 27001, PCI DSS, FedRAMP High 같은 감사 요건도 그대로 충족했어요. 보안 도구를 교체할 때 체크할 포인트는 이렇습니다.
- 신규 도구가 기존 인프라 프로비저닝, 운영 워크플로우에 자연스럽게 녹아드는지 확인하기
- 발견 건수 단순 비교보다 자산별 고유 CVE 기준으로 두 시스템을 비교하기
- 패키지 분류 방식, 커널 버전 처리 같은 세부 차이가 실제 탐지 누락인지 보고 방식 차이인지 먼저 구분하기
- 감사용 정적 리포트를 따로 관리하지 않고 실시간 발견 데이터를 리뷰, 감사에 그대로 쓰기
자주 묻는 질문
Datadog 란 무엇인가요
Datadog은 서버와 애플리케이션을 관측하는 모니터링 플랫폼으로, 이번 사례에서는 관측용으로 이미 깔려있던 Datadog Agent를 호스트 취약점 스캐닝에도 활용해 Cloud Security 기능과 연결했습니다.
Agent 기반 취약점 스캔은 기존 원격 스캐너와 뭐가 다른가요
원격 스캐너는 SSH로 각 호스트에 인증해 접근해야 하지만, Agent 기반 방식은 호스트에 이미 설치된 Agent가 패키지 목록을 수집해 전송하는 구조라 별도 인증서 관리나 네트워크 접근 설정이 필요 없습니다.
보안 도구 전환 시 병행 운영은 왜 필요한가요
Datadog 사례처럼 커버리지, 탐지 결과, 보고 체계가 두 시스템에서 다르게 나올 수 있기 때문에, 그 차이가 실제 탐지 누락인지 단순 보고 방식 차이인지 충분한 기간 비교해서 확인해야 전환 후 사고를 막을 수 있습니다.
ai agent 란 무엇이고 이 사례와 어떤 관련이 있나요
여기서 Agent는 생성형 AI 에이전트가 아니라 서버에 상주하며 데이터를 수집해 전송하는 Datadog Agent 소프트웨어를 말합니다. 이미 배포된 인프라 구성요소를 다른 용도로 재활용했다는 점에서 기존 자원을 확장 적용하는 사례로 참고할 만합니다.
에디터 노트
이미 깔려있는 에이전트를 재활용해 별도 스캐너 인프라를 없앤 건 운영 부담을 줄이는 현실적인 선택이에요. 다만 6개월이라는 긴 병행 운영 기간과 패키지 분류, 커널 버전 같은 세부 차이를 하나하나 검증한 과정을 보면, Agent 기반 전환이 쉬운 지름길은 아니고 꼼꼼한 검증 설계가 전제돼야 한다는 점을 보여줍니다.
참고 출처 | 원문 보기
태그
- Datadog
- 데이터독
- AI Agent
- 에이전트
- Cloud Security
- 클라우드 보안
- 호스트 취약점 스캐닝
- 호스트 취약점 스캐닝
관련 마테크
- Datadog로 보는 AI agent 개선 사례, trace-평가-실험 루프 만드는 방법AI 에이전트가 이상해졌을 때 감으로 고치지 말고 trace 데이터로 가설을 세우고 평가와 실험으로 검증하는 5단계 루프를 Datadog이 제안해요
- Datadog BYOC 크로스 클러스터 쿼리란, 리전별 로그 통합 검색 방법Datadog가 여러 리전에 흩어진 BYOC 클러스터 로그를 쿼리 한 번으로 동시에 검색하게 만들었어요
- Datadog Observability Pipelines란, Exabeam 보안 로그 필터링 Packs로 SIEM 비용 줄이는 법Datadog이 Exabeam으로 보내는 보안 로그에서 쓸모없는 노이즈만 걸러내는 사전 설정 필터 Packs를 내놨어요
- Datadog Tap to Parse란, 로그 파싱 규칙 클릭 한 번으로 자동 생성하는 법로그 메시지에 파묻힌 값을 클릭 한 번으로 검색 가능한 필드로 바꿔주는 Datadog 신기능이에요