2.7. コア管理認証
コア管理認証は、ManagementRealm
を使用してコア管理機能向けに管理インターフェイス (HTTP およびネイティブ) をセキュア化します。コア管理認証はコア管理に内蔵され、デフォルトではコアサービスとして有効化および設定されます。管理インターフェイスのセキュア化のみを行います。
2.7.1. セキュリティーレルム
セキュリティーレルムは、ユーザー、パスワード、およびグループメンバーシップ情報のアイデンティティーストアで、EJB、web アプリケーション、および管理インターフェイスのユーザーを認証するときに使用されます。デフォルトでは、JBoss EAP には事前設定された ManagementRealm
および ApplicationRealm
の 2 つのセキュリティーレルムが含まれています。これら両方のセキュリティーレルムはファイルシステムを使用して、ユーザーとパスワード間およびユーザーとグループメンバーシップ情報間のマッピングを保存します。両方のセキュリティーレルムはデフォルトでダイジェスト認証を使用します。
ダイジェストは認証のメカニズムで、プロパティーファイルをマッピングするユーザー名およびパスワードに格納された情報など、さまざまな情報で設定される 1 度限りの一方向ハッシュを使用してユーザーを認証します。これにより、JBoss EAP はネットワーク上でプレーンテキストのパスワードを送信せずに認証を行うことができます。
JBoss EAP インストールには、管理者が両方のレルムにユーザーを追加できるようにするスクリプトが含まれています。ユーザーがこのスクリプトで追加されると、ユーザー名とハッシュ化されたパスワードは対応するユーザー名とパスワードのプロパティーファイルに格納されます。ユーザーが認証を試みると、JBoss EAP は nonce という 1 度限りの番号をクライアントに送信します。クライアントはユーザー名、パスワード、nonce、およびその他のフィールドを使用して一方向ハッシュを生成し、ユーザー名、nonce、および一方向ハッシュを JBoss EAP に送信します。JBoss EAP はユーザーのハッシュ化前のパスワードを検索し、提供されたユーザー名、nonce、およびその他のフィールドとともに使用して別の一方向ハッシュを同様に生成します。正しいパスワードなど、すべて同じ情報が両側で使用された場合、ハッシュが一致してユーザーが認証されます。
セキュリティーレルムはデフォルトでダイジェスト認証を使用しますが、他の認証方法を使用するように再設定することもできます。管理インターフェイスは起動時に、ManagementRealm
に設定された認証方法を基にして、有効化される認証方法を判断します。
セキュリティーレルムは承認には全く関与しません。しかし、後で承認の決定に使用されるユーザーのグループメンバーシップ情報をロードするよう設定することが可能です。ユーザーの認証後、ユーザー名を基にグループメンバーシップ情報をロードする 2 つ目の手順が発生します。
デフォルトでは、ManagementRealm
は管理インターフェイスの認証および承認中に使用されます。ApplicationRealm
は、web アプリケーションと EJB がユーザーの認証および承認時に使用できるデフォルトのレルムです。
2.7.2. デフォルトのセキュリティー
デフォルトでは、コア管理認証は HTTP と ネイティブの各管理インターフェイスを、ローカルクライアントとリモートクライアントの 2 つの形式でセキュア化します。これら両方は、デフォルトでは ManagementRealm
セキュリティーレルムを使用して設定されます。デフォルトの設定は変更可能で、設定を完全に置き換えることもできます。
初期状態の管理インターフェイスは、ロールを使用しない簡単なアクセス制御を使用するよう設定されています。デフォルトでは、簡単なアクセス制御を使用するとすべてのユーザーに SuperUser ロールと同じ権限が与えられ、原則的にアクセスが制限されません。
2.7.2.1. ネイティブインターフェイスによるローカルおよびリモートクライアント認証
ネイティブインターフェイス (管理 CLI) は、稼働中の JBoss EAP インスタンスと同じホストにてローカルで呼び出すことができ、別のマシンからリモートで呼び出すこともできます。ネイティブインターフェイスを使用して接続を確立しようとすると、JBoss EAP は local jboss user
やベーシック認証などの利用可能な SASL 認証のリストをクライアントに提示します。クライアントは希望する認証方法を選択し、JBoss EAP インスタンスとの認証を試行します。認証に失敗すると、他の方法で認証を再試行するか、接続の確立を停止します。ローカルクライアントは local jboss user
認証を使用することもできます。これは、ローカルファイルシステムにアクセスできるクライアントの機能を基にしたセキュリティーメカニズムです。これは、ログインしようとしているユーザーが JBoss EAP インスタンスと同じホスト上のローカルファイルシステムにアクセスできる権限があるかを検証します。
この認証は 4 つのステップで行われます。
-
クライアントは、
local jboss user
を使用した認証リクエストが含まれるメッセージをサーバーに送信します。 - サーバーは 1 度限りのトークンを生成して、固有のファイルに書き込み、そのファイルのフルパスが含まれるメッセージをクライアントに送信します。
- クライアントはトークンをファイルから読み取って、サーバーに送信し、ローカルでファイルシステムにアクセスできることを確認します。
- サーバーはトークンを検証し、ファイルを削除します。
このような認証は、ファイルシステムへ物理的にアクセスできれば他のセキュリティーメカニズムは不要であるという原理に基づいています。これは、ユーザーがローカルのファイルシステムにアクセスできれば、ユーザーは新規ユーザーを作成できる権限があり、そうでなければ他のセキュリティーメカニズムが阻止されるという論理です。ローカルユーザーはユーザー名やパスワードの認証なしで管理 CLI にアクセスできるため、サイレント認証と呼ばれることもあります。
この機能は利便性のためと、管理 CLI スクリプトを実行しているローカルユーザーの追加認証を不要にするために有効になっています。通常、ユーザーがローカル設定にアクセスできれば、独自のユーザー詳細を追加することもできるため便利な機能と見なされます。
リモートクライアントとして、別のサーバーや同じサーバーからネイティブインターフェイスにアクセスすることもできます。リモートクライアントとしてネイティブインターフェイスにアクセスする場合、local jboss user
を使用してクライアントを認証することはできず、ダイジェストなどの別の認証を使用するよう強制されます。local jboss user
を使用したローカルクライアントの認証に失敗すると、自動的にフォールバックされ、リモートクライアントとして別の認証方法の使用を試みます。
ネイティブインターフェイスではなく HTTP インターフェイスを使用して、別のサーバーや同じサーバーから管理 CLI を呼び出すことができます。CLI であるかに関わらず、すべての HTTP 接続はリモートとして考慮され、ローカルインターフェイスの認証では処理されません。
デフォルトでは、ネイティブインターフェイスは処理されず、すべての管理 CLI トラフィックは HTTP インターフェイスによって処理されます。JBoss EAP 7 は HTTP アップグレードをサポートします。HTTP アップグレードによって、クライアントは HTTP 上で最初の接続を確立できますが、その接続を別のプロトコルにアップグレードするため、リクエストを送信します。管理 CLI の場合、HTTP 上から HTTP インターフェイスへの最初のリクエストが作成されますが、接続はネイティブプロトコルにアップグレードされます。この接続は HTTP インターフェイス上で処理されますが、通信には HTTP ではなくネイティブプロトコルが使用されます。この代わりに、必要であればネイティブインターフェイスを有効化し、使用することができます。
2.7.2.2. HTTP インターフェイスによるローカルおよびリモートクライアント認証
HTTP インターフェイスは、稼働中の JBoss EAP インスタンスと同じホスト上のクライアントがローカルで呼び出すことができ、他のマシンからクライアントがリモードで呼び出すこともできます。ローカルおよびリモートクライアントは HTTP インターフェイスにアクセスできますが、HTTP インターフェイスにアクセスするすべてのクライアントはリモート接続として処理されます。
クライアントが HTTP 管理インターフェイスへの接続を試みると、JBoss EAP は HTTP 応答とともに状態コード 401 Unauthorized
と、ダイジェストや GSSAPI などのサポートされる認証をリストする一連のヘッダーを返信します。ダイジェストのヘッダーには、JBoss EAP によって生成された nonce も含まれます。クライアントはヘッダーを確認して使用する認証方法を選択し、適切な返答を送信します。クライアントがダイジェストを選択した場合、ユーザーにユーザー名とパスワードの入力を要求します。クライアントは、ユーザー名やパスワードなどの提供されたフィールド、nonce、その他の情報を使用し、一方向ハッシュを生成します。その後、一方向ハッシュ、ユーザー名、および nonce を返答として JBoss EAP に返信します。JBoss EAP はその情報を取得して別の一方向ハッシュを生成し、両方のハッシュを比較した結果を基にしてユーザーを認証します。
2.7.3. 高度なセキュリティー
保護方法に影響を及ぼす、管理インターフェイスや認証および承認方法のデフォルト設定を変更する方法は複数あります。
2.7.3.1. 管理インターフェイスの更新
JBoss EAP では、管理者は認証および承認方法を変更できるだけでなく、管理インターフェイス自体の設定も更新できます。これには複数のオプションがあります。
- 一方向 SSL/TLS を使用するための管理インターフェイスの設定
- 一方向 SSL/TLS のみを使用して通信を行うよう JBoss EAP 管理コンソールを設定すると、セキュリティーが強化されます。クライアントと管理コンソール間のネットワークトラフィックはすべて暗号化されるため、仲介者攻撃などのセキュリティー攻撃のリスクが軽減されます。JBoss EAP インスタンスの管理者は、そのインスタンスに対して非特権ユーザーよりも多くのパーミッションを持ち、一方向 SSL/TLS を使用するとそのインスタンスの整合性や可用性の保護に役立ちます。JBoss EAP で一方向 SSL/TLS を設定するとき、認証局が署名した証明書は信頼チェーンを提供するため、自己署名証明書よりも優先されます。自己署名証明書は許可されますが、推奨されません。
- 双方向 SSL/TLS の使用
- クライアント認証とも呼ばれる双方向 SSL/TLS 認証は、SSL/TLS 証明書を使用してクライアントとサーバーを認証します。そのため、サーバーの伝えるアイデンティティーだけでなく、クライアントの伝えるアイデンティティーも信頼できます。
- 新しいセキュリティーレルムの更新および作成
- デフォルトのセキュリティーレルムは更新可能で、新しいセキュリティーレルムに置き換えることもできます。
2.7.3.2. アウトバウンド接続の追加
セキュリティーレルムには、LDAP サーバーなどの外部インターフェイスに接続するものあります。アウトバウンド接続は、このような接続の確立方法を定義します。事前定義された接続タイプ ldap-connection
は、LDAP サーバーへ接続し、クレデンシャルを検証するために必要な属性と任意の属性をすべて設定します。
2.7.3.3. 管理インターフェイスへの RBAC の追加
デフォルトでは、RBAC システムは無効になっています。有効にするには、provider
属性を simple
から rbac
に変更します。これは、管理 CLI を使用して変更できます。稼働中のサーバーで RBAC を無効化または有効化した場合、サーバー設定をリロードして変更を反映する必要があります。
管理インターフェイスに対して RBAC が有効化された場合、アクセスできるリソースとリソースの属性で実行できる操作は、ユーザーに割り当てられたロールによって決定されます。Administrator
または SuperUser
ロールのユーザーのみがアクセス制御システムを閲覧および変更できます。
ユーザーとロールを適切に設定せずに RBAC を有効にすると、管理者が管理インターフェイスにログインできなくなることがあります。
管理コンソールでの RBAC の影響
管理コンソールでは、ユーザーに割り当てられたパーミッションに応じて一部の制御と表示が無効になっていることがあります。 このような制御と表示は灰色で表示されるか全く表示されません。
ユーザーがリソース属性の読み取り権限を持たない場合、その属性はコンソールでは空欄で表示されます。たとえば、ほとんどのロールはデータソースのユーザー名およびパスワードフィールドを読み取りできません。
ユーザーがリソース属性の読み取り権限を持ち、書き込み権限は持たない場合、その属性はリソースの編集フォームで無効化されます。ユーザーがリソースへの書き込み権限を持たない場合、そのリソースの編集ボタンは表示されません。
ユーザーがリソースまたは属性へのアクセス権を持たず、そのロールに対してアドレス指定できない場合、そのユーザーのコンソールには表示されません。この例の 1 つがアクセス制御システム自体で、デフォルトでは特定のロールのみが閲覧できます。
管理コンソールは、以下の一般的な RBAC タスクに対してもインターフェイスを提供します。
- 各ユーザーに割り当てられたロール、または各ユーザーから除外されたロールの表示および設定。
- 各グループに割り当てられたロール、または各グループから除外されたロールの表示および設定。
- ロールごとのグループおよびユーザーメンバーシップの表示。
- ロールごとのデフォルトメンバーシップの設定。
- スコープ指定されたロールの作成。
現時点では、管理コンソールでは制約を設定できません。
管理 CLI または管理 API での RBAC の影響
RBAC が有効である場合、管理 CLI や管理 API の動作が若干異なります。
読み取りできないリソースや属性は、結果からフィルター処理されます。ロールがフィルターされたリソースや属性をアドレス指定できる場合、結果の response-headers
セクションにある filtered-attributes
としてリストされます。ロールがリソースや属性をアドレス指定できない場合はリストされません。
アドレス指定できないリソースにアクセスしようとすると、Resource Not Found
エラーが発生します。
適切な書き込みまたは読み取り権限のないユーザーが、アドレス指定可能なリソースを読み取りまたは書き込みしようとすると、Permission Denied
エラーが返されます。
管理 CLI は、管理コンソールと同じ RBAC タスクをすべて実行でき、さらに以下のような追加のタスクも実行できます。
- RBAC の有効化および無効化。
- パーミッション組み合わせポリシーの変更
- アプリケーションリソースおよびリソース機密性制約の設定
JMX 管理 Bean での RBAC の影響
ロールベースのアクセス制御は、3 つの方法で JMX に適用されます。
-
JBoss EAP の管理 API は、JMX 管理 Bean として公開されます。JMX 管理 Bean は
core mbeans
と呼ばれ、これらの Bean へのアクセスは基礎の管理 API 自体と全く同じように制御およびフィルターされます。 -
jmx
サブシステムは、書き込み権限が機密である状態で設定されます。そのため、Administrator
およびSuperUser
ロールのユーザーのみがこのサブシステムを変更できます。Auditor
ロールのユーザーはこのサブシステムの設定を読み取ることができます。 -
デフォルトでは、デプロイされたアプリケーションやサービス、またはコアでない MBean によって登録された管理 Bean にはすべての管理ユーザーがアクセスできますが、
Maintainer
、Operator
、Administrator
およびSuperUser
ロールを持つユーザーのみが書き込みできます。
RBAC 認証
RBAC は、JBoss EAP と含まれる標準の認証プロバイダーと動作します。
- ユーザー名/パスワード
-
ローカルプロパティーファイルまたは LDAP を使用できる
ManagementRealm
の設定に応じて検証されるユーザーとパスワードの組み合わせを使用して、ユーザーは認証されます。 - クライアント証明書
- トラストストアはクライアント証明書の認証情報を提供します。
- local jboss user
-
サーバーが同じマシン上で稼働している場合、
jboss-cli
スクリプトはlocal jboss user
として自動的に認証を行います。デフォルトでは、local jboss user
はSuperUser
グループのメンバーです。
使用されるプロバイダーに関係なく、JBoss EAP はユーザーへロールを割り当てます。ManagementRealm
または LDAP サーバーで認証を行う場合、これらのシステムはユーザーグループ情報を提供できます。JBoss EAP はこの情報を使用してユーザーにロールを割り当てることもできます。
2.7.3.4. LDAP と管理インターフェイスの使用
JBoss EAP には、LDAP サーバーを web および EJB アプリケーションの認証および承認機関として使用できるようにする複数の認証および承認モジュールが含まれています。
LDAP サーバーを管理コンソール、管理 CLI、または管理 API の認証ソースとして使用するには、以下のタスクを実行する必要があります。
- LDAP サーバーへアウトバウンド接続を作成します。
- LDAP が有効なセキュリティーレルムを作成するか、既存のセキュリティーレルムが LDAP を使用するよう更新します。
- 管理インターフェイスの新しいセキュリティーレルムを参照します。
LDAP オーセンティケーターは、最初にリモートディレクトリーサーバーへ接続を確立します。その後、ユーザーが認証システムに渡すユーザー名を使用して検索を実行し、LDAP レコードの完全修飾識別名 (DN) を探します。ユーザーによって提供されるクレデンシャルおよびパスワードとしてユーザーの DN を使用して、LDAP サーバーへの新しい接続が確立されます。LDAP サーバーの認証に成功すると、DN が有効であることが検証されます。
LDAP が有効なセキュリティーレルムが作成されると、管理インターフェイスによる参照が可能になります。管理インターフェイスはセキュリティーレルムを認証に使用します。管理インターフェイスおよび管理 CLI で認証に双方向 SSL/TLS を使用すると、LDAP サーバーへのアウトバウンド接続を使用するよう JBoss EAP を設定することもできます。
2.7.3.5. JAAS および管理インターフェイス
JAAS を使用して管理インターフェイスをセキュア化できます。管理インターフェイスに JAAS を使用する場合、セキュリティーレルムがセキュリティードメインを使用するように設定する必要があります。これにより、コアサービスとサブシステムの依存関係が発生します。SSL/TLS は、管理インターフェイスのセキュア化に JAAS を使用する必要はありませんが、管理者は SSL/TLS を有効にして、セキュアでない状態で機密情報を誤送信しないようにすることが推奨されます。
JBoss EAP インスタンスが admin-only
モードで実行されている場合、JAAS を使用した管理インターフェイスのセキュア化はサポートされません。admin-only
モードの詳細は、JBoss EAP設定ガイド のJBoss EAP の管理専用モードでの実行を参照してください。