「翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。」
でのきめ細かなアクセスコントロールAmazon Elasticsearch Service
きめ細かなアクセスコントロールは、 のデータへのアクセスをコントロールする追加の方法を提供します。Amazon Elasticsearch Service. たとえば、リクエスト者によっては、検索で 1 つのインデックスのみから結果が返されるようにしたい場合があります。ドキュメント内の特定のフィールドを非表示にしたい場合や、特定のドキュメントをまとめて除外したい場合もあります。きめ細かなアクセスコントロールには、以下の機能があります。
-
ロールベースアクセスコントロール
-
インデックスレベル、ドキュメントレベル、フィールドレベルのセキュリティ
-
Kibana マルチテナンシー
-
Elasticsearch および Kibana の HTTP 基本認証
トピック
全体像: きめ細かなアクセスコントロールと Amazon ES セキュリティ
Amazon Elasticsearch Service セキュリティには 3 つの主要なレイヤーがあります。
- ネットワーク
-
最初のセキュリティレイヤーはネットワークであり、リクエストが 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 へのアクセス、1 つは index1 への読み取り専用アクセス、もう 1 つは index2 への書き込みアクセスを提供します。 または、これらのすべてのアクセス許可を 1 つのロールに含めることもできます。
ユーザーは、Elasticsearch クラスターに対してリクエストを行うユーザーまたはアプリケーションです。ユーザーは、リクエスト時に指定する認証情報— IAM アクセスキーまたはユーザー名とパスワード—を持っています。のきめ細かなアクセスコントロールで、ドメインを設定するときにAmazon Elasticsearch Serviceマスターユーザー用にいずれかのアクセスコントロールを選択します。マスターユーザーはクラスターに対する完全なアクセス許可を持ち、ロールとロールマッピングを管理します。
-
マスターユーザー用に IAM を選択した場合、クラスターに対するすべてのリクエストは AWS 署名バージョン 4 を使用して署名される必要があります。サンプルコードについては、「」を参照してください。Amazon Elasticsearch Service への HTTP リクエストの署名.
複数のクラスターで同じユーザーを使用する場合、IAM を使用して Kibana にアクセスする場合、または署名バージョン 4 をサポートする Amazon Cognito クライアントがある場合は、Elasticsearch をお勧めします。
-
内部ユーザーデータベースを選択した場合は、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 を使用する場合は、Amazon CognitoKibana の 認証 を使用して Kibana にアクセスします。それ以外の方法では、Kibana の「機能しない」サインインページが表示されます。」を参照してください。Limitations.
認証では、ID プールから引き受けたいずれかのロールが、マスターユーザーに指定した IAM ロールと一致する必要があります。Amazon Cognitoこの設定の詳細については、「(オプション) きめ細かなアクセスの設定」および「チュートリアル: IAM マスターユーザーと Amazon Cognito.」を参照してください。
-
内部ユーザーデータベースを使用する場合は、マスターユーザー名とパスワードを使用して Kibana にサインインできます。HTTPS 経由で Kibana にアクセスする必要があります。Kibana の Amazon Cognito と SAML 認証はいずれも、このログイン画面を置き換えます。
この設定の詳細については、「」を参照してください。チュートリアル: 内部ユーザーデータベースと HTTP 基本認証.
-
SAML 認証を使用することを選択した場合は、外部 ID プロバイダーからの認証情報を使用してサインインできます。詳細については、「」を参照してください。Kibana の SAML 認証.
アクセス権限の管理
主要なコンセプト」で説明しているように、ロール、ユーザー、マッピングを使用してきめ細かなアクセスコントロールのアクセス許可を管理します。このセクションでは、これらのリソースを作成して適用する方法について説明します。これらの操作を実行するには、マスターユーザーとして Kibana にサインインすることをお勧めします。
ロールの作成
Kibana、または REST API の _opendistro/_security オペレーションを使用して、きめ細かなアクセスコントロール用の新しいロールを作成できます。詳細については、Open Distro for 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 のドキュメント
フィールドのマスキング
フィールドのマスキングは、フィールドレベルのセキュリティに代わるもので、フィールド内のデータを完全に削除するのではなく、匿名化できます。ロールを作成するときに、マスクするフィールドのリストを追加します。フィールドのマスキングは、検索時にフィールドの内容を表示できるかどうか.に影響します。
標準のマスキングをフィールドに適用すると、Amazon ES では安全でランダムなハッシュが使用されるため、不正確な集計結果が発生する可能性があります。マスクされたフィールドで集計を実行するには、代わりにパターンベースのマスキングを使用します。
ユーザーの作成
内部ユーザーデータベースを有効にした場合、Kibana、または REST API の _opendistro/_security オペレーションを使用してユーザーを作成できます。詳細については、Open Distro for Elasticsearch のドキュメント
マスターユーザーに IAM を選択した場合は、Kibana のこの部分は無視してください。代わりに、IAM ユーザーと IAM ロールを作成します。詳細については、「」を参照してください。IAM ユーザーガイド.
ユーザーへのロールのマッピング
ロールのマッピングは、きめ細かなアクセスコントロールの最も重要な側面です。きめ細かなアクセスコントロールには、使用の開始に役立ついくつかの事前定義されたロールがありますが、ロールをユーザーにマッピングしない限り、クラスターに対するすべてのリクエストはアクセス許可エラーという結果になります。
外部 ID とも呼ばれるバックエンドロールは、ロールをユーザーにマッピングする別の方法を提供します。同じロールを多数の異なるユーザーにマッピングするのではなく、ロールを 1 つのバックエンドロールにマッピングしてから、すべてのユーザーがそのバックエンドロールを持つようにできます。バックエンドロールは、IAM ロールまたは任意の文字列にすることができます。
-
[ARNsユーザーAmazon Cognito] セクションで、ユーザー、IAM ユーザー 、および ユーザー文字列を指定します。Cognito ユーザー文字列の形式は です。
Cognito/.user-pool-id/username -
[ARNs外部 ID] セクションで、バックエンドロールと 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 に移動してサインインします。
-
右上のユーザーアイコンを選択します。
-
[Switch Tonants] を選択します。
-
可視化またはダッシュボードを作成する前に、テナントを確認します。他のすべての Kibana ユーザーと作業を共有する場合は、[グローバル.] を選択します。一部の Kibana ユーザーと作業を共有するには、別の共有テナントを選択します。それ以外の場合は、[Private (プライベート).] を選択します。
推奨される設定
きめ細かなアクセスコントロールは他のセキュリティ機能と連携するため、ここでは、ほとんどのユースケースで適切に機能するきめ細かなアクセスコントロールの設定を複数お勧めします。
| 説明 | マスターユーザー | ドメインアクセスポリシー |
|---|---|---|
|
Elasticsearch への呼び出しには IAM 認証情報を使用し、Kibana へのアクセスには APIsSAML 認証を使用します。Kibana または REST API を使用して、きめ細かなアクセスコントロールのロールを管理します。 |
IAM ユーザーまたはロール |
|
|
Elasticsearch への呼び出しには、IAM 認証情報または基本認証を使用します。APIs Kibana または REST API を使用して、きめ細かなアクセスコントロールのロールを管理します。 この設定は、特に基本認証のみをサポートする Elasticsearch クライアントがある場合に、非常に柔軟な方法を提供します。 既存の ID プロバイダーがある場合は、SAML 認証を使用して Kibana にアクセスします。それ以外の場合は、内部ユーザーデータベースの Kibana ユーザーを管理します。 |
ユーザー名とパスワード |
|
|
Elasticsearch への呼び出しには IAM 認証情報を使用し、Kibana にアクセスするには APIs を使用します。Amazon CognitoKibana または REST API を使用して、きめ細かなアクセスコントロールのロールを管理します。 |
IAM ユーザーまたはロール |
|
|
Elasticsearch への呼び出しに IAM 認証情報を使用し、Kibana へのほとんどのアクセスをブロックします。APIsREST API を使用して、きめ細かなアクセスコントロールのロールを管理します。 |
IAM ユーザーまたはロール |
|
チュートリアル: IAM マスターユーザーと Amazon Cognito
このチュートリアルでは、一般的なユースケースとして、Kibana の Amazon Cognito 認証を受ける IAM マスターユーザーについて説明します。これらのステップでは、認証に Amazon Cognito ユーザープールを使用しますが、この同じ基本プロセスは、異なるユーザーに異なる IAM ロールを割り当てることを可能にする Cognito 認証プロバイダーに対して機能します。
このチュートリアルでは、マスターユーザー用と制限付きユーザー用の 2 つの既存の IAM ロールがあることを前提としています。ロールが 2 つない場合は、作成します.
きめ細かなアクセスコントロールの使用を開始するには
-
以下の設定でドメインを作成します。
-
Elasticsearch 7.8
-
パブリックアクセス
-
IAM ロールをマスターユーザーとして有効にしたきめ細かなアクセスコントロール (このチュートリアルの残りの部分では
IAMMasterUserRole -
以下のアクセスポリシー:
{ "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という名前を付け、[IAMMasterUserRoleIAM ロール] ドロップダウンリストで を選択してから、[グループの作成] を選択します。 -
limited-user-groupを使用するIAMLimitedUserRole. という名前の別のグループを作成します。 -
master-user-groupを選択し、[ユーザーの追加] を選択してから、master-user. を追加します。 -
limited-user-groupを選択し、[ユーザーの追加] を選択してから、limited-user. を追加します。 -
[アプリクライアントの設定] を選択し、ドメインのアプリクライアント ID をメモします。
-
フェデレーティッドアイデンティティ] を選択し、ID プールを選択してから、[ID プールの編集.] を選択します。
-
認証プロバイダー] を展開し、ドメインのユーザープール ID とアプリクライアント ID を見つけて、[デフォルトロールを使用] を [トークンからロールを選択する.] に変更します。
-
ロール解決」で、[拒否.] を選択します。この設定では、認証後に IAM ロールを受け取るには、ユーザーがグループに属している必要があります。
-
変更の保存.] を選択します。
-
Kibana に移動します。
-
でサインインします。
master-user. -
Try our sample data (サンプルデータを試す).] を選択します。
-
サンプルのフライトデータを追加します。
-
[Security]、[Roles]、[Create role] の順に選択します。
-
ロールに という名前を付けます。
new-role. -
インデックスのアクセス許可の場合は、インデックスパターンに
kibana_sample_data_fli*を指定します。 -
アクショングループには、[read (読み取り)] を選択します。
-
[Document Level Security Query (ドキュメントレベルセキュリティクエリ)] で、次のクエリを指定します。
{ "match": { "FlightDelay": true } } -
フィールドレベルのセキュリティの場合は、[Exclude fields (フィールドの除外)] を選択し、
FlightNumを指定します。 -
[Anonymize fields (フィールドの匿名化)] で、
Destを指定します。 -
作成.] を選択します。
-
[マッピングされたユーザー]、[マッピングの管理] の順に選択します。次に、
IAMLimitedUserRoleの ARN を外部 ID として追加し、[マップ] を選択します。 -
ロールのリストに戻り、[kibana_user] を選択します。[マッピングされたユーザー]、[マッピングの管理] の順に選択します。次に、
IAMLimitedUserRoleの ARN を外部 ID として追加し、[マップ] を選択します。 -
新しいプライベートブラウザウィンドウで、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 基本認証という、別の一般的なユースケースについて説明します。
きめ細かなアクセスコントロールの使用を開始するには
-
以下の設定でドメインを作成します。
-
Elasticsearch 7.9
-
パブリックアクセス
-
内部ユーザーデータベース内のマスターユーザーによるきめ細かなアクセスコントロール (このチュートリアルの残りの部分では
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 users (内部ユーザー)]、[Create internal user (内部ユーザーの作成)] の順に選択します。
-
ユーザーに
new-userという名前を付け、パスワードを指定します。次に [作成.] を選択します。 -
ロール]、[ロールの作成.] を選択します。
-
ロールに という名前を付けます。
new-role. -
インデックスのアクセス許可の場合は、インデックスパターンに
kibana_sample_data_fli*を指定します。 -
アクショングループの場合は、[read (読み取り)] を選択します。
-
[Document Level Security Query (ドキュメントレベルセキュリティクエリ)] で、次のクエリを指定します。
{ "match": { "FlightDelay": true } } -
フィールドレベルのセキュリティの場合は、[Exclude fields (フィールドの除外)] を選択し、
FlightNumを指定します。 -
[Anonymize fields (フィールドの匿名化)] で、
Destを指定します。 -
作成.] を選択します。
-
[マッピングされたユーザー]、[マッピングの管理] の順に選択します。次に、
new-userを [ユーザー] に追加し、[マップ] を選択します。 -
ロールのリストに戻り、[kibana_user] を選択します。[マッピングされたユーザー]、[マッピングの管理] の順に選択します。次に、
new-userを [ユーザー] に追加し、[マップ] を選択します。 -
新しいプライベートブラウザウィンドウで、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ロールが再マッピングされます。 -
以前に内部ユーザーデータベースを使用していた場合、きめ細かなアクセスコントロールにより、新しいマスターユーザーが作成されます。新しいマスターユーザーを使用して、古いマスターユーザーを削除できます。
-
内部ユーザーデータベースから IAM マスターユーザーへの切り替えは、内部ユーザーデータベースからユーザーを削除 しません。代わりに、HTTP 基本認証を無効にするだけです。内部ユーザーデータベースから手動でユーザーを削除するか、HTTP 基本認証を再有効化する必要が生じた場合に備えて手動で保持します。
-
-
Submit.] を選択します。
追加のマスターユーザー
ドメインの作成時にマスターユーザーを指定しますが、必要に応じて、このマスターユーザーを使用して追加のマスターユーザーを作成できます。Kibana または REST API の 2 つのオプションがあります。
-
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" ] }これらのリクエストは現在のロールマッピングを置き換えるため、
GETリクエストに現在のすべてのロールを含めることができるように、最初にPUTリクエストを実行します。REST API が特に役立つのは、Kibana にアクセスできず、IAM ロールを Amazon Cognito からall_accessロールにマッピングする場合です。
手動スナップショット
きめ細かなアクセスコントロールにより、手動スナップショットの取得がいくらか複雑になります。スナップショットリポジトリを登録するには—他のすべての目的に HTTP 基本認証を使用する場合でも—、manage_snapshots ロールを iam:PassRole を引き受けるための TheSnapshotRole アクセス許可を持つ IAM ロールにマッピングする必要があります。詳細については、「手動スナップショット前提条件」を参照してください。
次に、その IAM ロールを使用して、「」に概説されているように、署名付きリクエストをドメインに送信します。手動スナップショットレポジトリの登録.
Integrations
で他の AWS のサービスを使用する場合は、それらのサービスの IAM ロールを適切なアクセス許可で提供する必要があります。Amazon ESたとえば、Kinesis Data Firehose
配信ストリームでは、多くの場合、firehose_delivery_role という IAM ロールが使用されます。 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 リクエストを行って、想定されるリクエスト本文を確認します。たとえば、GET への _opendistro/_security/api/user リクエストはすべてのユーザーを返すため、それらの結果を変更して使用して、有効な PUT リクエストを行うことができます。
6.Elasticsearchx では、ユーザーの作成リクエストは次のようになります。
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 } }
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'
