KangHun-Lee
commented
3 days ago 보안
안전한 카프카 클러스터 특징
- 클라이언트 진정성 (client authenticity)
- 서버 진정성 (server authenticity)
- 기밀성 (data privacy)
- 무결성 (data integrity)
- 접근 제어 (access control)
- 감사 가능성 (auditability)
- 가용성 (availability)
보안 프로토콜
전송계층 :
PLAINTEXT,SSL인증계층 :
SSL,SASL
- PLAINTEXT
- 인증이 존재하지 않음
- 사설 네트워크 안에서 인증이나 암호화 없이 민감하지 않은 데이터를 처리 할 때 적합
- SSL
- 선택적으로 클라이언트 SSL 인증을 수행할 수 있음
- 암호화뿐만 아니라 클라이언트/서버 인증도 지원
- SASL_PLAINTEXT
- 서버 인증 지원
- 암호화는 지원하지 않음. 사설 네트워크 안에서만 적합
- SASL_SSL
- 암호화 지원
- 클라이언트/서버 인증 지원
- 안전하지 않은 네트워크에서 적절
SSL, SASL 어떤 것이 더 좋냐?
둘의 목표가 다름
SSL 은 종단 간 교환 되는 메시지를 안전하게 보호하는 것이 목표
SASL 은 종단 간 사용할 인증 방식을 서로 합의할 수 있도록 해주는 프레임워크 (구체적인 인증작업은 GSSAPI, OAUTHBEARER 등 인증 프로토콜 구현)
Inter.broker.listener.name, security.inter.broker.protocol 설정을 사용하여 브로커간 통신시 사용되는 리스너 선택 가능
(자세한 설정은 p.300 참조)
인증
인증 키 생성 및 카프카 설정
p.301 ~ p.306 서버에서 키 생성하고 카프카 설정하는 것은 DevOps 형님들 몫이니 참고용
서버 쪽 키 저장소는 동적으로 갱신해 줄 수 있지만 kafka-configs.sh 사용(카프카 설치시 bin 디렉토리 내에 존재)
클라이언트는 재시작하는 것 외엔 방법이 없음
보안을 강화하기 위해 인증서의 유효기간 등을 동적으로 업데이트하는 기법을 사용한다면 이야기가 달라짐
리밸런싱이 발생함으로 작업이 지연 될 수도 있음
SASL
- GSSAPI
- 케로베로스 인증 지원
TLS 가 사용되지 않는 경우 사전 공격, 무작위 암호 대입 공격을 위한 충분한 정보 획득 가능
파일 시스템 권한을 적절히 설정함으로써, 키탭 파일에 대한 접근 역시 제한해야함
누출이 발생했을 때 누구 소행인지 특정하기 어려움
-
PLAIN
-
사용자 이름/비밀번호 인증
-
외부 비밀번호 저장소를 사용해서 비밀번호를 검증한느 서버측 커스텀 콜백과 함께 사용됨
-
안전한 전송 계층을 보장하기 위해 PLAIN 메커니즘 활성화시 SASL_SSL 암호화 설정 역시 켜줘야함
-
SCRAM-SHA-256 and SCRAM-SHA-512
-
사용자 이름/비밀번호 인증
-
카프카를 설치하자마자 바로 사용 가능
-
반드시 SASL_SSL 보안 프로토콜과 함께 사용되야함
주키퍼 역시 SSL 기능을 켜야함
-
OAUTHBEARER
-
OAuth bearer 토큰을 사용한 인증
-
OAuth 서버에서 부여된 토큰을 추출하고 검증하는 커스텀 콜백과 함께 사용
-
재인증
- 카프카 브로커는 connections.max.reauth.ms 설정 옵션을 통해 SASL로 인증된 연결을 재인증할 수 있도록 함
- 이 옵션의 설정값을 0보다 큰 정숫값으로 설정하면 카프카 브로커는 SASL 연결의 세션 수명을 체크하고 있다가 SASL 핸드셰이크를 수행할 때 클라이언트에게 알려줌
- 세션 수명 : 자격 증명의 잔여 수명과 connections.max.reauth.ms 값 중 작은 값
무중단 보안 업데이트
-
Rolling Update: 보안 패치를 적용할 때 카프카 클러스터의 브로커들을 순차적으로 업데이트하여 서비스를 중단하지 않고 진행
-
SSL 키스토어/트러스트스토어 업데이트: 브로커 재시작 없이 동적으로 SSL 설정을 갱신할 수 있음
-
사용중인 클러스터에 새로운 보안 프로토콜을 추가할 때는 기존 브로커와의 호환성 유지를 위해 리스너 설정을 주의해야 함
보안 프로토콜 업데이트 절차
-
새로운 리스너를 추가할 때
listeners와advertised.listeners설정을 활용 -
브로커 간 통신에 필요한 리스너 업데이트는
inter.broker.listener.name을 통해 조정 가능 -
SASL 메커니즘을 PLAIN에서 SCRAM-SHA-256으로 교체하는 과정에서는 브로커 설정을 동적으로 적용할 수 있음
SCRAM-SHA-256 사용 절차
-
SCRAM 저장소에 사용자를 추가하고, 리스너 설정에서 SCRAM-SHA-256을 활성화
-
모든 클러스터에 SCRAM 설정을 적용한 후, 이전 PLAIN 설정을 삭제하여 보안 강화
암호화
- 암호화 목적: 데이터의 기밀성과 무결성을 보장하기 위해 SSL, SASL_SSL을 사용하여 전송 계층의 보호 및 저장된 데이터를 안전하게 유지
- FIPS 준수: 데이터 암호화가 필요한 규제를 준수하기 위해 추가적인 보안 조치를 적용할 수 있음
- 디스크 암호화: 로그에 저장된 데이터를 암호화하여 물리적으로 접근할 수 없는 환경을 구축
종단 암호화 (End-to-End Encryption)
- 종단 암호화: 데이터가 카프카를 통해 전송되는 동안 암호화되어 중간 단계에서 노출되지 않도록 함
- 암호화 및 복호화 과정: 프로듀서와 컨슈머 간에 KMS(Key Management System)를 통해 키를 관리하며 암호화된 데이터를 처리함
- 키 회전: 주기적으로 암호화 키를 교체하여 보안을 강화
인가
-
AclAuthorizer: ACL(Access Control List)을 사용하여 자원에 대한 접근 제어를 설정. 사용자가 특정 자원에 대해 수행할 수 있는 작업을
Allow또는Deny를 통해 설정할 수 있음. -
SimpleAclAuthorizer: 카프카 2.0 이후 기본 제공되는 인가 기능으로, 주로 리소스에 대한 ACL을 관리하는 데 사용됨.
AclAuthorizer 설정
-
리소스 유형: 클러스터, 토픽, 그룹 등의 리소스에 대해 접근 권한을 설정할 수 있음
-
패턴 유형: 리터럴(Literal)과 접두사(Prefixed)를 사용하여 특정 리소스나 그룹을 지정 가능
-
작업 권한:
Read,Write,Describe,Alter,Delete등의 작업에 대해 권한을 부여하거나 제한할 수 있음 -
ACL 예시 : 예를 들어, User에게 특정 토픽에 대해 쓰기 권한을 부여하는 방식으로 설정 가능
인가 기능 커스터마이즈
-
CustomAuthorizer: 기본 제공되는
AclAuthorizer를 확장하여 커스텀 권한 관리 기능을 구현할 수 있음 -
RbacAuthorizer: 역할 기반 접근 제어(Role-Based Access Control)를 지원, 특정 그룹이나 역할에 따라 권한을 설정할 수 있음
-
커스터마이징 예시: 내부 리소스에 대해 특정 사용자 또는 그룹에 맞춤형 역할과 접근 권한을 부여 가능(p.331 ~ 332 참고)
감사
- 로그 감사: Kafka는
log4j를 사용하여 감사와 디버깅 목적의 로그를 생성.kafka.authorizer.logger를 통해 인가 관련 로그를 기록할 수 있음 - 로그 예시: 로그를 통해 성공/실패한 접근 시도에 대한 정보를 제공하며, 이를 기반으로 의심스러운 활동을 탐지 가능
주키퍼 보안
-
SASL 인증: 주키퍼의 보안을 강화하기 위해 SASL과 같은 인증 메커니즘을 설정
-
SSL 설정: 주키퍼에 SSL을 설정하여 통신 중 데이터를 암호화, 클라이언트와 브로커 간의 안전한 연결을 보장
-
ACL 적용: 주키퍼 노드에 대한 접근 제어를 위해 ACL을 설정하여 데이터를 보호
플랫폼 보안
- 위협 모델링: 전체 시스템의 잠재적인 위험 요소를 분석하고 이를 기반으로 보안 방식을 설계
- 비밀번호 보호: 비밀번호를 안전하게 관리하기 위한 커스터마이즈 가능한 설정 제공
CHOICORE
zinokim
iamzin
hubtwork
kimsunhak
Chapter Ownership : @KangHun-Lee