AWS Secrets Manager の概念 - AWS Secrets Manager

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

AWS Secrets Manager の概念

以下の概念は、Secrets Manager の仕組みを理解するうえで重要です。

シークレット

Secrets Manager では、シークレットは、シークレット情報、シークレット値、およびシークレットに関するメタデータで構成されます。シークレット値には、文字列またはバイナリを使用できます。複数の文字列値をシークレットに保存するには、キーと値のペアを使用した JSON テキスト文字列を使用することをお勧めします。次に例を示します。

{ "host" : "ProdServer-01.databases.example.com", "port" : "8888", "username" : "administrator", "password" : "EXAMPLE-PASSWORD", "dbname" : "MyDatabase", "engine" : "mysql" }

シークレットのメタデータには以下が含まれます。

  • 次の形式の Amazon リソースネーム (ARN)

    arn:aws:secretsmanager:<Region>:<AccountId>:secret:SecretName-6RandomCharacters

    Secrets Manager は、シークレット ARN が確実に一意であるようにするのに役立つよう、シークレット名の末尾に 6 つのランダムな文字を含めます。元のシークレットが削除され、同じ名前で新しいシークレットが作成された場合、これらの文字により 2 つのシークレット ARN は異なったものとなります。ARN が異なるため、古いシークレットにアクセスできるユーザーであっても、新しいシークレットへのアクセスを自動的に取得するわけではありません。

  • シークレットの名前、説明、リソースポリシー、タグ

  • Secrets Manager がシークレット値を暗号化したり復号したりするために使用する AWS KMS key である暗号化キーの ARN Secrets Manager はシークレットテキストを常に暗号化された形式で保存し、転送中のシークレットを暗号化します。AWS Secrets Manager のシークレット暗号化と復号 を参照してください。

  • シークレットをローテーションする方法に関する情報 (ローテーションを設定した場合) [Rotation] (ローテーション) を参照してください。

Secrets Manager は、IAM アクセス許可ポリシーを使用して、認証されたユーザーのみがシークレットにアクセスまたは変更できるようにします。AWS Secrets Manager の認証とアクセスコントロール を参照してください。

シークレットには、暗号化されたシークレット値のコピーを保持している複数のバージョンがあります。シークレットの値を変更するか、シークレットをローテーションすると、Secrets Manager は新しいバージョンを作成します。バージョン を参照してください。

シークレットをレプリケートすることによって、シークレットを複数の AWS リージョン で使用できます。シークレットをレプリケートする場合、元のシークレットをコピーするか、レプリカシークレットと呼ばれるプライマリシークレットを作成します。レプリカシークレットは、プライマリシークレットにリンクされたままになっています。「AWS Secrets Manager シークレットを他の AWS リージョンにレプリケートする」を参照してください

AWS Secrets Manager でのシークレットの作成と管理」を参照してください

バージョン

シークレットには、暗号化されたシークレット値のコピーを保持している複数のバージョンがあります。シークレットの値を変更するか、シークレットをローテーションすると、Secrets Manager は新しいバージョンを作成します。

Secrets Manager は、シークレットの履歴をバージョン順には保存しません。代わりに、以下の 3 つの特定のバージョンにラベルを付け、それらを追跡します。

  • 現在のバージョン – AWSCURRENT

  • 以前のバージョン – AWSPREVIOUS

  • 保留中のバージョン (ローテーション中) – AWSPENDING

シークレットには常に、AWSCURRENT というラベルが付いたバージョンがあり、シークレット値を取得する際は、そのバージョンがデフォルトで Secrets Manager から返されます。

また、AWS CLI の update-secret-version-stage を呼び出し、バージョンに独自のラベルを付けることもできます。シークレットには、最大 20 個のラベルをアタッチできます。シークレットの 2 つのバージョンで同じステージングラベルを持つことはできません。各バージョンには、複数のラベル付けることが可能です。

ラベル付きのバージョンであれば、Secrets Manager により削除されることはありませんが、ラベルのないバージョンは非推奨と見なされます。非推奨のバージョンの数が 100 を超えた場合、Secrets Manager はそれらを削除します。ただし、Secrets Manager は 24 時間以内に作成されたバージョンは削除しません。

