翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon Data Firehose AWS Secrets Manager で を使用して認証する
Amazon Data Firehose は と統合 AWS Secrets Manager して、シークレットへの安全なアクセスを提供し、認証情報のローテーションを自動化します。この統合により、Firehose は実行時に Secrets Manager からシークレットを取得して、前述のストリーミングの宛先に接続し、データストリームを配信できます。これにより、 AWS マネジメントコンソール または API パラメータのストリーム作成ワークフロー中にシークレットがプレーンテキストで表示されません。シークレットを管理するための安全なプラクティスを提供し、パスワードローテーションを管理するためのカスタム Lambda 関数の設定など、複雑な認証情報管理アクティビティから解放します。
詳細については、「[AWS Secrets Manager ユーザーガイド](https://docs.aws.amazon.com/secretsmanager/latest/userguide)」を参照してください。
**Topics**
+ [シークレットを理解する](secrets-manager-whats-secret.md)
+ [シークレットを作成する](secrets-manager-create.md)
+ [シークレットを使用する](secrets-manager-how.md)
+ [シークレットをローテーションする](secrets-manager-rotate.md)
# シークレットを理解する
シークレットは、パスワード、ユーザーネームやパスワードなどの一連の認証情報、OAuth トークン、または、暗号化された形式で Secrets Manager に保存されるその他のシークレット情報にすることができます。
宛先ごとに、次のセクションに示すように、シークレット key-value ペアを正しい JSON 形式で指定する必要があります。Amazon Data Firehose は、シークレットが宛先に基づいて正しい JSON 形式を持っていない場合、宛先への接続に失敗します。
**MySQL や PostgreSQL などのデータベースのシークレットの形式**
```
{
"username": "",
"password": ""
}
```
**Amazon Redshift プロビジョンドクラスターと Amazon Redshift Serverless ワークグループのシークレットの形式**
```
{
"username": "",
"password": ""
}
```
**Splunk のシークレットの形式**
```
{
"hec_token": ""
}
```
**Snowflake のシークレットの形式**
```
{
"user": "",
"private_key": "", // without the beginning and ending private key, remove all spaces and newlines
"key_passphrase": "" // optional
}
```
**HTTP エンドポイント、Coralogix、Datadog、Dynatrace、Elastic、Honeycomb、LogicMonitor、Logz.io、MongoDB Cloud、および New Relic のシークレットの形式**
```
{
"api_key": ""
}
```
# シークレットを作成する
シークレットを作成するには、「 *AWS Secrets Manager ユーザーガイド*」の[「 AWS Secrets Manager シークレットを作成する](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html)」の手順に従います。
# シークレットを使用する
AWS Secrets Manager を使用して認証情報またはキーを保存し、Amazon Redshift、HTTP エンドポイント、Snowflake、Splunk、Coralogix、Datadog、Dynatrace、Elastic、Honeycomb、LogicMonitor、Logz.io、MongoDB Cloud、New Relic などのストリーミング送信先に接続することをお勧めします。
Firehose ストリームの作成時に、 AWS マネジメントコンソールを通じて Secrets Manager を使用して、これらの宛先のために認証を設定できます。詳細については、「[宛先の設定を構成する](create-destination.md)」を参照してください。あるいは、[CreateDeliveryStream](https://docs.aws.amazon.com/firehose/latest/APIReference/API_CreateDeliveryStream.html) および [UpdateDestination](https://docs.aws.amazon.com/firehose/latest/APIReference/API_UpdateDestination.html) API オペレーションを使用して Secrets Manager による認証を設定することもできます。
Firehose は暗号化を使用してシークレットをキャッシュし、宛先への各接続のためにそれらを使用します。最新の認証情報が使用されるように、10 分ごとにキャッシュを更新します。
ストリームのライフサイクル中はいつでも、Secrets Manager からシークレットを取得する機能をオフにすることを選択できます。シークレットを取得するために Secrets Manager を使用しない場合は、代わりにユーザー名/パスワードまたは API キーを使用できます。
**注記**
Firehose ではこの機能には追加コストはかかりませんが、Secrets Manager へのアクセスとメンテナンスについては課金されます。詳細については、[AWS Secrets Manager](https://aws.amazon.com/secrets-manager/pricing/) の料金ページを参照してください。
## シークレットを取得するために Firehose へのアクセスを付与する
Firehose がシークレットを取得するには AWS Secrets Manager、シークレットにアクセスするために必要なアクセス許可と、シークレットを暗号化するキーを Firehose に提供する必要があります。
AWS Secrets Manager を使用してシークレットを保存および取得する場合、シークレットの保存場所と暗号化方法に応じて、いくつかの異なる設定オプションがあります。
+ シークレットが IAM ロールと同じ AWS アカウントに保存されていて、デフォルトの AWS マネージドキー (`aws/secretsmanager`) で暗号化されている場合、Firehose が引き受ける IAM ロールはシークレットに対する`secretsmanager:GetSecretValue`アクセス許可のみを必要とします。
```
// secret role policy
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "secretsmanager:GetSecretValue",
"Resource": "Secret ARN"
}
]
}
```
IAM ポリシーの詳細については、「[Permissions policy examples for AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access_examples.html)」を参照してください。
+ シークレットがロールと同じアカウントに保存されているが、[カスタマーマネージドキー](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) (CMK) で暗号化されている場合、ロールには `secretsmanager:GetSecretValue` 許可と `kms:Decrypt` 許可の両方が必要です。また、CMK ポリシーは、IAM ロールが `kms:Decrypt` を実行することを許可する必要があります。
+ シークレットがロールとは異なる AWS アカウントに保存されていて、デフォルトの AWS マネージドキーで暗号化されている場合、シークレットが AWS マネージドキーで暗号化されている場合、Secrets Manager はクロスアカウントアクセスを許可しないため、この設定はできません。
+ シークレットが別のアカウントに保存され、CMK を使用して暗号化されている場合、IAM ロールにはシークレットに対する `secretsmanager:GetSecretValue` 許可と CMK に対する `kms:Decrypt` 許可が必要です。シークレットのリソースポリシーと他のアカウントの CMK ポリシーも、IAM ロールに必要な許可を付与する必要があります。詳細については、「[クロスアカウントアクセス](https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access_examples_cross.html)」を参照してください。
# シークレットをローテーションする
*ローテーション*とは、シークレットを定期的に更新することです。指定したスケジュールでシークレットを自動的にローテーション AWS Secrets Manager するように を設定できます。そうすれば、長期のシークレットを短期のシークレットに置き換えることができます。これは、侵害のリスクを低減するのに役立ちます。詳細については、「 *AWS Secrets Manager ユーザーガイド*」の[「シー AWS Secrets Manager クレットのロー](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets.html)テーション」を参照してください。