TIL

9.1 카프카 보안의 세 가지 요소

• 카프카는 최초 설치 과정에서 보안이 설정되지 않는다.
  • 어떤 클라이언트든 통신만 가능하다면 자유롭게 카프카와 연결 가능하다.
    • 외부의 악의적인 접근으로부터 유출의 위험이 있다.
  • 카프카와 연결 가능한 모든 클라이언트들은 모든 권한을 갖는다.
    • 모든 토픽에 메시지를 전송 또는 가져갈 수 있다.
    • 실수로 다른 서비스에서 사용하는 토픽으로 메시지를 보내버리면 데이터 정합성 문제가 발생할 수 있다.
  • 클라이언트와 카프카 간의 통신이 암호화되어 있지 않다.
    • 악의적입 접근이 통신에 끼어들어 패킷을 가로채면 데이터가 노출된다.
• 때문에 카프카에선 세 가지 보안 요소가 필요하다.
  • 암호화 - 패킷을 가로채더라도 암호화를 통해 데이터를 읽을 수 없게 함
  • 인증 - 클라이언트들이 카프카로 접근할 때 확인된 클라이언트만 접근할 수 있도록 설정
  • 권한 - 특정 클라이언트에게만 특정 토픽으로 데이터를 읽고 쓸 수 있는 권한을 부여

9.1.1 암호화(SSL)

• 암호화 통신을 위해 일반적으로 SSL을 사용한다.
  • SSL - Secure Socket Layer의 약자로 서버 클라이언트 통신 보안의 표준 암호 규약
• SSL 동작
  • 인증기관으로부터 인증서를 발급
  • 인증서를 이용한 공개 키, 개인 키 방식으로 서버와 클라이언트가 암호화, 복호화를 하면서 통신
  • 대칭키 방식과 비대칭키 두 가지 방식을 혼용하는 방식을 사용

9.1.2 인증(SASL)

• SASL(Simple Authentication and Security Layer)
  • 인터넷 프로토콜에서 인증과 데이터 보안을 위한 프레임워크
• 카프카에선 다음 네 가지 SASL 메커니즘을 지원한다.
  • SASL/GSSAPI
    • GSSAPI는 커버로스 인증 방식으로 많이 사용되며 사내에 별도 커버로스 서버가 있다면 가장 좋은 선택
    • 커버로스 인증 방식엔 렐름이라는 설정이 필요한데 되도록 하나의 렐름을 사용하는 것을 추천
    • 크로스 렐름으로 인해 재인증, 인증 실패가 종종 일어나기 때문
  • SASL/PLAIN
    • 아이디와 비밀번호를 텍스트 형태로 사용하는 방법
    • 운영 환경보단 개발 환경에서 테스트 등 목적으로 활용
  • SASL/SCREAM-SHA-256, SASL/SCREAM-SHA-512
    • 본래 암호에 해시된 내용을 추가하는 방식으로 인증 정보를 주키퍼에 저장
    • 토큰 방식도 지원하므로 커버로스가 없는 환경에서 좋은 선택
  • SASL/OAUTHBEARER
    • OAUTH 방식은 최근 인증에서 많이 사용되지만 카프카에선 매우 한정적이기에 개발 환경 정도에 활용 가능하다.

커버로스(Kerberos) 서버는 티켓 기반의 컴퓨터 네트워크 인증 암호화 프로토콜을 제공하는 서버를 말한다. 사용자의 신원을 안전하게 확인하고, 네트워크 상의 여러 서비스에 한 번의 로그인으로 접근할 수 있도록 돕는 통합 인증(SSO, Single Sign-On) 기능을 주로 담당한다.

9.1.3 권한(ACL)

• ACL은 접근 제어 리스트(Access Control List)의 약자로 규칙 기반 리스트로 접근을 제어하는 것이다.
• 카프카 클라이언트들이 모두 동일한 권한을 갖는 것에는 장단점이 있다.
  • 장점 - 손쉽게 자신이 원하는 데이터를 가져가면서 불필요한 커뮤니케이션 비용이 들지 않는다.
  • 단점 - 다른 팀/부서의 토픽에 데이터를 실수로 전송하는 일이 발생하면 해당 토픽 컨슈머는 파싱 에러나 정합성 오류가 발생하는 등의 여러 문제가 발생할 수 있다.
• 카프카에선 간단히 CLI로 ACL을 추가하거나 삭제할 수 있다.
• ACL은 리소스 타입별로 구체적인 설정이 가능하다.
  • 토픽, 그룹, 클러스터, 트랜잭셔널 ID, 위임 토큰 등