PKIユーザー認証

Elasticsearchを使用して、ユーザーを認証するために公開鍵基盤（PKI）証明書を使用するように構成できます。このシナリオでは、Elasticsearchに直接接続するクライアントは、X.509証明書を提示する必要があります。まず、証明書はElasticsearchのSSL/TLS層で認証のために受け入れられなければなりません。その後、PKIレルムによってさらに検証されることがオプションです。詳細は、Elasticsearchに直接接続するクライアントのPKI認証を参照してください。

また、Kibanaに対してPKI証明書を使用して認証することもできますが、これには追加の構成が必要です。Elasticsearch上で、この構成によりKibanaはSSL/TLS認証のプロキシとして機能し、クライアント証明書をElasticsearchに提出してPKIレルムによるさらなる検証を行います。詳細は、Kibanaに接続するクライアントのPKI認証を参照してください。

Elasticsearchに直接接続するクライアントのPKI認証

ElasticsearchでPKIを使用するには、PKIレルムを構成し、必要なネットワーク層（トランスポートまたはHTTP）でクライアント認証を有効にし、ユーザー証明書のSubjectフィールドからの識別名（DN）をロールにマッピングします。マッピングはロールマッピングファイルで作成するか、ロールマッピングAPIを使用します。

  • 1. pkiレルムのためのレルム構成をelasticsearch.ymlのxpack.security.authc.realms.pki名前空間の下に追加します。order属性を明示的に設定する必要があります。pkiレルムのために設定できるすべてのオプションについては、PKIレルム設定を参照してください。
    例えば、以下のスニペットは最も基本的なpkiレルム構成を示しています:

Yaml

  1. xpack:
  2.    security:
  3.    authc:
  4.    realms:
  5.    pki:
  6.    pki1:
  7.    order: 1

