セキュリティ

Cassandra が提供するセキュリティ機能には、主に 3 つのコンポーネントがあります。

クライアントとノード間の通信のための TLS/SSL 暗号化
クライアント認証
承認

デフォルトでは、これらの機能は無効になっています。これは、Cassandra がクラスターの他のメンバーを簡単に見つけ、見つけられるように構成されているためです。言い換えれば、初期状態の Cassandra インストールは、悪意のある攻撃者にとって大きな攻撃対象領域となります。バイナリプロトコルを使用するクライアントの認証を有効にするだけでは、クラスターを保護するのに十分ではありません。ノード間通信と JMX ポートにアクセスできる悪意のあるユーザーは、依然として以下のことが可能です。

認証スキーマにユーザーを挿入するためのノード間メッセージの作成
スキーマを切り詰めたり削除したりするためのノード間メッセージの作成
sstableloaderなどのツールを使用して、system_authテーブルを上書きする
クラスターに直接接続して、書き込みトラフィックをキャプチャする

3 つのセキュリティコンポーネントすべてを適切に構成することで、これらのベクトルを無効にする必要があります。したがって、Cassandra のセキュリティ機能を理解することは、セキュリティニーズに合わせてクラスターを構成するために非常に重要です。

TLS/SSL 暗号化

Cassandra は、クライアントマシンとデータベースクラスター間、およびクラスター内のノード間の安全な通信を提供します。暗号化を有効にすることで、転送中のデータが侵害されず、安全に転送されるようにします。クライアントからノードへの暗号化とノードからノードへの暗号化のオプションは個別に管理され、個別に構成できます。

どちらの場合も、暗号化が有効になっている場合は、サポートされているプロトコルと暗号スイートの JVM デフォルトが使用されます。これらは cassandra.yaml の設定を使用して上書きできますが、特定のポリシーで特定の構成が規定されている場合や、JVM を更新できない場合に脆弱な暗号またはプロトコルを無効にする必要がある場合を除き、推奨されません。

FIPS 準拠の設定は JVM レベルで構成でき、cassandra.yaml で暗号化設定を変更する必要はありません。詳細については、FIPS に関する Java ドキュメントを参照してください。

Cassandra では、Java ベースのキーマテリアルを使用したり、SSL コンテキストを完全にカスタマイズしたりする柔軟性があります。Java (JKS、PKCS12 など) でサポートされている任意のキーストア形式だけでなく、PEM などの他の標準を選択することもできます。キーマテリアルを保存するための Kuberenetes Secrets のような Cloud Native テクノロジーを使用したり、社内キー管理システムと統合したりするために、SSL コンテキストの作成をカスタマイズすることもできます。

SSL 通信で使用される Java でサポートされているキーストアで必要なキーストアファイルとトラストストアファイルの生成については、キーストアの作成に関する Java ドキュメントを参照してください。

SSL コンテキストの作成をカスタマイズするには、ISslContextCreationFactoryインターフェースを実装するか、適切な公開サブクラスの 1 つを拡張します。次に、server_encryption_options セクションまたは client_encryption_options セクションの ssl_context_factory 設定を適切に使用できます。詳細については、ssl-factory の例を参照してください。クラス階層を理解するには、以下のクラス図を参照してください。

PEM ベースのキーマテリアルの使用

PEM ベースのキーマテリアルの ssl_context_factory 設定として、組み込みクラス PEMBasedSSLContextFactory を使用できます。

このファクトリは、以下に示すように、インライン PEM データまたは必要な PEM データを含むファイルで構成できます。

構成: インラインで定義された PEM キー/証明書 (YAML のスペースに注意してください!)

   client/server_encryption_options:
     ssl_context_factory:
        class_name: org.apache.cassandra.security.PEMBasedSslContextFactory
        parameters:
            private_key: |
             -----BEGIN ENCRYPTED PRIVATE KEY----- OR -----BEGIN PRIVATE KEY-----
             <your base64 encoded private key>
             -----END ENCRYPTED 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 証明書のホットリロードをサポートしています。SSL/TLS サポートが Cassandra で有効になっており、デフォルトのファイルベースのキーマテリアルを使用している場合、ノードは cassandra.yaml で指定されたトラストストアとキーストアを定期的に (10 分ごと) ポーリングします。ファイルが更新されると、Cassandra はそれらをリロードし、後続の接続に使用します。トラストストアとキーストアのパスワードは yaml の一部であるため、更新されたファイルも同じパスワードを使用する必要があります。

