기술 지원
문서
로그인
문의하기
이 블로그 글의 AI 요약으로 바로 가기 
주요 내용
- 많은 보안 취약점은 프로덕션용으로 설계되지 않은 Kafka의 기본 구성에 의존하는 데서 발생합니다.
- 수명 종료(EOL) Kafka 버전을 실행하면 시스템이 패치되지 않은 새로운 취약점에 노출되어 심각한 위험을 초래할 수 있습니다.
- Kafka 클러스터를 업그레이드할 수 없는 조직을 위해 TuxCare의 ELS(Endless Lifecycle Support) 는 EOL 버전에 대한 지속적인 보안 패치를 제공합니다.
Apache Kafka 보안의 핵심 원칙은 변하지 않았지만 위협 환경은 변했습니다. 보안팀은 이제 공격자들이 단일 지점 방어를 우회하기 위해 다양한 방법을 사용하여 더욱 능동적으로 활동한다는 사실을 알 수 있습니다. 즉, 한두 가지 보안 기능만 활성화하는 것만으로는 더 이상 충분하지 않습니다. 인증, 권한 부여, 암호화, 네트워크 제어, 패치 관리 등 모든 측면에서 보안을 강화해야 안전한 Kafka 클러스터를 구축할 수 있습니다.
이 가이드에서는 카프카 클러스터 보안을 위한 필수 모범 사례를 안내하고, 피해야 할 일반적인 실수를 나열하며, EOL 카프카 버전 실행의 위험성을 조명합니다.
Apache Kafka 보안 모범 사례
이는 모든 카프카 보안 전략에 포함되어야 하는 필수 모범 사례입니다:
1. SSL/TLS 및 SASL을 사용한 보안 인증
인증은 클라이언트의 신원을 확인하고 신뢰할 수 있는 사용자와 애플리케이션만 Kafka 클러스터에 연결할 수 있도록 하는 프로세스입니다. Kafka 클라이언트 인증은 첫 번째 방어선이 되어야 합니다. SSL/TLS와 SASL 메커니즘을 모두 활성화하는 것이 좋습니다. SSL/TLS는 클라이언트와 브로커 간의 통신을 암호화하여 통신이 손상될 수 없도록 합니다. 보안을 강화하기 위해 SASL 메커니즘은 SCRAM(사용자 이름/비밀번호) 또는 Kerberos와 같은 다양한 Kafka 클라이언트 인증 메커니즘을 위한 프레임워크를 제공하며, 연결이 설정되기 전에 자격 증명을 요구하도록 구성할 수 있습니다.
2. ACL로 세분화된 권한 부여 구현하기
클라이언트가 인증되면 클라이언트가 수행할 수 있는 작업을 제어해야 합니다. 이때 권한 부여가 중요한 역할을 합니다. Apache Kafka의 기본 제공 ACL(액세스 제어 목록)은 이를 위한 업계 표준 메커니즘입니다. ACL을 사용하면 특정 리소스(토픽, 소비자 그룹, 클러스터)에서 특정 작업(읽기, 쓰기, 생성)을 수행할 수 있는 사용자 또는 그룹에 대해 매우 세분화된 규칙을 지정할 수 있습니다. 애플리케이션이 작업을 수행하는 데 필요한 권한만 부여하고 그 이상의 권한은 부여하지 않는 최소 권한 원칙을 따르는 것이 중요합니다. 또한 시간이 지남에 따라 권한 크리프가 발생하지 않도록 정기적으로 ACL을 감사하는 것도 중요합니다.
3. 전송 중 및 미사용 데이터 암호화 보장
데이터 암호화는 모든 침해 시도에 대한 무단 침입 또는 액세스를 방지하는 보호 계층입니다. 여기서는 전송 중인 데이터와 미사용 데이터 양쪽 모두에 초점을 맞춰야 합니다. 전송 중인 데이터는 기본적으로 모든 클라이언트-브로커 및 브로커 간 통신에 SSL/TLS 암호화를 적용하여 보호합니다. 이렇게 하면 메시지가 네트워크를 통해 이동할 때 스크램블링됩니다. 미사용 데이터(예: Kafka 브로커의 디스크에 저장된 메시지)는 디스크를 암호화하거나 클라우드 제공업체의 암호화 서비스를 사용하여 보호할 수 있습니다. 이렇게 하면 공격자가 손상된 서버의 원시 데이터 파일에 단순히 액세스하는 것을 막을 수 있습니다.
4. 보안 이벤트의 정기 감사 및 모니터링
모니터링 및 감사는 의심스러운 활동을 탐지하고 실시간 위협을 완화하는 데 필요한 가시성을 제공합니다. 인증 실패 및 권한 부여 거부와 같은 보안 이벤트를 추적하도록 Kafka의 로깅 기능을 구성해야 합니다. 이러한 로그는 중앙 집중식 보안 검색 및 모니터링 시스템에 제공되어 로그인 실패 횟수가 많거나 사용자가 제한된 주제에 액세스하려고 시도하는 등 이상한 패턴을 알려줄 수 있습니다. 이러한 사전 예방적 접근 방식은 위협이 심각한 피해를 일으키기 전에 이를 식별하고 무력화할 수 있도록 도와줍니다.
Kafka 보안 배포에서 흔히 발생하는 실수
사소한 데이터 보안 문제처럼 보일 수 있는 것이 종종 Kafka 배포의 주요 취약점으로 이어질 수 있습니다. 이러한 일반적인 함정을 학습하고 적극적으로 피함으로써 클러스터를 강화하고 보안 인시던트가 발생하지 않도록 예방할 수 있습니다.
기본 구성에 의존하기
Apache Kafka는 프로덕션 환경에서의 보안이 아닌, 개발 시 사용 편의성을 위해 설정되어 있습니다. 즉, Kafka 클라이언트 인증 및 암호화와 같은 가장 중요한 보안 기능들은 기본적으로 비활성화되어 있습니다. 매우 흔한 실수 중 하나는 Kafka를 기본 구성 그대로 배포하여, 네트워크에 연결할 수 있는 누구에게나 접근의 문을 열어두는 것입니다. 이러한 환경에서는 어떤 애플리케이션이나 사용자라도 어떠한 형태의 인증이나 권한 부여 없이 클러스터에 데이터를 생성하거나, 소비하거나, 관리할 수 있습니다.
지나치게 허용적인 ACL 부여
ACL을 구현하는 것이 필수적인 모범 사례이긴 하지만 올바르게 구성한 경우에만 보호 기능을 제공합니다. 일반적인 오류는 모든 사용자에게 모든 주제에 대한 쓰기 권한을 허용하는 등 지나치게 광범위한 권한을 부여하는 것입니다. 이는 "나중에 보안을 강화하겠다"는 의도로 애플리케이션을 서둘러 작동시키려는 경우에 발생할 수 있습니다. 그러나 지나치게 광범위한 권한을 부여하면 사용자의 자격 증명을 얻은 공격자가 전체 클러스터의 민감한 데이터에 액세스하거나 조작할 수 있는 위험한 상황이 발생할 수 있습니다.
브로커 간 보안 무시
많은 보안 전략은 클라이언트와 브로커 간의 경로 보안에 초점을 맞추지만, 브로커 자체 간의 중요한 통신 보안은 소홀히 합니다. 브로커 간 통신이 안전하지 않은 경우, 공격자가 한 Kafka 브로커를 손상시키면 클러스터의 다른 브로커로 전송되는 데이터 흐름을 가로채 변조할 수 있습니다. 따라서 내부 네트워크 내에서도 데이터가 암호화되고, 변조되지 않으며, 변경되지 않도록 하려면 브로커 간 통신에 SSL/TLS를 사용해야 합니다.
간과되는 보안 과제: 수명 종료(EOL) 카프카 버전
보안 모범 사례를 적용하는 것은 필수적이지만, 많은 조직에서 무시하는 경향이 있는 중요한 보안 공백은 소프트웨어의 수명이 끝난 후에도 소프트웨어를 계속 실행하는 것입니다. Apache Kafka의 가속화된 릴리즈 주기로 인해 일반적인 엔터프라이즈 소프트웨어 수명 주기보다 훨씬 빠르게 버전 지원이 종료됩니다.
아파치 카프카(Apache Kafka) 버전이 지원 종료(EOL) 시점에 도달하면, 커뮤니티와 프로젝트 관리자들은 보안 패치 제공을 중단합니다. 이는 지원 종료일 이후에 공개되는 새로운 CVE(Common Vulnerabilities and Exposures) 는 해당 버전에 대해 공식적으로 수정되지 않을 것임을 의미합니다. 이러한 클러스터를 운영하는 조직은 모범 사례를 아무리 잘 이행했더라도 시한폭탄을 안고 있는 셈입니다. 패치되지 않은 취약점은 공격자들에게는 천국과도 같으며, 이들은 이를 적극적으로 찾아내 악용함으로써 데이터 유출, 규정 위반, 대규모 서비스 중단 등을 초래합니다.
이 문제는 주로 안정적인 특정 Kafka 버전에 구축된 미션 크리티컬 애플리케이션을 보유한 조직이 직면하는 문제입니다. 최신 버전으로의 전면적인 마이그레이션에 따른 비용과 위험 때문에 업그레이드를 고려하지 않는 경우가 많습니다. 이로 인해 비용이 많이 들고 업무에 지장을 주는 업그레이드를 감수하느냐, 아니면 보안 침해의 위험을 감수하느냐 하는 어려운 딜레마가 생깁니다.
예를 들어, Kafka 버전 3.2.3과 3.5.2는 이미 공식 커뮤니티 지원 날짜가 지났습니다. 즉, 취약성 탐지를 통해 이러한 버전에서 새로운 버그가 발견되더라도 커뮤니티에서 패치를 적용하지 않으므로 해당 버전을 사용하는 조직은 완전히 노출된 상태로 남게 됩니다.
TuxCare의 지원 방법
수명이 다한 Apache Kafka 버전으로 인한 보안 위험은 관리하기 어렵습니다. 마이그레이션이 장기적인 목표라면 이상적이지만, 즉각적인 해결책으로 마이그레이션이 불가능한 경우도 있습니다. 이러한 경우 TuxCare의 Apache Kafka용 Endless Lifecycle Support(ELS)가 종합적인 보안 전략에서 중요한 역할을 할 수 있습니다.
TuxCare의 ELS는 3.2.3 및 3.5.2와 같이 지원되지 않는 이전 Kafka 버전에 대한 지속적인 보안 패치를 제공합니다. 따라서 비용이 많이 들고 업무에 지장을 주는 전면적인 업그레이드 없이도 새로 발견된 CVE로부터 시스템을 보호하는 데 필요한 보안 업데이트를 받을 수 있습니다. 이를 통해 보안팀은 자체 타임라인에 따라 업그레이드 경로를 계획하면서 보안과 규정 준수를 유지할 수 있습니다.
자주 묻는 질문
Kafka ACL이 올바르게 작동하는지 테스트하려면 어떻게 해야 하나요?
가장 간단한 방법은 kafka-console-producer.sh 그리고 kafka-console-consumer.sh 보안 주체가 구성된 도구로 액세스해야 합니다. 액세스가 거부된 경우에는 AuthorizationException 를 클라이언트 측 로그에서 확인하여 ACL이 권한 부여를 올바르게 적용하고 있는지 확인합니다.
Kafka에서 SSL을 활성화하면 성능에 어떤 영향이 있나요?
SSL/TLS를 활성화하면 암호화 및 암호 해독 오버헤드가 추가되므로 CPU 사용량이 약간 증가하고 처리량과 지연 시간이 약간 떨어질 수 있습니다. 정확한 영향은 하드웨어, 네트워크 구성 및 JCE(Java Cryptography Extension) 설정에 따라 달라집니다.
카프카 보안 감사를 위한 오픈소스 도구가 있나요?
카프카 감사만을 위한 단일 도구는 없지만, 여러 오픈 소스 솔루션이 도움이 될 수 있습니다. Kafka-UI와 AKHQ를 사용하면 토픽 ACL을 검사하고, 소비자 그룹을 모니터링하고, 메시지 데이터를 검색할 수 있습니다. 보다 심층적인 분석을 위해 ELK Stack은 Kafka 보안 로그를 처리하고 의심스러운 활동에 대한 경고를 보낼 수 있습니다.
카프카 버전이 수명이 다하면 어떻게 되나요?
Kafka 버전이 EOL에 도달하면 커뮤니티에서 보안 패치 및 버그 수정 제공이 중단됩니다. 그 이후에 발견된 모든 취약점(CVE)은 패치되지 않은 상태로 유지되므로 클러스터가 노출됩니다. 보안 및 규정 준수를 유지하려면 지원되는 버전으로 업그레이드하거나 EOL Kafka 버전에 대한 지속적인 보안 패치를 제공하는 TuxCare의 ELS(Endless Lifecycle Support) 같은 타사 서비스를 사용해야 합니다.
