

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# Amazon OpenSearch Ingestion のロールとユーザーの設定
<a name="pipeline-security-overview"></a>

Amazon OpenSearch Ingestion では、ソースアプリケーションからパイプラインへの書き込みと、パイプラインからシンクへの書き込みを行えるように、さまざまなアクセス許可モデルと IAM ロールを使用しています。データの取り込みを開始する前に、特定のアクセス許可を持つ IAM ロールをユースケースに基づいて 1 つ以上作成する必要があります。

パイプラインを正常に設定するには、少なくとも次のロールが必要です。


| 名前 | 説明 | 
| --- | --- | 
| [**パイプラインロール**](#pipeline-security-sink) |  パイプラインロールは、パイプラインがソースから読み取り、ドメインまたはコレクションシンクに書き込むために必要なアクセス許可を付与します。パイプラインロールは手動で作成することも、OpenSearch Ingestion で作成することもできます。  | 
| [**取り込みロール**](#pipeline-security-same-account) |  取り込みロールには、パイプラインリソースの `osis:Ingest` 許可が含まれています。これにより、プッシュ型のソースはパイプラインにデータを取り込むことができます。  | 

次の図は、Amazon S3 や Fluent Bit などのデータソースから別のアカウントのパイプラインに書き込むときの一般的なパイプライン設定を示しています。この場合、パイプラインにアクセスするには、クライアントが取り込みロールを引き受けている必要があります。詳細については、「[クロスアカウント取り込み](#pipeline-security-different-account)」を参照してください。

![Fluent Bit から STS へのクロスアカウントデータフローは、ロール、取り込みロール、パイプライン、 OpenSearch シンクを引き受けます。](http://docs.aws.amazon.com/ja_jp/opensearch-service/latest/developerguide/images/pipeline-security.png)


簡単な設定ガイドについては、「[チュートリアル: Amazon OpenSearch Ingestion を使用してドメインにデータを取り込む](osis-get-started.md)」を参照してください。

**トピック**
+ [パイプラインロール](#pipeline-security-sink)
+ [取り込みロール](#pipeline-security-same-account)
+ [クロスアカウント取り込み](#pipeline-security-different-account)

## パイプラインロール
<a name="pipeline-security-sink"></a>

パイプラインは、ソースから読み込み、シンクに書き込むために特定のアクセス許可が必要です。これらのアクセス許可は、クライアントアプリケーションまたはパイプラインに書き込む AWS のサービス 、およびシンクが OpenSearch Service ドメイン、OpenSearch Serverless コレクション、または Amazon S3 OpenSearch のいずれであるかによって異なります。さらに、パイプラインには、ソースアプリケーションから物理的にデータを*プル*するための権限 (ソースがプルベースのプラグインの場合)、および S3 デッドレターキュー (有効化されている場合) に書き込むための権限が必要になる場合があります。

パイプラインを作成するときは、手動で作成した既存の IAM ロールを指定するか、選択したソースとシンクに基づいて OpenSearch Ingestion にパイプラインロールを自動的に作成させることができます。次の図は、 AWS マネジメントコンソールでパイプラインロールを指定する方法を示しています。

![Pipeline role section with Use an existing IAM role selected and Select an existing roleドロップダウン。](http://docs.aws.amazon.com/ja_jp/opensearch-service/latest/developerguide/images/pipeline-role.png)


**Topics**
+ [パイプラインロールの作成の自動化](#pipeline-role-auto-create)
+ [パイプラインロールの手動作成](#pipeline-role-manual-create)

### パイプラインロールの作成の自動化
<a name="pipeline-role-auto-create"></a>

OpenSearch Ingestion でパイプラインロールを作成するように選択できます。設定されたソースとシンクに基づいて、ロールに必要なアクセス許可が自動的に識別されます。`OpenSearchIngestion-` というプレフィックスと、入力したサフィックスを持つ IAM ロールを作成します。たとえば、サフィックスとして `PipelineRole` と入力すると、OpenSearch Ingestion は `OpenSearchIngestion-PipelineRole` という名前のロールを作成します。

パイプラインロールを自動で作成すると、セットアッププロセスが簡素化され、設定エラーの発生可能性が軽減されます。ロールの作成を自動化することで、アクセス許可を手動で割り当てる必要がなくなり、セキュリティの誤設定のリスクなしに正しいポリシーが適用されます。これにより時間を節約でき、ベストプラクティスを適用することでセキュリティコンプライアンスが強化され、複数のパイプラインデプロイ間で一貫性が確保されます。

OpenSearch Ingestion のみが AWS マネジメントコンソールでパイプラインロールを自動的に作成できます。 AWS CLI、OpenSearch Ingestion API、またはいずれかの SDKs を使用している場合は、手動で作成したパイプラインロールを指定する必要があります。

OpenSearch でロールを作成するには、**[新しいサービスロールを作成して使用]** を選択します。

**重要**  
パイプラインロールへのアクセスを許可するには、ドメインまたはコレクションアクセスポリシーを手動で変更する必要があります。詳細なアクセスコントロールを使用するドメインの場合は、パイプラインロールをバックエンドロールにマッピングする必要があります。これらのステップは、パイプラインの作成前または作成後に実行できます。  
手順については、次のトピックを参照してください。  
[Configure data access for the domain](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/pipeline-domain-access.html#pipeline-access-domain)
[Configure data and network access for the collection](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/pipeline-domain-access.html#pipeline-collection-acces)

### パイプラインロールの手動作成
<a name="pipeline-role-manual-create"></a>

特定のセキュリティまたはコンプライアンス要件を満たすためにアクセス許可をより細かく制御する必要がある場合は、パイプラインロールを手動で作成することをお勧めします。手動作成では、既存のインフラストラクチャまたはアクセス管理戦略に合わせてロールを調整できます。また、手動セットアップを選択して、ロールを他の と統合 AWS のサービス したり、独自の運用ニーズに合わせて調整したりできます。

手動で作成したパイプラインロールを選択するには、**[既存の IAM ロールを使用]** を選択し、既存のロールを選択します。ロールには、選択したソースからデータを受信し、選択したシンクに書き込むために必要なすべてのアクセス許可が必要です。以下のセクションでは、パイプラインロールを手動で作成する方法について説明します。

**Topics**
+ [ソースから読み取るためのアクセス許可](#pipeline-security--source)
+ [ドメインシンクに書き込むためのアクセス許可](#pipeline-security-domain-sink)
+ [コレクションシンクに書き込むためのアクセス許可](#pipeline-security--collection-sink)
+ [Amazon S3 またはデッドレターキューに書き込むためのアクセス許可](#pipeline-security-dlq)

#### ソースから読み取るためのアクセス許可
<a name="pipeline-security--source"></a>

OpenSearch Ingestion パイプラインには、指定されたソースからデータを読み取って受信するためのアクセス許可が必要です。例えば、Amazon DynamoDB ソースの場合、`dynamodb:DescribeTable` や `dynamodb:DescribeStream` などのアクセス許可が必要です。Amazon S3、Fluent Bit、OpenTelemetry Collector などの一般的なソースのパイプラインロールアクセスポリシーの例については、「[Amazon OpenSearch Ingestion パイプラインを他のサービスやアプリケーションと統合する](configure-client.md)」を参照してください。

#### ドメインシンクに書き込むためのアクセス許可
<a name="pipeline-security-domain-sink"></a>

OpenSearch Ingestion パイプラインには、シンクとして設定されている OpenSearch Service ドメインに書き込むためのアクセス許可が必要です。これらのアクセス許可には、ドメインを記述して、そこに HTTP リクエストを送信できることが含まれます。これらのアクセス許可は、パブリックパイプラインと VPC ドメインのどちらも同じです。パイプラインロールを作成し、ドメインアクセスポリシーで指定する手順については、「[Allowing pipelines to access domains](pipeline-domain-access.md)」を参照してください。

#### コレクションシンクに書き込むためのアクセス許可
<a name="pipeline-security--collection-sink"></a>

シンクとして設定されている OpenSearch Serverless コレクションに書き込みを行うときは、OpenSearch Ingestion パイプラインにアクセス権限が必要になります。これらのアクセス権限には、コレクションを記述しそこに HTTP リクエストを送信できることが含まれます。

まず、パイプラインロールのアクセスポリシーが必要なアクセス許可を付与していることを確認します。次に、このロールをデータアクセスポリシーに追加し、インデックスの作成、インデックスの更新、インデックスの記述、コレクション内でのドキュメントの書き込みを行うためのアクセス権限をそれに付与します。これらの各ステップを完了する手順については、「[パイプラインにコレクションへのアクセスを許可する](pipeline-collection-access.md)」を参照してください。

#### Amazon S3 またはデッドレターキューに書き込むためのアクセス許可
<a name="pipeline-security-dlq"></a>

パイプラインのシンク送信先として Amazon S3 を指定する場合、または[デッドレターキュー](https://opensearch.org/docs/latest/data-prepper/pipelines/dlq/) (DLQ) を有効にする場合、パイプラインロールは送信先として指定した S3 バケットへのアクセスを許可する必要があります。

DLQ アクセスを提供するパイプラインロールに別の許可ポリシーをアタッチします。少なくとも、ロールにはバケットリソースに対する `S3:PutObject` アクションが付与されている必要があります。

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Sid": "WriteToS3DLQ",
      "Effect": "Allow",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::{{my-dlq-bucket}}/*"
    }
  ]
}
```

------

## 取り込みロール
<a name="pipeline-security-same-account"></a>

取り込みロールは、外部サービスが OpenSearch Ingestion パイプラインと安全にやり取りしてデータを送信できるようにする IAM ロールです。Amazon Security Lake などのプッシュベースのソースの場合、このロールは、`osis:Ingest` を含むパイプラインにデータをプッシュするためのアクセス許可を付与する必要があります。Amazon S3 などのプルベースのソースの場合、ロールは OpenSearch Ingestion がロールを引き受け、必要なアクセス許可でデータにアクセスできるようにする必要があります。

**Topics**
+ [プッシュベースのソース用の取り込みロール](#ingestion-role-push-based)
+ [プルベースのソース用の取り込みロール](#ingestion-role-pull-based)
+ [クロスアカウント取り込み](#pipeline-security-different-account)

### プッシュベースのソース用の取り込みロール
<a name="ingestion-role-push-based"></a>

プッシュベースのソースの場合、データは Amazon Security Lake や Amazon DynamoDB などの別のサービスから取り込みパイプラインに送信またはプッシュされます。このシナリオでは、取り込みロールには、少なくともパイプラインを操作するための `osis:Ingest` アクセス許可が必要です。

次の IAM アクセスポリシーは、このアクセス許可を取り込みロールに付与する方法を示しています。

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "osis:Ingest"
      ],
      "Resource": "arn:aws:osis:{{us-east-1}}:{{111122223333}}:pipeline/{{pipeline-name}}/*"
    }
  ]
}
```

------

### プルベースのソース用の取り込みロール
<a name="ingestion-role-pull-based"></a>

プルベースのソースの場合、OpenSearch Ingestion パイプラインは Amazon S3 などの外部ソースからデータをアクティブにプルまたは取得します。この場合、パイプラインはデータソースにアクセスするために必要なアクセス許可を付与する IAM パイプラインロールを引き受ける必要があります。これらのシナリオでは、*取り込みロール*は*パイプラインロール*と同義です。

ロールには、OpenSearch Ingestion がロールを引き受けられるようにする信頼関係と、データソースに固有のアクセス許可を含める必要があります。詳細については、「[ソースから読み取るためのアクセス許可](#pipeline-security--source)」を参照してください。

### クロスアカウント取り込み
<a name="pipeline-security-different-account"></a>

アプリケーションアカウントなど AWS アカウント、別のパイプラインにデータを取り込む必要がある場合があります。クロスアカウント取り込みを設定するには、パイプラインと同じアカウント内で取り込みロールを定義し、その取り込みロールとアプリケーションアカウント間に信頼関係を確立します。

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [{
     "Effect": "Allow",
     "Principal": {
       "AWS": "arn:aws:iam::{{444455556666}}:root"
      },
     "Action": "sts:AssumeRole"
  }]
}
```

------

次に、取り込みロールを引き受けるようにアプリケーションを設定します。アプリケーションアカウントは、パイプラインアカウントの取り込みロールに対する [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) 許可を、アプリケーションロールに付与する必要があります。

詳細な手順と IAM ポリシーの例については、「[クロスアカウント取り込みアクセスの提供](configure-client.md#configure-client-cross-account)」を参照してください。