ssl_context_factory 設定を介して SSL 構成をカスタマイズしている場合、Cassandra は (上記と同じ定期的な間隔で) 実装をポーリングして、SSL 証明書をリロードする必要があるかどうかを確認します。詳細については、ISslContextFactory ドキュメントを参照してください。ファイルベースのキーマテリアルを使用して Cassandra の組み込み SSL コンテキストファクトリクラス (例: PEMBasedSslContextFactory) のいずれかを使用している場合、上記のように SSL 証明書のホットリロードをサポートします。

証明書のホットリロードは、nodetool reloadssl コマンドを使用してトリガーすることもできます。Cassandra が変更された証明書をすぐに認識させたい場合は、これを使用してください。

ノード間暗号化

ノード間暗号化を管理するための設定は、cassandra.yaml の server_encryption_options セクションにあります。ノード間暗号化を有効にするには、internode_encryption 設定のデフォルト値 none を、rack、dc、または all のいずれかの値に変更します。

クライアントからノードへの暗号化

クライアントからノードへの暗号化を管理するための設定は、cassandra.yaml の client_encryption_options セクションにあります。暗号化を有効にするための主なトグルが 2 つあります。enabled と optional です。

どちらも true に設定されていない場合、クライアント接続は完全に暗号化されません。
enabled が true に設定され、optional が false に設定されている場合、すべてのクライアント接続を保護する必要があります。
両方のオプションが true に設定されている場合、暗号化された接続と暗号化されていない接続の両方が同じポートを使用してサポートされます。この構成で暗号化を使用するクライアント接続は、サーバーによって自動的に検出および処理されます。

optional 設定の代わりに、運用要件で必要な場合は、安全な接続と安全でない接続に個別のポートを設定することもできます。そのためには、optional を false に設定し、cassandra.yaml の native_transport_port_ssl 設定を使用して、安全なクライアント通信に使用するポートを指定します。

ロール

Cassandra は、認証とアクセス許可管理の両方で、単一のユーザーまたはユーザーグループを表すデータベースロールを使用します。ロール管理は Cassandra の拡張ポイントであり、cassandra.yaml の role_manager 設定を使用して構成できます。デフォルト設定では、system_auth キースペースのテーブルにロール情報を格納する実装である CassandraRoleManager を使用します。

ロールに関する CQL ドキュメントも参照してください。

認証

認証は Cassandra でプラグイン可能であり、cassandra.yaml の authenticator 設定を使用して構成されます。Cassandra には、デフォルトのディストリビューションに含まれる 2 つのオプションが付属しています。

デフォルトでは、Cassandra は認証チェックを実行せず、したがって資格情報を必要としない AllowAllAuthenticator で構成されています。これは認証を完全に無効にするために使用されます。認証は Cassandra のアクセス許可サブシステムの必要な条件であるため、認証が無効になっている場合、アクセス許可も事実上無効になることに注意してください。

デフォルトのディストリビューションには、システムテーブルに暗号化された資格情報を格納する PasswordAuthenticator も含まれています。これは、単純なユーザー名/パスワード認証を有効にするために使用できます。

パスワード認証の有効化

クラスターでクライアント認証を有効にする前に、クライアントアプリケーションを意図した資格情報で事前に構成する必要があります。接続が開始されると、サーバーは認証が有効になった場合にのみ資格情報を要求するため、事前にクライアント側の構成を設定するのは安全です。対照的に、サーバーで認証が有効になるとすぐに、適切な資格情報なしでの接続試行は拒否され、クライアントアプリケーションで可用性の問題が発生する可能性があります。クライアントがセットアップされ、認証を有効にする準備ができたら、次の手順に従ってクラスターで有効にします。

初期構成を実行するクラスター内の単一のノードを選択します。理想的には、セットアッププロセス中にクライアントがこのノードに接続しないようにする必要があるため、クライアント構成から削除したり、ネットワークレベルでブロックしたり、この目的のために新しい一時ノードをクラスターに追加したりすることもできます。そのノードで、次の手順を実行します。

