翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# パスワードベースの認証 (AUTH) から IAM 認証への移行
このガイドでは、Amazon ElastiCache ノードベースのクラスターまたはサーバーレスキャッシュを、サービスを中断することなくパスワードベースの認証 (AUTH) から AWS Identity and Access Management (IAM) 認証に移行する方法について説明します。
**注記**
本番環境に変更を適用する前に、非本番環境でこの移行をテストすることをお勧めします。
## 概要
IAM 認証は、存続期間の長いパスワードを不要にすることで、セキュリティを強化します。代わりに、アプリケーションは[AWS 署名バージョン 4 の署名プロセス](https://docs.aws.amazon.com//general/latest/gr/signature-version-4.html)を使用して、有効期間の短い認証トークン (最大 15 分間有効) を生成します。
## 前提条件
開始する前に、以下の点を確認してください。
+ キャッシュで Redis OSS 7.0 以降、または Valkey が実行されています。IAM 認証は、以前のエンジンバージョンではサポートされていません。
+ 転送時の暗号化 (TLS) はキャッシュで有効になっています。IAM 認証には TLS が必要です。詳細については、「[ElastiCache の転送時の暗号化 (TLS)](in-transit-encryption.md)」を参照してください。
+ ユーザーを作成し、ユーザーグループを変更するために必要な IAM アクセス許可があります。詳細については、「[Amazon ElastiCache で IAM が機能する仕組み](security_iam_service-with-iam.md)」を参照してください。
+ アプリケーションが使用する IAM ロールまたはユーザーには、ターゲットキャッシュと IAM ユーザーの `elasticache:Connect`アクションを許可する IAM ポリシーがあります。詳細については、「[IAM を使用した認証](auth-iam.md)」を参照してください。
+ アプリケーションには追加の IAM 認証の制限は適用されません。制限の一覧については、「」を参照してください[IAM を使用した認証](auth-iam.md)。
## 移行プロセス
移行プロセスでは、パスワードベースのユーザーと IAM 認証ユーザーの両方を作成し、接続を検証してから、アプリケーションを IAM 認証に移行します。
### ステップ 1: ユーザーを作成する
移行期間中にキャッシュがパスワードベースの認証と IAM 認証の両方をサポートするように、2 人の ElastiCache ユーザーを作成します。
**パスワードベースの認証ユーザーを作成する**
**注記**
パスワードベースのユーザーがすでに設定されている場合は、新しいユーザーの作成をスキップして、既存のユーザーを使用できます。
パスワードベースのユーザーを作成するには、次の AWS CLI コマンドを使用します。
Linux、macOS、Unix の場合:
```
aws elasticache create-user \
--user-id {{}} \
--user-name default \
--engine {{}} \
--passwords "{{}}" \
--access-string "on ~* +@all"
```
Windows の場合:
```
aws elasticache create-user ^
--user-id {{}} ^
--user-name default ^
--engine {{}} ^
--passwords "{{}}" ^
--access-string "on ~* +@all"
```
置き換え前:
+ {{}} – このユーザーの一意の ID。
+ {{}} – キャッシュが使用するエンジン: `valkey`または `redis`。
+ {{}} – キャッシュで現在設定されている AUTH トークン。
**IAM 認証ユーザーを作成する**
次の AWS CLI コマンドを使用して、IAM 認証ユーザーを作成します。
Linux、macOS、Unix の場合:
```
aws elasticache create-user \
--user-id {{}} \
--user-name {{}} \
--authentication-mode Type=iam \
--engine {{}} \
--access-string "on ~* +@all"
```
Windows の場合:
```
aws elasticache create-user ^
--user-id {{}} ^
--user-name {{}} ^
--authentication-mode Type=iam ^
--engine {{}} ^
--access-string "on ~* +@all"
```
置き換え前:
+ {{}} – IAM ユーザーの一意の ID。
+ {{}} – IAM ユーザーのユーザー名。
+ {{}} – キャッシュが使用するエンジン: `valkey`または `redis`。
### ステップ 2: ユーザーグループを作成してアタッチする
パスワードベースのユーザーを含むユーザーグループが既にある場合は、その既存のグループに IAM 認証ユーザーを追加します。
Linux、macOS、Unix の場合:
```
aws elasticache modify-user-group \
--user-group-id {{}} \
--user-ids-to-add {{}}
```
Windows の場合:
```
aws elasticache modify-user-group ^
--user-group-id {{}} ^
--user-ids-to-add {{}}
```
置き換え前:
+ {{}} – 既存のユーザーグループの ID。
+ {{}} – ステップ 1 で作成した IAM 認証ユーザーのユーザー ID。
その後、[ステップ 3: 両方の認証方法を検証する](#auth-to-iam-verify-dual)に進みます。
それ以外の場合は、新しいユーザーグループを作成し、両方のユーザーを追加し、そのグループをキャッシュにアタッチします。
次の AWS CLI コマンドを使用して、両方のユーザーを持つユーザーグループを作成します。
Linux、macOS、Unix の場合:
```
aws elasticache create-user-group \
--user-group-id {{}} \
--engine {{}} \
--user-ids {{}} {{}}
```
Windows の場合:
```
aws elasticache create-user-group ^
--user-group-id {{}} ^
--engine {{}} ^
--user-ids {{}} {{}}
```
置き換え前:
+ {{}} – ユーザーグループの一意の ID。
+ {{}} – キャッシュが使用するエンジン: `valkey`または `redis`。
+ {{}}、{{}} – ステップ 1 で作成したユーザー IDs。
次に、新しいユーザーグループを使用するようにキャッシュを変更します。
ノードベースのクラスターの場合:
Linux、macOS、Unix の場合:
```
aws elasticache modify-replication-group \
--replication-group-id {{}} \
--auth-token-update-strategy DELETE \
--user-group-ids-to-add {{}}
```
Windows の場合:
```
aws elasticache modify-replication-group ^
--replication-group-id {{}} ^
--auth-token-update-strategy DELETE ^
--user-group-ids-to-add {{}}
```
置き換え前:
+ {{}} – レプリケーショングループの ID。
+ {{}} – 上記で作成したユーザーグループ ID。
サーバーレスキャッシュの場合:
Linux、macOS、Unix の場合:
```
aws elasticache modify-serverless-cache \
--serverless-cache-name {{}} \
--user-group-id {{}}
```
Windows の場合:
```
aws elasticache modify-serverless-cache ^
--serverless-cache-name {{}} ^
--user-group-id {{}}
```
置き換え前:
+ {{}} – サーバーレスキャッシュの名前。
+ {{}} – 上記で作成したユーザーグループ ID。
### ステップ 3: 両方の認証方法を検証する
ステップ 2 を完了すると、キャッシュは両方の認証方法をサポートします。続行する前に、アプリケーションが両方の方法を使用して接続できることを確認します。
+ パスワードベースの認証を使用するアプリケーションは、引き続きパスワードで接続できます。
+ IAM 認証用に設定されたアプリケーションは、IAM トークンを使用して接続できます。
### ステップ 4: IAM に接続する
**IAM 認証トークンを生成する**
[AWS SigV4 署名付きリクエスト](https://docs.aws.amazon.com//general/latest/gr/sigv4-signed-request-examples.html)を使用して、有効期間の短い IAM 認証トークンを生成します。次の Python の例は、トークンの生成を示しています。
```
import boto3
from botocore.auth import SigV4QueryAuth
from botocore.awsrequest import AWSRequest
cache_name = ""
user = ""
region = ""
expires = 900
session = boto3.Session()
credentials = session.get_credentials().get_frozen_credentials()
req = AWSRequest(
method="GET",
url=f"http://{cache_name}/",
params={"Action": "connect", "User": user}
)
SigV4QueryAuth(credentials, "elasticache", region, expires=expires).add_auth(req)
token = req.url.replace("http://", "")
print(token)
```
**注記**
生成されたトークンは、作成から最大 15 分間有効です。
**valkey-cli を使用して接続する**
生成されたトークンを使用して ElastiCache キャッシュに接続します。**valkey-cli** または を使用して Valkey クラスター**redis-cli**に接続できます。Redis OSS クラスターの場合は、 を使用します**redis-cli**。
```
valkey-cli -h {{}} -p 6379 --tls
```
クラスターモードが有効になっているクラスターの場合は、 `--cluster`フラグを追加します。
```
valkey-cli -h {{}} -p 6379 --tls --cluster
```
次に、次のコマンドで認証します。
```
AUTH {{}} {{}}
```
置き換え前:
+ {{}} – キャッシュのエンドポイント。
+ {{}} – IAM 認証ユーザーのユーザー名。
+ {{}} – 生成した IAM 認証トークン。
正常な出力:
```
OK
```
次のコマンドを実行してユーザー名を検証します。
```
ACL WHOAMI
```
### ステップ 5: アプリケーション統合
Java アプリケーションの場合は、デフォルトの AWS 認証情報プロバイダーチェーンを使用して一時的なセキュリティ認証情報を生成します。詳細については、「[IAM を使用した認証](auth-iam.md)」を参照してください。他の言語の場合は、[AWS 署名バージョン 4 の署名プロセス](https://docs.aws.amazon.com//general/latest/gr/signature-version-4.html)を使用して IAM 認証トークンを生成し、クライアントの `AUTH` コマンドでパスワードとして渡します。
## 移行の完了
アプリケーションが IAM 認証を使用して接続できるようになったら、次のステップを実行して移行を確定します。
### ステップ 1: フォールバックを使用して IAM 認証を設定する
パスワードベースのユーザーを削除する前に、プライマリメソッドとして IAM 認証を使用するようにアプリケーションコードを更新し、パスワードベースのユーザーをフォールバックとして保持します。
アプリケーションコードで、次の操作を行います。
+ IAM 生成トークンをプライマリメソッドとして使用して認証するようにクライアントを設定します。
+ IAM 認証が失敗した場合 (トークンの有効期限切れや生成エラーなど）、クライアントはパスワードベースの AUTH 認証情報を使用して再試行するようにフォールバックメカニズムを追加します。
+ フォールバックや再試行を含むすべての認証試行をログに記録し、接続がパスワードベースの認証にフォールバックしているかどうかをモニタリングできます。
### ステップ 2: のモニタリングと検証
アプリケーションログと `IamAuthenticationExpirations`および `IamAuthenticationThrottling` Amazon CloudWatch メトリクスを少なくとも 24～48 時間にわたって確認し、すべての接続が IAM 経由であることを確認します。
いずれかのメトリクスの値がゼロ以外の場合は、調査が必要です。
+ `IamAuthenticationExpirations` – IAM 認証接続は 12 時間後に自動的に切断されます。新しい IAM 認証トークンを使用して `AUTH`または `HELLO` コマンドを送信することで、接続を延長できます。
+ `IamAuthenticationThrottling` – 認証リクエストが多すぎることを示します。これは、アプリケーションがトークンを過度に積極的に生成しているか、接続プーリングの問題があることを意味します。
ノードベースのクラスターでは、追加のエンジンレベルのチェックを実行できます。
+ `ACL LOG` – 認証の試行が失敗したかどうかを確認します。でエントリを探します`reason=auth`。
+ `CLIENT LIST` – 接続されたユーザーを確認します。`user=` フィールドをチェックして、クライアントが IAM ユーザーを使用していることを確認します。
`ACL LOG` および `CLIENT LIST`はノードベースのクラスターでのみ使用できます。ElastiCache サーバーレスデプロイでは、アプリケーション側のログ記録と Amazon CloudWatch メトリクスに依存します。
### ステップ 3: パスワードベースのユーザーを削除する
すべてのアプリケーションが IAM 認証を使用していることを確認したら、ユーザーグループからパスワードベースのユーザーを削除します。
**Valkey キャッシュ**
パスワードベースのユーザーを直接削除します。
Linux、macOS、Unix の場合:
```
aws elasticache modify-user-group \
--user-group-id {{}} \
--user-ids-to-remove {{}}
```
Windows の場合:
```
aws elasticache modify-user-group ^
--user-group-id {{}} ^
--user-ids-to-remove {{}}
```
**Redis OSS キャッシュ**
Redis OSS キャッシュの場合、ユーザーグループには常にユーザー名 のユーザーが含まれている必要があります`default`。ステップ 1 で作成したパスワードベースのユーザーにユーザー名 がある場合は`default`、削除する前に、無効にしたプレースホルダーユーザーを作成して置き換える必要があります。
Linux、macOS、Unix の場合:
```
aws elasticache create-user \
--user-id {{}} \
--user-name default \
--engine redis \
--no-password-required \
--access-string "off ~* -@all"
```
Windows の場合:
```
aws elasticache create-user ^
--user-id {{}} ^
--user-name default ^
--engine redis ^
--no-password-required ^
--access-string "off ~* -@all"
```
次に、無効なユーザーをグループに追加し、パスワードベースのユーザーを削除します。
Linux、macOS、Unix の場合:
```
aws elasticache modify-user-group \
--user-group-id {{}} \
--user-ids-to-add {{}} \
--user-ids-to-remove {{}}
```
Windows の場合:
```
aws elasticache modify-user-group ^
--user-group-id {{}} ^
--user-ids-to-add {{}} ^
--user-ids-to-remove {{}}
```
ステップ 1 で作成したパスワードベースのユーザーにユーザー名 がない場合は`default`、上記の Valkey キャッシュと同じコマンドを使用して直接削除できます。
置き換え前:
+ {{}} – 無効になっているプレースホルダーユーザーの一意の ID (Redis OSS のみ）。
+ {{}} – キャッシュに関連付けられたユーザーグループの ID。
+ {{}} – 削除するパスワードベースのユーザーのユーザー ID。
**注記**
ユーザーグループから削除した後は、パスワードベースのユーザーを削除しないでください。パスワードベースの認証にロールバックする必要がある場合に備えて、使用できるようにしておきます。
### ステップ 4: 削除後の確認
ユーザーグループからパスワードベースのユーザーを削除したら、`AuthenticationFailures`Amazon CloudWatch メトリクスをモニタリングします。値 0 が持続すると、パスワードベースの試行の残りを含め、認証の失敗が発生しないことが確認されます。このメトリクスに CloudWatch アラームを設定して、予期しない試行を検出します。
ノードベースのクラスターでは、 `ACL LOG`と を使用して検証することもできます`CLIENT LIST`。サーバーレスキャッシュの場合は、アプリケーション側のログ記録と CloudWatch メトリクスに依存します。
## ロールバック手順
パスワードベースのユーザーをユーザーグループに再追加し、調査中にアプリケーションでパスワードベースの認証を復元します。
Valkey キャッシュの場合:
Linux、macOS、Unix の場合:
```
aws elasticache modify-user-group \
--user-group-id {{}} \
--user-ids-to-add {{}}
```
Windows の場合:
```
aws elasticache modify-user-group ^
--user-group-id {{}} ^
--user-ids-to-add {{}}
```
パスワードベースのユーザーがユーザー名 を持たない Redis OSS キャッシュの場合は`default`、上記と同じコマンドを使用します。
で無効化されたプレースホルダーユーザーを作成した Redis OSS キャッシュの場合[ステップ 3: パスワードベースのユーザーを削除する](#auth-to-iam-remove-user)、パスワードベースのユーザーを追加し、無効化されたプレースホルダーユーザーを 1 回のオペレーションで削除します。
Linux、macOS、Unix の場合:
```
aws elasticache modify-user-group \
--user-group-id {{}} \
--user-ids-to-add {{}} \
--user-ids-to-remove {{}}
```
Windows の場合:
```
aws elasticache modify-user-group ^
--user-group-id {{}} ^
--user-ids-to-add {{}} ^
--user-ids-to-remove {{}}
```
置き換え前:
+ {{}} – キャッシュに関連付けられたユーザーグループの ID。
+ {{}} – 再追加するパスワードベースのユーザーのユーザー ID。
+ {{}} – 無効になっているプレースホルダーユーザーのユーザー ID (Redis OSS のみ）。