セキュリティ・キースペースのレプリケーション係数の設定

前提条件として、認証と権限を管理するセキュリティ・キースペースのレプリケーション係数（RF）を大きくして、ロックアウトを回避しクラスター内の整合性を確保します。

実稼働環境でDSEセキュリティを使用する場合は適切なレプリケーション係数を構成する必要があります。レプリケーション係数を大きくする必要があるキースペースは以下のとおりです。
  • system_auth
  • dse_security
注: DSE Unified Authentication（DSE統合認証）では、セキュリティ・キースペース内に認証および権限管理情報を格納します。security_authキースペースとdse_securityキースペースへの読み取りアクセス権は、すべての認証ユーザーに暗黙的に付与されます。
警告: デフォルト・ユーザーcassandraを使用して初めてログインするには、system_authキースペースのRFを大きくする必要があります。キースペースを使用できない場合、cassandraアカウントはログインに失敗します。cassandraアカウントでは、すべての要求に対してQUORUM整合性レベルを使用します。

キースペースとテーブルのセキュリティ

これらのシステム・テーブルへの読み取りアクセス権は、すべての認証ユーザーに暗黙的に付与されます。これらのテーブルはほとんどのDSEツールで使用されるためです。

system_authキースペース

権限管理と内部認証データが含まれます。

表 1. system_authテーブル
テーブル カラム 説明
resource_role_permissons_index resource（PK）、role ロールと、そのロールが設定パーミッションを持つリソースを格納します。
role_permissions role（PK）、resource、permissions ロール、リソース（たとえば、keyspace_name/table_name）、およびそのロールがリソースにアクセスするために必要なパーミッションを格納します。
role_members role（PK）、member ロールとロール・メンバーを格納します。
roles role（PK）、can_login、is_superuser、member_of、salted_hash ロール名、そのロールをログインに使用可能かどうか、そのロールがスーパーユーザーかどうか、そのロールがメンバーに含まれている他のロール、そのロールのbcryptソルト付きハッシュ・パスワードを格納します。

dse_securityキースペース

DSE Spark、Kerberosダイジェスト・データ、ロール・オプションを含みます。

表 2. dse_securityテーブル
テーブル カラム 説明
role_options role、options ロール・オプション。
digest_tokens id、password Kerberosダイジェスト・トークン（有効な場合）。
spark_security dc、shared_secret Sparkのシークレットを共有します。

デフォルトのレプリケーション係数

system_authキースペースとdse_securityキースペースのデフォルトのレプリケーション係数は1です。

単一ノードの開発およびテスト時のみレプリケーション係数1が適していますが、実稼働環境には適していません。DataStaxでは、認証を有効にする前にレプリケーション係数を変更することを推奨しています。DSEでは、cassandraロールを使用する場合を除き、すべてのセキュリティ・キースペース・クエリーに対してLOCAL_ONE整合性レベルを使用します。cassandraロールの場合は整合性レベルQUORUMを使用します。cassandraロールのみを使用してログインし、独自のフル・アクセス・アカウントを作成したら、cassandraロールを削除してください。

推奨されるレプリケーション係数

フォールト・トレランスとデプロイのサイズに基づいて、適切なRFを決定します。

  • system_auth：ログインごと、およびデータベース・オブジェクトに影響を与えるアクションごとに必須です。ユーザーがログインすると、それぞれの認証情報、ロール、パーミッションは、cassandra.yamlで設定されている期間にわたりキャッシュされます。「セキュリティのプロパティ」を参照してください。LDAP、ネイティブ認証、権限管理に関するデータが含まれています。キースペースを使用できない場合、ログインとアクションは失敗する可能性があります。別のデータ・センターのノードにある場合、遅延が発生し、障害につながる可能性があります。キースペース・テーブルは、比較的小さくなります。

    DataStaxでは、データ・センターごとにレプリケーション係数3、4、または5の使用を推奨しています。

    注: DSEは、キャッシュ間隔を調整するためセキュリティ・データをキャッシュします。「セキュリティのプロパティ」を参照してください。
  • dse_security：DSE Analytic（Spark）、DSEクライアント・ダイジェスト・トークン、その他のKerberosに関するデータが含まれています。関連するDSEサービスでは必須ですが、純粋なデータベース・アクティビティーでは重要度は低くなります。

    DataStaxでは、これらのサービスがどれも存在しない場合、データ・センターごとにレプリケーション係数1の使用を推奨しています。

    注: これらのサービスが存在する場合、推奨されるdse_securityについては、対応する設定手順を参照してください。

手順

セキュリティ・キースペースのレプリケーション係数（RF）を変更するには、以下の手順を実行します。
  1. system_authキースペースRFを変更します。 
    ALTER KEYSPACE system_auth
    WITH REPLICATION= {'class' : 'NetworkTopologyStrategy', 
                       'data_center_name' : N, 
                       'data_center_name' : N};
    注: データ・センターを追加または削除するたびに、手動でsystem_authキースペースを再構成する必要があります。
  2. dse_securityキースペースRFを変更します。 
    ALTER KEYSPACE dse_security
    WITH REPLICATION= {'class' : 'NetworkTopologyStrategy', 
                       'data_center_name' : N, 
                       'data_center_name' : N};
    重要: データ・センターを追加または削除するたびに、手動でdse_securityキースペースを再構成する必要があります。また、DataStax EnterpriseまたはSparkのセキュリティ・オプションがクラスターで有効になっている場合、すべての論理データ・センターでdse_leasesキースペースのレプリケーション係数を大きくする必要があります。
  3. セキュリティ・キースペースでnodetool repairを実行します。 
    nodetool repair --full system_auth nodetool repair --full dse_security
    注: レプリケーション・ストラテジを変更した後、--fullオプションを指定してnodetool repairを実行する必要があります。