DSE Advanced Security（DSE拡張セキュリティ）に関するFAQ

DataStax Enterpriseのセキュリティ機能についてよく寄せられる質問。

DSE Advanced Security（DSE拡張セキュリティ）に関する質問と回答を以下のカテゴリーに分けて説明します。

DSE 5.1の新しいセキュリティ機能

新しいセキュリティ機能には、テーブル行と検索インデックスのパーミッションを許可する詳細なアクセス制御、LDAPグループによって管理されるロール割り当て、データベース・クライアントのDSEプロキシ認証、DSE Unified Authentication（DSE統合認証）と統合されたJMX認証（LDAPまたは内部）があります。

行レベル・パーミッションのための行レベル・アクセス制御（RLAC）
検索インデックスのためのロール・ベース・アクセス制御（RBAC）
アプリケーションのプロキシ・ロールの構成
「LDAPモード用にロールを作成する」で説明している統合型のロール管理
JMXユーザー認証の設定、内部またはLDAPを使用

一般

使用する通信プロトコルは何ですか？: すべての通信はTCPソケットを使用して行われ、JVMの標準Java Security SSL/TLS実装を使用してセキュリティを保護できます。ゴシップやCQLバイナリー・プロトコルなど、その他のアプリケーション固有のプロトコルは、トランスポートにこれらのソケットを使用します。DSEで使用されるポートのリストについては、「DataStax Enterpriseポートのセキュリティ保護」を参照してください。

認証と権限管理

デフォルトのcassandraユーザーにはどのような制限事項がありますか？

cassandraデフォルト・アカウントは、すべてのデータベース・リソースにアクセスできます。ログイン時やアクションの実行時に、このアカウントの整合性レベルはQUORUMに設定されます。実稼働環境では、cassandraアカウントを使用することによってパフォーマンスが低下し、障害が発生する場合があります。DataStaxでは、ロール・ベース・アクセス制御でDSE Unified Authentication（DSE統合認証）を有効にした後すぐにスーパーユーザー・アカウントの作成を行うことを推奨しています。

ユーザー・パーミッションはどのように管理されますか？

スーパーユーザーのパーミッションがあると、他のユーザーの作成と削除のほか、パーミッションの付与または取り消しを行うことができます。デフォルトのcassandraユーザーは、新規ユーザーとスーパーユーザーの初期セットアップを支援する目的でのみ使用し、使用後は無効にしてください。認証ユーザーにどのロールを割り当てるかは、DSE Role Manager（DSEロール・マネージャー）が決定します。「ロールについて」を参照してください。

ユーザー・グループはどのようにサポートされていますか？

DSEでは、LDAPグループ・メンバーシップに基づくロール管理がサポートされています。LDAPスキームをグループ検索で構成して、ロール管理モード・オプションをLDAPに設定し、グループ名と一致するロールを作成してから、パーミッションを割り当てます。「LDAPスキームの定義」を参照してください。

注: 効率化のため、グループ検索にはmemberof検索メソッドの使用が推奨されます。ただし、DataStaxではディレクトリー検索もサポートしています。

ユーザー・アクション・パーミッションはどのようにサポートされていますか？

DSEは、ロール固有のパーミッションをテーブル・レベルと行レベルで割り当てるために、標準的なオブジェクト・パーミッション管理をサポートしています。すべてのキースペース、指定のキースペース、テーブル、関数、またはMBeanにアクセスするためのパーミッションをロールに付与することができます。参照先：ロールの管理

どの認証メカニズムがサポートされていますか？

内部：接続によって、内部に格納されたパスワードを持つロールの認証情報が提供されます。追加の構成は必要ありません。「ロールの管理」を参照してください。
LDAP：接続によってLDAP認証情報が提供され、DSEが検証の認証情報をLDAPに渡します。「LDAPスキームの定義」を参照してください。
Kerberos：接続によってKerberosチケットが提供され、DSEはサービス・プリンシパルとして構成され（「Kerberosの設定」を参照）、検証のためにチケットをKDSに渡します。参照先： Kerberosスキームの定義

