보안

보안 (Security)

Cassandra가 제공하는 보안 기능에는 세 가지 주요 구성 요소가 있습니다:

  • 클라이언트 및 노드 간 통신을 위한 TLS/SSL 암호화
  • 클라이언트 인증
  • 권한 부여(Authorization)

기본적으로 이 기능들은 비활성화되어 있는데, Cassandra는 클러스터의 다른 멤버를 쉽게 찾고 발견되도록 구성되어 있기 때문이에요. 즉 기본 설치된 Cassandra는 공격자에게 큰 공격 표면을 제공합니다. 바이너리 프로토콜을 사용하는 클라이언트에 대해 인증을 활성화하는 것만으로는 클러스터를 보호하기에 충분하지 않습니다. 노드 간 통신과 JMX 포트에 접근할 수 있는 악의적인 사용자는 여전히 다음을 할 수 있어요:

  • 인증 스키마에 사용자를 삽입하는 노드 간 메시지 제작
  • 스키마를 잘라내거나 삭제하는 노드 간 메시지 제작
  • sstableloader 같은 도구를 사용해 system_auth 테이블 덮어쓰기
  • 쓰기 트래픽을 캡처하기 위해 클러스터에 직접 연결

세 보안 구성 요소를 모두 올바르게 구성하면 이러한 벡터를 무효화해야 합니다. 따라서 Cassandra의 보안 기능을 이해하는 것은 클러스터를 보안 요구에 맞게 구성하는 데 중요합니다.

출처: 문서

본문

TLS/SSL 암호화

Cassandra는 클라이언트 머신과 데이터베이스 클러스터 사이, 그리고 클러스터 내 노드 사이에 보안 통신을 제공합니다. 암호화를 활성화하면 전송 중(in flight) 데이터가 손상되지 않고 안전하게 전송됩니다. 클라이언트-노드 및 노드-노드 암호화 옵션은 별도로 관리되며 독립적으로 구성될 수 있어요.

두 경우 모두 암호화가 활성화되면 지원되는 프로토콜과 암호 스위트에 대한 JVM 기본값이 사용됩니다. 이는 cassandra.yaml의 설정으로 재정의할 수 있지만, 특정 설정을 지시하는 정책이 있거나 JVM을 업데이트할 수 없는 경우 취약한 암호나 프로토콜을 비활성화해야 하는 경우가 아니라면 권장되지 않습니다.

FIPS 호환 설정은 JVM 수준에서 구성할 수 있으며 cassandra.yaml의 암호화 설정을 변경해서는 안 됩니다. FIPS에 대한 자세한 내용은 java 문서를 참고하세요.

Cassandra는 Java 기반 키 자료를 사용하거나 SSL 컨텍스트를 완전히 사용자 정의할 수 있는 유연성을 제공합니다. Java가 지원하는 어떤 키스토어 형식(JKS, PKCS12 등)뿐 아니라 PEM 같은 다른 표준도 선택할 수 있어요. SSL 컨텍스트 생성을 사용자 정의해 Kuberenetes Secrets 같은 Cloud Native 기술로 키 자료를 저장하거나 사내 Key Management System과 통합할 수도 있습니다.

SSL 통신에서 사용되는 Java 지원 키스토어와 함께 필요한 키스토어·트러스트스토어 파일 생성에 대한 정보는 키스토어 생성에 관한 java 문서를 참고하세요.

SSL 컨텍스트 생성을 사용자 정의하려면 ISslContextCreationFactory 인터페이스를 구현하거나 공개 하위 클래스 중 하나를 적절히 확장하면 됩니다. 그런 다음 server_encryption_options 또는 client_encryption_options 섹션에서 ssl_context_factory 설정을 사용할 수 있어요. 자세한 내용은 ssl-factory 예제를 참고하세요. 클래스 계층을 이해하려면 아래 클래스 다이어그램을 참고하세요.

PEM 기반 키 자료 사용

내장된 PEMBasedSSLContextFactory 클래스를 PEM 기반 키 자료의 ssl_context_factory 설정으로 사용할 수 있습니다.

