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

前提条件として、認証と権限を管理するセキュリティ・キースペースのレプリケーション係数(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では、データ・センターごとにレプリケーション係数34、または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を実行する必要があります。