この構成では、ElasticsearchのSSL/TLS層によって信頼される任意の証明書が認証のために受け入れられます。ユーザー名は、エンドエンティティ証明書のSubjectフィールドのDNから抽出された共通名（CN）です。この構成はKibanaへのPKI認証を許可するには不十分であり、追加の手順が必要です。

  1. - 2*.* オプション: ユーザー名は[username_pattern](d1e2d0944ccc2737.md#ref-pki-settings)によって定義されます。Subject DNのCN以外のものをユーザー名として使用したい場合は、希望するユーザー名を抽出するための正規表現を指定できます。正規表現はSubject DNに適用されます。
  2. 例えば、以下の構成の正規表現はSubject DNからメールアドレスを抽出します:
  5. #### Yaml
  7. ``````yaml
  8. xpack:
  9.    security:
  10.    authc:
  11.    realms:
  12.    pki:
  13.    pki1:
  14.    order: 1
  15.    username_pattern: "EMAILADDRESS=(.*?)(?:,|$)"
  16. `

正規表現が厳しすぎてクライアントの証明書のSubject DNに一致しない場合、レルムは証明書を認証しません。

  • 3. オプション: 同じユーザーがKibanaに接続する際に証明書を使用して認証されることを望む場合、Elasticsearch PKIレルムをデリゲーションを許可するように構成する必要があります。詳細は、Kibanaに接続するクライアントのPKI認証を参照してください。
  • 4. Elasticsearchを再起動します。レルム構成は自動的に再読み込みされません。次の手順を進める場合は、再起動を最後に行うことをお勧めします。
  • 5. SSL/TLSを有効にする。
  • 6. 必要なネットワーク層（トランスポートまたはHTTP）でクライアント認証を有効にします。
    クライアントがElasticsearchに直接接続する際にPKIを使用するには、クライアント認証を伴うSSL/TLSを有効にする必要があります。つまり、xpack.security.transport.ssl.client_authenticationとxpack.security.http.ssl.client_authenticationをoptionalまたはrequiredに設定する必要があります。設定値がoptionalの場合、証明書のないクライアントは他の資格情報で認証できます。
    クライアントがElasticsearchに直接接続し、プロキシ認証されていない場合、PKIレルムはノードのネットワークインターフェースのTLS設定に依存します。レルムは、基盤となるネットワーク接続よりも制限的に構成できます。つまり、ノードを構成して、ネットワークインターフェースによって受け入れられる接続がありながら、PKIレルムによって認証に失敗することが可能です。ただし、その逆は不可能です。PKIレルムは、ネットワークインターフェースによって拒否された接続を認証することはできません。
    特に、これは以下を意味します:
    • トランスポートまたはHTTPインターフェースは、client_authenticationをoptionalまたはrequiredに設定することによってクライアント証明書を要求する必要があります。
    • インターフェースは、truststoreまたはcertificate_authoritiesパスを構成するか、verification_modeをnoneに設定することによって、クライアントによって提示された証明書を信頼する必要があります。
    • インターフェースによってサポートされるプロトコルは、クライアントによって使用されるプロトコルと互換性がある必要があります。
      これらの設定の説明については、一般的なTLS設定を参照してください。
      関連するネットワークインターフェース（トランスポートまたはHTTP）は、PKIレルム内で使用される任意の証明書を信頼するように構成する必要があります。ただし、PKIレルムを構成して、ネットワークインターフェースによって受け入れられる証明書のサブセットのみを信頼することも可能です。これは、SSL/TLS層が、ユーザーの証明書を署名するCAとは異なるCAによって署名された証明書を持つクライアントを信頼する場合に便利です。
      PKIレルムを独自のトラストストアで構成するには、truststore.pathオプションを指定します。パスはElasticsearch構成ディレクトリ内に配置する必要があります（ES_PATH_CONF）。例えば:

Yaml

  1. xpack:
  2.    security:
  3.    authc:
  4.    realms:
  5.    pki:
  6.    pki1:
  7.    order: 1
  8.    truststore:
  9.    path: "pki1_truststore.jks"

トラストストアがパスワードで保護されている場合、パスワードは適切なsecure_password設定をElasticsearchキーストアに追加することによって構成する必要があります。例えば、以下のコマンドは上記の例のレルムのパスワードを追加します:

Shell

  1. bin/elasticsearch-keystore add \
  2.   xpack.security.authc.realms.pki.pki1.truststore.secure_password
  1. - 7*.* PKIユーザーのロールをマッピングします。
  2. PKIユーザーのロールは、[ロールマッピングAPI](0e8e70aa29cc2ec2.md#security-role-mapping-apis)を通じて、または各ノードに保存されたファイルを使用してマッピングします。両方の構成オプションは統合されます。ユーザーがPKIレルムに対して認証されると、そのユーザーの特権は、ユーザーがマッピングされているロールによって定義されたすべての特権の和になります。
  3. ユーザーは、証明書の識別名によって識別されます。例えば、以下のマッピング構成は、ロールマッピングAPIを使用して`````John Doe`````を`````user`````ロールにマッピングします:
  6. #### Python
  8. ``````python
  9. resp = client.security.put_role_mapping(
  10.    name="users",
  11.    roles=[
  12.    "user"
  13.    ],
  14.    rules={
  15.    "field": {
  16.    "dn": "cn=John Doe,ou=example,o=com"
  17.    }
  18.    },
  19.    enabled=True,
  20.   )
  21.   print(resp)
  22. `

Js

  1. const response = await client.security.putRoleMapping({
  2.    name: "users",
  3.    roles: ["user"],
  4.    rules: {
  5.    field: {
  6.    dn: "cn=John Doe,ou=example,o=com",
  7.    },
  8.    },
  9.    enabled: true,
  10.   });
  11.   console.log(response);

Console

  1. PUT /_security/role_mapping/users
  2.   {
  3.    "roles" : [ "user" ],
  4.    "rules" : { "field" : {
  5.    "dn" : "cn=John Doe,ou=example,o=com"
  6.    } },
  7.    "enabled": true
  8.   }
PKIユーザーの識別名（DN）。

代わりに、ロールマッピングファイルを使用します。例えば:

Yaml

  1. user:
  2.     - "cn=John Doe,ou=example,o=com"
ロールの名前。
PKIユーザーの識別名（DN）。

ファイルのパスはデフォルトでES_PATH_CONF/role_mapping.ymlです。ES_PATH_CONF内にある必要がある異なるパスを指定することもできます。files.role_mappingレルム設定を使用して（例: xpack.security.authc.realms.pki.pki1.files.role_mapping）。
PKIユーザーの識別名は、最も特定のフィールド（cnやuidのような）が名前の先頭にあり、最も一般的なフィールド（oやdcのような）が名前の末尾にあるX.500命名規則に従います。opensslなどの一部のツールは、異なる形式で主題名を出力する場合があります。
証明書の正しいDNを決定する方法の1つは、authenticate APIを使用し（関連するPKI証明書を認証手段として使用）、結果のメタデータフィールドを検査することです。ユーザーの識別名はpki_dnキーの下に設定されます。ロールマッピングを検証するためにauthenticate APIを使用することもできます。
詳細については、ユーザーとグループをロールにマッピングするを参照してください。
PKIレルムは、ロールマッピングの代替として認可レルムをサポートしています。

Kibanaに接続するクライアントのPKI認証

デフォルトでは、PKIレルムはノードのネットワークインターフェースに依存してSSL/TLSハンドシェイクを実行し、クライアント証明書を抽出します。この動作は、クライアントがElasticsearchに直接接続し、そのSSL接続がElasticsearchノードによって終了されることを要求します。KibanaによってSSL/TLS認証が実行される場合、PKIレルムはデリゲーションを許可するように構成されなければなりません。

具体的には、X.509証明書を提示するクライアントがKibanaに接続すると、KibanaはSSL/TLS認証を実行します。Kibanaはその後、クライアントの証明書チェーンを（Elasticsearch APIを呼び出すことによって）PKIレルムに転送し、デリゲーションのために構成されたPKIレルムによってさらに検証されます。

特定のElasticsearch PKIレルムに対して認証デリゲーションを許可するには、通常のケースのためにレルムを構成することから始めます。これは、Elasticsearchに直接接続するクライアントのPKI認証セクションで詳述されています。このシナリオでは、TLSを有効にする際に、HTTPクライアント通信を暗号化することが必須です。

ネットワーク層で構成したのと同じトラスト構成であるにもかかわらず、truststore（または同等のcertificate_authorities）を明示的に構成する必要があります。xpack.security.authc.token.enabledおよびdelegation.enabled設定もtrueである必要があります。例えば:

Yaml

  1. xpack:
  2.   security:
  3.    authc:
  4.    token.enabled: true
  5.    realms:
  6.    pki:
  7.    pki1:
  8.    order: 1
  9.    delegation.enabled: true
  10.    truststore:
  11.    path: "pki1_truststore.jks"

Elasticsearchを再起動した後、このレルムはデリゲートされたPKI認証を検証できます。その後、KibanaをPKI証明書認証を許可するように構成する必要があります。

  2. ただし、[ロールマッピングAPI](0e8e70aa29cc2ec2.md#security-role-mapping-apis)を使用する場合、デリゲーションによって認証されたユーザーと直接認証されたユーザーを区別できます。前者は、ユーザーのメタデータに`````pki_delegated_by_user`````および`````pki_delegated_by_realm`````という追加フィールドを持っています。一般的なセットアップでは、認証がKibanaにデリゲートされる場合、これらのフィールドの値はそれぞれ`````kibana`````および`````reserved`````です。例えば、以下のロールマッピングルールは、`````pki1`````レルムによって直接認証されたすべてのユーザーに`````role_for_pki1_direct`````ロールを割り当てます。これは、Kibanaを経由せずにElasticsearchに接続することによって行われます:
  5. #### Python
  7. ``````python
  8. resp = client.security.put_role_mapping(
  9.    name="direct_pki_only",
  10.    roles=[
  11.    "role_for_pki1_direct"
  12.    ],
  13.    rules={
  14.    "all": [
  15.    {
  16.    "field": {
  17.    "realm.name": "pki1"
  18.    }
  19.    },
  20.    {
  21.    "field": {
  22.    "metadata.pki_delegated_by_user": None
  23.    }
  24.    }
  25.    ]
  26.    },
  27.    enabled=True,
  28. )
  29. print(resp)
  30. `

Js

  1. const response = await client.security.putRoleMapping({
  2.   name: "direct_pki_only",
  3.   roles: ["role_for_pki1_direct"],
  4.   rules: {
  5.    all: [
  6.    {
  7.    field: {
  8.    "realm.name": "pki1",
  9.    },
  10.    },
  11.    {
  12.    field: {
  13.    "metadata.pki_delegated_by_user": null,
  14.    },
  15.    },
  16.    ],
  17.   },
  18.   enabled: true,
  19. });
  20. console.log(response);

Console

  1. PUT /_security/role_mapping/direct_pki_only
  2. {
  3.   "roles" : [ "role_for_pki1_direct" ],
  4.   "rules" : {
  5.    "all": [
  6.    {
  7.    "field": {"realm.name": "pki1"}
  8.    },
  9.    {
  10.    "field": {
  11.    "metadata.pki_delegated_by_user": null
  12.    }
  13.    }
  14.    ]
  15.   },
  16.   "enabled": true
  17. }
このメタデータフィールドが設定されている場合（つまり、設定されていないnull）、ユーザーはデリゲーションシナリオで認証されています。