이 팩토리를 인라인 PEM 데이터 또는 아래처럼 필요한 PEM 데이터를 가진 파일로 구성할 수 있어요.

  • 구성: PEM 키/인증서가 인라인으로 정의됨(YAML의 공백에 주의!)
   client/server_encryption_options:
     ssl_context_factory:
        class_name: org.apache.cassandra.security.PEMBasedSslContextFactory
        parameters:
            private_key: |
             [REDACTED PRIVATE KEY] OR -----END PRIVATE KEY-----
             -----BEGIN CERTIFICATE-----
             <your base64 encoded certificate chain>
             -----END CERTIFICATE-----

            private_key_password: "<your password if the private key is encrypted with a password>"

            trusted_certificates: |
              -----BEGIN CERTIFICATE-----
              <your base64 encoded certificate>
              -----END CERTIFICATE-----
  • 구성: PEM 키/인증서가 파일에 정의됨
    client/server_encryption_options:
     ssl_context_factory:
        class_name: org.apache.cassandra.security.PEMBasedSslContextFactory
     keystore: <file path to the keystore file in the PEM format with the private key and the certificate chain>
     keystore_password: "<your password if the private key is encrypted with a password>"
     truststore: <file path to the truststore file in the PEM format>

SSL 인증서 핫 리로딩

Cassandra 4부터 Cassandra는 SSL 인증서의 핫 리로딩을 지원합니다. Cassandra에서 SSL/TLS 지원이 활성화되어 있고 기본 파일 기반 키 자료를 사용한다면, 노드는 주기적으로(10분마다) cassandra.yaml에 지정된 Trust 및 Key Store를 폴링합니다. 파일이 업데이트되면 Cassandra가 다시 로드해 후속 연결에 사용합니다. Trust 및 Key Store 비밀번호는 yaml의 일부이므로 업데이트된 파일도 같은 비밀번호를 사용해야 한다는 점을 유의하세요.

ssl_context_factory 설정으로 SSL 구성을 사용자 정의한다면 Cassandra는 (위에서 언급한 것과 같은 주기로) SSL 인증서를 다시 로드해야 하는지 확인하기 위해 구현을 폴링합니다. 자세한 내용은 ISslContextFactory 문서를 참고하세요. 파일 기반 키 자료와 함께 Cassandra 내장 SSL 컨텍스트 팩토리 클래스(예: PEMBasedSslContextFactory) 중 하나를 사용한다면 위에서 언급한 대로 SSL 인증서 핫 리로딩을 지원합니다.

인증서 핫 리로딩은 nodetool reloadssl 명령으로도 트리거할 수 있습니다. 변경된 인증서를 Cassandra가 즉시 인지하도록 하려면 이것을 사용하세요.

노드 간 암호화 (Inter-node Encryption)

노드 간 암호화를 관리하는 설정은 cassandra.yaml의 server_encryption_options 섹션에서 찾을 수 있어요. 노드 간 암호화를 활성화하려면 internode_encryption 설정을 기본값 none에서 rack, dc, all 중 하나로 변경하세요.

클라이언트-노드 암호화

클라이언트-노드 암호화를 관리하는 설정은 cassandra.yaml의 client_encryption_options 섹션에서 찾을 수 있어요. 암호화를 활성화하기 위한 두 가지 기본 토글이 있습니다: enabled와 optional.

  • 둘 다 true로 설정되지 않으면 클라이언트 연결은 완전히 암호화되지 않습니다.
  • enabled가 true이고 optional이 false이면 모든 클라이언트 연결이 보안되어야 합니다.
  • 두 옵션 모두 true이면 같은 포트를 사용해 암호화 및 비암호화 연결이 모두 지원됩니다. 이 구성으로 암호화를 사용하는 클라이언트 연결은 서버가 자동으로 감지해 처리합니다.

optional 설정의 대안으로, 운영 요구 사항에 따라 보안 및 비보안 연결에 별도의 포트를 구성할 수도 있습니다. 이렇게 하려면 optional을 false로 설정하고 cassandra.yaml의 native_transport_port_ssl 설정으로 보안 클라이언트 통신에 사용할 포트를 지정하세요.

역할 (Roles)

Cassandra는 인증과 권한 관리 모두에서 데이터베이스 역할을 사용합니다. 이는 단일 사용자 또는 사용자 집단을 나타낼 수 있어요. 역할 관리는 Cassandra의 확장 지점이며 cassandra.yaml의 role_manager 설정으로 구성할 수 있습니다. 기본 설정은 system_auth 키스페이스의 테이블에 역할 정보를 저장하는 구현인 CassandraRoleManager를 사용합니다.

