翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
Amazon OpenSearch Service での Identity and Access Management
Amazon OpenSearch Service には、ドメインへのアクセスを制御する方法がいくつか用意されています。このトピックでは、さまざまなポリシータイプ、それぞれがやり取りする方法、および独自のカスタムポリシーを作成する方法を説明します。
重要
VPC サポートでは、 OpenSearch サービスアクセスコントロールに関する追加の考慮事項がいくつか導入されています。詳細については、「VPC ドメインのアクセスポリシーについて」を参照してください。
ポリシーのタイプ
OpenSearch サービスは、次の 3 種類のアクセスポリシーをサポートしています。
リソースベースのポリシー
ドメインを作成するときに、ドメインアクセスポリシーと呼ばれる場合があるリソースベースのポリシーを追加します。これらのポリシーは、ドメインのサブリソースでプリンシパルが実行するアクションを指定します (cross-cluster 検索を除く)。サブリソースには、 OpenSearch インデックス と APIs。Principal 要素は、アクセスを許可するアカウント、ユーザー、またはロールを指定します。Resource 要素は、これらのプリンシパルがアクセスできるサブリソースを指定します。
例えば、次のリソースベースのポリシーでは、test-domain のサブリソースへのフルアクセス (es:*) が test-user に付与されます。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::123456789012:user/test-user" ] }, "Action": [ "es:*" ], "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/*" } ] }
このポリシーには、2 つの重要な考慮事項が適用されます。
-
これらの権限はこのドメインのみに適用されます。他のドメインで同様のポリシーを作成しない限り、
test-userはtest-domainにしかアクセスできません。 -
Resource要素の末尾の/*は重要であり、リソースベースのポリシーがドメイン自体ではなく、ドメインのサブリソースにのみ適用されることを示します。リソースベースのポリシーでは、es:*アクションはes:ESHttp*と同等です。例えば、
test-userはインデックス (GET https://search-test-domain.us-west-1.es.amazonaws.com/test-index) に対してリクエストを行うことができますが、ドメインの設定を更新できません (POST https://es.us-west-1.amazonaws.com/2021-01-01/opensearch/domain/test-domain/config)。2 つのエンドポイント間の違いに注目してください。設定 API にアクセスするには ID ベースのポリシーが必要です。
ワイルドカードを追加することで、インデックス名の一部を指定できます。次の例では、commerce で始まるすべてのインデックスを特定しています。
arn:aws:es:us-west-1:987654321098:domain/test-domain/commerce*
この場合、ワイルドカードの意味は、commerce で始まる名前の test-domain のインデックスに test-user がリクエストを送信できるということです。
test-user をさらに制限するには、次のポリシーを適用することができます。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::123456789012:user/test-user" ] }, "Action": [ "es:ESHttpGet" ], "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/commerce-data/_search" } ] }
これにより、test-user は commerce-data インデックスに対する検索で、1 つのオペレーションのみを実行できます。ドメインのその他すべてのインデックスはアクセス不可となり、、test-user は、es:ESHttpPut または es:ESHttpPost アクションを使用する許可なしにドキュメントを追加あるいは変更できなくなります。
次に、パワーユーザーのロールを設定することができます。このポリシーは、power-user-role にインデックスのすべての URI に対する HTTP GET メソッドおよび PUT メソッドへのアクセスを付与します。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::123456789012:role/power-user-role" ] }, "Action": [ "es:ESHttpGet", "es:ESHttpPut" ], "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/commerce-data/*" } ] }
ドメインが VPC 内にあるか、きめ細かなアクセスコントロールを使用している場合は、オープンドメインアクセスポリシーを使用できます。それ以外の場合、ドメインアクセスポリシーには、プリンシパルまたは IP アドレスによる制限が含まれている必要があります。
使用できるすべてのアクションの詳細については、「ポリシーエレメントのリファレンス」を参照してください。データをより細かく制御するには、きめ細かなアクセスコントロールとともにオープンドメインアクセスポリシーを使用します。
アイデンティティベースのポリシー
各 OpenSearch サービスドメインの一部であるリソースベースのポリシーとは異なり、 AWS Identity and Access Management (IAM) サービスを使用して、アイデンティティベースのポリシーをユーザーまたはロールにアタッチします。リソースベースのポリシーと同様に、アイデンティティベースのポリシーは、サービスに誰がアクセスできるか、どのアクションキーを実行できるか、そして該当する場合には、これらのアクションを実行できるリソースを指定します。
これらを実行する実際の義務はないため、アイデンティティベースのポリシーはより一般的になる傾向があります。これにより、多くの場合、ユーザーが実行できる設定 API アクションのみ管理されます。これらのポリシーを設定したら、 OpenSearch サービスでリソースベースのポリシー (またはきめ細かなアクセスコントロール) を使用して、 OpenSearch インデックスと APIsへのアクセス権をユーザーに付与できます。
注記
AWS 管理AmazonOpenSearchServiceReadOnlyAccessポリシーを持つユーザーは、コンソールでクラスターのヘルスステータスを表示できません。クラスターのヘルスステータス (およびその他の OpenSearch データ) を表示できるようにするには、アクセスポリシーに es:ESHttpGetアクションを追加し、アカウントまたはロールにアタッチします。
アイデンティティベースのポリシーはユーザーあるいはロール (プリンシパル) にアタッチされるため、JSON はプリンシパルを指定しません。次のポリシーは、Describe および List で始まるアクションへのアクセスを付与します。このアクションの組み合わせはドメインの設定への読み取り専用のアクセスを提供しますが、ドメイン自体に保存されたデータへのアクセスは提供しません。
{ "Version": "2012-10-17", "Statement": [ { "Action": [ "es:Describe*", "es:List*" ], "Effect": "Allow", "Resource": "*" } ] }
管理者は、 OpenSearch サービスおよびすべてのドメインに保存されているすべてのデータへのフルアクセスを持つ場合があります。
{ "Version": "2012-10-17", "Statement": [ { "Action": [ "es:*" ], "Effect": "Allow", "Resource": "*" } ] }
ID ベースのポリシーでは、タグを使用して設定 API へのアクセスを制御できます。例えば、次のポリシーでは、ドメインに team:devops タグがある場合、アタッチされたプリンシパルがドメインの設定を表示および更新できるようにします。
{ "Version": "2012-10-17", "Statement": [{ "Action": [ "es:UpdateDomainConfig", "es:DescribeDomain", "es:DescribeDomainConfig" ], "Effect": "Allow", "Resource": "*", "Condition": { "ForAnyValue:StringEquals": { "aws:ResourceTag/team": [ "devops" ] } } }] }
タグを使用して OpenSearch API へのアクセスを制御することもできます。 OpenSearch API のタグベースのポリシーは、HTTP メソッドにのみ適用されます。例えば、次のポリシーでは、ドメインに environment:production タグがある場合、アタッチされたプリンシパルが GET および PUT リクエストを OpenSearch API に送信できます。
{ "Version": "2012-10-17", "Statement": [{ "Action": [ "es:ESHttpGet", "es:ESHttpPut" ], "Effect": "Allow", "Resource": "*", "Condition": { "ForAnyValue:StringEquals": { "aws:ResourceTag/environment": [ "production" ] } } }] }
OpenSearch API をよりきめ細かく制御するには、きめ細かなアクセスコントロール の使用を検討してください。
注記
タグベースのポリシーに 1 つ以上の OpenSearch APIs を追加した後、ドメインに変更を有効にするには、1 つのタグオペレーション (タグの追加、削除、変更など) を実行する必要があります。タグベースのポリシーに OpenSearch API オペレーションを含めるには、サービスソフトウェア R20211203 以降を使用している必要があります。
OpenSearch サービスは、 API ではなく、設定 API の RequestTagおよび TagKeys グローバル条件キーをサポートします OpenSearch 。これらの条件は、リクエスト内にタグを含む API 呼び出し (CreateDomain、AddTags、および RemoveTags など) にのみ適用されます。次のポリシーでは、アタッチされたプリンシパルがドメインを作成できるようにしますが、それは、team:it タグをリクエストに含めた場合のみです。
{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": [ "es:CreateDomain", "es:AddTags" ], "Resource": "*", "Condition": { "StringEquals": { "aws:RequestTag/team": [ "it" ] } } } }
アクセス制御でタグを使用する方法とリソースベースのポリシーとアイデンティティベースのポリシーの違いについての詳細は、「IAM ユーザーガイド」を参照してください。
IP ベースのポリシー
IP ベースのポリシーは、1 つ以上の IP アドレスあるいは CIDR ブロックにドメインへのアクセスを制限します。技術的には、IP ベースのポリシーは異なるタイプのポリシーではありません。代わりに、これらのポリシーは、匿名のプリンシパルを指定し、特別な Condition 要素を含む、リソースベースのポリシーです。
IP ベースのポリシーの主な特徴は、 OpenSearch サービスドメインへの署名なしリクエストを許可することです。これにより、curl
注記
ドメインで VPC アクセスを有効にすると、IP ベースのポリシーを設定することはできません。代わりに、どの IP アドレスがドメインにアクセスできるかを制御するセキュリティグループを使用できます。詳細については、「VPC ドメインのアクセスポリシーについて」を参照してください。
以下のポリシーは、指定された IP 範囲からのすべての HTTP リクエストが test-domain にアクセスする許可を付与します。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": [ "es:ESHttp*" ], "Condition": { "IpAddress": { "aws:SourceIp": [ "192.0.2.0/24" ] } }, "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/*" } ] }
ドメインにパブリックエンドポイントがあり、きめ細かなアクセスコントロールを使用しない場合は、IAM プリンシパルと IP アドレスを組み合わせることをお勧めします。このポリシーでは、指定した IP 範囲からのリクエストの場合にのみ、test-user HTTP アクセスを許可します。
{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::987654321098:user/test-user" ] }, "Action": [ "es:ESHttp*" ], "Condition": { "IpAddress": { "aws:SourceIp": [ "192.0.2.0/24" ] } }, "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/*" }] }
OpenSearch サービスリクエストの作成と署名
完全にオープンなリソースベースのアクセスポリシーを設定しても、 OpenSearch サービス設定 API へのすべてのリクエストに署名する必要があります。ポリシーで IAM ロールまたはユーザーを指定する場合、 OpenSearch APIsへのリクエストも Signature Version AWS 4 を使用して署名する必要があります。署名メソッドは API によって異なります。
-
OpenSearch サービス設定 API を呼び出すには、いずれかの AWS SDKs
を使用することをお勧めします。SDK を使用するほうが、独自のリクエストを作成し署名するよりも、プロセスが簡素化し、大幅な時間の節約ができます。API エンドポイント設定には次の形式を使用します。 es.region.amazonaws.com/2021-01-01/例えば、次のリクエストは、
moviesドメインの設定を変更しますが、自分で署名する必要があります (お勧めしません)。POST https://es.us-east-1.amazonaws.com/2021-01-01/opensearch/domain/movies/config { "ClusterConfig": { "InstanceType": "c5.xlarge.search" } }Boto 3
などのいずれかの SDK を使用する場合、SDK はリクエスト署名を自動的に処理します。 import boto3 client = boto3.client(es) response = client.update_domain_config( DomainName='movies', ClusterConfig={ 'InstanceType': 'c5.xlarge.search' } )Java コードの例については、「Amazon OpenSearch Service を操作するための AWS SDKの使用」を参照してください。
-
OpenSearch APIs を呼び出すには、独自のリクエストに署名する必要があります。 OpenSearch APIs形式を使用します。
domain-id.region.es.amazonaws.com例えば、次のリクエストは、thor の
moviesインデックスを検索します。GET https://my-domain.us-east-1.es.amazonaws.com/movies/_search?q=thor
注記
このサービスは、署名バージョン 4 で署名された HTTP POST リクエストの URL で渡されるパラメータを無視します。
複数のポリシーが衝突する場合
複数のポリシーが同意しない、あるいはユーザーを明示的に指定しない場合、困難が生じます。IAM ユーザーガイドの「IAM の詳細を理解する」では、ポリシーの評価ロジックの適切な概要が説明されています。
-
デフォルトでは、すべてのリクエストが拒否されます。
-
明示的な許可はこのデフォルトに優先します。
-
明示的な拒否はすべての許可に上書きされます。
例えば、リソースベースのポリシーによってドメインサブリソース ( OpenSearch インデックスまたは API) へのアクセスが許可されているが、アイデンティティベースのポリシーによってアクセスが拒否された場合、アクセスは拒否されます。アイデンティティベースのポリシーとリソースベースのポリシーによってユーザーがアクセス許可を持つべきかを指定いない場合、アクセスは許可されます。ドメインサブリソースのすべての結果の概要における交差するポリシーの図を以下で参照してください。
| リソースベースのポリシーで許可 | リソースベースのポリシーで拒否 | リソースベースのポリシーで許可あるいは拒否されない | |
|---|---|---|---|
| Allowed in identity-based policy |
許可 |
拒否 | 許可 |
| Denied in identity-based policy | 拒否 | 拒否 | 拒否 |
| Neither allowed nor denied in identity-based policy | 許可 | 拒否 | 拒否 |
ポリシーエレメントのリファレンス
OpenSearch サービスは、IAM ポリシー要素リファレンス のほとんどのポリシー要素をサポートしますが、 は除きますNotPrincipal。次の表は、最も一般的なエレメントを示しています。
| JSON ポリシーエレメント | [概要] |
|---|---|
Version |
ポリシー言語の最新バージョンは |
Effect |
このエレメントは、指定されたアクションへのアクセスをステートメントが許可するか拒否するかを指定します。有効な値は |
Principal |
この要素は、リソースへのアクセスを許可または拒否する AWS アカウント または IAM ロールまたはユーザーを指定し、いくつかの形式を取ることができます。
重要
|
Action
|
OpenSearch サービスは OpenSearch HTTP メソッドの 特定の 使用可能なすべてのアクションのリストと、ドメインサブリソース (
もちろん、次のように、制限がより緩和されたリソース要素のアクションを含めることもできます。
アクションとリソースのペアリングについての詳細は、テーブルの |
Condition |
OpenSearch サービスは、IAM ユーザーガイド AWS のグローバル条件コンテキストキーで説明されているほとんどの条件をサポートします。注目すべき例外には、 OpenSearch サービスがサポートしていない IP ベースのポリシーを設定する場合、次に示すように、IP アドレスまたは CIDR ブロックを条件として指定します。 で説明したようにアイデンティティベースのポリシー、、 |
Resource |
OpenSearch サービスは、次の 3 つの基本的な方法で
どのアクションがリソースレベルのアクセス権限をサポートするかの詳細については、このテーブルの |
詳細オプションと API に関する考慮事項
OpenSearch サービスにはいくつかの高度なオプションがあり、そのうちの 1 つはアクセスコントロールに影響しますrest.action.multi.allow_explicit_index。デフォルト設定の true では、特定の状況下でユーザーがサブリソースへのアクセス権限を回避することが許可されます。
例えば、次のリソースベースのポリシーを考えます。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::123456789012:user/test-user" ] }, "Action": [ "es:ESHttp*" ], "Resource": [ "arn:aws:es:us-west-1:987654321098:domain/test-domain/test-index/*", "arn:aws:es:us-west-1:987654321098:domain/test-domain/_bulk" ] }, { "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::123456789012:user/test-user" ] }, "Action": [ "es:ESHttpGet" ], "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/restricted-index/*" } ] }
このポリシーは、 test-indexと OpenSearch 一括 API へのtest-userフルアクセスを許可します。また、GET への restricted-index リクエストを許可します。
次のインデックスリクエストは、見てわかるように、アクセス権限エラーによって失敗します。
PUT https://search-test-domain.us-west-1.es.amazonaws.com/restricted-index/movie/1 { "title": "Your Name", "director": "Makoto Shinkai", "year": "2016" }
インデックス API とは異なり、バルク API では、単一の呼び出しで多くのドキュメントの作成、更新、削除を実行できます。多くの場合、これらのオペレーションはリクエスト URL ではなく、リクエストの本文で指定します。 OpenSearch サービスは URLs を使用してドメインサブリソースへのアクセスを制御するため、 は実際に一括 API を使用して に変更を加えるtest-userことができますrestricted-index。ユーザーにはインデックスで POST アクセス権限が欠如していますが、次のリクエストは成功します。
POST https://search-test-domain.us-west-1.es.amazonaws.com/_bulk { "index" : { "_index": "restricted-index", "_type" : "movie", "_id" : "1" } } { "title": "Your Name", "director": "Makoto Shinkai", "year": "2016" }
このような状況では、アクセスポリシーはその目的達成に失敗します。ユーザーがこれらの制限を回避することを防ぐためには、rest.action.multi.allow_explicit_index を false に変更できます。この値が false の場合、リクエストボディでインデックス名を指定するバルク、mget、および msearch API へのすべての呼び出し動作は停止します。つまり、_bulk への呼び出しは機能しなくなりますが、test-index/_bulk への呼び出しは動作します。この 2 番目のエンドポイントにはインデックス名が含まれるため、リクエストボディにそれを指定する必要はありません。
OpenSearch ダッシュボードはmgetとmsearchに大きく依存しているため、この変更後に正しく動作する可能性はほとんどありません。部分的な解決策としては、rest.action.multi.allow_explicit_index を true のまま残して、特定のユーザーが 1 つ以上の API にアクセスすることを拒否します。
この設定の変更については、「高度なクラスター設定」を参照してください。
同様に、以下のリソースベースのポリシーには 2 つの小さな問題があります。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:user/test-user" }, "Action": "es:ESHttp*", "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/*" }, { "Effect": "Deny", "Principal": { "AWS": "arn:aws:iam::123456789012:user/test-user" }, "Action": "es:ESHttp*", "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/restricted-index/*" } ] }
-
明示的な拒否にも関わらず、
test-userがGET https://search-test-domain.us-west-1.es.amazonaws.com/_all/_searchやGET https://search-test-domain.us-west-1.es.amazonaws.com/*/_searchなどの呼び出しを実行して、restricted-indexのドキュメントにアクセスできることです。 -
Resourceエレメントレファレンスrestricted-index/*により、test-userはインデックスのドキュメントに直接アクセスする権限がありません。しかし、ユーザーにはインデックス全体を削除する権限があります。アクセスと削除を防ぐには、このポリシーでrestricted-index*を指定する必要があります。
広範囲な許可と一部の拒否を混合するよりは、最小限の権限の原則を守り、タスクを実行するために必要なアクセス権限のみを付与することが最も安全なアプローチです。個々のインデックスまたは OpenSearchオペレーションへのアクセスの制御の詳細については、「」を参照してくださいAmazon サービスのきめ細かいアクセス制御 OpenSearch 。
重要
* ワイルドカードを指定すると、ドメインへの匿名アクセスが可能になります。ワイルドカードを使用することはお勧めしません。さらに、以下のポリシーを注意深く調べて、広範なアクセスを許可していないことを確認してください。
-
関連付けられた AWS プリンシパルにアタッチされたアイデンティティベースのポリシー (IAM ロールなど）
-
関連付けられたリソースにアタッチされた AWS リソースベースのポリシー ( AWS Key Management Service KMS キーなど）
アクセスポリシーの設定
-
Service でリソースベースおよび IP ベースのポリシーを作成または変更する手順については OpenSearch 、「」を参照してくださいアクセスポリシーの設定。
-
IAM でアイデンティティベースのポリシーを作成または変更する方法については、IAM ユーザーガイドの「IAM ポリシーの作成」を参照してください 。
追加のサンプルポリシー
この章には多くのサンプルポリシーが含まれていますが、 AWS アクセスコントロールは複雑なテーマであり、例として理解するのが最善です。詳細については、IAM ユーザーガイドの「IAM アイデンティティベースのポリシーの例」を参照してください。
