全体像: きめ細かなアクセスコントロールとAmazon ESセキュリティ主要なコンセプトきめ細かなアクセスコントロールの有効化マスターユーザーとしての Kibana へのアクセスアクセス権限の管理推奨される設定チュートリアル: IAM マスターユーザーとAmazon Cognito チュートリアル: 内部ユーザーデータベースと HTTP 基本認証 Limitations マスターユーザーの変更追加のマスターユーザー手動スナップショット Integrations REST API の相違点

Amazon Elasticsearch Service でのきめ細かなアクセスコントロール

きめ細かなアクセスコントロールは、Amazon Elasticsearch Service のデータへのアクセスをコントロールする追加の方法を提供します。たとえば、リクエスト者によっては、検索で 1 つのインデックスのみから結果が返されるようにしたい場合があります。ドキュメント内の特定のフィールドを非表示にしたい場合や、特定のドキュメントをまとめて除外したい場合もあります。きめ細かなアクセスコントロールには、以下の機能があります。

ロールベースアクセスコントロール
インデックスレベル、ドキュメントレベル、フィールドレベルのセキュリティ
Kibana マルチテナンシー
Elasticsearch および Kibana の HTTP 基本認証

トピック

全体像: きめ細かなアクセスコントロールとAmazon ESセキュリティ
主要なコンセプト
きめ細かなアクセスコントロールの有効化
マスターユーザーとしての Kibana へのアクセス
アクセス権限の管理
推奨される設定
チュートリアル: IAM マスターユーザーとAmazon Cognito
チュートリアル: 内部ユーザーデータベースと HTTP 基本認証
Limitations
マスターユーザーの変更
追加のマスターユーザー
手動スナップショット
Integrations
REST API の相違点

全体像: きめ細かなアクセスコントロールとAmazon ESセキュリティ

Amazon Elasticsearch Service セキュリティには 3 つの主要なレイヤーがあります。

Network: 最初のセキュリティレイヤーはネットワークであり、リクエストが Amazon ES ドメインに到達するかどうかを決定します。ドメインを作成するときに [パブリックアクセス] を選択した場合、インターネットに接続されたクライアントからのリクエストがドメインエンドポイントに到達できます。[VPC access (VPC アクセス)] を選択した場合、クライアントがエンドポイントに到達するためには、クライアントが VPC に接続する必要があります (かつ、関連するセキュリティグループがその接続を許可する必要があります)。詳細については、Amazon Elasticsearch Service ドメインの VPC サポートを参照してください。

ドメインアクセスポリシー: 2 番目のセキュリティレイヤーは、ドメインアクセスポリシーです。リクエストがドメインエンドポイントに到達すると、リソースベースのアクセスポリシーにより、指定された URI へのアクセスリクエストが許可または拒否されます。このアクセスポリシーにより、リクエストは Elasticsearch 自体に到達する前に、ドメインの「エッジ」で許可または拒否されます。

きめ細かなアクセス制御: 最後の 3 番目のセキュリティレイヤーは、きめ細かなアクセスコントロールです。リソースベースのアクセスポリシーにより、リクエストがドメインエンドポイントに到達することが許可された後、きめ細かなアクセスコントロールにより、ユーザー認証情報が評価されて、ユーザーが認証されるか、リクエストが拒否されます。きめ細かなアクセスコントロールによりユーザーが認証された場合、そのユーザーにマッピングされているすべてのロールが取得され、付与されるすべてのアクセス許可を使用してリクエストの処理方法が決定されます。

注記

リソースベースのアクセスポリシーに IAM ユーザーまたはロールが含まれる場合、クライアントは AWS 署名バージョン 4 を使用して署名付きリクエストを送信する必要があります。そのため、アクセスポリシーは、特に内部ユーザーデータベースと HTTP 基本認証を使用する場合、きめ細かなアクセスコントロールと競合することがあります。ユーザー名とパスワードで、かつ IAM 認証情報で、リクエストに署名することはできません。一般に、きめ細かなアクセスコントロールを有効にする場合は、署名付きリクエストを必須としないドメインアクセスポリシーを使用することをお勧めします。

この最初の図は、きめ細かなアクセスコントロールが有効な VPC アクセスドメイン、IAM ベースのアクセスポリシー、IAM マスターユーザーという、一般的な構成を示しています。

この 2 番目の図は、きめ細かなアクセスコントロールが有効なパブリックアクセスドメイン、IAM プリンシパルを使用しないアクセスポリシー、内部ユーザーデータベース内のマスターユーザーという、別の一般的な構成を示しています。

Example

へのGETリクエストを考えてみますmovies/_search?q=thor。ユーザーにmoviesインデックスを検索するアクセス許可があることを確認します。その場合、ユーザーにその内部のすべてのドキュメントを表示するアクセス許可があることを確認します。レスポンスで、フィールドを省略または匿名化するかを選択します。マスターユーザーの場合、レスポンスは以下のようになります。