CQL 역할 문서도 참고하세요.

인증 (Authentication)

인증은 Cassandra에서 플러그 가능하며 cassandra.yaml의 authenticator 설정으로 구성됩니다. Cassandra는 기본 배포판에 포함된 두 가지 옵션과 함께 제공됩니다.

기본적으로 Cassandra는 아무 인증 검사를 수행하지 않아 자격 증명이 필요 없는 AllowAllAuthenticator로 구성됩니다. 이는 인증을 완전히 비활성화하는 데 사용됩니다. 인증은 Cassandra 권한 하위 시스템의 필요 조건이므로, 인증이 비활성화되면 사실상 권한도 비활성화됩니다.

기본 배포판에는 시스템 테이블에 암호화된 자격 증명을 저장하는 PasswordAuthenticator도 포함됩니다. 이는 간단한 사용자 이름/비밀번호 인증을 활성화하는 데 사용할 수 있어요.

비밀번호 인증 활성화

클러스터에서 클라이언트 인증을 활성화하기 전에 클라이언트 애플리케이션에 의도한 자격 증명을 미리 구성해야 합니다. 연결이 시작될 때 인증이 활성화된 후에만 서버가 자격 증명을 묻기 때문에, 클라이언트 측 구성을 미리 설정하는 것은 안전합니다. 반대로 서버가 인증을 활성화하는 즉시 적절한 자격 증명이 없는 모든 연결 시도는 거부되어 클라이언트 애플리케이션에 가용성 문제를 일으킬 수 있어요. 클라이언트가 설정되어 인증 활성화 준비가 되면, 이 절차를 따라 클러스터에서 활성화하세요.

초기 구성을 수행할 클러스터의 단일 노드를 고르세요. 이상적으로는 설정 과정 중 어떤 클라이언트도 이 노드에 연결하지 않아야 하므로, 클라이언트 구성에서 제거하거나 네트워크 수준에서 차단하거나 이 용도로 클러스터에 새 임시 노드를 추가할 수도 있어요. 그 노드에서 다음 단계를 수행하세요:

  • cqlsh 세션을 열고 system_auth 키스페이스의 복제 계수를 변경합니다. 기본적으로 이 키스페이스는 SimpleReplicationStrategy와 복제 계수 1을 사용합니다. 노드가 사용 불가능해져도 로그인이 여전히 가능하도록 확실히 하려면 사소하지 않은 배포에서 이를 변경하는 것이 좋습니다. 모범 사례는 DC당 복제 계수 3에서 5로 구성하는 것입니다.
ALTER KEYSPACE system_auth WITH replication = {'class': 'NetworkTopologyStrategy', 'DC1': 3, 'DC2': 3};
  • cassandra.yaml을 편집해 authenticator 옵션을 이렇게 변경합니다:
authenticator: PasswordAuthenticator
  • 노드를 다시 시작합니다.
  • 기본 슈퍼유저의 자격 증명으로 새 cqlsh 세션을 엽니다:
$ cqlsh -u cassandra -p cassandra
  • 로그인 중 기본 슈퍼유저의 자격 증명은 QUORUM 일관성 수준으로 읽히는 반면, 다른 모든 사용자(슈퍼유저 포함)의 자격 증명은 LOCAL_ONE으로 읽힙니다. 성능과 가용성, 보안을 위해 운영자는 다른 슈퍼유저를 만들고 기본값을 비활성화해야 합니다. 이 단계는 선택사항이지만 강력히 권장됩니다. 기본 슈퍼유저로 로그인한 상태에서 추가 구성을 부트스트랩하는 데 사용할 수 있는 다른 슈퍼유저 역할을 만드세요.
# create a new superuser
CREATE ROLE dba WITH SUPERUSER = true AND LOGIN = true AND PASSWORD = 'super';
  • 새 cqlsh 세션을 시작하고, 이번에는 새 슈퍼유저로 로그인해 기본 슈퍼유저를 비활성화합니다.
ALTER ROLE cassandra WITH SUPERUSER = false AND LOGIN = false;
  • 마지막으로 CREATE ROLE 문으로 애플리케이션 사용자에 대한 역할과 자격 증명을 설정합니다.

