설명
Amazon MSK는 저장 데이터를 항상 암호화합니다. 생성 시 KMS 키를 지정하지 않으면 AWS 관리형 키를 사용하며, 기본적으로 클라이언트·브로커 통신은 TLS만 허용하고 브로커 간 통신도 암호화합니다. EncryptionInfo를 생략했다는 이유만으로 데이터가 평문으로 저장되거나 전송된다고 볼 수는 없습니다.
다만 클라이언트 통신에 PLAINTEXT 또는 TLS_PLAINTEXT를 허용하거나 InCluster를 끄면 평문 통신이 가능해집니다. TLS 암호화와 별도로 클라이언트 인증, 토픽 권한과 네트워크 접근도 제한해야 합니다.
잠재적 영향
평문 통신 경로에 접근할 수 있는 공격자는 메시지나 민감정보를 엿보거나 변경할 수 있습니다. 키를 비활성화하거나 필요한 권한을 제거하면 저장 데이터 접근과 서비스 운영에 장애가 생길 수 있습니다.
해결 방법
- 클라이언트의 TLS 연결을 준비하고
ClientBroker: TLS,InCluster: true를 사용하세요. 정상 생산자·소비자의 연결과 권한을 확인하세요. - 조직의 키 관리 요구사항에 따라 기본 키 또는 고객 관리형 키를 선택하고 필요한 키 권한을 유지하세요.
- 기존 클러스터는 변경 세트를 확인하세요. CloudFormation에서
InCluster변경은 교체를 요구하므로 데이터 이전과 클라이언트 전환을 계획해야 합니다.
예시
생성 시 기본값과 명시적 설정을 비교합니다. 지원되는 Kafka 버전, 서로 다른 세 가용 영역의 서브넷과 적절한 보안 그룹을 제공하세요. 클라이언트 인증·권한은 별도로 구성해야 합니다.
암호화 기본값 사용
yaml
Parameters:
KafkaVersion:
Type: String
BrokerSubnets:
Type: List<AWS::EC2::Subnet::Id>
BrokerSecurityGroups:
Type: List<AWS::EC2::SecurityGroup::Id>
Resources:
TestCluster:
Type: AWS::MSK::Cluster
Properties:
ClusterName: ClusterWithAllProperties
KafkaVersion: !Ref KafkaVersion
NumberOfBrokerNodes: 3
BrokerNodeGroupInfo:
InstanceType: kafka.m5.large
ClientSubnets: !Ref BrokerSubnets
SecurityGroups: !Ref BrokerSecurityGroups
기본 저장 암호화와 TLS 설정을 사용합니다. 이 구성만으로 평문 통신이 허용된다고 판단하지 마세요.
암호화 설정과 키 명시
yaml
Parameters:
KafkaVersion:
Type: String
BrokerSubnets:
Type: List<AWS::EC2::Subnet::Id>
BrokerSecurityGroups:
Type: List<AWS::EC2::SecurityGroup::Id>
DataKeyArn:
Type: String
Resources:
TestCluster:
Type: AWS::MSK::Cluster
Properties:
ClusterName: ClusterWithAllProperties
KafkaVersion: !Ref KafkaVersion
NumberOfBrokerNodes: 3
EncryptionInfo:
EncryptionAtRest:
DataVolumeKMSKeyId: !Ref DataKeyArn
EncryptionInTransit:
ClientBroker: TLS
InCluster: true
BrokerNodeGroupInfo:
InstanceType: kafka.m5.large
ClientSubnets: !Ref BrokerSubnets
SecurityGroups: !Ref BrokerSecurityGroups
전송 설정과 실제 KMS 키 ARN을 명시합니다. 키 권한을 확인하고, 기존 클러스터에 적용할 때는 교체 여부와 전환 절차를 검토하세요.