{
  "hits": {
    "total": 7,
    "max_score": 8.772789,
    "hits": [{
        "_index": "movies",
        "_type": "_doc",
        "_id": "tt0800369",
        "_score": 8.772789,
        "_source": {
          "directors": [
            "Kenneth Branagh",
            "Joss Whedon"
          ],
          "release_date": "2011-04-21T00:00:00Z",
          "genres": [
            "Action",
            "Adventure",
            "Fantasy"
          ],
          "plot": "The powerful but arrogant god Thor is cast out of Asgard to live amongst humans in Midgard (Earth), where he soon becomes one of their finest defenders.",
          "title": "Thor",
          "actors": [
            "Chris Hemsworth",
            "Anthony Hopkins",
            "Natalie Portman"
          ],
          "year": 2011
        }
      },
      ...
    ]
  }
}

アクセス許可がより制限されたユーザーが上記と同じリクエストを発行した場合、レスポンスは以下のようになります。


{
  "hits": {
    "total": 2,
    "max_score": 8.772789,
    "hits": [{
        "_index": "movies",
        "_type": "_doc",
        "_id": "tt0800369",
        "_score": 8.772789,
        "_source": {
          "year": 2011,
          "release_date": "3812a72c6dd23eef3c750c2d99e205cbd260389461e19d610406847397ecb357",
          "plot": "The powerful but arrogant god Thor is cast out of Asgard to live amongst humans in Midgard (Earth), where he soon becomes one of their finest defenders.",
          "title": "Thor"
        }
      },
      ...
    ]
  }
}

レスポンスでは、ヒット数、およびヒットあたりのフィールド数が少なくなっています。また、release_date フィールドは匿名化されています。アクセス許可のないユーザーが上記と同じリクエストを発行した場合、クラスターによってエラーが返されます。


{
  "error": {
    "root_cause": [{
      "type": "security_exception",
      "reason": "no permissions for [indices:data/read/search] and User [name=limited-user, roles=[], requestedTenant=null]"
    }],
    "type": "security_exception",
    "reason": "no permissions for [indices:data/read/search] and User [name=limited-user, roles=[], requestedTenant=null]"
  },
  "status": 403
}

ユーザーが無効な認証情報を提供した場合、クラスターによって Unauthorized 例外が返されます。

主要なコンセプト

ロールは、きめ細かなアクセスコントロールの主要な使用方法です。この場合、ロールは IAM ロールとは異なります。ロールには、クラスター全体、インデックス固有、ドキュメントレベル、フィールドレベルのアクセス許可の任意の組み合わせが含まれます。

ロールを設定したら、1 人以上のユーザーにマッピングします。たとえば、3 つのロールを 1 人のユーザーにマッピングできます。1 つは Kibana index1 へのアクセスを許可するロール、もう 1 つはへの読み取り専用アクセスを許可するロール、もう 1 つはへの書き込みアクセスを許可するロールindex2です。または、これらのすべてのアクセス許可を 1 つのロールに含めることもできます。

ユーザーは、Elasticsearch クラスターに対してリクエストを行うユーザーまたはアプリケーションです。ユーザーは、リクエスト時に指定する認証情報として IAM アクセスキーを使用するか、ユーザー名とパスワードを使用します。Amazon Elasticsearch Service のきめ細かなアクセスコントロールで、ドメインを設定するときにマスターユーザー用にいずれかの認証情報を選択します。マスターユーザーはクラスターに対する完全なアクセス許可を持ち、ロールとロールマッピングを管理します。

マスターユーザー用に IAM を選択した場合、クラスターに対するすべてのリクエストは AWS 署名バージョン 4 を使用して署名される必要があります。サンプルコードについては、「Amazon Elasticsearch Service への HTTP リクエストの署名」を参照してください。

複数のクラスターで同じユーザーを使用する場合、Amazon Cognito を使用して Kibana にアクセスする場合 (外部 ID プロバイダの有無にかかわらず)、または署名バージョン 4 をサポートする Elasticsearch クライアントがある場合は、IAM をお勧めします。
内部ユーザーデータベースを選択した場合は、HTTP 基本認証 (および IAM 認証情報) を使用して、クラスターに対してリクエストを行うことができます。ほとんどのクライアントは、curl などの基本認証をサポートしています。内部ユーザーデータベースは Elasticsearch インデックスに保存されるため、他のクラスターと共有することはできません。

複数のクラスター間でユーザーを再利用する必要がない場合、Kibana へのアクセスに Amazon Cognito ではなく HTTP 基本認証を使用する場合、または基本認証のみをサポートするクライアントがある場合は、内部ユーザーデータベースをお勧めします。Amazon ES の使用を開始するには、内部ユーザーデータベースが最もシンプルな方法です。

きめ細かなアクセスコントロールの有効化