이 단계가 끝나면 노드 하나가 비밀번호 인증을 사용하도록 구성됩니다. 클러스터 전체에 배포하려면 각 노드에서 2단계와 3단계를 반복하세요. 모든 노드가 다시 시작되면 클러스터 전체에서 인증이 완전히 활성화됩니다.

PasswordAuthenticator를 사용하려면 CassandraRoleManager도 필요하다는 점을 유의하세요.

내부 인증을 위한 자격 증명 설정, CREATE ROLE, ALTER ROLE, ALTER KEYSPACE, GRANT PERMISSION도 참고하세요.

권한 부여 (Authorization)

권한 부여는 Cassandra에서 플러그 가능하며 cassandra.yaml의 authorizer 설정으로 구성됩니다. Cassandra는 기본 배포판에 포함된 두 가지 옵션과 함께 제공됩니다.

기본적으로 Cassandra는 어떤 검사도 수행하지 않아 사실상 모든 역할에 모든 권한을 부여하는 AllowAllAuthorizer로 구성됩니다. 이는 AllowAllAuthenticator가 구성된 authenticator일 때 사용해야 합니다.

기본 배포판에는 전체 권한 관리 기능을 구현하고 데이터를 Cassandra 시스템 테이블에 저장하는 CassandraAuthorizer도 포함됩니다.

내부 권한 부여 활성화

권한은 화이트리스트로 모델링되며, 주어진 역할은 기본적으로 어떤 데이터베이스 리소스에도 접근할 수 없다고 가정합니다. 이 의미는 노드에서 권한 부여가 활성화되면 필요한 권한이 부여될 때까지 모든 요청이 거부된다는 것입니다. 이런 이유로 클라이언트 요청을 처리하지 않는 노드에서 초기 설정을 수행하는 것을 강력히 권장합니다.

다음은 비밀번호 인증에서 설명한 과정으로 인증이 이미 활성화되었다고 가정합니다. 클러스터 전체에서 내부 권한 부여를 활성화하려면 다음 단계를 수행하세요:

  • 선택된 노드에서 cassandra.yaml을 편집해 authorizer 옵션을 이렇게 변경합니다:
authorizer: CassandraAuthorizer
  • 노드를 다시 시작합니다.
  • 슈퍼유저 자격 증명을 가진 역할의 자격 증명으로 새 cqlsh 세션을 엽니다:
$ cqlsh -u dba -p super
  • GRANT PERMISSION 문으로 클라이언트에 대한 적절한 접근 권한을 구성합니다. 다른 노드에서는 구성이 업데이트되고 노드가 다시 시작될 때까지 효과가 없으므로 클라이언트에 대한 중단이 피해집니다.
GRANT SELECT ON ks.t1 TO db_user;
  • 필요한 모든 권한이 부여되면 각 노드에서 1단계와 2단계를 차례로 반복합니다. 각 노드가 다시 시작되고 클라이언트가 다시 연결되면 부여된 권한의 집행이 시작됩니다.

GRANT PERMISSION, GRANT ALL, REVOKE PERMISSION도 참고하세요.

캐싱 (Caching)

인증과 권한 부여를 활성화하면 system_auth 테이블을 자주 읽어 클러스터에 추가 부하를 가합니다. 더욱이 이러한 읽기는 많은 클라이언트 연산의 중요 경로에 있어 서비스 품질에 심각한 영향을 줄 잠재력이 있습니다. 이를 완화하기 위해 자격 증명, 권한, 역할 세부 정보 같은 인증 데이터는 구성 가능한 기간 동안 캐시됩니다. 캐싱은 cassandra.yaml 또는 JMX 클라이언트에서 구성(및 비활성화)할 수 있습니다. JMX 인터페이스는 다양한 캐시의 무효화도 지원하지만, JMX를 통해 변경된 내용은 영구적이지 않으며 노드가 다시 시작될 때 cassandra.yaml에서 다시 읽힙니다.

각 캐시에는 설정할 수 있는 3가지 옵션이 있습니다:

유효 기간 (Validity Period) 캐시 항목의 만료를 제어합니다. 이 기간이 지나면 항목이 무효화되고 캐시에서 제거됩니다.

새로고침 속도 (Refresh Rate) 기본 데이터의 변경을 수집하기 위해 백그라운드 읽기가 수행되는 속도를 제어합니다. 이 비동기 새로고침이 수행되는 동안 캐시는 (어쩌면) 오래된 데이터를 계속 제공합니다. 보통 유효 기간보다 짧은 시간으로 설정됩니다.

