翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon OpenSearch Service での OpenSearch UI の使用
OpenSearch UI (ユーザーインターフェイス) は、Amazon OpenSearch Service のモダナイズされた運用分析エクスペリエンスであり、複数のソース間でデータを操作するための統一されたビューを提供します。OpenSearch Dashboards がホストされている単一のドメインまたはコレクションでのみ動作するのに対し、OpenSearch UI は AWS クラウドでホストされています。これにより、OpenSearch UI は高可用性を実現し、クラスターのアップグレード中も機能し続け、複数のデータソースにネイティブに接続できます。OpenSearch Dashboards の詳細については、「[Amazon OpenSearch Service での OpenSearch Dashboards の使用](dashboards.md)」を参照してください。
OpenSearch UI の主要な機能は以下のとおりです。
+ **複数のデータソースのサポート** – OpenSearch UI は、複数のデータソースに接続して包括的なビューを作成できます。これには、OpenSearch ドメインとサーバーレスコレクション、Amazon CloudWatch、Amazon Security Lake、Amazon Simple Storage Service (Amazon S3) などの統合 AWS データソースが含まれます。
+ **アップグレード中のダウンタイムゼロ** – OpenSearch UI は AWS クラウドでホストされます。つまり、OpenSearch は引き続き動作し、アップグレードプロセス中にクラスターからデータを取得できます。
+ **ワークスペース** – オブザーバビリティ、セキュリティ分析、検索など、さまざまなワークフローのチーム共同作業のための厳選されたスペース。プライバシー設定を定義し、ワークスペース内の共同作業者のアクセス許可を管理できます。
+ **シングルサインオン** – OpenSearch UI は、 AWS IAM アイデンティティセンター および SAML through AWS Identity and Access Management (IAM) フェデレーションと連携して ID プロバイダーと統合し、エンドユーザー向けのシングルサインオンエクスペリエンスを作成します。
+ **GenAI を活用した分析** – OpenSearch UI は自然言語クエリ生成をサポートしているため、分析に適したクエリを生成できます。OpenSearch UI は Amazon Q Developer と連携し、Amazon Q チャットを提供するとともに、可視化、アラート概要、インサイト、推奨される異常検知器の生成を支援します。
+ **複数クエリ言語のサポート** – OpenSearch UI は、Piped Processing Language (PPL)、SQL、Lucene、および Dashboards Query Language (DQL) をサポートしています。
+ **クロスリージョンおよびクロスアカウントのサポート** – OpenSearch UI は、クラスター間検索機能を利用して、異なるアカウントおよび異なるリージョンの OpenSearch ドメインに接続し、集約された分析と視覚化を行うことができます。
開始して最初の OpenSearch UI を作成するには、「[Amazon OpenSearch Service における OpenSearch ユーザーインターフェースの開始方法](application-getting-started.md)」の手順に従います。
OpenSearch UI 用にリリースされた最新の機能については、「[Amazon OpenSearch Service ユーザーインターフェイスのリリース履歴](application-release-history.md)」を参照してください。
**Topics**
+ [Amazon OpenSearch Service ユーザーインターフェイスのリリース履歴](application-release-history.md)
+ [Amazon OpenSearch Service における OpenSearch ユーザーインターフェースの開始方法](application-getting-started.md)
+ [Amazon OpenSearch Service のエージェント AI](application-ai-assistant.md)
+ [カスタマーマネージドキーを使用した OpenSearch UI アプリケーションメタデータの暗号化](application-encryption-cmk.md)
+ [での SAML フェデレーションの有効化 AWS Identity and Access Management](application-enable-SAML-identity-federation.md)
+ [データソースの関連付けと Virtual Private Cloud アクセス許可の管理](application-data-sources-and-vpc.md)
+ [Amazon OpenSearch Service ワークスペースの使用](application-workspaces.md)
+ [クロスリージョンおよびクロスアカウントデータアクセス](application-cross-region-cross-account.md)
+ [VPC エンドポイントからの OpenSearch UI へのアクセスの管理](application-access-ui-from-vpc-endpoint.md)
+ [保存されたオブジェクトを OpenSearch Dashboards から OpenSearch UI に移行する](application-migration.md)
+ [OpenSearch UI エンドポイントとクォータ](opensearch-ui-endpoints-quotas.md)
# Amazon OpenSearch Service ユーザーインターフェイスのリリース履歴
以下の表は、Amazon OpenSearch Service の OpenSearch UI サポートに関する全リリースと、各リリースに含まれる機能および強化点を一覧表示します。
| 変更 | リリース日 | 説明 |
| --- | --- | --- |
| 機能を追加 | 2025-03-10 | OpenSearch UI は、OpenSearch ドメインへのクロスアカウントデータアクセスをサポートするようになりました。パブリックドメインと VPC ドメインの両方について、IAM または AWS IAM アイデンティティセンター 認証を使用して異なるアカウントのドメインにアクセスするように、1 つのアカウントでアプリケーションを設定できます。詳細については、「[OpenSearch ドメインへのクロスアカウントデータアクセス](application-cross-account-data-access-domains.md)」を参照してください。 |
| 機能を追加 | 2025-12-29 | OpenSearch UI は、アプリケーションメタデータを暗号化するためのカスタマーマネージドキー (CMK) をサポートするようになりました。この機能は、暗号化キーを完全に制御することで、規制およびコンプライアンス要件を満たすのに役立ちます。この起動により、OpenSearch UI に保存されたオブジェクトのメタデータサイズ制限も引き上げられるため、複雑なクエリ、広範な視覚化、大規模なワークスペースを作成および保存できます。詳細については、「[カスタマーマネージドキーを使用した OpenSearch UI アプリケーションメタデータの暗号化](application-encryption-cmk.md)」を参照してください。 |
| 機能を追加 | 2025-04-16 | OpenSearch UI が[クラスター間検索](cross-cluster-search.md)で動作するようになりました。これにより、一つの AWS リージョン で OpenSearch UI を使用して、別のリージョンのクラスターにアクセスできるようになります。これを行うには、アクセスしたいクラスターを、同じリージョン内のクラスターに接続されたリモートクラスターとして設定します。詳細については、「[クラスター間検索](application-cross-cluster-search.md)」を参照してください。 |
| 機能を追加 | 2025-03-31 | Amazon Q Developer が Amazon OpenSearch Service で一般提供されました。詳細については、「[Amazon OpenSearch Service 用 AI アシスタント](AI-assistant-support.md)」を参照してください。 |
| 機能を追加 | 2025-02-05 | Security Assertion Markup Language 2.0) (SAML) から AWS Identity and Access Management (IAM) フェデレーションが OpenSearch UI で動作するようになりました。これにより、エンドユーザー向けの ID プロバイダー主導のシングルサインオン (SSO) エクスペリエンスを作成できます。詳細については、「[での SAML フェデレーションの有効化 AWS Identity and Access Management](application-enable-SAML-identity-federation.md)」を参照してください。 |
| 新しい統合 | 2024-12-01 | Amazon CloudWatch とのゼロ ETL 統合は、ログデータの分析と視覚化を簡素化し、技術的なオーバーヘッドと運用コストを削減します。詳細については、「*AWS ニュースブログ*」の「[New Amazon CloudWatch and Amazon OpenSearch Service launch an integrated analytics experience](https://aws.amazon.com/blogs/aws/new-amazon-cloudwatch-and-amazon-opensearch-service-launch-an-integrated-analytics-experience/)」を参照してください。 |
| 新しい統合 | 2024-12-01 | Amazon Security Lake とのゼロ ETL 統合により、組織はセキュリティデータから実用的なインサイトを効率的に検索、分析、取得できます。詳細については、「*AWS ニュースブログ*」の「[セキュリティ分析を簡素化するための Amazon OpenSearch Service と Amazon Security Lake の統合のご紹介](https://aws.amazon.com/blogs/aws/introducing-amazon-opensearch-service-zero-etl-integration-for-amazon-security-lake/)」を参照してください。 |
| 初回リリース | 2024-11-07 | OpenSearch UI の最初の一般リリースです。詳細については、「*AWS ビッグデータブログ*」の「[Amazon OpenSearch Service が次世代 OpenSearch UI を発表](https://aws.amazon.com/blogs/big-data/amazon-opensearch-service-launches-the-next-generation-opensearch-ui/)」を参照してください。 |
# Amazon OpenSearch Service における OpenSearch ユーザーインターフェースの開始方法
Amazon OpenSearch Service では、*アプリケーション*は OpenSearch ユーザーインターフェイス (OpenSearch UI) のインスタンスです。各アプリケーションは複数のデータソースに関連付けることができ、1 つのソースを複数のアプリケーションに関連付けることができます。サポートされているさまざまな認証オプションを使用して、管理者ごとに複数のアプリケーションを作成できます。
このトピックの情報を使用して、 AWS マネジメントコンソール または を使用して OpenSearch UI アプリケーションを作成するプロセスについて説明します AWS CLI。
**Topics**
+ [Amazon OpenSearch Service アプリケーションを作成するために必要なアクセス許可](#application-prerequisite-permissions)
+ [OpenSearch UI アプリケーションの作成](#create-application)
+ [アプリケーション管理者の管理](#managing-application-administrators)
## Amazon OpenSearch Service アプリケーションを作成するために必要なアクセス許可
アプリケーションを作成する前に、タスクに必要なアクセス許可が付与されていることを確認します。必要に応じて、アカウント管理者にお問い合わせください。
### 全般的なアクセス許可
OpenSearch Service でアプリケーションを使用するには、次のポリシーに示すアクセス許可が必要です。アクセス許可は以下の目的のために設定されます:
+ アプリケーションを作成および管理するには、5 つの `es:*Application` アクセス許可が必要です。
+ アプリケーションからタグを追加、一覧表示、削除するには、3 つの `es:*Tags` アクセス許可が必要です。
+ データソースを関連付けるには `aoss:BatchGetCollection`、`es:DescribeDomain`、`es:GetDirectQueryDataSource` のアクセス許可が必要です。
+ データソースにアクセスするには `aoss:APIAccessAll`、`es:ESHttp*`、および 4 つの `opensearch:*DirectQuery*` のアクセス許可が必要です。
+ `iam:CreateServiceLinkedRole` は、アカウントにサービスにリンクされたロール (SLR) を作成するためのアクセス許可を Amazon OpenSearch Service に提供します。このロールは、OpenSearch UI アプリケーションが Amazon CloudWatch メトリクスをお使いのアカウントに公開できるようにするために使用されます。詳細については、「[サービスにリンクされたロールを使用して、VPC ドメインとダイレクトクエリデータソースを作成する](slr-aos.md)」トピックの「[アクセス許可](slr-aos.md#slr-permissions)」を参照してください。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"es:CreateApplication",
"es:DeleteApplication",
"es:GetApplication",
"es:ListApplications",
"es:UpdateApplication",
"es:AddTags",
"es:ListTags",
"es:RemoveTags",
"aoss:APIAccessAll",
"es:ESHttp*",
"opensearch:StartDirectQuery",
"opensearch:GetDirectQuery",
"opensearch:CancelDirectQuery",
"opensearch:GetDirectQueryResult",
"aoss:BatchGetCollection",
"aoss:ListCollections",
"es:DescribeDomain",
"es:DescribeDomains",
"es:ListDomainNames",
"es:GetDirectQueryDataSource",
"es:ListDirectQueryDataSources"
],
"Resource": "*"
},
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws:iam::*:role/aws-service-role/opensearchservice.amazonaws.com/AWSServiceRoleForAmazonOpenSearchService"
}
]
}
```
------
### IAM Identity Center 認証を使用するアプリケーションを作成するアクセス許可 (オプション)
デフォルトでは、ダッシュボードアプリケーションは AWS Identity and Access Management (IAM) を使用して認証され、 AWS リソースユーザーのアクセス許可を管理します。ただし、IAM Identity Center を使用してシングルサインオンエクスペリエンスを提供することを選択できます。これにより、既存の ID プロバイダーを使用して OpenSearch UI アプリケーションにログインできます。この場合、このトピックの後半の手順で **[IAM Identity Center による認証]** オプションを選択し、OpenSearch UI アプリケーションにアクセスするために必要なアクセス許可を IAM Identity Center ユーザーに付与します)。
IAM Identity Center 認証を使用するアプリケーションを作成するには、次のアクセス許可が必要です。*プレースホルダー値*を、ユーザー自身の情報に置き換えます。必要に応じて、アカウント管理者にお問い合わせください。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "IDCPermissions",
"Effect": "Allow",
"Action": [
"es:CreateApplication",
"es:DeleteApplication",
"es:GetApplication",
"es:ListApplications",
"es:UpdateApplication",
"es:AddTags",
"es:ListTags",
"es:RemoveTags",
"aoss:BatchGetCollection",
"aoss:ListCollections",
"es:DescribeDomain",
"es:DescribeDomains",
"es:ListDomainNames",
"es:GetDirectQueryDataSource",
"es:ListDirectQueryDataSources",
"sso:CreateApplication",
"sso:DeleteApplication",
"sso:PutApplicationGrant",
"sso:PutApplicationAccessScope",
"sso:PutApplicationAuthenticationMethod",
"sso:ListInstances",
"sso:DescribeApplicationAssignment",
"sso:DescribeApplication",
"sso:CreateApplicationAssignment",
"sso:ListApplicationAssignments",
"sso:DeleteApplicationAssignment",
"sso-directory:SearchGroups",
"sso-directory:SearchUsers",
"sso:ListDirectoryAssociations",
"identitystore:DescribeUser",
"identitystore:DescribeGroup",
"iam:ListRoles"
],
"Resource": "*"
},
{
"Sid": "SLRPermission",
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws:iam::*:role/aws-service-role/opensearchservice.amazonaws.com/AWSServiceRoleForAmazonOpenSearchService"
},
{
"Sid": "PassRolePermission",
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::111122223333:role/iam-role-for-identity-center"
}
]
}
```
------
## OpenSearch UI アプリケーションの作成
次のいずれかの手順を使用して、アプリケーション名、認証方法、および管理者を指定するアプリケーションを作成します。
**Topics**
+ [コンソールで IAM 認証を使用する OpenSearch UI アプリケーションの作成](#create-application-iam-authentication-console)
+ [コンソールで AWS IAM アイデンティティセンター 認証を使用する OpenSearch UI アプリケーションを作成する](#create-application-iam-identity-center-authentication-console)
+ [を使用した AWS IAM アイデンティティセンター 認証を使用する OpenSearch UI アプリケーションの作成 AWS CLI](#create-application-iam-identity-center-authentication-cli)
### コンソールで IAM 認証を使用する OpenSearch UI アプリケーションの作成
**コンソールで IAM 認証を使用する OpenSearch UI アプリケーションを作成するには**
1. [https://console.aws.amazon.com/aos/home](https://console.aws.amazon.com/aos/home) で Amazon OpenSearch Service コンソールにサインインします。
1. 左のナビゲーションペインの **[OpenSearch UI (ダッシュボード)]** を選択します。
1. [**アプリケーションを作成**] を選択します。
1. **[アプリケーション名]** に、そのアプリケーションの名前を入力します。
1. **[IAM Identity Center による認証]** チェックボックスをオンにしないでください。認証を使用したアプリケーションの作成については AWS IAM アイデンティティセンター、このトピックの[コンソールで AWS IAM アイデンティティセンター 認証を使用する OpenSearch UI アプリケーションを作成する](#create-application-iam-identity-center-authentication-console)後半の「」を参照してください。
1. (オプション) 作成するアプリケーションの管理者として自動的に追加されます。**[OpenSearch アプリケーション管理者管理]** エリアでは、他のユーザーに管理者権限を付与できます。
**注記**
OpenSearch UI アプリケーション管理者ロールは、OpenSearch UI アプリケーションを編集および削除する権限を付与します。アプリケーション管理者は、OpenSearch UI アプリケーションでワークスペースを作成、編集、削除することもできます。
管理者権限を他のユーザーに付与するには、次のいずれかを選択します。
+ **[特定のユーザー (複数可) に管理者の権限を付与]** – **[OpenSearch アプリケーション管理者]** フィールドの **[プロパティ]** ポップアップリストで、**[IAM ユーザー]** または
**AWS IAM アイデンティティセンター ユーザー**を選択し、管理者権限を付与する個々のユーザーを選択します。
+ **[すべてのユーザーに管理者権限を付与]** – 組織またはアカウント内のすべてのユーザーに管理者権限が付与されます。
1. (オプション) 暗号化設定を構成します。デフォルトでは、OpenSearch UI メタデータは AWS 所有キーで暗号化されます。暗号化に独自のカスタマーマネージドキー (CMK) を使用するには、「」を参照してください[カスタマーマネージドキーを使用した OpenSearch UI アプリケーションメタデータの暗号化](application-encryption-cmk.md)。
1. (オプション) **[タグ]** エリアで、1 つ以上のタグキーの名前と値のペアをアプリケーションに適用します。
タグは、リソースに割り当てるオプションのメタデータです。タグを使用すると、目的、所有者、環境などのさまざまな方法でリソースを分類できます。
1. **[作成]** を選択します。
### コンソールで AWS IAM アイデンティティセンター 認証を使用する OpenSearch UI アプリケーションを作成する
AWS IAM アイデンティティセンター 認証を使用する OpenSearch UI アプリケーションを作成するには、[IAM Identity Center 認証を使用するアプリケーションを作成するアクセス許可 (オプション)](#prerequisite-permissions-idc) のこのトピックで前述した IAM アクセス許可が必要です。
**コンソールで AWS IAM アイデンティティセンター 認証を使用する OpenSearch UI アプリケーションを作成するには**
1. [https://console.aws.amazon.com/aos/home](https://console.aws.amazon.com/aos/home) で Amazon OpenSearch Service コンソールにサインインします。
1. 左のナビゲーションペインの **[OpenSearch UI (ダッシュボード)]** を選択します。
1. [**アプリケーションを作成**] を選択します。
1. **[アプリケーション名]** に、そのアプリケーションの名前を入力します。
1. (オプション) 組織またはアカウントのシングルサインオンを有効にするには、次の手順を実行します。
1. 次の図に示すように、**[IAM Identity Center による認証]** チェックボックスをオンにします。
![\[「IAM Identity Center による認証」ボックスが選択された「シングルサインオン認証」領域。\]](http://docs.aws.amazon.com/ja_jp/opensearch-service/latest/developerguide/images/ui-Single-sign-on-authentication.png)
1. 次のいずれかを行います。
+ **[Identity Center アプリケーションリストの IAM ロール]** で、IAM Identity Center が OpenSearch UI および関連するデータソースにアクセスするために必要なアクセス許可を提供する既存の IAM ロールを選択します。ロールに必要なアクセス許可については、次の箇条書きのポリシーを参照してください。
+ 必要なアクセス許可を持つ新しいロールを作成します。*IAM ユーザーガイド*の次の手順と、指定されたオプションを使用して新しいロールを作成し、必要なアクセス許可ポリシーと信頼ポリシーを使用します。
+ 手順: [IAM ポリシーを作成する (コンソール)](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/access_policies_create-console.html)
この手順のステップに従って、次のポリシーをポリシーエディタ **[JSON]** フィールドに貼り付けます:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "IdentityStoreOpenSearchDomainConnectivity",
"Effect": "Allow",
"Action": [
"identitystore:DescribeUser",
"identitystore:ListGroupMembershipsForMember",
"identitystore:DescribeGroup"
],
"Resource": "*",
"Condition": {
"ForAnyValue:StringEquals": {
"aws:CalledViaLast": "es.amazonaws.com"
}
}
},
{
"Sid": "OpenSearchDomain",
"Effect": "Allow",
"Action": [
"es:ESHttp*"
],
"Resource": "*"
},
{
"Sid": "OpenSearchServerless",
"Effect": "Allow",
"Action": [
"aoss:APIAccessAll"
],
"Resource": "*"
}
]
}
```
------
+ 手順: [カスタム信頼ポリシーを使用してロールを作成する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-custom.html)
この手順のステップに従って、**[カスタム信頼ポリシー]** ボックスのプレースホルダー JSON を次のように置き換えます。
**ヒント**
既存のロールに信頼ポリシーを追加する場合は、ロールの **[信頼関係]** タブにポリシーを追加します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "application.opensearchservice.amazonaws.com"
},
"Action": "sts:AssumeRole"
},
{
"Effect": "Allow",
"Principal": {
"Service": "application.opensearchservice.amazonaws.com"
},
"Action": "sts:SetContext",
"Condition": {
"ForAllValues:ArnEquals": {
"sts:RequestContextProviders": "arn:aws:iam::123456789012:oidc-provider/portal.sso.us-east-1.amazonaws.com/apl/application-id"
}
}
}
]
}
```
------
1. 組織またはアカウントに IAM Identity Center インスタンスがすでに作成されている場合、次の図に示すように、コンソールは Amazon OpenSearch Dashboards が IAM Identity Center の組織インスタンスに既に接続されていることを報告します。
![\[「IAM Identity Center のアカウントインスタンスに接続された Amazon OpenSearch Dashboard」エリアには、既存の IAM Identity Center アカウントインスタンスの URL が表示されます。\]](http://docs.aws.amazon.com/ja_jp/opensearch-service/latest/developerguide/images/ui-connected-instance.png)
IAM Identity Center が組織またはアカウントでまだ利用できない場合は、ユーザーまたは必要なアクセス許可を持つ管理者が組織インスタンスまたはアカウントインスタンスを作成できます。**[Amazon OpenSearch Dashboards を IAM アイデンティティセンターに接続する]** エリアには、次の図に示すように、両方のオプションがあります。
![\[「Amazon OpenSearch Dashboards を IAM アイデンティティセンターに接続する」エリアには、組織インスタンスまたはアカウントインスタンスを作成するためのボタンがあります。\]](http://docs.aws.amazon.com/ja_jp/opensearch-service/latest/developerguide/images/ui-no-connected-instance.png)
この場合、IAM アイデンティティセンターでテスト用のアカウントインスタンスを作成するか、管理者が IAM アイデンティティセンターで組織インスタンスを作成するようにリクエストできます。詳細については、「*AWS IAM アイデンティティセンター ユーザーガイド*」の以下のトピックを参照してください。
**注記**
IAM アイデンティティセンターの組織インスタンス AWS リージョン とは異なる で OpenSearch UI アプリケーションを作成する場合は、[「複数の で IAM アイデンティティセンターを使用する AWS リージョン](https://docs.aws.amazon.com/singlesignon/latest/userguide/multi-region-iam-identity-center.html)」を参照してください。
+ [IAM Identity Center の組織インスタンス](https://docs.aws.amazon.com/singlesignon/latest/userguide/organization-instances-identity-center.html)
+ [IAM アイデンティティセンターのアカウントインスタンス](https://docs.aws.amazon.com/singlesignon/latest/userguide/account-instances-identity-center.html)
+ [有効化 AWS IAM アイデンティティセンター](https://docs.aws.amazon.com/singlesignon/latest/userguide/enable-identity-center.html)
1. (オプション) 作成するアプリケーションの管理者として自動的に追加されます。**[OpenSearch アプリケーションの管理者管理]** エリアでは、次の画像に示すように、管理者権限を他のユーザーに付与できます。
![\[「OpenSearch アプリケーションの管理者管理」エリアには、ユーザーまたはすべてのユーザーを選択するアクセス許可を管理者に付与するオプションがあります。\]](http://docs.aws.amazon.com/ja_jp/opensearch-service/latest/developerguide/images/ui-admins-management.png)
**注記**
OpenSearch UI アプリケーション管理者ロールは、OpenSearch UI アプリケーションを編集および削除する権限を付与します。アプリケーション管理者は、OpenSearch UI アプリケーションでワークスペースを作成、編集、削除することもできます。
管理者権限を他のユーザーに付与するには、次のいずれかを選択します。
+ **[特定のユーザー (複数可) に管理者の権限を付与]** – **[OpenSearch アプリケーション管理者]** フィールドの **[プロパティ]** ポップアップリストで、**[IAM ユーザー]** または
**AWS IAM アイデンティティセンター ユーザー**を選択し、管理者権限を付与する個々のユーザーを選択します。
+ **[すべてのユーザーに管理者権限を付与]** – 組織またはアカウント内のすべてのユーザーに管理者権限が付与されます。
1. (オプション) **[タグ]** エリアで、1 つ以上のタグキーの名前と値のペアをアプリケーションに適用します。
タグは、リソースに割り当てるオプションのメタデータです。タグを使用すると、目的、所有者、環境などのさまざまな方法でリソースを分類できます。
1. **[作成]** を選択します。
### を使用した AWS IAM アイデンティティセンター 認証を使用する OpenSearch UI アプリケーションの作成 AWS CLI
を使用して AWS IAM アイデンティティセンター 認証を使用する OpenSearch UI アプリケーションを作成するには AWS CLI、以下のオプションを指定して [create-application](https://docs.aws.amazon.com/cli/latest/reference/opensearch/create-application.html) コマンドを使用します。
+ `--name` – アプリケーションの名前。
+ `--iam-identity-center-options` – (オプション) OpenSearch が認証とアクセスコントロールに使用する IAM Identity Center インスタンスと IAM ロール。
*プレースホルダー値*を、ユーザー自身の情報に置き換えます。
```
aws opensearch create-application \
--name application-name \
--iam-identity-center-options "
{
\"enabled\":true,
\"iamIdentityCenterInstanceArn\":\"arn:aws:sso:::instance/sso-instance\",
\"iamRoleForIdentityCenterApplicationArn\":\"arn:aws:iam::account-id:role/role-name\"
}
"
```
## アプリケーション管理者の管理
OpenSearch UI アプリケーション管理者は、OpenSearch UI アプリケーションを編集および削除できる権限を持つ定義されたロールです。
デフォルトでは、OpenSearch UI アプリケーションの作成者は、OpenSearch UI アプリケーションの最初の管理者です。
### コンソールを使用した OpenSearch UI 管理者の管理
AWS マネジメントコンソールの OpenSearch UI アプリケーションには、アプリケーションの作成ワークフロー中またはアプリケーションの作成後の **[編集]** ページで、管理者を追加できます。
OpenSearch UI アプリケーション管理者ロールは、OpenSearch UI アプリケーションを編集および削除する権限を付与します。アプリケーション管理者は、OpenSearch UI アプリケーションでワークスペースを作成、編集、削除することもできます。
アプリケーションの詳細ページで、IAM プリンシパルの Amazon リソースネーム (ARN) を検索するか、IAM Identity Center のユーザーの名前を検索できます。
**コンソールを使用して OpenSearch UI 管理者を管理するには**
1. [https://console.aws.amazon.com/aos/home](https://console.aws.amazon.com/aos/home) で Amazon OpenSearch Service コンソールにサインインします。
1. 左のナビゲーションペインの **[OpenSearch UI (ダッシュボード)]** を選択します。
1. **[OpenSearch アプリケーション]** エリアで、既存のアプリケーションの名前を選択します。
1. [**編集**] を選択します。
1. 管理者権限を他のユーザーに付与するには、次のいずれかを選択します。
+ **[特定のユーザー (複数可) に管理者の権限を付与]** – **[OpenSearch アプリケーション管理者]** フィールドの **[プロパティ]** ポップアップリストで、**[IAM ユーザー]** または
**AWS IAM アイデンティティセンター ユーザー**を選択し、管理者権限を付与する個々のユーザーを選択します。
+ **[すべてのユーザーに管理者権限を付与]** – 組織またはアカウント内のすべてのユーザーに管理者権限が付与されます。
1. **[更新]** を選択します。
追加の管理者を削除できますが、各 OpenSearch UI アプリケーションは少なくとも 1 人の管理者を保持する必要があります。
### を使用した OpenSearch UI 管理者の管理 AWS CLI
AWS CLIを使用して、OpenSearch UI アプリケーション管理者を作成および更新できます。
#### を使用した OpenSearch UI 管理者の作成 AWS CLI
OpenSearch UI アプリケーションを作成するときに、IAM プリンシパルと IAM Identity Center ユーザーを管理者として追加する例を次に示します。
##### 例 1: IAM ユーザーを管理者として追加する OpenSearch UI アプリケーションを作成する
次のコマンドを実行して、IAM ユーザーを管理者として追加する OpenSearch UI アプリケーションを作成します。*プレースホルダー値*を、ユーザー自身の情報に置き換えます。
```
aws opensearch create-application \
--name application-name \
--app-configs "
{
\"key\":\"opensearchDashboards.dashboardAdmin.users\",
\"value\":\"arn:aws:iam::account-id:user/user-id\"
}
"
```
##### 例 2: IAM Identity Center を有効にし、OpenSearch Identity Center ユーザー ID を OpenSearch UI アプリケーション管理者として追加する OpenSearch UI アプリケーションを作成する
次のコマンドを実行して、IAM Identity Center を有効にし、IAM Identity Center ユーザー ID を OpenSearch UI アプリケーション管理者として追加する OpenSearch UI アプリケーションを作成します。*プレースホルダー値*を、ユーザー自身の情報に置き換えます。
`key` は、OpenSearch UI アプリケーションの管理者ロールなど、設定する構成項目を指定します。有効な値は、`opensearchDashboards.dashboardAdmin.users` および `opensearchDashboards.dashboardAdmin.groups` です。
*xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx* は、IAM ユーザーの Amazon リソースネーム (ARN) など、キーに割り当てられた値を表します。
```
aws opensearch create-application \
--name myapplication \
--iam-identity-center-options "
{
\"enabled\":true,
\"iamIdentityCenterInstanceArn\":\"arn:aws:sso:::instance/ssoins-instance-id\",
\"iamRoleForIdentityCenterApplicationArn\":\"arn:aws:iam::account-id:role/role-name\"
}
" \
--app-configs "
{
\"key\":\"opensearchDashboards.dashboardAdmin.users\",
\"value\":\"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx\"
}
"
```
#### を使用した OpenSearch UI 管理者の更新 AWS CLI
以下は、既存の OpenSearch アプリケーションの管理者として割り当てられた IAM プリンシパルと IAM Identity Center ユーザーを更新する例です。
##### 例 1: 既存の OpenSearch アプリケーションの管理者として IAM ユーザーを追加する
次のコマンドを実行して OpenSearch UI アプリケーションを更新し、IAM ユーザーを管理者として追加します。*プレースホルダー値*を、ユーザー自身の情報に置き換えます。
```
aws opensearch update-application \
--id myapplication \
--app-configs "
{
\"key\":\"opensearchDashboards.dashboardAdmin.users\",
\"value\":\"arn:aws:iam::account-id:user/user-id\"
}
"
```
##### 例 2: OpenSearch UI アプリケーションを更新して、IAM Identity Center ユーザー ID を OpenSearch UI アプリケーション管理者として追加する
次のコマンドを実行して、OpenSearch UI アプリケーションを更新し、IAM Identity Center ユーザー ID を OpenSearch UI アプリケーション管理者として追加します。*プレースホルダー値*を、ユーザー自身の情報に置き換えます。
`key` は、OpenSearch UI アプリケーションの管理者ロールなど、設定する構成項目を指定します。有効な値は、`opensearchDashboards.dashboardAdmin.users` および `opensearchDashboards.dashboardAdmin.groups` です。
*xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx* は、IAM ユーザーの Amazon リソースネーム (ARN) など、キーに割り当てられた値を表します。
```
aws opensearch update-application \
--id myapplication \
--app-configs "
{
\"key\":\"opensearchDashboards.dashboardAdmin.users\",
\"value\":\"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx\"
}
"
```
# Amazon OpenSearch Service のエージェント AI
OpenSearch UI には、運用分析を簡素化し、エンジニアリングチームとサポートチームのインシデント調査を加速するために設計された一連のエージェント AI 機能が含まれています。
OpenSearch UI アプリケーションのすべてのページで、AI に**尋ねる**ボタンを選択してエージェントチャットを開きます。エージェントチャットは、表示しているページのコンテキストを理解し、エージェントツールを使用して基盤となるデータを分析し、クエリを更新して Discover で結果を表示し、質問に明確かつ正確に回答します。複雑な根本原因分析でより詳細な調査が必要な場合は、調査エージェントをトリガーして、複数ステップのワークフローを通じて自律的に計画、実行、および反映し、データ証拠に基づく構造化された仮説を提供できます。両方のエージェント機能を強化するのは、会話や調査内のコンテキストを保持するメモリレイヤーであるエージェントメモリです。これにより、さまざまなウェブセッションにわたって同じ一貫したコンテキストでフォローアップの質問をし続けることができます。
![\[自然言語入力「レイテンシーが 10 秒を超えるすべてのリクエストを検索」から PPL クエリを生成するエージェントチャットを示す OpenSearch UI の検出ページ。Ask AI パネルにはクエリの説明と調査の開始ボタンが表示されます。\]](http://docs.aws.amazon.com/ja_jp/opensearch-service/latest/developerguide/images/agentic-chat-discover-ppl.png)
## 主な機能
+ **エージェントチャット** – OpenSearch UI のすべてのページの AI 機能に埋め込まれているエージェントチャットは、現在のコンテキストを理解し、データを分析して質問に最もよく答えるためのツールを呼び出します。Discover で、チャットインターフェイスに自然言語を入力して Piped Processing Language (PPL) クエリを生成して反復処理するため、実用的なインサイトを得るために PPL の専門家である必要はありません。エージェントチャットがグラフ内の異常を識別し、基盤となるデータと相関させ、分析を生成できる視覚化から直接会話を開始することもできます。複雑な根本原因分析が必要な場合は、`/investigate`スラッシュコマンドを使用して、進行中の会話または新しい指示に基づいて調査エージェントを起動します。
+ **調査エージェント** – チャット`/investigate`で入力するか、機能ページで**調査の開始ボタンを選択してアクティブ化する、目標駆動型の深層調査**エージェント。「このレイテンシースパイクの根本原因を見つける」などの調査目標を入力します。調査エージェントは、データと指定された目標を使用して自律的に計画し、クエリと分析を実行し、複数ステップのワークフローを通じて反映します。調査が完了すると、通常は数分以内に、データ証拠に基づいて、可能性別にランク付けされた構造化された仮説が生成されます。推論のすべてのステップを完全に透明化できるため、結果を検証して信頼できます。
+ **エージェントメモリ** – 会話や調査内のコンテキストを保持するサービスマネージドメモリレイヤー。一貫したコンテキスト内で質問や調査を継続できます。エージェントメモリを使用すると、エージェントチャットと調査エージェントの両方がセッション全体の継続性を維持できます。
## 料金と使用制限
エージェント AI 機能は無料で使用できます。トークンベースの使用制限は、不正使用を防ぐためにアカウントごとに適用されます。
エージェント AI 機能は、Amazon Bedrock の基盤モデルを使用します。すべての Amazon Bedrock セキュリティおよびデータガバナンス設定は、エージェント AI 機能に適用されます。詳細については、[「Amazon Bedrock でのデータ保護](https://docs.aws.amazon.com/bedrock/latest/userguide/data-protection.html)」を参照してください。
## セキュリティ
エージェント AI 機能は、既存のセキュリティフレームワーク内で動作し、設定されたアクセスコントロールをバイパスまたは上書きしません。エージェントチャットを操作するか、調査エージェントを起動すると、AI 機能は現在の IAM または IAM アイデンティティセンターの認証情報を使用して認証し、関連するすべてのアクセス許可を継承します。AI アシスタントは、既存のロールベースのアクセスコントロール (RBAC) ポリシーを通じて既に明示的にアクセスできるデータソース、インデックス、視覚化のみをクエリできます。
OpenSearch ドメインがフィールドレベルまたはドキュメントレベルのセキュリティを備えたきめ細かなアクセスコントロールを実装している場合、AI はこれらの制限を尊重し、アクセス許可の範囲外の制限されたフィールドまたはドキュメントのデータを表示することはできません。同様に、エージェントチャットによって生成された PPL クエリや調査中に実行されたデータ取り出しは、ユーザーコンテキストで実行され、設定されたすべてのセキュリティポリシーが完全に適用されるようにします。
このアクセス許可継承モデルにより、AI 機能を有効にしても、新しいセキュリティの脆弱性は発生せず、管理者は AI インタラクション用に個別のアクセス許可構造を管理する必要もありません。
## エージェント AI 機能の有効化と無効化
エージェント AI 機能は、OpenSearch ドメインのいずれかで AI 機能を明示的に無効にしない限り、新しい OpenSearch UI アプリケーションと既存のアプリケーションに対して自動的に有効になります。
AI 機能を有効または無効にするには、 AWS マネジメントコンソール または API を使用できます。
+ **コンソール** – OpenSearch UI アプリケーションの詳細ページに移動し、そこから AI 機能を更新します。
![\[コンソールの AI Assistant 機能の管理ページには、チャットボットとエージェントの調査機能の有効化チェックボックスと更新ボタンが表示されます。\]](http://docs.aws.amazon.com/ja_jp/opensearch-service/latest/developerguide/images/agentic-ai-manage-features.png)
+ **API** – [RegisterCapability](https://docs.aws.amazon.com/opensearch-service/latest/APIReference/API_RegisterCapability.html) API を使用して AI 機能を有効にするか、[DeregisterCapability](https://docs.aws.amazon.com/opensearch-service/latest/APIReference/API_DeregisterCapability.html) API を使用して無効にします。
## リージョンの可用性
エージェント AI の機能は次のとおりです AWS リージョン。
+ アジアパシフィック (東京) – ap-northeast-1
+ アジアパシフィック (シドニー) – ap-southeast-2
+ 欧州 (フランクフルト) – eu-central-1
+ 欧州 (ストックホルム) - eu-north-1
+ 欧州 (スペイン) eu-south-2
+ 欧州 (アイルランド) – eu-west-1
+ 米国東部 (バージニア北部) – us-east-1
+ 米国東部 (オハイオ) – us-east-2
+ 米国西部 (オレゴン) – us-west-2
**Topics**
+ [主な機能](#application-ai-assistant-key-capabilities)
+ [料金と使用制限](#application-ai-assistant-pricing)
+ [セキュリティ](#application-ai-assistant-security)
+ [エージェント AI 機能の有効化と無効化](#application-ai-assistant-enable-disable)
+ [リージョンの可用性](#application-ai-assistant-regions)
+ [Amazon OpenSearch Service のエージェントチャット](application-agentic-chat.md)
+ [Amazon OpenSearch Service の調査エージェント](application-investigation-agent.md)
+ [Amazon OpenSearch Service のエージェントメモリ](application-agentic-memory.md)
# Amazon OpenSearch Service のエージェントチャット
エージェントチャットは、OpenSearch UI のすべてのページに埋め込まれた AI アシスタントです。**Ask AI** ボタンを選択してチャットパネルを開き、データに関する質問、クエリの生成、調査の開始を行うことができます。エージェントチャットは、検出と調査で表示しているページのコンテキストを理解し、エージェントツールを使用して基盤となるデータを分析します。
![\[OpenSearch UI の検出ページでは、右上隅に Ask AI ボタンが強調表示されています。\]](http://docs.aws.amazon.com/ja_jp/opensearch-service/latest/developerguide/images/agentic-chat-ask-ai-button.png)
チャットパネルを開くと、エージェントチャットには、データに関する質問、問題の調査、概念の説明など、開始に役立つオプションが表示されます。以前に会話を開始した場合は、ページ間を移動するときにチャットパネルに表示されたままになるため、中断した場所を続行できます。または、右上隅の新しい**チャット**ボタンを選択して、新しい会話を開始します。
![\[エージェントチャットパネルには、AI Assistant のウェルカムメッセージと、データに関する質問、問題の調査、概念の説明のオプションが表示されます。\]](http://docs.aws.amazon.com/ja_jp/opensearch-service/latest/developerguide/images/agentic-chat-ask-ai-panel.png)
## Discover でのエージェントチャットの使用
オブザーバビリティワークスペースの検出ページで、チャットインターフェイスに自然言語を入力して PPL クエリを生成できます。エージェントチャットは質問を PPL に変換し、クエリを実行し、結果を検出ビューに直接表示します。データから実用的なインサイトを得るために、PPL の専門家である必要はありません。
生成されたクエリを絞り込むには、「ステータスコード 500 のフィルターを追加する」など、自然言語でフォローアップの質問をします。エージェントチャットは、現在のクエリのコンテキストを理解し、それに応じて変更します。集計の調整、時間範囲の変更、結果へのフィールドの追加を に依頼することもできます。反復するたびに、Discover ビューが新しいクエリ結果で更新されます。
## エージェントチャットとビジュアライゼーションの使用
エージェントチャットとの会話は、視覚化から直接開始できます。視覚化パネルのコンテキストメニューを開き、AI を**尋ねる**を選択します。エージェントチャットは、視覚化を分析し、グラフ内の異常を識別し、基盤となるデータと関連付けて、分析を生成します。
![\[OpenSearch UI の視覚化。コンテキストメニューの Ask AI オプションと、視覚化を分析するエージェントチャットパネルが表示されます。\]](http://docs.aws.amazon.com/ja_jp/opensearch-service/latest/developerguide/images/agentic-chat-visualization.png)
## チャットから調査を開始する
複雑な根本原因分析が必要な場合は、エージェントチャットから直接調査エージェントを起動できます。チャット入力で`/investigate`スラッシュコマンドを使用するか、機能ページで**調査の開始**ボタンを選択します。
調査エージェントの詳細については、「」を参照してください[Amazon OpenSearch Service の調査エージェント](application-investigation-agent.md)。
## サポートされているツール
エージェントチャットは、以下のツールを使用してデータを分析し、質問に回答します。利用可能なツールの最新up-to-dateリストを表示するには、チャットインターフェイスで「使用できるツール」と入力します。
**フロントエンドツール**
これらのツールは OpenSearch UI を更新します。
+ `create_investigation` – 目標、症状、インデックス、時間範囲などの詳細を含む新しいエージェント調査ノートブックを作成します。
+ `execute_ppl_query` – 現在のデータセットに対して PPL クエリを実行し、検出ページに結果を表示します。
+ `update_time_range` – 現在の検出ページのグローバル時間範囲フィルターを更新します (例：「過去 24 時間」または「先週」）。
**バックエンドツール**
これらのツールは OpenSearch データおよび APIs。
+ `SearchIndexTool` – DSL クエリを使用してインデックスを検索します。
+ `MsearchTool` – 1 つのリクエストで複数の検索オペレーションを実行します。
+ `CountTool` – クエリに一致するドキュメントの数を返します。
+ `ExplainTool` – ドキュメントがクエリと一致するか一致しない理由について説明します。
+ `ListIndexTool` – クラスター内のインデックスをオプションの詳細とともに一覧表示します。
+ `IndexMappingTool` – インデックスマッピングと設定を取得します。
+ `GetShardsTool` – インデックスのシャード情報を取得します。
+ `ClusterHealthTool` – クラスターのヘルス情報を返します。
+ `LogPatternAnalysisTool` – ログパターンを分析し、時間範囲を比較し、トレースシーケンス分析を実行します。
+ `MetricChangeAnalysisTool` – 2 つの時間範囲間の数値フィールドのパーセンタイル分布を比較します。
+ `DataDistributionTool` – オプションでベースラインと比較して、ターゲット時間範囲内のフィールド値の分布を分析します。
+ `GenericOpenSearchApiTool` – OpenSearch API エンドポイントを直接呼び出すための柔軟なツールです。
# Amazon OpenSearch Service の調査エージェント
調査エージェントは、OpenSearch UI の目標駆動型の深層調査エージェントであり、ユーザーに代わって複雑な問題を自律的に調査します。データおよび指定された目標を使用して計画し、クエリと分析を実行し、複数ステップのワークフローを通じて反映します。調査が完了すると、通常は数分以内に、データ証拠に基づいて、可能性別にランク付けされた構造化された仮説が生成されます。推論のすべてのステップを完全に透明化できるため、結果を検証して信頼できます。
## 調査の開始
調査は、次の 2 つの方法で開始できます。
+ 検出、視覚化、またはその他のサポートされている機能ページから、**調査の開始**ボタンを選択します。調査目標を入力し、「根本原因分析」や「パフォーマンスの問題」などの推奨テンプレートから選択できるダイアログが表示されます。
+ エージェントチャットから、調査目標を含むチャット入力に`/investigate`スラッシュコマンドを入力します。
![\[調査開始ダイアログには、調査目標のテキストフィールドと、根本原因分析とパフォーマンスの問題に関する推奨テンプレートが表示されます。\]](http://docs.aws.amazon.com/ja_jp/opensearch-service/latest/developerguide/images/investigation-agent-start.png)
エージェントチャットの詳細については、「」を参照してください[Amazon OpenSearch Service のエージェントチャット](application-agentic-chat.md)。
## 調査結果の確認
調査が完了すると、調査エージェントは信頼度と裏付けとなる証拠を含む主要な仮説を提示します。結果ページには、実行された調査手順、重要度別にランク付けされた関連する結果、代替仮説が表示されます。
![\[Accept オプションと Rule out オプション、重要度でランク付けされた関連する結果、代替仮説を含む主要な仮説を示す調査結果ページ。\]](http://docs.aws.amazon.com/ja_jp/opensearch-service/latest/developerguide/images/investigation-agent-results.png)
各仮説の背後にある結果を確認し、**Accept** を選択して仮説を確認するか、**Rule out** を選択して拒否することができます。可能性の低い代替仮説もレビューできます。評価により一致すれば、最終結論として代替仮説を選択できます。
## 再調査
調査結果をより明確にする必要がある場合、または調査エージェントが調査の質問に回答できないと判断した場合は、**再調査**オプションを使用して調査を調整および再実行できます。**再調査**を選択して最初の目標を編集し、時間範囲を調整し、オプションで既存の仮説と結果を新しい調査に取り込みます。
![\[問題の再調査ダイアログには、最初の目標を編集し、時間範囲を調整し、既存の仮説と結果を新しい調査に取り込むオプションが表示されます。\]](http://docs.aws.amazon.com/ja_jp/opensearch-service/latest/developerguide/images/investigation-agent-reinvestigate.png)
# Amazon OpenSearch Service のエージェントメモリ
エージェントメモリは、エージェントチャットと調査エージェントを強化するサービスマネージドメモリレイヤーです。会話や調査にコンテキストを保持するため、さまざまな機能ページ、ブラウザタブ、ページの更新で一貫したエクスペリエンスが得られます。エージェントメモリは自動的に動作し、ユーザー設定は必要ありません。
エージェントメモリは、OpenSearch エージェントメモリフレームワーク上に構築されています。メモリストレージは、プライバシーのためにユーザー ID によって分離されます。
## データ保護
エージェントメモリは無料で使用できます。エージェントメモリに保存されている顧客データは、サービスマネージドキーで暗号化されます。OpenSearch UI アプリケーションのカスタマーマネージドキー (CMK) 暗号化を有効にした場合、メモリデータは代わりに CMK で暗号化されます。メモリは、サービス管理の Amazon OpenSearch Serverless コレクションに保存されます。
CMK 暗号化の詳細については、「」を参照してください[カスタマーマネージドキーを使用した OpenSearch UI アプリケーションメタデータの暗号化](application-encryption-cmk.md)。
## 制限事項
エージェントメモリは、異なる会話スレッド間でコンテキストを保持することはできません。
# カスタマーマネージドキーを使用した OpenSearch UI アプリケーションメタデータの暗号化
ビジュアルアセットと設定は、OpenSearch UI アプリケーションのメタデータとして保存されます。これには、保存されたクエリ、視覚化、ダッシュボードが含まれます。関連付けられたデータソースからのデータはメタデータに保存されません。データソース内のデータの暗号化の詳細については、[「Amazon OpenSearch Service for OpenSearch ドメインでのデータ保護](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/data-protection.html)」および[「サーバーレスコレクションでの Amazon OpenSearch Serverless での暗号化](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/serverless-encryption.html)」を参照してください。 OpenSearch
OpenSearch UI メタデータは、保管時の暗号化で保護されます。これにより、不正アクセスが防止されます。暗号化では、 AWS Key Management Service (AWS KMS) を使用して暗号化キーを保存および管理します。デフォルトでは、OpenSearch UI メタデータは AWS 所有キーで暗号化されます。
カスタマーマネージドキー (CMK) 機能を使用して、独自の暗号化キーを管理することもできます。これにより、規制とコンプライアンスの要件を満たすことができます。CMK を使用するには、新しい OpenSearch UI アプリケーションを作成し、作成プロセスで CMK を有効にする必要があります。現在、既存の OpenSearch UI アプリケーションを AWS 所有キーから CMK に更新することはサポートされていません。
カスタマーマネージドキーを使用するタイミング:
+ 組織にキー管理に関する規制コンプライアンス要件がある
+ 暗号化キーの使用には監査証跡が必要です
+ キーローテーションスケジュールを制御する場合
+ 既存のキー管理ワークフローと統合する必要があります
カスタマーマネージドキーを使用すると、キーを完全に制御できます。これには、次の機能が含まれます。
+ キーポリシーの確立と維持
+ IAM ポリシーとグラントの確立と維持
+ キーを有効または無効にする
+ キーの暗号化マテリアルをローテーションする
+ キーにタグを追加する
+ キーエイリアスの作成
+ キーの削除をスケジュールする
**注記**
カスタマーマネージドキーは、OpenSearch UI アプリケーション AWS リージョン と同じ にある必要があります。別のリージョンのキーを使用することはできません。
**Topics**
+ [カスタマーマネージドキーを使用するための前提条件](#application-encryption-cmk-prerequisites)
+ [コンソールを使用したカスタマーマネージドキー暗号化を使用したアプリケーションの作成](#application-encryption-cmk-create-console)
+ [を使用したカスタマーマネージドキー暗号化によるアプリケーションの作成 AWS CLI](#application-encryption-cmk-create-cli)
+ [カスタマーマネージドキーの使用状況のモニタリング](#application-encryption-cmk-monitoring)
+ [暗号化設定の更新](#application-encryption-cmk-update)
## カスタマーマネージドキーを使用するための前提条件
カスタマーマネージドキーを使用して OpenSearch UI アプリケーションメタデータを暗号化する前に、 で対称暗号化キーを作成する必要があります AWS KMS。キーの作成手順については、「 *AWS KMS デベロッパーガイド*」の[「キーの作成](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html)」を参照してください。
カスタマーマネージドキーのキーポリシーは、そのキーを使用するアクセス許可を OpenSearch UI に付与する必要があります。次のキーポリシーを使用して、*プレースホルダー値を*独自の情報に置き換えます。
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowOpenSearchUIToUseKey",
"Effect": "Allow",
"Principal": {
"Service": [
"application.opensearchservice.amazonaws.com"
]
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:GenerateDataKey",
"kms:DescribeKey"
],
"Resource": "*"
},
{
"Sid": "AllowKeyAdministration",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::account-id:root"
},
"Action": "kms:*",
"Resource": "*"
}
]
}
```
ポリシーには、2 つのステートメントが含まれています。
+ 最初のステートメントでは、OpenSearch UI が暗号化オペレーションに キーを使用することを許可します。
+ 2 番目のステートメントでは、 のユーザーがキーを管理 AWS アカウント できるようにします。これには、キーポリシーを更新し、キーを有効または無効にし、キーの削除をスケジュールするアクセス許可が含まれます。ルートプリンシパルを特定の IAM ユーザーまたはロールに置き換えることで、これらのアクセス許可をさらに制限できます。
キーポリシーの詳細については、 *AWS KMS デベロッパーガイド*の[「 でのキーポリシー AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html)の使用」を参照してください。
## コンソールを使用したカスタマーマネージドキー暗号化を使用したアプリケーションの作成
コンソールで OpenSearch UI アプリケーションを作成するときに、アプリケーションのメタデータを暗号化するためのカスタマーマネージドキーを指定できます。
**コンソールを使用してカスタマーマネージドキー暗号化を使用して OpenSearch UI アプリケーションを作成するには**
1. [https://console.aws.amazon.com/aos/home](https://console.aws.amazon.com/aos/home) で Amazon OpenSearch Service コンソールにサインインします。
1. 左のナビゲーションペインの **[OpenSearch UI (ダッシュボード)]** を選択します。
1. [**アプリケーションを作成**] を選択します。
1. **[アプリケーション名]** に、そのアプリケーションの名前を入力します。
1. 必要に応じて、認証と管理者の設定を行います。詳細については、「[Amazon OpenSearch Service における OpenSearch ユーザーインターフェースの開始方法](application-getting-started.md)」を参照してください。
1. **「暗号化**」セクションの**「保管時の暗号化**」で、**「カスタマーマネージドキーを使用する**」を選択します。
1. リストから既存のカスタマーマネージドキーを選択するか、**キーの作成**を選択して新しいキーを作成します AWS KMS。
**注記**
キーは、作成するアプリケーション AWS リージョン と同じ にある必要があります。
1. (オプション) アプリケーションにタグを追加します。
1. **[作成]** を選択します。
## を使用したカスタマーマネージドキー暗号化によるアプリケーションの作成 AWS CLI
を使用してカスタマーマネージドキー暗号化を使用して OpenSearch UI アプリケーションを作成するには AWS CLI、 `--kms-key-arn`パラメータを指定して [create-application](https://docs.aws.amazon.com/cli/latest/reference/opensearch/create-application.html) コマンドを使用します。
*プレースホルダー値*を、ユーザー自身の情報に置き換えます。
```
aws opensearch create-application \
--name my-application \
--kms-key-arn arn:aws:kms:us-east-1:123456789012:key/12345678-1234-1234-1234-123456789012
```
`--kms-key-arn` パラメータを指定しない場合、OpenSearch は AWSマネージドキーを使用してアプリケーションのメタデータを暗号化します。
## カスタマーマネージドキーの使用状況のモニタリング
OpenSearch UI アプリケーションでカスタマーマネージドキーを使用する場合、 AWS KMS はキーのすべての使用を AWS CloudTrail ログに記録します。これらのログを使用して、キーの使用方法とタイミングをモニタリングできます。ログには、キーにアクセスしたユーザーまたはサービスが表示されます。
AWS AWS KMS は、カスタマーマネージドキーを毎年自動的にローテーションします。必要に応じてキーを手動でローテーションすることもできます。キーローテーションの詳細については、 *AWS KMS デベロッパーガイド*の[「KMS キーのローテーション](https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html)」を参照してください。
キー使用状況のモニタリングの詳細については、「 *AWS KMS デベロッパーガイド*」の「 [を使用した AWS KMS API コールのログ記録 AWS CloudTrail](https://docs.aws.amazon.com/kms/latest/developerguide/logging-using-cloudtrail.html)」を参照してください。
**注記**
カスタマーマネージドキーを使用すると、 AWS KMS 料金が発生します。料金は、保存された API リクエストとキーの数に基づいています。料金の詳細については、[AWS 「 Key Management Service の料金](https://aws.amazon.com/kms/pricing/)」を参照してください。
## 暗号化設定の更新
OpenSearch UI アプリケーションを作成した後は、暗号化設定を変更することはできません。別のカスタマーマネージドキーを使用する必要がある場合は、新しいアプリケーションを作成する必要があります。 AWSマネージドキーとカスタマーマネージドキーを切り替える必要がある場合は、必要な暗号化設定で新しいアプリケーションを作成する必要があります。
**重要**
カスタマーマネージドキーを無効化または削除する前に、次の点を考慮してください。
キーを無効にすると、アプリケーションは暗号化されたメタデータにアクセスできなくなります。アクセスを復元するには、同じキーを再度有効にする必要があります。
キーを削除すると、アプリケーションの保存されたオブジェクトに永続的にアクセスできなくなります。これには、クエリ、ビジュアライゼーション、ダッシュボードが含まれます。削除されたキーは復元できません。
キーステータスを変更する前に、キー ARN を文書化することをお勧めします。
**次の手順**
アプリケーションの CMK 暗号化を設定したら、次のことができます。
+ データソースをアプリケーションに関連付けます。詳細については、「[データソースの関連付けと Virtual Private Cloud アクセス許可の管理](application-data-sources-and-vpc.md)」を参照してください。
+ チームのワークスペースを作成します。詳細については、「[Amazon OpenSearch Service ワークスペースの使用](application-workspaces.md)」を参照してください。
+ キー使用状況 AWS CloudTrail のモニタリングを設定します。詳細については、「[カスタマーマネージドキーの使用状況のモニタリング](#application-encryption-cmk-monitoring)」を参照してください。
# での SAML フェデレーションの有効化 AWS Identity and Access Management
OpenSearch UI は、多くの ID プロバイダーが使用するオープンスタンダードである Security Assertion Markup Language 2.0 (SAML) をサポートしています。これにより、 AWS Identity and Access Management (IAM) との ID フェデレーションが可能になります。このサポートにより、アカウントまたは組織のユーザーは、IAM ロールを引き受けることで OpenSearch UI に直接アクセスできます。エンドユーザーが外部 ID プロバイダーで認証し、OpenSearch UI の定義されたページに直接ルーティングできる ID プロバイダー主導 (IdP) シングルサインオンエクスペリエンスを作成できます。OpenSearch UI および関連するデータソースにアクセスするためのアクセス許可が異なるさまざまな IAM ロールを引き受けるように、エンドユーザーまたはグループを設定することで、詳細なアクセス制御を実装することもできます。
このトピックでは、OpenSearch UI で SAML を使用するための設定手順を段階的に説明します。これらの手順では、例として Okta アイデンティティおよびアクセス管理アプリケーションを設定する手順を使用します。Azure Active Directory や Ping など、他の ID プロバイダーの設定手順は似ています。
**Topics**
+ [ステップ 1: ID プロバイダーアプリケーションを設定する (Okta)](#SAML-identity-federation-step-1)
+ [ステップ 2: Okta AWS の設定をセットアップする](#SAML-identity-federation-step-2)
+ [ステップ 3: IAM で Amazon OpenSearch Service アクセスポリシーを作成する](#SAML-identity-federation-step-3)
+ [ステップ 4: SAML で ID プロバイダーが開始したシングルサインオンエクスペリエンスを検証する](#SAML-identity-federation-step-4)
+ [ステップ 5: SAML 属性ベースの詳細なアクセス制御を設定する](#SAML-identity-federation-step-5)
## ステップ 1: ID プロバイダーアプリケーションを設定する (Okta)
OpenSearch UI で SAML を使用するには、まず ID プロバイダーを設定します。
**タスク 1: Okta ユーザーを作成する**
1. 管理者権限を持つユーザーとして、[https://login.okta.com/](https://login.okta.com/) で Okta 組織にサインインします。
1. 管理者コンソールのナビゲーションペインの **[ディレクトリ]** で、**[ユーザー]** を選択します。
1. **[Add Person]** (ユーザーを追加) を選択します。
1. **[名前]** には、ユーザーの名前を入力します。
1. **[姓]** には、ユーザーの姓を入力します。
1. **[ユーザー名]** には、ユーザーのユーザー名を E メール形式で入力します。
1. **[パスワードを設定する]** を選択してパスワードを入力します。
1. (オプション) ユーザーが初回サインイン時にパスワードを変更する必要がない場合は、**[初回ログイン時にパスワードを変更する必要があります]** チェックボックスをオフにします。
1. **[保存]** を選択します。
**タスク 2: グループを作成して割り当てる**
1. 管理者権限を持つユーザーとして、[https://login.okta.com/](https://login.okta.com/) で Okta 組織にサインインします。
1. 管理者コンソールのナビゲーションペインの **[ディレクトリ]** で、**[グループ]** を選択します。
1. **[グループの追加]** を選択します。
1. グループ名を入力し、**[保存]** を選択します。
1. 新しく作成したグループを選択し、**[ユーザーの割り当て]** を選択します。
1. プラス記号 (**[\$1]**) を選択し、**[完了]** を選択します。
1. (オプション) ステップ 1～6 を繰り返して、さらにグループを追加します。
**タスク 3: Okta アプリケーションを作成する**
1. 管理者権限を持つユーザーとして、[https://login.okta.com/](https://login.okta.com/) で Okta 組織にサインインします。
1. 管理者コンソールのナビゲーションペインの **[アプリケーション]** で、**[アプリケーション]** を選択します。
1. **[Create App Integration]** (アプリの統合の作成) を選択します。
1. サインイン方法として SAML 2.0 を選択し、**[次へ]** を選択します。
1. アプリ統合用の名前 (**OpenSearch\$1UI** など) を入力し、**[次へ]** を選択します。
1. アプリに次の値を入力します。他の値を変更する必要はありません。
1. 1. **シングルサインオン URL** の場合は、商用 AWS リージョン**https://signin.aws.amazon.com/saml**に を入力するか、リージョン固有の URL を入力します。
1. 2. **[オーディエンス URI (SP Entity ID)]** には、**urn:amazon:webservices** を入力します。
1. 3. **[名前の形式]** には **EmailAddress** を入力します。
1. [**次へ**] を選択します。
1. **[私は Okta の顧客で、内部アプリを追加します]** を選択し、次に **[これは当社が作成した内部アプリです]** を選択します。
1. [**Finish**] を選択してください。
1. **[割り当て]** を選択してから、**[割り当てる]** を選択します。
1. **[グループに割り当てる]** を選択し、追加するグループの横にある **[割り当てる]** を選択します。
1. **[Done]** (完了) をクリックします。
**タスク 4: Okta の詳細設定をセットアップする**
カスタム SAML アプリケーションを作成したら、次の手順を実行します。
1. 管理者権限を持つユーザーとして、[https://login.okta.com/](https://login.okta.com/) で Okta 組織にサインインします。
管理者コンソールの **[全般]** エリアで、**[SAML 設定]** で **[編集]** を選択します。
1. [**次へ**] を選択します。
1. 次の形式を使用して、**[デフォルトのリレーステート]** を OpenSearch UI エンドポイントに設定します:
`https://region.console.aws.amazon.com/aos/home?region=region#opensearch/applications/application-id/redirectToDashboardURL`.
以下に例を示します。
`https://us-east-2.console.aws.amazon.com/aos/home?region=us-east-2#opensearch/applications/abc123def4567EXAMPLE/redirectToDashboardURL`
1. **[属性ステートメント (オプション)]** で、以下のプロパティを追加します。
1. **[ロール]** 属性を使用して、IAM ロールと ID プロバイダーをカンマ区切り形式で指定します。この同じ IAM ロールと ID プロバイダーは、後のステップで AWS 設定時に使用します。
1. **[RoleSessionName]** の **[user.login]** を設定します。これは、ロールが引き受けられたときに発行される一時的な認証情報の識別子として使用されます。
参考までに:
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/opensearch-service/latest/developerguide/application-enable-SAML-identity-federation.html)
1. 属性プロパティを追加したら、**[次へ]** を選択し、**[終了]** を選択します。
属性は、以下の画像に示されているものと同様の形式である必要があります。**[デフォルトのリレーステート]** 値は、Okta からのシングルサインオン検証を完了した後、アカウントまたは組織のエンドユーザー向けランディングページを定義する URL です。OpenSearch UI の任意のページに設定し、その URL を目的のエンドユーザーに提供できます。
![\[「SAML 2.0」エリアは、アプリケーションのデフォルトのリレーステート URL とメタデータ URL を報告します。\]](http://docs.aws.amazon.com/ja_jp/opensearch-service/latest/developerguide/images/ui-saml-2.0-area-okta.png)
## ステップ 2: Okta AWS の設定をセットアップする
Okta AWS の設定を設定するには、次のタスクを実行します。
**タスク 1: Okta 情報を収集する**
このステップでは、Okta 情報を収集して、後で AWSで設定できるようにする必要があります。
1. 管理者権限を持つユーザーとして、[https://login.okta.com/](https://login.okta.com/) で Okta 組織にサインインします。
1. **[サインオン]** タブのページの右下隅で、**[SAML セットアップ手順の表示]** を選択します。
1. **[ID プロバイダーシングルサインオン URL]** の値をコピーまたは保存します。この URL は、SQL [Workbench/J](https://www.sql-workbench.eu/) などのサードパーティー SQL クライアントに接続するときに使用できます。
1. ブロック 4 で ID プロバイダーメタデータを使用し、メタデータファイルを .xml 形式 (例: `metadata.xml`) で保存します。
**タスク 2: IAM プロバイダーを作成する**
IAM プロバイダーを作成するには、次の手順を実行します。
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) で IAM コンソールを開きます。
1. ナビゲーションペインの **[アクセス管理]** で **[ID プロバイダー]** を選択します。
1. **[プロバイダーを追加]** をクリックします。
1. **[プロバイダーのタイプ]** に、**[SAML]** を選択します。
1. **[プロバイダー名]** に名前を入力します。
1. **[メタデータドキュメント]** で、**[ファイルを選択]** を選択し、前にダウンロードしたメタデータファイル (.xml) をアップロードします。
1. **[プロバイダーを追加]** をクリックします。
**タスク 3: IAM ロールを作成する**
AWS Identity and Access Management ロールを作成するには、次の手順を実行します。
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) で IAM コンソールを開きます。
1. ナビゲーションペインの **[アクセス管理]** で、**[ロール]** を選択します。
1. [**ロールの作成**] を選択してください。
1. **[信頼されたエンティティタイプ]** で、**[SAML 2.0 フェデレーション]** を選択します。
1. **[SAML 2.0 ベースのプロバイダー]** として、前に作成した ID プロバイダーを選択します。
1. **プログラムによるアクセスと AWS マネジメントコンソール アクセスを許可する**を選択します。
1. [**次へ**] を選択します。
1. アクセス**許可ポリシー**リストで、 AWS 管理ポリシー **AmazonOpenSearchServiceFullAccess** OpenSearch Service のアクセス許可を付与するポリシーのチェックボックスをオンにします。
1. [**次へ**] を選択します。
1. **[確認]** エリアの **[ロール名]** に、ロールの名前を入力します (例: **oktarole**)。
1. (オプション) **[説明]** に、ロールの目的についての簡単な説明を入力してください。
1. [**ロールの作成**] を選択してください。
1. 先ほど作成したロールに移動し、**[信頼関係]** タブを選択し、**[信頼ポリシーを編集]** を選択します。
1. **[ステートメントを編集]** ペインの **「STS のアクションを追加]** で、**[TagSession]** のボックスを選択します。
1. [**ポリシーの更新**] を選択してください。
## ステップ 3: IAM で Amazon OpenSearch Service アクセスポリシーを作成する
OpenSearch アクセス制御の IAM ロールを設定する方法について説明します。IAM ロールを使用すると、Okta ユーザーグループが OpenSearch リソースにアクセスするための詳細なアクセス制御を実装できます。このトピックでは、2 つのサンプルグループを使用した IAM ロールベースの設定を示します。
------
#### [ Sample group: Alice ]
リクエスト:
```
GET _plugins/_security/api/roles/alice-group
```
結果:
```
{
"alice-group": {
"reserved": false,
"hidden": false,
"cluster_permissions": [
"unlimited"
],
"index_permissions": [
{
"index_patterns": [
"alice*"
],
"dls": "",
"fls": [],
"masked_fields": [],
"allowed_actions": [
"indices_all"
]
}
],
"tenant_permissions": [
{
"tenant_patterns": [
"global_tenant"
],
"allowed_actions": [
"kibana_all_write"
]
}
],
"static": false
}
}
```
------
#### [ Sample group: Bob ]
リクエスト:
```
GET _plugins/_security/api/roles/bob-group
```
結果:
```
{
"bob-group": {
"reserved": false,
"hidden": false,
"cluster_permissions": [
"unlimited"
],
"index_permissions": [
{
"index_patterns": [
"bob*"
],
"dls": "",
"fls": [],
"masked_fields": [],
"allowed_actions": [
"indices_all"
]
}
],
"tenant_permissions": [
{
"tenant_patterns": [
"global_tenant"
],
"allowed_actions": [
"kibana_all_write"
]
}
],
"static": false
}
}
```
------
次の例に示すように、バックエンドロールマッピングを使用して Amazon OpenSearch Service ドメインロールを IAM ロールにマッピングできます。
```
{
"bob-group": {
"hosts": [],
"users": [],
"reserved": false,
"hidden": false,
"backend_roles": [
"arn:aws:iam::111222333444:role/bob-group"
],
"and_backend_roles": []
},
"alice-group": {
"hosts": [],
"users": [],
"reserved": false,
"hidden": false,
"backend_roles": [
"arn:aws:iam::111222333444:role/alice-group"
],
"and_backend_roles": []
}
}
```
## ステップ 4: SAML で ID プロバイダーが開始したシングルサインオンエクスペリエンスを検証する
**[デフォルトのリレーステート]** URL を開き、Okta 認証ページを開きます。エンドユーザーの認証情報を入力します。OpenSearch UI に自動的にリダイレクトされます。
次の図に示すように、ナビゲーションパネルの下部にあるユーザーアイコンを選択すると、現在の認証情報を確認できます。
![\[Okta の「設定とセットアップ」ページでユーザーアイコンを選択すると、現在のユーザーの認証情報が表示されます。\]](http://docs.aws.amazon.com/ja_jp/opensearch-service/latest/developerguide/images/ui-okta-user-icon.png)
ナビゲーションパネルの下部にある開発者ツールにアクセスし、コンソールでクエリを実行することで、ユーザーの詳細なアクセス制御の権限を確認することもできます。次にサンプルクエリを示します:
------
#### [ Example 1: Displays information about the current user ]
リクエスト:
```
GET _plugins/_security/api/account
```
結果:
```
{
"user_name": "arn:aws:iam::XXXXXXXXXXXX:role/bob-group",
"is_reserved": false,
"is_hidden": false,
"is_internal_user": false,
"user_requested_tenant": null,
"backend_roles": [
"arn:aws:iam::XXXXXXXXXXXX:role/bob-group"
],
"custom_attribute_names": [],
"tenants": {
"global_tenant": true,
"arn:aws:iam::XXXXXXXXXXXX:role/bob-group": true
},
"roles": [
"bob-group"
]
}
```
------
#### [ Example 2: Displays actions permitted for a user ]
リクエスト:
```
GET bob-test/_search
```
結果:
```
{
"took": 390,
"timed_out": false,
"_shards": {
"total": 5,
"successful": 5,
"skipped": 0,
"failed": 0
},
"hits": {
"total": {
"value": 1,
"relation": "eq"
},
"max_score": 1,
"hits": [
{
"_index": "bob-test",
"_id": "ui01N5UBCIHpjO8Jlvfy",
"_score": 1,
"_source": {
"title": "Your Name",
"year": "2016"
}
}
]
}
}
```
------
#### [ Example 3: Displays actions not permitted for a user ]
リクエスト:
```
GET alice-test
```
結果:
```
{
"error": {
"root_cause": [
{
"type": "security_exception",
"reason": "no permissions for [indices:admin/get] and User [name=arn:aws:iam::111222333444:role/bob-group, backend_roles=[arn:aws:iam::111222333444:role/bob-group], requestedTenant=null]"
}
],
"type": "security_exception",
"reason": "no permissions for [indices:admin/get] and User [name=arn:aws:iam::111222333444:role/bob-group, backend_roles=[arn:aws:iam::111222333444:role/bob-group], requestedTenant=null]"
},
"status": 403
}
```
------
## ステップ 5: SAML 属性ベースの詳細なアクセス制御を設定する
Amazon OpenSearch Service を使用すると、SAML による詳細なアクセス制御を使用して、ID プロバイダーのユーザーとグループを OpenSearch の詳細なアクセス制御のユーザーやロールに動的にマッピングできます。これらのロールを特定の OpenSearch ドメインとサーバーレスコレクションにスコープし、インデックスレベルのアクセス許可とドキュメントレベルのセキュリティを定義できます。
**注記**
詳細なアクセス制御の詳細については、「[Amazon OpenSearch Service のきめ細かなアクセスコントロール](fgac.md)」を参照してください。
**Topics**
+ [詳細なアクセス制御のための SAML 属性](#saml-fgac-key-attributes)
+ [タスク 1: 詳細なアクセス制御のために Okta を設定する](#configure-okta-fgac)
+ [タスク 2: OpenSearch ドメインで SAML を設定する](#configure-opensearch-domain-fgac)
+ [タスク 3: OpenSearch Serverless コレクションで SAML を設定する](#saml-configure-collections)
### 詳細なアクセス制御のための SAML 属性
**subjectKey**
E メールやユーザー名などの一意のユーザー属性にマッピングされ、認証するユーザーを識別します。
**rolesKey**
認可するためのロールまたはアクセス許可を決定する IdP のグループまたはロール属性にマッピングします。
### タスク 1: 詳細なアクセス制御のために Okta を設定する
**詳細なアクセス制御のために Okta を設定するには**
1. **[属性ステートメント]** セクションに OpenSearch ユーザープリンシパルの新しい属性を追加します。
+ 名前: `UserName`
+ 値: `${user-email}`
この属性は、認証用の OpenSearch きめ細かなアクセスコントロール設定の **[サブジェクトキー]** として使用されます。
1. **[グループ属性ステートメント]** セクションにロール用のグループ属性を追加します:
+ 名前: `groups`
+ フィルタ: `OpenSearch_xxx`
この属性は、認可するためのグループを OpenSearch の詳細なアクセス制御ロールにマッピングするための **[ロールキー]** として使用されます。
### タスク 2: OpenSearch ドメインで SAML を設定する
**OpenSearch ドメインで SAML を設定するには**
1. AWS マネジメントコンソールで、OpenSearch UI ユーザーのきめ細かなアクセスコントロールを有効にする OpenSearch Service ドメインを特定します。
1. 特定のドメインの詳細ページに移動します。
1. **[セキュリティ設定]** タブを選択し、**[編集]** をクリックします。
1. **[IAM フェデレーションを使用する SAML]** を拡張します。
1. Okta で定義した `subjectKey` と `roleKey` を入力します。
1. **[変更を保存]** を選択します。
AWS CLIを使用して詳細なアクセス制御を設定することもできます。
```
aws opensearch create-domain \
--domain-name testDomain \
--engine-version OpenSearch_1.3 \
--cluster-config InstanceType=r5.xlarge.search,InstanceCount=1,DedicatedMasterEnabled=false,ZoneAwarenessEnabled=false,WarmEnabled=false \
--access-policies '{"Version": "2012-10-17", "Statement":[{"Effect":"Allow","Principal":{"AWS":"*"},"Action":"es:*","Resource":"arn:aws:es:us-east-1:12345678901:domain/neosaml10/*"}]}' \
--domain-endpoint-options '{"EnforceHTTPS":true,"TLSSecurityPolicy":"Policy-Min-TLS-1-2-2019-07"}' \
--node-to-node-encryption-options '{"Enabled":true}' \
--encryption-at-rest-options '{"Enabled":true}' \
--advanced-security-options '{"Enabled":true,"InternalUserDatabaseEnabled":true,"MasterUserOptions":{"MasterUserName":"********","MasterUserPassword":"********"}, "IAMFederationOptions":{"Enabled": true,"SubjectKey":"TestSubjectKey","RolesKey":"TestRolesKey"}}' \
--ebs-options "EBSEnabled=true,VolumeType=gp2,VolumeSize=300" \
--no-verify-ssl \
--endpoint-url https://es.us-east-1.amazonaws.com \
--region us-east-1
```
既存のドメインを更新するには:
```
aws opensearch update-domain-config \
--domain-name testDomain \
--advanced-security-options '{"Enabled":true,"InternalUserDatabaseEnabled":true,"MasterUserOptions":{"MasterUserName":"********","MasterUserPassword":"********"}, "IAMFederationOptions":{"Enabled": true,"SubjectKey":"TestSubjectKey","RolesKey":"TestRolesKey"}}' \
--ebs-options "EBSEnabled=true,VolumeType=gp2,VolumeSize=300" \
--no-verify-ssl \
--endpoint-url https://es.us-east-1.amazonaws.com \
--region us-east-1
```
### タスク 3: OpenSearch Serverless コレクションで SAML を設定する
**OpenSearch Serverless で SAML ベースの詳細なアクセス制御を設定するには**
1. を開き AWS マネジメントコンソール 、Amazon OpenSearch Service に移動します。
1. ナビゲーションペインの **[サーバーレス]** で、**[セキュリティ]** を選択し、**[認証]** を選択します。
1. **[IAM フェデレーション]** セクションで、**[編集]** を選択します。
この設定を使用して、SAML 属性ベースの詳細なアクセス制御を制御できます。IAM フェデレーションはデフォルトで無効になっています。
1. **[IAM フェデレーションを有効にする]** を選択します。
1. Okta で定義した `subjectKey` と `roleKey` の値を入力します。
詳細については、「[詳細なアクセス制御のための SAML 属性](#saml-fgac-key-attributes)」を参照してください。
1. **[Save]** (保存) をクリックします。
1. ナビゲーションペインで、**[サーバーレス]** の **[データアクセスポリシー]** を選択します。
1. 既存のポリシーを更新するか、新しいポリシーを作成します。
1. ルールを展開し、**[プリンシパルを追加]** を選択し、**[IAM フェデレーションのユーザーとグループ]** を選択します。
1. 必要なプリンシパルを追加し、**[保存]** を選択します。
1. **[付与]** を選択します。
1. このルールで、次の操作を行います。
+ 選択したプリンシパルに対して定義するアクセス許可を選択します。
+ アクセス許可を適用するコレクションを指定します。
+ 必要に応じて、インデックスレベルのアクセス許可を定義します。
**注記**
複数のルールを作成して、異なるプリンシパルグループに異なるアクセス許可を割り当てることができます。
1. 完了したら、**[保存]** を選択します。
1. **[作成]** を選択します。
または、CLI を使用して、次に示すようにコレクションのセキュリティ設定を作成することもできます。
```
aws opensearchserverless create-security-config --region "region" --type iamfederation --name "configuration_name" --description "description" --iam-federation-options '{"groupAttribute":"GroupKey","userAttribute":"UserKey"}'
```
# データソースの関連付けと Virtual Private Cloud アクセス許可の管理
このセクションの手順を使用して、データソースの関連付けを管理し、仮想プライベートクラウド (VPC) に必要なアクセス許可を設定します。
**Topics**
+ [データソースと OpenSearch UI アプリケーションの関連付け](#application-data-source-association)
+ [VPC 内のドメインへのアクセスの管理](#application-manage-vpc-access)
+ [VPC 内の OpenSearch Serverless コレクションへのアクセスの設定](#application-configure-vpc-access-serverless-connections)
## データソースと OpenSearch UI アプリケーションの関連付け
OpenSearch UI アプリケーションを作成したら、コンソールまたは を使用して AWS CLI 1 つ以上のデータソースに関連付けることができます。その後、エンドユーザーはこれらのデータソースからデータを取得して、検索、ダッシュボードの操作などを行うことができます。
### データソースを OpenSearch UI アプリケーションに関連付ける (コンソール)
**コンソールを使用してデータソースを OpenSearch UI アプリケーションに関連付けるには**
1. [https://console.aws.amazon.com/aos/home](https://console.aws.amazon.com/aos/home) で Amazon OpenSearch Service コンソールにサインインします。
1. **[OpenSearch UI (ダッシュボード)]** を選択し、OpenSearch UI アプリケーションの名前を選択します。
1. **[関連付けられたデータソース]** エリアで、**[データソースを管理]** を選択します。
1. アプリケーションに関連付ける OpenSearch ドメインとコレクションから選択します。
**ヒント**
探しているデータソースが見つからない場合は、管理者に連絡して必要なアクセス許可を付与してください。詳細については、「[IAM Identity Center 認証を使用するアプリケーションを作成するアクセス許可 (オプション)](application-getting-started.md#prerequisite-permissions-idc)」を参照してください。
1. **[次へ]** を選択してから、**[保存]** を選択します。
データソースをアプリケーションに関連付けると、アプリケーションの詳細ページで **[アプリケーションの起動]** ボタンが有効になります。**[アプリケーションを起動]** を選択して、ワークスペースを作成および管理できる **[OpenSearch へようこそ]** ページを開くことができます。
ワークスペースの詳しい使い方については、「[Amazon OpenSearch Service ワークスペースの使用](application-workspaces.md)」を参照してください。
## VPC 内のドメインへのアクセスの管理
VPC 内の OpenSearch ドメインがアプリケーションに関連付けられている場合、VPC 管理者はコンソールまたは AWS CLIを使用して OpenSearch UI と VPC 間のアクセスを許可する必要があります。
### VPC 内のドメインへのアクセスの管理 (コンソール)
**AWS マネジメントコンソールを使用して VPC ドメインへのアクセスを設定するには:**
1. [https://console.aws.amazon.com/aos/home](https://console.aws.amazon.com/aos/home) で Amazon OpenSearch Service コンソールにサインインします。
1. 左側のナビゲーションペインで、**[ドメイン]** を選択し、VPC ドメインの名前を選択します。
-または-
**[ドメインを作成]** を選択し、ドメインの詳細を設定します。
1. **[VPC エンドポイント]** タブを選択し、**[プリンシパルの承認]** を選択します。
1. プリン**シパルの承認**ダイアログボックスで、**他の AWS サービスからプリンシパルの承認**を選択し、リストから **OpenSearch アプリケーション (ダッシュボード)** を選択します。
1. [**承認**] を選択します。
### VPC 内のドメインへのアクセスの管理 (AWS CLI)
**を使用して VPC ドメインを承認するには AWS CLI**
を使用して VPC ドメインを承認するには AWS CLI、次のコマンドを実行します。*プレースホルダー値*を、ユーザー自身の情報に置き換えます。
```
aws opensearch authorize-vpc-endpoint-access \
--domain-name domain-name \
--service application.opensearchservice.amazonaws.com \
--region region-id
```
**コンソールを使用して VPC ドメインの関連付けを解除するには**
関連付けが不要になった場合、VPC ドメイン所有者は次の手順を使用してアクセスを取り消すことができます。
1. [https://console.aws.amazon.com/aos/home](https://console.aws.amazon.com/aos/home) で Amazon OpenSearch Service コンソールにサインインします。
1. 左側のナビゲーションペインで、**[ドメイン]** を選択し、VPC ドメインの名前を選択します。
1. **[VPC エンドポイント]** タブを選択し、**[OpenSearch アプリケーション (ダッシュボード)]** の行のボタンを選択します。
1. **[アクセスを取り消す]** をクリックします。
**を使用して VPC ドメインの関連付けを取り消すには AWS CLI**
OpenSearch UI アプリケーションとの VPC ドメインの関連付けを取り消すには、次のコマンドを実行します。*プレースホルダー値*を、ユーザー自身の情報に置き換えます。
```
aws opensearch revoke-vpc-endpoint-access \
--domain-name domain-name \
--service application.opensearchservice.amazonaws.com \
--region region-id
```
## VPC 内の OpenSearch Serverless コレクションへのアクセスの設定
VPC 内の Amazon OpenSearch Serverless コレクションがアプリケーションに関連付けられている場合、VPC 管理者は新しいネットワークポリシーを作成してコレクションにアタッチすることでアクセスを許可できます。
### VPC 内の OpenSearch Serverless コレクションへのアクセスの設定 (コンソール)
**コンソールを使用して VPC 内の OpenSearch Serverless コレクションへのアクセスを設定するには**
1. [https://console.aws.amazon.com/aos/home](https://console.aws.amazon.com/aos/home) で Amazon OpenSearch Service コンソールにサインインします。
1. 左側のナビゲーションで、**[ネットワークポリシー]** を選択し、ネットワークポリシーの名前を選択し、**[編集]** を選択します。
-または-
**[ネットワークポリシーを作成]** を選択し、ポリシーの詳細を設定します。
1. **[アクセスタイプ]** エリアで、**[プライベート (推奨)]** を選択し、**[AWS サービスプライベートアクセス]** を選択します。
1. 検索フィールドで **[サービス]** を選択し、次に `application.opensearchservice.amazonaws.com` を選択します。
1. **[リソースタイプ]** エリアで、**[OpenSearch エンドポイントへのアクセスを有効にする]** ボックスを選択します。
1. **[検索コレクション (複数可) または入力特定のプレフィックス用語 (複数可)]** では、検索フィールドに **[コレクション名]** を選択し、ネットワークポリシーに関連付けるコレクションの名前を入力または選択します。
1. 新しいネットワークポリシーの場合は **[作成]**、既存のネットワークポリシーの場合は **[更新]** を選択します。
### VPC 内の OpenSearch Serverless コレクションへのアクセスの設定 (AWS CLI)
**を使用して VPC 内の OpenSearch Serverless コレクションへのアクセスを設定するには AWS CLI**
1. 以下のような .json ファイルを作成します。*プレースホルダー値*を、ユーザー自身の情報に置き換えます。
```
{
"Description" : "policy-description",
"Rules": [{
"ResourceType" : "collection",
"Resource" : ["collection/collection_name"]
}],
"SourceServices" : [
"application.opensearchservice.amazonaws.com"
],
"AllowFromPublic" : false
}
```
1. VPC 内のコレクションのネットワークポリシーを作成または更新して、OpenSearch UI アプリケーションを操作します。
------
#### [ Create a network policy ]
以下のコマンドを実行してください。*プレースホルダー値*を、ユーザー自身の情報に置き換えます。
```
aws opensearchserverless create-security-policy \
--type network \
--region region \
--endpoint-url endpoint-url \
--name network-policy-name \
--policy file:/path_to_network_policy_json_file
```
コマンドは以下のような情報を返します。
```
{
"securityPolicyDetail": {
"createdDate": ******,
"lastModifiedDate": ******,
"name": "network-policy-name",
"policy": [
{
"SourceVPCEs": [],
"AllowFromPublic": false,
"Description": "",
"Rules": [
{
"Resource": [
"collection/network-policy-name"
],
"ResourceType": "collection"
}
],
"SourceServices": [
"application.opensearchservice.amazonaws.com"
]
}
],
"policyVersion": "******",
"type": "network"
}
}
```
------
#### [ Update a network policy ]
以下のコマンドを実行してください。*プレースホルダー値*を、ユーザー自身の情報に置き換えます。
```
aws opensearchserverless update-security-policy \
--type network \
--region region \
--endpoint-url endpoint-url \
--name network-policy-name \
--policy-version "policy_version_from_output_of_network_policy_creation" \
--policy file:/path_to_network_policy_json_file
```
コマンドは以下のような情報を返します。
```
{
"securityPolicyDetail": {
"createdDate": ******,
"lastModifiedDate": ******,
"name": "network-policy-name",
"policy": [
{
"SourceVPCEs": [],
"AllowFromPublic": false,
"Description": "",
"Rules": [
{
"Resource": [
"collection/network-policy-name"
],
"ResourceType": "collection"
}
],
"SourceServices": [
"application.opensearchservice.amazonaws.com"
]
}
],
"policyVersion": "******",
"type": "network"
}
}
```
------
# Amazon OpenSearch Service ワークスペースの使用
Amazon OpenSearch Service は、複数のユースケース固有のワークスペースの作成をサポートしています。各ワークスペースは、オブザーバビリティ、セキュリティ分析、検索などの一般的なユースケース向けに厳選されたエクスペリエンスを提供します。ワークスペースは共同作業者管理にも対応しているため、目的の共同作業者のみとワークスペースを共有し、それぞれのアクセス許可を管理することもできます。
## OpenSearch UI アプリケーションワークスペースの作成
OpenSearch UI アプリケーションが作成され、データソースに関連付けられ、アプリケーションのユーザーアクセス許可が設定されたら、OpenSearch UI アプリケーションを起動してワークスペースを作成できます。
ワークスペースの作成を開始するには、アプリケーションの詳細ページの **[アプリケーション起動]** ボタンを選択するか、OpenSearch UI アプリケーション URL を使用して、新しいブラウザウィンドウで OpenSearch UI アプリケーションのホームページを開きます。
OpenSearch UI アプリケーションは、ワークスペースを作成するためのオプションを提供し、ホームページ内のすべての既存のワークスペースをユースケース別に分類して一覧表示します。
![\[コンソールの「My workspaces」エリアを使用して、オブザーバビリティ、セキュリティ分析、検索、Essentials、分析の 5 つの異なるタイプのワークスペースを作成できます。「My workspaces」エリアにある既存のワークスペースをすべて表示することもできます。\]](http://docs.aws.amazon.com/ja_jp/opensearch-service/latest/developerguide/images/workspaces.png)
サポートされているワークスペースの種類に関する詳細については、「[ワークスペースタイプ](#application-workspaces-types)」を参照してください。
## ワークスペースのプライバシーと共同作業者
ワークスペースのプライバシー設定は、すべてのユーザーのデフォルトのアクセス許可レベルとして定義できます。これは、ワークスペースの作成時または既存のワークスペースの変更時 (ワークスペース **[共同作業者]** タブ) に行うことができます。選択できるプライバシーオプションは 3 つあります。
+ **[共同作業者限定]** – ワークスペースに明示的に追加した共同作業者のみがアクセスできます。各共同作業者のアクセス許可レベルを定義できます。
+ **[**誰でも閲覧可能**]** – OpenSearch UI アプリケーションにアクセスできるユーザーは、ワークスペースにアクセスしてアセットを表示できますが、ワークスペースに変更を加えることはできません。
+ **[**誰でも編集可能**]** – OpenSearch UI アプリケーションにアクセスできるユーザーは、ワークスペースにアクセスし、その中のアセットを表示して、ワークスペース内のアセットを変更することができます。
Workspace **Collaborators** タブで、IAM ユーザーまたはロールと AWS IAM アイデンティティセンター ユーザーをワークスペースの共同作業者として追加できます。共同作業者が選択できるアクセス許可には 3 つのレベルがあります。
+ **[読み取り専用]** – 共同作業者はワークスペース内のアセットのみを表示できます。ワークスペースが **[誰でも編集可能]** のプライバシー設定を使用するように構成されている場合、この設定は上書きされます。
+ **[読み取りと書き込み]** – 共同作業者はワークスペース内のアセットを表示および編集できます。**[誰でも閲覧可能]** のプライバシー設定が適用されているワークスペースの場合、共同編集者は編集を継続できます。
+ **[管理者]** – 共同作業者は設定を更新し、ワークスペースを削除できます。共同作業者は、ワークスペースのプライバシー設定を変更したり、共同作業者を管理したりすることもできます。ワークスペースを作成するユーザーは、ワークスペース管理者に自動的に割り当てられます。
## ワークスペースタイプ
Amazon OpenSearch Service には 5 つのワークスペースタイプがあり、それぞれにユースケースごとに異なる機能があります。
+ **[オブザーバビリティ]** ワークスペースは、ログ、メトリクス、トレースのモニタリングを通じて、システムの状態、パフォーマンス、信頼性を可視化するように設計されています。
+ **[セキュリティ分析]** ワークスペースは、システムとデータ全体で潜在的なセキュリティの脅威と脆弱性を検出して調査するように設計されています。
+ **[検索]** ワークスペースは、組織のデータソース全体で関連情報をすばやく検索および探索するように設計されています。
+ **[Essentials]** ワークスペースは、データソースとして OpenSearch Serverless 向けに設計されており、データを分析してインサイトを取得し、パターンと傾向を特定し、データ駆動型の意思決定を迅速に行うことができます。組織のデータソース全体の関連情報は、**[Essentials]** ワークスペースで検索して確認できます。
+ **[アナリティクス]** (すべての機能) ワークスペースは、多目的ユースケース向けに設計されており、OpenSearch Service UI (ダッシュボード) で使用可能なすべての機能をサポートしています。
# クロスリージョンおよびクロスアカウントデータアクセス
OpenSearch UI は、さまざまな AWS アカウントおよび にわたる OpenSearch AWS リージョンドメインからのデータへのアクセスをサポートしています。要件に応じて 2 つのアプローチから選択できます。次の表は、2 つのアプローチを比較したものです。
**注記**
クロスアカウントデータアクセスとクラスター間検索はどちらもOpenSearch ドメインでのみ機能します。どちらのアプローチも OpenSearch Serverless コレクションをサポートしていません。
| 側面 | クロスアカウントデータアクセス | クラスター間検索 |
| --- | --- | --- |
| 機能 | OpenSearch UI で他のアカウントのドメインを直接データソースとして関連付ける | クラスター間検索接続を使用して、接続されたドメイン間でデータをクエリする |
| メカニズム | 直接アクセス – OpenSearch UI は別のアカウントのターゲットドメインに直接接続します | 間接アクセス – リモートドメインにリクエストを中継するには、OpenSearch UI と同じアカウントのローカルドメインが必要です |
| クロスアカウントのサポート | はい | はい |
| クロスリージョンサポート | いいえ – ソースドメインとターゲットドメインは同じ に存在する必要があります AWS リージョン | はい – 送信元ドメインと送信先ドメインは異なる に配置できます AWS リージョン |
| ドメイン間でデータを結合する | いいえ – 各ドメインは個別のデータソースとして個別にクエリされます | はい – 1 つのクエリで複数の接続されたドメインの結果を集計できます |
| 認証方法 | IAM と AWS IAM アイデンティティセンター | IAM (きめ細かなアクセスコントロールを使用) |
| セットアップの複雑さ | 低 – 検証にはクロスアカウント IAM ロールが必要です | 高 – クラスター間接続、両方のドメインのアクセスポリシー、きめ細かなアクセスコントロールが必要 |
| OpenSearch UI でのデータソースの可視性 | 各クロスアカウントドメインは個別のデータソースとして表示されます | リモートドメインは、ローカルソースドメインの接続エイリアスを介してアクセスされます。 |
| リモートドメインへの書き込みアクセス | はい – ターゲットドメインのアクセスポリシーによって制御されます | いいえ – クラスター間検索はリモートドメインへの読み取り専用アクセスを提供します |
**Topics**
+ [OpenSearch ドメインへのクロスアカウントデータアクセス](application-cross-account-data-access-domains.md)
+ [クラスター間検索](application-cross-cluster-search.md)
# OpenSearch ドメインへのクロスアカウントデータアクセス
1 つのアカウントで OpenSearch UI アプリケーションを設定して、異なるアカウントの OpenSearch ドメインにアクセスできます。クロスアカウントデータソースを使用して OpenSearch UI アプリケーションを作成するときは、ターゲットアカウントの IAM ロール`iamRoleForDataSourceArn`を指す を指定します。OpenSearch UI は、このロールを引き受け、 `es:DescribeDomain`を呼び出してドメインアクセシビリティを検証することで、リクエストを検証します。クロスアカウントロールは、コントロールプレーンの検証にのみ使用されます。データプレーンへのアクセスは、ターゲットドメインのアクセスポリシーによって個別に制御されます。
**「サンプルコード」**
このトピックのコード例は、説明のみを目的としています。基本的な機能を示しており、エラー処理、セキュリティのベストプラクティス、本番稼働用の機能が含まれていない場合があります。本番環境でサンプルコードを使用する前に、特定の要件を満たすようにサンプルコードを確認して変更し、環境で徹底的にテストします。
## 主要なコンセプト
ソースアカウント
OpenSearch UI アプリケーションをホスト AWS アカウント する 。
ターゲットアカウント
OpenSearch ドメイン AWS アカウント が存在する 。
クロスアカウントロール
コントロールプレーンの検証にのみ使用されるターゲットアカウントの IAM ロール。このロールには アクセス`es:DescribeDomain`許可のみが必要です。
IAM Identity Center アプリケーションロール
IAM Identity Center ユーザーデータプレーンアクセスに使用されるソースアカウントの IAM ロール。
## 前提条件
クロスアカウントデータアクセスを設定する前に、以下があることを確認してください。
+ AWS CLI のインストールと設定
+ ソースとターゲットの両方へのアクセス AWS アカウント
+ IAM Identity Center フローの場合: AWS IAM アイデンティティセンター 組織インスタンス
## シナリオ
認証方法とドメイン設定に一致するシナリオを選択します。
+ [シナリオ 1: パブリックドメインにアクセスする IAM ユーザー](#cross-account-scenario-1)
+ [シナリオ 2: パブリックドメインにアクセスする IAM Identity Center ユーザー](#cross-account-scenario-2)
+ [シナリオ 3: VPC ドメインにアクセスする IAM ユーザー](#cross-account-scenario-3)
+ [シナリオ 4: VPC ドメインにアクセスする IAM Identity Center ユーザー](#cross-account-scenario-4)
## シナリオ 1: パブリックドメインにアクセスする IAM ユーザー
### ステップ 1: クロスアカウント IAM ロールを作成する (ターゲットアカウント)
ソースアカウントがドメイン検証のために引き受けることを許可する IAM ロールをターゲットアカウントに作成します。
**クロスアカウントロールを作成するには**
1. ソースアカウントがロールを引き受けることを許可する信頼ポリシーを作成します。
```
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::source-account-id:root"
},
"Action": "sts:AssumeRole"
}]
}
```
1. ロールを作成します。
```
aws iam create-role \
--role-name OpenSearchUIAccessRole \
--assume-role-policy-document file://trust-policy.json
```
1. `es:DescribeDomain` アクションのみを使用してアクセス許可ポリシーを作成します。
```
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "es:DescribeDomain",
"Resource": "arn:aws:es:region:target-account-id:domain/*"
}]
}
```
1. アクセス許可ポリシーをロールにアタッチします:
```
aws iam put-role-policy \
--role-name OpenSearchUIAccessRole \
--policy-name ValidationOnly \
--policy-document file://permissions-policy.json
```
### ステップ 2: OpenSearch ドメインを作成する (ターゲットアカウント)
きめ細かなアクセスコントロールと暗号化を有効にして、ターゲットアカウントに OpenSearch ドメインを作成します。
```
aws opensearch create-domain \
--domain-name domain-name \
--engine-version OpenSearch_2.19 \
--cluster-config InstanceType=m5.large.search,InstanceCount=1 \
--ebs-options "EBSEnabled=true,VolumeType=gp3,VolumeSize=100" \
--advanced-security-options '{"Enabled":true,"InternalUserDatabaseEnabled":true,"MasterUserOptions":{"MasterUserName":"admin","MasterUserPassword":"master-password"}}' \
--node-to-node-encryption-options '{"Enabled":true}' \
--encryption-at-rest-options '{"Enabled":true}' \
--domain-endpoint-options '{"EnforceHTTPS":true,"TLSSecurityPolicy":"Policy-Min-TLS-1-2-2019-07"}' \
--access-policies '{"Version":"2012-10-17", "Statement":[{"Effect":"Allow","Principal":{"AWS":"*"},"Action":"es:ESHttp*","Resource":"arn:aws:es:region:target-account-id:domain/domain-name/*"}]}' \
--region region
```
続行する`Active`前に、ドメインのステータスが になるまで待ちます。
### ステップ 3: OpenSearch UI アプリケーションを作成する (ソースアカウント)
クロスアカウントデータソースを使用してソースアカウントにアプリケーションを作成します。
```
aws opensearch create-application \
--region region \
--name "cross-account-iam-app" \
--data-sources '[{
"dataSourceArn":"arn:aws:es:region:target-account-id:domain/domain-name",
"dataSourceDescription":"Cross-account domain",
"iamRoleForDataSourceArn":"arn:aws:iam::target-account-id:role/OpenSearchUIAccessRole"
}]' \
--app-configs '[{"key":"opensearchDashboards.dashboardAdmin.users","value":"[\"*\"]"}]'
```
### ステップ 4: 検証とアクセス
アプリケーションの詳細を取得してエンドポイント URL を取得します。
```
aws opensearch get-application \
--region region \
--id application-id
```
+ レスポンスからアプリケーションエンドポイント URL に移動します。
+ IAM 認証情報を使用してサインインします。
+ IAM ユーザーは、独自の認証情報を使用してデータプレーンリクエストに署名します。
+ ターゲットドメインアクセスポリシーは、ユーザーがアクセスできるデータを制御します。
## シナリオ 2: パブリックドメインにアクセスする IAM Identity Center ユーザー
### ステップ 1: クロスアカウント IAM ロールを作成する (ターゲットアカウント)
ソースアカウントがドメイン検証のために引き受けることを許可する IAM ロールをターゲットアカウントに作成します。
**クロスアカウントロールを作成するには**
1. ソースアカウントがロールを引き受けることを許可する信頼ポリシーを作成します。
```
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::source-account-id:root"
},
"Action": "sts:AssumeRole"
}]
}
```
1. ロールを作成します。
```
aws iam create-role \
--role-name OpenSearchUIAccessRole \
--assume-role-policy-document file://trust-policy.json
```
1. `es:DescribeDomain` アクションのみを使用してアクセス許可ポリシーを作成します。
```
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "es:DescribeDomain",
"Resource": "arn:aws:es:region:target-account-id:domain/*"
}]
}
```
1. アクセス許可ポリシーをロールにアタッチします:
```
aws iam put-role-policy \
--role-name OpenSearchUIAccessRole \
--policy-name ValidationOnly \
--policy-document file://permissions-policy.json
```
### ステップ 2: OpenSearch ドメインを作成する (ターゲットアカウント)
ターゲットアカウントに OpenSearch ドメインを作成します。と同じコマンドを使用しますが[ステップ 2: OpenSearch ドメインを作成する (ターゲットアカウント)](#scenario-1-step-2)、アクセスポリシーを更新して、ソースアカウントからの IAM Identity Center アプリケーションロールを許可します。
```
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::source-account-id:role/NeoIdCAppRole"
},
"Action": "es:ESHttp*",
"Resource": "arn:aws:es:region:target-account-id:domain/domain-name/*"
}]
}
```
続行する`Active`前に、ドメインのステータスが になるまで待ちます。
### ステップ 3: IAM Identity Center アプリケーションの IAM ロールを作成する (ソースアカウント)
OpenSearch UI が IAM Identity Center ユーザーデータプレーンアクセスに使用するソースアカウントに IAM ロールを作成します。
**IAM Identity Center アプリケーションロールを作成するには**
1. 信頼ポリシーを作成します。
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "application.opensearchservice.amazonaws.com"
},
"Action": "sts:AssumeRole"
},
{
"Effect": "Allow",
"Principal": {
"Service": "application.opensearchservice.amazonaws.com"
},
"Action": "sts:SetContext",
"Condition": {
"ForAllValues:ArnEquals": {
"sts:RequestContextProviders": "arn:aws:iam::source-account-id:oidc-provider/portal.sso.region.amazonaws.com/apl/application-id"
}
}
}
]
}
```
1. アクセス許可ポリシーを作成します。
```
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "OpenSearchDomain",
"Effect": "Allow",
"Action": ["es:ESHttp*"],
"Resource": "*"
}]
}
```
1. ロールを作成し、ポリシーをアタッチします。
```
aws iam create-role \
--role-name NeoIdCAppRole \
--assume-role-policy-document file://neoidc-trust-policy.json
aws iam put-role-policy \
--role-name NeoIdCAppRole \
--policy-name NeoIdCAppPermissions \
--policy-document file://neoidc-permissions-policy.json
```
### ステップ 4: IAM Identity Center を使用して OpenSearch UI アプリケーションを作成する (ソースアカウント)
```
aws opensearch create-application \
--region region \
--name "cross-account-idc-app" \
--iam-identity-center-options '{
"enabled":true,
"iamIdentityCenterInstanceArn":"arn:aws:sso:::instance/ssoins-instance-id",
"iamRoleForIdentityCenterApplicationArn":"arn:aws:iam::source-account-id:role/NeoIdCAppRole"
}' \
--data-sources '[{
"dataSourceArn":"arn:aws:es:region:target-account-id:domain/domain-name",
"dataSourceDescription":"Cross-account domain",
"iamRoleForDataSourceArn":"arn:aws:iam::target-account-id:role/OpenSearchUIAccessRole"
}]' \
--app-configs '[{"key":"opensearchDashboards.dashboardAdmin.users","value":"[\"*\"]"}]'
```
### ステップ 5: IAM Identity Center ユーザーとグループを作成して割り当てる
**IAM Identity Center ユーザーを作成する**
以下のコマンドを実行してください。*プレースホルダー値*を、ユーザー自身の情報に置き換えます。
```
aws identitystore create-user \
--identity-store-id d-directory-id \
--user-name user-email \
--display-name "display-name" \
--name Formatted=string,FamilyName=last-name,GivenName=first-name \
--emails Value=user-email,Type=work,Primary=true
```
**IAM Identity Center グループを作成し、ユーザーを追加する**
以下の コマンドを実行します。
```
aws identitystore create-group \
--identity-store-id d-directory-id \
--display-name "OpenSearchUsers" \
--description "Users with OpenSearch access"
aws identitystore create-group-membership \
--identity-store-id d-directory-id \
--group-id group-id \
--member-id UserId=user-id
```
**ユーザーまたはグループをアプリケーションに割り当てる**
次のコマンドを実行します。
```
aws sso-admin create-application-assignment \
--application-arn "arn:aws:sso:::source-account-id:application/ssoins-instance-id/apl-application-id" \
--principal-id user-id-or-group-id \
--principal-type USER
```
**ターゲットドメインでバックエンドロールマッピングを設定する**
IAM Identity Center グループをターゲットドメインの OpenSearch セキュリティロールにマッピングします。
```
curl -XPUT "https://domain-endpoint/_plugins/_security/api/rolesmapping/all_access" \
-u admin:master-password \
-H 'Content-Type: application/json' \
-d '{
"backend_roles": ["group-id"],
"hosts": [],
"users": []
}'
```
### ステップ 6: 検証とアクセス
```
aws opensearch get-application \
--region region \
--id application-id
```
+ アプリケーションエンドポイント URL に移動します。
+ IAM Identity Center ユーザー認証情報を使用してサインインします。
+ IAM Identity Center ユーザーのデータリクエストは、クロスアカウントロールではなく、IAM Identity Center アプリケーションロールで署名されます。
+ ドメインコントロールデータアクセス許可のバックエンドロールマッピング。
## シナリオ 3: VPC ドメインにアクセスする IAM ユーザー
### ステップ 1: クロスアカウント IAM ロールを作成する (ターゲットアカウント)
ソースアカウントがドメイン検証のために引き受けることを許可する IAM ロールをターゲットアカウントに作成します。
**クロスアカウントロールを作成するには**
1. ソースアカウントがロールを引き受けることを許可する信頼ポリシーを作成します。
```
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::source-account-id:root"
},
"Action": "sts:AssumeRole"
}]
}
```
1. ロールを作成します。
```
aws iam create-role \
--role-name OpenSearchUIAccessRole \
--assume-role-policy-document file://trust-policy.json
```
1. `es:DescribeDomain` アクションのみを使用してアクセス許可ポリシーを作成します。
```
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "es:DescribeDomain",
"Resource": "arn:aws:es:region:target-account-id:domain/*"
}]
}
```
1. アクセス許可ポリシーをロールにアタッチします:
```
aws iam put-role-policy \
--role-name OpenSearchUIAccessRole \
--policy-name ValidationOnly \
--policy-document file://permissions-policy.json
```
### ステップ 2: VPC をセットアップする (ターゲットアカウント)
ターゲットアカウントに VPC がすでに存在する場合は、このステップをスキップします。
```
# Create VPC
aws ec2 create-vpc \
--cidr-block 10.0.0.0/16 \
--region region
# Create subnet
aws ec2 create-subnet \
--vpc-id vpc-id \
--cidr-block 10.0.1.0/24 \
--availability-zone regiona \
--region region
# Create security group
aws ec2 create-security-group \
--group-name opensearch-vpc-sg \
--description "Security group for OpenSearch VPC domain" \
--vpc-id vpc-id \
--region region
# Allow inbound HTTPS
aws ec2 authorize-security-group-ingress \
--group-id security-group-id \
--protocol tcp \
--port 443 \
--cidr 10.0.0.0/16 \
--region region
```
[VPC ドメインの作成](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/vpc.html)について詳しく説明します。
### ステップ 3: VPC ドメインを作成する (ターゲットアカウント)
```
aws opensearch create-domain \
--domain-name vpc-domain-name \
--engine-version OpenSearch_2.19 \
--cluster-config InstanceType=m5.large.search,InstanceCount=1 \
--ebs-options "EBSEnabled=true,VolumeType=gp3,VolumeSize=100" \
--vpc-options "SubnetIds=subnet-id,SecurityGroupIds=security-group-id" \
--advanced-security-options '{"Enabled":true,"InternalUserDatabaseEnabled":true,"MasterUserOptions":{"MasterUserName":"admin","MasterUserPassword":"master-password"}}' \
--node-to-node-encryption-options '{"Enabled":true}' \
--encryption-at-rest-options '{"Enabled":true}' \
--domain-endpoint-options '{"EnforceHTTPS":true,"TLSSecurityPolicy":"Policy-Min-TLS-1-2-2019-07"}' \
--access-policies '{"Version":"2012-10-17", "Statement":[{"Effect":"Allow","Principal":{"AWS":"*"},"Action":"es:ESHttp*","Resource":"arn:aws:es:region:target-account-id:domain/vpc-domain-name/*"}]}' \
--region region
```
続行する`Active`前に、ドメインのステータスが になるまで待ちます。
### ステップ 4: OpenSearch UI サービスプリンシパル (ターゲットアカウント) の VPC エンドポイントを承認する
**重要**
これは VPC ドメインに固有の重要なステップです。OpenSearch UI サービスには、VPC エンドポイントへのアクセスを明示的に許可する必要があります。
```
# Authorize the service principal
aws opensearch authorize-vpc-endpoint-access \
--domain-name vpc-domain-name \
--service "application.opensearchservice.amazonaws.com" \
--region region
# Verify authorization
aws opensearch list-vpc-endpoint-access \
--domain-name vpc-domain-name \
--region region
```
予想されるレスポンス
```
{
"AuthorizedPrincipalList": [
{
"PrincipalType": "AWS_SERVICE",
"Principal": "application.opensearchservice.amazonaws.com"
}
]
}
```
### ステップ 5: OpenSearch UI アプリケーションを作成する (ソースアカウント)
```
aws opensearch create-application \
--region region \
--name "cross-account-vpc-iam-app" \
--data-sources '[{
"dataSourceArn":"arn:aws:es:region:target-account-id:domain/vpc-domain-name",
"dataSourceDescription":"Cross-account VPC domain",
"iamRoleForDataSourceArn":"arn:aws:iam::target-account-id:role/OpenSearchUIAccessRole"
}]' \
--app-configs '[{"key":"opensearchDashboards.dashboardAdmin.users","value":"[\"*\"]"}]'
```
### ステップ 6: 検証とアクセス
アプリケーションの詳細を取得してエンドポイント URL を取得します。
```
aws opensearch get-application \
--region region \
--id application-id
```
+ レスポンスからアプリケーションエンドポイント URL に移動します。
+ IAM 認証情報を使用してサインインします。
+ IAM ユーザーは、独自の認証情報を使用してデータプレーンリクエストに署名します。
+ ターゲットドメインアクセスポリシーは、ユーザーがアクセスできるデータを制御します。
## シナリオ 4: VPC ドメインにアクセスする IAM Identity Center ユーザー
### ステップ 1: クロスアカウント IAM ロールを作成する (ターゲットアカウント)
ソースアカウントがドメイン検証のために引き受けることを許可する IAM ロールをターゲットアカウントに作成します。
**クロスアカウントロールを作成するには**
1. ソースアカウントがロールを引き受けることを許可する信頼ポリシーを作成します。
```
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::source-account-id:root"
},
"Action": "sts:AssumeRole"
}]
}
```
1. ロールを作成します。
```
aws iam create-role \
--role-name OpenSearchUIAccessRole \
--assume-role-policy-document file://trust-policy.json
```
1. `es:DescribeDomain` アクションのみを使用してアクセス許可ポリシーを作成します。
```
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "es:DescribeDomain",
"Resource": "arn:aws:es:region:target-account-id:domain/*"
}]
}
```
1. アクセス許可ポリシーをロールにアタッチします:
```
aws iam put-role-policy \
--role-name OpenSearchUIAccessRole \
--policy-name ValidationOnly \
--policy-document file://permissions-policy.json
```
### ステップ 2: VPC をセットアップする (ターゲットアカウント)
ターゲットアカウントに VPC がすでに存在する場合は、このステップをスキップします。
```
# Create VPC
aws ec2 create-vpc \
--cidr-block 10.0.0.0/16 \
--region region
# Create subnet
aws ec2 create-subnet \
--vpc-id vpc-id \
--cidr-block 10.0.1.0/24 \
--availability-zone regiona \
--region region
# Create security group
aws ec2 create-security-group \
--group-name opensearch-vpc-sg \
--description "Security group for OpenSearch VPC domain" \
--vpc-id vpc-id \
--region region
# Allow inbound HTTPS
aws ec2 authorize-security-group-ingress \
--group-id security-group-id \
--protocol tcp \
--port 443 \
--cidr 10.0.0.0/16 \
--region region
```
[VPC ドメインの作成](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/vpc.html)について詳しく説明します。
### ステップ 3: VPC ドメインを作成する (ターゲットアカウント)
と同じコマンドを使用しますが[ステップ 3: VPC ドメインを作成する (ターゲットアカウント)](#scenario-3-step-3)、アクセスポリシーを更新して、ソースアカウントからの IAM Identity Center アプリケーションロールを許可します。
```
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::source-account-id:role/NeoIdCAppRole"
},
"Action": "es:ESHttp*",
"Resource": "arn:aws:es:region:target-account-id:domain/vpc-domain-name/*"
}]
}
```
続行する`Active`前に、ドメインのステータスが になるまで待ちます。
### ステップ 4: OpenSearch UI サービスプリンシパル (ターゲットアカウント) の VPC エンドポイントを承認する
**重要**
これは VPC ドメインに固有の重要なステップです。OpenSearch UI サービスには、VPC エンドポイントへのアクセスを明示的に許可する必要があります。
```
# Authorize the service principal
aws opensearch authorize-vpc-endpoint-access \
--domain-name vpc-domain-name \
--service "application.opensearchservice.amazonaws.com" \
--region region
# Verify authorization
aws opensearch list-vpc-endpoint-access \
--domain-name vpc-domain-name \
--region region
```
予想されるレスポンス
```
{
"AuthorizedPrincipalList": [
{
"PrincipalType": "AWS_SERVICE",
"Principal": "application.opensearchservice.amazonaws.com"
}
]
}
```
### ステップ 5: IAM Identity Center アプリケーションの IAM ロールを作成する (ソースアカウント)
OpenSearch UI が IAM Identity Center ユーザーデータプレーンアクセスに使用するソースアカウントに IAM ロールを作成します。
**IAM Identity Center アプリケーションロールを作成するには**
1. 信頼ポリシーを作成します。
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "application.opensearchservice.amazonaws.com"
},
"Action": "sts:AssumeRole"
},
{
"Effect": "Allow",
"Principal": {
"Service": "application.opensearchservice.amazonaws.com"
},
"Action": "sts:SetContext",
"Condition": {
"ForAllValues:ArnEquals": {
"sts:RequestContextProviders": "arn:aws:iam::source-account-id:oidc-provider/portal.sso.region.amazonaws.com/apl/application-id"
}
}
}
]
}
```
1. アクセス許可ポリシーを作成します。
```
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "OpenSearchDomain",
"Effect": "Allow",
"Action": ["es:ESHttp*"],
"Resource": "*"
}]
}
```
1. ロールを作成し、ポリシーをアタッチします。
```
aws iam create-role \
--role-name NeoIdCAppRole \
--assume-role-policy-document file://neoidc-trust-policy.json
aws iam put-role-policy \
--role-name NeoIdCAppRole \
--policy-name NeoIdCAppPermissions \
--policy-document file://neoidc-permissions-policy.json
```
### ステップ 6: IAM Identity Center を使用して OpenSearch UI アプリケーションを作成する (ソースアカウント)
```
aws opensearch create-application \
--region region \
--name "cross-account-vpc-idc-app" \
--iam-identity-center-options '{
"enabled":true,
"iamIdentityCenterInstanceArn":"arn:aws:sso:::instance/ssoins-instance-id",
"iamRoleForIdentityCenterApplicationArn":"arn:aws:iam::source-account-id:role/NeoIdCAppRole"
}' \
--data-sources '[{
"dataSourceArn":"arn:aws:es:region:target-account-id:domain/vpc-domain-name",
"dataSourceDescription":"Cross-account VPC domain",
"iamRoleForDataSourceArn":"arn:aws:iam::target-account-id:role/OpenSearchUIAccessRole"
}]' \
--app-configs '[{"key":"opensearchDashboards.dashboardAdmin.users","value":"[\"*\"]"}]'
```
### ステップ 7: IAM Identity Center ユーザーとグループを作成して割り当てる
**IAM Identity Center ユーザーを作成する**
以下のコマンドを実行してください。*プレースホルダー値*を、ユーザー自身の情報に置き換えます。
```
aws identitystore create-user \
--identity-store-id d-directory-id \
--user-name user-email \
--display-name "display-name" \
--name Formatted=string,FamilyName=last-name,GivenName=first-name \
--emails Value=user-email,Type=work,Primary=true
```
**IAM Identity Center グループを作成し、ユーザーを追加する**
以下の コマンドを実行します。
```
aws identitystore create-group \
--identity-store-id d-directory-id \
--display-name "OpenSearchUsers" \
--description "Users with OpenSearch access"
aws identitystore create-group-membership \
--identity-store-id d-directory-id \
--group-id group-id \
--member-id UserId=user-id
```
**ユーザーまたはグループをアプリケーションに割り当てる**
次のコマンドを実行します。
```
aws sso-admin create-application-assignment \
--application-arn "arn:aws:sso:::source-account-id:application/ssoins-instance-id/apl-application-id" \
--principal-id user-id-or-group-id \
--principal-type USER
```
**ターゲットドメインでバックエンドロールマッピングを設定する**
IAM Identity Center グループをターゲットドメインの OpenSearch セキュリティロールにマッピングします。
```
curl -XPUT "https://domain-endpoint/_plugins/_security/api/rolesmapping/all_access" \
-u admin:master-password \
-H 'Content-Type: application/json' \
-d '{
"backend_roles": ["group-id"],
"hosts": [],
"users": []
}'
```
### ステップ 8: 検証とアクセス
```
aws opensearch get-application \
--region region \
--id application-id
```
+ アプリケーションエンドポイント URL に移動します。
+ IAM Identity Center ユーザー認証情報を使用してサインインします。
+ IAM Identity Center ユーザーのデータリクエストは、クロスアカウントロールではなく、IAM Identity Center アプリケーションロールで署名されます。
+ ドメインコントロールデータアクセス許可のバックエンドロールマッピング。
## アプリケーションの管理
**クロスアカウントデータソースを使用してアプリケーションを更新する**
以下のコマンドを実行してください。*プレースホルダー値*を、ユーザー自身の情報に置き換えます。
```
aws opensearch update-application \
--region region \
--id application-id \
--data-sources '[{
"dataSourceArn":"arn:aws:es:region:target-account-id:domain/domain-1",
"dataSourceDescription":"First cross-account domain",
"iamRoleForDataSourceArn":"arn:aws:iam::target-account-id:role/OpenSearchUIAccessRole"
},{
"dataSourceArn":"arn:aws:es:region:target-account-id:domain/domain-2",
"dataSourceDescription":"Second cross-account domain",
"iamRoleForDataSourceArn":"arn:aws:iam::target-account-id:role/OpenSearchUIAccessRole"
}]'
```
**重要**
更新オペレーションは、データソース配列全体を置き換えます。保持するすべてのデータソースを含めます。
**アプリケーションを一覧表示する**
次のコマンドを実行します。
```
aws opensearch list-applications \
--region region
```
**アプリケーションの削除**
次のコマンドを実行します。
```
aws opensearch delete-application \
--region region \
--id application-id
```
**VPC エンドポイントアクセスの取り消し**
次のコマンドを実行します。
```
aws opensearch revoke-vpc-endpoint-access \
--domain-name vpc-domain-name \
--service "application.opensearchservice.amazonaws.com" \
--region region
```
## クイックリファレンス
次の表は、ドメインタイプと認証方法の主な違いをまとめたものです。
**VPC ドメインと比較したパブリックドメイン**
| 側面 | パブリックドメイン | VPC ドメイン |
| --- | --- | --- |
| VPC エンドポイント認可 | 不要 | 必須 – 認可する必要があります application.opensearchservice.amazonaws.com |
| ネットワーク設定 | なし | HTTPS (443) インバウンドの VPC、サブネット、セキュリティグループ |
| IAM アクセスポリシー | 必須 | 必須 |
| クロスアカウントロール | クロスアカウントで必須 | クロスアカウントで必須 |
**IAM ユーザーと IAM Identity Center ユーザーの比較**
| 側面 | IAM ユーザー | IAM Identity Center ユーザー |
| --- | --- | --- |
| データプレーンの認証情報 | ユーザー独自の IAM 認証情報 | IAM Identity Center アプリケーションロール |
| アクセスコントロール | ドメインアクセスポリシー | ドメインアクセスポリシーとバックエンドロールマッピング |
| 追加セットアップ | なし | IAM Identity Center アプリケーションロール、ユーザー/グループの作成、アプリケーションの割り当て、バックエンドロールマッピング |
| OpenSearch UI アプリケーション設定 | IAM Identity Center オプションなし | --iam-identity-center-options が必須 |
## 重要な注意事項
+ は、 と同じアカウントにある`iamRoleForDataSourceArn`必要があります`dataSourceArn`。
+ `iamRoleForDataSourceArn` は、クロスアカウントデータソースにのみ必要です。同じアカウントデータソースの場合は省略します。
+ クロスアカウントロールには アクセス`es:DescribeDomain`許可のみが必要です。データプレーンへのアクセスには使用されません。
+ VPC ドメインの場合、IAM ポリシーと VPC エンドポイント認可の両方を設定する必要があります。
+ サポートされているエンジンバージョン: OpenSearch 1.3 以降。
## トラブルシューティング
| 問題 | 解決方法 |
| --- | --- |
| 「ドメインにアクセスできません」でアプリケーションの作成が失敗する | クロスアカウントロールに アクセスes:DescribeDomain許可があり、信頼ポリシーでソースアカウントが許可されていることを確認します。 |
| VPC ドメインの関連付けが失敗する | VPC エンドポイントが に対して承認されていることを確認しますapplication.opensearchservice.amazonaws.com。 |
| IAM ユーザーのデータプレーンアクセスが拒否されました | ターゲットドメインアクセスポリシーが IAM ユーザーまたはロールプリンシパルを許可していることを確認します。 |
| IAM Identity Center ユーザーのデータプレーンアクセスが拒否されました | バックエンドロールマッピングに IAM Identity Center グループ ID が含まれ、ドメインポリシーで IAM Identity Center アプリケーションロールが許可されていることを確認します。 |
| アカウントの不一致エラー | iamRoleForDataSourceArn が のドメインと同じアカウントにあることを確認しますdataSourceArn。 |
# クラスター間検索
Amazon OpenSearch Serverless の[クラスター間検索](cross-cluster-search.md)を使用すると、接続された複数のドメインにわたってクエリや集計を実行できます。
Amazon OpenSearch Serverless でのクラスター間検索では、*ソースドメイン*と*宛先ドメイン*の概念を使用します。クラスター間検索リクエストは、ソースドメインから送信されます。レプリケート先ドメインは、クエリ元のレプリケート元ドメインの別の AWS アカウント または AWS リージョン (またはその両方) にあることができます。クラスター間検索を使用すると、同じアカウントの OpenSearch UI に関連付けるようにソースドメインを設定し、ターゲットドメインへの接続を作成できます。その結果、別のアカウントまたはリージョンにある場合でも、ターゲットドメインのデータで OpenSearch UI を使用できます。
Amazon OpenSearch Service との間で転送されるデータには、[標準の AWS データ転送料金](https://aws.amazon.com/opensearch-service/pricing/)がかかります。OpenSearch Service ドメイン内のノード間で転送されたデータには課金されません。データ「イン」および「アウト」の料金に関する詳細については、「*Amazon EC2 オンデマンド料金*」ページの「[データ転送](https://aws.amazon.com/ec2/pricing/on-demand/#Data_Transfer)」をご参照ください。
OpenSearch UI を別のアカウントまたは別のリージョンのクラスターに関連付けるメカニズムとして、クラスター間検索を使用できます。ドメイン間のリクエストは、ノード間暗号化の一環として、デフォルトで転送中に暗号化されます。
**注記**
オープンソースの OpenSearch ツールも、[クラスター間検索](https://opensearch.org/docs/latest/search-plugins/cross-cluster-search/)について文書化しています。オープンソースクラスターにおけるオープンソースツールの設定は、マネージド Amazon OpenSearch Serverless ドメインとは大きく異なることに注意してください。
特に、Amazon OpenSearch Serverless では、`cURL` リクエストを使用する代わりに AWS マネジメントコンソール を使用してクラスター間接続を設定します。マネージドサービスは、詳細なアクセス制御に加えて、クラスター間認証に AWS Identity and Access Management (IAM) を使用します。
したがって、ドメインのクロスクラスター検索を設定する際には、オープンソースの OpenSearch ドキュメントではなく、このトピックの内容を使用することをお勧めします。
**クラスター間検索を使用する場合の機能の違い**
通常のドメインと比較して、クラスター間検索を使用して作成されたターゲットドメインには、以下の機能上の違いと要件があります。
+ リモートクラスターに書き込んだり、`PUT` コマンドを実行したりすることはできません。リモートクラスターへのアクセスは*読み取り専用*です。
+ ソースドメインとターゲットドメインの両方が OpenSearch ドメインである必要があります。OpenSearch UI 用に Elasticsearch ドメインまたはセルフマネージド OpenSearch/Elasticsearch OpenSearch クラスターを接続することはできません。
+ ドメインは他のドメインに対して最大 20 の接続を持つことができます。これには、送信接続と受信接続の両方が含まれます。
+ ソースドメインは、ターゲットドメインと同じかそれ以上のバージョンの OpenSearch である必要があります。2 つのドメイン間で双方向接続を設定したい場合、両ドメインは同じバージョンである必要があります。接続する前に、両方のドメインを最新バージョンにアップグレードすることをお勧めします。双方向接続の設定後にドメインを更新する必要がある場合は、まず接続を削除してから再作成する必要があります。
+ リモートクラスターではカスタム辞書や SQL を使用できません。
+ を使用してドメイン CloudFormation を接続することはできません。
+ M3 インスタンスとバースト可能 (T2 および T3) インスタンスではクラスター間検索は使用できません。
+ クラスター間検索は、Amazon OpenSearch Serverless コレクションでは機能しません。
**OpenSearch UI におけるクラスター間検索の前提条件**
2 つの OpenSearch ドメインでクラスター間検索をセットアップする前に、ドメインが次の要件を満たしていることを確認してください:
+ 両方のドメインで詳細なアクセス制御が有効になっています
+ 両ドメインでノード間暗号化が有効化されています
**Topics**
+ [クラスター間検索を使用したクロスリージョンおよびクロスアカウントデータアクセスのアクセス許可の設定](#cross-cluster-search-security)
+ [ドメイン間の接続の作成](#cross-cluster-search-create-connection)
+ [クラスター間検索による、リージョン間およびアカウント間のデータアクセスに対するセキュリティ設定のテスト](#cross-cluster-search-security-testing)
+ [接続を削除する](#cross-cluster-search-deleting-connection)
## クラスター間検索を使用したクロスリージョンおよびクロスアカウントデータアクセスのアクセス許可の設定
クラスター間検索リクエストをソースドメインに送信すると、ドメインはそのリクエストをドメインアクセスポリシーに対して評価します。クラスター間検索には、詳細なアクセス制御が必要です。ソースドメインでのオープンアクセスポリシーの例を次に示します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": [
"*"
]
},
"Action": [
"es:ESHttp*"
],
"Resource": "arn:aws:es:us-east-1:111222333444:domain/src-domain/*"
}
]
}
```
------
**注記**
パスにリモートインデックスを含める場合は、ドメイン ARN で URI を URL エンコードする必要があります。
例えば、次の ARN 形式を使用します:
`:arn:aws:es:us-east-1:111222333444:domain/my-domain/local_index,dst%3Aremote_index`
次の ARN 形式は使用しません:
`arn:aws:es:us-east-1:111222333444:domain/my-domain/local_index,dst:remote_index.`
詳細なアクセス制御に加えて制限付きアクセスポリシーを使用することを選択した場合、ポリシーは最低限 `es:ESHttpGet` へのアクセスを許可する必要があります。以下に例を示します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::111222333444:user/john-doe"
]
},
"Action": "es:ESHttpGet",
"Resource": "arn:aws:es:us-east-1:111122223333:domain/my-domain/*"
}
]
}
```
------
ソースドメインの[詳細なアクセス制御](fgac.md)は、リクエストを評価して、有効な IAM または HTTP の基本認証情報で署名されているかどうかを判断します。その場合、詳細なアクセス制御は次に、ユーザーが検索を実行してデータにアクセスするアクセス許可を持っているかどうかを評価します。
検索のアクセス許可要件は次のとおりです:
+ リクエストがターゲットドメイン (例: `dest-alias:dest-index/_search)`) のデータのみを検索する場合、アクセス許可はターゲットドメインでのみ必要です。
+ リクエストが両方のドメインのデータを検索する場合 (例: `source-index,dest-alias:dest-index/_search)`)、両方のドメインでアクセス許可が必要です。
+ 詳細なアクセス制御を使用するには、関連するインデックスに対する標準的な読み取りまたは検索権限に加えて、アクセス許可 `indices:admin/shards/search_shards` が必要です。
ソースドメインは、ターゲットドメインにリクエストを渡します。ターゲットドメインでは、このリクエストをドメインアクセスポリシーに照らし合わせて評価します。ドキュメントのインデックス作成や標準検索の実行など、OpenSearch UI のすべての機能をサポートするには、完全なアクセス許可を設定する必要があります。次は、ターゲットドメインで推奨されるポリシーの例です:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": [
"*"
]
},
"Action": [
"es:ESHttp*"
],
"Resource": "arn:aws:es:us-east-2:111222333444:domain/my-destination-domain/*"
},
{
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": "es:ESCrossClusterGet",
"Resource": "arn:aws:es:us-east-2:111222333444:domain/"
}
]
}
```
------
基本的な検索のみを実行する場合、ポリシーの最小要件は、ワイルドカードサポートなしでターゲットドメインに適用される `es:ESCrossClusterGet` アクセス許可です。例えば、前述のポリシーでは、ドメイン名を */my-destination-domain* として指定し、*/my-destination-domain/\$1* として指定しません。
この場合、ターゲットドメインが検索を実行し、結果をソースドメインに返します。ソースドメインにより、独自の結果 (存在する場合) とターゲットドメインの結果を組み合わせたものが返されます。
## ドメイン間の接続の作成
クロスクラスター検索接続は、ソースドメインからターゲットドメインへの単方向です。つまり、ターゲットドメイン (別のアカウントまたはリージョン) は、OpenSearch UI にローカルなソースドメインをクエリできません。ソースドメインは、ターゲットドメインへの*アウトバウンド*接続を作成します。ターゲットドメインは、ソースドメインから*インバウンド*接続リクエストを受信します。
![\[この図は、クロスクラスター検索接続は、ソースドメインからターゲットドメインへの単方向であることを示しています。\]](http://docs.aws.amazon.com/ja_jp/opensearch-service/latest/developerguide/images/ui-oubound-inbound-connections.png)
**ドメイン間の接続を作成するには**
1. [https://console.aws.amazon.com/aos/home](https://console.aws.amazon.com/aos/home) で Amazon OpenSearch Service コンソールにサインインします。
1. 左側のナビゲーションペインで **[ドメイン]** を選択します。
1. ソースドメインとして機能するドメインの名前を選択し、**[接続]** タブを選択します。
1. **[アウトバウンド接続]** セクションで、**[リクエスト]** を選択します。
1. [**接続のエイリアス**] に接続の名前を入力します。接続エイリアスは、ターゲットドメインを選択するために OpenSearch UI で使用されます。
1. **[接続モード]** では、クラスター間検索またはレプリケーションに **[直接接続]** を選択します。
1. 検索中に使用できないクラスターをスキップするように接続を指定するには、**[使用できないクラスターをスキップ]** ボックスを選択します。このオプションを選択すると、1 つ以上のリモートクラスタで障害が発生した場合でも、クラスタ間クエリで部分的な結果が返されるようになります。
1. **[ターゲットクラスター]** で、**[この AWS アカウントのクラスターに接続する]** と、**[別の AWS アカウントのクラスターに接続する]** を選択します。
1. **[リモートドメイン ARN]** には、クラスターの Amazon リソースネーム (ARN) を入力します。ドメイン ARN は、ドメインの詳細ページの **[一般情報]** エリアにあります。
ドメインは次の要件を満たしている必要があります。
+ ARN は形式 `arn:partition:es:regionaccount-id:type/domain-id` である必要があります。例えば、次のようになります。
`arn:aws:es:us-east-2:111222333444:domain/my-domain`
+ ドメインは、OpenSearch バージョン 1.0 (以降) または Elasticsearch バージョン 6.7 (以降) を使用するように設定する必要があります。
+ 詳細なアクセス制御は、ドメインで有効にする必要があります。
+ ドメインは OpenSearch を実行している必要があります。
1. **[リクエスト]** を選択します。
クラスター間検索では、まず接続リクエストを検証することで、前提条件が満たされているか確認が行われます。ドメインが互換性がない場合、接続リクエストは `Validation failed` の状態になります。
接続リクエストが正常に検証されると、ターゲットドメインに送信され、承認される必要があります。この承認が行われるまで、接続は `Pending acceptance` の状態のままです。接続要求がターゲットドメインで承諾されると、状態が `Active` に変わり、ターゲットドメインをクエリに使用できるようになります。
ドメインページには、ターゲットドメインについて、ドメインの全体的な正常性とインスタンスの正常性に関する詳細が表示されます。ドメインとの間の接続を柔軟に作成、表示、削除、モニタリングできるのは、ドメイン所有者のみです。
接続が確立されると、接続されたドメインのノード間で流れるトラフィックはすべて暗号化されます。VPC ドメインを非 VPC ドメインに接続し、非 VPC ドメインがインターネットからのトラフィックを受信できるパブリックエンドポイントである場合も、ドメイン間のクラスター間トラフィックは暗号化され、安全に保たれます。
## クラスター間検索による、リージョン間およびアカウント間のデータアクセスに対するセキュリティ設定のテスト
クロスクラスター検索によるクロスリージョンおよびクロスアカウントデータアクセスのアクセス許可を設定したら、共同 API 開発用のサードパーティープラットフォームである [https://www.postman.com/](https://www.postman.com/) を使用してセットアップをテストすることをお勧めします。
**Postman を使用してセキュリティ設定を行うには**
1. ターゲットドメインで、ドキュメントのインデックスを作成します。リクエストの例を次に示します:
```
POST https://dst-domain.us-east-1.es.amazonaws.com/books/_doc/1
{
"Dracula": "Bram Stoker"
}
```
1. ソースドメインからこのインデックスを照会するには、クエリ内にターゲットドメインの接続エイリアスを含めます。接続エイリアスは、ドメインダッシュボードの [接続] タブで確認できます。以下は、リクエストと切り捨てられたレスポンスの例です。
```
GET https://src-domain.us-east-1.es.amazonaws.com/connection_alias:books/_search
{
...
"hits": [
{
"_index": "source-destination:books",
"_type": "_doc",
"_id": "1",
"_score": 1,
"_source": {
"Dracula": "Bram Stoker"
}
}
]
}
```
1. (オプション) 1 回の検索で複数のドメインを含む設定を作成できます。例えば、次のように設定したとします。
接続エイリアス名を `cluster_b` とする `domain-a` から `domain-b` への接続
接続エイリアス名を `cluster_c` とする `domain-a` から `domain-c` への接続
この場合、検索にはコンテンツ `domain-a`、`domain-b`、および `domain-c` が含まれます。以下はリクエストとレスポンスのサンプルです:
リクエスト
```
GET https://src-domain.us-east-1.es.amazonaws.com/local_index,cluster_b:b_index,cluster_c:c_index/_search
{
"query": {
"match": {
"user": "domino"
}
}
}
```
レスポンス:
```
{
"took": 150,
"timed_out": false,
"_shards": {
"total": 3,
"successful": 3,
"failed": 0,
"skipped": 0
},
"_clusters": {
"total": 3,
"successful": 3,
"skipped": 0
},
"hits": {
"total": 3,
"max_score": 1,
"hits": [
{
"_index": "local_index",
"_type": "_doc",
"_id": "0",
"_score": 1,
"_source": {
"user": "domino",
"message": "This is message 1",
"likes": 0
}
},
{
"_index": "cluster_b:b_index",
"_type": "_doc",
"_id": "0",
"_score": 2,
"_source": {
"user": "domino",
"message": "This is message 2",
"likes": 0
}
},
{
"_index": "cluster_c:c_index",
"_type": "_doc",
"_id": "0",
"_score": 3,
"_source": {
"user": "domino",
"message": "This is message 3",
"likes": 0
}
}
]
}
}
```
接続のセットアップで使用できないクラスターをスキップしなかった場合、検索リクエストを正常に実行するには、検索するすべての宛先クラスターが使用可能である必要があります。そうでない場合は、リクエスト全体が失敗します ドメインのうち、いずれか 1 つだけが使用できない場合でも、検索結果は返されません。
## 接続を削除する
接続を削除すると、ターゲットドメインのクラスター間検索オペレーションが停止します。
接続を削除するには、ソースドメインまたはターゲットドメインのいずれかで次の手順を実行できます。接続を削除した後も、15 日間は `Deleted` のステータスで表示されたままになります。
アクティブなクラスター間接続のあるドメインは削除できません。ドメインを削除するには、まずそのドメインからすべての受信接続と送信接続を削除します。この操作は、ドメインを削除する前にクラスター間ドメインのユーザーを考慮するために行います。
**接続を削除する方法**
1. [https://console.aws.amazon.com/aos/home](https://console.aws.amazon.com/aos/home) で Amazon OpenSearch Service コンソールにサインインします。
1. 左側のナビゲーションペインで **[ドメイン]** を選択します。
1. 削除するドメインの名前を選択し、**[接続]** タブを選択します。
1. 削除する接続の名前を選択します。
1. **[削除]** を選択し、削除を確定します。
# VPC エンドポイントからの OpenSearch UI へのアクセスの管理
AWS PrivateLinkを使用して、VPC と OpenSearch UI の間にプライベート接続を確立できます。この接続を使用すると、同じ VPC 内にあるかのように OpenSearch UI アプリケーションにアクセスできます。これにより、インターネットゲートウェイ、NAT デバイス、VPN 接続、または を設定 AWS Direct Connect して接続を確立する必要はありません。VPC のインスタンスは、パブリック IP アドレスがなくても OpenSearch UI にアクセスできます。
このプライベート接続を確立するには、まず を使用するインターフェイスエンドポイントを作成します AWS PrivateLink。インターフェースエンドポイントに指定した各サブネットには、エンドポイント用のネットワークインターフェースが自動的に作成されます。これらはリクエスター管理型ネットワークインターフェースであり、OpenSearch UI アプリケーション宛てのトラフィックのエントリポイントとして機能します。
## VPC と OpenSearch UI 間のプライベート接続の作成
AWS マネジメントコンソール または を使用して、VPC から OpenSearch UI にアクセスするためのプライベート接続を作成できます AWS CLI。
### VPC と OpenSearch UI 間のプライベート接続の作成 (コンソール)
**コンソールを使用して VPC と OpenSearch UI 間のプライベート接続を作成するには**
1. [https://console.aws.amazon.com/aos/home](https://console.aws.amazon.com/aos/home) で Amazon OpenSearch Service コンソールにサインインします。
1. 左側のナビゲーションの **[サーバーレス]** で、**[VPC エンドポイント]** を選択します。
1. **[Create VPC endpoint]** (VPC エンドポイントの作成) を選択します。
1. **[名前]** に、エンドポイントの名前を入力します。
1. **[VPC]** で OpenSearch UI アプリケーションにアクセスする VPC を選択します。
1. **[サブネット]** で、OpenSearch UI アプリケーションにアクセスするサブネットを 1 つ選択します。
**注記**
エンドポイントの IP アドレスと DNS タイプはサブネットタイプに基づいています:
デュアルスタック: すべてのサブネットに IPv4 および IPv6 のアドレス範囲が設定されている場合。
IPv6: すべてのサブネットが IPv6 のみのサブネットの場合。
IPv4: すべてのサブネットに IPv4 アドレス範囲がある場合。
1. **[セキュリティグループ]** で、エンドポイントネットワークインターフェイスに関連付けるセキュリティグループを 1 つ以上選択します。
**注記**
このステップでは、エンドポイントに対して承認するインバウンドトラフィックのポート、プロトコル、およびソースを制限しています。OpenSearch UI アプリケーションとの通信に VPC エンドポイントを使用するリソースがエンドポイントのネットワークインターフェイスと通信できるように、セキュリティグループルールが設定されていることを確認します。
1. 8. **エンドポイントの作成** を選択します。
### VPC と OpenSearch UI 間のプライベート接続の作成 (AWS CLI)
**を使用して VPC と OpenSearch UI の間にプライベート接続を作成するには AWS CLI**
以下のコマンドを実行してください。*プレースホルダー値*を、ユーザー自身の情報に置き換えます。
```
aws opensearchserverless create-vpc-endpoint \
--region region \
--endpoint endpoint \
--name vpc_endpoint_name \
--vpc-id vpc_id \
--subnet-ids subnet_ids
```
## OpenSearch UI アプリケーションへのアクセスを許可するように VPC エンドポイントポリシーを更新する
プライベート接続を作成したら、VPC エンドポイントポリシーを更新して、アプリケーション ID を指定して VPC エンドポイントポリシーの OpenSearch UI アプリケーションへのアクセスを許可します。
VPC エンドポイントポリシーの更新ついては、「*AWS PrivateLink ガイド*」の「[VPC エンドポイントポリシーの更新](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html#update-vpc-endpoint-policy)」を参照してください。
VPC エンドポイントポリシーに次のステートメントが含まれていることを確認します。*プレースホルダー値*を、ユーザー自身の情報に置き換えます。
```
{
"Statement": [{
"Action": ["opensearch:*"],
"Effect": "Allow",
"Principal": "*",
"Resource": "*",
"Condition": {
"StringEquals": {
"opensearch:ApplicationId": ["opensearch-ui-application-id"]
}
}
}]
}
```
## VPC エンドポイントポリシーでの OpenSearch UI へのアクセスの取り消し
OpenSearch UI では、ユーザーが VPC からアプリケーションにアクセスできるようにするには、VPC エンドポイントポリシーに明示的なアクセス許可が必要です。ユーザーが VPC から OpenSearch UI にアクセスする必要がなくなった場合は、エンドポイントポリシーのアクセス許可を削除できます。その後、OpenSearch UI にアクセスしようとすると、ユーザーに `403 forbidden` エラーメッセージが表示されます。
VPC エンドポイントポリシーの更新ついては、「*AWS PrivateLink ガイド*」の「[VPC エンドポイントポリシーの更新](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html#update-vpc-endpoint-policy)」を参照してください。
以下は、VPC からの UI アプリケーションへのアクセスを拒否する VPC エンドポイントポリシーの例です。
```
{
"Statement": [{
"Action": ["opensearch:*"],
"Effect": "Allow",
"Principal": "*",
"Resource": "*",
"Condition": {
"StringEquals": {
"opensearch:ApplicationId": [""]
}
}
}]
}
```
# 保存されたオブジェクトを OpenSearch Dashboards から OpenSearch UI に移行する
OpenSearch Dashboards に既存のダッシュボード、ビジュアライゼーション、インデックスパターン、およびその他の保存されたオブジェクトがある場合は、OpenSearch UI でそれらを移行して再利用できます。
OpenSearch UI に移行するメリット:
+ **高可用性** — OpenSearch UI は でホスト AWS クラウド され、ドメインのアップグレードとメンテナンス中は引き続き使用できますが、OpenSearch Dashboards はドメイン内でホストされ、一時的に使用できなくなります。
+ **複数のデータソース** – OpenSearch UI は、OpenSearch ドメイン、サーバーレスコレクション、Amazon OpenSearch S3 および Amazon CloudWatch とのデータ接続など、複数のデータソースにまたがる統合された単一ペインを提供できますが、各 OpenSearch Dashboards は 1 つのドメインまたはコレクションでのみ使用できます。 Amazon S3
+ AI Assistant や WorkSpaces などの追加機能は、OpenSearch UI で利用できます。詳細については、「」を参照してください[Amazon OpenSearch Service での OpenSearch UI の使用](application.md)。
**Topics**
+ [移行の概要](#application-migrate-saved-objects-overview)
+ [前提条件](#application-migrate-saved-objects-prerequisites)
+ [ステップ 1: OpenSearch Dashboards から保存されたオブジェクトをエクスポートする](#application-migrate-saved-objects-export)
+ [ステップ 2: 保存したオブジェクトを OpenSearch UI にインポートする](#application-migrate-saved-objects-import)
## 移行の概要
移行プロセスは、以下の大まかなステップで構成されます。
1. **OpenSearch Dashboards から保存済みオブジェクトをエクスポート** – OpenSearch Dashboards の保存済みオブジェクト管理 UI またはエクスポート API を使用して、ダッシュボード、視覚化、インデックスパターン、およびその他のオブジェクトを改行区切り JSON (NDJSON) ファイルとしてダウンロードします。
1. **OpenSearch UI アプリケーションとワークスペースを作成する** – まだ作成していない場合は、OpenSearch UI アプリケーションとワークスペースを作成して、インポートされたオブジェクトを受信します。
1. **OpenSearch UI にデータソースを登録する** – OpenSearch ドメインを OpenSearch UI アプリケーションに関連付け、ワークスペース内のデータソースとして登録します。インポートされたオブジェクトのインデックスパターンは、このデータソースを参照します。
1. **OpenSearch UI への保存済みオブジェクトのインポート** – OpenSearch UI の保存済みオブジェクト管理 UI またはインポート API を使用して、NDJSON ファイルをターゲットワークスペースにアップロードします。
1. **インポートされたオブジェクトを検証する** – OpenSearch UI でダッシュボードとビジュアライゼーションを開き、それらが正しく表示され、関連するドメインまたはコレクションからデータが流れていることを確認します。
## 前提条件
移行する前に、次の前提条件を確認してください。
+ Amazon OpenSearch Service および OpenSearch APIs を呼び出すために必要な OpenSearch IAM アクセス許可があります。詳細については、「[Amazon OpenSearch Service アプリケーションを作成するために必要なアクセス許可](application-getting-started.md#application-prerequisite-permissions)」を参照してください。
+ ドメインまたはコレクション、および移行する OpenSearch Dashboards にアクセスできます。
+ OpenSearch UI アプリケーションを作成しました。アプリケーションとワークスペースの作成については、「」を参照してください[Amazon OpenSearch Service における OpenSearch ユーザーインターフェースの開始方法](application-getting-started.md)。
+ 同じドメインまたはコレクションを OpenSearch UI アプリケーションに関連付けています。データソースの関連付けについては、「」を参照してください[データソースの関連付けと Virtual Private Cloud アクセス許可の管理](application-data-sources-and-vpc.md)。
**注記**
OpenSearch UI は OpenSearch バージョン 1.3 以降のみをサポートしています。保存したオブジェクトを移行する前に、OpenSearch ドメインがバージョン 1.3 以降を実行していることを確認します。
## ステップ 1: OpenSearch Dashboards から保存されたオブジェクトをエクスポートする
管理 UI またはエクスポート API を使用して、保存されたオブジェクトを OpenSearch Dashboards からエクスポートします。エクスポートでは、選択したすべての保存済みオブジェクトタイプとその依存関係を含む改行区切りの JSON (NDJSON) ファイルが生成されます。
**Topics**
+ [OpenSearch Dashboards で手動でエクスポートする](#application-migrate-export-console)
+ [API を使用したエクスポート](#application-migrate-export-api)
### OpenSearch Dashboards で手動でエクスポートする
**OpenSearch Dashboards 管理 UI を使用して保存済みオブジェクトをエクスポートするには**
1. OpenSearch Dashboards インスタンスを開きます。
1. 左側のナビゲーションパネルで、**管理**を選択します。
1. **ダッシュボード管理**で、**保存済みオブジェクト**を選択します。
1. エクスポートする保存済みオブジェクトを選択します。特定のタイプのすべてのオブジェクトをエクスポートするには、検索バーを使用してタイプでフィルタリングします。すべてのオブジェクトをエクスポートするには、テーブルヘッダーのチェックボックスをオンにします。
1. **[エクスポート]** を選択します。
1. 保存**済みオブジェクトのエクスポート**ダイアログボックスで、**関連するオブジェクトを含める**が選択されていることを確認します。このオプションには、ビジュアライゼーションによって参照されるインデックスパターンなど、選択した保存済みオブジェクトが依存するすべてのオブジェクトが含まれます。このオプションは、依存関係を手動で管理する場合にのみクリアします。
1. **エクスポート** を選択して、`.ndjson`ファイルをローカルマシンにダウンロードします。
**ヒント**
**関連オブジェクトを含める**を選択すると、エクスポートされた NDJSON ファイルには、依存するインデックスパターン、ビジュアライゼーション、検索オブジェクトなど、選択したダッシュボードとビジュアライゼーションのレンダリングに必要なすべての保存済みオブジェクトが含まれます。これにより、インポートステップが簡素化され、参照エラーの欠落を回避できます。
### API を使用したエクスポート
OpenSearch Dashboards の保存済みオブジェクトのエクスポート API を使用して、保存済みオブジェクトをプログラムでエクスポートできます。これは、移行を自動化したり、エクスポートステップを CI/CD パイプラインに統合したりするのに役立ちます。
**注記**
OpenSearch ドメインで[きめ細かなアクセスコントロール](fgac.md)が有効になっている場合は、エクスポートリクエストで認証情報を指定する必要があります。ユーザー名とパスワードで `-u`フラグを追加して、HTTP 基本認証を使用します。認証オプションの詳細については、「[Amazon OpenSearch Service のきめ細かなアクセスコントロール](fgac.md)」を参照してください。
次の の例では、関連するオブジェクトを含むすべてのダッシュボードをエクスポートします。*プレースホルダー値*を、ユーザー自身の情報に置き換えます。
```
curl -X POST \
"https://dashboards-endpoint/_dashboards/api/saved_objects/_export" \
-u 'master-username:master-password' \
-H "Content-Type: application/json" \
-H "osd-xsrf: true" \
-d '{
"type": ["dashboard", "visualization", "index-pattern", "search"],
"includeReferencesDeep": true,
"excludeExportDetails": false
}' \
-o saved-objects-export.ndjson
```
ドメインできめ細かなアクセスコントロールが有効になっていない場合は、 `-u`フラグを省略できます。
特定の保存済みオブジェクトを ID でエクスポートするには、 の代わりに `objects`パラメータを使用します`type`。
```
curl -X POST \
"https://dashboards-endpoint/_dashboards/api/saved_objects/_export" \
-u 'master-username:master-password' \
-H "Content-Type: application/json" \
-H "osd-xsrf: true" \
-d '{
"objects": [
{"type": "dashboard", "id": "dashboard-id"},
{"type": "visualization", "id": "visualization-id"}
],
"includeReferencesDeep": true
}' \
-o saved-objects-export.ndjson
```
**注記**
保存済みオブジェクト IDs を検索するには、保存済みオブジェクト API を使用して、特定のタイプのすべてのオブジェクトを一覧表示します。次の の例では、すべてのダッシュボードを一覧表示します。
```
curl -X GET \
"https://dashboards-endpoint/_dashboards/api/saved_objects/_find?type=dashboard" \
-u 'master-username:master-password'
```
レスポンスには、保存された各オブジェクトの ID が含まれます。OpenSearch Dashboards でオブジェクトを表示するときに、ブラウザ URL で ID を見つけることもできます。
## ステップ 2: 保存したオブジェクトを OpenSearch UI にインポートする
保存したオブジェクトをエクスポートした後、NDJSON ファイルを OpenSearch UI に手動でインポートするか、API 経由でインポートできます。
**Topics**
+ [OpenSearch UI に手動でインポートする](#application-migrate-import-console)
+ [API 経由でのインポート](#application-migrate-import-api)
### OpenSearch UI に手動でインポートする
**OpenSearch UI 管理 UI を使用して保存済みオブジェクトをインポートするには**
1. OpenSearch UI アプリケーションを開き、ターゲットワークスペースに移動します。
1. ワークスペースで、上部のナビゲーションから**アセット**を選択するか、ワークスペースアセットページに移動します。
1. **Import** を選択して、**Import assets** ダイアログを開きます。
1. **ファイルの選択** を選択し、OpenSearch Dashboards からエクスポートした`.ndjson`ファイルを選択します。
1. **競合管理**では、次のいずれかを選択します。
+ **一意の IDs を使用して新しいアセットを作成する** (デフォルト) – インポートされたすべてのオブジェクトに新しい IDs を生成し、既存のアセットとの競合を回避します。
+ **既存のアセットをチェックする** – 既存のオブジェクトとの競合をチェックします。選択したら、次のいずれかのサブオプションを選択します。
+ **競合を自動的に上書き**する – 同じ ID を持つ既存のアセットは自動的に置き換えられます。
+ **競合に対するアクションのリクエスト** – 各競合を個別に解決するように求められます。
1. [**インポート**] を選択します。
1. インポートの概要を確認します。
### API 経由でのインポート
AWS 署名バージョン 4 認証で API を使用して保存済みオブジェクトをインポートするには、まずデータソース ID を取得し、インポートリクエストで使用する必要があります。*プレースホルダー値*を、ユーザー自身の情報に置き換えます。
ステップ 1: ワークスペースのデータソース ID を取得する:
```
curl -X GET \
"https://opensearch-ui-endpoint/w/workspace-id/api/saved_objects/_find?type=data-source" \
--aws-sigv4 "aws:amz:region:opensearch" \
--user "$AWS_ACCESS_KEY_ID:$AWS_SECRET_ACCESS_KEY" \
-H "x-amz-security-token: $AWS_SESSION_TOKEN" \
-H "osd-xsrf: true"
```
**注記**
レスポンスにはデータソース ID が含まれます。OpenSearch UI でデータソースを表示するときに、ブラウザ URL でデータソース ID を確認することもできます。
ステップ 2: ステップ 1 のデータソース ID を使用して保存されたオブジェクトをインポートします。
```
curl -X POST \
"https://opensearch-ui-endpoint/w/workspace-id/api/saved_objects/_import?overwrite=true&dataSourceId=data-source-id" \
--aws-sigv4 "aws:amz:region:opensearch" \
--user "$AWS_ACCESS_KEY_ID:$AWS_SECRET_ACCESS_KEY" \
-H "x-amz-security-token: $AWS_SESSION_TOKEN" \
-H "osd-xsrf: true" \
-F "file=@saved-objects-export.ndjson"
```
**注記**
これらの例では、curl の組み込み`--aws-sigv4`オプション (curl 7.75 以降で利用可能) を使用してリクエストに署名します。コマンドを実行する前に、認証情報を環境変数として設定します AWS 。`AWS_ACCESS_KEY_ID`、`AWS_SECRET_ACCESS_KEY`、および `AWS_SESSION_TOKEN` (一時的な認証情報を使用している場合）。
# OpenSearch UI エンドポイントとクォータ
プログラムで AWS サービスに接続するには、 エンドポイントを使用します。サービスクォータ (制限とも呼ばれます) は、 AWS アカウントのサービスリソースまたはオペレーションの最大数です。
Amazon OpenSearch UI は、OpenSearch Dashboards 用の次世代 OpenSearch ユーザーインターフェイスです。OpenSearch ダッシュボードにアクセスするためのエンドポイントを提供します。このトピックを使用して、OpenSearch UI のサービスエンドポイントとサービスクォータを検索します。
他の OpenSearch サービスの詳細については、「[サービスエンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/opensearch-service.html)」を参照してください。
## OpenSearch UI エンドポイント
OpenSearch UI は次のリージョンで利用できます。
| リージョン名 | リージョン | エンドポイント | プロトコル |
| --- | --- | --- | --- |
| アジアパシフィック (ムンバイ) | ap-south-1 | opensearch.ap-south-1.amazonaws.com es.ap-south-1.amazonaws.com | HTTPS HTTPS |
| 欧州 (パリ) | eu-west-3 | opensearch.eu-west-3.amazonaws.com es.eu-west-3.amazonaws.com | HTTPS HTTPS |
| 米国東部 (オハイオ) | us-east-2 | opensearch.us-east-2.amazonaws.com es.us-east-2.amazonaws.com | HTTPS HTTPS |
| 欧州 (アイルランド) | eu-west-1 | opensearch.eu-west-1.amazonaws.com es.eu-west-1.amazonaws.com | HTTPS HTTPS |
| 欧州 (フランクフルト) | eu-central-1 | opensearch.eu-central-1.amazonaws.com es.eu-central-1.amazonaws.com | HTTPS HTTPS |
| 南米 (サンパウロ) | sa-east-1 | opensearch.sa-east-1.amazonaws.com es.sa-east-1.amazonaws.com | HTTPS HTTPS |
| 米国東部 (バージニア北部) | us–east–1 | opensearch.us-east-1.amazonaws.com es.us-east-1.amazonaws.com | HTTPS HTTPS |
| 欧州 (ロンドン) | eu-west-2 | opensearch.eu-west-2.amazonaws.com es.eu-west-2.amazonaws.com | HTTPS HTTPS |
| アジアパシフィック (東京) | ap-northeast-1 | opensearch.ap-northeast-1.amazonaws.com es.ap-northeast-1.amazonaws.com | HTTPS HTTPS |
| 米国西部 (オレゴン) | us-west-2 | opensearch.us-west-2.amazonaws.com es.us-west-2.amazonaws.com | HTTPS HTTPS |
| アジアパシフィック (シンガポール) | ap-southeast-1 | opensearch.ap-southeast-1.amazonaws.com es.ap-southeast-1.amazonaws.com | HTTPS HTTPS |
| アジアパシフィック (シドニー) | ap-southeast-2 | opensearch.ap-southeast-2.amazonaws.com es.ap-southeast-2.amazonaws.com | HTTPS HTTPS |
| カナダ (中部) | ca-central-1 | opensearch.ca-central-1.amazonaws.com es.ca-central-1.amazonaws.com | HTTPS HTTPS |
| 欧州 (ストックホルム) | eu-north-1 | opensearch.eu-north-1.amazonaws.com es.eu-north-1.amazonaws.com | HTTPS HTTPS |
| アジアパシフィック (香港) | ap-east-1 | opensearch.ap-east-1.amazonaws.com es.ap-east-1.amazonaws.com | HTTPS HTTPS |
| アジアパシフィック (ソウル) | ap-northeast-2 | opensearch.ap-northeast-2.amazonaws.com es.ap-northeast-2.amazonaws.com | HTTPS HTTPS |
| アジアパシフィック (大阪) | ap-northeast-3 | opensearch.ap-northeast-3.amazonaws.com es.ap-northeast-3.amazonaws.com | HTTPS HTTPS |
| アジアパシフィック (ハイデラバード) | ap-south-2 | opensearch.ap-south-2.amazonaws.com es.ap-south-2.amazonaws.com | HTTPS HTTPS |
| 欧州 (スペイン) | eu-south-2 | opensearch.eu-south-2.amazonaws.com es.eu-south-2.amazonaws.com | HTTPS HTTPS |
| 米国西部 (北カリフォルニア) | us-west-1 | opensearch.us-west-1.amazonaws.com es.us-west-1.amazonaws.com | HTTPS HTTPS |
| 欧州 (チューリッヒ) | eu-central-2 | opensearch.eu-central-2.amazonaws.com es.eu-central-2.amazonaws.com | HTTPS HTTPS |
| ヨーロッパ (ミラノ) | eu-south-1 | opensearch.eu-south-1.amazonaws.com es.eu-south-1.amazonaws.com | HTTPS HTTPS |
## OpenSearch UI サービスクォータ
AWS アカウントには、OpenSearch UI リソースに関連する次のクォータがあります。
| 名前 | デフォルト | 引き上げ可能 | 注意事項 |
| --- | --- | --- | --- |
| アカウントごと、リージョンごとの OpenSearch UI アプリケーション | 30 | はい | リージョンごとにアカウントごとに作成できる OpenSearch UI アプリケーションの最大数。 サービスクォータを使用して制限を 50 に引き上げ、自動的に承認を受けることができます。上限の引き上げをリクエストするには、サポートチケットを送信します。 |