検索

2.2. 管理インターフェイスのセキュア化の方法

download PDF

ここでは、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 を有効にする手順を実行している間は、明示的に指示されない限り、設定を再ロードしないでください。これを実行すると、管理インターフェイスがロックされる可能性があります。

  1. キーストアを作成して、管理インターフェイスのセキュリティーを確保します。

    注記

    このキーストアは、管理インターフェイスが JCEKS 形式のキーストアと互換性がないため、JKS 形式である必要があります。

    以下を実行してキーストアを生成します。パラメーターの例の値 (例: aliaskeypasskeystorestorepassdname) を環境に適切な値に置き換えます。

    注記

    パラメーターの 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

  2. 管理インターフェイスが HTTPS にバインドされていることを確認します。

    1. スタンドアロンサーバーを実行しています。

      管理インターフェイスが 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)
    2. マネージドドメインの起動

      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)
  3. オプション: カスタム 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}"
        }
    }

  4. 新しいセキュリティーレルムを作成します。この例では、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
    重要

    プロパティーファイルを使用してユーザー名とパスワードを保存するようにセキュリティーレルムを設定する場合、各レリムは別のレルムと共有されていない個別のプロパティーを使用することが推奨されます。

  5. 新しいセキュリティーレルムを使用するように管理インターフェイスを設定します。

    /core-service=management/management-interface=http-interface:write-attribute(name=security-realm,value=ManagementRealmHTTPS)
  6. キーストアを使用するように管理インターフェイスを設定します。

    以下の 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 が再接続できるようにします。

  7. 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 を明示的に無効化することを推奨しています。

  1. キーストアを生成します。

    $ 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
  2. 証明書をエクスポートします。

    $ 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
  3. 対立するトラストストアにインポートします。

    $ 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.cer
  4. CertificateRealm を定義します。

    サーバー (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)
  5. http-interfacesecurity-realm を新しい CertificateRealm に変更します。

    /core-service=management/management-interface=http-interface:write-attribute(name=security-realm,value=CertificateRealm)
  6. 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 ガイド を参照してください。

  1. 最初に 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 を明示的に無効化することを推奨しています。

  2. 変更を反映するためにサーバーをリロードします。

    reload

2.2.6. アプリケーションの双方向 SSL/TLS の設定

アプリケーションの双方向 SSL/TLS の設定は 管理インターフェイスの双方向 SSL/TLS の設定 で概説されているのと同じ手順の多くに従います。アプリケーションに双方向 SSL/TLS を設定するには、次の手順を実行する必要があります。

  1. クライアントとサーバー両方のストアを生成します。
  2. クライアントとサーバー両方の証明書をエクスポートします。
  3. opposing トラストストアに証明書をインポートします。
  4. サーバーのキーストアおよびトラストストアを使用するサーバーで、CertificateRealm などのセキュリティーレルムを定義します。
  5. セキュリティーレルムを使用し、クライアント検証が必須となるように 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 データベースの設定

  1. 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 の実行に使用するオペレーティングシステム上のユーザーに置き換える必要があります。

  2. NSS 設定ファイル (/usr/share/jboss-as/nss_pkcsll_fips.cfg) を作成します。

    以下を指定する必要があります。

    • 名前
    • NSS ライブラリーが置かれているディレクトリー
    • 以前のステップで NSS データベースが作成されたディレクトリー

      nss_pkcsll_fips.cfg

      name = 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 に置き換えます。

  3. $JAVA_HOME/jre/lib/security/java.security 設定ファイルを編集します。

    次の行を $JAVA_HOME/jre/lib/security/java.security に追加します。

    java.security

    security.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.Provider

    to

    security.provider.5=com.sun.net.ssl.internal.ssl.Provider  SunPKCS11-nss-fips
    重要

    このファイルの他の security.provider.X 行 (例: security.provider.2) には、このプロバイダーに優先順位が指定されるように X の値を増やす必要があります。

  4. 前の手順で作成した NSS データベースディレクトリーで modutil コマンドを実行して、FIPS モードを有効化します。

    modutil -fips true -dbdir /usr/share/jboss-as/nssdb
    注記

    この時点では、NSS 共有オブジェクトの一部に対するライブラリー署名の再生成を求めるセキュリティーライブラリーエラーが発生することがあります。

  5. 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"

  6. 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 準拠暗号化のセットアップを完了するには、次の手順を実行します。

  1. 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-batch

    Undertow を SSL / TLS に設定する基本的な詳細は、Setting up an SSL/TLS for Applications で説明されています。

  2. 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_SHA

    https リスナーに暗号スイートを有効にする基本的な方法は、暗号スイートについて で説明されています。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")

  3. セキュリティーレルムで暗号スイートを有効にします。

    セキュリティーレルムで暗号スイートを有効化するコマンドの例

    /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])

  4. 以下のコマンドを実行することで、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 を明示的に無効化することを推奨しています。

  1. マスタードメインコントローラー上に 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>

  2. 各ホストコントローラーに SSL/TLS セキュリティーレルムを作成します。

    認証用に SSL/TLS トラストストアを使用してセキュリティーレルムを作成する必要があります。

    セキュリティーレルムの例

    <security-realm name="HTTPSRealm">
      <authentication>
        <truststore provider="PKCS11" keystore-password="strongP@ssword1"/>
      </authentication>
    </security-realm>

    注記

    各ホストでこのプロセスを繰り返す必要があります。

  3. マスタードメインコントローラー上のネイティブインターフェイスを保護します。

    マスタードメインコントローラーのネイティブインターフェイスが、作成したばかりのセキュリティーレルムで保護されていることを確認する必要があります。

    ネイティブインターフェイスの例

    <management-interfaces>
      ...
      <native-interface security-realm="HTTPSRealm">
        <socket interface="management" port="${jboss.management.native.port:9999}"/>
       </native-interface>
    </management-interfaces>

  4. 各ホストコントローラーで SSL/TLS レルムを使用して、マスタードメインコントローラーに接続します。

    マスタードメインコントローラーへの接続に使用されるセキュリティー領域を更新する必要があります。この変更は、サーバーが動作していないときにホストコントローラーの設定ファイル (host.xmlhost-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>

  5. 各サーバーがホストコントローラーに接続する方法を更新します。

    また、各サーバーがホストコントローラーに接続する方法も更新する必要があります。

    サーバー設定の例

    <server name="my-server" group="my-server-group">
      <ssl ssl-protocol="TLS" trust-manager-algorithm="SunX509" truststore-type="PKCS11" truststore-password="strongP@ssword1"/>
    </server>

  6. マネージドドメインで双方向 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=master

    SSL サーバーアイデンティティーを持つように各ホストコントローラーのセキュリティーレルムを更新する必要もあります。以下の管理 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 を使用して管理インターフェイスに認証するには、以下の手順を実行する必要があります。

  1. セキュリティードメインを作成します。

    この例では、セキュリティードメインが 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")])
  2. JAAS 認証でセキュリティーレルムを作成します。

    /core-service=management/security-realm=SecurityDomainAuthnRealm:add
    
    /core-service=management/security-realm=SecurityDomainAuthnRealm/authentication=jaas:add(name=UsersLMDomain)
  3. 新しいセキュリティーレルムを使用するように http-interface 管理インターフェイスを更新します。

    /core-service=management/management-interface=http-interface/:write-attribute(name=security-realm,value=SecurityDomainAuthnRealm)
  4. オプション: グループメンバーシップを割り当てます。

    属性 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 つの応答ヘッダーが含まれています。

  • ServerJBoss-EAP/7 に設定されています
  • X-Powered-ByUndertow/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
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.