최대 항목 수 (Max Entries) 캐시 크기의 상한을 제어합니다.

cassandra.yaml에서 이 옵션들의 명명은 다음 규약을 따릅니다:

  • <type>_validity_in_ms
  • <type>_update_interval_in_ms
  • <type>_cache_max_entries

여기서 <type>은 credentials, permissions, roles 중 하나입니다.

언급한 대로 이들은 org.apache.cassandra.auth 도메인의 mbeans에서 JMX로도 노출됩니다.

JMX 접근

JMX 클라이언트에 대한 접근 제어는 CQL과 별도로 구성됩니다. 인증과 권한 부여 모두에 두 공급자가 사용 가능합니다. 첫 번째는 표준 JMX 보안에 기반하고, 두 번째는 Cassandra 자체 인증 하위 시스템과 더 밀접하게 통합됩니다.

Cassandra의 기본 설정은 JMX를 localhost에서만 접근 가능하게 만듭니다. 원격 JMX 연결을 활성화하려면 cassandra-env.sh를 편집해 LOCAL_JMX 설정을 no로 변경하세요. 표준 구성에서 원격 JMX 연결이 활성화되면 표준 JMX 인증도 켜집니다.

기본적으로 로컬 전용 연결은 인증 대상이 아니지만, 이를 활성화할 수 있습니다.

원격 연결을 활성화한다면 SSL 연결도 사용하는 것이 좋습니다.

마지막으로 인증 및/또는 SSL을 활성화한 후에는 nodetool 같은 JMX를 사용하는 도구가 올바르게 구성되어 예상대로 작동하는지 확인하세요.

표준 JMX 인증

JMX 서버에 연결할 수 있는 사용자는 간단한 텍스트 파일에 지정됩니다. 이 파일의 위치는 cassandra-env.sh의 다음 줄에 설정됩니다:

JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.password.file=/etc/cassandra/jmxremote.password"

비밀번호 파일을 편집해 사용자 이름/비밀번호 쌍을 추가하세요:

jmx_user jmx_password

Cassandra 프로세스를 실행하는 사용자만 읽을 수 있도록 자격 증명 파일을 보호하세요:

$ chown cassandra:cassandra /etc/cassandra/jmxremote.password
$ chmod 400 /etc/cassandra/jmxremote.password

선택적으로, 정의된 사용자가 JMX로 무엇을 할 수 있는지 범위를 제한하는 접근 제어를 활성화할 수 있습니다. 다만 대부분의 Cassandra 운영 도구는 전체 읽기/쓰기 접근을 요구하므로 이 맥락에서는 다소 무딘 도구라는 점을 유의하세요. 간단한 접근 파일을 구성하려면 cassandra-env.sh에서 이 줄의 주석을 해제하세요:

#JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.access.file=/etc/cassandra/jmxremote.access"

그런 다음 접근 파일을 편집해 JMX 사용자에게 readwrite 권한을 부여하세요:

jmx_user readwrite

새 설정을 적용하려면 Cassandra를 다시 시작해야 합니다.

JMX에서 파일 기반 비밀번호 인증 사용도 참고하세요.

Cassandra 통합 인증

기본 제공 JMX 인증의 대안은 JMX 클라이언트에 Cassandra 자체 인증 및/또는 권한 부여 공급자를 사용하는 것입니다. 이는 잠재적으로 더 유연하고 안전하지만 한 가지 주요 주의 사항이 있습니다. 인증 하위 시스템이 완전히 구성되기 전이기 때문에 노드가 링에 조인하기 전까지는 사용할 수 없다는 것입니다. 하지만 특히 부트스트랩 중에는 JMX 접근이 모니터링 목적으로 중요한 경우가 많아요. 따라서 가능하면 부트스트랩 중에는 로컬 전용 JMX 인증을 사용하고, 원격 연결이 필요하면 노드가 링에 조인하고 초기 설정이 완료된 후 통합 인증으로 전환하는 것이 좋습니다.

이 옵션을 사용하면 CQL 인증에 사용되는 것과 같은 데이터베이스 역할로 JMX 접근을 제어할 수 있으므로 cqlsh만 사용해 업데이트를 중앙에서 관리할 수 있어요. 또한 특정 MBeans에서 정확히 어떤 연산이 허용되는지에 대한 세밀한 제어를 GRANT PERMISSION으로 달성할 수 있습니다.