コンソール、AWS CLI、または configuration API を使用して、きめ細かなアクセスコントロールを有効にします。コンソールを使用すると、エクスペリエンスは最もシンプルです。手順については、「Amazon Elasticsearch Service ドメインの作成と管理」を参照してください。きめ細かなアクセスコントロールを有効にするための要件は以下のとおりです。

Elasticsearch 6.7 以降
保管時のデータの暗号化およびノード間の暗号化の有効化
[Require HTTPS for all traffic to the domain (ドメインへのすべてのトラフィックに HTTPS を要求する)] の有効化

きめ細かなアクセスコントロールは既存のドメインに対して有効にすることはできません。新しいドメインに対してのみ有効にすることができます。きめ細かなアクセスコントロールを有効にした後、無効にすることはできません。

マスターユーザーとしての Kibana へのアクセス

きめ細かなアクセスコントロールには、管理タスクをシンプルにする Kibana プラグインがあります。Kibana を使用して、ユーザー、ロール、マッピング、アクショングループ、テナントを管理できます。ただし、Kibana サインインページと基になる認証方法は、ドメインの設定方法によって異なります。

ユーザー管理に IAM を使用する場合は、Kibana の Amazon Cognito 認証を有効にし、ユーザープールの認証情報を使用してサインインして Kibana にアクセスする必要があります。それ以外の方法では、Kibana の「機能しない」サインインページが表示されます。「Limitations」を参照してください。

Amazon Cognito ID プールから引き受けたいずれかのロールが、マスターユーザーに指定した IAM ロールと一致する必要があります。この設定の詳細については、「(オプション) きめ細かなアクセスの設定」および「チュートリアル: IAM マスターユーザーとAmazon Cognito」を参照してください。
内部ユーザーデータベースを使用する場合は、マスターユーザー名とパスワードを使用して Kibana にサインインできます。HTTPS 経由で Kibana にアクセスする必要があります。この設定の詳細については、「チュートリアル: 内部ユーザーデータベースと HTTP 基本認証」を参照してください。
SAML 認証を使用することを選択した場合は、外部 ID プロバイダーからの認証情報を使用してサインインできます。詳細については、Kibana の SAML 認証を参照してください。

アクセス権限の管理

「主要なコンセプト」で説明しているように、ロール、ユーザー、マッピングを使用してきめ細かなアクセスコントロールのアクセス許可を管理します。このセクションでは、これらのリソースを作成して適用する方法について説明します。これらの操作を実行するには、マスターユーザーとして Kibana にサインインすることをお勧めします。

ロールの作成

Kibana、または REST API の _opendistro/_security オペレーションを使用して、きめ細かなアクセスコントロール用の新しいロールを作成できます。詳細については、Open Distro for Elasticsearch のドキュメントを参照してください。

きめ細かなアクセスコントロールには、多くの事前定義されたロールも含まれます。Kibana や Logstash などのクライアントは、Elasticsearch に対して多種多様なリクエストを行うため、最小限のアクセス許可のセットを使用してロールを手動で作成するのが難しくなる場合があります。たとえば、kibana_user ロールには、ユーザーがインデックスパターン、可視化、ダッシュボード、およびテナントを操作するのに必要なアクセス許可が含まれます。このロールは、他のインデックスへのアクセスを許可する追加のロールと共に、Kibana にアクセスするすべてのユーザーまたはバックエンドロールにマッピングすることをお勧めします。

クラスターレベルのセキュリティ

_mgetクラスターレベルのアクセス許可により、、 _msearch 、などの広範なリクエストの実行、ヘルスのモニタリング、スナップショットの取得などが可能になります。_bulkロールを作成するときに、[Cluster Permissions (クラスターアクセス許可)] タブを使用してこれらのアクセス許可を管理します。クラスターレベルのアクショングループのリストについては、Open Distro for Elasticsearch のドキュメントを参照してください。

インデックスレベルのセキュリティ

インデックスレベルのアクセス許可により、新しいインデックスの作成、インデックスの検索、ドキュメントの読み取りと書き込み、ドキュメントの削除、エイリアスの管理などを可能にするかどうかを制御できます。ロールを作成するときに、[Index Permissions (インデックスアクセス許可)] タブを使用してこれらのアクセス許可を管理します。インデックスレベルのアクショングループのリストについては、Open Distro for Elasticsearch のドキュメントを参照してください。

ドキュメントレベルのセキュリティ

ドキュメントレベルのセキュリティにより、インデックス内のどのドキュメントをユーザーが表示できるかを制限できます。ロールを作成するときに、インデックスパターンと Elasticsearch クエリを指定します。そのロールにマッピングされたすべてのユーザーは、クエリに一致するドキュメントのみを表示できます。ドキュメントレベルのセキュリティは、検索時に受け取るヒットの数に影響します。

