第22章 Red Hat JBoss Data Grid セキュリティー: 認証および承認
22.1. Red Hat JBoss Data Grid セキュリティー: 認証および承認 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat JBoss Data Grid は、CacheManager および Cache での承認を実行できます。JBoss Data Grid 承認は、JAAS および SecurityManager などの JDK で利用できる標準的なセキュリティー機能に基づいています。
アプリケーションがセキュアな CacheManager および Cache と対話する場合、JBoss Data Grid のセキュリティーレイヤーが必須ロールおよびパーミッションのセットに対して検証できるアイデンティティーを指定する必要があります。検証されると、クライアントに後続操作のトークンが発行されます。アクセスが拒否されると、セキュリティー違反を示す例外が発生します。
キャッシュの承認が設定される場合、キャッシュが取得されると SecureCache のインスタンスが返されます。SecureCache はキャッシュの単純なラッパーであり、「現行ユーザー」が操作の実行に必要なパーミッションを持っているかどうかを確認します。「現行ユーザー」は AccessControlContext に関連する Subject です。
JBoss Data Grid はプリンシパル名を、1 つ以上のパーミッションを表すロールにマップします。以下の図はこれらの関係を示しています。
図22.1 ロールとパーミッションのマッピング
22.2. パーミッション リンクのコピーリンクがクリップボードにコピーされました!
CacheManager または Cache へのアクセスは必要なパーミッションセットを使用して制御されます。パーミッションは、操作されているデータのタイプではなく、CacheManager または Cache で実行されるアクションのタイプを制御します。これらのパーミッションの一部は、名前付きキャッシュなどの名前エンティティーにとくに適用されます。エンティティーによって使用できるタイプのパーミッションが異なります。
| パーミッション | 関数 | 説明 |
|---|---|---|
|
CONFIGURATION |
defineConfiguration |
新規キャッシュ設定を定義できるかどうか。 |
|
LISTEN |
addListener |
リスナーをキャッシュマネージャーに対して登録できるかどうか。 |
|
LIFECYCLE |
stop, start |
キャッシュマネージャーを停止または開始できるかどうか。 |
|
ALL |
上記すべてを含む便利なパーミッション。 |
| パーミッション | 関数 | 説明 |
|---|---|---|
|
READ |
get, contains |
エントリーをキャッシュから取得できるかどうか。 |
|
WRITE |
put, putIfAbsent, replace, remove, evict |
データをキャッシュから書き込み、置き換え、エビクトできるかどうか。 |
|
EXEC |
distexec, mapreduce |
コード実行をキャッシュに対して実行できるかどうか。 |
|
LISTEN |
addListener |
リスナーをキャッシュに対して登録できるかどうか。 |
|
BULK_READ |
keySet, values, entrySet,query |
一括取得操作を実行できるかどうか。 |
|
BULK_WRITE |
g |
一括書き込み操作を実行できるかどうか。 |
|
LIFECYCLE |
start, stop |
キャッシュを開始または停止できるかどうか。 |
|
ADMIN |
getVersion, addInterceptor*, removeInterceptor, getInterceptorChain, getEvictionManager, getComponentRegistry, getDistributionManager, getAuthorizationManager, evict, getRpcManager, getCacheConfiguration, getCacheManager, getInvocationContextContainer, setAvailability, getDataContainer, getStats, getXAResource |
基礎となるコンポーネントまたは内部構造へのアクセスが可能かどうか。 |
|
ALL |
上記すべてを含む便利なパーミッション。 | |
|
ALL_READ |
READ と BULK_READ の組み合わせ。 | |
|
ALL_WRITE |
WRITE と BULK_WRITE の組み合わせ。 |
使いやすさを強化するために一部のパーミッションを他のパーミッションに組み合わせることが必要になる場合があります。たとえば、EXEC を READ または WRITE と組み合わせることがあります。
22.3. ロールマッピング リンクのコピーリンクがクリップボードにコピーされました!
Subject のプリンシパルを承認で使用される一連のロールに変換するには、 PrincipalRoleMapper をグローバル設定に指定する必要があります。Red Hat JBoss Data Grid には 3 つのマッパーが含まれ、さらにカスタムマッパーを使用することもできます。
| マッパー名 | Java | XML | 説明 |
|---|---|---|---|
|
IdentityRoleMapper |
org.infinispan.security.impl.IdentityRoleMapper |
<identity-role-mapper /> |
ロール名としてプリンシパル名を使用します。 |
|
CommonNameRoleMapper |
org.infinispan.security.impl.CommonRoleMapper |
<common-name-role-mapper /> |
プリンシパル名が識別名 (DN) の場合、このマッパーは共通名 (CN) を抽出し、これをロール名として使用します。たとえば、DN |
|
ClusterRoleMapper |
org.infinispan.security.impl.ClusterRoleMapper |
<cluster-role-mapper /> |
|
|
Custom Role Mapper |
<custom-role-mapper class="a.b.c" /> |
|
22.4. ログインモジュールを使用した認証およびロールマッピングの設定 リンクのコピーリンクがクリップボードにコピーされました!
LDAP からロールクエリー用の認証 login-module を使用する場合、カスタムクラスは使用中であるため、プリンシパルからロールへの独自のマッピングを実装する必要があります。以下の例は、login-module から取得したプリンシパルをロールにマップする方法を示しています。これは、ユーザープリンシパル名をロールにマッピングし、同様のアクションを IdentityRoleMapper に対して実行します。
プリンシパルのマッピング
LDAP サーバーの設定や LDAP サーバーでのユーザーおよびロールの指定についての詳細は、Red Hat Directory Server の Administration Guide を参照してください。
22.5. Red Hat JBoss Data Grid の承認の設定 リンクのコピーリンクがクリップボードにコピーされました!
承認はキャッシュコンテナー (CacheManager) と単一キャッシュの 2 つのレベルで設定されます。
各キャッシュコンテナーは以下を決定します。
- 承認を使用するかどうか。
- プリンシパルをルールセットにマップするクラス。
- 名前付きロールのセットとそれらが表すパーミッション。
コンテナーレベルで定義されたロールのサブセットのみを使用することを選択できます。
ロール
ロールは、以下のようにキャッシュコンテナーのレベルで定義されたロールを使用して、キャッシュごとに適用できます。
認証が必要とされるキャッシュには、ロールの一覧が定義されている必要があります。そうでない場合、キャッシュの承認では非匿名ポリシーは定義されないため、認証は強制されません。
プログラムを使用した CacheManager 承認 (ライブラリーモード)
以下の例は、プログラムによる設定を使用して同じ承認パラメーターをライブラリーモードに対して設定する方法を示しています。
プログラムを使用した CacheManager 承認の設定
REST プロトコルの承認での使用はサポートされておらず、承認を有効にした状態でキャッシュにアクセスしようとすると SecurityException が発生します。
22.6. ライブラリーモードのデータセキュリティー リンクのコピーリンクがクリップボードにコピーされました!
22.6.1. サブジェクトおよびプリンシパルクラス リンクのコピーリンクがクリップボードにコピーされました!
リソースへのアクセスを承認するには、アプリケーションが最初に要求元を認証する必要があります。JAAS フレームワークは、要求元を表す用語サブジェクトを定義します。Subject クラスは JAAS の重要なクラスです。Subject は人やサービスなどの、単一エンティティーの情報を表します。これには、エンティティーのプリンシパル、パブリックのクレデンシャル、プライベートのクレデンシャルなどが含まれます。JAAS API は既存の Java 2 java.security.Principal インターフェースを使用して、型指定された名前であるプリンシパルを表します。
認証プロセス中、サブジェクトには関連するアイデンティティーまたはプリンシパルが入力されます。サブジェクトに複数のプリンシパルが含まれるようにすることができます。たとえば、一個人は名前のプリンシパル (John Doe)、ソーシャルセキュリティー番号のプリンシパル (123-45-6789)、ユーザー名のプリンシパル (johnd) を持つことができ、これらすべてのプリンシパルはサブジェクトを他のサブジェクトから区別するのに役立ちます。1 つのサブジェクトに関連するプリンシパルを取得する方法は 2 つあります。
public Set getPrincipals() {...}
public Set getPrincipals(Class c) {...}
public Set getPrincipals() {...}
public Set getPrincipals(Class c) {...}
getPrincipals() はサブジェクトに含まれるすべてのプリンシパルを返します。getPrincipals(Class c) は、クラス c のインスタンスであるプリンシパルまたはそのサブクラスの 1 つのみを返します。サブジェクトに一致するプリンシパルがない場合は、空のセットが返されます。
java.security.acl.Group インターフェースは java.security.Principal のサブインターフェースであるため、プリンシパルのセットのインスタンスは、他のプリンシパルやプリンシパルのグループの論理グループを表すことがあります。
22.6.2. サブジェクトの取得 リンクのコピーリンクがクリップボードにコピーされました!
ライブラリーモードでセキュア化されたキャッシュを使用するには、javax.security.auth.Subject を取得する必要があります。Subject は、人やサービスなどの単一のキャッシュエンティティーの情報を表します。
Red Hat JBoss Data Grid では、コンテナーの機能またはサードパーティーライブラリーのどちらかを使用して JAAS Subject を取得できます。
JBoss コンテナーの場合は以下を使用して取得します。
Subject subject = SecurityContextAssociation.getSubject();
Subject subject = SecurityContextAssociation.getSubject();
Subject には、LDAP や Active Directory などのセキュリティードメインで属するユーザーおよびグループを表すプリンシパルのセットを指定する必要があります。
Java EE API では、以下のメソッドを用いてコンテナーセットのプリンシパルを取得できます。
-
サーブレット:
ServletRequest.getUserPrincipal() -
EJB:
EJBContext.getCallerPrincipal() -
MessageDrivenBeans:
MessageDrivenContext.getCallerPrincipal()
mapper は、Subject と関連するプリンシパルを識別し、コンテナーレベルで定義したものに対応するロールへの変換に使用されます。
プリンシパルは Subject のコンポーネントの 1 つにすぎず、 java.security.AccessControlContext から取得されます。コンテナーが AccessControlContext の Subject を設定するか、Security.doAs() メソッドを使用して呼び出しを JBoss Data Grid API にラッピングする前にユーザーがプリンシパルを適切なサブジェクトへマップする必要があります。
Subject が取得されると、キャッシュは PrivilegedAction のコンテキスト内で対話できます。
サブジェクトの取得
Security.doAs() メソッドは、通常の Subject.doAs() メソッドの代わりになります。アプリケーションのセキュリティーモデルに固有する理由で AccessControlContext を変更しなければならない場合以外は、Security.doAs() を使用するとパフォーマンスが向上します。
現在の Subject を取得するには、Subject を JBoss Data Grid コンテキストまたは AccessControlContext から取得する Security.getSubject(); を使用します。
22.6.3. サブジェクトの認証 リンクのコピーリンクがクリップボードにコピーされました!
サブジェクトの認証には JAAS ログインが必要です。ログイン手順は次のようになります。
-
アプリケーションは
LoginContextをインスタンス化し、ログイン設定の名前とCallbackHandlerを渡して、設定LoginModuleが必要とするCallbackオブジェクトを追加します。 -
LoginContextは、名前付きログイン設定に含まれるすべてのLoginModulesをロードするためConfigurationを確認します。このような名前付き設定が存在しない場合は、other設定がデフォルトで使用されます。 -
アプリケーションは
LoginContext.loginメソッドを呼び出します。 -
ログインメソッドはロードされたすべての
LoginModuleを呼び出します。各LoginModuleはサブジェクトを認証するため、関連するLoginModuleでハンドルメソッドを呼び出し、認証プロセスに必要な情報を取得します。必要な情報は、Callbackオブジェクトのアレイの形式でハンドルメソッドに渡されます。認証に成功すると、LoginModuleは関連のプリンシパルとクレデンシャルをサブジェクトに関連付けします。 -
LoginContextは認証ステータスをアプリケーションに返します。ログインメソッドから返されると認証が成功したことになります。ログインメソッドによって LoginException が発生すると認証に失敗したことになります。 -
認証に成功すると、アプリケーションは
LoginContext.getSubjectメソッドを使用して認証されたサブジェクトを取得します。 -
サブジェクトの認証が完了した後に
LoginContext.logoutメソッドを呼び出すと、loginメソッドによりサブジェクトに関連付けられたすべてのプリンシパルおよび関連情報を削除できます。
LoginContext クラスは、サブジェクト認証の基本メソッドを提供し、基礎となる認証技術に依存しないアプリケーションの開発方法を提供します。LoginContext は、特定のアプリケーション向けに設定された認証サービスを判断するため Configuration を確認します。LoginModule クラスは認証サービスを表します。そのため、アプリケーション自体を変更しなくても、異なるログインモジュールをアプリケーションにプラグ可能です。次のコードは、アプリケーションによるサブジェクトの認証で必要になる手順を示しています。
開発者は、LoginModule インターフェースの実装を作成することで、認証技術を統合します。これにより、管理者は異なる認証技術を 1 つのアプリケーションにプラグできます。複数の LoginModule をチェーン化し、複数の認証技術を認証プロセスに加えることが可能です。たとえば、1 つの LoginModule がユーザー名およびパスワードベースの認証を行い、別の LoginModule をスマートカードリーダーや生体認証などのハードウェアデバイスへ接続するインターフェースとすることが可能です。
LoginModule のライフサイクルは、クライアントがログインメソッドを作成し公開するLoginContext オブジェクトによって決定されます。このプロセスには 2 つのフェーズがあり、プロセスの手順は次のようになります。
-
LoginContextは引数のないパブリックコンストラクターを使用して、設定されたLoginModuleを作成します。 -
各
LoginModuleは、初期化メソッドへの呼び出しによって初期化されます。Subject引数は null 以外になることが保証されます。初期化メソッドのシグネチャーはpublic void initialize(Subject subject, CallbackHandler callbackHandler, Map sharedState, Map options)です。 -
loginメソッドは、認証プロセスを開始するために呼び出されます。たとえば、あるメソッド実装はユーザーにユーザー名とパスワードの入力を求め、NIS や LDAP などのネーミングサービスに保存されたデータと照合してこの情報を検証することがあります。別の実装は、スマートカードや生体認証デバイスにインターフェースとして接続したり、基礎となるオペレーティングシステムからユーザー情報を抽出したりすることがあります。各LoginModuleによるユーザーアイデンティティーの検証は、JAAS 認証のフェーズ 1 とみなされます。loginメソッドのシグネチャーはboolean login() throws LoginExceptionです。LoginExceptionは失敗を意味します。true の戻り値はメソッドが成功したことを示し、false の戻り値はログインモジュールが無視されることを示します。 -
LoginContextの全体的な認証が成功すると、各LoginModuleでcommitが呼び出されます。フェーズ 1 がLoginModuleに対して成功すると、コミットメソッドはフェーズ 2 を続行し、関連するプリンシパル、パブリッククレデンシャル、プライベートクレデンシャルをサブジェクトに関連付けます。フェーズ 1 がLoginModuleに対して失敗すると、commitはユーザー名やパスワードなどの以前保存した認証状態をすべて削除します。commitメソッドのシグネチャーはboolean commit() throws LoginExceptionです。LoginExceptionの発生は、コミットフェーズの完了に失敗したことを示します。true が返されるとメソッドが成功したことを示し、false が返されるとログインモジュールが無視されることを示します。 -
LoginContextの全体的な認証が失敗すると、各LoginModuleでabortメソッドが呼び出されます。abortメソッドはログインまたは初期化メソッドによって作成されたすべての認証状態を削除または破棄します。abortメソッドのシグネチャーはboolean abort() throws LoginExceptionです。LoginExceptionの発生は、abortフェーズの完了に失敗したことを示します。true が返されるとメソッドが成功したことを示し、false が返されるとログインモジュールが無視されることを示します -
ログイン成功後に認証状態を削除するため、アプリケーションは
LoginContextでlogoutを呼び出します。これにより、各LoginModuleでlogoutメソッドが呼び出されます。logoutメソッドは、commit操作中に当初サブジェクトに関連付けられていたプリンシパルとクレデンシャルを削除します。クレデンシャルは削除時に破棄されるはずです。logoutメソッドのシグネチャーはboolean logout() throws LoginExceptionです。LoginExceptionの発生は、ログアウトプロセスの完了に失敗したことを示します。true が返されるとメソッドが成功したことを示し、false が返されるとログインモジュールが無視されることを示します。
LoginModule がユーザーと通信して認証情報を取得する必要がある場合、CallbackHandler オブジェクトを使用します。アプリケーションはインターフェースを実装して LoginContext に渡し、基礎となるログインモジュールに直接認証情報を送信します。
ログインモジュールは、CallbackHandler を使用して、パスワードやスマートカード PIN などのユーザー入力による情報を取得したり、ステータスなどの情報をユーザーに提供したりします。アプリケーションによる CallbackHandler の指定を可能にすることで、基礎となる LoginModule がアプリケーションとユーザーが対話するさまざまな方法に依存しないようにします。たとえば、GUI アプリケーションの CallbackHandler の実装は、ウィンドウを表示してユーザーの入力を求めることがあります。一方でアプリケーションサーバーなどの GUI でない環境の CallbackHandler 実装は、アプリケーションサーバー API を使用してクレデンシャル情報を取得することがあります。インターフェースには実装するメソッドが 1 つあります。
void handle(Callback[] callbacks)
throws java.io.IOException,
UnsupportedCallbackException;
void handle(Callback[] callbacks)
throws java.io.IOException,
UnsupportedCallbackException;
最後に説明する認証クラスは Callback インターフェースです。これは複数のデフォルト実装が提供されているタグ付けインターフェースで、前述の例で使用した NameCallback と PasswordCallback が含まれます。LoginModule は Callback を使用し、認証メカニズムで必要となる情報を要求します。LoginModule は認証のログインフェーズの間に Callback のアレイを直接 CallbackHandler.handle メソッドに渡します。callbackhandler がハンドルメソッドに渡された Callback オブジェクトの使用方法を理解できない場合は UnsupportedCallbackException が発生し、ログイン呼び出しが中止されます。
22.7. インターフェースのセキュア化 リンクのコピーリンクがクリップボードにコピーされました!
22.7.1. インターフェースのセキュア化 リンクのコピーリンクがクリップボードにコピーされました!
Hot Rod インターフェースはプログラムを使ってセキュア化できますが、memcached および REST インターフェースは宣言的にセキュア化する必要があります。これらのインターフェースをセキュア化する手順は、JBoss Data Grid の Administration and Configuration Guide を参照してください。
22.7.2. Hot Rod インターフェースセキュリティー リンクのコピーリンクがクリップボードにコピーされました!
22.7.2.1. Hot Rod サーバーと Hot Rod クライアント間の通信の暗号化 リンクのコピーリンクがクリップボードにコピーされました!
Hot Rod は TLS/SSL を使用して暗号化でき、証明書ベースのクライアント認証を必要とするオプションを指定できます。
以下の手順にしたがって、SSL を使用して Hot Rod コネクターをセキュア化します。
SSL/TLS を使用した Hot Rod のセキュア化
プレーンテキストのパスワードが設定またはソースコードに表示されないようにするには、プレーンテキストのパスワードを Vault パスワードに変更する必要があります。Vault パスワードのセットアップ方法についての詳細は、JBoss Enterprise Application Platform の『How to Configure Server Security』に記載されている パスワード Vault を参照してください。
22.7.2.2. SSL を使用した LDAP サーバーに対する Hot Rod のセキュア化 リンクのコピーリンクがクリップボードにコピーされました!
SSL を有効にして LDAP に接続する際に、適切な証明書が含まれるトラストストアまたはキーストアを指定する必要がある場合があります。
LDAP サーバーに対する Hot Rod クライアントの認証には、SSL 上の PLAIN 認証を使用できます。Hot Rod クライアントはプレーンテキストのクレデンシャルを SSL 上で JBoss Data Grid に送信し、サーバーは提供されたクレデンシャルを指定の LDAP サーバーに対して検証します。さらに、JBoss Data Grid サーバーと LDAP サーバー間にセキュアな接続を設定する必要があります。サーバーが LDAP バックエンドと通信するための設定方法の詳細は、JBoss Data Grid の Administration and Configuration Guide を参照してください。以下は、Hot Rod のクライアント側で SSL 上の PLAIN 認証を設定する例になります。
Hot Rod クライアントの LDAP サーバーに対する認証
プレーンテキストのパスワードが設定またはソースコードに表示されないようにするには、プレーンテキストのパスワードを Vault パスワードに変更する必要があります。Vault パスワードのセットアップ方法についての詳細は、Red Hat Enterprise Application Platform Security Guide を参照してください。
22.7.2.3. SASL を使用した Hot Rod でのユーザー認証 リンクのコピーリンクがクリップボードにコピーされました!
22.7.2.3.1. SASL を使用した Hot Rod でのユーザー認証 リンクのコピーリンクがクリップボードにコピーされました!
Hot Rod でのユーザー認証は、以下の SASL (Simple Authentication and Security Layer) メカニズムを使用して実装できます。
-
PLAINは、クレデンシャルがプレーンテキスト形式でトランスポートされるため、最も安全性の低いメカニズムになります。ただし、実装が最も単純なメカニズムでもあります。このメカニズムは、セキュリティーを強化するために暗号化 (SSL) と併用できます。 -
DIGEST-MD5は、クレデンシャルをトランスポートする前にハッシュ化するメカニズムです。その結果、PLAINメカニズムよりも安全性が高くなります。 -
GSSAPIは、Kerberos チケットを使用するメカニズムです。その結果、正しく設定された Kerberos Domain Controller (例: Microsoft Active Directory) が必要になります。 -
EXTERNALは、基礎となるトランスポート (例:X.509クライアント証明書) から必要なクレデンシャルを取得するメカニズムであるため、正常に機能するにはクライアント証明書の暗号化が必要です。
22.7.2.3.2. Hot Rod 認証の設定 (GSSAPI/Kerberos) リンクのコピーリンクがクリップボードにコピーされました!
以下の手順を使用し、SASL GSSAPI/Kerberos メカニズムを使用して Hot Rod 認証をセットアップします。
SASL GSSAPI/Kerberos 認証の設定: クライアント側の設定
- サーバー側の設定が完了していることを確認してください。この設定は宣言的に行われ、JBoss Data Grid の Administration and Configuration Guide に記載されています。
クライアント側のログイン設定ファイル (gss.conf) にログインモジュールを定義します。
[source],options="nowrap"
GssExample {
com.sun.security.auth.module.Krb5LoginModule required client=TRUE;
};
GssExample {
com.sun.security.auth.module.Krb5LoginModule required client=TRUE;
};
以下のシステムプロパティーを設定します。
java.security.auth.login.config=gss.conf java.security.krb5.conf=/etc/krb5.conf
java.security.auth.login.config=gss.conf java.security.krb5.conf=/etc/krb5.confCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記krb5.conf ファイルは環境に依存し、Keberos の鍵配布センター (Key Distribution Center) を示している必要があります。
CallbackHandlerを実装します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のように Hot Rod クライアントを設定します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
22.7.2.3.3. Hot Rod 認証 (MD5) の設定 リンクのコピーリンクがクリップボードにコピーされました!
以下の手順にしたがい、MD5 メカニズムを使用して SASL による Hot Rod 認証をセットアップします。
- サーバーに MD5 認証が設定されていることを確認してください。この設定を行う手順は、JBoss Data Grid の Administration and Configuration Guide に記載されています。
CallbackHandlerを実装します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のように、クライアントを設定された Hot Rod コネクターに接続します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
22.7.3. Hot Rod C++ クライアントの暗号化 リンクのコピーリンクがクリップボードにコピーされました!
デフォルトでは、リモートサーバーとの通信はすべて暗号化されていませんが、SslConfigurationBuilder で serverCAFile メソッドを使用してサーバーのキーを定義すると、TLS による暗号化を有効にすることができます。さらに、clientCertificateFile でクライアントの証明書を定義すると、クライアント認証を有効にできます。
以下は、任意のクライアント証明書でサーバーキーを定義する例になります。
Hot Rod C++ での TLS の例
クライアントは、sniHostName 関数に値を提供して TLS/SNI ハンドシェイク処理の開始時に接続を試みるホスト名を示すこともできます。たとえば、以下を使用できます。
[...]
builder.ssl().enable().serverCAFile(argv[1]).sniHostName("sni");
[...]
[...]
builder.ssl().enable().serverCAFile(argv[1]).sniHostName("sni");
[...]
22.7.4. Hot Rod C# クライアントの暗号化 リンクのコピーリンクがクリップボードにコピーされました!
デフォルトでは、リモートサーバーとの通信はすべて暗号化されていませんが、SslConfigurationBuilder で ServerCAFile メソッドを使用してサーバーのキーを定義すると、TLS による暗号化を有効にすることができます。さらに、ClientCertificateFile でクライアントの証明書を定義すると、クライアント認証を有効にできます。
以下は、任意のクライアント証明書でサーバーキーを定義する例になります。
Hot Rod C# での TLS の例
クライアントは、SniHostName に値を提供して TLS/SNI ハンドシェイク処理の開始時に接続を試みるホスト名を示すこともできます。たとえば、ServerCAFile を定義した直後に以下の呼び出しを含めることができます。
[...]
sslConfB.ServerCAFile("resources/infinispan-ca.pem").SniHostName("sni");
[...]
[...]
sslConfB.ServerCAFile("resources/infinispan-ca.pem").SniHostName("sni");
[...]
22.7.5. Hot Rod Node.js の暗号化 リンクのコピーリンクがクリップボードにコピーされました!
The Node.js クライアントは SSL/TLS 経由の暗号化と任意の TLS/SNI をサポートします。クライアントで設定を行うには、JDK に含まれる keytool アプリケーションを使用して Java KeyStore (JKS) を作成する必要があります。作成されたキーストアには、JBoss Data Grid サーバーが接続を承認するために必要なキーと証明書が含まれる必要があり、暗号化に対して JBoss Data Grid サーバーを設定する必要があります。暗号化に対してサーバーを設定するための詳細は、JBoss Data Grid の Administration and Configuration Guide を参照してください。
TLS/SSL の Node.js クライアント実装は自己署名証明書を許可しません。以前証明書が自己署名されていた場合は、ローカルの証明機関を設定して証明書に署名するか、オープンな証明機関を使用することが推奨されます。
信頼できる証明書の場所を定義すると、クライアントの接続がサーバーによって承認されます。
また、クライアントは PKCS#12 または PFX 形式のキーストアから信頼できる証明書を読み取ることもできます。
さらに、クライアントを暗号化された認証と設定することもできます。認証を設定するには、クライアントのプライベートキー、パスフレーズ、および証明書キーを提供する必要があります。
クライアントは、sniHostName ディレクティブを含めることで、TLS/SNI ハンドシェイク処理の開始時に接続を試みるホスト名を示すこともできます
sniHostName が提供されない場合、クライアントは localhost を SNI パラメーターとして送信します。サーバーのデフォルトレルムが localhost と一致しない場合、エラーが発生します。
22.8. セキュリティー監査ロガー リンクのコピーリンクがクリップボードにコピーされました!
22.8.1. セキュリティー監査ロガー リンクのコピーリンクがクリップボードにコピーされました!
Red Hat JBoss Data Grid には、キャッシュまたはキャッシュマネージャーの操作が各種操作で許可または拒否されたかどうかを確認するために、キャッシュのセキュリティーログを監査するロガーが含まれます。
デフォルトの監査ロガーは org.infinispan.security.impl.DefaultAuditLogger です。このロガーは、利用可能なロギングフレームワーク (JBoss Logging など) を使用して監査ログを出力し、TRACE レベルおよび AUDIT カテゴリーで結果を提供します。
AUDIT カテゴリーを、ログファイル、JMS キュー、またはデータベースのいずれかに送信するには、適切なログアペンダーを使用します。
22.8.2. セキュリティー監査ロガーの設定 (ライブラリーモード) リンクのコピーリンクがクリップボードにコピーされました!
以下のように、Red Hat JBoss Data Grid の監査ロガーを設定します。
GlobalConfigurationBuilder global = new GlobalConfigurationBuilder();
global.security()
.authorization()
.auditLogger(new DefaultAuditLogger());
GlobalConfigurationBuilder global = new GlobalConfigurationBuilder();
global.security()
.authorization()
.auditLogger(new DefaultAuditLogger());
22.8.3. カスタム監査ロガー リンクのコピーリンクがクリップボードにコピーされました!
ユーザーは、カスタム監査ロガーを Red Hat JBoss Data Grid のライブラリーおよびリモートクライアントサーバーモードで実装できます。カスタムロガーは org.infinispan.security.AuditLogger インターフェースを実装する必要があります。カスタムロガーが指定されない場合、デフォルトのロガー (DefaultAuditLogger) が使用されます。