통합 인증을 활성화하려면 cassandra-env.sh를 편집해 이 줄들의 주석을 해제하세요:

#JVM_OPTS="$JVM_OPTS -Dcassandra.jmx.remote.login.config=CassandraLogin"
#JVM_OPTS="$JVM_OPTS -Djava.security.auth.login.config=$CASSANDRA_HOME/conf/cassandra-jaas.config"

그리고 이 줄을 주석 처리해 JMX 표준 인증을 비활성화하세요:

JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.password.file=/etc/cassandra/jmxremote.password"

통합 권한 부여를 활성화하려면 이 줄의 주석을 해제하세요:

#JVM_OPTS="$JVM_OPTS -Dcassandra.jmx.authorizer=org.apache.cassandra.auth.jmx.AuthorizationProxy"

이 줄이 주석 처리되어 있어 표준 접근 제어가 꺼져 있는지 확인하세요:

#JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.access.file=/etc/cassandra/jmxremote.access"

통합 인증과 권한 부여가 활성화되면 운영자는 특정 역할을 정의하고 그들이 필요한 특정 JMX 리소스에 접근 권한을 부여할 수 있어요. 예를 들어 jconsole이나 jmc 같은 도구를 읽기 전용으로 사용하는 데 필요한 권한을 가진 역할은 다음과 같이 정의됩니다:

CREATE ROLE jmx WITH LOGIN = false;
GRANT SELECT ON ALL MBEANS TO jmx;
GRANT DESCRIBE ON ALL MBEANS TO jmx;
GRANT EXECUTE ON MBEAN 'java.lang:type=Threading' TO jmx;
GRANT EXECUTE ON MBEAN 'com.sun.management:type=HotSpotDiagnostic' TO jmx;

# Grant the role with necessary permissions to use nodetool commands (including nodetool status) in read-only mode
GRANT EXECUTE ON MBEAN 'org.apache.cassandra.db:type=EndpointSnitchInfo' TO jmx;
GRANT EXECUTE ON MBEAN 'org.apache.cassandra.db:type=StorageService' TO jmx;

# Grant the jmx role to one with login permissions so that it can access the JMX tooling
CREATE ROLE ks_user WITH PASSWORD = 'password' AND LOGIN = true AND SUPERUSER = false;
GRANT jmx TO ks_user;

개별 MBeans에 대한 세밀한 접근 제어도 지원됩니다:

GRANT EXECUTE ON MBEAN 'org.apache.cassandra.db:type=Tables,keyspace=test_keyspace,table=t1' TO ks_user;
GRANT EXECUTE ON MBEAN 'org.apache.cassandra.db:type=Tables,keyspace=test_keyspace,table=*' TO ks_owner;

이것은 ks_user 역할이 test_keyspace의 단일 테이블을 나타내는 MBean의 메서드를 호출하도록 허용하고, 그 키스페이스의 모든 테이블 수준 MBean에 같은 권한을 ks_owner 역할에 부여합니다.

역할 추가/제거와 권한 부여/취소는 초기 설정이 완료된 후 동적으로 처리되므로, 권한이 변경되어도 재시작이 필요하지 않습니다.

권한(Permissions)도 참고하세요.

JMX와 SSL

JMX SSL 구성은 몇 가지 시스템 속성으로 제어되며, 일부는 선택적입니다. SSL을 켜려면 cassandra-env.sh의 관련 줄을 편집해 주석을 해제하고 필요에 따라 이 속성들의 값을 설정하세요:

com.sun.management.jmxremote.ssl true로 설정하면 SSL 활성화

com.sun.management.jmxremote.ssl.need.client.auth true로 설정하면 클라이언트 인증서 검증 활성화

com.sun.management.jmxremote.registry.ssl 클라이언트가 JMX 커넥터 스텁을 얻는 RMI 레지스트리에 SSL 소켓 활성화

com.sun.management.jmxremote.ssl.enabled.protocols 기본적으로는 JVM이 지원하는 프로토콜이 사용되며, 쉼표로 구분된 목록으로 재정의. 보통 필요하지 않으며 기본값을 사용하는 것이 선호되는 옵션