詳細については、Open Distro for Elasticsearch のドキュメントを参照してください。

フィールドレベルのセキュリティ

フィールドレベルのセキュリティにより、どのドキュメントフィールドをユーザーが表示できるかを制御できます。ロールを作成するときに、含めるフィールドと除外するフィールドのリストを追加します。フィールドを含めると、そのロールにマッピングされたユーザーはそれらのフィールドのみを表示できます。フィールドを除外すると、除外されたフィールドを除くすべてのフィールドを表示できます。フィールドレベルのセキュリティは、検索時にヒットに含まれるフィールドの数に影響します。

詳細については、Open Distro for Elasticsearch のドキュメントを参照してください。

フィールドのマスキング

フィールドのマスキングは、フィールドレベルのセキュリティに代わるもので、フィールド内のデータを完全に削除するのではなく、匿名化できます。ロールを作成するときに、マスクするフィールドのリストを追加します。フィールドのマスキングは、検索時にフィールドの内容を表示できるかどうかに影響します。

ユーザーの作成

内部ユーザーデータベースを有効にした場合、Kibana、または REST API の _opendistro/_security オペレーションを使用してユーザーを作成できます。詳細については、Open Distro for Elasticsearch のドキュメントを参照してください。

マスターユーザーに IAM を選択した場合は、Kibana のこの部分は無視してください。代わりに、IAM ユーザーと IAM ロールを作成します。詳細については、IAM ユーザーガイドを参照してください。

ユーザーへのロールのマッピング

ロールのマッピングは、きめ細かなアクセスコントロールの最も重要な側面です。きめ細かなアクセスコントロールには、使用の開始に役立ついくつかの事前定義されたロールがありますが、ロールをユーザーにマッピングしない限り、クラスターに対するすべてのリクエストはアクセス許可エラーという結果になります。

バックエンドロールは、ロールをユーザーにマッピングする別の方法です。同じロールを多数の異なるユーザーにマッピングするのではなく、ロールを 1 つのバックエンドロールにマッピングしてから、すべてのユーザーがそのバックエンドロールを持つようにできます。バックエンドロールは、内部ユーザーデータベースでユーザーを作成するときに指定する IAM ロールまたは任意の文字列です。

ユーザーARNsセクションで、ユーザー、IAM ユーザー、およびAmazon Cognitoユーザー文字列を指定します。Cognito ユーザー文字列の形式は Cognito/user-pool-id/username です。
ARNsバックエンドロールセクションで、バックエンドロールと IAM ロールを指定します。

Kibana、または REST API の _opendistro/_security オペレーションを使用して、ロールをユーザーにマッピングできます。詳細については、Open Distro for Elasticsearch のドキュメントを参照してください。

アクショングループの作成

アクショングループは、さまざまなリソースで再利用できるアクセス許可のセットです。Kibana、または REST API の _opendistro/_security オペレーションを使用して新しいアクショングループを作成できますが、ほとんどのユースケースではデフォルトのアクショングループで十分です。デフォルトのアクショングループの詳細については、Open Distro for Elasticsearch のドキュメントを参照してください。

Kibana マルチテナンシー

テナントは、インデックスパターン、可視化、ダッシュボード、その他の Kibana オブジェクトを保存するための領域です。Kibana マルチテナンシーを使用すると、他の Kibana ユーザーと作業を安全に共有できます (プライベートに保持できます)。どのロールがテナントにアクセスできるか、それらのロールに読み取りアクセスがあるか書き込みアクセスがあるかを制御できます。詳細については、Open Distro for Elasticsearch のドキュメントを参照してください。

現在のテナントを表示したりテナントを変更したりするには

Kibana に移動してサインインします。
[Tenants (テナント)] を選択します。
可視化またはダッシュボードを作成する前に、テナントを確認します。他のすべての Kibana ユーザーと作業を共有する場合は、[グローバル] を選択します。一部の Kibana ユーザーと作業を共有するには、別の共有テナントを選択します。それ以外の場合は、[Private (プライベート)] を選択します。

推奨される設定

きめ細かなアクセスコントロールは他のセキュリティ機能と連携するため、ここでは、ほとんどのユースケースで適切に機能するきめ細かなアクセスコントロールの推奨される設定を示します。

