翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # Amazon OpenSearch Service のきめ細かなアクセスコントロール きめ細かなアクセスコントロールは、Amazon OpenSearch Service のデータへのアクセスをコントロールする追加の方法を提供します。例えば、リクエスト者によっては、検索で 1 つのインデックスのみから結果が返されるようにしたい場合があります。ドキュメント内の特定のフィールドを非表示にしたい場合や、特定のドキュメントをまとめて除外したい場合もあります。 きめ細かなアクセスコントロールには、以下の利点があります。 + ロールベースアクセスコントロール + インデックスレベル、ドキュメントレベル、フィールドレベルのセキュリティ + OpenSearch Dashboards マルチテナンシー + OpenSearch および OpenSearch Dashboards の HTTP 基本認証 **Topics** + [全体像: きめ細かなアクセスコントロールと OpenSearch Service セキュリティ](#fgac-access-policies) + [主要なコンセプト](#fgac-concepts) + [マスターユーザーについて](#fgac-master-user) + [きめ細かなアクセスコントロールの有効化](#fgac-enabling) + [マスターユーザーとして OpenSearch Dashboards にアクセスする](#fgac-dashboards) + [許可の管理](#fgac-access-control) + [推奨される設定](#fgac-recommendations) + [制限事項](#fgac-limitations) + [マスターユーザーの変更](#fgac-forget) + [追加のマスターユーザー](#fgac-more-masters) + [手動スナップショット](#fgac-snapshots) + [統合](#fgac-integrations) + [REST API の相違点](#fgac-rest-api) + [チュートリアル: IAM マスターユーザーと Amazon Cognito 認証を使用してドメインを設定する](fgac-iam.md) + [チュートリアル: 内部ユーザーデータベースと HTTP 基本認証でドメインを設定する](fgac-http-auth.md) ## 全体像: きめ細かなアクセスコントロールと OpenSearch Service セキュリティ Amazon OpenSearch Service のセキュリティには 3 つの主要なレイヤーがあります。 **ネットワーク** 最初のセキュリティレイヤーはネットワークであり、リクエストが OpenSearch Service ドメインに到達するかどうかを決定します。ドメインを作成するときに [**パブリックアクセス**] を選択した場合、インターネットに接続されたクライアントからのリクエストがドメインエンドポイントに到達できます。[**VPC アクセス**] を選択した場合、クライアントがエンドポイントに到達するためには、クライアントが VPC に接続する必要があります (かつ、関連するセキュリティグループがその接続を許可する必要があります)。詳細については、「[VPC 内で Amazon OpenSearch Service ドメインを起動する](vpc.md)」を参照してください。 **ドメインアクセスポリシー** 2 番目のセキュリティレイヤーは、ドメインアクセスポリシーです。リクエストがドメインエンドポイントに到達すると、[リソースベースのアクセスポリシー](ac.md#ac-types-resource)により、指定された URI へのアクセスリクエストが許可または拒否されます。このアクセスポリシーにより、リクエストは OpenSearch 自体に到達する前に、ドメインの「エッジ」で許可または拒否されます。 **きめ細かなアクセスコントロール** 最後の 3 番目のセキュリティレイヤーは、きめ細かなアクセスコントロールです。リソースベースのアクセスポリシーにより、リクエストがドメインエンドポイントに到達することが許可された後、きめ細かなアクセスコントロールにより、ユーザー認証情報が評価されて、ユーザーが認証されるか、リクエストが拒否されます。きめ細かなアクセスコントロールによりユーザーが認証された場合、そのユーザーにマッピングされているすべてのロールが取得され、付与されるすべての許可を使用してリクエストの処理方法が決定されます。 **注記** リソースベースのアクセスポリシーに IAM ロールまたはユーザーが含まれている場合、クライアントは AWS 署名バージョン 4 を使用して署名付きリクエストを送信する必要があります。そのため、アクセスポリシーは、特に内部ユーザーデータベースと HTTP 基本認証を使用する場合、きめ細かなアクセスコントロールと競合することがあります。ユーザー名とパスワードで、*かつ* IAM 認証情報で、リクエストに署名することはできません。一般に、きめ細かなアクセスコントロールを有効にする場合は、署名付きリクエストを必須としないドメインアクセスポリシーを使用することをお勧めします。 以下の図表は、きめ細かなアクセスコントロールが有効な VPC アクセスドメイン、IAM ベースのアクセスポリシー、IAM マスターユーザーという、一般的な構成を示しています。 ![\[VPC ドメインを使用したきめ細かなアクセスコントロールの承認フロー\]](http://docs.aws.amazon.com/ja_jp/opensearch-service/latest/developerguide/images/fgac-vpc-iam.png) 以下の図表は、きめ細かなアクセスコントロールが有効なパブリックアクセスドメイン、IAM プリンシパルを使用しないアクセスポリシー、内部ユーザーデータベース内のマスターユーザーという、別の一般的な構成を示しています。 ![\[パブリックアクセスドメインを使用したきめ細かなアクセスコントロールの承認フロー\]](http://docs.aws.amazon.com/ja_jp/opensearch-service/latest/developerguide/images/fgac-public-basic.png) ### 例 `movies/_search?q=thor` への `GET` リクエストを考えてみます。ユーザーに `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 つは Dashboards へのアクセスを許可し、1 つは `index1` への読み取り専用アクセスを許可し、もう 1 つは `index2` への書き込みアクセスを許可します。または、これらのすべての許可を 1 つのロールに含めることもできます。 + **[ユーザー]** – OpenSearch クラスターに対してリクエストを行うユーザーまたはアプリケーション。ユーザーは、リクエストを行うときに指定する認証情報 (IAM アクセスキーまたはユーザー名とパスワードのいずれか) を持っています。 ## マスターユーザーについて OpenSearch Service の*マスターユーザーは*、ユーザー名とパスワードの組み合わせ、または基盤となる OpenSearch クラスターへの完全なアクセス許可を持つ IAM プリンシパルのいずれかです。OpenSearch Dashboards 内で内部ユーザー、ロール、ロールマッピングを作成する機能に加えて、OpenSearch クラスターへのすべてのアクセス権を持っている場合、ユーザーはマスターユーザーと見なされます。 OpenSearch Service コンソールまたは CLI を使用して作成されたマスターユーザーは、次の 2 つの定義済みロールに自動的にマッピングされます。 + `all_access` – すべてのクラスター全体のオペレーションへのフルアクセス、すべてのクラスターインデックスへの書き込み許可、およびすべてのテナントへの書き込み許可を提供します。 + `security_manager` – [セキュリティプラグイン](https://opensearch.org/docs/latest/security/)へのアクセスと、ユーザーとアクセス許可の管理を提供します。 これらの 2 つのロールを使用すると、ユーザーは OpenSearch Dashboards の **[セキュリティ]** タブにアクセスして、ユーザーとアクセス許可を管理できます。別の内部ユーザーを作成し、`all_access` ロールにのみマッピングすると、そのユーザーは **[セキュリティ]** タブにアクセスできなくなります。追加のマスターユーザーは、`all_access` と `security_manager` ロールの両方に明示的にマッピングすることで作成できます。手順については、「[追加のマスターユーザー](#fgac-more-masters)」を参照してください。 ドメインのマスターユーザーを作成するときは、既存の *IAM プリンシパル*を指定するか、*内部ユーザーデータベース*内にマスターユーザーを作成できます。どちらを使用するかを決定するときは、次の点を考慮してください。 + **IAM プリンシ**パル – マスターユーザーの IAM プリンシパルを選択した場合、クラスターへのすべてのリクエストは AWS 署名バージョン 4 を使用して署名する必要があります。 OpenSearch Service では、IAM プリンシパルのアクセス許可は考慮されません。IAM ユーザーまたはロールは、*認証*のためにのみ機能します。そのユーザーまたはロールのポリシーは、マスターユーザーの*許可*には関係しません。許可は、OpenSearch セキュリティプラグインのさまざまな[アクセス許可](https://opensearch.org/docs/latest/security/access-control/permissions/)を通じて処理されます。 例えば、*IAM* プリンシパルに IAM アクセス許可をゼロに割り当てることができます。マシンまたはユーザーがそのユーザーまたはロールに認証できる限り、そのプリンシパルは OpenSearch Service でマスターユーザーの権限を持ちます。 複数のクラスターで同じユーザーを使用する場合、Amazon Cognito を使用して Dashboards にアクセスする場合、または署名バージョン 4 の署名をサポートする OpenSearch クライアントがある場合は、IAM をお勧めします。 + **[内部ユーザーデータベース]** – 内部ユーザーデータベースにマスターを作成する場合 (ユーザー名とパスワードの組み合わせを使用)、HTTP 基本認証 (および IAM 認証情報) を使用してクラスターにリクエストを行うことができます。ほとんどのクライアントは、[curl](https://curl.haxx.se/) を含む基本認証をサポートしています。curl は、[--aws-sigv4 オプション](https://curl.se/docs/manpage.html)で AWS 署名バージョン 4 もサポートしています。内部ユーザーデータベースは OpenSearch インデックスに保存されるため、他のクラスターと共有することはできません。 複数のクラスター間でユーザーを再利用する必要がない場合、Dashboards へのアクセスに Amazon Cognito ではなく HTTP 基本認証を使用する場合、または基本認証のみをサポートするクライアントがある場合は、内部ユーザーデータベースをお勧めします。OpenSearch Service の使用を開始するには、内部ユーザーデータベースが最もシンプルな方法です。 ## きめ細かなアクセスコントロールの有効化 コンソール、 AWS CLI、または設定 API を使用して、きめ細かなアクセスコントロールを有効にします。手順については、「[Amazon OpenSearch Service ドメインの作成と管理](createupdatedomains.md)」を参照してください。 きめ細かなアクセスコントロールには、OpenSearch または Elasticsearch 6.7 以降が必要です。また、ドメインへのすべてのトラフィックに HTTPS、[保管時のデータの暗号化](encryption-at-rest.md)、および[ノード間の暗号化](ntn.md)を要求します。きめ細かなアクセス制御の、高度な機能の設定方法によっては、さらに多くのリクエストを処理するために、個々のデータノードにコンピューティングリソースとメモリリソースが必要になる場合があります。きめ細かなアクセスコントロールを有効にした後、無効にすることはできません。 ### 既存のドメインでのきめ細かなアクセスコントロールの有効化 OpenSearch または Elasticsearch 6.7 以降を実行している既存のドメインに対して、きめ細かなアクセスコントロールを有効にすることができます。 **既存のドメインに対してきめ細かなアクセスコントロールを有効にするには (コンソール)** 1. ドメインを選択し、[**アクション**] および [**セキュリティ設定の編集**] を選択します。 1. [**きめ細かなアクセスコントロールを有効にする**] を選択します。 1. マスターユーザーの作成方法を選択します。 + ユーザー管理に IAM を使用する場合は、[**IAM ARN をマスターユーザーとして設定**] を選択し、IAM ロールの ARN を指定します。 + 内部ユーザーデータベースを使用する場合は、**[Create master user]** (マスターユーザーの作成) を選択し、ユーザー名とパスワードを指定します。 1. (オプション) [**Open/IP ベースのアクセスポリシーの移行期間を有効にする**] を選択します。この設定により、30 日間の移行期間が有効になります。この期間中、既存のユーザーが中断することなくドメインにアクセスできるようになり、[IP ベースのアクセスポリシー](ac.md#ac-types-ip)は引き続きドメインで動作します。この移行期間中に、管理者が[必要なロールを作成し、それらをドメインのユーザーにマップする](#fgac-access-control)ことをお勧めします。オープンアクセスポリシーまたは IP ベースのアクセスポリシーの代わりに ID ベースのポリシーを使用している場合は、この設定を無効にすることができます。 また、移行期間中にきめ細かなアクセス制御を使用するようにクライアントを更新する必要があります。たとえば、IAM ロールをきめ細かなアクセスコントロールにマッピングする場合、 AWS 署名バージョン 4 でリクエストの署名を開始するようにクライアントを更新する必要があります。きめ細かなアクセス制御を使用して HTTP 基本認証を構成する場合、リクエストに応じた基本認証資格情報を提供するようにクライアントを更新する必要があります。 移行期間中、ドメインの OpenSearch Dashboards エンドポイントにアクセスするユーザーは、ログインページではなく、**Discover** ページに直接アクセスします。管理者とマスターユーザーは、**Login** を選択して管理者の認証情報を使用してログインし、ロールのマッピングを設定できます。 **重要** **OpenSearch Service は 30 日後に移行期間を自動的に無効にします**。必要なロールを作成してユーザーにマップしたら、すぐに終了することをお勧めします。移行期間が終了した後、再度有効化することはできません。 1. **[Save changes]** (変更の保存) をクリックします。 この変更により、[青/緑のデプロイ](managedomains-configuration-changes.md#bg)がトリガーされ、その間にクラスターの状態が赤になりますが、すべてのクラスターオペレーションは影響を受けません。 **既存のドメインに対してきめ細かなアクセスコントロールを有効にするには (CLI)** きめ細かなアクセスコントロールを使用して移行期間を有効にするには、`AnonymousAuthEnabled` を `true` に設定します。 ``` aws opensearch update-domain-config --domain-name test-domain --region us-east-1 \ --advanced-security-options '{ "Enabled": true, "InternalUserDatabaseEnabled":true, "MasterUserOptions": {"MasterUserName":"master-username","MasterUserPassword":"master-password"},"AnonymousAuthEnabled": true}' ``` ### default\$1role について きめ細かなアクセスコントロールには、[ロールマッピング](#fgac-mapping)が必要です。ドメインが[アイデンティティベースのアクセスポリシー](ac.md#ac-types-identity)を使用している場合、OpenSearch Service は、既存のユーザーを適切に移行できるように、ユーザーを **default\$1role** と呼ばれる新しいロールに自動的にマップします。この一時的なマッピングにより、独自のロールマッピングを作成するまで、ユーザーは IAM 署名付き GET および PUT リクエストを正常に送信できます。 ロールによって、OpenSearch サービスドメインにセキュリティの脆弱性や欠陥が追加されることはありません。独自のロールを設定したら、すぐにデフォルトのロールを削除して、それに応じてマッピングすることをお勧めします。 ### 移行シナリオ 次の表に、既存のドメインできめ細かなアクセス制御を有効にする前と後の各認証方式の動作と、管理者がユーザーをロールに適切にマッピングするために必要な手順について説明します。 | 認証方法 | きめ細かなアクセスコントロールの有効化の前 | きめ細かなアクセスコントロールの有効化の後 | 管理タスク | | --- | --- | --- | --- | | アイデンティティベースのポリシー | IAM ポリシーを満たすすべてのユーザーが、ドメインにアクセスできます。 | 移行期間を有効にする必要はありません。 OpenSearch Service は、IAM ポリシーを満たすすべてのユーザーがドメインに引き続きアクセスできるように、これらのユーザーを **[default\$1role](#fgac-enabling-defaultrole)** に自動的にマップします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/opensearch-service/latest/developerguide/fgac.html) | | IP ベースのポリシー | 許可された IP アドレスまたは CIDR ブロックのすべてのユーザーがドメインにアクセスできます。 | 30 日間の移行期間中は、許可された IP アドレスまたは CIDR ブロックのすべてのユーザーが引き続きドメインにアクセスできます。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/opensearch-service/latest/developerguide/fgac.html) | | オープンアクセスポリシー | インターネット上のすべてのユーザーがドメインにアクセスできます。 | 30 日間の移行期間中は、インターネット上のすべてのユーザーが引き続きドメインにアクセスできます。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/opensearch-service/latest/developerguide/fgac.html) | ## マスターユーザーとして OpenSearch Dashboards にアクセスする きめ細かなアクセスコントロールには、管理タスクをシンプルにする OpenSearch Dashboards プラグインがあります。Dashboards を使用して、ユーザー、ロール、マッピング、アクショングループ、テナントを管理できます。ただし、OpenSearch Dashboards サインインページと基になる認証方法は、ユーザーの管理方法とドメインの設定方法によって異なります。 + ユーザー管理に IAM を使用する場合は、[OpenSearch Dashboards の Amazon Cognito 認証の設定](cognito-auth.md) を使用して、Dashboards にアクセスします。それ以外の方法では、Dashboards の「機能しない」サインインページが表示されます。「[制限事項](#fgac-limitations)」を参照してください。 Amazon Cognito 認証では、ID プールから引き受けたいずれかのロールが、マスターユーザーに指定した IAM ロールと一致する必要があります。この設定の詳細については、「[(オプション) きめ細かなアクセスの設定](cognito-auth.md#cognito-auth-granular)」および「[チュートリアル: IAM マスターユーザーと Amazon Cognito 認証を使用してドメインを設定する](fgac-iam.md)」を参照してください。 ![\[Cognito のサインインページ\]](http://docs.aws.amazon.com/ja_jp/opensearch-service/latest/developerguide/images/cognito-auth.png) + 内部ユーザーデータベースを使用することを選択した場合は、マスターユーザー名とパスワードを使用して Dashboards にサインインできます。HTTPS 経由で Dashboards にアクセスする必要があります。このログイン画面は、Dashboards の Amazon Cognito 認証と SAML 認証の両方に置き換えられます。 この設定の詳細については、「[チュートリアル: 内部ユーザーデータベースと HTTP 基本認証でドメインを設定する](fgac-http-auth.md)」を参照してください。 ![\[基本認証のサインインページ\]](http://docs.aws.amazon.com/ja_jp/opensearch-service/latest/developerguide/images/basic-auth-dashboards.png) + SAML 認証を使用することを選択した場合は、外部 ID プロバイダーからの認証情報を使用してサインインできます。詳細については、「[OpenSearch Dashboards の SAML 認証](saml.md)」を参照してください。 ## 許可の管理 「[主要なコンセプト](#fgac-concepts)」で説明しているように、ロール、ユーザー、マッピングを使用してきめ細かなアクセスコントロールの許可を管理します。このセクションでは、これらのリソースを作成して適用する方法について説明します。これらの操作を実行するには、[マスターユーザーとして Dashboards にサインイン](#fgac-dashboards)することをお勧めします。 ![\[Dashboards のセキュリティホームページ\]](http://docs.aws.amazon.com/ja_jp/opensearch-service/latest/developerguide/images/dashboards-fgac-home.png) **注記** ユーザーに付与するために選択する権限は、ユースケースによって大きく異なります。このドキュメントですべてのシナリオを実行可能にカバーすることはできません。ユーザーに付与するアクセス許可を決定するときは、次のセクションで説明する OpenSearch クラスターとインデックスのアクセス許可を参照し、常に [最小特権の原則](https://en.wikipedia.org/wiki/Principle_of_least_privilege) に従ってください。 ### ロールの作成 OpenSearch Dashboards、または REST API の `_plugins/_security` オペレーションを使用して、きめ細かなアクセスコントロール用の新しいロールを作成できます。詳細については、「[ロールの作成](https://opensearch.org/docs/latest/security/access-control/users-roles/#create-roles)」を参照してください。 きめ細かなアクセスコントロールには、多くの[事前定義されたロール](https://opensearch.org/docs/latest/security/access-control/users-roles/#predefined-roles)も含まれます。OpenSearch Dashboards や Logstash などのクライアントは、OpenSearch に対して多種多様なリクエストを行うため、最小限の許可のセットを使用してロールを手動で作成するのが難しくなる場合があります。例えば、`opensearch_dashboards_user` ロールには、ユーザーがインデックスパターン、可視化、ダッシュボード、およびテナントを操作するのに必要な許可が含まれます。このロールは、他のインデックスへのアクセスを許可する追加のロールと共に、Dashboards にアクセスするすべてのユーザーまたはバックエンドロールに[マッピング](#fgac-mapping)することをお勧めします。 Amazon OpenSearch Service では、次の OpenSearch ロールは提供されていません。 + `observability_full_access` + `observability_read_access` + `reports_read_access` + `reports_full_access` Amazon OpenSearch Service には、OpenSearch では利用できないロールがいくつかあります。 + `ultrawarm_manager` + `ml_full_access` + `cold_manager` + `notifications_full_access` + `notifications_read_access` #### クラスターレベルのセキュリティ クラスターレベルの許可により、`_mget`、`_msearch`、`_bulk` などの広範なリクエストの実施、ヘルスのモニタリング、スナップショットの取得などを可能にするかどうかを制御できます。ロールを作成するときに、[**クラスター許可**] セクションを使用してこれらの許可を管理します。クラスタレベルの権限の完全なリストについては、「[クラスタ権限](https://opensearch.org/docs/latest/security/access-control/permissions/#cluster-permissions)」を参照してください。 多くの場合、個別の権限ではなく、デフォルトのアクショングループの組み合わせを使用して、目的のセキュリティ体制を実現できます。クラスターレベルのアクショングループのリストについては、「[クラスターレベル](https://opensearch.org/docs/latest/security/access-control/default-action-groups/#cluster-level)」を参照してください。 #### インデックスレベルのセキュリティ インデックスレベルの許可により、新しいインデックスの作成、インデックスの検索、ドキュメントの読み取りと書き込み、ドキュメントの削除、エイリアスの管理などを可能にするかどうかを制御できます。ロールを作成するときに、[**インデックス許可**] セクションを使用してこれらのアクセス許可を管理します。インデックスレベルの権限の完全なリストについては、「[インデックス権限](https://opensearch.org/docs/latest/security/access-control/permissions/#index-permissions)」を参照してください。 多くの場合、個別の権限ではなく、デフォルトのアクショングループの組み合わせを使用して、目的のセキュリティ体制を実現できます。インデックスレベルのアクショングループのリストについては、「[インデックスレベル](https://opensearch.org/docs/latest/security/access-control/default-action-groups/#index-level)」を参照してください。 #### ドキュメントレベルのセキュリティ ドキュメントレベルのセキュリティにより、インデックス内のどのドキュメントをユーザーが表示できるかを制限できます。ロールを作成するときに、インデックスパターンと OpenSearch クエリを指定します。そのロールにマッピングされたすべてのユーザーは、クエリに一致するドキュメントのみを表示できます。ドキュメントレベルのセキュリティは、[検索時に受け取るヒットの数](#fgac-example)に影響します。 詳細については、「[ドキュメントレベルのセキュリティ](https://opensearch.org/docs/latest/security/access-control/document-level-security/)」を参照してください。 #### フィールドレベルのセキュリティ フィールドレベルのセキュリティにより、どのドキュメントフィールドをユーザーが表示できるかを制御できます。ロールを作成するときに、含めるフィールドと除外するフィールドのリストを追加します。フィールドを含めると、そのロールにマッピングされたユーザーはそれらのフィールドのみを表示できます。フィールドを除外すると、除外されたフィールドを*除く*すべてのフィールドを表示できます。フィールドレベルのセキュリティは、[検索時にヒットに含まれるフィールドの数](#fgac-example)に影響します。 詳細については、「[フィールドレベルのセキュリティ](https://opensearch.org/docs/latest/security/access-control/field-level-security/)」を参照してください。 #### フィールドのマスキング フィールドのマスキングは、フィールドレベルのセキュリティに代わるもので、フィールド内のデータを完全に削除するのではなく、匿名化できます。ロールを作成するときに、マスクするフィールドのリストを追加します。フィールドのマスキングは、[検索時にフィールドの内容を表示できるかどうか](#fgac-example)に影響します。 **ヒント** 標準のマスキングをフィールドに適用すると、OpenSearch Service は不正確な集計結果を引き起こす可能性のある安全でランダムなハッシュを使用します。マスキングされたフィールドで集計を実施するには、代わりにパターンベースのマスキングを使用します。 ### ユーザーの作成 内部ユーザーデータベースを有効にした場合、OpenSearch Dashboards、または REST API の `_plugins/_security` オペレーションを使用してユーザーを作成できます。詳細については、「[ユーザーの作成](https://opensearch.org/docs/latest/security/access-control/users-roles/#create-users)」を参照してください。 マスターユーザーに IAM を選択した場合は、Dashboards のこの部分は無視してください。その代わりに IAM ロールを作成します。詳細については、[IAM ユーザーガイド](https://docs.aws.amazon.com/IAM/latest/UserGuide/)を参照してください。 ### ユーザーへのロールのマッピング ロールのマッピングは、きめ細かなアクセスコントロールの最も重要な側面です。きめ細かなアクセスコントロールには、使用の開始に役立ついくつかの事前定義されたロールがありますが、ロールをユーザーにマッピングしない限り、クラスターに対するすべてのリクエストは許可エラーという結果になります。 *バックエンドロール*を使用すると、ロールのマッピングプロセスを簡素化できます。このロールを使えば、同じロールを 100 人のユーザーに割り当てるのではなく、100 人のユーザーが共有している 1 つのバックエンドロールにロールをマッピングできます。バックエンドロールは、IAM ロールまたは任意の文字列にすることができます。 + **[Users]** (ユーザー) セクションで、ユーザー、ユーザー ARN、および Amazon Cognito ユーザー文字列を指定します。Cognito ユーザー文字列の形式は `Cognito/user-pool-id/username` です。 + [**バックエンドロール**] セクションで、バックエンドロールと IAM ロール ARN を指定します。 ![\[ロールのマッピング画面\]](http://docs.aws.amazon.com/ja_jp/opensearch-service/latest/developerguide/images/role-mapping-edit.png) OpenSearch Dashboards、または REST API の `_plugins/_security` オペレーションを使用して、ロールをユーザーにマッピングできます。詳細については、「[ユーザーをロールにマッピングする](https://opensearch.org/docs/latest/security/access-control/users-roles/#map-users-to-roles)」を参照してください。 ### アクショングループの作成 アクショングループは、さまざまなリソースで再利用できる許可のセットです。OpenSearch Dashboards、または REST API の `_plugins/_security` オペレーションを使用して新しいアクショングループを作成できますが、ほとんどのユースケースではデフォルトのアクショングループで十分です。デフォルトのアクショングループの詳細については、「[デフォルトのアクショングループ](https://opensearch.org/docs/latest/security/access-control/default-action-groups/)」を参照してください。 ### OpenSearch Dashboards マルチテナンシー テナントは、インデックスパターン、可視化、ダッシュボード、その他の Dashboards オブジェクトを保存するための領域です。Dashboards マルチテナンシーを使用すると、他の Dashboards ユーザーと作業を安全に共有できます (プライベートに保持できます)。また、テナントを動的に設定できます。どのロールがテナントにアクセスできるか、それらのロールに読み取りアクセスがあるか書き込みアクセスがあるかを制御できます。グローバルテナントがデフォルトです。詳細については、「[OpenSearch Dashboards マルチテナンシー](https://opensearch.org/docs/latest/security/multi-tenancy/tenant-index/)」を参照してください。 **現在のテナントを表示したりテナントを変更したりするには** 1. OpenSearch Dashboards に移動し、サインインします。 1. 右上隅にあるユーザーアイコンを選択し、[**テナントの切り替え**] を選択します。 1. 可視化またはダッシュボードを作成する前に、テナントを確認します。他のすべての Dashboards ユーザーと作業を共有する場合は、[**グローバル**] を選択します。一部の Dashboards ユーザーと作業を共有するには、別の共有テナントを選択します。それ以外の場合は、[**プライベート**] を選択します。 **注記** OpenSearch Dashboards は、テナントごとに個別のインデックスを維持し、`tenant_template` と呼ばれるインデックステンプレートを作成します。テナントインデックスのマッピングが正しく構成されていない場合、OpenSearch Dashboards が誤動作する可能性があるため、`tenant_template` インデックスを削除または変更しないでください。 ## 推奨される設定 きめ細かなアクセスコントロールは[他のセキュリティ機能と連携](#fgac-access-policies)するため、ここでは、ほとんどのユースケースで適切に機能するきめ細かなアクセスコントロールの推奨される設定を示します。 | 説明 | マスターユーザー | ドメインアクセスポリシー | | --- | --- | --- | | OpenSearch API への呼び出しに IAM 認証情報を使用し、[SAML 認証](saml.md)を使用して、Dashboards にアクセスします。Dashboards または REST API を使用して、きめ細かなアクセスコントロールのロールを管理します。 | IAM ロールまたはユーザー | JSON **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "es:ESHttp*", "Resource": "arn:aws:es:us-east-1:111122223333:domain/domain-name/*" } ] } ``` | | OpenSearch API への呼び出しに IAM 認証情報または基本認証を使用します。Dashboards または REST API を使用して、きめ細かなアクセスコントロールのロールを管理します。 この設定は、特に基本認証のみをサポートする OpenSearch クライアントがある場合、多くの柔軟性を提供します。 既存の ID プロバイダーがある場合は、[SAML 認証](saml.md)を使用して、Dashboards にアクセスします。それ以外の場合は、内部ユーザーデータベースで Dashboards ユーザーを管理します。 | ユーザー名とパスワード | JSON **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "es:ESHttp*", "Resource": "arn:aws:es:us-east-1:111122223333:domain/domain-name/*" } ] } ``` | | OpenSearch API への呼び出しに IAM 認証情報を使用し、Amazon Cognito を使用して、Dashboards にアクセスします。Dashboards または REST API を使用して、きめ細かなアクセスコントロールのロールを管理します。 | IAM ロールまたはユーザー | JSON **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "es:ESHttp*", "Resource": "arn:aws:es:us-east-1:111122223333:domain/domain-name/*" } ] } ``` | | OpenSearch API への呼び出しに IAM 認証情報を使用し、Dashboards へのほとんどのアクセスをブロックします。REST API を使用して、きめ細かなアクセスコントロールのロールを管理します。 | IAM ロールまたはユーザー | JSON **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "es:ESHttp*", "Resource": "arn:aws:es:us-east-1:111122223333:domain/domain-name/*" }, { "Effect": "Deny", "Principal": { "AWS": "*" }, "Action": "es:ESHttp*", "Resource": "arn:aws:es:us-east-1:111122223333:domain/domain-name/_dashboards*" } ] } ``` | ## 制限事項 きめ細かなアクセスコントロールには、いくつかの重要な制限があります。 + `hosts` のロールマッピングの側面は、ロールをホスト名または IP アドレスにマッピングすることですが、ドメインが VPC 内にある場合は機能しません。ただし、ロールをユーザーとバックエンドロールにマッピングすることは可能です。 + マスターユーザーに IAM を選択し、Amazon Cognito または SAML 認証を有効にしない場合、Dashboards の「機能しない」サインインページが表示されます。 + マスターユーザーに IAM を選択しても、内部ユーザーデータベースにユーザーを作成することはできます。ただし、この設定では HTTP 基本認証が有効になっていないため、これらのユーザー認証情報で署名されたリクエストは拒否されます。 + [SQL](sql-support.md) を使用して、アクセスできないインデックスをクエリすると、「許可なし」のエラーが表示されます。インデックスが存在しない場合、「インデックスなし」のエラーが表示されます。このエラーメッセージの違いは、インデックスの名前を推測できれば、そのインデックスが存在していることがわかる点です。 この問題を最小限に抑えるために、[インデックス名に機密情報を含めないでください](indexing.md#indexing-naming)。SQL へのすべてのアクセスを拒否するには、ドメインアクセスポリシーに以下の要素を追加します。 ``` { "Effect": "Deny", "Principal": { "AWS": [ "*" ] }, "Action": [ "es:*" ], "Resource": "arn:aws:es:us-east-1:123456789012:domain/my-domain/_plugins/_sql" } ``` + ドメインバージョンが 2.3 以上で、きめ細かいアクセス制御が有効になっている場合、`max_clause_count` を 1 に設定するとドメインで問題が発生します。このアカウントにはもっと高い数値を設定することをおすすめします。 + きめ細かなアクセスコントロールが設定されていないドメインできめ細かなアクセスコントロールを有効にする場合、直接クエリ用に作成されたデータソースについては、きめ細かなアクセスコントロールロールを自分で設定する必要があります。きめ細かなアクセスロールを設定する方法の詳細については、「[Creating Amazon OpenSearch Service data source integrations with Amazon S3](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/direct-query-s3-creating.html#direct-query-s3-prereq)」を参照してください。 ## マスターユーザーの変更 マスターユーザーの詳細を忘れた場合は、コンソール、 AWS CLI、または configuration API を使用して再設定できます。 **マスターユーザーを変更するには (コンソール)** 1. [https://console.aws.amazon.com/aos/home/](https://console.aws.amazon.com/aos/home/) の Amazon OpenSearch Service コンソールに移動します。 1. ドメインを選択し、**[Actions]** (アクション)、**[Edit security configuration]** (セキュリティ設定の編集) を選択します。 1. [**マスターユーザーとして IAM ARN を設定**] または [**マスターユーザーを作成**] を選択します。 + 以前に IAM マスターユーザーを使用していた場合、きめ細かなアクセスコントロールにより、指定した新しい IAM ARN に `all_access` ロールが再マッピングされます。 + 以前に内部ユーザーデータベースを使用していた場合、きめ細かなアクセスコントロールにより、新しいマスターユーザーが作成されます。新しいマスターユーザーを使用して、古いマスターユーザーを削除できます。 + 内部ユーザーデータベースから IAM マスターユーザーへの切り替えでは、内部ユーザーデータベースからユーザーを削除*しません*。代わりに、HTTP 基本認証を無効にするだけです。内部ユーザーデータベースからユーザーを手動で削除するか、HTTP 基本認証を再度有効にする必要がある場合に備えて、ユーザーを保持します。 1. **[Save changes]** (変更の保存) をクリックします。 ## 追加のマスターユーザー ドメインの作成時にマスターユーザーを指定しますが、必要に応じて、このマスターユーザーを使用して追加のマスターユーザーを作成できます。OpenSearch Dashboards または REST API の 2 つのオプションがあります。 + Dashboards で [**セキュリティ**]、[**ロール**] の順に選択し、新しいマスターユーザーを `all_access` および `security_manager` ロールにマッピングします。 ![\[ロールのマッピングページ\]](http://docs.aws.amazon.com/ja_jp/opensearch-service/latest/developerguide/images/new-master-users.png) + REST API を使用するには、以下のリクエストを送信します。 ``` PUT _plugins/_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 _plugins/_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 が特に役立つのは、Dashboards にアクセスできず、IAM ロールを Amazon Cognito から `all_access` ロールにマッピングする場合です。 ## 手動スナップショット きめ細かなアクセスコントロールにより、手動スナップショットの取得がいくらか複雑になります。スナップショットリポジトリを登録するには、HTTP 基本認証を他のすべての目的で使用する場合でも、[前提条件](managedomains-snapshots.md#managedomains-snapshot-prerequisites) で定義されるように、`TheSnapshotRole` を引き受けるための `iam:PassRole` 許可がある IAM ロールに `manage_snapshots` ロールをマッピングする必要があります。 次に、その IAM ロールを使用して、「[手動スナップショットレポジトリの登録](managedomains-snapshot-registerdirectory.md)」に概説されているように、署名付きリクエストをドメインに送信します。 ## 統合 OpenSearch Service で[他の AWS サービス](integrations.md)を使用する場合は、それらのサービスの IAM ロールに適切なアクセス許可を付与する必要があります。例えば、Firehose の配信ストリームでは、`firehose_delivery_role` という名前の IAM ロールがよく使用されます。Dashboards で、[きめ細かなアクセスコントロール用のロールを作成](#fgac-roles)し、[そのロールに IAM ロールをマッピング](#fgac-mapping)します。この場合、新しいロールには以下の許可が必要です。 ``` { "cluster_permissions": [ "cluster_composite_ops", "cluster_monitor" ], "index_permissions": [{ "index_patterns": [ "firehose-index*" ], "allowed_actions": [ "create_index", "manage", "crud" ] }] } ``` 許可は、各サービスが実行するアクションによって異なります。データのインデックスを作成する AWS IoT ルールまたは AWS Lambda 関数には Firehose と同様のアクセス許可が必要になる可能性がありますが、検索のみを実行する Lambda 関数では、より制限されたセットを使用できます。 ## REST API の相違点 きめ細かなアクセスコントロールの REST API は、OpenSearch/Elasticsearch バージョンによってわずかに異なります。`PUT` リクエストを行う前に、`GET` リクエストを行って、想定されるリクエスト本文を確認します。例えば、`GET` への `_plugins/_security/api/user` リクエストはすべてのユーザーを返すため、それらの結果を変更して使用して、有効な `PUT` リクエストを行うことができます。 Elasticsearch 6.*x* では、ユーザーの作成リクエストは以下のようになります。 ``` PUT _opendistro/_security/api/user/new-user { "password": "some-password", "roles": ["new-backend-role"] } ``` OpenSearch または Elasticsearch 7.x では、リクエストは次のようになります (Elasticsearch を使用している場合は、`_plugins` を `_opendistro` に変更してください)。 ``` PUT _plugins/_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" } } ``` OpenSearch と Elasticsearch 7.x では、それらは独自の URI を持つオブジェクトです (Elasticsearch を使用している場合は、`_plugins` を `_opendistro` に変更してください)。 ``` GET _plugins/_security/api/tenants { "global_tenant": { "reserved": true, "hidden": false, "description": "Global tenant", "static": false } } ``` OpenSearch REST API のドキュメントについては、「[セキュリティプラグイン API リファレンス](https://opensearch.org/docs/latest/security/access-control/api/)」を参照してください。 **ヒント** 内部ユーザーデータベースを使用する場合は、[curl](https://curl.haxx.se/) を使用してリクエストを行い、ドメインをテストできます。次のサンプルコマンドを試してください。 ``` curl -XGET -u 'master-user:master-user-password' 'domain-endpoint/_search' curl -XGET -u 'master-user:master-user-password' 'domain-endpoint/_plugins/_security/api/user' ```