cqlshセッションを開き、system_authキースペースのレプリケーションファクターを変更します。デフォルトでは、このキースペースはSimpleReplicationStrategyとreplication_factorが1を使用します。ノードが利用できなくなった場合にログインが可能であることを保証するために、重要度の高いデプロイメントではこれを変更することをお勧めします。ベストプラクティスは、データセンターごとに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セッションを開始し、今度はnew_superuserとしてログインし、デフォルトのスーパーユーザーを無効にします。

ALTER ROLE cassandra WITH SUPERUSER = false AND LOGIN = false;

最後に、CREATE ROLEステートメントを使用して、アプリケーションユーザーのロールと資格情報を設定します。

これらの手順の最後に、1つのノードがパスワード認証を使用するように構成されます。クラスター全体に展開するには、クラスター内の各ノードで手順2と3を繰り返します。すべてのノードが再起動されると、クラスター全体で認証が完全に有効になります。

PasswordAuthenticatorを使用するには、CassandraRoleManagerも使用する必要があることに注意してください。

参考資料：setting-credentials-for-internal-authentication、CREATE ROLE、ALTER ROLE、ALTER KEYSPACE、GRANT PERMISSION。

認証

認証はCassandraでプラグイン可能であり、cassandra.yamlのauthorizer設定を使用して構成されます。Cassandraには、デフォルトのディストリビューションに含まれている2つのオプションがあります。

デフォルトでは、CassandraはAllowAllAuthorizerで構成されており、チェックを実行しないため、事実上すべてのロールにすべての権限を付与します。AllowAllAuthenticatorが構成された認証システムの場合は、これを使用する必要があります。

デフォルトのディストリビューションにはCassandraAuthorizerも含まれており、完全な権限管理機能を実装し、そのデータをCassandraシステムテーブルに保存します。

内部認証の有効化

権限はホワイトリストとしてモデル化され、特定のロールはデータベースリソースにアクセスできないことがデフォルトの前提となります。この意味は、ノードで認証が有効になると、必要な権限が付与されるまですべてのリクエストが拒否されるということです。このため、クライアントリクエストを処理していないノードで初期セットアップを実行することを強くお勧めします。

以下では、password-authenticationで概説したプロセスを介して認証がすでに有効になっていることを前提としています。クラスター全体で内部認証を有効にするには、次の手順を実行します。

選択したノードで、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。

キャッシュ

認証と承認を有効にすると、system_authテーブルからの頻繁な読み取りにより、クラスターに追加の負荷がかかります。さらに、これらの読み取りは多くのクライアント操作のクリティカルパスにあるため、サービス品質に深刻な影響を与える可能性があります。これを軽減するために、資格情報、権限、ロールの詳細などの認証データは、構成可能な期間キャッシュされます。キャッシュは、cassandra.yamlまたはJMXクライアントを使用して構成（または無効化）できます。JMXインターフェースは、さまざまなキャッシュの無効化もサポートしていますが、JMXを介して行われた変更は永続的ではなく、ノードの再起動時にcassandra.yamlから再読み込みされます。

各キャッシュには、設定できる3つのオプションがあります。

有効期間: キャッシュエントリの有効期限を制御します。この期間後、エントリは無効になり、キャッシュから削除されます。
更新頻度: バックグラウンド読み取りが実行されて、基になるデータへの変更が取得される速度を制御します。これらの非同期更新が実行されている間、キャッシュは（おそらく）古いデータを提供し続けます。通常、これは有効期間よりも短い時間に設定されます。
最大エントリ数: キャッシュサイズの上限を制御します。

cassandra.yamlでのこれらのオプションの命名は、次の規則に従います。

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

ここで、<type>は、credentials、permissions、またはrolesのいずれかです。

前述のように、これらはorg.apache.cassandra.authドメインのmbeanのJMX経由でも公開されます。

JMXアクセス

JMXクライアントのアクセス制御は、CQLのアクセス制御とは別に構成されます。認証と承認の両方について、2つのプロバイダーが利用可能です。1つ目は標準のJMXセキュリティに基づいており、2つ目はCassandra独自の認証サブシステムとより緊密に統合されています。

Cassandraのデフォルト設定では、JMXはlocalhostからのみアクセス可能です。リモートJMX接続を有効にするには、cassandra-env.shを編集して、LOCAL_JMX設定をnoに変更します。標準構成では、リモートJMX接続が有効になっている場合、標準JMX認証 <standard-jmx-auth>もオンになります。

デフォルトでは、ローカルのみの接続は認証の対象になりませんが、これを有効にすることができます。