次の図に、AWS のラベルとカスタマーのラベルが付けられたバージョンを持つシークレットを示します。ラベルのないバージョンは非推奨と見なされ、将来のある時点で Secrets Manager によって削除されます。

[Rotation] (ローテーション)

ローテーションとは、定期的にシークレット情報を更新して、攻撃者が認証情報にアクセスするのをより困難にするプロセスです。Secrets Manager では、シークレットの自動ローテーションを設定できます。Secrets Manager がシークレットをローテーションすると、シークレットおよびデータベースまたはサービスの認証情報が更新されます。「AWS Secrets Managerシークレットのローテーション」を参照してください。

ヒント

他のサービスによって管理されるシークレット の場合、マネージドローテーションを使用します。マネージドローテーション を使用するには、最初に管理サービスを通じてシークレットを作成します。

ローテーション戦略

Secrets Manager には、次の 2 つのローテーション戦略が用意されています。

ローテーション戦略: シングルユーザー

この戦略は、1 つのシークレット内で 1 人のユーザーの認証情報を更新します。Amazon RDS Db2 インスタンスの場合、ユーザーは自分のパスワードを変更できないため、管理者の認証情報を別のシークレットで提供する必要があります。これは最も簡単なローテーション戦略であり、ほとんどのユースケースに使用することができます。特に、1 回限りの (アドホック) ユーザーまたはインタラクティブユーザーの認証情報には、この方法を使用することを推奨します。

シークレットがローテーションしても、開いているデータベース接続は切断されません。ローテーションの実行中、データベース内のパスワードが変更されてからシークレットが更新されるまでには少し時間がかかります。その間に、ローテーションされた認証情報を使用する呼び出しがデータベースによって拒否されるリスクは低く抑えられています。このリスクは、適切な再試行戦略を適用することで低減することが可能です。ローテーション後、新しい接続は新しい認証情報を使用します。

ローテーション戦略: 交代ユーザー

この戦略は、1 つのシークレット内で 2 人のユーザーの認証情報を更新します。最初のユーザーを作成し、その最初のローテーション中に、ローテーション関数がユーザーのクローンを作成して 2 人目のユーザーを作成します。シークレットがローテーションされるたびに、ローテーション関数はパスワードを更新するユーザーを切り替えます。ほとんどのユーザーにはクローン作成権限がないため、superuser の認証情報を別のシークレット内で用意する必要があります。データベース内のクローンユーザーがオリジナルユーザーと同じ権限を持っていない場合や、1 回限り (アドホック) またはインタラクティブなユーザーの認証情報には、シングルユーザーローテーション方法を使用することを推奨します。

この戦略は、1 つ目のロールがデータベーステーブルを所有し、2 つ目のロールにそのデータベーステーブルへのアクセス許可を付与するといった権限モデルのデータベースに適しています。また、高可用性を必要とするアプリケーションにも適しています。アプリケーションは、ローテーション中にシークレットを取得しても、引き続き有効な認証情報セットを取得します。ローテーション後、useruser_clone の両方の認証情報が有効になります。このタイプのローテーション中にアプリケーションが拒否される可能性は、シングルユーザーのローテーションを比較すると一段と低くなります。データベースをホストしているサーバーファームでパスワードの変更がサーバー全体に伝播するまでに時間がかかる場合には、新しい認証情報を使用する呼び出しがデータベースによって拒否されるおそれがあります。このリスクは、適切な再試行戦略を適用することで低減することが可能です。

Secrets Manager は、元のユーザーと同じアクセス許可を持つクローンユーザーを作成します。クローンユーザーが作成された後に元のユーザーの権限を変更する場合は、クローンユーザー側の権限も変更する必要があります。

例えば、データベースユーザーの認証情報を使用してシークレットを作成した場合、そのシークレットには、使用した認証情報によるバージョンが 1 つ含まれます。

1 回目のローテーション – ローテーション関数がパスワードを生成し、それを使用してユーザーのクローンを作成します。それらの認証情報は、現在のシークレットバージョンになります。

2 回目のローテーション – ローテーション関数は、元のユーザーのパスワードを更新します。

3 回目のローテーション – ローテーション関数は、クローンされたユーザーのパスワードを更新します。