com.sun.management.jmxremote.ssl.enabled.cipher.suites 기본적으로는 JVM이 지원하는 암호 스위트가 사용되며, 쉼표로 구분된 목록으로 재정의. 보통 필요하지 않으며 기본값을 사용하는 것이 선호되는 옵션

javax.net.ssl.keyStore 서버 프라이빗 키와 공개 인증서를 포함하는 키스토어의 로컬 파일시스템 경로 설정

javax.net.ssl.keyStorePassword 키스토어 파일의 비밀번호 설정

javax.net.ssl.trustStore 클라이언트 인증서 검증이 필요한 경우, 신뢰된 클라이언트의 공개 인증서를 포함하는 트러스트스토어의 경로를 이 속성으로 지정

javax.net.ssl.trustStorePassword 트러스트스토어 파일의 비밀번호 설정

Oracle Java7 문서, Monitor Java with JMX도 참고하세요.

크립토 공급자 (Crypto providers)

커스텀 Java Crypto Provider를 지정하는 기능은 CASSANDRA-18624의 일부로 이루어졌습니다.

cassandra.yaml의 기본 crypto_provider 구성은 다음과 같습니다:

# Configures Java crypto provider. By default, it will use
# DefaultCryptoProvider which will install Amazon Correto
# Crypto Provider.
#
# Amazon Correto Crypto Provider works currently for
# x86_64 and aarch_64 platforms. If this provider fails it will
# fall back to the default crypto provider in the JRE.
#
# To force failure when the provider was not installed properly,
# set the property "fail_on_missing_provider" to "true".
#
# To bypass the installation of a crypto provider use
# class 'org.apache.cassandra.security.JREProvider'
#
crypto_provider:
  - class_name: org.apache.cassandra.security.DefaultCryptoProvider
    parameters:
      - fail_on_missing_provider: "false"

오래된 노드가 crypto_provider 섹션이 아직 설정되지 않은 같은 cassandra.yaml으로 Cassandra 5.0으로 업그레이드하면, 어떤 공급자도 설치하지 않고 Cassandra가 실행되는 JRE의 공급자를 사용하는 JREProvider를 기본으로 사용할 것입니다.

위 스니펫이 보여주듯 DefaultCryptoProvider는 JRE 설치의 기본 크립토 공급자보다 훨씬 더 성능이 좋은 것으로 입증된 Amazon Corretto Crypto 공급자를 설치합니다.

다른 크립토 공급자를 사용하고 싶다면 두 가지 옵션이 있습니다.

첫 번째는 JRE를 구성해, 구체적으로 java.security 파일로 JRE에 어떤 크립토 공급자를 사용할지 지시하는 것입니다. 해당 크립토 공급자의 각 구현을 JRE의 클래스 경로에 넣어야 합니다.

두 번째 옵션은 org.apache.cassandra.security.AbstractCryptoProvider를 확장하고 네 가지 메서드를 구현해 자신만의 크립토 공급자를 구현하는 것입니다:

getProviderName 공급자 이름 반환

getProviderClassAsString java.security.Provider를 확장하는 실제 크립토 공급자의 FQCN 반환

installator 런타임에 java.security.Provider를 설치하는 Runnable 반환

isHealthyInstallation 설치가 정상이면 true, 그렇지 않으면 false 반환. 이는 공급자 설치가 성공했는지 여부를 확인하는 방법으로 사용

크립토 공급자 설치 시 AbstractCryptoProvider는 설치하려는 공급자가 이미 설치되었는지 확인합니다. 설치되어 있고 그 설치 위치가 1이면(공급자는 순서로 설치되므로) 이 사실에 대한 메시지가 기록됩니다. 이 경우는 JRE를 java.security로 직접 구성하고 같은 공급자를 Cassandra 자신으로도 설치하려 할 때 발생할 수 있습니다.

이미 설치되었지만 첫 번째 위치가 아니면, fail_on_missing_provider가 true로 설정된 경우 예외가 발생하고 노드가 시작에 실패합니다. 공급자 설치가 성공하지 못한 경우에도 마찬가지입니다.

플랫폼별 라이브러리는 cassandra.in.sh 스크립트가 Cassandra의 클래스 경로에 자동으로 추가합니다. 현재 각 아키텍처에 대한 JAR 파일이 있는 lib/aarch64와 lib/x86_64 디렉터리가 있습니다. 플랫폼은 uname -m 명령의 출력으로 결정됩니다.

더 알아보기 (Learn more)