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 がシークレット値を暗号化したり復号したりするために使用する 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 でのシークレットの作成と管理」を参照してください。
[Rotation] (ローテーション)
ローテーションとは、定期的にシークレット情報を更新して、攻撃者が認証情報にアクセスするのをより困難にするプロセスです。Secrets Manager では、シークレットの自動ローテーションを設定できます。Secrets Manager がシークレットをローテーションすると、シークレットおよびデータベースまたはサービスの認証情報が更新されます。「AWS Secrets Managerシークレットのローテーション」を参照してください。
ヒント
他のサービスによって管理されるシークレット の場合、マネージドローテーションを使用します。マネージドローテーション を使用するには、最初に管理サービスを通じてシークレットを作成します。
ローテーション戦略
ローテーション戦略: シングルユーザー
この戦略は、1 つのシークレット内で 1 人のユーザーの認証情報を更新します。ユーザーには、自身のパスワードを更新する権限が必要です。これは最も簡単なローテーション戦略であり、ほとんどのユースケースに使用することができます。特に、1 回限りの (アドホック) ユーザーまたはインタラクティブユーザーの認証情報には、この方法を使用することを推奨します。
シークレットがローテーションしても、開いているデータベース接続は切断されません。ローテーションの実行中、データベース内のパスワードが変更されてからシークレットが更新されるまでには少し時間がかかります。その間に、ローテーションされた認証情報を使用する呼び出しがデータベースによって拒否されるリスクは低く抑えられています。このリスクは、適切な再試行戦略
ローテーション戦略: 交代ユーザー
この戦略は、1 つのシークレット内で 2 人のユーザーの認証情報を更新します。最初のユーザーを作成し、その最初のローテーション中に、ローテーション関数がユーザーのクローンを作成して 2 人目のユーザーを作成します。シークレットがローテーションされるたびに、ローテーション関数はパスワードを更新するユーザーを切り替えます。ほとんどのユーザーにはクローン作成権限がないため、superuser
の認証情報を別のシークレット内で用意する必要があります。データベース内のクローンユーザーがオリジナルユーザーと同じ権限を持っていない場合や、1 回限り (アドホック) またはインタラクティブなユーザーの認証情報には、シングルユーザーローテーション方法を使用することを推奨します。
この戦略は、1 つ目のロールがデータベーステーブルを所有し、2 つ目のロールにそのデータベーステーブルへのアクセス許可を付与するといった権限モデルのデータベースに適しています。また、高可用性を必要とするアプリケーションにも適しています。アプリケーションは、ローテーション中にシークレットを取得しても、引き続き有効な認証情報セットを取得します。ローテーション後、user
と user_clone
の両方の認証情報が有効になります。このタイプのローテーション中にアプリケーションが拒否される可能性は、シングルユーザーのローテーション比較すると一段と低くなります。データベースをホストしているサーバーファームでパスワードの変更がサーバー全体に伝播するまでに時間がかかる場合には、新しい認証情報を使用する呼び出しがデータベースによって拒否されるおそれがあります。このリスクは、適切な再試行戦略
バージョン
シークレットには、暗号化されたシークレット値のコピーを保持している複数のバージョンがあります。シークレットの値を変更するか、シークレットをローテーションすると、Secrets Manager は新しいバージョンを作成します。
Secrets Manager はシークレットの履歴をバージョンと一緒に保存しません。代わりに、そのシークレットバージョンを AWSPREVIOUS
とラベリングすることで、以前のシークレット値を追跡します。ローテーション中、Secrets Manager は、そのシークレットバージョンを AWSPENDING
とラベリングすることで、次のシークレット値も追跡します。シークレットは、かならず AWSCURRENT
バージョンを持っています。AWSCURRENT
バージョンは、別のバージョンを指定しない限り、シークレット値を取得したときに Secrets Manager が返すものです。
AWS CLI または AWS SDK で UpdateSecretVersionStage
を使用して、独自のラベルを持つ他のバージョンを追加できます。シークレットには、最大 20 のステージングラベルをアタッチできます。シークレットの 2 つのバージョンで同じステージングラベルを持つことはできません。あるバージョンにラベルが付いていない場合、Secrets Manager はそれを非推奨と見なします。Secrets Manager は、100 を超える場合は、非推奨のシークレットバージョンを削除します。ただし、Secrets Manager は 24 時間以内に作成されたバージョンは削除せず、またラベルがあるバージョンも削除しません。