25.9. インターフェースのセキュア化
25.9.1. Hot Rod インターフェースセキュリティー
25.9.1.1. Hot Rod エンドポイントをパブリックインターフェースとして公開
Red Hat JBoss Data Grid の Hot Rod サーバーはデフォルトで管理インターフェースとして動作します。操作をパブリックインターフェースに拡張するには、以下のように、
management
の socket-binding
要素の interface
パラメーターの値を public
に変更します。
<socket-binding name="hotrod" interface="public" port="11222" />
25.9.1.2. Hot Rod サーバーと Hot Rod クライアント間の通信の暗号化
Hot Rod は TLS/SSL を使用して暗号化でき、証明書ベースのクライアント認証を必要とするオプションを使用できます。
以下の手順を使用し、SSL を使用して Hot Rod コネクターのセキュリティーを保護します。
手順25.3 SSL/TLS を使用したセキュアな Hot Rod
キーストアを生成します。
JDK と共に配信されるキーツールアプリケーションを使用して Java キーストアを作成し、証明書をこれに追加します。証明書は、セキュリティーポリシーに応じて自己署名型を使用するか、または信頼された CA から取得できます。キーストアを設定ディレクトリーに配置します。
キーストアを、~/JDG_HOME/docs/examples/configs
ディレクトリーからのstandalone-hotrod-ssl.xml
ファイルとと共に~/JDG_HOME/standalone/configuration
ディレクトリーに配置します。SSL サーバー ID を宣言します。
設定ファイルの管理セクションのセキュリティーレルム内で SSL サーバー ID を宣言します。SSL サーバー ID ではキーストアへのパスとそのシークレットキーを指定する必要があります。<server-identities> <ssl protocol="..."> <keystore path="..." relative-to="..." keystore-password="${VAULT::VAULT_BLOCK::ATTRIBUTE_NAME::ENCRYPTED_VALUE}" /> </ssl> <secret value="..." /> </server-identities>
これらのパラメーターについての詳細は、「Hot Rod 認証の設定 (X.509) 」を参照してください。セキュリティー要素を追加します。
以下のようにセキュリティー要素を Hot Rod コネクターに追加します。<hotrod-connector socket-binding="hotrod" cache-container="local"> <encryption ssl="true" security-realm="ApplicationRealm" require-ssl-client-auth="false" /> </hotrod-connector>
証明書のサーバー認証
サーバーがクライアント証明書の認証を実行できるようにするには、有効なクライアント証明書を含むトラストストアを作成し、require-ssl-client-auth
属性をtrue
に設定します。
サーバーを起動します。
以下を使用してサーバーを起動します。bin/standalone.sh -c standalone-hotrod-ssl.xml
これにより、Hot Rod エンドポイントがポート 11222 にある状態でサーバーが起動します。このエンドポイントは SSL 接続のみを受け入れます。
重要
プレーンテキストのパスワードが設定またはソースコードに表示されないようにするには、プレーンテキストのパスワードを Vault パスワードに変更する必要があります。Vault パスワードのセットアップ方法についての詳細は、『Red Hat Enterprise Application Platform Security Guide』 を参照してください。
25.9.1.3. SSL を使用した Hot Rod のセキュア化
SSL を有効にして LDAP に接続する際に、適切な証明書が含まれるトラストストアまたはキーストアを指定する必要がある場合があります。
「Hot Rod サーバーと Hot Rod クライアント間の通信の暗号化」 は、Hot Rod クライアント/サーバー間通信のために SSH をセットアップする方法について説明しています。これは、たとえば
PLAIN
ユーザー名/パスワードを使ったセキュアな Hot Rod クライアントの認証に使用できます。ユーザー名/パスワードが LDAP のクレデンシャルに対してチェックされる際、Hot Rod サーバーから LDAP サーバーへのセキュアな接続も必要になります。SSL 経由で Hot Rod サーバーから LDAP への接続を有効にするには、セキュリティーレルムを以下のように定義する必要があります。
例25.12 Hot Rod クライアントの LDAP サーバーに対する認証
<management> <security-realms> <security-realm name="LdapSSLRealm"> <authentication> <truststore path="ldap.truststore" relative-to="jboss.server.config.dir" keystore-password=${VAULT::VAULT_BLOCK::ATTRIBUTE_NAME::ENCRYPTED_VALUE} /> </authentication> </security-realm> </security-realms> <outbound-connections> <ldap name="LocalLdap" url="ldaps://localhost:10389" search-dn="uid=wildfly,dc=simple,dc=wildfly,dc=org" search-credential="secret" security-realm="LdapSSLRealm" /> </outbound-connections> </management>
重要
プレーンテキストのパスワードが設定またはソースコードに表示されないようにするには、プレーンテキストのパスワードを Vault パスワードに変更する必要があります。Vault パスワードのセットアップ方法についての詳細は、『 Red Hat Enterprise Application Platform Security Guide』 を参照してください。
25.9.1.4. 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
クライアント証明書) から必要なクレデンシャルを取得するメカニズムであるため、正常に機能するにはクライアント証明書の暗号化が必要です。
25.9.1.4.1. Hot Rod 認証の設定 (GSSAPI/Kerberos)
以下の手順を使用し、SASL GSSAPI/Kerberos メカニズムを使用して Hot Rod 認証をセットアップします。
手順25.4 SASL GSSAPI/Kerberos 認証の設定: サーバー側の設定
- セキュリティードメインサブシステムを使用して Kerberos のセキュリティーログインモジュールを定義します。
<system-properties> <property name="java.security.krb5.conf" value="/tmp/infinispan/krb5.conf"/> <property name="java.security.krb5.debug" value="true"/> <property name="jboss.security.disable.secdomain.option" value="true"/> </system-properties> <security-domain name="infinispan-server" cache-type="default"> <authentication> <login-module code="Kerberos" flag="required"> <module-option name="debug" value="true"/> <module-option name="storeKey" value="true"/> <module-option name="refreshKrb5Config" value="true"/> <module-option name="useKeyTab" value="true"/> <module-option name="doNotPrompt" value="true"/> <module-option name="keyTab" value="/tmp/infinispan/infinispan.keytab"/> <module-option name="principal" value="HOTROD/localhost@INFINISPAN.ORG"/> </login-module> </authentication> </security-domain>
- キャッシュコンテナーに承認ロールが定義されており、これらのロールが 「Red Hat JBoss Data Grid の承認の設定」 に示されるようにキャッシュの承認ブロックで適用されていることを確認します。
- Hot Rod コネクターを以下のように設定します。
<hotrod-connector socket-binding="hotrod" cache-container="default"> <authentication security-realm="ApplicationRealm"> <sasl server-name="node0" mechanisms="{mechanism_name}" qop="{qop_name}" strength="{value}"> <policy> <no-anonymous value="true" /> </policy> <property name="com.sun.security.sasl.digest.utf8">true</property> </sasl> </authentication> </hotrod-connector>
server-name
属性は、サーバーが着信クライアントに対して宣言する名前を指定します。クライアント設定にも同じサーバー名の値が含まれる必要があります。server-context-name
属性は、特定の SASL メカニズムのサーバーサブジェクトを取得するために使用されるログインコンテキストの名前を指定します (例: GSSAPI)。mechanisms
属性は、使用される認証メカニズムを指定します。サポートされるメカニズムの一覧は、「SASL を使用した Hot Rod でのユーザー認証」 を参照してください。qop
属性は、設定についての本番環境の値の SASL の品質を指定します。この属性のサポートされる値は、auth
(認証)、auth-int
(改ざんを検出するためにメッセージがチェックサムに対して検証されることを意味する認証と整合性)、およびauth-conf
(メッセージの暗号化も行われることを意味する認証、整合性および機密性) です。auth-int auth-conf
などのように複数の値を指定できます。順番は優先順位を示し、クライアントとサーバーの優先順位の両方に一致する最初の値が選択されます。strength
属性は、SASL の暗号強度を指定します。有効な値はlow
、medium
、およびhigh
です。policy
要素内のno-anonymous
要素は、匿名ログインを受け入れるメカニズムを許可するかどうかを指定します。許可するには、この値をfalse
にし、拒否するにはtrue
に設定します。
- 各クライアントでクライアント側の設定を実行します。Hot Rod クライアントをプログラムを用いて設定する際に、この設定の情報については、JBoss Data Grid の 『Developer Guide』 で確認できます。
25.9.1.4.2. Hot Rod 認証の設定 (MD5)
以下の手順を使用し、MD5 メカニズムを使用した SASL による Hot Rod 認証をセットアップします。
手順25.5 Hot Rod 認証の設定 (MD5)
sasl
要素をauthentication
要素に追加し、以下のように Hot Rod コネクター設定をセットアップします (authentication
要素の詳細は、「セキュリティーレルムの宣言的な有効化」 を参照してください)。<hotrod-connector socket-binding="hotrod" cache-container="default"> <authentication security-realm="ApplicationRealm"> <sasl server-name="myhotrodserver" mechanisms="DIGEST-MD5" qop="auth" /> </authentication> </hotrod-connector>
server-name
属性は、サーバーが着信クライアントに対して宣言する名前を指定します。クライアント設定にも同じサーバー名の値が含まれる必要があります。mechanisms
属性は、使用される認証メカニズムを指定します。サポートされるメカニズムの一覧は、「SASL を使用した Hot Rod でのユーザー認証」 を参照してください。qop
属性は、設定についての本番環境の値の SASL の品質を指定します。この属性のサポートされる値は、auth
、auth-int
、およびauth-conf
です。
- 各クライアントが Hot Rod コネクターに接続されるように設定します。この手順をプログラムを用いて実行する際に、その方法については JBoss Data Grid の 『Developer Guide』 で確認できます。
25.9.1.4.3. LDAP/Active Directory を使用した Hot Rod の設定
以下を使用し、LDAP または Microsoft Active Directory を使用して Hot Rod で認証を設定します。
<security-realms> <security-realm name="ApplicationRealm"> <authentication> <ldap connection="ldap_connection" recursive="true" base-dn="cn=users,dc=infinispan,dc=org"> <username-filter attribute="cn" /> </ldap> </authentication> </security-realm> </security-realms> <outbound-connections> <ldap name="ldap_connection" url="ldap://my_ldap_server" search-dn="CN=test,CN=Users,DC=infinispan,DC=org" search-credential="Test_password"/> </outbound-connections>
以下は、この設定で使用される要素およびパラメーターについての詳細です。
security-realm
要素のname
パラメーターは、接続の確立時に使用するために参照するセキュリティーレルムを指定します。authentication
要素には認証の詳細情報が含まれます。ldap
要素は、ユーザーを認証するために LDAP 検索を使用する方法を指定します。最初に、LDAP への接続が確立され、ユーザーの識別名を特定するために指定されるユーザー名を使用して検索が実行されます。その後のサーバーへの接続は、ユーザーが指定するパスワードを使って確立されます。2 番目の接続が成功すると認証が行われます。connection
パラメーターは、LDAP に接続するために使用する接続の名前を指定します。- (オプション)
recursive
パラメーターは、フィルターが再帰的に実行されるかどうかを指定します。このパラメーターのデフォルト値はfalse
です。 base-dn
パラメーターは、検索の開始に使用するコンテキストの識別名を指定します。- (オプション)
user-dn
パラメーターは、ユーザーの検索後にユーザーの識別名を読み取るために使用する属性を指定します。このパラメーターのデフォルト値はdn
です。
outbound-connections
要素は LDAP ディレクトリーに接続するために使用される接続名を指定します。ldap
要素は送信 LDAP 接続のプロパティーを指定します。name
パラメーターは、この接続を参照するために使用される固有名を指定します。url
パラメーターは、LDAP 接続を確立するために使用される URL を指定します。search-dn
パラメーターは、認証対象で、検索を実行するためのユーザーの識別名を指定します。search-credential
パラメーターは、LDAP にsearch-dn
として接続することが必要なパスワードを指定します。- (オプション)
initial-context-factory
パラメーターは、初期のコンテキストファクトリーのオーバーライドを許可します。このパラメーターのデフォルト値はcom.sun.jndi.ldap.LdapCtxFactory
です。
25.9.1.4.4. Hot Rod 認証の設定 (X.509)
X.509
証明書をノードでインストールでき、かつ受信および送信 SSL 接続の認証のためにこれを他のノードで利用できるようにすることができます。これは、サーバーの外部アプリケーションへの表示方法を定義するセキュリティーレルム定義の <server-identities/>
要素を使用して有効にされます。この要素は、リモート接続の確立時、および X.509
キーのロード時に使用されるパスワードを設定するために使用できます。
以下の例は、
X.509
証明書をノードにインストールする方法を示しています。
<security-realm name="ApplicationRealm"> <server-identities> <ssl protocol="..."> <keystore path="..." relative-to="..." keystore-password="..." alias="..." key-password="..." /> </ssl> </server-identities> [... authentication/authorization ...] </security-realms>
この例では、SSL 要素に <keystore/> 要素が含まれます。これは、キーをファイルベースのキーストアからロードする方法を定義するために使用されます。以下のパラメーターはこの要素に利用できます。
パラメーター | 必須/オプション | 説明 |
---|---|---|
path | 必須 | これはキーストアへのパスです。絶対パスを使用することも、次の属性の相対パスを使用することもできます。 |
relative-to | 任意 | キーストアが相対するパスを表すサービスの名前。 |
keystore-password | 必須 | キーストアを開くために必要なパスワード。 |
alias | 任意 | キーストアから使用するエントリーのエイリアス。複数のエントリーが使用されるキーストアの場合、最初に使用できるエントリーが使用されますが、これに依存するのではなく、使用されるエントリーを保証できるようにエイリアスを設定する必要があります。 |
key-password | 任意 | キーエントリーをロードするためのパスワード。省略されている場合、keystore-password が代わりに使用されます。 |
注記
以下のエラーが発生する場合、1 つのキーのみがロードされていることを確認するために、
key-password
および alias
を指定します。
UnrecoverableKeyException: Cannot recover key
25.9.2. REST インターフェースセキュリティー
25.9.2.1. REST エンドポイントをパブリックインターフェースとして公開
Red Hat JBoss Data Grid の REST サーバーはデフォルトで管理インターフェースとして動作します。操作をパブリックインターフェースに拡張するには、以下のように、
management
の socket-binding
要素の interface
パラメーターの値を public
に変更します。
<socket-binding name="http" interface="public" port="8080"/>
25.9.2.2. REST エンドポイントのセキュリティーの有効化
以下の手順を使用して、Red Hat JBoss Data Grid で REST エンドポイントのセキュリティーを有効にします。
注記
REST エンドポイントは、JBoss Enterprise Application Platform のセキュリティーサブシステムプロバイダーのいずれかをサポートします。
手順25.6 REST エンドポイントのセキュリティーの有効化
REST インターフェースを使用する場合に JBoss Data Grid のセキュリティーを有効にするには、
standalone.xml
に以下の変更を行います。
セキュリティーパラメーターの指定
rest エンドポイントでsecurity-domain
パラメーターおよびauth-method
パラメーターの有効な値を指定するようにします。これらのパラメーターの推奨設定は以下のとおりです。<subsystem xmlns="urn:infinispan:server:endpoint:8.0"> <rest-connector virtual-server="default-host" cache-container="local" security-domain="other" auth-method="BASIC"/> </subsystem>
セキュリティードメイン宣言のチェック
セキュリティーサブシステムに、対応するセキュリティードメイン宣言が含まれるようにします。セキュリティードメイン宣言の設定の詳細については、JBoss Enterprise Application Platform 7 ドキュメンテーションを参照してください。アプリケーションユーザーの追加
該当するスクリプトを実行し、アプリケーションユーザーを追加する設定を入力します。adduser.sh
スクリプト ($JDG_HOME/bin
に存在) を実行します。- Windows システムでは、
adduser.bat
ファイル ($JDG_HOME/bin
に存在) を代わりに実行します。
- 追加するユーザーのタイプについて尋ねられたら、
b
を入力してApplication User (application-users.properties)
を選択します。 - リターンキーを押して、レルム (
ApplicationRealm
) のデフォルト値を使用します。 - ユーザー名とパスワードを指定します。
- グループを尋ねられたら、
REST
と入力します。 - プロンプトが表示されたら、ユーザー名とアプリケーションレルム情報が正しいことを確認し、"yes" と入力して作業を続行します。
作成されたアプリケーションユーザーの確認
作成されたアプリケーションユーザーが正しく設定されていることを確認します。application-users.properties
ファイル ($JDG_HOME/standalone/configuration/
に存在) にリストされた設定を確認します。以下は、このファイルの正しい設定の例です。user1=2dc3eacfed8cf95a4a31159167b936fc
application-roles.properties
ファイル ($JDG_HOME/standalone/configuration/
に存在) にリストされた設定を確認します。以下は、このファイルの正しい設定の例です。user1=REST
サーバーのテスト
サーバーを起動し、ブラウザーウィンドウに以下のリンクを入力して REST エンドポイントにアクセスします。http://localhost:8080/rest/namedCache
注記
GET 要求の使用をテストする場合は、405
応答コードが期待され、サーバーが正常に認証されたことが示されます。
25.9.3. Memcached インターフェースセキュリティー
25.9.3.1. Memcached エンドポイントをパブリックインターフェースとして公開
Red Hat JBoss Data Grid の memcached サーバーは、デフォルトで管理インターフェースとして機能します。memcached 操作をパブリックインターフェースに拡張することはできますが、このインターフェースに使用できる追加のセキュリティーはありません。セキュリティーに関連する懸念点がある場合には、このインターフェースを、分離された内部ネットワークに留めるか、または REST または Hot Rod インターフェースのいずれかを使用することをお勧めします。
memcached インターフェースをパブリックインターフェースとして設定するには、
socket-binding
要素の interface
パラメーターの値を、以下のように management
から public
に変更します。
<socket-binding name="memcached" interface="public" port="11211" />