説明	マスターユーザー	ドメインアクセスポリシー
への呼び出しには IAM Elasticsearch APIs 認証情報を使用し、Kibana へのアクセスには SAML 認証を使用します。Kibana または REST API を使用して、きめ細かなアクセスコントロールのロールを管理します。	IAM ユーザーまたはロール	`{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "" }, "Action": "es:ESHttp", "Resource": "domain-arn/*" } ] }`
への呼び出しに IAM Elasticsearch APIs 認証情報または基本認証を使用し、Kibana へのアクセスに基本認証を使用します。Kibana または REST API を使用して、きめ細かなアクセスコントロールのロールを管理します。	ユーザー名とパスワード	`{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "" }, "Action": "es:ESHttp", "Resource": "domain-arn/*" } ] }`
への呼び出しには IAM Elasticsearch APIs 認証情報を使用し、Kibana へのアクセスにはを使用します。Amazon CognitoKibana または REST API を使用して、きめ細かなアクセスコントロールのロールを管理します。	IAM ユーザーまたはロール	`{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "" }, "Action": "es:ESHttp", "Resource": "domain-arn/*" } ] }`
への呼び出しに IAM Elasticsearch APIs 認証情報を使用し、Kibana へのほとんどのアクセスをブロックします。REST API を使用して、きめ細かなアクセスコントロールのロールを管理します。	IAM ユーザーまたはロール	`{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "" }, "Action": "es:ESHttp", "Resource": "domain-arn/" }, { "Effect": "Deny", "Principal": { "AWS": "" }, "Action": "es:ESHttp", "Resource": "domain-arn/_plugin/kibana" } ] }`

チュートリアル: IAM マスターユーザーとAmazon Cognito

このチュートリアルでは、一般的なユースケースとして、Kibana の Amazon Cognito 認証を受ける IAM マスターユーザーについて説明します。これらの手順は、認証に Amazon Cognito ユーザープールを使用しますが、この同じ基本プロセスは、Cognito 認証プロバイダに対して機能するため、異なる IAM ロールを異なるユーザー (SAML など) に割り当てることができます。

注記

このチュートリアルでは、マスターユーザー用と制限付きユーザー用の 2 つの既存の IAM ロールがあることを前提としています。ロールが 2 つない場合は、作成します。

きめ細かなアクセスコントロールの使用を開始するには

以下の設定でドメインを作成します。
- Elasticsearch7.8
- パブリックアクセス
- IAM ロールをマスターユーザーとして有効にしたきめ細かなアクセスコントロール (このチュートリアルの残りの部分では IAMMasterUserRole)
- Kibana の Amazon Cognito 認証の有効化
- 以下のアクセスポリシー:
```
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "*"
        ]
      },
      "Action": [
        "es:ESHttp*"
      ],
      "Resource": "arn:aws:es:region:account:domain/domain-name/*"
    }
  ]
}
```
- ドメインへのすべてのトラフィックに HTTPS を必須とする
- ノード間の暗号化
- 保管時のデータの暗号化
IAM コンソールに移動し、[ロール] を選択します。
IAMMasterUserRole を選択してから、[信頼関係] タブを選択します。

[信頼関係の編集] を選択し、Amazon Cognito ID プールがロールを引き受け可能になっていることを確認します。以下のステートメントが表示されます。


{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "Federated": "cognito-identity.amazonaws.com"
    },
    "Action": "sts:AssumeRoleWithWebIdentity",
    "Condition": {
      "StringEquals": {
        "cognito-identity.amazonaws.com:aud": "identity-pool-id"
      },
      "ForAnyValue:StringLike": {
        "cognito-identity.amazonaws.com:amr": "authenticated"
      }
    }
  }]
}

