Keycloak 이벤트 스토어, `enabled_event_types` 없이 기본 설정으로 실행될 때

(dev.to)

Keycloak Terraform provider의 문서와 실제 동작 간의 불일치로 인해, 설정 생략 시 REFRESH_TOKEN 등 특정 보안 이벤트가 데이터베이스에 저장되지 않는 심각한 보안 감사 누락 위험이 발견되었습니다.

이 글의 핵심 포인트

1Keycloak 26.7.4 및 Terraform provider v5.9.0 환경에서 설정 불일치 확인
2`enabled_event_types` 생략 시 모든 이벤트가 활성화된다는 문서 설명과 실제 동작이 다름
3`LOGIN` 이벤트는 저장되지만, `REFRESH_TOKEN` 관련 이벤트는 DB에 저장되지 않음
4로그 리스너(jboss-logging)에는 이벤트가 전달되나, DB 기반 감사 기능에는 누락됨
5Keycloak 내부 로직이 '기본 저장 대상'으로 지정된 이벤트만 선별적으로 저장하기 때문임

이 글에 대한 공공지능 분석

왜 중요한가?

IaC(Infrastructure as Code)를 통한 보안 자동화 설정이 문서와 다르게 작동할 경우, 개발자는 인프라가 안전하다고 믿지만 실제로는 보안 감사(Audit)의 핵심 데이터가 유실되는 '보이지 않는 보안 구멍'이 생길 수 있기 때문입니다.

어떤 배경과 맥락이 있나?

Keycloak은 기업용 인증 솔루션으로, Terraform/OpenTual과 같은 IaC 도구를 통해 보안 정책을 선언적으로 관리합니다. 이번 이슈는 프로바이더의 문서화된 기본값(Default)과 Keycloak 엔진 내부의 이벤트 저장 로직(isSaveByDefault) 사이의 간극에서 발생했습니다.

업계에 어떤 영향을 주나?

클라우드 네이티브 환경에서 보안 가시성(Visibility)은 사고 대응의 핵심입니다. 프로바이더의 잘못된 문서에 의존해 자동화된 환경을 구축한 기업들은 `REFRESH_TOKEN_ERROR`와 같은 이상 징후를 DB 기반 모니터링 시스템에서 놓칠 수 있는 운영 리스크를 안게 됩니다.

한국 시장에 어떤 시사점이 있나?

금융 및 핀테크 등 엄격한 보안 컴플라이언스 준수가 필요한 한국 스타트업은 IaC 설정 시 문서의 'Default' 값을 맹신하기보다, 실제 런타임에서 이벤트가 의도한 대로 저장되는지 검증하는 테스트 프로세스를 반드시 포함해야 합니다.

이 글에 대한 큐레이터 의견

이번 발견은 IaC(Infrastructure as Code)의 '선언적 자동화'가 가진 치명적인 취약점을 시사합니다. 개발자는 프로바이더의 문서를 신뢰하여 코드를 작성하지만, 실제 런타임 로직이 문서와 다르게 동작할 때 보안 가시성이 완전히 상실될 수 있습니다. 특히 `REFRESH_TOKEN_ERROR`와 같은 이벤트는 계정 탈취나 세션 하이재킹을 탐지하는 핵심 지표인데, 이것이 DB에 남지 않는다면 사후 사고 추적이 불가능해집니다.

물론, 모든 이벤트를 기본적으로 저장하는 것은 데이터베이스 부하와 스토리지 비용을 증가시킨다는 트레이드오프가 존재합니다. Keycloak의 설계 의도는 효율적인 저장일 수 있으나, IaC 프로바이더의 잘못된 문서는 이를 '모든 이벤트 활성화'로 오인하게 만들어 보안 사고의 씨앗을 제공합니다. 따라서 스타트업 창업자와 엔지니어는 자동화된 인프라 구축 시, '문서 기반 설정'에만 의존하지 말고 실제 데이터가 의도한 대로 기록되는지 확인하는 '검증 가능한 인프라(Verifiable Infrastructure)' 전략을 취해야 합니다.

원문 보기 →