どのLDAPサーバーがサポートされていますか？

Microsoft Active Directory、OpenLDAP、Oracle Directory Server Enterprise Editionがサポートされています。「LDAPスキームの定義」を参照してください。

IPホワイトリスト/ブラックリストを使用してアクセスを制限できますか？

通常、任意のクライアント・プログラムがデータベースにアクセスすることはありません。一般的なユーザー母集団によるデータベース・アクセスは、アプリケーション層で制御されます。アプリケーション・ノードからデータベース・ノードへのアクセスは、Linux iptablesなどの従来のファイアウォール・メカニズムを使用して制御する必要があります。ただし、データベース管理者は例外で、DBAホストからの接続を許可できます。

特定のデータ要素へのアクセス権は、どの程度細かく設定できますか？

管理権限の付与と取り消しはデータの行レベルで行われます。

RBACとRLACの違いは何ですか？

ロール・ベース・アクセス制御（RBAC）はデータベース・リソースに対する権限管理を指し、これには行レベル・アクセス制御（RLAC）が含まれます。行レベル・アクセス制御は、テキストベースのパーティション・カラムをフィルター処理することによって、テーブル内の行に対するパーミッションの付与/取り消しを行うことができる機能です。

行レベル・アクセス制御（RLAC）

行レベルのパーミッションの設定についてよく寄せられる質問。

行へのアクセスはどのように制限しますか？

テーブルごとにUTF-8パーティション・キー・カラムを1つ指定できます。このカラムを使用して、テーブル内の行へのアクセス権を付与する（別のコマンド）フィルターを作成します。RESTRICTは、フィルター処理に使用するカラム名のみを設定します。

RESTRICT ROWS ON [keyspace_name.]table_name 
USING partition_key;

注: カラム名を設定した後で、GRANTコマンドを使用して行へのアクセス権を構成します。

RLAC権限管理を使用して、テーブル内の行へのアクセス制限を解除できますか？

GRANTの使用時にフィルター処理するパーティション・キーをテーブルで選択解除できます。

UNRESTRICT ROWS ON [keyspace_name.]table_name 
USING partition_key;

ヒント: パーミッションが付与されているすべてのロールを表示するには、テーブルに対してLISTコマンドを使用します。

注: カラムの制限を解除しても、既存のフィルターが無効になるだけで、テーブル内のすべてのカラムへのアクセス権が付与されるわけではありません。フィルターを使用してアクセス権を付与されていたユーザーは、テーブル内のどの行にもアクセスできなくなります。すべての行に対するパーミッションを付与するには、テーブルに対するパーミッションをそのロールに付与します。

テーブル内の行のパーミッションはどのように付与しますか？

テーブル内の行へのアクセス権を構成するには、RESTRICTコマンドで選択したパーティション・キー・カラムに適用するフィルター文字列を指定します。フィルター文字列には、大文字と小文字が区別されるリテラル・テキストを使用します。行レベルの権限管理は、filtering_dataと完全に一致している行にしか適用されません。RLACに基づくアクセス権の付与は、セキュリティ・ポリシーに応じて必要な数だけバリエーションを作成できます。テーブル内の行へのアクセスを許可するには、以下のコマンドを使用します。

GRANT permission 
on 'filtering_data' ROWS IN keyspace_name.table_name 
to role_name;

ヒント: あるロールが1つのリソースに対して持っているパーミッションをすべて表示するには、LISTコマンドを使用します。

テーブル内の行のパーミッションはどのように取り消しますか？

行のパーミッションは、フィルター文字列に基づいて格納されます。パーミッションを削除するには、REVOKEコマンドを使用して、削除するフィルター文字列を正確に指定します。

REVOKE permission on 'filtering_data' ROWS IN keyspace_name.table_name;

ヒント: LIST ALL PERMISSIONS ON TABLE table_nameを指定すると、ロールに付与されているすべてのフィルターが表示されます。

既に制限されているテーブルに対してRESTRICTコマンドを実行すると、どうなりますか？