[Update Trust Policy] を選択します。
同じ信頼ポリシーを 2 番目の IAM ロールに追加します (このチュートリアルの残りの部分では IAMLimitedUserRole)。
Amazon Cognito コンソールに移動し、[ユーザープールの管理] を選択します。
ユーザープールを選択してから、[ユーザーとグループ] を選択します。
[ユーザーの作成] を選択し、ユーザー名 master-user とパスワードを指定して、[ユーザーの作成] を選択します。
limited-user という名前の別のユーザーを作成します。
[グループ] タブを選択してから、[グループの作成] を選択します。
グループに master-user-group という名前を付け、[IAM ロール] ドロップダウンリストで IAMMasterUserRole を選択してから、[グループの作成] を選択します。
IAMLimitedUserRole を使用する limited-user-group という名前の別のグループを作成します。
master-user-group を選択し、[ユーザーの追加] を選択してから、master-user を追加します。
limited-user-group を選択し、[ユーザーの追加] を選択してから、limited-user を追加します。
[アプリクライアントの設定] を選択し、ドメインのアプリクライアント ID をメモします。
[フェデレーティッドアイデンティティ] を選択し、ID プールを選択してから、[ID プールの編集] を選択します。
[認証プロバイダー] を展開し、ドメインのユーザープール ID とアプリクライアント ID を見つけて、[デフォルトロールを使用] を [トークンからロールを選択する] に変更します。
「ロール解決」で、[拒否] を選択します。この設定では、認証後に IAM ロールを受け取るには、ユーザーがグループに属している必要があります。
[Save Changes (変更の保存)] を選択します。
Kibana に移動します。
master-user でサインインします。
[Try our sample data (サンプルデータを試す)] を選択します。
サンプルのフライトデータを追加します。
[Security (セキュリティ)]、[ロール]、[Add a new role (新しいロールの追加)] の順に選択します。
ロールに new-role という名前を付け、[Index Permissions (インデックスアクセス許可)] を選択します。
[Add index permissions (インデックスアクセス許可の追加)] を選択し、インデックスパターンに kibana_sample_data_fli* を指定します。
[アクションの追加]、[read (読み取り)] の順に選択します。
[Document Level Security Query (ドキュメントレベルセキュリティクエリ)] で、以下のクエリを指定します。
```
{
  "match": {
    "FlightDelay": true
  }
}
```
次に、[Test DLS query syntax (DLS クエリ構文のテスト)] を選択します。
[Include or exclude fields (フィールドを含める/除外する)] で [Exclude fields (フィールドの除外)]、[Add Field (フィールドの追加)] の順に選択します。を指定しますFlightNum。
[Anonymize fields (フィールドの匿名化)] で、[Add Field (フィールドの追加)] を選択します。を指定しますDest。
[Save Role Definition (ロール定義の保存)] を選択します。
[Back (戻る)]、[Role Mappings (ロールマッピング)]、[Add a new role mapping (新しいロールマッピングの追加)] の順に選択します。
[Role (ロール)] で、[new-role] を選択します。[Add Backend Role (バックエンドロールの追加)] を選択し、の ARN を指定しますIAMLimitedUserRole。次に、[送信] を選択します。
[Add a new role mapping (新しいロールマッピングの追加)] を再度選択します。
[Role (ロール)] で、[kibana_user] を選択します。[Add Backend Role (バックエンドロールの追加)] を選択し、の ARN を指定しますIAMLimitedUserRole。次に、[送信] を選択します。
新しいプライベートブラウザウィンドウで、Kibana に移動し、limited-user を使用してサインインして、[Explore on my own (自分で探す)] を選択します。
[Dev Tools (開発ツール)] を選択し、デフォルトの検索を実行します。
```
GET _search
{
  "query": {
    "match_all": {}
  }
}
```
アクセス許可エラーに注意します。には、クラスター全体の検索を実行するアクセス許可がありません。limited-user
別の検索を実行します。
```
GET kibana_sample_data_flights/_search
{
  "query": {
    "match_all": {}
  }
}
```
一致するすべてのドキュメントでは、[FlightDelay] フィールドが true であり、Dest フィールドが匿名化されて、FlightNum フィールドはありません。
元のブラウザウィンドウで、master-user としてサインインし、[Dev Tools (開発ツール)] を選択して、同じ検索を実行します。アクセス許可、ヒット数、一致するドキュメント、含まれるフィールドが異なっています。

チュートリアル: 内部ユーザーデータベースと HTTP 基本認証

このチュートリアルでは、内部ユーザーデータベースのマスターユーザーと Kibana の HTTP 基本認証という、別の一般的なユースケースについて説明します。

きめ細かなアクセスコントロールの使用を開始するには

以下の設定でドメインを作成します。
- Elasticsearch7.8
- パブリックアクセス
- 内部ユーザーデータベース内のマスターユーザーによるきめ細かなアクセスコントロール (このチュートリアルの残りの部分では TheMasterUser)
- Kibana の Amazon Cognito 認証は無効
- 以下のアクセスポリシー:
```
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "*"
        ]
      },
      "Action": [
        "es:ESHttp*"
      ],
      "Resource": "arn:aws:es:region:account:domain/domain-name/*"
    }
  ]
}
```
- ドメインへのすべてのトラフィックに HTTPS を必須とする
- ノード間の暗号化
- 保管時のデータの暗号化
Kibana に移動します。
TheMasterUser を使用してサインインします。
[Try our sample data (サンプルデータを試す)] を選択します。
サンプルのフライトデータを追加します。
[Security (セキュリティ)]、[Internal User Database (内部ユーザーデータベース)]、[Add a new internal user (新しい内部ユーザーの追加)] の順に選択します。
ユーザーに new-user という名前を付け、パスワードを指定して、ユーザーにのバックエンドロールを与えますnew-backend-role。次に、[送信] を選択します。
[Back (戻る)]、[ロール]、[Add a new role (新しいロールの追加)] の順に選択します。
ロールに new-role という名前を付け、[Index Permissions (インデックスアクセス許可)] を選択します。
[Add index permissions (インデックスアクセス許可の追加)] を選択し、インデックスパターンに kibana_sample_data_fli* を指定します。
[Add Action Group (アクショングループの追加)]、[read (読み取り)] の順に選択します。
[Document Level Security Query (ドキュメントレベルセキュリティクエリ)] で、以下のクエリを指定します。
```
{
  "match": {
    "FlightDelay": true
  }
}
```
次に、[Test DLS query syntax (DLS クエリ構文のテスト)] を選択します。
[Include or exclude fields (フィールドを含める/除外する)] で [Exclude fields (フィールドの除外)]、[Add Field (フィールドの追加)] の順に選択します。を指定しますFlightNum。
[Anonymize fields (フィールドの匿名化)] で、[Add Field (フィールドの追加)] を選択します。を指定しますDest。
[Save Role Definition (ロール定義の保存)] を選択します。
[Back (戻る)]、[Role Mappings (ロールマッピング)]、[Add a new role mapping (新しいロールマッピングの追加)] の順に選択します。
[Role (ロール)] で、[new-role] を選択します。[Add Backend Role (バックエンドロールの追加)] を選択し、 new-backend-role を指定します。次に、[送信] を選択します。
[Add a new role mapping (新しいロールマッピングの追加)] を再度選択します。
[ Role ( ロール)] で、を選択しますkibana_user。 [Add User] を選択してを指定しますnew-user。次に、[送信] を選択します。

