Kafka 심화) 보안

보안 프로토콜

PLAINTEXT : PLAINTEXT 전송 계층에는 인증이 존재하지 않는다. 사설 네트워크 안에서 인증이나 암호화가 필요없을 정도로 민감하지 않은 데이터를 처리할 때문 적합하다. 

 

SSL : SSL전송 계층은 선택적으로 클라이언트 SSL인증을 수행할 수 있다. 암호화 뿐만 아니라 클라이언트/서버 인증도 지원되기 때문에 안전하지 않은 네트워크에서 적절하다. 

 

SASL_PLAINTEXT : SASL 인증과 PLAINTEXT 전송계층이 합쳐진 것이다. 어떤 SASL메커니즘은 서버 인증 역시 지원한다. 암호화는 지우하지 않기 때문에 사실 네트워크 안에서만 적합하다. 

 

SASL_SSL : SASL 인증과 SSL 전송계층이 합쳐진 것이다. 암호화 뿐만아니라 클라이언트/서버 인증도 지워되기 때문에 안전하지 않은 네트워크에서 적절하다. 

 

인증

SSL

SASL

카프카 프로토콜은 SASL을 사용한 인증을 지원하며, 자주 사용되는 SASL 메커니즘을 기본적으로 지원한다. 기본적으로 다음과 같은 SASL 메커니즘과 함께 기존 보안 인프라스트럭처와 통합하기 위한 커스터마이즈 가능한 콜백을 지원한다. 

1) GSSAPI : SASL/GSSAPI 를 사용하는 케르베로스 인증이 지원되며, Active Directory나 OpenLDAP와 같은 케르베로스 서버와 통합하는데 사용될 수 있다. 

2) PLAIN : 사용자 이름/비밀번호 인증, 보통 외부 비밀번호 저장소를 사용해서 비밀번호를 검증하는 서버측 커스텀 콜백과 함께 사용된다.

3) SCRAM-SHA-256 and SCRAM-SHA-512 : 추가적인 비밀번호 저장소 같은 것을 설정할 필요없이 카프카를 설치하자마자 바로 사용할수 있는 사용자 이름/비밀번호 인증

4) OAUTHBEARER : OAuth bearer 토큰을 사용한 인증, 보통 표준화된 OAuth 서버에서 부여된 토큰을 추출하고 검증하는 커스텀 콜백과 함께 사용한다. 

 

- SASL/GSSAPI : 이 메커니즘은 GSS-API의 케르베로스 V5 메커니즘을 사용해서 인증을 수행한다. 

- SASL/PLAIN: TLS와 함께 사용될 수 있는 단순한 사용자  이름/비밀번호 인증 메커니즘을 정의한다. 카프카는 커스텀 콜백 핸들러를 사용해서 안전한 외부 비밀번호 저장소와 통합할 수 있는 안전한 SASL/PLAIN 구현체를 기본적으로 사용한다. 

- SASL/SCRAM : RFC-5802는 SASL/PLAIN처럼 비밀번호를 직접 전송하는 인증 메커니즘에서 발생하는 보안 문제에 대처할 수 있는 안전한 사용자 이름/비밀번호 인증 메커니즘을 제안한다. SCRAM은 암호화 되지 않은 비밀번호가 전송되는 것을 피하고 악의적인 사용자가 다른 사용자로 가장해서 내용을 읽어오는 것이 불가능한 형식으로 저장한다. 

- SASL/OAUTHBEARER : OAUTHBEARER는 OAuth 2.0 베어러 토큰을 사용하되 더 짧은 토큰 유효기관과 제한도니 자우 접근만 허용하는데, 이는 장기 비밀번호를 사용하는 메커니즘에서 발생하는 보안 취약점을 방지하는 효과가 있다. 카프카는 클라이언트 인증에 SASL/OAUTHBEARER를 지원하며, 서드파티 OAuth 서버와의 통합 역지 지원한다. 