テーブルの制限は1つだけです。RESTRICTコマンドを実行すると、既存の制限と置き換えられます。テーブルの既存の制限を表示するにはDESCRIBE TABLEを使用します。

キースペース/テーブル・レベルへのアクセス権を持っているロールに行アクセス権を付与すると、どうなりますか？

パーミッションは階層構造です。パーミッションがキースペースまたはテーブルにも付与されている場合、ユーザーはテーブル内のすべての行にアクセスできます。RLACパーミッションは影響を及ぼしません。

RLACはDSE Graphで使用できますか？

いいえ。以下の文を使用すると、パーミッションが表示されますが、エラーはスローされません。

GRANT SELECT ON 'custom_key' ROWS IN graph_keyspace.graph_table to 'alice';

これらのパーミッションは適用されません。RLACはDSE Graphでは使用できません。

警告: テーブル内の行に対するアクセス権を付与すると、すべてのグラフ・キースペース内のデータにアクセスできるようになります。

暗号化

暗号化キーの保護と管理はどのように行われますか？

暗号化キーはサーバー外で、またはローカルに管理できます。

暗号化キーのKMIP（Key Management Interoperability Protocol）暗号化は別のサーバーに格納され、DSEによって使用されるときにメモリー・ヒープにローカルにキャッシュされます。
ローカル暗号化キーを使用し、アクセスを制限するLinuxパーミッションを使用してセキュリティを保護します。

クライアントとノード間の暗号化を双方向SSLとして構成できますか？

はい。ただし、クライアント証明書DNはデータベース・ユーザー・プリンシパルとして使用されません。クライアントとノード間の暗号化は、クライアント・コンピューターからデータベース・クラスターに転送中のデータをSSL（Secure Sockets Layer）を使用して保護し、クライアントとコーディネーター・ノードの間にセキュアなチャネルを確立します。

保存データの暗号化はどのようにサポートされていますか？

ローカル暗号化キー・ファイル、またはリモートで格納され管理されているKMIP暗号化キーを使用して、機密性の高い保存データを保護します。

特定のテーブルの暗号化キーを変更することはできますか？

はい。テーブルごとの透過的なデータ暗号化（TDE）を指定してください。暗号化を使用して、複数の異なる暗号化アルゴリズムを使用するSSTableに対しても、暗号化を一切使用しないSSTableに対しても、読み取り/書き込みが可能です。暗号化と圧縮を設定するには、単一のALTER TABLE文を使用します。

AWSのEBS暗号化は、TDEの代わりに使用するのに適していますか？それともTDEを補完する機能として使用すべきですか（または、そのどちらでもありませんか）？

EBS暗号化は、データ・ファイルを暗号化するもう1つの方法です。EBS暗号化では、TDEを使用する場合にパーティション・キーがプレーン・テキストで生成される、監査ログ、システム・ログ、SSTableインデックス・ファイルを確実に暗号化できます。一般的に、EBS暗号化の方が操作が簡単です。TDEは主に、ディスク全体を暗号化するとコストがかかりすぎる場合や、ディスク全体の暗号化はできない場合に使用します。

暗号化は、レコードレベル、カラムレベル、フィールドレベルなど、細分性の高いデータ層でサポートされていますか？

いいえ。透過的なデータ暗号化（TDE）はテーブル単位で指定してください。

監査

どのユーザー・アクションとイベントがログに記録されますか？: 監査ロギングを構成する際、ログに記録する監査イベントのカテゴリー（管理、認証、DML、DDL、DCL、およびクエリー操作）と、特定のキースペースに対する操作を監査ロギングで省略するかどうかを指定できます。
監査ログはどこに格納され、誰がアクセスできますか？: 監査ログは、logbackを使用してファイル・システムのログ・ファイルに書き込むか、またはデータベース・テーブルに書き込むことができます。データベース・テーブルに格納された監査イベントは、他のデータベース・テーブルと同様に、RBACを使用してセキュリティを保護できます。ファイルベースの監査ログは、ノード単位で格納され、標準的なLinuxファイル・システム・パーミッションでセキュリティを保護できます。参照先：