翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon OpenSearch Service での Identity and Access Management
Amazon OpenSearch Service には、ドメインへのアクセスを制御するいくつかの方法が用意されています。このトピックでは、さまざまなポリシータイプ、それぞれがやり取りする方法、および独自のカスタムポリシーを作成する方法を説明します。
**重要**
VPC は OpenSearch Service のアクセス制御へのいくつかの追加考慮事項の導入をサポートしています。詳細については、「[VPC ドメインのアクセスポリシーについて](vpc.md#vpc-security)」を参照してください。
## ポリシーのタイプ
OpenSearch Service はアクセスポリシーの 3 つのタイプをサポートしています。
+ [リソースベースのポリシー](#ac-types-resource)
+ [アイデンティティベースのポリシー](#ac-types-identity)
+ [IP ベースのポリシー](#ac-types-ip)
### リソースベースのポリシー
ドメインを作成するときに、ドメインアクセスポリシーと呼ばれる場合があるリソースベースのポリシーを追加します。これらのポリシーは、ドメインの*サブリソース*でプリンシパルが実行するアクションを指定します ([cross-cluster 検索](cross-cluster-search.md#cross-cluster-search-walkthrough)を除く)。サブリソースには、OpenSearch インデックスおよび API が含まれます。IAM の [Principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) JSON ポリシー要素は、アクセスを許可するアカウント、ユーザー、またはロール (プリンシパル) を指定します。[Resource](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_resource.html) JSON ポリシー要素は、これらのプリンシパルがアクセスできるサブリソースを指定します。
例えば、次のリソースベースのポリシーでは、`test-domain` のサブリソースへのフルアクセス (`es:*`) が `test-user` に付与されます。
------
#### [ JSON ]
****
```
{
"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 ベースのポリシー](#ac-types-identity)が必要です。
ワイルドカードを追加することで、インデックス名の一部を指定できます。次の例では、`commerce` で始まるすべてのインデックスを特定しています。
```
arn:aws:es:us-west-1:987654321098:domain/test-domain/commerce*
```
この場合、ワイルドカードの意味は、`commerce` で始まる名前の `test-domain` のインデックスに `test-user` がリクエストを送信できるということです。
`test-user` をさらに制限するには、次のポリシーを適用することができます。
------
#### [ JSON ]
****
```
{
"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 メソッドへのアクセスを付与します。
------
#### [ JSON ]
****
```
{
"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 アドレスによる制限が含まれている必要があります。
使用できるすべてのアクションの詳細については、「[ポリシーエレメントのリファレンス](#ac-reference)」を参照してください。データをより細かく制御するには、[きめ細かなアクセスコントロール](fgac.md)とともにオープンドメインアクセスポリシーを使用します。
### アイデンティティベースのポリシー
各 OpenSearch Service ドメインの一部であるリソースベースのポリシーとは異なり、 AWS Identity and Access Management (IAM) サービスを使用してアイデンティティベースのポリシーをユーザーまたはロールにアタッチします。[リソースベースのポリシー](#ac-types-resource)と同様に、アイデンティティベースのポリシーは、サービスに誰がアクセスできるか、どのアクションキーを実行できるか、そして該当する場合には、これらのアクションを実行できるリソースを指定します。
これらを実行する実際の義務はないため、アイデンティティベースのポリシーはより一般的になる傾向があります。これにより、多くの場合、ユーザーが実行できる設定 API アクションのみ管理されます。これらのポリシーの配置が完了したら、OpenSearch Service でリソースベースのポリシー (または[きめ細かなアクセスコントロール](fgac.md)) を使用して、OpenSearch インデックスおよび API へのアクセスをユーザーに提供できます。
**注記**
AWS 管理`AmazonOpenSearchServiceReadOnlyAccess`ポリシーを持つユーザーは、 コンソールでクラスターのヘルスステータスを表示できません。これらのユーザーがヘルスステータス (および他の OpenSearch データ) を確認できるようにするには、アクセスポリシーに `es:ESHttpGet` アクションを追加し、これをユーザーのアカウントまたはロールにアタッチします。
アイデンティティベースのポリシーはユーザーあるいはロール (プリンシパル) にアタッチされるため、JSON はプリンシパルを指定しません。次のポリシーは、`Describe` および `List` で始まるアクションへのアクセスを付与します。このアクションの組み合わせはドメインの設定への読み取り専用のアクセスを提供しますが、ドメイン自体に保存されたデータへのアクセスは提供しません。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"es:Describe*",
"es:List*"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
```
------
管理者には、OpenSearch Service およびすべてのドメインに保存された全データへのフルアクセス権がある場合があります。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"es:*"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
```
------
ID ベースのポリシーでは、タグを使用して設定 API へのアクセスを制御できます。例えば、次のポリシーでは、ドメインに `team:devops` タグがある場合、アタッチされたプリンシパルがドメインの設定を表示および更新できるようにします。
------
#### [ JSON ]
****
```
{
"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 に送信できます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Action": [
"es:ESHttpGet",
"es:ESHttpPut"
],
"Effect": "Allow",
"Resource": "*",
"Condition": {
"ForAnyValue:StringEquals": {
"aws:ResourceTag/environment": [
"production"
]
}
}
}]
}
```
------
OpenSearch API をよりきめ細かく制御するには、[きめ細かいアクセス制御](fgac.md) の使用を検討してください。
**注記**
1 つ以上の OpenSearch API をタグベースのポリシーに追加した後、変更をドメインで有効にするには、単一の [タグオペレーション](managedomains-awsresourcetagging.md) (タグの追加、削除、変更など) を実行する必要があります。タグベースのポリシーに OpenSearch API オペレーションを含めるには、サービスソフトウェア R20211203 以降を使用している必要があります。
OpenSearch サービスは、OpenSearch API ではなく、設定 API の `RequestTag` および `TagKeys` グローバル条件キーをサポートします。これらの条件は、リクエスト内にタグを含む API 呼び出し (`CreateDomain`、`AddTags`、および `RemoveTags` など) にのみ適用されます。次のポリシーでは、アタッチされたプリンシパルがドメインを作成できるようにしますが、それは、`team:it` タグをリクエストに含めた場合のみです。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": [
"es:CreateDomain",
"es:AddTags"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestTag/team": [
"it"
]
}
}
}
}
```
------
アクセスコントロールにタグを使用する方法と、リソースベースのポリシーとアイデンティティベースのポリシーの違いの詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可で属性に基づいてアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。
### IP ベースのポリシー
IP ベースのポリシーは、1 つ以上の IP アドレスあるいは CIDR ブロックにドメインへのアクセスを制限します。技術的には、IP ベースのポリシーは異なるタイプのポリシーではありません。これらのポリシーは、匿名のプリンシパルを指定し、特別な Condition を含む、リソースベースのポリシーです。詳細については、「*IAM ユーザーガイド*」の「[IAM JSON ポリシー要素 Condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)」を参照してください。
IP ベースのポリシーの最大の特徴は、OpenSearch Service ドメインへの署名なしのリクエストを許可することです。これにより、[curl](https://curl.haxx.se/) や [OpenSearch Dashboards](dashboards.md) などのクライアントを使用したり、プロキシサーバーを介してドメインにアクセスしたりすることができます。詳細については[プロキシを使用して Dashboards から OpenSearch Service にアクセスする](dashboards.md#dashboards-proxy)を参照してください。
**注記**
ドメインで VPC アクセスを有効にすると、IP ベースのポリシーを設定することはできません。代わりに、どの IP アドレスがドメインにアクセスできるかを制御する `security groups` を使用できます。詳細については、以下の各トピックを参照してください。
[VPC ドメインのアクセスポリシーについて](vpc.md#vpc-security)
*「Amazon VPC ユーザーガイド*」の[「セキュリティグループを使用して AWS リソースへのトラフィックを制御する](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html)」
以下のポリシーは、指定された IP 範囲からのすべての HTTP リクエストが `test-domain` にアクセスする許可を付与します。
------
#### [ JSON ]
****
```
{
"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/*"
}
]
}
```
------
ドメインにパブリックエンドポイントがあり、[きめ細かなアクセスコントロール](fgac.md)を使用しない場合は、IAM プリンシパルと IP アドレスを組み合わせることをお勧めします。このポリシーでは、指定した IP 範囲からのリクエストの場合にのみ、`test-user` HTTP アクセスを許可します。
------
#### [ JSON ]
****
```
{
"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/*"
}]
}
```
------
## 複数のポリシーが衝突する場合
複数のポリシーが同意しない、あるいはユーザーを明示的に指定しない場合、困難が生じます。「*IAM ユーザーガイド*」の「[IAM の仕組み](https://docs.aws.amazon.com/IAM/latest/UserGuide/intro-structure.html)」では、ポリシーの評価ロジックの簡略な概要を説明しています。
+ デフォルトでは、すべてのリクエストが拒否されます。
+ 明示的な許可はこのデフォルトに優先します。
+ 明示的な拒否はすべての許可に上書きされます。
例えば、リソースベースのポリシーがドメインサブリソース (OpenSearch インデックスまたは API) にアクセスを許可しているが、アイデンティティベースのポリシーはアクセスを拒否するため、アクセスは拒否されます。アイデンティティベースのポリシーとリソースベースのポリシーによってユーザーがアクセス許可を持つべきかを指定いない場合、アクセスは許可されます。ドメインサブリソースのすべての結果の概要における交差するポリシーの図を以下で参照してください。
****
| | リソースベースのポリシーで許可 | リソースベースのポリシーで拒否 | リソースベースのポリシーで許可あるいは拒否されない |
| --- |--- |--- |--- |
| **Allowed in identity-based policy** | 許可 | Deny | Allow |
| --- |--- |--- |--- |
| **Denied in identity-based policy** | Deny | Deny | Deny |
| --- |--- |--- |--- |
| **Neither allowed nor denied in identity-based policy** | Allow | Deny | Deny |
| --- |--- |--- |--- |
## ポリシーエレメントのリファレンス
OpenSearch Service では、「[IAM ポリシーエレメントのリファレンス](https://docs.aws.amazon.com/IAM/latest/UserGuide/AccessPolicyLanguage_ElementDescriptions.html)」のほとんどのポリシー要素がサポートされています (`NotPrincipal` は除く)。次の表は、最も一般的なエレメントを示しています。
****
| JSON ポリシーエレメント | 概要 |
| --- | --- |
| Version | ポリシー言語の最新バージョンは `2012-10-17` です。すべてのアクセスポリシーでこの値を指定する必要があります。 |
| Effect | このエレメントは、指定されたアクションへのアクセスをステートメントが許可するか拒否するかを指定します。有効な値は `Allow` または `Deny` です。 |
| Principal | この要素は、リソースへのアクセスを許可または拒否し、いくつかの形式を取ることができる AWS アカウント または IAM ロールまたはユーザーを指定します。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/opensearch-service/latest/developerguide/ac.html) `*` ワイルドカードを指定すると、ドメインへの匿名アクセスが有効になります。これは [IP ベースの条件](#ac-types-ip)を追加する、[VPC サポート](vpc.md)を使用する、または[きめ細かなアクセスコントロール](fgac.md)を有効にしない限り、お勧めしません。さらに、次のポリシーを注意深く調べて、広範なアクセスが許可されていないことを確かめてください。 関連する AWS プリンシパル (IAM ロールなど) にアタッチされているアイデンティティベースのポリシー 関連付けられた AWS リソースにアタッチされたリソースベースのポリシー ( AWS Key Management Service KMS キーなど) |
| Action | OpenSearch Service は、OpenSearch HTTP メソッドに対して `ESHttp*` アクションを使用します。残りのアクションは設定 API に適用されます。特定の `es:` アクションは、リソースレベルの許可をサポートします。例えば、*すべて*のドメインを削除する許可を付与せずに、1 つの特定のドメインのみ削除する許可をユーザーに付与することができます。その他のアクションはサービス自体に適用されます。例えば、`es:ListDomainNames` は単一ドメインのコンテキストでは意味を成しませんが、それでもワイルドカードを必要とします。使用可能なすべてのアクションのリストと、それらがドメインのサブリソース (`test-domain/*`) に適用されるのか、ドメイン設定 (`test-domain`) に適用されるのか、サービス (`*`) のみに適用されるのかについては、「*サービス認証リファレンス*」の「[Actions, resources, and condition keys for Amazon OpenSearch Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonopensearchservice.html)」を参照してくださいリソースベースのポリシーは、リソースレベルのアクセス権限とは異なっています。[リソースベースのポリシー](#ac-types-resource) は、ドメインにアタッチする完全な JSON ポリシーです。リソースレベルのアクセス許可は、特定のドメインあるいはサブリソースにアクションを制限します。実際には、リソースレベルのアクセス許可はリソース、あるいはアイデンティティベースのポリシーのオプションの一部として捉えることができます。`es:CreateDomain` へのリソースレベルのアクセス権限は直観的ではないように見えることがあります。(つまり、すでに存在するドメインを作成するアクセス権限をなぜユーザーに付与するのでしょうか？) ワイルドカードの使用でドメインに簡単な命名スキームを適用できます (`"Resource": "arn:aws:es:us-west-1:987654321098:domain/my-team-name-*"` など)。もちろん、次のように、制限がより緩和されたリソース要素のアクションを含めることもできます。 JSON
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"es:ESHttpGet",
"es:DescribeDomain"
],
"Resource": "*"
}
]
}
``` アクションとリソースのペアリングについての詳細は、テーブルの `Resource` 要素を参照してください。 |
| Condition | OpenSearch Service は、*IAM ユーザーガイド*の「[AWS グローバル条件コンテキストキー](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#AvailableKeys)」に記載されているほとんどの条件をサポートします。注目すべき例外は、OpenSearch Service がサポートしていない `aws:PrincipalTag` キーがあることです。 [IP ベースのポリシー](#ac-types-ip)を設定する場合、次に示すように、IP アドレスまたは CIDR ブロックを条件として指定します。 "Condition": {
"IpAddress": {
"aws:SourceIp": [
"192.0.2.0/32"
]
}
} [アイデンティティベースのポリシー](#ac-types-identity) に記載されているように、`aws:ResourceTag`、`aws:RequestTag`、および `aws:TagKeys` 条件キーは、設定 API と OpenSearch API に適用されます。 |
| Resource | OpenSearch サービスは、3 つの基本的な方法で `Resource` エレメントを使用します。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/opensearch-service/latest/developerguide/ac.html) どのアクションがリソースレベルのアクセス権限をサポートするかの詳細については、このテーブルの `Action` 要素を参照してください。 |
## 詳細オプションと API に関する考慮事項
OpenSearch Service にはいくつかの詳細オプションがあり、その 1 つにはアクセスコントロールが関連します (`rest.action.multi.allow_explicit_index`)。デフォルト設定の true では、特定の状況下でユーザーがサブリソースへのアクセス権限を回避することが許可されます。
例えば、次のリソースベースのポリシーを考えます。
------
#### [ JSON ]
****
```
{
"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-user` に `test-index` および OpenSearch バルク API へのフルアクセスを付与します。また、`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 Service が URL を使用してドメインサブリソースへのアクセスを制御するため、`test-user` は、結果的にバルク API を使用して `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 Dashboards](dashboards.md) は mget および msearch に大きく依存しています。そのため、この変更後には正常に動作しないことが予想されます。部分的な解決策としては、`rest.action.multi.allow_explicit_index` を true のまま残して、特定のユーザーが 1 つ以上の API にアクセスすることを拒否します。
この設定の変更については、「[高度なクラスター設定](createupdatedomains.md#createdomain-configure-advanced-options)」を参照してください。
同様に、以下のリソースベースのポリシーには 2 つの小さな問題があります。
------
#### [ JSON ]
****
```
{
"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*` を指定する必要があります。
広範囲な許可と一部の拒否を混合するよりは、[最小限の権限](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)の原則を守り、タスクを実行するために必要なアクセス権限のみを付与することが最も安全なアプローチです。個々のインデックスまたは OpenSearch オペレーションに対するアクセスコントロールの詳細については、[Amazon OpenSearch Service のきめ細かなアクセスコントロール](fgac.md) を参照してください。
**重要**
\$1 ワイルドカードを指定すると、ドメインへの匿名アクセスが有効になります。ワイルドカードを使用することはお勧めしません。さらに、以下のポリシーを注意深く調べて、広範なアクセスが許可されていないことを確かめてください。
関連付けられた AWS プリンシパルにアタッチされたアイデンティティベースのポリシー (IAM ロールなど)
関連付けられたリソースにアタッチされた AWS リソースベースのポリシー ( AWS Key Management Service KMS キーなど)
## アクセスポリシーの設定
+ リソースの作成あるいは変更、そして OpenSearch Service の IP ベースのポリシーに関する説明は、「[アクセスポリシーの設定](createupdatedomains.md#createdomain-configure-access-policies)」を参照してください。
+ IAM でアイデンティティベースのポリシーを作成または変更する方法については、「*IAM ユーザーガイド*」の「[カスタマー管理ポリシーでカスタム IAM アクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)」を参照してください。
## 追加のサンプルポリシー
この章には多くのサンプルポリシーが含まれていますが、 AWS アクセスコントロールは複雑なテーマであり、例を通じて最もよく理解できます。詳細については、*IAM ユーザーガイド*の「[IAM アイデンティティベースのポリシーの例](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_examples.html)」を参照してください。