new-user には kibana_user ロールのみがありますが、new-backend-role バックエンドロールを持つすべてのユーザーには new-role ロールがあります。
新しいプライベートブラウザウィンドウで、Kibana に移動し、new-user を使用してサインインして、[Explore on my own (自分で探す)] を選択します。
[Dev Tools (開発ツール)] を選択し、デフォルトの検索を実行します。
```
GET _search
{
  "query": {
    "match_all": {}
  }
}
```
アクセス許可エラーに注意します。には、クラスター全体の検索を実行するアクセス許可がありません。new-user
別の検索を実行します。
```
GET kibana_sample_data_flights/_search
{
  "query": {
    "match_all": {}
  }
}
```
一致するすべてのドキュメントでは、[FlightDelay] フィールドが true であり、Dest フィールドが匿名化されて、FlightNum フィールドはありません。
元のブラウザウィンドウで、TheMasterUser としてサインインし、[Dev Tools (開発ツール)] を選択して、同じ検索を実行します。アクセス許可、ヒット数、一致するドキュメント、含まれるフィールドが異なっています。

Limitations

きめ細かなアクセスコントロールには、いくつかの重要な制限があります。

hosts のロールマッピングの側面は、ロールをホスト名または IP アドレスにマッピングすることですが、ドメインが VPC 内にある場合は機能しません。ただし、ロールをユーザーとバックエンドロールにマッピングすることは可能です。
内部ユーザーデータベース内のユーザーは自分のパスワードを変更できません。マスターユーザー (または同等のアクセス許可を持つユーザー) はパスワードを変更する必要があります。
マスターユーザーに IAM を選択し、 Amazon Cognitoまたは SAML 認証を有効にしない場合、Kibana の「機能しない」サインインページが表示されます。
マスターユーザーに IAM を選択しても、内部ユーザーデータベースにユーザーを作成することはできます。ただし、この設定では HTTP 基本認証が有効になっていないため、これらのユーザー認証情報で署名されたリクエストは拒否されます。
SQL を使用して、アクセスできないインデックスをクエリすると、「アクセス許可なし」のエラーが表示されます。インデックスが存在しない場合、「インデックスなし」のエラーが表示されます。このエラーメッセージの違いは、インデックスの名前を推測できれば、そのインデックスが存在していることがわかる点です。

この問題を最小限に抑えるために、インデックス名に機密情報を含めないでください。SQL へのすべてのアクセスを拒否するには、ドメインアクセスポリシーに以下の要素を追加します。
```
{
  "Effect": "Deny",
  "Principal": {
    "AWS": [
      "*"
    ]
  },
  "Action": [
    "es:*"
  ],
  "Resource": "arn:aws:es:us-east-1:123456789012:domain/my-domain/_opendistro/_sql"
}
```

マスターユーザーの変更

マスターユーザーの詳細を忘れた場合は、コンソール、AWS CLI、または configuration API を使用して再設定できます。

マスターユーザーを変更するには (コンソール)

https://aws.amazon.com にアクセスし、[Sign In to the Console] を選択します。
[分析] で、[Elasticsearch Service] を選択します。
ドメインを選択します。
[Actions (アクション)]、[Modify authentication (認証の変更)] の順に選択します。
[Set IAM role as master user (マスターユーザーとして IAM ロールを設定)] または [Create new master user (新しいマスターユーザーを作成)] を選択します。
- 以前に IAM マスターユーザーを使用していた場合、きめ細かなアクセスコントロールにより、指定した新しい IAM ARN に all_access ロールが再マッピングされます。
- 以前に内部ユーザーデータベースを使用していた場合、きめ細かなアクセスコントロールにより、新しいマスターユーザーが作成されます。新しいマスターユーザーを使用して、古いマスターユーザーを削除できます。
[Submit] を選択します。

追加のマスターユーザー

ドメインの作成時にマスターユーザーを指定しますが、必要に応じて、このマスターユーザーを使用して追加のマスターユーザーを作成できます。これには2つのオプションがあります。Kibana または REST API。

