既存の 2 人のユーザーを切り替えることで AWS Secrets Manager シークレットを更新する - AWS Secrets Manager

英語の翻訳が提供されている場合で、内容が矛盾する場合には、英語版がオリジナルとして取り扱われます。翻訳は機械翻訳により提供されています。

既存の 2 人のユーザーを切り替えることで AWS Secrets Manager シークレットを更新する

保護されたリソースのシークレットを自動的に更新するように、AWS Secrets Manager を構成できます。

このトピックでは、必要なときにパスワードを変更できる 2 人のユーザーを作成して、切り替えることができるシステムのローテーションの設定について説明します。これにより、1 つのユーザーアカウントに限定されているシナリオで発生するダウンタイムの可能性を排除できます。この場合は、シークレットのバージョンのパスワード以外も変更します。各バージョンでは、ユーザーの変更をキャプチャする必要があります。各ローテーションサイクルで各ユーザーを交互に切り替える必要があります。

管理者が最初の 2 人のユーザーのパスワードを変更する昇格された権限を持つ第 3 の「マスター」ユーザーを作成できる場合は、そのようにすることをお勧めします。これは、ユーザーに自分自身のパスワードを変更するアクセス許可を付与するより安全です。この方法でシナリオを設定する場合、最初のシークレットで切り替えられたユーザーのパスワードを変更するために使用される第 2 のシークレットを作成する必要があります。最初に「マスター」シークレットを作成し、「ユーザー」シークレットを設定するときに参照用に使用できるようにします。

Secrets Manager は、現在の認証情報を無効にしても、すぐには削除しない次のシナリオを実装するためのテンプレートを提供します。その代わりに、Secrets Manager により、現在の認証情報を含むバージョンのシークレットがステージングラベル AWSPREVIOUS でマークされます。これにより、「最後の既知の正常な」認証情報として、これらの認証情報が 1 つの追加のローテーションサイクルとして保持されます。Secrets Manager では、現在の認証情報に何らかの問題が生じた場合に、復旧のためにこれらの認証方法を利用できるようにします。

Secrets Manager は、このトピックで後で説明するように、ユーザーがアクティブなサービスに戻ったとき、2 番目のローテーションサイクルの後でのみ、認証情報を削除します。つまり、指定した日数のみ特定の認証情報のセットを有効にする場合は、ローテーション期間をその半分から 1 を引いた期間に設定することをお勧めします。これにより、2 つのローテーションサイクルは両方とも完了し、指定された期間内に認証情報が完全に廃止されます。

たとえば、コンプライアンスで義務付けられた認証情報の最大有効期間が 90 日である場合は、ローテーション間隔を 44 日 (90/2 - 1 = 44) に設定することをお勧めします。0 日目に、Secrets Manager によって新しい認証情報がローテーションで作成され、AWSCURRENT というラベルが付けられます。44 日目に、次のローテーションにより、それらの認証情報を持つシークレットが AWSPREVIOUS に降格し、クライアントはそれらのアクティブな使用を停止します。88 日目に、次のローテーションにより、すべてのステージングラベルがバージョンから削除されます。Secrets Manager は、この時点でバージョンを完全に非推奨にし、データベースのユーザーを新しいパスワードでリサイクルします。これにより、サイクルが再開されます。

ローテーションでラベルを使用して 2 人のユーザー間で切り替える方法

ステージングラベルを使用すると、Secrets Manager は 2 人のユーザー間で前後に切り替えることができます。AWSCURRENT というラベルが付けられたユーザーは、クライアントによって積極的に使用されます。Lambda 関数のローテーションがトリガーされると、ローテーションプロセスはアクティブでない第 2 のユーザーに新しいパスワードを割り当てます。Secrets Manager は、それらの認証情報を新しいバージョンのシークレットに保存します。新しいシークレットバージョンの認証情報でのアクセスが機能していることを確認した後、ローテーションプロセスは AWSCURRENT ラベルを新しいバージョンに移動し、それをアクティブバージョンにします。次回にトリガーされると、Secrets Manager のロールによって 2 つのユーザーアカウントが逆になります。

基本的なシナリオの例