- 위임토큰 : 위임토큰은 카프카 브로커와 클라이언트 사이에 공유된 비밀로써, 클라이언트에 SSL키스토어나 케르베로스 키탭 파일을 배포할 필요없는 경량 설정 메커니즘을 제공한다. 위임 토큰은 케르베로스 키 배포센터와 같은 인증 서버의 부하르 ㄹ줄이기 위해 사용될 수 도 있다. 

 

재인증

케르베로스나 OAuth와 같은 보안 메커니즘은 유효기간이 있는 자격 증명을 사용한다.카프카는 기존 자격 증명이 만료되기 전 새로운 자격 증명을 얻어오기 위해 백드라운드에서 돌아가는 로그인 스레드를 사용하지만, 새로운 자격증명은 기본적으로 새로운 연결에만 적용되도록 되어 있다. 

 

암호화

메시지를 카프카 로그에 저장되는 바이트 배열로 변환하기 위해 시리얼라이저를 사용하는 것을 보았다. 시리얼라이저와 디시리얼라이저를 직렬화 도중에 메시지를 암호화 하거나, 역직렬화 도중에 복호화를 수행할 수 있도록 암호화 라이브러리에 통합될 수 있다. 

 

1. 카프카 프로듀서를 사용해서 메시지를 보낸다.

2. 프로듀서가 KMS에 저장된 암호화 키를 사용해서 메시지를 암호화한다. 

3. 암호화된 메시지가 브로커로 전달된다. 브로커는 암호화된 메시지를 파티션 로그에 저장한다. 

4. 브로커가 암호화된 메시지를 컨슈머로 보낸다. 

5. 컨슈머가 KMS에 저장된 암호화 키를 사용해서 메시지를 복호화 시킨다. 

 

인가

AclAuthorizer

AclAuthorizer는 접근 제어 목록을 사용해서 카프카 자원에 대한 접근을 세밀하게 제어할 수 있도록 해준다. ACL은 주키퍼에 저장되는데, 요청ㅇ르 빠르게 인가할 수 있게 하기 위해 모든 브로커의 메모리에 캐시한다. 

 

카프카 ACL과 부여되는 접근 권한

https://docs.confluent.io/platform/current/security/authorization/acls/overview.html#token-resource-type-operations

Use access control lists (ACLs) for authorization in Confluent Platform | Confluent Documentation

 

Cluster resource operations

Alter	Cluster	AlterReplicaLogDirs, CreateAcls, DeleteAcls
AlterConfigs	Cluster	AlterConfigs
ClusterAction	Cluster	Fetch (for replication only), LeaderAndIsr, OffsetForLeaderEpoch, StopReplica, UpdateMetadata, ControlledShutdown, WriteTxnMarkers
Create	Cluster	CreateTopics, Metadata
Describe	Cluster	DescribeAcls, DescribeLogDirs, ListGroups
DescribeConfigs	Cluster	DescribeConfigs

 

Topic resource type operations

Alter	Topic	CreatePartitions
AlterConfigs	Topic	AlterConfigs
Create	Topic	CreateTopics, Metadata
Delete	Topic	DeleteRecords, DeleteTopics
Describe	Topic	ListOffsets, Metadata, OffsetFetch, OffsetForLeaderEpoch
DescribeConfigs	Topic	DescribeConfigs
Read	Topic	Fetch, OffsetCommit, TxnOffsetCommit
Write	Topic	Produce, AddPartitionsToTxn

 

Group resource type operations

Delete	Group	DeleteGroups
Describe	Group	DescribeGroup, FindCoordinator, ListGroups
Read	Group	AddOffsetsToTxn, Heartbeat, JoinGroup, LeaveGroup, OffsetCommit, OffsetFetch, SyncGroup, TxnOffsetCommit

Token resource type operations

Describe

DelegationToken

DescribeTokens

 

Transactional ID resource type operations

Describe	TransactionalId	FindCoordinator
Write	TransactionalId	Produce, AddPartitionsToTxn, AddOffsetsToTxn, EndTxn, InitProducerId, TxnOffsetCommit