リモート接続を有効にする場合は、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ユーザーに読み取り/書き込み権限を付与します。

jmx_user readwrite

新しい設定を適用するには、Cassandraを再起動する必要があります。

参考資料：JMXでのファイルベースのパスワード認証の使用

Cassandra統合認証

既製のJMX認証の代替として、JMXクライアントにCassandra独自の認証および/または承認プロバイダーを使用する方法があります。これはより柔軟で安全になる可能性がありますが、1つの大きな注意点があります。つまり、ノードがリングに参加するまで利用できません。これは、認証サブシステムがその時点まで完全に構成されていないためです。ただし、特にブートストラップ中にJMXアクセスが必要になることは、監視の観点から重要であることがよくあります。したがって、可能であれば、ブートストラップ中にローカルのみのJMX認証を使用し、リモート接続が必要な場合は、ノードがリングに参加し、初期セットアップが完了したら統合認証に切り替えることをお勧めします。

このオプションを使用すると、CQL認証に使用されるものと同じデータベースロールを使用してJMXへのアクセスを制御できるため、cqlshのみを使用して一元的に更新を管理できます。さらに、特定のMBeanで許可される操作をきめ細かく制御するには、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;

個々のMBeanへのきめ細かいアクセス制御もサポートされています

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ロールに同じ権限が付与されます。

ロールの追加/削除と権限の付与/取り消しは、初期セットアップが完了すると動的に処理されるため、権限が変更された場合でも再起動は不要です。

参考資料：権限。

SSL付きのJMX

JMX SSL構成は、いくつかのシステムプロパティによって制御され、その一部はオプションです。SSLをオンにするには、cassandra-env.shの関連する行を編集して、必要に応じてこれらのプロパティのコメントを解除し、値を設定します

com.sun.management.jmxremote.ssl: SSLを有効にする場合はtrueに設定します
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ドキュメント、JMXでJavaを監視する

暗号化プロバイダー

カスタムJava暗号化プロバイダーを指定する機能は、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 にアップグレードすると、デフォルトで JREProvider になり、プロバイダーはインストールされず、Cassandra が実行されている JRE に含まれるプロバイダーが使用されます。

上記の例が示すように、DefaultCryptoProvider は、JRE インストールに含まれるデフォルトの暗号化プロバイダーよりもパフォーマンスが大幅に優れていることが証明されている Amazon Corretto Crypto プロバイダーをインストールします。

他の暗号化プロバイダーを使用したい場合は、2つのオプションがあります。

1つ目のオプションは、JRE の java.security ファイルを具体的に構成して、使用する暗号化プロバイダーを JRE に指示することです。また、そのような暗号化プロバイダーの実装を JRE のクラスパスに追加する必要があります。

2つ目のオプションは、org.apache.cassandra.security.AbstractCryptoProvider を拡張し、次の 4 つのメソッドを実装して、独自の暗号化プロバイダーを実装することです。

getProviderName: プロバイダーの名前を返します。
getProviderClassAsString: java.security.Provider を拡張する実際の暗号化プロバイダーの FQCN を返します。
installator: 実行時に java.security.Provider をインストールする Runnable を返します。
isHealthyInstallation: インストールが正常である場合は true、そうでない場合は false を返します。これは、プロバイダーのインストールが成功したかどうかを確認する方法として機能します。

暗号化プロバイダーのインストール時に、AbstractCryptoProvider は、インストールするプロバイダーが既にインストールされているかどうかを確認します。インストールされており、インストール位置が 1 (プロバイダーは順番にインストールされるため) の場合は、この事実に関するメッセージがログに記録されます。このケースは、java.security を介して JRE を直接構成し、Cassandra 自体によって同じプロバイダーをインストールしようとした場合に発生する可能性があります。

既にインストールされているものの、最初の位置にない場合は、fail_on_missing_provider が true に設定されていると、例外がスローされ、ノードの起動に失敗します。プロバイダーのインストール自体が成功しなかった場合も同様です。

プラットフォーム固有のライブラリは、cassandra.in.sh スクリプトによって Cassandra のクラスパスに自動的に追加されます。現在、各アーキテクチャに対応する JAR ファイルを含む lib/aarch64 および lib/x86_64 ディレクトリがあります。プラットフォームは、uname -m コマンドの出力によって決定されます。

Cassandra ドキュメント

バージョン