以下で、このシナリオについて詳しく説明します。

  1. このシナリオは、単一のバージョン「A」を持つシークレットを使用してデータベースにアクセスするアプリケーションから始まります。このシークレットのバージョンには、AWSCURRENT というラベルがアタッチされており、2 人のユーザーのうち最初のユーザーの認証情報が含まれています。アプリケーションは、AWSCURRENT というラベルの付いたバージョンを要求してシークレットを取得します (次の図のステップ 1 と 2)。次に、そのバージョンのシークレットの認証情報を使用してデータベースにアクセスし (ステップ 3)、必要なデータを取得します (ステップ 4)。

  2. 最初のローテーション中に、プロセスは、新しいバージョン「B」バージョンのシークレットを作成します (新しいシークレットではなく、同じシークレットの新しいバージョン)。プロセスは A バージョンのすべての詳細のクローンを作成しますが、ユーザー名を第 2 のユーザーに切り替えて新しいパスワードを生成する点が異なります。次に、ローテーションプロセスは、この新しいパスワードで第 2 のユーザーを更新します。このシークレットのバージョン B は、ローテーションプロセスでアタッチされたラベル AWSPENDING を最初に持っています。常に AWSCURRENT ラベルを要求するようカスタムアプリをプログラムしており、そのラベルは変更されていないため、アプリケーションは引き続き元の A バージョンのシークレットの認証情報を取得して使用し続け、データベースにアクセスします。

  3. バージョン B シークレットが動作することをテストした後、ローテーションプロセスはバージョン A から AWSCURRENT ラベルを移動して、そのラベルを新しいバージョン B のシークレットにアタッチします。また、AWSPREVIOUS ステージングラベルを AWSCURRENT ステージングラベルの以前のバージョンに自動的に移動します。これは、復元が必要になった場合に、「最後の正常な設定」として使用されます。このシークレットの AWSPREVIOUS バージョンも、追加のローテーションサイクルとして復旧のために引き続き使用できます。Secrets Manager は、次のサイクルでシークレットを非推奨にします。

  4. カスタムアプリからの次のリクエストでは、B に AWSCURRENT というラベルがあるため、バージョン B のシークレットが取得されます。カスタムアプリケーションは、第 2 のユーザーで新しいパスワードを使用してデータベースにアクセスします。

2 人のユーザー間のローテーションを設定する

サポートされている Amazon RDS データベースのいずれにシークレットを使用する場合は、Amazon RDS データベースシークレットのローテーションを有効にする の手順に従ってください。

その代わりに別のサービスまたはデータベースのローテーションを設定する場合は、Lambda ローテーション関数を作成し、以下の手順を使用してその関数をカスタマイズします。

  1. データベースまたはサービスで 2 人のユーザーを作成します。使用するユーザー名とパスワードをメモしておきます。各ユーザーに、各自のパスワードを変更する権限があることを確認します。

  2. 最初のユーザーの認証情報が含まれているシークレットを作成します。

他のデータベースやサービスのローテーションと AWS Secrets Manager のシークレット」のステップに従って、カスタマイズできる汎用的な Lambda ローテーション関数テンプレートを作成します。ステップ 7 に到達したら、ここに示されている情報を使用して関数をカスタマイズします。

ローテーション関数を記述するための基礎として、次のロジックを使用します。

  • createSecret フェーズ:

    • GetSecretValue オペレーションを使用して、シークレットの AWSCURRENT バージョンを取得します。

    • SecretString フィールドから保護されたシークレットテキストを抽出し、構造体に保存して使用することができます。

    • username フィールドを調べて、代替ユーザー名を決定します。

    • 代替ユーザー名を持つユーザーがデータベースに存在するかどうかを確認します。存在しない場合、初回のローテーションプロセスであるはずです。現在のユーザーとアクセス許可をクローンします。

    • シークレット構造のコピーの username エントリを別のユーザー名に設定します。

    • 保護されたリソースでサポートされている最大の長さと複雑さの要件を持つ新しいパスワードを生成します。

    • シークレット構造のコピーの password エントリを新しいパスワードに設定します。

    • シークレット構造の修正されたコピーをシークレットに保存するには、PutSecretValue への呼び出しで SecretString パラメータとして渡します。Secrets Manager は、シークレットの新しいバージョンに AWSPENDING としてラベルを付けます。

  • setSecret フェーズ:

    • GetSecretValue オペレーションを使用して、シークレットの AWSPENDING バージョンを取得します。

    • SecretString フィールドから、ユーザー名とパスワードを抽出します。

    • 保護されたリソース認証システムにコマンドを発行して、指定されたユーザーパスワードをその値に変更します。

  • testSecret フェーズ:

    • GetSecretValue オペレーションを使用して、シークレットの AWSPENDING バージョンを取得します。

    • シークレットの認証情報を使用して、保護されたリソースへの接続を試みます。

  • finishSecret フェーズ:

    • ラベル AWSCURRENTAWSPENDING というラベルの付いたバージョンに移動します。

    • (オプション) AWSPENDING というラベルをそのバージョンのシークレットから削除します。

注記

このシナリオでは、シークレットのローテーション中にユーザーにエラーが発生する可能性は低くなります。新しいバージョンを設定している間、古いバージョンは引き続き使用されます。Secrets Manager で新しいバージョンがテストされた後にのみ、ラベルを新しいバージョンを指すように切り替えると、クライアントはそれを使用し始めます。ただし、一部のサーバーはパスワードの変更時に伝播遅延のあるサーバーファームに配置されているため、パスワードがすべてのサーバーに伝播されるまでの時間があることを確認するために、合理的な遅延 (テスト前に setSecret ステップにある可能性が高い) を必ず含める必要があります。また、このリスクを軽減するために、クライアントアプリケーションに合理的な再試行機能を組み込んでください。