第2章 新機能および改良された機能
2.1. セキュリティー リンクのコピーリンクがクリップボードにコピーされました!
クレデンシャルストアの認証情報の自動更新のサポート
これで、store 属性および clear-text 属性の両方を指定する認証情報参照を設定する際に、Elytron は事前に定義されたクレデンシャルストアへの認証情報の追加および更新を自動化するようになりました。
今回の更新で、credential-reference から参照する前に、既存のクレデンシャルストアに認証情報を追加する必要がなくなりました。自動プロセスにより、異なるサブシステムで新しい認証情報を参照するために必要なステップの数が減ります。
Elytron の新しいロールマッパー regex-role-mapper
Elytron では、セキュリティーロールの正規表現 (regex) ベースのマッピングを定義する新しいロールマッパー regex-role-mapper を利用できるようになりました。
regex-role-mapper を使用して、ロールのリストを単純なロールに変換できます。例を以下に示します。
-
*-adminからadmin -
*-userからuser
regex-role-mapper では、独自のカスタムコンポーネントを実装してセキュリティーロールを変換する必要はありません。詳細は、regex-role-mapper 属性 を参照してください。
リモートクライアントの IP アドレスへのアクセス
source-address-role-decoder ロールデコーダーを elytron サブシステムに追加できるようになりました。このロールデコーダーを設定すると、権限付与に関する意思決定を行う場合に、リモートクライアントから追加情報を取得できます。
source-address-role-decoder は、リモートクライアントの IP アドレスを抽出し、pattern 属性または source-address 属性で指定された IP アドレスと一致することを確認します。リモートクライアントの IP アドレスがいずれかの属性で指定された IP アドレスと一致する場合、roles 属性はロールをユーザーに割り当てます。source-address-role-decoder を設定した場合は、セキュリティードメイン の role-decoder 属性で参照できます。
aggregate-role-decoder ロールデコーダー
aggregate-role-decoder は、2 つ以上のロールデコーダーで設定されます。指定された各ロールデコーダーがその操作を完了した後に、ロールを aggregate-role-decoder に追加します。
ユーザーのロールを割り当てるロールデコーダーを追加して、aggregate-role-decoder を使用して権限付与の意思決定を行うことができます。さらに aggregate-role-decoder は、各ロールデコーダーから返されるロールを集約する便利な方法を提供します。
JDK 11 での TLS プロトコルバージョン 1.3 の使用
Elytron では、JDK 11 で稼働している JBoss EAP に Transport Layer Security (TLS) プロトコルのバージョン 1.3 を使用できるようになりました。
TLS 1.3 は、デフォルトでは無効になっています。TLS 1.3 を有効にするには、elytron サブシステムの SSL コンテキストリソース定義で新しい cipher-suite-names 属性を設定します。
TLS 1.3 を JDK 11 で実行時のパフォーマンスは、TLS 1.2 と比較すると、低下する可能性があります。TLS 1.3 で非常に多くの要求が生じると、パフォーマンスが低下する可能性があります。新しい JDK バージョンにアップグレードさせることで、パフォーマンスを向上できます。実稼働環境で有効にする前に、TLS 1.3 を使用する設定で、パフォーマンス低下がないかをテストします。
TLS の OpenSSL プロバイダーを使用した TLS 1.3 プロトコルのサポートの有効化
JBoss EAP 7.4 には、Transport Layer Security (TLS) プロトコルのバージョン 1.3 のサポートが含まれています。TLS 用の OpenSSL プロバイダーでの TLS 1.3 プロトコルの使用はデフォルトで無効になっています。ssl-context 設定で providers 属性を設定するか、Elytron サブシステム設定で initial-providers 属性を使用して、グローバルに登録されたすべてのプロバイダーの前に OpenSSL プロバイダーを登録することにより、TLS の OpenSSL プロバイダーを有効にできます。
ssl-context 設定で cipher-suite-names 属性を設定して、TLS の OpenSSL プロバイダーで TLS 1.3 プロトコルのサポートを有効にできます。
TLS 1.3 を JDK 11 で実行時のパフォーマンスは、TLS 1.2 と比較すると、低下する可能性があります。TLS 1.3 で非常に多くの要求が生じると、パフォーマンスが低下する可能性があります。新しい JDK バージョンにアップグレードさせることで、パフォーマンスを向上できます。実稼働環境で有効にする前に、TLS 1.3 を使用する設定で、パフォーマンス低下がないかをテストします。
JDK 設定で TLS 1.1 プロトコルのサポートを再度有効にする
新しいバージョンの JDK は、デフォルトで Transport Layer Security (TLS) プロトコルのバージョン 1.1 を無効にすることができます。JBoss EAP 7.4 設定が連邦情報処理標準 (FIPS) に準拠する必要がある場合は、JDK 設定で TLS 1.1 プロトコルのサポートを再度有効にすることが必要になる場合があります。
JBoss EAP 7.4 と互換性のある TLS プロトコルの詳細は、Red Hat カスタマーポータルの Red Hat JBoss Enterprise Application Platform (EAP) 7 でサポートされる設定 を参照してください。
SSH 認証情報を使用したリモート Git SSH リポジトリーへの接続
JBoss EAP 7.4 では、SSH 認証情報を使用してリモート Git SSH リポジトリーに接続できます。このリポジトリーは、サーバー設定データ、プロパティーファイル、およびデプロイメントを管理できます。
SSH 認証情報を指定するには、elytron 設定ファイルを使用する必要があります。その後、スタンドアロンサーバーインスタンスを起動し、リモートの Git SSH リポジトリーでサーバー設定ファイル履歴を管理できます。
必要な場合は、以下のいずれかの方法で SSH 鍵を生成できます。
-
elytron-tool.shスクリプト - OpenSSH コマンドライン
リモート Git SSH リポジトリーへの接続に関する詳細は、リモート Git SSH リポジトリーの使用 を参照してください。
elytron サブシステムに追加された新しいプリンシパルトランスフォーマー
JBoss EAP 7.4 には、elytron サブシステムに新しいプリンシパルトランスフォーマー (case-principal-transformer) が追加されました。case-principal-transformer を使用して、プリンシパルのユーザー名を大文字または小文字のいずれかに変更できます。
自己署名証明書を自動生成する機能
JBoss EAP 7.4 では、自己署名証明書を自動的に生成できます。
自己署名証明書は、テスト環境にのみ使用してください。実稼働環境で自己署名証明書を使用しないでください。
この新機能を使用するには、undertow サブシステムで http-listener の設定を更新します。
batch
/subsystem=undertow/server=default-server/https-listener=https:undefine-attribute(name=security-realm)
/subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=ssl-context,value=applicationSSC)
run-batch
reload
設定の更新後に、キーストアファイルが存在しない場合には、JBoss EAP で HTTPS 要求を初めて受信すると、システムで自動的に自己署名証明書が生成されます。自己署名証明書が使用されると JBoss EAP は警告をログに記録します。
フェイルオーバーをサポートする複数のセキュリティーレルムの設定
JBoss EAP 7.4 では、フェイルオーバーのセキュリティーレルムを設定できます。セキュリティーレルムが利用できない場合には、JBoss EAP はフェイルオーバーレルムを使用します。以下のコードは、設定例です。
<failover-realm name="myfailoverrealm" delegate-realm="LdapRealm" failover-realm="LocalRealm" />
複数のセキュリティーレルム間での分散アイデンティティー
JBoss EAP 7.4 では、分散セキュリティーレルムを設定でき、アイデンティティーのあるレルムが見つかるまで、設定済みのレルムのリストを順次呼び出します。以下のコードは、設定例です。
<distributed-realm name="mymainrealm" realms="realm1 realm2 realm3" />
elytron サブシステムの HTTP 経由での外部認証情報へのアクセス
JBoss EAP 7.4 では、HTTP 認証を使用する場合に JBoss EAP は外部で確立されたクレデンシャルを基にしてユーザーを認証できます。
この機能を使用するには、ユーザーの認証に外部メカニズムを使用するようにセキュリティードメインを設定します。
RESTEasy クライアントでの Elytron クライアント認証設定の使用
JBoss EAP 7.4 リリースは、RESTEasy クライアントと Elytron クライアントを統合します。RESTEasy クライアントは、Elytron クライアント設定から認証情報、ベアラートークン、SSL 設定などの認証情報を使用します。
以下のように、RESTEasy クライアントが使用できる Elytron クライアント設定を指定できます。
wildfly-config.xmlファイルを Elytron クライアントに提供する。Elytron クライアントはwildfly-config.xmlまたはMETA-INF/wildfly-config.xmlのクラスパスを検索します。-
または、
wildfly.config.urlシステムプロパティーを使用してwildfly-config.xmlファイルのパスを指定することもできます。
-
または、
- Elytron クライアント API を使用して認証設定をプログラム的に指定します。
初期秘密鍵を指定するための秘密鍵クレデンシャルストア
secret-key-credential-store という名前の新しいタイプのクレデンシャルストアを使用して、最初の秘密鍵をアプリケーションサーバープロセスに提供できるようになりました。このクレデンシャルストアを使用すると、独自の初期シークレットを管理できるため、パスワードベースの暗号化よりも堅牢なセキュリティーが得られます。JBoss EAP への初期キーの指定は、セキュリティーで保護されたリソースを解除するための初期キーの JBoss EAP への指定 を参照してください。
さらに、秘密鍵を生成し、すべてのクレデンシャルストアに対して、以前に生成されたすべての秘密鍵をエクスポートおよびインポートできるようになりました。既存のクレデンシャルストアを使用して秘密鍵を保存し、管理操作を使用してそれらを維持することもできます。詳細は、JBoss EAP 管理 CLI を使用したクレデンシャルストアの操作 を参照してください。
セキュリティーの影響を受ける文字列を保護するための暗号化された式
暗号化された式を使用して、セキュリティーの影響を受ける文字列を管理モデルにセキュアに保存できるようになりました。Elytron は Advanced Encryption Standard (AES) 暗号化を使用してプレーンテキスト文字列を暗号化し、クレデンシャルストアに保存された SecretKey キーを使用してランタイム時に暗号化された式を動的に復号します。
暗号化された式は、elytron サブシステムで新しいリソース expression-encryption を使用して設定できます。create-expression 管理操作を使用して、暗号化された式を作成します。暗号化式については、Elytron の暗号化式 を参照してください。
パスワードの保存にはクレデンシャルストアを使用します。パスワードの vault は非推奨となり、今後のリリースで削除されます。
elytron-tool の更新
既存のクレデンシャルストアと新しいクレデンシャルストアの両方で elytron-tool を使用できます。credential-store コマンドを使用して秘密鍵を管理し、式で使用する暗号化されたトークンを生成します。