Kibana で [Security (セキュリティ)]、[Role Mappings (ロールマッピング)] の順に選択し、新しいマスターユーザーを all_access および security_manager ロールにマッピングします。

REST API を使用するには、以下のリクエストを送信します。


PUT _opendistro/_security/api/rolesmapping/all_access
{
  "backend_roles": [
    "arn:aws:iam::123456789012:role/fourth-master-user"
  ],
  "hosts": [],
  "users": [
    "master-user",
    "second-master-user",
    "arn:aws:iam::123456789012:user/third-master-user"
  ]
}


PUT _opendistro/_security/api/rolesmapping/security_manager
{
  "backend_roles": [
    "arn:aws:iam::123456789012:role/fourth-master-user"
  ],
  "hosts": [],
  "users": [
    "master-user",
    "second-master-user",
    "arn:aws:iam::123456789012:user/third-master-user"
  ]
}

これらのリクエストは現在のロールマッピングを置き換えるため、PUT リクエストに現在のすべてのロールを含めることができるように、最初に GET リクエストを実行します。REST API が特に役立つのは、Kibana にアクセスできず、IAM ロールを Amazon Cognito から all_access ロールにマッピングする場合です。

手動スナップショット

きめ細かなアクセスコントロールにより、手動スナップショットの取得がいくらか複雑になります。スナップショットリポジトリを登録するには (他のすべての目的に HTTP 基本認証を使用する場合でも)、「手動スナップショット前提条件」で定義されているように、manage_snapshots ロールを、TheSnapshotRole を引き受ける iam:PassRole アクセス許可を持つ IAM ロールにマッピングする必要があります。

次に、その IAM ロールを使用して、「手動スナップショットレポジトリの登録」に概説されているように、署名付きリクエストをドメインに送信します。

Integrations

Amazon ES でその他の AWS のサービスを使用する場合、それらのサービスに対する適切なアクセス許可を持つ IAM ロールを提供する必要があります。たとえば、Kinesis Data Firehose配信ストリームでは、多くの場合、と呼ばれる IAM ロールを使用しますfirehose_delivery_role。 Kibana で、きめ細かなアクセスコントロール用のロールを作成し、それに IAM ロールをマッピングします。この場合、新しいロールには以下のアクセス許可が必要です。


{
  "cluster_permissions": [
    "cluster_composite_ops",
    "cluster_monitor"
  ],
  "index_permissions": [{
    "index_patterns": [
      "firehose-index*"
    ],
    "allowed_actions": [
      "create_index",
      "manage",
      "crud"
    ]
  }]
}

アクセス許可は、各サービスが実行するアクションによって異なります。データのインデックスを作成する AWS IoT ルールまたは AWS Lambda 関数には、Kinesis Data Firehose と同様のアクセス許可が必要になる可能性がありますが、検索のみを実行する Lambda 関数では、より制限されたアクセス許可のセットを使用できます。

REST API の相違点

きめ細かなアクセスコントロールの REST API は、Elasticsearch バージョンによってわずかに異なります。PUT リクエストを行う前に、GET リクエストを行って、想定されるリクエスト本文を確認します。たとえば、_opendistro/_security/api/user への GET リクエストはすべてのユーザーを返すため、それらの結果を変更して使用して、有効な PUT リクエストを行うことができます。

Elasticsearch 6.x では、ユーザーの作成リクエストは以下のようになります。


PUT _opendistro/_security/api/user/new-user
{
  "password": "some-password",
  "roles": ["new-backend-role"]
}

Elasticsearch 7.x では、リクエストは以下のようになります。


PUT _opendistro/_security/api/user/new-user
{
  "password": "some-password",
  "backend_roles": ["new-backend-role"]
}

さらに、Elasticsearch 6.x では、テナントはロールのプロパティです。


GET _opendistro/_security/api/roles/all_access

{
  "all_access": {
    "cluster": ["UNLIMITED"],
    "tenants": {
      "admin_tenant": "RW"
    },
    "indices": {
      "*": {
        "*": ["UNLIMITED"]
      }
    },
    "readonly": "true"
  }
}

Elasticsearch 7.x では、それらは独自の URI が関連付けられたオブジェクトです。


GET _opendistro/_security/api/tenants

{
  "global_tenant": {
    "reserved": true,
    "hidden": false,
    "description": "Global tenant",
    "static": false
  }
}

7.x REST API のドキュメントについては、Open Distro for Elasticsearch のドキュメントを参照してください。

ヒント

内部ユーザーデータベースを使用する場合は、curl を使用してリクエストを行い、ドメインをテストできます。次のサンプルコマンドを試してください。


curl -XGET -u master-user:master-user-password 'domain-endpoint/_search'
curl -XGET -u master-user:master-user-password 'domain-endpoint/_opendistro/_security/api/user'

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

アイデンティティとアクセスの管理

監査ログ