2.2. 管理インターフェイスのセキュア化の方法
ここでは、JBoss EAP 管理インターフェイスと関連サブシステムのセキュア化に関連するさまざまな操作を実行する方法を説明します。
ここで使用する管理 CLI コマンドは、JBoss EAP スタンドアロンサーバーを実行していることを仮定しています。JBoss EAP 管理対象ドメインの管理 CLI の使用の詳細は、JBoss EAP 管理 CLI ガイド を参照してください。
2.2.1. JBoss EAP で使用されるネットワークとポートの設定 リンクのコピーリンクがクリップボードにコピーされました!
ホストの設定に応じて、JBoss EAP はさまざまなネットワークインターフェイスおよびポートを使用するように設定できます。これにより、JBoss EAP はさまざまなホスト、ネットワーク、およびファイアウォール要件で使用できます。
JBoss EAP で使用されるネットワークとポート、およびそれらの設定の設定方法の詳細は、設定ガイド の ネットワークとポートの設定 セクションを参照してください。
2.2.2. HTTPS の管理インターフェイスの設定 リンクのコピーリンクがクリップボードにコピーされました!
HTTPS を使用した通信のみを行うように JBoss EAP 管理インターフェイスを設定すると、セキュリティーが強化されます。クライアントと管理インターフェイス間のすべてのネットワークトラフィックは暗号化されるため、中間者攻撃などのセキュリティー攻撃のリスクが軽減されます。
この手順では、JBoss EAP インスタンスとの暗号化されていない通信を無効にします。この手順は、スタンドアロンサーバーとマネージドドメイン設定の両方に該当します。マネージドドメインの場合は、管理 CLI コマンドにホスト名 (例: /host=master) を付けます。
管理インターフェイスで HTTPS を有効にする手順を実行している間は、明示的に指示されない限り、設定を再ロードしないでください。これを実行すると、管理インターフェイスがロックされる可能性があります。
キーストアを作成して、管理インターフェイスのセキュリティーを確保します。
注記このキーストアは、管理インターフェイスが JCEKS 形式のキーストアと互換性がないため、JKS 形式である必要があります。
以下を実行してキーストアを生成します。パラメーターの例の値 (例:
alias、keypass、keystore、storepass、dname) を環境に適切な値に置き換えます。注記パラメーターの
validityは、キーが有効な日数を指定します。730の値は 2 年と等しくなります。keytoolコマンドを使用してターミナルからキーストアを生成します$ keytool -genkeypair -alias appserver -storetype jks -keyalg RSA -keysize 2048 -keypass password1 -keystore EAP_HOME/standalone/configuration/identity.jks -storepass password1 -dname "CN=appserver,OU=Sales,O=Systems Inc,L=Raleigh,ST=NC,C=US" -validity 730 -v管理インターフェイスが HTTPS にバインドされていることを確認します。
スタンドアロンサーバーを実行しています。
管理インターフェイスが HTTPS にバインドされるようにするには、
management-https設定を追加し、management-http設定を削除する必要があります。以下の CLI コマンドを使用して管理インターフェイスを HTTPS にバインドします。
/core-service=management/management-interface=http-interface:write-attribute(name=secure-socket-binding, value=management-https) /core-service=management/management-interface=http-interface:undefine-attribute(name=socket-binding)マネージドドメインの起動
secure-portを追加し、ポート設定を削除して、management-interfaceセクション内の socket 要素を変更します。以下のコマンドを使用して管理インターフェイスを HTTPS にバインドします。
/host=master/core-service=management/management-interface=http-interface:write-attribute(name=secure-port,value=9993) /host=master/core-service=management/management-interface=http-interface:undefine-attribute(name=port)
オプション: カスタム socket-binding-group を使用します。カスタムの
socket-binding-groupを使用する場合は、management-httpsバインディングが定義されていることを確認する必要があります。デフォルトではポート9993にバインドされます。これを確認するには、サーバーの設定ファイルのsocket-binding-groupセクションを確認するか、管理 CLI を使用します。管理 CLI を使用して socket-binding-group 設定を読み取る例
/socket-binding-group=standard-sockets/socket-binding=management-https:read-resource(recursive=true) { "outcome" => "success", "result" => { "client-mappings" => undefined, "fixed-port" => false, "interface" => "management", "multicast-address" => undefined, "multicast-port" => undefined, "name" => "management-https", "port" => expression "${jboss.management.https.port:9993}" } }新しいセキュリティーレルムを作成します。この例では、HTTPS を使用する新しいセキュリティーレルム ManagementRealmHTTPS は、
EAP_HOME/standalone/configuration/ディレクトリーにあるhttps-mgmt-users.propertiesという名前のプロパティーファイルを使用して、ユーザー名とパスワードを保存します。ユーザー名とパスワードは後でファイルに追加できます。ただし、現在は、https-mgmt-users.propertiesという名前で空のファイルを作成し、その場所に保存する必要があります。以下の例は、touchコマンドの使用を示しています。しかし、テキストエディターなどの他のメカニズムを使用することもできます。touchコマンドを使用して空のファイルを作成する例$ touch EAP_HOME/standalone/configuration/https-mgmt-users.properties次に、次の CLI コマンドを入力して、ManagementRealmHTTPS という名前の新しいセキュリティーレルムを作成します。
/core-service=management/security-realm=ManagementRealmHTTPS:add /core-service=management/security-realm=ManagementRealmHTTPS/authentication=properties:add(path=https-mgmt-users.properties,relative-to=jboss.server.config.dir)これで、新しいセキュリティーレルムを作成し、認証用にプロパティーファイルを使用するよう設定しました。次に、
EAP_HOME/bin/ディレクトリーのadd-userスクリプトを使用して、そのプロパティーファイルにユーザーを追加する必要があります。add-userスクリプトを実行する際には、-upと-rオプションをそれぞれ使用してプロパティーファイルとセキュリティーレルムの両方を指定する必要があります。そこから、add-userスクリプトは、https-mgmt-users.propertiesファイルに保存するユーザー名とパスワード情報を対話的に要求します。$ EAP_HOME/bin/add-user.sh -up EAP_HOME/standalone/configuration/https-mgmt-users.properties -r ManagementRealmHTTPS ... Enter the details of the new user to add. Using realm 'ManagementRealmHTTPS' as specified on the command line. ... Username : httpUser Password requirements are listed below. To modify these restrictions edit the add-user.properties configuration file. - The password must not be one of the following restricted values {root, admin, administrator} - The password must contain at least 8 characters, 1 alphabetic character(s), 1 digit(s), 1 non-alphanumeric symbol(s) - The password must be different from the username ... Password : Re-enter Password : About to add user 'httpUser' for realm 'ManagementRealmHTTPS' ... Is this correct yes/no? yes .. Added user 'httpUser' to file 'EAP_HOME/configuration/https-mgmt-users.properties' ... Is this new user going to be used for one AS process to connect to another AS process? e.g. for a slave host controller connecting to the master or for a Remoting connection for server to server EJB calls. yes/no? no重要プロパティーファイルを使用してユーザー名とパスワードを保存するようにセキュリティーレルムを設定する場合、各レリムは別のレルムと共有されていない個別のプロパティーを使用することが推奨されます。
新しいセキュリティーレルムを使用するように管理インターフェイスを設定します。
/core-service=management/management-interface=http-interface:write-attribute(name=security-realm,value=ManagementRealmHTTPS)キーストアを使用するように管理インターフェイスを設定します。
以下の CLI コマンドを使用して、キーストアを使用するように管理インターフェイスを設定します。パラメーターファイル、パスワード、およびエイリアスについては、その値を 最初の手順 からコピーする必要があります。
キーストアをセキュリティーレルムに追加するための CLI コマンド
/core-service=management/security-realm=ManagementRealmHTTPS/server-identity=ssl:add(keystore-path=identity.jks,keystore-relative-to=jboss.server.config.dir,keystore-password=password1, alias=appserver)注記キーストアのパスワードを更新するには、以下の CLI コマンドを使用します。
/core-service=management/security-realm=ManagementRealmHTTPS/server-identity=ssl:write-attribute(name=keystore-password,value=newpassword)このときは、サーバーの設定をリロードする必要があります。
reloadサーバー設定のリロード後には、起動したサービスの数を示すテキストの直前に以下の内容がログに含まれるはずです。
13:50:54,160 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0061: Http management interface listening on https://127.0.0.1:9993/management 13:50:54,162 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0052: Admin console listening on https://127.0.0.1:9993これで、管理インターフェイスはポート
9993をリッスンするようになります。これにより、手順が成功したことを確認できました。重要このとき、CLI は接続を切断し、ポートバインディングが変更されたため再接続できなくなります。次の手順 に進み、
jboss-cli.xmlを更新して CLI が再接続できるようにします。jboss-cli.xmlを更新します。管理 CLI を使用して管理アクションを実行する場合は、
EAP_HOME/bin/jboss-cli.xmlファイルに次の変更を加える必要があります。-
<default-protocol>の値をhttps-remotingに更新します。 -
<default-controller>において、<protocol>の値をhttps-remotingに更新します。 <default-controller>で、<port>の値を9993に更新します。jboss-cli.xml の例
<jboss-cli xmlns="urn:jboss:cli:2.0"> <default-protocol use-legacy-override="true">https-remoting</default-protocol> <!-- The default controller to connect to when 'connect' command is executed w/o arguments --> <default-controller> <protocol>https-remoting</protocol> <host>localhost</host> <port>9993</port> </default-controller> ...次回、管理 CLI を使用して管理インターフェイスに接続する場合は、サーバー証明書を受け入れ、
ManagementRealmHTTPSセキュリティーレルムに対して認証を行う必要があります。サーバー証明書の受け入れと認証の例
$ ./jboss-cli.sh -c Unable to connect due to unrecognised server certificate Subject - CN=appserver,OU=Sales,O=Systems Inc,L=Raleigh,ST=NC,C=US Issuer - CN=appserver, OU=Sales, O=Systems Inc, L=Raleigh, ST=NC, C=US Valid From - Tue Jun 28 13:38:48 CDT 2016 Valid To - Thu Jun 28 13:38:48 CDT 2018 MD5 : 76:f4:81:8b:7e:c3:be:6d:ee:63:c1:7a:b7:b8:f0:fb SHA1 : ea:e3:f1:eb:53:90:69:d0:c9:69:4a:5a:a3:20:8f:76:c1:e6:66:b6 Accept certificate? [N]o, [T]emporarily, [P]ermenantly : p Authenticating against security realm: ManagementRealmHTTPS Username: httpUser Password: [standalone@localhost:9993 /]
-
2.2.3. 管理コンソールのみを無効にする リンクのコピーリンクがクリップボードにコピーされました!
JBoss Operations Network などの他のクライアントは、JBoss EAP の管理に HTTP インターフェイスを使用して動作します。これらのサービスの使用を継続するには、Web ベースの管理コンソール自体を無効にしてください。これは、console-enabled 属性を false に設定すると実行できます。
Web ベースの管理コンソールを無効にするための CLI コマンド
/core-service=management/management-interface=http-interface/:write-attribute(name=console-enabled,value=false)
2.2.4. 管理インターフェイスの双方向 SSL/TLS の設定 リンクのコピーリンクがクリップボードにコピーされました!
クライアント認証 とも呼ばれる双方向 SSL/TLS 認証は、SSL/TLS 証明書を使用してクライアントとサーバーの両方を認証します。これは、クライアントとサーバーの両方に証明書があるという点で、HTTPS 用の管理インターフェイスの設定 セクションとは異なります。そのため、サーバーの伝えるアイデンティティーだけでなく、クライアントの伝えるアイデンティティーも信頼できます。
本セクションでは、以下の規則を使用します。
- HOST1
-
JBoss サーバーのホスト名。例:
jboss.redhat.com. - HOST2
-
クライアントに適した名前。例:
myclientこれは必ずしも実際のホスト名ではないことに注意してください。 - CA_HOST1
-
HOST1 証明書に使用する DN (識別名) です。たとえば、
cn=jboss,dc=redhat,dc=comとなります。 - CA_HOST2
-
HOST2 証明書に使用する DN (識別名) です。例:
cn=myclient,dc=redhat,dc=com
キーストアおよびトラストストアパスワードの保存にパスワード vault が使用された場合 (推奨)、パスワード vault はすでに作成されている必要がある。パスワード Vault の詳細は、Red Hat JBoss Enterprise Application Platform 7 セキュリティーアーキテクチャーガイド の パスワード Vault セクションおよび パスワード Vault システム セクションを参照してください。
Red Hat では、影響するすべてのパッケージで TLSv1.1 または TLSv1.2 を利用するために SSLv2、SSLv3、および TLSv1.0 を明示的に無効化することを推奨しています。
キーストアを生成します。
$ keytool -genkeypair -alias HOST1_alias -keyalg RSA -keysize 1024 -validity 365 -keystore HOST1.keystore.jks -dname "CA_HOST1" -keypass secret -storepass secret $ keytool -genkeypair -alias HOST2_alias -keyalg RSA -keysize 1024 -validity 365 -keystore HOST2.keystore.jks -dname "CA_HOST2" -keypass secret -storepass secret証明書をエクスポートします。
$ keytool -exportcert -keystore HOST1.keystore.jks -alias HOST1_alias -keypass secret -storepass secret -file HOST1.cer $ keytool -exportcert -keystore HOST2.keystore.jks -alias HOST2_alias -keypass secret -storepass secret -file HOST2.cer対立するトラストストアにインポートします。
$ keytool -importcert -keystore HOST1.truststore.jks -storepass secret -alias HOST2_alias -trustcacerts -file HOST2.cer $ keytool -importcert -keystore HOST2.truststore.jks -storepass secret -alias HOST1_alias -trustcacerts -file HOST1.cerCertificateRealm を定義します。
サーバー (
host.xmlまたはstandalone.xml) の設定で CertificateRealm を定義し、その先となるインターフェイスを指定します。これは、以下のコマンドで実行できます。/core-service=management/security-realm=CertificateRealm:add() /core-service=management/security-realm=CertificateRealm/server-identity=ssl:add(keystore-path=/path/to/HOST1.keystore.jks, keystore-password=secret,alias=HOST1_alias) /core-service=management/security-realm=CertificateRealm/authentication=truststore:add(keystore-path=/path/to/HOST1.truststore.jks,keystore-password=secret)http-interfaceのsecurity-realmを新しい CertificateRealm に変更します。/core-service=management/management-interface=http-interface:write-attribute(name=security-realm,value=CertificateRealm)CLI の SSL/TLS 設定を追加します。
重要双方向 SSL/TLS の追加に加え、管理インターフェイスも HTTPS にバインドされるように設定 してください。
EAP_HOME/bin/jboss-cli.xmlを設定ファイルとして使用する CLI の SSL/TLS 設定を追加します。キーストアとトラストストアのパスワードをプレーンテキストで保存するには、
EAP_HOME/bin/jboss-cli.xmlを編集し、変数に適切な値を使用して SSL/TLS 設定を追加します。jboss-cli.xml XML の例
<ssl> <alias>HOST2_alias</alias> <key-store>/path/to/HOST2.keystore.jks</key-store> <key-store-password>secret</key-store-password> <trust-store>/path/to/HOST2.truststore.jks</trust-store> <trust-store-password>secret</trust-store-password> <modify-trust-store>true</modify-trust-store> </ssl>パスワード vault に保存されているキーストアおよびトラストストアパスワードを使用するには、vault 設定および適切な vault の値を
EAP_HOME/bin/jboss-cli.xmlに追加する必要があります。jboss-cli.xml XML の例
<ssl> <vault> <vault-option name="KEYSTORE_URL" value="path-to/vault/vault.keystore"/> <vault-option name="KEYSTORE_PASSWORD" value="MASK-5WNXs8oEbrs"/> <vault-option name="KEYSTORE_ALIAS" value="vault"/> <vault-option name="SALT" value="12345678"/> <vault-option name="ITERATION_COUNT" value="50"/> <vault-option name="ENC_FILE_DIR" value="EAP_HOME/vault/"/> </vault> <alias>HOST2_alias</alias> <key-store>/path/to/HOST2.keystore.jks</key-store> <key-store-password>VAULT::VB::cli_pass::1</key-store-password> <key-password>VAULT::VB::cli_pass::1</key-password> <trust-store>/path/to/HOST2.truststore.jks</trust-store> <trust-store-password>VAULT::VB::cli_pass::1</trust-store-password> <modify-trust-store>true</modify-trust-store> </ssl>
2.2.5. アプリケーション用の SSL/TLS の設定 リンクのコピーリンクがクリップボードにコピーされました!
JBoss EAP では、管理インターフェイスの HTTPS および双方向 SSL/TLS のサポートに加えて、セキュリティードメインで使用するために SSL/TLS (HTTPS リスナー経由) を設定することもできます。
前提条件として、SSL/TLS 暗号化キーと証明書を作成し、アクセス可能なディレクトリーに配置する必要があります。さらに、関連情報 (キーストアのエイリアスとパスワード、必要な暗号スイートなど) にもアクセスできる必要があります。SSL/TLS キーと証明書の生成例については、管理インターフェイスの双方向 SSL/TLS の設定セクション の最初の 2 つの手順を参照してください。HTTPS リスナー (暗号スイートを含む) の詳細は、HTTPS リスナーのリファレンスセクション を参照してください。
一方向 SSL/TLS の設定
この例では、キーストアの identity.jks がサーバー設定ディレクトリーにコピーされ、指定のプロパティーで設定されたことを仮定します。管理者は、example の独自の値を置き換えてください。
ここで使用する管理 CLI コマンドは、JBoss EAP スタンドアロンサーバーを実行していることを仮定しています。JBoss EAP 管理対象ドメインの管理 CLI の使用の詳細は、JBoss EAP 管理 CLI ガイド を参照してください。
最初に HTTPS セキュリティーレルムを追加し、設定します。HTTPS セキュリティーレルムが設定されたら、セキュリティーレルムを参照する
undertowサブシステムでhttps-listenerを設定します。batch /core-service=management/security-realm=HTTPSRealm/:add /core-service=management/security-realm=HTTPSRealm/server-identity= \ ssl:add(keystore-path=identity.jks, \ keystore-relative-to=jboss.server.config.dir, \ keystore-password=password1, alias=appserver) /subsystem=undertow/server=default-server/https-listener=https:add( \ socket-binding=https, security-realm=HTTPSRealm) run-batch警告Red Hat では、影響するすべてのパッケージで TLSv1.1 または TLSv1.2 を利用するために SSLv2、SSLv3、および TLSv1.0 を明示的に無効化することを推奨しています。
変更を反映するためにサーバーをリロードします。
reload
2.2.6. アプリケーションの双方向 SSL/TLS の設定 リンクのコピーリンクがクリップボードにコピーされました!
アプリケーションの双方向 SSL/TLS の設定は 管理インターフェイスの双方向 SSL/TLS の設定 で概説されているのと同じ手順の多くに従います。アプリケーションに双方向 SSL/TLS を設定するには、次の手順を実行する必要があります。
- クライアントとサーバー両方のストアを生成します。
- クライアントとサーバー両方の証明書をエクスポートします。
- opposing トラストストアに証明書をインポートします。
-
サーバーのキーストアおよびトラストストアを使用するサーバーで、
CertificateRealmなどのセキュリティーレルムを定義します。 -
セキュリティーレルムを使用し、クライアント検証が必須となるように
undertowサブシステムを更新します。
最初の 4 つの手順については 管理インターフェイスの双方向 SSL/TLS の設定 で説明されています。
新しいセキュリティーレルムが追加されても、サーバーがリロードされていない場合は、サーバーをリロードしてから次の手順を実行する必要があります。
Undertow サブシステムの調整
キーストア、証明書、トラストストア、およびセキュリティーレルムが作成され、設定されると、undertow サブシステムに HTTPS リスナーを追加し、作成したセキュリティーレルムを使用する必要があり、クライアントの検証が必須になります。
/subsystem=undertow/server=default-server/https-listener=https:add( \
socket-binding=https, security-realm=CertificateRealm, verify-client=REQUIRED)
アプリケーションに双方向 SSL/TLS を有効化した JBoss EAP インスタンスに接続するクライアントは、クライアント証明書またはキーストアにアクセスできなければなりません。つまり、クライアントのキーストアに証明書が含まれるクライアントキーストアが必要になります。クライアントがブラウザーを使用して JBoss EAP インスタンスに接続している場合は、その証明書またはキーストアをブラウザーの証明書マネージャーにインポートする必要があります。
アプリケーションでの双方向 SSL/TLS に加えて、アプリケーションで証明書ベースの認証を使用する方法の詳細は、JBoss EAP の アイデンティティー Management の設定方法 の 証明書ベースの認証を使用するためのセキュリティードメインの設定 を参照してください。
2.2.7. HTTPS リスナーのリファレンス リンクのコピーリンクがクリップボードにコピーされました!
HTTPS リスナーで使用できる属性の完全なリストについては、JBoss EAP 設定ガイド の Undertow サブシステム属性 を参照してください。
2.2.7.1. 暗号化スイートについて リンクのコピーリンクがクリップボードにコピーされました!
許可される一連の暗号を設定できます。JSSE 構文については、コンマ区切りのリストが必要です。OpenSSL 構文については、コロン区切のリストが必要です。1 つのみの構文を使うようにしてください。デフォルトは JVM のデフォルトです。
強度の低い暗号を使用すると、セキュリティーが重大なリスクにさらされることになります。暗号スイートに関する NIST の推奨事項は、http://www.nist.gov/manuscript-publication-search.cfm?pub_id=915295 を参照してください。
使用可能な OpenSSL 暗号のリストは、https://www.openssl.org/docs/manmaster/apps/ciphers.html#CIPHER-STRINGS を参照してください。以下はサポート対象外であることに注意してください。
- @SECLEVEL
- SUITEB128
- SUITEB128ONLY
- SUITEB192
標準の JSSE 暗号のリストについては、http://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html#Cipher を参照してください。
有効な暗号スイートのリストを更新するには、undertow サブシステムの HTTPS リスナーの enabled-cipher-suites 属性を使用します。
CLI の例
/subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=enabled-cipher-suites,value="TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA")
この例では、2 つの暗号だけが一覧表示されますが、実際の例はより多くの暗号が使用されます。
2.2.8. Red Hat Enterprise Linux 6 での SSL/TLS の FIPS 140-2 暗号の有効化 リンクのコピーリンクがクリップボードにコピーされました!
Undertow は、SSL/TLS に FIPS 140-2 準拠の暗号を使用するように設定できます。この設定例の範囲は、FIPS モードで Mozilla NSS ライブラリーを使用する Red Hat Enterprise Linux 6 に限定されます。
Red Hat Enterprise Linux 6 は、FIPS140-2 に準拠するように設定済みである。詳細は、https://access.redhat.com/knowledge/solutions/137833 を参照してください。
TLS 1.2 プロトコルは、FIPS モードで実行されている場合、Oracle/OpenJDK および JBoss EAP ではサポートされていないため、NoSuchAlgorithmException が発生する可能性があります。この問題の詳細は、こちら を参照してください。
SSL/TLS の FIPS 140-2 準拠暗号化が有効になっている環境で jboss-cli.sh を実行すると、FIPS mode: only SunJSSE TrustManagers may be used というエラーが表示されます。jboss-cli.sh ファイルの javax.net.ssl.keyStore および javax.net.ssl.trustStore システムプロパティーを更新することで、この問題を回避できます。
JAVA_OPTS="$JAVA_OPTS -Djavax.net.ssl.trustStore=NONE -Djavax.net.ssl.trustStoreType=PKCS11"
JAVA_OPTS="$JAVA_OPTS -Djavax.net.ssl.keyStore=NONE -Djavax.net.ssl.keyStoreType=PKCS11 -Djavax.net.ssl.keyStorePassword=imapassword"
SSL/TLS に FIPS 140-2 に準拠する暗号を使用するように Undertow を設定するには、以下を行う必要があります。
- NSS データベースの設定
- Undertow の設定
2.2.8.1. NSS データベースの設定 リンクのコピーリンクがクリップボードにコピーされました!
NSS データベースを格納するために、適切なユーザーが所有するディレクトリーを作成します。
NSS データベースディレクトリーを作成するコマンドの例
$ mkdir -p /usr/share/jboss-as/nssdb $ chown jboss /usr/share/jboss-as/nssdb $ modutil -create -dbdir /usr/share/jboss-as/nssdb注記jboss ユーザーはあくまで例です。実際には、JBoss EAP の実行に使用するオペレーティングシステム上のユーザーに置き換える必要があります。
NSS 設定ファイル (
/usr/share/jboss-as/nss_pkcsll_fips.cfg) を作成します。以下を指定する必要があります。
- 名前
- NSS ライブラリーが置かれているディレクトリー
以前のステップで NSS データベースが作成されたディレクトリー
例
nss_pkcsll_fips.cfgname = nss-fips nssLibraryDirectory=/usr/lib64 nssSecmodDirectory=/usr/share/jboss-as/nssdb nssDbMode = readOnly nssModule = fips注記64 ビットバージョンの Red Hat Enterprise Linux 6 使用していない場合は、
nssLibraryDirectoryを/usr/lib64ではなく、/usr/libに置き換えます。
$JAVA_HOME/jre/lib/security/java.security設定ファイルを編集します。次の行を
$JAVA_HOME/jre/lib/security/java.securityに追加します。例
java.securitysecurity.provider.1=sun.security.pkcs11.SunPKCS11 /usr/share/jboss-as/nss_pkcsll_fips.cfg注記上記の行で指定されている
nss_pkcsll_fips.cfg設定ファイルは、前のステップで作成したファイルです。$JAVA_HOME/jre/lib/security/java.securityの次のリンクも更新する必要があります。security.provider.5=com.sun.net.ssl.internal.ssl.Providerto
security.provider.5=com.sun.net.ssl.internal.ssl.Provider SunPKCS11-nss-fips重要このファイルの他の
security.provider.X行 (例:security.provider.2) には、このプロバイダーに優先順位が指定されるように X の値を増やす必要があります。前の手順で作成した NSS データベースディレクトリーで
modutilコマンドを実行して、FIPS モードを有効化します。modutil -fips true -dbdir /usr/share/jboss-as/nssdb注記この時点では、NSS 共有オブジェクトの一部に対するライブラリー署名の再生成を求めるセキュリティーライブラリーエラーが発生することがあります。
FIPS トークンにパスワードを設定します。
トークンの名前は、NSS FIPS 140-2 Certificate DB である 必要があります 。
modutil -changepw "NSS FIPS 140-2 Certificate DB" -dbdir /usr/share/jboss-as/nssdb重要FIPS トークンに使用されるパスワードは、FIPS に準拠したパスワードである必要があります。パスワードの強度が不十分な場合は、以下のようなエラーが発生することがあります。ERROR: Unable to change password on token "NSS FIPS 140-2 Certificate DB"
NSS ツールを使用して証明書を作成します。
コマンド例
certutil -S -k rsa -n undertow -t "u,u,u" -x -s "CN=localhost, OU=MYOU, O=MYORG, L=MYCITY, ST=MYSTATE, C=MY" -d /usr/share/jboss-as/nssdb
2.2.8.2. Undertow の設定 リンクのコピーリンクがクリップボードにコピーされました!
SSL/TLS の FIPS 140-2 準拠暗号化のセットアップを完了するには、次の手順を実行します。
SSL/TLS を使用するように Undertow を設定します。
注記以下のコマンドはバッチモードで実行する必要があります。あるいは、ssl サーバーアイデンティティーを追加した後にサーバーをリロードする必要があります。以下の例はバッチモードを使用しています。
batch /core-service=management/security-realm=HTTPSRealm:add /core-service=management/security-realm=HTTPSRealm/server-identity=ssl:add(keystore-provider=PKCS11, keystore-password="strongP@ssword1") /subsystem=undertow/server=default-server/https-listener=https:add(socket-binding=https, security-realm=HTTPSRealm, enabled-protocols="TLSv1.1") run-batchUndertow を SSL / TLS に設定する基本的な詳細は、Setting up an SSL/TLS for Applications で説明されています。
Undertow によって使用される暗号スイートを設定します。
SSL/TLS を設定した後は、特定のセットの暗号スイートを有効にするために https リスナーとセキュリティーレルムを設定する必要があります。
必要な暗号スイート
SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_anon_WITH_AES_128_CBC_SHA, TLS_ECDH_anon_WITH_AES_256_CBC_SHAhttps リスナーに暗号スイートを有効にする基本的な方法は、暗号スイートについて で説明されています。https リスナーで暗号化スイートを有効にするには、以下を行います。
HTTPS リスナーでの暗号スイートを有効にするコマンドの例
/subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=enabled-cipher-suites,value="SSL_RSA_WITH_3DES_EDE_CBC_SHA,SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_anon_WITH_AES_128_CBC_SHA,TLS_ECDH_anon_WITH_AES_256_CBC_SHA")セキュリティーレルムで暗号スイートを有効にします。
セキュリティーレルムで暗号スイートを有効化するコマンドの例
/core-service=management/security-realm=HTTPSRealm/server-identity=ssl:write-attribute(name=enabled-cipher-suites, value=[SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_anon_WITH_AES_128_CBC_SHA, TLS_ECDH_anon_WITH_AES_256_CBC_SHA])以下のコマンドを実行することで、JVM が PKCS11 キーストアから秘密鍵を読み取りできることを確認します。
keytool -list -storetype pkcs11
2.2.9. IBM JDK における FIPS 140-2 準拠暗号化 リンクのコピーリンクがクリップボードにコピーされました!
IBM JDK では、マルチプラットフォーム用の IBM JCE (Java Cryptographic Extension) IBMJCEFIPS プロバイダーと IBM JSSE (Java Secure Sockets Extension) FIPS 140-2 暗号化モジュール (IBMJSSE2) が FIPS 140-2 準拠の暗号化を提供します。
IBMJCEFIPS プロバイダーの詳細は、IBM JCEFIPS の IBM ドキュメント および NIST IBMJCEFIPS – セキュリティーポリシー を参照してください。IBMJSSE2 の詳細は、ここ を参照してください。
2.2.9.1. キーストレージ リンクのコピーリンクがクリップボードにコピーされました!
IBM JCE はキーストアを提供しません。このキーはコンピューターに保存され、その物理境界は残しません。このキーがコンピューター間で移動している場合は暗号化する必要があります。
FIPS 準拠モードで keytool を実行するには、次のように各コマンドで -providerClass オプションを使用します。
keytool -list -storetype JCEKS -keystore mystore.jck -storepass mystorepass -providerClass com.ibm.crypto.fips.provider.IBMJCEFIPS
2.2.9.2. FIPS プロバイダー情報の確認 リンクのコピーリンクがクリップボードにコピーされました!
サーバーによって使用される IBMJCEFIPS に関する情報を調べるには、-Djavax.net.debug=true をstandalone.conf または domain.conf に追加してデバッグレベルのロギングを有効にします。FIPS プロバイダーに関する情報は、server.log に記録されます。次に例を示します。
04:22:45,685 INFO [stdout] (http-/127.0.0.1:8443-1) JsseJCE: Using MessageDigest SHA from provider IBMJCEFIPS version 1.7
04:22:45,689 INFO [stdout] (http-/127.0.0.1:8443-1) DHCrypt: DH KeyPairGenerator from provider from init IBMJCEFIPS version 1.7
04:22:45,754 INFO [stdout] (http-/127.0.0.1:8443-1) JsseJCE: Using KeyFactory DiffieHellman from provider IBMJCEFIPS version 1.7
04:22:45,754 INFO [stdout] (http-/127.0.0.1:8443-1) JsseJCE: Using KeyAgreement DiffieHellman from provider IBMJCEFIPS version 1.7
04:22:45,754 INFO [stdout] (http-/127.0.0.1:8443-1) DHCrypt: DH KeyAgreement from provider IBMJCEFIPS version 1.7
04:22:45,754 INFO [stdout] (http-/127.0.0.1:8443-1) DHCrypt: DH KeyAgreement from provider from initIBMJCEFIPS version 1.7
2.2.10. JVM が FIPS モードで実行されているときにマネージドドメインを起動する リンクのコピーリンクがクリップボードにコピーされました!
管理対象ドメインがあり、FIPS が設定されており、必要な証明書がすべて設定されていることを前提としています。これには、ドメインコントローラーの証明書を各コントローラーのトラストストアにインポートすることが含まれます。管理対象ドメインの設定の詳細は、JBoss EAP 設定ガイドの ドメイン管理 を参照してください。FIPS の設定の詳細は、Red Hat Enterprise Linux 6 での SSL/TLS の FIPS 140-2 暗号化の有効化 を参照してください。
通信に SSL/TLS を使用するには、各ホストコントローラーとマスタードメインコントローラーを更新する必要があります。
Red Hat では、影響するすべてのパッケージで TLSv1.1 を利用するために SSLv2、SSLv3、および TLSv1.0 を明示的に無効化することを推奨しています。
マスタードメインコントローラー上に SSL/TLS セキュリティーレルムを作成します。
NSS データベースを PKCS11 プロバイダーとして使用するように設定されたマスタードメインコントローラー上に SSL/TLS セキュリティーレルムを作成する必要があります。
セキュリティーレルムの例
<security-realm name="HTTPSRealm"> <server-identities> <ssl> <engine enabled-protocols="TLSv1.1"/> <keystore provider="PKCS11" keystore-password="strongP@ssword1"/> </ssl> </server-identities> <authentication> <local default-user="\$local"/> <properties path="https-users.properties" relative-to="jboss.domain.config.dir"/> </authentication> </security-realm>各ホストコントローラーに SSL/TLS セキュリティーレルムを作成します。
認証用に SSL/TLS トラストストアを使用してセキュリティーレルムを作成する必要があります。
セキュリティーレルムの例
<security-realm name="HTTPSRealm"> <authentication> <truststore provider="PKCS11" keystore-password="strongP@ssword1"/> </authentication> </security-realm>注記各ホストでこのプロセスを繰り返す必要があります。
マスタードメインコントローラー上のネイティブインターフェイスを保護します。
マスタードメインコントローラーのネイティブインターフェイスが、作成したばかりのセキュリティーレルムで保護されていることを確認する必要があります。
ネイティブインターフェイスの例
<management-interfaces> ... <native-interface security-realm="HTTPSRealm"> <socket interface="management" port="${jboss.management.native.port:9999}"/> </native-interface> </management-interfaces>各ホストコントローラーで SSL/TLS レルムを使用して、マスタードメインコントローラーに接続します。
マスタードメインコントローラーへの接続に使用されるセキュリティー領域を更新する必要があります。この変更は、サーバーが動作していないときにホストコントローラーの設定ファイル (
host.xml、host-slave.xmlなど) で直接行う必要があります。ホストコントローラー設定ファイルの例
<domain-controller> <remote security-realm="HTTPSRealm"> <discovery-options> <static-discovery name="primary" protocol="${jboss.domain.master.protocol:remote}" host="${jboss.domain.master.address}" port="${jboss.domain.master.port:9999}"/> </discovery-options> </remote> </domain-controller>各サーバーがホストコントローラーに接続する方法を更新します。
また、各サーバーがホストコントローラーに接続する方法も更新する必要があります。
サーバー設定の例
<server name="my-server" group="my-server-group"> <ssl ssl-protocol="TLS" trust-manager-algorithm="SunX509" truststore-type="PKCS11" truststore-password="strongP@ssword1"/> </server>マネージドドメインで双方向 SSL/TLS を設定します。
双方向 SSL/TLS を有効にするには、マスタードメインコントローラーの SSL/TLS セキュリティーレルムにトラストストア認証メソッドを追加します。以下の管理 CLI コマンドを実行します。
/host=master/core-service=management/security-realm=HTTPSRealm/authentication=truststore:add(keystore-provider="PKCS11",keystore-password="strongP@ssword1") reload --host=masterSSL サーバーアイデンティティーを持つように各ホストコントローラーのセキュリティーレルムを更新する必要もあります。以下の管理 CLI コマンドを実行します。
/host=host1/core-service=management/security-realm=HTTPSRealm/server-identity=ssl:add(keystore-provider=PKCS11, keystore-password="strongP@ssword1",enabled-protocols=["TLSv1.1"]) reload --host=host1重要また、各ホストの証明書がドメインコントローラーのトラストストアにインポートされることを確認する必要があります。
2.2.11. JMX へのリモートアクセスの無効化 リンクのコピーリンクがクリップボードにコピーされました!
jmx サブシステムへのリモートアクセスにより、JDK とアプリケーション管理操作がリモートでトリガーできます。JBoss EAP で JMX へのリモートアクセスを無効にするには、jmx サブシステムのリモーティングコネクターを削除します。
リモーティングコネクターの削除
/subsystem=jmx/remoting-connector=jmx/:remove
JMX の詳細は、Red Hat JBoss Enterprise Application Platform セキュリティーアーキテクチャーガイドの JMX セクション を参照してください。
2.2.12. 管理インターフェイスのセキュア化での JAAS の使用 リンクのコピーリンクがクリップボードにコピーされました!
JAAS は、JBoss EAP がセキュリティーを管理するために使用する宣言型セキュリティー API です。JAAS および宣言型セキュリティーに関する詳細と背景については、Red Hat JBoss Enterprise Application Platform セキュリティーアーキテクチャーガイドの宣言型セキュリティーと JAAS セクション を参照してください。
JBoss EAP インスタンスが ADMIN_ONLY モードで実行されるように設定されていると、JAAS を使用した管理インターフェイスのセキュア化はサポートされません。ADMIN_ONLY モードの詳細は、JBoss EAP 設定ガイド の ADMIN_ONLY モードでの JBoss EAP の実行 セクションを参照してください。
JAAS を使用して管理インターフェイスに認証するには、以下の手順を実行する必要があります。
セキュリティードメインを作成します。
この例では、セキュリティードメインが UserRoles ログインモジュールで作成されますが、その他のログインモジュールも使用できます。
/subsystem=security/security-domain=UsersLMDomain:add(cache-type=default) /subsystem=security/security-domain=UsersLMDomain/authentication=classic:add /subsystem=security/security-domain=UsersLMDomain/authentication=classic/login-module=UsersRoles:add(code=UsersRoles, flag=required,module-options=[("usersProperties"=>"users.properties"),("rolesProperties"=>"roles.properties")])JAAS 認証でセキュリティーレルムを作成します。
/core-service=management/security-realm=SecurityDomainAuthnRealm:add /core-service=management/security-realm=SecurityDomainAuthnRealm/authentication=jaas:add(name=UsersLMDomain)新しいセキュリティーレルムを使用するように
http-interface管理インターフェイスを更新します。/core-service=management/management-interface=http-interface/:write-attribute(name=security-realm,value=SecurityDomainAuthnRealm)オプション: グループメンバーシップを割り当てます。
属性
assign-groupsは、セキュリティーレルム内のグループ割り当てに、セキュリティードメインからロードされたユーザーメンバーシップ情報を使用するかどうかを決定します。trueに設定すると、グループ割り当ては、RBAC (Role-Based Access Control) に使用されます。/core-service=management/security-realm=SecurityDomainAuthnRealm/authentication=jaas:write-attribute(name=assign-groups,value=true)
2.2.13. サイレント認証 リンクのコピーリンクがクリップボードにコピーされました!
JBoss EAP のデフォルトインストールには、ローカル管理 CLI ユーザーのサイレント認証メソッドが含まれています。これにより、ローカルユーザーは、ユーザー名またはパスワード認証なしで管理 CLI にアクセスできます。この機能は便宜上、ローカルユーザーが認証を必要とせずに管理 CLI スクリプトを実行できるようにするために有効になっています。通常、ユーザーがローカル設定にアクセスできれば、独自のユーザー詳細を追加することもできるため便利な機能と見なされます。
ローカルユーザーのサイレント認証の利便性は、セキュリティー管理が長い場合に無効にすることができます。これは、設定ファイルの security-realm セクション内の local 要素を削除することで実現できます。これは、スタンドアロンインスタンスとドメインの両方に適用されます。
local 要素の削除は、JBoss EAP インスタンスの影響と、その設定を完全に理解している場合にのみ行う必要があります。
レルムからサイレント認証を削除するには:
/core-service=management/security-realm=REALM_NAME/authentication=local:remove
2.2.14. Undertow 応答ヘッダーの削除 リンクのコピーリンクがクリップボードにコピーされました!
デフォルトの JBoss EAP undertow サブシステムには、default-host によって各 HTTP 応答に追加される 2 つの応答ヘッダーが含まれています。
-
Server。JBoss-EAP/7に設定されています -
X-Powered-By。Undertow/1に設定されています
これらは開発やデバッグの目的には役立ちますが、使用中のサーバーに関する情報を公開しない場合は、これらのヘッダーを削除することを検討してください。
次の管理 CLI コマンドを使用して、これらの応答ヘッダーを default-host から削除します。
/subsystem=undertow/server=default-server/host=default-host/filter-ref=server-header:remove
/subsystem=undertow/server=default-server/host=default-host/filter-ref=x-powered-by-header:remove
reload