aws secrets manager - ユーザーガイド...secrets manager...

AWS Secrets Managerユーザーガイド

AWS Secrets Manager ユーザーガイド

AWS Secrets Manager: ユーザーガイドCopyright © 2020 Amazon Web Services, Inc. and/or its affiliates. All rights reserved.

Amazon's trademarks and trade dress may not be used in connection with any product or service that is not Amazon's,in any manner that is likely to cause confusion among customers, or in any manner that disparages or discreditsAmazon. All other trademarks not owned by Amazon are the property of their respective owners, who may or may notbe affiliated with, connected to, or sponsored by Amazon.


Table of ContentsAWS Secrets Manager とは ................................................................................................................. 1

Secrets Manager の使用開始 ........................................................................................................ 1Secrets Manager の基本シナリオ .................................................................................................. 1Secrets Manager の機能 .............................................................................................................. 2

実行時のプログラムによる暗号化されたシークレットの値の取得 ............................................... 2さまざまな種類のシークレットの保存 .................................................................................... 3シークレットデータの暗号化 ................................................................................................ 3シークレットを自動的に更新する .......................................................................................... 3シークレットへのアクセスの制御 .......................................................................................... 5

標準への準拠 ............................................................................................................................. 5Secrets Manager へのアクセス ..................................................................................................... 6Secrets Manager の料金表 ........................................................................................................... 6

AWS KMS– 顧客の暗号化キー .............................................................................................. 7AWS CloudTrailログ記録– ストレージと通知 .......................................................................... 7

AWS Secrets Manager のサポートとフィードバック ....................................................................... 7開始方法 ............................................................................................................................................ 8

用語と概念 ................................................................................................................................ 8シークレット ..................................................................................................................... 8保護されたサービス .......................................................................................................... 10Rotation ........................................................................................................................... 10ステージングラベル .......................................................................................................... 11バージョニング ................................................................................................................. 11

チュートリアル ......................................................................................................................... 12チュートリアル: シークレットの作成と取得 .......................................................................... 12チュートリアル: AWS データベースのシークレットのローテーション ...................................... 15チュートリアル: マスターシークレットでユーザーのシークレットをローテーションする ............. 23

ベストプラクティス .......................................................................................................................... 29その他の機密情報の保護 ............................................................................................................ 29AWS 提供のクライアント側キャッシュコンポーネントを使用したパフォーマンス強化 ........................ 29Lambda 関数のログ記録とデバッグのリスクの軽減 ........................................................................ 30AWS CLI を使用してシークレットを保存するリスクの軽減 ............................................................. 30クロスアカウントアクセス – ユーザー/ロールまたはアカウントを指定する必要がありますか｡ .............. 31VPC ですべてを実行する ........................................................................................................... 32シークレットにタグ付けする ...................................................................................................... 33

AWS Secrets Manager に対する認証とアクセスコントロール ................................................................. 34.............................................................................................................................................. 34

概要 ........................................................................................................................................ 34認証 ................................................................................................................................ 35アクセスコントロール (認証) .............................................................................................. 36

Secrets Manager でアイデンティティベースのポリシー (IAM ポリシー) を使用する ............................ 43AWSSecrets Manager の管理ポリシー ................................................................................. 44完全なシークレットマネージャー管理者アクセス権限をユーザーに付与する .............................. 441 つのシークレットへの読み取りアクセスの付与 ................................................................... 45特定のアクションへのアクセスの制限 .................................................................................. 45特定のシークレットへのアクセスの制限 ............................................................................... 45特定のステージングラベルまたはタグを持つシークレットへのアクセスを制限する ..................... 47別のマスターシークレットへのアクセス権限をローテーション関数に付与する ........................... 48

Secrets Manager のリソースベースのポリシーを使用する .............................................................. 49プリンシパルのシークレットへのアクセスの制御 ................................................................... 49ロールへの読み取り専用アクセスの付与 ............................................................................... 50

シークレットへのアクセスを判断する .......................................................................................... 51ポリシーの評価について .................................................................................................... 51リソースポリシーの確認 .................................................................................................... 52IAM ポリシーの確認 .......................................................................................................... 53

iii


シークレットの作成と管理 ................................................................................................................. 55基本的なシークレットを作成する ................................................................................................ 55シークレットの変更 .................................................................................................................. 59シークレット値の取得 ............................................................................................................... 64

AWS が開発したオープンソースのクライアント側キャッシングコンポーネントの使用 ................ 65シークレットの削除と復元 ......................................................................................................... 66シークレットのリソースベースのポリシーを管理する .................................................................... 70

リソースベースのポリシーをシークレットにアタッチする ...................................................... 71リソースベースのポリシーをシークレットから取得する ......................................................... 71リソースベースのポリシーをシークレットから削除する ......................................................... 72

シークレットの更新 .......................................................................................................................... 74シークレットを自動的に更新するために必要なアクセス許可 ........................................................... 74

ローテーションを設定するユーザーとローテーションをトリガーするユーザーのアクセス許可 ..... 74Lambda ローテーション関数に関連付けられたアクセス許可 ................................................... 75

シークレットの更新をサポートするネットワークの設定 ................................................................. 77Amazon RDS シークレットの更新 .............................................................................................. 78

Amazon RDS データベースシークレットのローテーションを有効にする ................................... 80Secrets Manager が提供する Lambda ローテーション関数のカスタマイズ ................................ 86

Amazon Redshift シークレットのローテーション ........................................................................... 87Amazon Redshift シークレットのローテーションを有効にする ................................................ 89

Amazon DocumentDB シークレットのローテーション .................................................................... 95Amazon DocumentDB シークレットのローテーションを有効にする ......................................... 96

他のシークレットの更新 ........................................................................................................... 103他のシークレットの更新 ................................................................................................... 103別のデータベースまたはサービスのシークレットのローテーションを有効にする ...................... 106

Lambda ローテーション関数の理解とカスタマイズ ...................................................................... 108Lambda ローテーション関数の概要 ................................................................................... 109シークレットの更新 - シングルユーザー､1 つのパスワード ................................................... 112シークレットの更新 - 既存のユーザーを切り替える .............................................................. 116シークレットの更新 - パスワードのみ ................................................................................ 119

ローテーション関数の削除 ........................................................................................................ 122VPC エンドポイントで Secrets Manager を使用する ........................................................................... 126

VPC エンドポイントを介した Secrets Manager への接続 ............................................................. 126Secrets Manager VPC プライベートエンドポイントの作成 ........................................................... 127Secrets Manager VPC プライベートエンドポイントへの接続 ........................................................ 129ポリシーステートメントでの VPC プライベートエンドポイントの使用 ........................................... 130Secrets Manager VPC エンドポイントのエンドポイントポリシーを作成する ................................... 132Secrets Manager VPC エンドポイントの使用の監査 ..................................................................... 133

シークレットを監視する ................................................................................................................... 134AWS CloudTrail を使用した AWS Secrets Manager API コールのログ作成 ...................................... 134

CloudTrail 内の Secrets Manager 情報 ............................................................................... 134Secrets Manager ログファイルエントリの取得 .................................................................... 135Secrets Manager ログファイルエントリの概要 .................................................................... 136

Amazon CloudWatch Events ..................................................................................................... 137削除予定のシークレットバージョンの監視 .......................................................................... 137

他のサービスでの使用 ...................................................................................................................... 140AWS CloudFormation でシークレットの作成を自動化する ............................................................ 140AWS Identity and Access Management (IAM) を使用したシークレットの保護 ................................... 140AWS CloudTrail と Amazon CloudWatch を使用してシークレットをモニタリングする ....................... 141AWS KMS を使用したシークレットの暗号化 ............................................................................... 141パラメータストア API を使用してシークレットを取得する ............................................................ 141AWS CloudFormation のシークレット作成を自動化する ................................................................ 142

例 ................................................................................................................................. 142AWS Secrets Manager でのセキュリティ ........................................................................................... 149

AWS Secrets Manager でのデータ保護 ...................................................................................... 149保管時の暗号化 ............................................................................................................... 149転送中の暗号化 ............................................................................................................... 150

iv


暗号化キーの管理 ............................................................................................................ 150ネットワーク内のトラフィックプライバシー ....................................................................... 150

インフラストラクチャセキュリティ ........................................................................................... 150弾力 ...................................................................................................................................... 151コンプライアンス検証 .............................................................................................................. 151

AWS Secrets Managerリファレンス .................................................................................................. 152AWS Secrets Manager のクォータ ............................................................................................ 152

名前の制限 ..................................................................................................................... 152最大クォータ .................................................................................................................. 152レートクォータ ............................................................................................................... 153

ローテーション関数のテンプレート ........................................................................................... 153Amazon RDS データベースのテンプレート ......................................................................... 154他のデータベースのテンプレート ...................................................................................... 159他のサービスのテンプレート ............................................................................................. 161

管理ポリシー .......................................................................................................................... 161アクション、リソース、およびコンテキストキー ......................................................................... 162

アクション ..................................................................................................................... 162リソース ........................................................................................................................ 165コンテキストキー ............................................................................................................ 165

AWS Secrets Manager のトラブルシューティング ............................................................................... 169一般的な問題のトラブルシューティング ..................................................................................... 169

AWS Secrets Manager にリクエストを送信すると、「アクセスが拒否されました」というメッセージが表示される。 ...................................................................................................... 169一時的なセキュリティ認証情報を使用してリクエストを送信すると「アクセスが拒否されました」というメッセージが表示される。 ................................................................................ 169変更がすぐに表示されない。 ............................................................................................. 170シークレットを作成するときに「非対称 CMK でデータキーを生成できません」というメッセージが表示される。 ............................................................................................................ 170

ローテーションのトラブルシューティング .................................................................................. 170Lambda ローテーション関数の診断ログを確認する方法 ........................................................ 171ローテーションが開始される時を予測できません ................................................................. 171シークレットのローテーションを設定しようとすると「アクセス拒否」が発生する ................... 171ローテーションを有効にすると最初のローテーションに失敗する ........................................... 172シークレット値はローテーション関数が予期する形式ではないため、ローテーションが失敗します。 .............................................................................................................................. 172Secrets Manager は、ローテーションを正常に設定したが、パスワードはローテーションしていない .............................................................................................................................. 173ローテーションがエラーメッセージ「内部エラー」で失敗する ............................................... 173CloudTrail がローテーション中にアクセス拒否エラーを表示する ............................................ 173

HTTP クエリリクエストを行う ......................................................................................................... 175エンドポイント ....................................................................................................................... 175HTTPS の必要性 ..................................................................................................................... 175Secrets Manager の API リクエストへの署名 .............................................................................. 176

ドキュメント履歴 ............................................................................................................................ 177AWS の用語集 ................................................................................................................................ 179

v

AWS Secrets Manager ユーザーガイドSecrets Manager の使用開始

AWS Secrets Manager とはAWS は、シークレットの管理を容易にするために AWS Secrets Manager サービスを提供します。シークレットとは、データベース認証情報、パスワード、サードパーティーの API キーなどの任意のテキストです。Secrets Manager コンソール、Secrets Manager コマンドラインインターフェイス (CLI)、SecretsManager API および SDK を使用すると、これらのシークレットへのアクセスを一元的に保存および制御できます。

以前は、データベースから情報を取得するカスタムアプリケーションを作成したとき、通常、アプリケーション内でデータベースに直接アクセスするための認証情報（シークレット）を埋め込んでいました。認証情報を更新するときには、単に新しい認証情報を作成する以上のことが必要でした。新しい認証情報を使用するために､アプリケーションを更新する時間を費やさなければなりませんでした。次に、更新されたアプリケーションを配布しました。認証情報を共有している複数のアプリケーションがあり、そのうちの1 つを更新しなかった場合、アプリケーションは失敗しました。このリスクのために、多くのお客様は定期的に認証情報を更新せずに、実際のところは代わりに別のリスクを選択していました。

代わりに、Secrets Manager を使用すると、コード内のハードコードされた認証情報 (パスワードを含む)を Secrets Manager への API コールで置き換えて、プログラムでシークレットを取得することができます。これは、シークレットがコード内に存在しなくなったため、コードを調べる人によってシークレットが侵害されないようにするのに役立ちます。また、Secrets Manager を設定して、指定したスケジュールに従って自動的にシークレットを更新するようにできます。これにより、長期のシークレットを短期のシークレットに置き換えることが可能となり、侵害されるリスクを大幅に減少させるのに役立ちます｡

Secrets Manager の使用開始Secrets Manager を十分に活用するために理解しておく必要のある用語や概念のリストについては、「AWS Secrets Manager の主な用語と概念 (p. 8)」を参照してください。

Secrets Manager の一般的なユーザーは、次のロールの 1 つ以上を持つことができます。

• Secrets Manager 管理者 – Secrets Manager サービスを管理します。ここにリストされている他のロールを実行できる個人にアクセス権限を付与します。

• データベースまたはサービス管理者 – シークレットが Secrets Manager に保存されているデータベースまたはサービスを管理します。シークレットのローテーションと有効期限の設定を決定して､設定します。

• アプリケーション開発者 – アプリケーションを作成し、Secrets Manager から適切な認証情報を要求するようにアプリケーションを設定します。

Secrets Manager の基本シナリオこの最も基本的なシナリオを以下に図で示します。この図は、Secrets Manager のデータベースの認証情報を保存する方法を示して、データベースへのアクセスのためのこれらの認証情報をアプリケーションで使用します。

1

AWS Secrets Manager ユーザーガイドSecrets Manager の機能

1. データベース管理者は、人事データベースに認証情報のセットを作成し、MyCustomApp という名前のアプリケーションで使用します。また、管理者は、アプリケーションが従業員データベースにアクセスするために必要なアクセス許可でこれらの認証情報を設定します。

2. データベース管理者は、これらの認証情報を MyCustomAppCreds という名前の Secrets Managerにシークレットとして保存します。次に、Secrets Manager では認証情報をシークレット内で暗号化し、保護されたシークレットテキストとして保存します。

3. MyCustomApp がデータベースにアクセスする必要があるとき、アプリケーションは Secrets Managerで MyCustomAppCreds という名前のシークレットをクエリします。

4. Secrets Manager はシークレットを取得して、保護されたシークレットテキストを復号し、保護された(TLS を使用した HTTPS) チャネルを介してそのシークレットをクライアントアプリケーションに返します。

5. クライアントアプリケーションは、認証情報、接続文字列、およびその他の必要な情報をレスポンスから解析し、その情報を使用してデータベースサーバーにアクセスします。

Note

Secrets Manager は、多くの種類のシークレットをサポートしています。ただし、SecretsManager は、追加のプログラミングなしで、サポートされている AWS データベース (p. 4)の認証情報をネイティブに更新できます。ただし、他のデータベースまたはサービスのシークレットを更新するには、カスタム Lambda 関数を作成して、Secrets Manager がデータベースまたはサービスとどのようにやりとりするかを定義する必要があります。その関数を作成するには、プログラミングスキルが必要です。詳細については、「AWS Secrets Manager シークレットの更新 (p. 74)」を参照してください。

Secrets Manager の機能実行時のプログラムによる暗号化されたシークレットの値の取得Secrets Manager はアプリケーションのソースコードからハードコードされた認証情報を削除するか、アプリケーション内に認証情報を保存しないことによって、セキュリティの体制を改善するのに役立ちます。認証情報をアプリケーション内またはアプリケーションと共に保存すると、アプリケーションまたはそのコンポーネントを調べることができるすべてのユーザーに、その認証情報が漏洩する可能性があります。また、古い認証情報を廃止する前に、アプリケーションを更新してすべてのクライアントに変更をデプロイする必要があるため、認証情報の更新が困難になります。

2

AWS Secrets Manager ユーザーガイドさまざまな種類のシークレットの保存

Secrets Manager を使用すると、保存された認証情報を Secrets Manager ウェブサービスへのランタイム呼び出しで置き換えて､必要に応じて認証情報を動的に取得することができます。

ほとんどの場合、クライアントは暗号化されたシークレット値の最新バージョンにアクセスする必要があります。暗号化されたシークレット値をクエリするときは、バージョン情報をまったく指定せずにシークレット名またはその Amazon リソースネーム (ARN) だけを指定することができます。これを行うと、Secrets Manager は最新バージョンのシークレット値を自動的に返します｡

ただし、他のバージョンも同時に存在する可能性があります。ほとんどのシステムでは、接続の詳細、ユーザー ID、パスワードなどの資格情報の完全なセットなど、単純なパスワードよりも複雑な秘密がサポートされています。Secrets Manager では、これらの認証情報の複数のセットを同時に保存することができます。Secrets Manager は、各セットを異なるバージョンのシークレットに保存します。シークレットのローテーションプロセス中、Secrets Manager は古い認証情報と、更新が完了するまで使用したい新しい認証情報を追跡します。ステージングラベル (p. 11)を使用して、さまざまなバージョンを追跡します｡

さまざまな種類のシークレットの保存Secrets Manager により、シークレットの暗号化されたシークレットデータ部分にテキストを保存できます。通常、このテキストはデータベースまたはサービスへの接続の詳細です。詳細には、サーバー名、IPアドレス、ポート番号、サービスにサインインするために使用されるユーザー名とパスワードが含まれます。シークレットについては、「最大値と最小値」を参照してください。保護されたテキストに以下の情報は含まれません。

• シークレットの名前と説明• ローテーションまたは有効期限の設定• シークレットに関連付けられている AWS KMS カスタマーマスターキー (CMK) の ARN。• アタッチされた AWS タグ

シークレットデータの暗号化Secrets Manager は、AWS Key Management Service (AWS KMS) を使用して、シークレットの保護テキストを暗号化します。多くの AWS サービスでは、キーストレージおよび暗号化に AWS KMS を使用します。AWS KMS は、保管時のシークレットの安全な暗号化を保証します。Secrets Manager はすべてのシークレットを AWS KMS CMK に関連付けます。Secrets Manager のアカウントのデフォルト CMK、または、お客様が作成した CMK のいずれかになります。

Secrets Manager で保護されたシークレットデータの新しいバージョンを暗号化するたびに、SecretsManager では、指定された CMK から新しいデータキーを作成するよう AWS KMS に要求します。Secrets Manager は、このデータキーをエンベロープ暗号化に使用します。Secrets Manager は、暗号化されたデータキーを、保護されたシークレットデータを使用して保存します。シークレットが復号を必要とするたびに、Secrets Manager では、データキーの復号を AWS KMS に要求します。SecretsManager は、このデータキーを使用して保護されたシークレットデータを復号します。Secrets Managerでは、データキーを暗号されていない形式で保存することはなく、常にデータキーを使用直後に破棄します。

また、Secrets Manager はデフォルトで、オープン標準のトランスポート層セキュリティ (TransportLayer Security) とパーフェクトフォワードシークレットを使用するホストからの要求のみを受け入れます。Secrets Manager は、シークレットの取得に使用する AWS とコンピュータ間での転送中にシークレットを確実に暗号化します。

シークレットを自動的に更新するユーザーの介入なしに、指定したスケジュールに基づいてシークレットを自動的に更新するよう SecretsManager を設定できます。

3

reference_limits.html#reference_limits_max-min

https://docs.aws.amazon.com/kms/latest/developerguide/

https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#enveloping

https://en.wikipedia.org/wiki/Transport_Layer_Security

https://en.wikipedia.org/wiki/Transport_Layer_Security

https://en.wikipedia.org/wiki/Forward_secrecy

AWS Secrets Manager ユーザーガイドシークレットを自動的に更新する

AWS Lambda 関数を使用して、ローテーションを定義し、実装します。この関数は、Secrets Manager が次のタスクを実行する方法を定義します:

• これにより、シークレットの新しいバージョンが作成されます。• シークレットを Secrets Manager に保存します。• 新しいバージョンを使用するように保護されたサービスを構成します。• 新しいバージョンを確認します。• 新しいバージョンを本番準備完了としてマークします。

ステージングラベルは、シークレットの異なるバージョンを追跡するのに役立ちます。各バージョンには複数のステージングラベルをアタッチできますが、各ステージングラベルは 1 つのバージョンにのみアタッチできます。たとえば、Secrets Manager では、現在アクティブで使用中のシークレットのバージョンに AWSCURRENT というラベルが付けられます。現在のバージョンのシークレットを常にクエリするようアプリケーションを設定する必要があります。ローテーションプロセスで新しいバージョンのシークレットが作成されると、Secrets Manager では、テストおよび検証が完了されるまで、AWSPENDINGというステージングラベルが新しいバージョンに自動的に付けられます。その後、Secrets Manager はAWSCURRENT ステージングラベルをこの新しいバージョンに追加します。アプリケーションは、次回のAWSCURRENT バージョンのクエリで､すぐに新しいシークレットの使用を開始します。

完全に設定された即時使用ローテーションをサポートするデータベースローテーションを有効にする場合、Secrets Manager は次の Amazon Relational Database Service(Amazon RDS) データベースを AWS で書かれた、テスト済みの Lambda ローテーション関数テンプレート、およびローテーションプロセスの完全な設定でサポートしています。

• Amazon RDS での Amazon Aurora• Amazon RDS での MySQL• Amazon RDS 上の PostgreSQL• Amazon RDS での Oracle• Amazon RDS の MariaDB• Amazon RDS での Microsoft SQL Server

完全に設定された即時使用ローテーションをサポートする他のサービスAWS によって記述されてテストされた Lambda ローテーション関数テンプレート、および完全に設定されたローテーションプロセスをフルサポートする以下のサービスでも、ローテーションを有効にすることもできます。

• Amazon DocumentDB• Amazon Redshift

ほとんどすべての他の種類のデータベースやサービスのシークレットを保存することもできます。ただし、自動的に更新するには、カスタム Lambda ローテーション関数を作成して設定する必要があります。データベースまたはサービスのカスタム Lambda 関数の記述の詳細については、「Lambda ローテーション関数の概要 (p. 109)」を参照してください。

4

AWS Secrets Manager ユーザーガイドシークレットへのアクセスの制御

シークレットへのアクセスの制御特定のシークレットへのアクセスを許可または拒否するユーザー、グループ、およびロールに AWSIdentity and Access Management (IAM) アクセス許可ポリシーをアタッチして、それらのシークレットの管理を制限できます。たとえば、メンバーがシークレットを完全に管理および設定する能力を必要とするグループに､1 つのポリシーをアタッチすることができます。アプリケーションによって使用されるロールにアタッチされる別のポリシーは、アプリケーションが実行する必要がある 1 つのシークレットに対する読み取りアクセス権限のみを許可する場合があります。

また、リソースベースのポリシーをシークレットに直接アタッチして、シークレット、およびバージョンの読み取りや変更を許可するユーザーを指定するアクセス許可を付与することもできます。(ユーザー、グループ、またはロールに自動的に適用される) アイデンティティベースのポリシーとは異なり、シークレットに関連付けられたリソースベースのポリシーは、Principal 要素を使用して、ポリシーの適用対象を識別します。Principal 要素には、同じアカウントからのユーザーやロールを、他のアカウントからのシークレットまたはプリンシパルとして含めることができます。

標準への準拠AWS Secrets Manager は、以下の標準について監査済みであり、コンプライアンスの認定を取得する必要がある場合にはソリューションの一部となります。

AWS は、医療保険の相互運用性と説明責任に関する法令 (HIPAA) コンプライアンスプログラムを拡張し、HIPAA 対応サービスとして AWS Secrets Manager を含めています。AWS と事業提携契約 (BAA) を締結している場合は、Secrets Manager を使用して HIPAA 準拠アプリケーションを構築できます。AWS では、医療情報の処理や保存に AWS の活用をお考えのお客様向けに、HIPAA 関連のホワイトペーパーも用意しています。詳細については、HIPAA への準拠を参照してください。

AWS Secrets Manager は、クレジットカード業界 (PCI) のデータセキュリティ標準 (DSS)バージョン 3.2、サービスプロバイダーレベル 1 で準拠証明書を取得しています。AWS の製品やサービスを使用してカード所有者のデータを保存、処理、転送するユーザーは、各自のPCI DSS 準拠認定の管理に AWS Secrets Manager を使用できます。PCI DSS の詳細 (AWSPCI Compliance Package のコピーをリクエストする方法など) については、「PCI DSS レベル 1」を参照してください。

AWS Secrets Manager は、ISO/IEC 27001、ISO/IEC 27017、ISO/IEC 27018、および ISO9001 のコンプライアンス認証を正常に取得しました。詳細については、「ISO 27001」､「ISO 27017」､「ISO 27018」､および「ISO 9001」を参照してください。

System and Organization Control (SOC) レポートとは、重要なコンプライアンスの統制および目標を Secrets Manager がどのように達成したかを実証する、独立した第三者による審査報告書です。このレポートの目的は、オペレーションとコンプライアンスをサポートするよう確立された AWS 統制を、ユーザーおよびユーザーの監査人が容易に把握できるようにすることです。詳細については、「SOC コンプライアンス」を参照してください。

5

https://aws.amazon.com/compliance/hipaa-eligible-services-reference/

https://d0.awsstatic.com/whitepapers/compliance/AWS_HIPAA_Compliance_Whitepaper.pdf

https://aws.amazon.com/compliance/hipaa-compliance/

https://aws.amazon.com/compliance/hipaa-compliance/

https://aws.amazon.com/compliance/pci-dss-level-1-faqs/

https://aws.amazon.com/compliance/pci-dss-level-1-faqs/

https://aws.amazon.com/compliance/iso-27001-faqs/




https://aws.amazon.com/compliance/soc-faqs/

AWS Secrets Manager ユーザーガイドSecrets Manager へのアクセス

Secrets Manager へのアクセス次のいずれかの方法で Secrets Manager を使用できます。

AWS マネジメントコンソール

ブラウザベースのコンソールを使用してシークレットを管理し、Secrets Manager コンソールを使用してシークレットに関連するほぼすべてのタスクを実行できます。

現時点では、コンソールで以下のタスクを実行することはできません。• ストアバイナリデータをシークレットに保存します。コンソールは現在、シークレットのSecretString フィールドにのみデータを保存し、SecureBinary フィールドは使用しません。バイナリデータを保存するには、AWS CLI または AWS SDK のいずれかを現在使用する必要があります。

AWS コマンドラインツール

AWS コマンドラインツールを使用して、システムのコマンドラインでコマンドを発行することで、Secrets Manager およびその他の AWS タスクを実行できます。これは、コンソールを使用するよりも高速でより便利になります。コマンドラインツールは、AWS タスクを実行するスクリプトを作成する場合にも便利です。

AWS には、AWS Command Line Interface (AWS CLI) と AWS Tools for Windows PowerShell という 2 セットのコマンドラインツールが用意されています。AWS CLI のインストールおよび使用の詳細については、『AWS Command Line Interface ユーザーガイド』を参照してください。Toolsfor Windows PowerShell のインストールおよび使用の詳細については、『AWS Tools for WindowsPowerShell ユーザーガイド』を参照してください。

AWS SDK

AWS SDK は、さまざまなプログラミング言語とプラットフォーム (Java､Python､Ruby、.NET、iOSおよび Android､その他など) のライブラリとサンプルコードで構成されています。SDK には、暗号署名によるリクエスト、エラーの管理、リクエストの自動再試行などのタスクが含まれます。AWS SDKのダウンロードおよびインストール方法の詳細については、「アマゾンウェブサービス用ツール」を参照してください。

Secrets Manager HTTPS クエリ API

Secrets Manager HTTPS クエリ API を使用すると、Secrets Manager および AWS にプログラムでアクセスできます。HTTPS クエリ API を使用すると、サービスに HTTPS リクエストを直接発行できます。HTTPS API を使用する場合は、認証情報を使用してリクエストにデジタル署名するコードを含める必要があります。詳細については、「HTTP クエリリクエストを作成して API を呼び出す」および「AWS Secrets Manager API リファレンス」を参照してください。

Note

HTTPS クエリ API を使用する代わりに、望ましいプログラミング言語に固有の SDK を使用することをお勧めします。SDK は、手動で実行する多くの便利なタスクを実行します。SDKは自動的にリクエストに署名し、該当言語で構文的に適切な構造になるようレスポンスを変換します。HTTPS Query API は、SDK が使用できない場合にのみ使用します。

Secrets Manager の料金表Secrets Manager を使用するときは、お客様が利用された分のみのお支払いとなり、最低料金や設定料金はありません。現在の価格の詳細なリストについては、「AWS Secrets Manager 料金表」を参照してください。

6

https://console.aws.amazon.com/secretsmanager/

https://aws.amazon.com/cli/

https://aws.amazon.com/powershell/

https://docs.aws.amazon.com/cli/latest/userguide/

https://docs.aws.amazon.com/powershell/latest/userguide/

https://docs.aws.amazon.com/powershell/latest/userguide/

https://aws.amazon.com/sdk-for-java/

https://aws.amazon.com/sdk-for-python/

https://aws.amazon.com/sdk-for-ruby/

https://aws.amazon.com/sdk-for-net/

https://aws.amazon.com/mobile/resources/

https://aws.amazon.com/mobile/resources/

https://aws.amazon.com/tools/#sdk


https://docs.aws.amazon.com/secretsmanager/latest/userguide/query-requests.html

https://docs.aws.amazon.com/secretsmanager/latest/apireference/

https://aws.amazon.com/secrets-manager/pricing

AWS Secrets Manager ユーザーガイドAWS KMS– 顧客の暗号化キー

AWS KMS– 顧客の暗号化キーAWS KMS を使用して自分のシークレットを暗号化する独自のお客様マスターキーを作成すると、AWSが現行の AWS KMS レートで課金されます。ただし、AWS Secrets Manager がアカウント用に作成する「デフォルト」キーは、無料で使用できます。お客様が作成する AWS KMS キーのコストの詳細については、「AWS Key Management Service 料金表」を参照してください。

AWS CloudTrailログ記録– ストレージと通知アカウントで AWS CloudTrail を有効にすると、AWS Secrets Manager が送信する API コールのログを取得できます。Secrets Manager はすべてのイベントを管理イベントとして記録します。データイベントがありません。AWS CloudTrail の 1 つの証跡を、管理イベントをキャプチャするために、キャプチャしても追加料金は発生しません。AWS CloudTrail では、すべての管理イベントのコピーは無料で保管されます。ただし、通知を有効にすると、Amazon SNS のログストレージと Amazon S3 の料金が発生する場合があります。また、追加の証跡を設定している場合、管理イベントの追加コピーについては、料金が発生する可能性があります。詳細については、AWS CloudTrail 料金表ページを参照してください。

AWS Secrets Manager のサポートとフィードバック

ご意見をお待ちしております。[email protected] にコメントを送信することができます。また、AWS Secrets Manager サポートフォーラムにフィードバックと質問を掲載することができます。AWS サポートフォーラムの詳細については、「フォーラムヘルプ」を参照してください。

AWS Secrets Manager コンソールまたはコマンドラインツールの新しい機能をリクエストするには、[email protected] に E メールを送信することをお勧めします。

ドキュメントのフィードバックを提供するには、各ウェブページの下部にあるフィードバックリンクを使用してください。直面している問題と､そのドキュメントが役に立たなかった理由について､具体的に記述してください。お客様が実際に見たものと、期待したものとがどのように異なっているかを教えてください。そのようなコメントは､私たちがドキュメントを改善するために何が必要であるかを理解するのに役立ちます。

ここでは、その他のリソースも使用できます。

• AWS トレーニングカタログ – AWS スキルの向上と実践的な経験を積むために、ロールベースの専門コースとセルフペースのラボです。

• AWS 開発者ツール – 開発者用ツールと、AWS を利用した革新的なアプリケーションの構築に役立つ資料、コード例、リリースノート、その他の情報を含むツールとリソースです。

• AWS サポートセンター – AWS サポートケースを作成および管理するためのハブです。フォーラム、技術上のよくある質問、サービス状態ステータス、AWS Trusted Advisor などの便利なリソースへのリンクが含まれています。

• AWS サポート – 1 対 1 での迅速な対応を行うサポートチャネルである AWS サポートは、クラウドでのアプリケーションの構築と運用を支援します。

• お問い合わせ – AWS の請求、アカウント、イベント、不正行為、およびその他の問題に関するお問い合わせ先です。

• AWS サイトの利用規約 – 当社の著作権、商標、お客様のアカウント、ライセンス、サイトへのアクセス、およびその他のトピックに関する詳細情報です。

7

https://aws.amazon.com/kms/pricing

https://aws.amazon.com/cloudtrail/pricing

mailto:[email protected]

https://forums.aws.amazon.com/forum.jspa?forumID=296

https://forums.aws.amazon.com/help.jspa

mailto:[email protected]

https://aws.amazon.com/training/course-descriptions/

https://aws.amazon.com/developertools/

https://console.aws.amazon.com/support/home#/

https://aws.amazon.com/premiumsupport/

https://aws.amazon.com/contact-us/

https://aws.amazon.com/terms/

AWS Secrets Manager ユーザーガイド用語と概念

AWS Secrets Manager の使用開始AWS Secrets Manager の使用を開始するには、次のトピックを確認することをお勧めします。

• 用語と概念 (p. 8) - 基本概念、および API、SDK コマンド、コンソールインターフェイス全体で使用する Secrets Manager 用語です。

• チュートリアル (p. 12) - Secrets Manager での基本的なタスクの実行方法を習得するために、一般的なシナリオを順を追って説明します。

AWS Secrets Manager の主な用語と概念以下の用語と概念は、AWS Secrets Manager とその仕組みを理解する上で重要です。

シークレットSecrets Manager では、シークレットは認証情報、ユーザー名、パスワードそしてセキュリティで保護されたサービス (p. 10)にアクセスするために使用する接続の詳細一式で構成されています。これらを安全に保存し、許可されたユーザーだけがアクセスできるようにします｡Secrets Manager は、シークレットテキストを常に暗号化された形式で格納し、転送中のシークレットを暗号化します。

Secrets Manager は、IAM アクセス許可ポリシーを使用して、許可されたユーザーのみがシークレットにアクセスまたは変更できるようにします。これらのポリシーをユーザーまたはロールに添付し、それらのユーザーがアクセスできるシークレットを指定できます。シークレットへのアクセスの制御方法については、「AWS Secrets Manager に対する認証とアクセスコントロール (p. 34)」を参照してください。

認証情報を保存する場合、保護された異なるサービスでは異なる情報が必要になることがあります。Secrets Manager は、このシークレットをテキスト文字列のキーと値のペアとして保存することにより、この柔軟性を提供します。Secrets Manager でサポートされているデータベースを選ぶ際は、SecretsManager が、選択したデータベースのローテーション関数の要件に合わせてキーと値の組み合わせを定義します。Secrets Manager は、JSON テキストとして組み合わせを形式化します。その他サービスまたはデータベースを選択した場合、Secrets Manager は、Lambda 関数を提供しないので、ユーザーが定義した JSON のキーと値の組み合わせとしてシークレットを指定することができます。

結果として保存される暗号化されたシークレットテキストは、次の例のようになります。

{ "host" : "ProdServer-01.databases.example.com", "port" : "8888", "username" : "administrator", "password" : "My-P@ssw0rd!F0r+Th3_Acc0unt", "dbname" : "MyDatabase", "engine" : "mysql"}

コマンドラインツールまたは API を使用する場合、バイナリデータをシークレットに保存することもできます。Secrets Manager コンソールは、バイナリデータをサポートしていません。

Secrets Manager は、指定したスケジュールでシークレットを自動的にローテーションします。パスワードの代わりにユーザーまたはアカウントの完全な認証情報セットを保存する場合、サービスを中断せずに認証情報をローテーションすることができます。パスワードのみを変更または更新すると、古いパスワードは直ちに使用できなくなり、クライアントは直ちに新しいパスワードの使用を開始しなければなりませ

8

http://json.org

AWS Secrets Manager ユーザーガイドシークレット

ん｡そうしないと失敗します。新しいパスワードを使用して新しいユーザーを作成するか、少なくとも 2人のユーザーを交互に変更することができれば、古いユーザーとパスワードは、古いユーザーとパスワードを非推奨にするまで、新しいユーザーとパスワードを並行して操作できます。これにより、新しい認証情報をテストして検証する間に、すべてのクライアントが引き続き作業できる時間を確保できます。新しい認証情報がテストに合格したら、すべてのクライアントが新しい認証情報を使用することを確実にし、古い認証情報を削除します。

サポートされているデータベース

Secrets Manager コンソールを使用し、Secrets Manager がネイティブにサポートするデータベースのいずれか (p. 4)のシークレットを指定すると、Secrets Manager はすべての構造を管理し、解析します。コンソールは、特定のタイプのデータベースの詳細を入力するように求めます。その後、Secrets Managerは、必要な構成を構築し、情報を保存し、情報を取得する際に、解析を行い、簡単に理解しやすいテキスト情報に戻します。

その他のデータベースまたはサービス

その代わりに、「カスタム」データベースまたはサービスのシークレットを指定する場合は、シークレットテキストを取得した後で行う操作とその解釈を管理します。Secrets Manager コンソールは、シークレットをキーと値の文字列として受け入れ、自動的にそれらを保存用の JSON 構造に変換します。コンソールでシークレットを取得すると、Secrets Manager はシークレットを自動的に解析して、キーと値のテキスト文字列に戻して表示します。シークレットをプログラムで取得する場合は、適切な JSON 解析ライブラリを使用することができます。これは、ほぼすべてのプログラミング言語で利用可能で、効果的な方法で、シークレットを解析できます。シークレットあたりの制限 10,240 バイトを超える必要がある場合は、キーと値のペアを 2 つのシークレットに分割し、取り出すときに連結することができます。

Secrets Manager シークレットの基本構造Secrets Manager では、シークレットには暗号化されたシークレットテキストだけでなく、シークレットを記述するいくつかのメタデータ要素が含まれており、シークレットをどのように Secrets Manager が処理するべきかが定義されています。

• メタデータ – シークレットの詳細• シークレットの名前、説明、および一意の識別子として機能する Amazon リソースネーム (ARN) を含

む基本情報。• Secrets Manager がシークレットの保護テキストを暗号化および復号するために使用する AWS Key

Management Service (AWS KMS) キーの ARN。この情報を指定しない場合、Secrets Manager はアカウントのデフォルト AWS KMS キーを使用します。

9

AWS Secrets Manager ユーザーガイド保護されたサービス

• キーをローテーションする頻度 (p. 10)およびローテーションを実行するために使用する Lambda関数に関する情報。

• ユーザーが提供した一連のタグ。タグは、整理、論理グループ、およびコスト配分用にキーと値のペアとして AWS リソースにアタッチできます。

• バージョン – 暗号化されたシークレットテキストの 1 つまたは複数のバージョン (p. 11)• 通常は一度に 1 つのバージョンのシークレットしか使用できませんが、データベースまたはサービス

上のシークレットをローテーションしている間は、複数のバージョンが存在する可能性があります。シークレットを変更するたびに、Secrets Manager は、新規バージョンを作成します。

• 各バージョンには、暗号化されたシークレット値のコピーが保持されています。• 各バージョンは、シークレットローテーションサイクルのステージを識別するために添付された 1 つ

以上のステージングラベル (p. 11)を保持することができます。

保護されたサービスSecrets Manager は、セキュリティで保護されたサービスをデータベースまたはシークレットで保存されている認証情報で管理されているアクセスがあるネットワークサーバーで実行中のその他サービスとして定義します。セキュリティで保護されたサービスは、単一のサーバー、または同じアクセス方法を共有する大規模なサーバーグループを参照できます。保護されたサービスに正常にアクセスするには､シークレットが必要です。シークレットには、クライアントが保護されたサービスにアクセスするために必要なすべての情報が含まれています。このガイドでは、シークレットを AWS Secrets Manager で保護できるさまざまなタイプのデータベースまたはサービスをすべて表す一般的な用語として、「保護されたサービス」という用語を使用しています。

RotationSecrets Manager はローテーションを、定期的にシークレットを変更して、攻撃者がセキュリティで保護されたサービスにアクセスするのをより困難にするプロセスとして定義します。Secrets Manager を使用すると、手動でシークレットを変更してすべてのクライアントで更新する必要がなくなります｡代わりに、Secrets Manager は AWS Lambda 関数を使用して、すべてのローテーションステップを定期的なスケジュールで実行します。

たとえば、データベースやセキュリティで保護されたサービス (p. 10)にアクセスするアプリケーションをすべて実行している大規模のクライアントがあるとします。認証情報をアプリケーションにハードコーディングする代わりに、アプリケーションは必要に応じて、Secrets Manager にリクエストを送信し、シークレットの詳細を受信します。シークレットをローテーションさせる際、Lambda ローテーション関数は自動的に以下のステップを実行します｡

1. ローテーション関数は、セキュリティで保護されたサービスの認証システムに接続し、データベースにアクセスするための新しい認証情報の一式を作成します。認証情報は、通常ユーザー名、パスワード、および接続の詳細で構成されますが、システムによって異なる場合があります。Secrets Managerは、AWSPENDING ステージングラベルが添付されたシークレットの新しいバージョン (p. 11)で、シークレットテキストとしてこれら新しい認証情報を保存します。

2. その後、ローテーション関数は、シークレットの AWSPENDING バージョンをテストして、認証情報が機能し、保護されたサービスに必要なレベルのアクセスを許可していることを確認します。

3. テストが成功した場合、ローテーション関数はラベル AWSCURRENT を新しいバージョンに移動し、それをデフォルトバージョンとしてマークします。これにより、すべてのクライアントが古いバージョンではなく､このバージョンのシークレットの使用を開始します。また、この関数は、古いバージョンにAWSPREVIOUS というラベルを割り当て、それを「最後の既知の正常な」バージョンとしてマークします。これで、AWSPREVIOUS ステージングラベルを持つバージョンに、ラベルがなくなるため、非推奨になります。

コンソールで [Rotate secret (シークレットをローテーションする)] を選択すると、手動で Lambda ローテーション関数を起動することも、ローテーションスケジュールを指定して n 日ごとに自動的にトリガー

10

https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/tag-editor.html

https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html#allocation-what

AWS Secrets Manager ユーザーガイドステージングラベル

することもできます。Secrets Manager がネイティブでサポートする AWS データベースのいずれかを使用すると (p. 4)、Secrets Manager はそのデータベースの認証情報をローテーションする Lambda 関数を提供します。この関数は、基本的なローテーションを自動的に実行します｡または高度なカスタムローテーションポリシーをサポートするように､この機能をカスタマイズすることができます。

カスタムサービスのシークレットを作成する場合は、Lambda 関数を自分で作成しなければなりません。この関数のコードでは、JSON 構造の作成方法を決定し、その関数内で解析します。

シークレットが使用するいずれのサービスまたはデータベースでも、シークレット用の Lambda ローテーション関数は、データベースまたはサービスの両方、そして Secrets Manager サービスエンドポイントにアクセスできなければなりません。Lambda ローテーション関数およびデータベースまたはサービスが Amazon VPC から提供される VPC に存在する場合、Secrets Manager 用の VPC サービスエンドポイント (p. 77)、またはNAT ゲートウェイを使用した直接的なインターネット接続のいずれかを使用して、VPC がパブリック Secrets Manager サービスエンドポイントへのアクセスを許可するように設定します。

ローテーションについて詳しくは、「AWS Secrets Manager シークレットの更新 (p. 74)」を参照してください。

ステージングラベルSecrets Manager は、簡単なテキスト文字列のステージングラベルを使用して、ローテーション (p. 10)中に異なるバージョン (p. 11)のシークレットを識別できるようにします。暗号化されたシークレット値をクエリするたびに、取得するシークレットのバージョンを指定することができます。バージョン ID またはステージングラベルでバージョンを指定しない場合、Secrets Manager はステージングラベル AWSCURRENT が添付されたバージョンを規定値とします。Secrets Manager は、常にステージングラベル AWSCURRENT を 1 つのバージョンのシークレットに添付します。これがどのように機能するかの例については、ローテーション (p. 10)の簡単な紹介を参照してください。

シークレットのバージョンは、0 〜 20 のステージングラベルがアタッチされています｡

ステージングラベルは、一度にシークレットの 1 つのバージョンにのみアタッチできます。ステージングシークレットの 2 つのバージョンは同じラベルを持つことはできません。ステージングラベルをバージョンに添付する際に、同じラベルがある別のバージョンが存在する場合は、ラベルを削除するバージョンも指定する必要があります。指定しないと、Secrets Manager はエラーを返します。

シークレットの 1 つのバージョンは、常にステージングラベル AWSCURRENT を保持する必要があり、APIオペレーションによってこの動作が強制されます。Secrets Manager によって提供される Lambda ローテーション関数は、適切なバージョンの AWSPENDING、AWSCURRENT、および AWSPREVIOUS ラベルを自動的に保持します。

バージョニングシークレットのローテーション (p. 10)をサポートするため、シークレットには複数のバージョンが存在します。Secrets Manager は、ステージングラベル (p. 11)を使用して、異なるバージョンを区別します。ほとんどのシナリオでは、シークレットのバージョンについて心配する必要はありません。SecretsManager および提供される Lambda ローテーション関数が、これらの詳細を管理します。ただし、独自のLambda ローテーション関数を作成する場合は、コードで複数のバージョンのシークレットをご自身で管理し、バージョン間でステージングラベルを適切に移動する必要があります。バージョン間で移動できるステージングラベルとは異なり、バージョンには同じバージョンで常に保持される一意の識別子 (通常はUUID 値) もあります。

AWSCURRENT ラベルがアタッチされたシークレットのデフォルトバージョンを常に要求するようにクライアントを設定します。他のバージョンも存在できますが、特定のバージョン ID またはステージングラベルを要求することによってのみ他のバージョンにアクセスできます。シークレット値を要求すると、バージョン ID またはステージングラベルを指定しない場合、デフォルトでは、AWSCURRENT というステージングラベルのバージョンが取得されます。

11

https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-nat-gateway.html

https://wikipedia.org/wiki/UUID

AWS Secrets Manager ユーザーガイドチュートリアル

ローテーション中、Secrets Manager はシークレットの新しいバージョンを作成し、ステージングラベルAWSPENDING をアタッチします。ローテーション関数は、AWSPENDING バージョンを使用し、バージョンがテストに合格するまで、そのバージョンを識別します。ローテーション関数が新しい認証情報が機能することを確認したら、Secrets Manager は、ラベル AWSPREVIOUS をAWSCURRENT のある古いバージョンに移動し、ラベル AWSCURRENT を新しい AWSPENDING ラベルに移動し、最後に、AWSPENDING を削除します。

ステージングラベルがローテーションをサポートする方法の詳細については、「AWS Secrets Managerシークレットの更新 (p. 74)」を参照してください。

シークレット用に維持される各バージョンは、次の要素が含まれます。

• バージョンの一意の ID。• バージョンを識別するために使用するステージングラベルのコレクション、シークレット内では固

有。Secrets Manager は、ステージングラベルが存在しないバージョンを非推奨と認識し、これらバージョンは、削除対象となる場合があります。

• 暗号化され、保存されたシークレットテキスト。

暗号化されたシークレット値をクエリするたびに、シークレットのバージョンを指定することができます。バージョン ID またはステージングラベルのいずれかでバージョンを指定しない場合、SecretsManager は、ステージングラベル AWSCURRENT が添付されたバージョンを規定値とします。SecretsManager は常にステージングラベル AWSCURRENT を 1 つのバージョンのシークレットに添付します。

AWS Secrets Manager のチュートリアルこのセクションのチュートリアルを使用して、AWS Secrets Manager を使用するタスクの実行方法について学びます。

チュートリアル: シークレットの作成と取得 (p. 12)

シークレットを作成して、それを取得する手順を実行します。このチュートリアルでは、事前設定された AWS データベースは必要ありません。

チュートリアル: AWS データベースのシークレットのローテーション (p. 15)

Amazon RDS MySQL データベースのシークレットを作成します。次に、データベースへのアクセスに使用されるシークレットを更新して、スケジュールに従って更新するようにシークレットを設定します。

チュートリアル: マスターシークレットでユーザーのシークレットをローテーションする (p. 23)

前のチュートリアルのシークレットを、Amazon RDS MySQL データベースの個別のユーザーシークレットをローテーションできるマスターシークレットとして使用します。次に、マスターシークレットおよび代替ユーザーとしてサインインして、ユーザーシークレットをローテーションします。

チュートリアル: シークレットの作成と取得このチュートリアルでは、シークレットを作成して AWS Secrets Manager に保存します。次に、AWS マネジメントコンソールと AWS CLI の両方でシークレットを取得します。シークレットを作成して保存するだけなので、このチュートリアルではシークレットと連動するデータベースは必要ありません。

ステップ 1: AWS Secrets Manager でシークレットを作成および保存する (p. 13)

このステップでは、シークレットを作成し、AWS Secrets Manager で必要な基本情報を提供します。

12

AWS Secrets Manager ユーザーガイドチュートリアル: シークレットの作成と取得

ステップ 2: AWS Secrets Manager からシークレットを取得する (p. 14)

次に、Secrets Manager コンソールと AWS CLI を使用して、デコードされたシークレット情報を取得します。

前提条件このチュートリアルでは、AWS アカウントにアクセスできることを前提としており、AWS SecretsManager コンソールまたは AWS CLI の同等のコマンドでシークレットを作成および取得するアクセス許可を持つ IAM ユーザーとして AWS にサインインできることを前提としています。

ステップ 1: AWS Secrets Manager でシークレットを作成および保存するこのステップでは、IAM ユーザーとしてサインインしてシークレットを作成します。

コンソールからシークレットを作成して保存する

1. https://console.aws.amazon.com/secretsmanager/ で AWS Secrets Manager コンソールにサインインします。

2. サービスの概要ページまたは [シークレット] リストページで、[新しいシークレットの保存] を選択します｡

3. [新しいシークレットの保存] ページで、[他の種類のシークレット] を選択します。4. [このシークレットに保存するキーと値のペアを指定します] で、最初のフィールドに tutorials/

MyFirstTutorialSecret と入力します。これにより、仮想フォルダ tutorials にシークレットと値MyFirstTutorialSecret が保存されます。2 番目のフィールドは空白のままにしておきます。

5. [プレーンテキスト] を選択すると、シークレットの [SecretString] フィールドに保存されるシークレットテキストの JSON バージョンが表示されます。

6. [暗号化キーを選択] で、[DefaultEncryptionKey] を選択します。Secrets Manager がアカウントで作成するデフォルトの AWS マネージドキーを使用する場合は、AWS KMS は、料金を請求しません。カスタム KMS キーを使用する場合は、標準の AWS KMS レートで課金されます｡

7. [Next] を選択します。8. [シークレット名] で、テキストフィールドにシークレットの名前を入力します。使用できるのは英数

字と /_+ =.@- の文字だけです。9. [説明] フィールドに、ルールの説明を入力します。

[説明] に「The secret I created for the first tutorial.」などと入力します。10. [タグ] セクションで、[キー] および [Value - optional (値 - オプション)] テキストフィールドに目的のタ

グを追加します。

このチュートリアルでは、タグを空白のままにしておきます。11. [Next] を選択します。12. このチュートリアルでは、ローテーションの設定を割愛し、[自動ローテーションを無効化] を選択

し、[次へ] を選択します。13. [確認] ページでは、選択した設定を確認することができます。また、「サンプルコード」セクション

で、認証情報の取得にこのシークレットを使用するために、切り取ってアプリケーションに貼り付けられる – コードを確認します。各タブには、コードがさまざまなプログラミング言語であります。

14. 変更を保存するには、[保存] を選択します。

Secrets Manager コンソールがアカウントのシークレットリストに戻り、新しいシークレットがリストに含まれます。

13


AWS Secrets Manager ユーザーガイドチュートリアル: シークレットの作成と取得

ステップ 1: CLI を使用して AWS Secrets Manager でシークレットを作成して保存する1. コマンドプロンプトを開き、AWS CLI を実行します。AWS CLI をまだインストールしていない場合

は、「AWS Command Line Interface のインストール」を参照してください。2. シークレットにアクセスするためのアクセス許可を持つ認証情報を使用して、次の各コマンドを入力

します。3. シークレットを作成する

$ aws secretsmanager create-secret --name tutorials/MyFirstTutorialSecret --description "The secret I created for the first tutorial"

コマンドの出力には、次の情報が表示されます。

{ "ARN": "arn:aws:secretsmanager:us-west-2:123456789012:secret:tutorials/MyFirstTutorialSecret-a1b2c3", "Name": "tutorials/MyFirstTutorialSecret", }

ステップ 2: AWS Secrets Manager からシークレットを取得するこのステップでは、Secrets Manager コンソールと AWS CLI の両方を使用してシークレットを取得します。

AWS Secrets Manager コンソールでシークレットを取得する

1. コンソールにログインしていない場合は、コンソール (https://console.aws.amazon.com/secretsmanager/) に移動し、Secrets Manager サービスにログインします。

2. [シークレット] リストページで、作成した新しいシークレットの名前を選択します。

Secrets Manager に、シークレットの [Secrets details (シークレットの詳細)] ページが表示されます。3. [シークレット値] セクションで、[Retrieve secret value(シークレット値の取得)] を選択します。4. シークレットは、キーと値のペアとして、または JSON テキスト構造として表示できます。

AWS Secrets Manager CLI を使用してシークレットを取得するには

1. コマンドプロンプトを開き、AWS CLI を実行します。AWS CLI をまだインストールしていない場合は、「AWS Command Line Interface のインストール」を参照してください。

2. シークレットにアクセスするためのアクセス許可を持つ認証情報を使用して、次の各コマンドを入力します。

暗号化されたテキスト以外のすべてのシークレットの詳細を表示するには:

$ aws secretsmanager describe-secret --secret-id tutorials/MyFirstTutorialSecret{ "ARN": "arn:aws:secretsmanager:region:123456789012:secret:tutorials/MyFirstTutorialSecret-jiObOV", "Name": "tutorials/MyFirstTutorialSecret", "Description": "My First Secret", "LastChangedDate": 1522680794.8, "LastAccessedDate": 1522627200.0, "VersionIdsToStages": { "EXAMPLE1-90ab-cdef-fedc-ba987EXAMPLE": [

14

https://docs.aws.amazon.com/cli/latest/userguide/installing.html



https://docs.aws.amazon.com/cli/latest/userguide/installing.html

AWS Secrets Manager ユーザーガイドチュートリアル: AWS データベー

スのシークレットのローテーション

"AWSCURRENT" ] }}

VersionIdsToStages の戻り値を確認します。出力には、シークレットのすべての有効なバージョン、および各バージョンに添付されたステージングラベルのリストが含まれます。このチュートリアルでは、単一のステージングラベル AWSCURRENT にマッピングされるバージョン ID (UUID タイプ値) が表示されます。

シークレットの暗号化されたテキストを表示するには:

$ aws secretsmanager get-secret-value --secret-id tutorials/MyFirstTutorialSecret --version-stage AWSCURRENT{ "ARN": "arn:aws:secretsmanager:region:123456789012:secret:tutorials/MyFirstTutorialSecret-jiObOV", "Name": "tutorials/MyFirstTutorialSecret", "VersionId": "EXAMPLE1-90ab-cdef-fedc-ba987EXAMPLE", "SecretString": "{\"username\":\"myserviceusername\",\"password\":\"MyVerySecureP@ssw0rd!\"}", "VersionStages": [ "AWSCURRENT" ], "CreatedDate": 1522680764.668}

AWSCURRENT とは異なるステージングラベルのバージョンの詳細のみが必要な場合は、前述のコマンドに --version-stage パラメータを含める必要があります。Secrets Manager は、規定値としてAWSCURRENT を使用します。

結果には、SecretString レスポンスフィールドの、シークレット値の JSON バージョンが含まれます。

概要

このチュートリアルでは、単純なシークレットを作成する方法と、値を必要な際に、シークレット値を取得する方法について説明しました。シークレットの作成と自動ローテーションの設定に関する別のチュートリアルについては、「チュートリアル: AWS データベースのシークレットのローテーション (p. 15)」を参照してください。

チュートリアル: AWS データベースのシークレットのローテーションこのチュートリアルでは、AWS データベースのシークレットを作成し、スケジュールに従ってローテーションするよう設定します。1 つのローテーションを手動でトリガーし、新しいバージョンのシークレットが引き続きアクセスを提供していることを確認します。

ステップ 1: テストデータベースを設定する (p. 17)

このステップでは、Amazon Relational Database Service (Amazon RDS) でテストデータベースを作成します。このチュートリアルでは、テストデータベースは MySQL を実行します。

ステップ 2: シークレットを作成する (p. 18)

次に、Secrets Manager コンソールを使用してシークレットを作成し、MySQL データベース用の最初のユーザー名とパスワードをシークレットに自動入力します。返された認証情報を使用してデータベースにサインインすることで、シークレットをテストします。

15



ステップ 3: 最初のシークレットを検証する (p. 19)

ステップ 3 では、新しいシークレットを使用して認証情報をテストし、データベースに接続するために使用できることを確認します。

ステップ 4: シークレットのローテーションを設定する (p. 20)

ステップ 4 では、シークレットのローテーションを有効にして最初のローテーションを実行します。ステップ 5: 成功したローテーションの確認 (p. 21)

このステップでは、最初のローテーションが完了した後、ローテーション中に生成された新しい認証情報で引き続きデータベースにアクセスできることを示すために検証ステップを繰り返します。

ステップ 6: クリーンアップ (p. 22)

最後のステップでは、不要なコストの発生を避けるため、Amazon RDS データベースインスタンスとシークレットを削除します。

前提条件このチュートリアルでは、AWS アカウントにアクセスでき、さらにコンソールを使用するか、またはAWS CLI の同等のコマンドを使用して AWS Secrets Manager と Amazon RDS を設定するための完全なアクセス許可を持つユーザーとして AWS にサインインできることを前提としています。

このチュートリアルでは MySQL クライアントツールを使用して、データベースとやり取りしユーザーを設定してステータスを確認します。このチュートリアルには、次のステップの適切なポイントにおけるインストール手順が含まれています。

このチュートリアルでは、jq と呼ばれる Linux JSON 解析ツールも使用しています。ツールをダウンロードするには、「GitHub ウェブサイトで jq」を参照してください。

Important

わかりやすいように、このチュートリアルでは jq を使用してシークレット値を環境変数に解析し、コマンドライン操作を簡単にします。これは、本稼働環境用のセキュリティのベストプラクティスではありません。本番環境では、環境変数にパスワードを保存しないことをお勧めします。また、このチュートリアルで設定したデータベースではポート 3306 のパブリックインターネットへのアクセスを許可します (もう一度チュートリアルをシンプルなセットアップにするために)。このチュートリアルを完了するには、インターネットに接続されたコンピュータからMySQL クライアントツールを使用して MySQL データベースにアクセスできる必要があります。本番稼働サービスを安全に設定するには、Lambda と Amazon EC2 VPC ドキュメントのガイダンスに従います。Important

ローテーションを有効にするには、ネットワーク環境で Lambda ローテーション関数がお客様のデータベースと Secrets Manager サービスと通信できるように許可する必要があります。このチュートリアルでは、パブリックインターネットアクセスを使用してデータベースを設定し、Lambda がパブリック IP アドレスを使用してデータベースにアクセスするローテーション関数を自動的に設定します。データベースインスタンスへのパブリックインターネットアクセスをブロックする場合、Lambda 関数をデータベースインスタンスと同じ VPC 内で実行できるように設定する必要があります。次に、プライベート Secrets Manager エンドポイントで VPC を設定 (p. 77)するか、NAT ゲートウェイを使用してパブリックインターネットアクセスを持つVPC を設定して、Lambda ローテーション関数がパブリック Secrets Manager エンドポイントにアクセスできるようにする必要があります。

必要なアクセス許可このチュートリアルを実行するには、SecretsManagerReadWrite AWS 管理ポリシーに関連付けられているすべてのアクセス許可が必要です。IAM ロールを作成してアクセス許可ポリシーをアタッチす

16

https://stedolan.github.io/jq/



https://console.aws.amazon.com/iam/home?#/policies/arn:aws:iam::aws:policy/SecretsManagerReadWrite



るアクセス許可も必要です。IAMFullAccess AWS 管理ポリシーを付与するか、iam:CreateRole とiam:AttachRolePolicy を明示的に割り当てる事もできます。

Warning

iam:CreateRole と iam:AttachRolePolicy を使用すると、ユーザーが自分にどのようなアクセス許可も付与できるため、これらのポリシーはアカウントで信頼されたユーザーのみ付与してください。

ステップ 1: テストデータベースを設定するこのステップでは、アカウントにサインインし、Amazon RDS の MySQL データベースをセットアップします。

1. AWS マネジメントコンソールにサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

2. コンソールに Amazon Relational Database Service ウェルカムページが表示されたら、[今すぐ始める] を選択します。

コンソールにダッシュボードが表示された場合は、[インスタンス] を選択し、[DB インスタンスの起動] を選択します。

3. [エンジンの選択] ページで、[MySQL] を選択し、[Only enable options eligible for RDS Free UsageTier (RDS 無料利用枠の対象オプションのみを有効化)] を選択して、[次へ] を選択します。

4. [DB 詳細の指定] ページの [インスタンスの仕様] セクションで、すべての設定をデフォルト値のままにしておきます。

5. [Settings] (設定) セクションで、以下のように選択します。

• DB インスタンス識別子: MyTestDatabaseInstance• マスターユーザー名: adminuser• [マスターパスワード]: 安全な初期パスワードを入力し、そのパスワードを [パスワードの確認] ボッ

クス内に再入力します。このパスワードは忘れないようにしてください。ステップ 2 でシークレットを作成するときに必要になります。

6. [Next] を選択します。7. [Configure advanced settings (詳細設定の構成)] ページの [Network & Security (ネットワーク & セキュ

リティ)] セクションで、[Public accessibility (パブリックアクセシビリティ)] を Yes に設定します。この設定は、自動的にパブリック Elastic IP アドレスをデータベースインスタンスに追加します。その他のネットワーク設定は、すべてデフォルト値のままにします。

Note

チュートリアルを正しく設定するためには、少なくともこれらの設定を使用します。プライベート VPC が必要な場合は、Lambda 関数を VPC で実行するように設定する必要があります。次に、プライベート Secrets Manager エンドポイント (p. 77)で VPC を設定するか、NAT ゲートウェイを使用してパブリックインターネットアクセスを持つ VPC を設定して、Lambda ローテーション関数がパブリック Secrets Manager エンドポイントにアクセスできるようにする必要があります。

8. [Database Options (データベースオプション)] セクションで、[Database Name (データベース名)] に「MyTestDatabase」と入力しますその他の設定はデフォルト値のままにしておきます。

9. [バックアップ] セクションで [Backup retention (バックアップの保持)] 期間を [0 days (0 日)] に設定して、バックアップを無効にします。

10. 他のすべてのセクションの設定はデフォルト値のままにしておきます。11. [Launch DB instance] を選択します。12. [View DB instance summary (DB インスタンスの概要を表示)] をクリックし、インスタンスがアク

ティブになるまで待ってから、次のステップに進みます。このステップは、完了するまでに数分かかることがあります。

17

https://console.aws.amazon.com/iam/home?#/policies/arn:aws:iam::aws:policy/IAMFullAccess

https://console.aws.amazon.com/rds/





13. [要約] セクションの [DB インスタンスのステータス] が [利用可能] と表示されたら、ページを更新してから [接続] セクションまで下へスクロールします。

14. [接続] セクションで、タイプが [CIDR/IP - Inbound (CIDR/IP - インバウンド)] であるセキュリティグループの名前を選択します。これで、そのセキュリティグループの Amazon EC2 コンソールが開きます。

15. ページ下部で、[インバウンド] タブを選択し、次に [編集] を選択します。

1 つの既存のルールにより、現在の VPC からデータベースへのアクセスが有効になります。MySQLクライアントツールとアプリケーションを実行している仮定の顧客の両方がすべてこのデータベースにアクセスできるように、パブリックインターネットからデータベースへのアクセスを有効にする必要があります。

Warning

次のステップでは、テストデータベースへのインターネットアクセスが許可されます。Secrets Manager では、このチュートリアルにこの構成を使用します。安全なセットアップでは、データベースインスタンスへのパブリックアクセスをブロックします。そして、データベースインスタンスと同じ VPC で実行するように Lambda 関数を設定します。プライベート Secrets Manager エンドポイント (p. 77)で VPC を設定するか、NAT ゲートウェイを使用してパブリックインターネットアクセスを持つ VPC を設定します。これにより、Lambda ローテーション関数は Secrets Manager エンドポイントにアクセスできます。このデータベースのチュートリアルを完了したら、次のステップで作成するルールを削除することをお勧めします。

16. [ソース] の下で、[カスタム] から [任意の場所] へ変更します。[ポート範囲] は MySQL のデフォルトである 3306 のままにしておきます。

17. [Save] を選択します。

ステップ 2: シークレットを作成するこのステップでは、Secrets Manager でシークレットを作成して、そのシークレットにテストデータベースの詳細やマスターユーザーの認証情報を追加します。

シークレットを作成するには

1. Secrets Manager コンソール (https://console.aws.amazon.com/secretsmanager/) を開きます。2. コンソールが、前のステップで Amazon RDS MySQL データベースを作成したときと同じリージョン

に設定されていることを確認します。3. [新しいシークレットの保存] を選択します｡4. [Create Secret] (シークレットの作成) ページで、[Select secret type] (シークレットタイプの選択) セ

クションの [Credentials for RDS database] (RDS データベース認証情報) を選択します。5. [ユーザー名] に、前にステップ 1.3 で提供したマスターユーザーの名前と一致するように

「adminuser」と入力します。6. [パスワード] には、ステップ 1.3 で [adminuser] 用に提供したものと同じパスワードを入力します。7. [Select the encryption key] (暗号化キーの選択) に、[DefaultEncryptionKey] を使用します。カスタムマ

スターキー (CMK) を使用する場合は、アカウントのデフォルトの代わりに、そのカスタム (CMK) の使用に対して課金されます。

8. [このシークレットがアクセスする RDS データベースを選択] に、ステップ 1 で作成したインスタンス[MyTestDatabaseInstance] を選択します。

9. [Next] を選択します。10. [Secret name and description (シークレットの名前と説明)] セクションで、[Secret name (シークレッ

ト名)] に「MyTestDatabaseMasterSecret」と入力します。11. [Configure automatic rotation (自動ローテーションの設定)] セクションで、今のところローテーション

を無効のままにしておきます。[Next] を選択します。

18






12. [確認] セクションで詳細を確認し、[Store (保存)] を選択します。

新しいシークレットが含まれるようになったシークレットの一覧に戻ります。

ステップ 3: 最初のシークレットを検証するシークレットを自動的にローテーションするように設定する前に、シークレットに正しい情報があり、データベースに接続するために使用できることを確認する必要があります。このチュートリアルでは、Linux ベースの MySQL クライアントコンポーネントをインストールする方法を説明しました。次に、シークレットを取得する Linux コマンドを実行し、シークレットで設定された認証情報を使ってデータベースに接続します。

他のプラットフォームでこのチュートリアルを実行している場合、これらのコマンドはお使いのプラットフォームの同等のコマンドへの変換が必要になる場合があります。少なくとも、AWS CLI または SecretsManager コンソールを使用してシークレットを取得することができます。次に、ユーザー名とパスワードを MySQL データベースクライアントにカットアンドペーストします。

1. MySQL クライアントをインストールします。次に例を示します。

$ sudo yum install mysql...Installed: mysql.noarch 0:5.5-1.3.amzn1

Dependency Installed: mysql55.x86_64 0:5.5.24-1.24.amzn1 mysql55-common.x86_64 0:5.5.24-1.24.amzn1

Complete!$

2. シークレットを取得して一時的に保存するコマンドを実行します。

$ secret=$(aws secretsmanager get-secret-value --secret-id MyTestDatabaseMasterSecret | jq .SecretString | jq fromjson)$ user=$(echo $secret | jq -r .username)$ password=$(echo $secret | jq -r .password)$ endpoint=$(echo $secret | jq -r .host)$ port=$(echo $secret | jq -r .port)

最初のコマンドでは、Secrets Manager からシークレットを取得します。次に、コマンドがSecretString フィールドを JSON レスポンスから抽出して環境変数に保存します。続く各コマンドで、1 つの追加認証情報の一部や接続の詳細を解析して、個別の環境変数に保存します。

3. 解析した詳細を使用してデータベースにアクセスするコマンドを実行します。

$ mysql -h $endpoint -u $user -P $port -p$passwordWarning: Using a password on the command line interface can be insecure.Welcome to the MySQL monitor. Commands end with ; or \g.Your MySQL connection id is 44Server version: 5.6.39 MySQL Community Server (GPL)

Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or itsaffiliates. Other names may be trademarks of their respectiveowners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

19



mysql>

トラブルシューティングのヒント:

mysql コマンドがデータベースに接続できなかった場合、データベースで VPC にアタッチされているセキュリティグループを確認する必要があります。セキュリティグループのデフォルトルールでは、すべてのアウトバウンドトラフィックを有効にしますが、ルールを定義することで明示的に許可したトラフィック以外のすべてのインバウンドトラフィックをブロックします。コンピュータをパブリックインターネットで実行している場合、セキュリティグループはデータベース通信を構成したインターネットから TCP ポートへのインバウンドトラフィックを有効にする必要があります (通常は 3306)。別の TCP ポートを使用するように MySQL を設定する場合、セキュリティルールがそれに一致するよう必ず更新してください。

4. mysql> プロンプトで、シークレットの認証情報を使用してデータベースへの接続を検証するコマンドを実行します。出力の [Current user (現在のユーザー)] にシークレットで指定されたユーザーが含まれていることを確認します。

mysql> status;--------------/path/mysql_real Ver 14.14 Distrib 5.6.39, for Linux (x86_64) using EditLine wrapper

Connection id: 48Current database:Current user: [email protected]: Not in useCurrent pager: lessUsing outfile: ''Using delimiter: ;Server version: 5.6.39 MySQL Community Server (GPL)Protocol version: 10Connection: mytestdatabaseinstance.randomcharacters.region.rds.amazonaws.com via TCP/IPServer characterset: latin1Db characterset: latin1Client characterset: utf8Conn. characterset: utf8TCP port: 3306Uptime: 2 hours 52 min 24 sec

Threads: 2 Questions: 15249 Slow queries: 0 Opens: 319 Flush tables: 1 Open tables: 80 Queries per second avg: 1.474--------------

5. 次のコマンドを使用して接続を閉じます。

mysql> quitBye

ステップ 4: シークレットのローテーションを設定するシークレットの初期認証情報が検証された後、最初のローテーションを設定し開始できます。

1. Secrets Manager コンソールで、シークレット [MyTestDatabaseMasterSecret] を選択します。2. シークレットの詳細ページで、[Rotation configuration (ローテーション設定)] セクションの [Edit

rotation (ローテーションの編集)] を選択します。3. [Edit rotation configuration] (ローテーション設定の編集) ページで、[Enable automatic rotation] (自動

ローテーションを有効化) を選択します。

20



4. [Select rotation interval] (ローテーションの間隔の選択) に、[30 days] (30 日) を選択します。5. [Select which secret will be used to perform the rotation (このローテーションを実行するために使用さ

れるシークレットを選択)] で、[Use this secret (このシークレットを使用)] を選択します。6. [保存] を選択します。Secrets Manager は、Lambda ローテーション関数の作成や Secrets Manager

が関数を呼び出すことを可能にするロールの追加など、シークレットのローテーションの設定を開始します。

7. [ローテーションを設定中です] というメッセージが [Your secret MyTestDatabaseMasterSecret hasbeen successfully stored and secret rotation is enabled. (シークレット MyTestDatabaseMasterSecretが正常に保存され、シークレットのローテーションが有効になっています)] に変わるまで、コンソールに留まります。

ステップ 5: 成功したローテーションの確認シークレットのローテーション後、シークレットの新しい認証情報がデータベースに接続できることが確認できます。

1. シークレットを取得して、環境変数に一時的に保存するコマンドを実行します。

$ secret=$(aws secretsmanager get-secret-value --secret-id MyTestDatabaseMasterSecret | jq .SecretString | jq fromjson)$ user=$(echo $secret | jq -r .username)$ password=$(echo $secret | jq -r .password)$ endpoint=$(echo $secret | jq -r .host)$ port=$(echo $secret | jq -r .port)

2. 以前にインストールしたのと同じ MySQL クライアントを使用し、解析された詳細を使ってデータベースにアクセスするコマンドを実行します。





mysql>

3. mysql> プロンプトで、シークレットの認証情報を使用してデータベースへの接続を検証するコマンドを実行します。


Connection id: 48Current database:Current user: [email protected]: Not in useCurrent pager: lessUsing outfile: ''Using delimiter: ;Server version: 5.6.39 MySQL Community Server (GPL)

21



Protocol version: 10Connection: mytestdatabaseinstance.randomcharacters.region.rds.amazonaws.com via TCP/IPServer characterset: latin1Db characterset: latin1Client characterset: utf8Conn. characterset: utf8TCP port: 3306Uptime: 2 hours 52 min 24 sec


4. 出力の [Current user (現在のユーザー)] がシークレットで指定されたユーザーと一致していることを確認します。

5. 次のコマンドを使用して接続を閉じます。

mysql> quitBye

ステップ 6: クリーンアップImportant

チュートリアルチュートリアル: マスターシークレットでユーザーのシークレットをローテーションする (p. 23) も実行する場合は、そのチュートリアルも完了するまではこれらのステップを実行しないでください。

データベースとシークレットにより AWS 請求書の料金が発生する可能性があるため、チュートリアルの実験が完了したら、このチュートリアルで作成したデータベースインスタンスとシークレットを削除する必要があります。

シークレットの削除

1. Secrets Manager コンソール (https://console.aws.amazon.com/secretsmanager/) を開きます。2. シークレットのリストで、このチュートリアルで作成した [MyTestDatabaseSecret] シークレットを選

択します。3. [Actions] (アクション) を選択してから、[Delete secret] (シークレットの削除) を選択します。4. [Schedule secret deletion (シークレットの削除をスケジュールする)] ダイアログボックスで、[Enter a

waiting period (待機期間の入力)] に可能な最小値、7 を入力します。5. [Schedule deletion] を選択します。

復旧期間の日数が経過すると、Secrets Manager はシークレットを完全に削除します。

データベースインスタンスを削除するには

1. https://console.aws.amazon.com/rds/ にある Amazon RDS コンソールを開きます。2. ナビゲーションペインで、[インスタンス] を選択します。3. 利用可能なインスタンスのリストで、このチュートリアルで作成した [MyTestDatabaseInstance] イン

スタンスを選択します。4. [Instance actions] を選択し、[Delete] を選択します。5. [Delete DB Instance (DB インスタンスの削除)] ページの、[Options (オプション)] セクションで、

[Create final snapshot (最終スナップショットの作成)] に [No (いいえ)] を選択します。6. すべてのデータが失われることを承認するというメッセージを選択し、[削除] を選択します。

22



AWS Secrets Manager ユーザーガイドチュートリアル: マスターシークレットでユー

ザーのシークレットをローテーションする

チュートリアル: マスターシークレットでユーザーのシークレットをローテーションするこのチュートリアルは、最初のチュートリアル (チュートリアル: AWS データベースのシークレットのローテーション (p. 15)) で完了したタスクに基づいています。このチュートリアルを開始する前に、前のチュートリアルを完了してください。

このチュートリアルでは、すでに作成したシークレットをデータベースのマスターユーザーとして使用します。新しい限定されたユーザーを作成し、そのユーザーのシークレットを作成します。マスターシークレットの認証情報を使用して、ユーザーシークレットのローテーションを設定します。マスターシークレットの Lambda ローテーション関数は、最初のユーザーをクローンした後、ユーザー間で交互に、各パスワードを順に変更します。

ステップ 1: データベースとユーザーシークレットのための新しいユーザーを作成する (p. 23)

まず、Amazon RDS MySQL データベースに制限されたアクセス許可を持つ新しいユーザーを作成し、それらの認証情報を新しいシークレットに保存します。

ステップ 2: 最初のシークレットを検証する (p. 24)

ステップ 2 では、シークレットに保存されている認証情報を使用して、新しいユーザーとしてデータベースにアクセスできることを確認します。

ステップ 3: シークレットのローテーションを設定する (p. 26)

ステップ 3 では、ユーザーシークレットのローテーションを設定します。ローテーション関数へのアクセスを許可するために使用するマスターシークレットを指定します。

ステップ 4: 成功したローテーションの確認 (p. 27)

このステップでは、シークレットを 2 回ローテーションさせて、シークレットがデータベースにアクセスできる 2 つの代替ユーザーから、機能している認証情報を取得することを示します。

ステップ 5: クリーンアップ (p. 28)

最後のステップでは、不要なコストの発生を避けるため、Amazon RDS データベースインスタンスと作成したシークレットを削除します。

前提条件• このチュートリアルでは、AWS アカウントにアクセスでき、さらにコンソールで、または AWS CLI の

同等のコマンドを使用して AWS Secrets Manager と Amazon RDS を設定するための完全なアクセス許可を持つユーザーとして AWS にサインインできることを前提としています。

• 最後のセクションで説明したように、データベースとユーザーを削除することなく、チュートリアルチュートリアル: AWS データベースのシークレットのローテーション (p. 15) のステップを完了する必要があります。これにより以下が提供されます。• [MyTestDatabaseInstance] というインスタンスで実行される [MyTestDatabase] という Amazon RDS

MySQL データベース。• 管理者のアクセス許可を持つ [adminuser] という名前のマスターユーザー。• [adminuser] の認証情報が保存されている MyTestDatabaseMasterSecret というシークレット。

ステップ 1: データベースとユーザーシークレットのための新しいユーザーを作成する元のチュートリアルでは、Amazon RDS MySQL データベースには単一の管理者のマスターユーザーがいます。また、マスターユーザーの最新の認証情報を取得するために照会できるシークレットもあります。

23



このステップでは、新しい限定されたユーザーを作成し、認証情報をシークレットに保存します。このシークレットは、たとえば、データベースから情報をクエリする必要のあるモバイルアプリで使用できます。ユーザーは、読み取り権限以外のものは必要ありません。

a. AWS CLI と MySQL クライアント (前述のチュートリアルでインストールしたもの) を実行できるコマンドプロンプトを開きます。次のコマンドを実行してマスターシークレットを取得します。次に、そのシークレットを使って MySQL サーバーにサインインします。

$ secret=$(aws secretsmanager get-secret-value --secret-id MyTestDatabaseMasterSecret | jq .SecretString | jq fromjson)$ user=$(echo $secret | jq -r .username)$ password=$(echo $secret | jq -r .password)$ endpoint=$(echo $secret | jq -r .host)$ port=$(echo $secret | jq -r .port)$ mysql -h $endpoint -u $user -P $port -p$password

b. ここで、mysql> プロンプトで以下のコマンドを実行して、制限付きのアクセス許可が付与されている新しいユーザーを作成します。サンプルパスワードを自分のパスワードに置き換え、次のステップで使用します。

mysql> CREATE USER mytestuser IDENTIFIED BY 'ReplaceThisWithASecurePassword';Query OK, 0 rows affected (0.07 sec)

mysql> GRANT SELECT on *.* TO mytestuser;Query OK, 0 rows affected (0.08 sec)

c. Secrets Manager コンソール (https://console.aws.amazon.com/secretsmanager/) を開きます。d. アカウントのシークレットのリストが表示されたページで、[Store new secret] (新しいシークレットの

保存) を選択します｡e. [Create Secret] (シークレットの作成) ページで、[Select secret type] (シークレットタイプの選択) セク

ションの [Credentials for RDS database] (RDS データベース認証情報) を選択します。f. [User name (ユーザー名)] に、ステップ 1b で作成したユーザー名と一致するように mytestuser と入

力します。g. [Password] (パスワード) にステップ 1b で [mytestuser] 用に提供したのと同じパスワードを入力しま

す。h. [Select the encryption key] (暗号化キーの選択) に、[DefaultEncryptionKey] を使用します。i. [Select which RDS database this secret will access (このシークレットがアクセスする RDS データベー

スを選択) ] に、前のチュートリアルで作成したインスタンス [MyTestDatabaseInstance] を選択します。

j. [Next] を選択します。k. [Secret name and description (シークレットの名前と説明)] セクションで、[Secret name (シークレット

名)] に「MyTestDatabaseUserSecret」と入力します。l. [Configure automatic rotation] (自動ローテーションの設定) セクションで、今のところローテーションを

無効のままにしておきます。[Next] を選択します。m.[Review] (レビュー) セクションで詳細を確認し、[Store] (保存) を選択します。

新しいシークレットが含まれるようになったシークレットの一覧に戻ります。

ステップ 2: 最初のシークレットを検証するシークレットを自動的にローテーションするように設定する前に、シークレットに正しい情報があり、データベースに接続できることを確認する必要があります。前のチュートリアルでは、Linux ベースの MySQL クライアントコンポーネントをインストールしました。このチュートリアルでは、引き続きMySQL クライアントを使用します。

24




他のプラットフォームでこのチュートリアルを実行している場合、これらのコマンドはお使いのプラットフォームの同等のコマンドへの変換が必要になる場合があります。少なくとも、AWS CLI または SecretsManager コンソールを使用してシークレットを取得することができます。ユーザー名とパスワードをMySQL データベースクライアントにカットアンドペーストします。

a. シークレットを取得して一時的に保存するコマンドを実行します。

$ secret=$(aws secretsmanager get-secret-value --secret-id MyTestDatabaseUserSecret | jq .SecretString | jq fromjson)$ user=$(echo $secret | jq -r .username)$ password=$(echo $secret | jq -r .password)$ endpoint=$(echo $secret | jq -r .host)$ port=$(echo $secret | jq -r .port)

最初のコマンドで Secrets Manager からシークレットを取得しそれから、SecretString フィールドを JSON レスポンスから抽出して環境変数に保存します。続く各コマンドで、1 つの追加認証情報の一部や接続の詳細を解析して、個別の環境変数に保存します。

b. 解析した詳細を使用してデータベースにアクセスするコマンドを実行します。





mysql>

c. mysql> プロンプトで、シークレットの認証情報を使用してデータベースへの接続を検証するコマンドを実行します。出力の [Current user] (現在のユーザー) がシークレットで指定されたユーザーと一致していることを確認します。



25




d. 次のコマンドを使用して接続を閉じます。

mysql> quitBye

ステップ 3: シークレットのローテーションを設定するシークレットの初期認証情報が検証された後、最初のローテーションを設定し開始できます。

a. Secrets Manager コンソールで、シークレット [MyTestDatabaseUserSecret] を選択します。b. シークレットの詳細ページで、[Rotation configuration] (ローテーション設定) セクションの [Edit

rotation] (ローテーションの編集) を選択します。c. [Edit rotation configuration] (ローテーション設定の編集) ページで、[Enable automatic rotation] (自動

ローテーションを有効化) を選択します。d. [Select rotation interval] (ローテーションの間隔の選択) に、[30 days] (30 日) を選択します。e. [Select which secret will be used to perform the rotation] (このローテーションを実行するために使用され

るシークレットを選択) に、[Use a secret that I have previously stored in AWS Secrets Manager] (AWSシークレットマネージャーで以前に保存したシークレットを使用) を選択します。

f. 表示されたシークレットのリストで、[MyTestDatabaseMasterSecret] を選択します。g. [Save] を選択します。

ローテーション設定が開始されますが、セキュリティ上の目的で 1 つのステップを自分で実行する必要があるため、最初のローテーションは失敗します。

h. ローテーション設定が完了すると、次のメッセージがページの上部に表示されます。

シークレット test/MyTestDatabaseUserSecret が正常に保存され、シークレットのローテーションが有効になっています。ローテーションの設定を終了するには、シークレットのarn:aws:secretsmanager:us-east-1:123456789012:secret:MyTestDatabaseMasterSecret-QZhDKU の値にアクセスするロールのアクセス許可を付与する必要があります。

ロールのポリシーを手動で変更し、マスターシークレットへの GetSecretValue アクセス権限をローテーション関数に付与する必要があります。ローテーションポリシーはマスターシークレットにアクセスできないため、次のステップを完了するまでシークレットのローテーションは失敗し続けます。

i. マスターシークレットの Amazon リソースネーム (ARN) をメッセージからクリップボードにコピーします。

j. メッセージで、role という単語のリンクを選択します。これにより、Secrets Manager が自動的に作成した、Lambda ローテーション関数にアタッチされたロールの詳細ページが IAM コンソールで開きます。

k. [Permissions] (アクセス許可) タブで、[Add inline policy] (インラインポリシーの追加) を選択し、以下の値を設定します。• [Service] (サービス) で、[Secrets Manager] (シークレットマネージャー) を選択します。• [Actions] (アクション) で、[GetSecretValue] を選択します。• [Resources (リソース)] で、[secret (シークレット)] リソースタイプエントリの横に、[Add ARN (ARN

の追加)] を選択します。• [Add ARN(s) (ARN の追加)] ダイアログボックスで、以前にコピーしたマスターシークレットの ARN

を貼り付け、[Add (追加)] を選択します。l. [ポリシーの確認]を選択し、[名前] で「AccessToMasterSecret」と入力します。m.[Create policy] を選択します。

26



Note

前のステップで説明しているようにビジュアルエディタを使用する代わりに、以下のステートメントを既存または新規のポリシーにコピーして貼り付けることができます。

{ "Effect": "Allow", "Action": [ "secretsmanager:GetSecretValue" ], "Resource": "<ARN of the master secret>" }

n. AWS Secrets Manager コンソールに戻ります。o. [Secrets] (シークレット) リストページで、ユーザーシークレットの名前を選択します。p. [Retrieve secret value] (シークレット値の取得) を選択して、現在のパスワードを表示します。シーク

レット値は、元のパスワードか、ローテーションの成功によって作成された新しいパスワードのいずれかである必要があります。元のパスワードが引き続き表示される場合は、[シークレット値] セクションを閉じ、シークレット値が正常に変更されるまで再度開きます。このステップには数分かかる場合があります。変更後、次のステップに進みます。

ステップ 4: 成功したローテーションの確認これでシークレットがローテーションされ、シークレットの新しい認証情報がデータベースに接続することを確認できます。

a. シークレットを取得して、環境変数に一時的に保存するコマンドを実行します。

$ secret=$(aws secretsmanager get-secret-value --secret-id MyTestDatabaseUserSecret | jq .SecretString | jq fromjson)$ user=$(echo $secret | jq -r .username)$ password=$(echo $secret | jq -r .password)$ endpoint=$(echo $secret | jq -r .host)$ port=$(echo $secret | jq -r .port)

b. 以前にインストールしたのと同じ MySQL クライアントを使用して、解析された詳細を使用してデータベースにアクセスするコマンドを実行します。





mysql>

c. mysql> プロンプトで、シークレットの認証情報を使用してデータベースへの接続を検証するコマンドを実行します。出力の [Current user (現在のユーザー)] が、最初のユーザーシークレットで指定されたユーザーまたは _clone のサフィックスが追加された同じユーザー名と一致することを確認します。これは、ローテーションにより元のユーザーのクローンが正常に作成され、新しいバージョンのシークレットに切り替えられたことを示します。


27





d. 次のコマンドを使用して接続を閉じます。

mysql> quitBye

ステップ 5: クリーンアップデータベースとシークレットに AWS 請求書に料金が発生する可能性があるため、このチュートリアルで作成したデータベースインスタンスとシークレットを削除する必要があります。

シークレットの削除

a. Secrets Manager コンソール (https://console.aws.amazon.com/secretsmanager/) を開きます。b. シークレットのリストで、このチュートリアルで作成した [MyTestDatabaseSecret] シークレットを選

択します。c. [Actions] (アクション) を選択してから、[Delete secret] (シークレットの削除) を選択します。d. [Schedule secret deletion (シークレットの削除をスケジュールする)] ダイアログボックスで、[Enter a

waiting period (待機期間の入力)] に可能な最小値、7 を入力します。e. [Schedule deletion] を選択します。

復旧期間の日数が経過すると、Secrets Manager はシークレットを完全に削除します。

データベースインスタンスを削除するには

a. https://console.aws.amazon.com/rds/ にある Amazon RDS コンソールを開きます。b. ナビゲーションペインで、[インスタンス] を選択します。c. 利用可能なインスタンスのリストで、このチュートリアルで作成した [MyTestDatabaseInstance] イン

スタンスを選択します。d. [Instance actions] を選択し、[Delete] を選択します。e. [Delete DB Instance (DB インスタンスの削除)] ページの、[Options (オプション)] セクションで、

[Create final snapshot (最終スナップショットの作成)] に [No (いいえ)] を選択します。f. すべてのデータが失われることの確認を選択し、[削除] を選択します。

28



AWS Secrets Manager ユーザーガイドその他の機密情報の保護

AWS Secrets Manager のベストプラクティス

次の推奨事項は、AWS Secrets Manager をより安全に使用するのに役立ちます。

トピック• その他の機密情報の保護 (p. 29)• AWS 提供のクライアント側キャッシュコンポーネントを使用したパフォーマンス強化 (p. 29)• Lambda 関数のログ記録とデバッグのリスクの軽減 (p. 30)• AWS CLI を使用してシークレットを保存するリスクの軽減 (p. 30)• クロスアカウントアクセス – ユーザー/ロールまたはアカウントを指定する必要があります

か｡ (p. 31)• VPC ですべてを実行する (p. 32)• シークレットにタグ付けする (p. 33)

その他の機密情報の保護シークレットには、ユーザー名とパスワード以外の情報も含まれていることがよくあります。データベース、サービス、またはウェブサイトによっては、機密データを追加することもできます。このデータには、パスワードのヒントや、パスワードの復旧に使用できる質問と答えなどが含まれています。

シークレット内の認証情報にアクセスするために使用される可能性のある情報は、認証情報そのものと同じように安全に保護してください。そのような情報を､シークレットの Description など、暗号化されていない部分に保存しないでください。

代わりに、すべての機密情報は、暗号化されたシークレット値の一部としてSecretString またはSecretBinary フィールドに保存します。シークレットには最大 10240 バイトを保存できます。以下の例に示すとおり、SecretString フィールドでは、テキストは通常 JSON のキーと値のペアの形式をとります。

{ "engine": "mysql", "username": "user1", "password": "i29wwX!%9wFV", "host": "my-database-endpoint.us-east-1.rds.amazonaws.com", "dbname": "myDatabase", "port": "3306"}

AWS 提供のクライアント側キャッシュコンポーネントを使用したパフォーマンス強化

認証情報が必要になるたびに Secrets Manager からシークレット値を取得するだけでは、シークレットを効率的に使用しているとは言えません。そこで、サポートされる Secrets Manager クライアントコンポーネントを使用してシークレットをキャッシュし、ローテーションに必要な場合にのみシークレットを更新します。AWS では、そのようなクライアントコンポーネントを作成し、オープンソースとして提供してい

29

AWS Secrets Manager ユーザーガイドLambda 関数のログ記録とデバッグのリスクの軽減

ます。詳細については、「AWS が開発したオープンソースのクライアント側キャッシングコンポーネントの使用 (p. 65)」を参照してください。

Lambda 関数のログ記録とデバッグのリスクの軽減Secrets Manager シークレットをサポートするためにカスタムの Lambda ローテーション関数を作成するときは、関数にデバッグステートメントまたはロギングステートメントを含めるように注意してください。これらのステートメントは、関数内の情報を CloudWatch に書き込む可能性があります。CloudWatchへのこの情報のロギングに、暗号化されたシークレット値に保存されている機密データが含まれていないことを確認してください。また、開発中にテストおよびデバッグのためにコードにそのようなステートメントを含める場合は、本稼働環境で使用する前にこうした行をコードから必ず削除してください。また、開発中に収集された機密情報を含むログは、不要になった後で忘れずに削除してください。

AWS およびサポートされるデータベース (p. 4)で提供される Lambda 関数には、ロギングおよびデバッグステートメントは含まれません。

AWS CLI を使用してシークレットを保存するリスクの軽減

AWS Command Line Interface (AWS CLI) を使用して AWS オペレーション呼び出す場合は、それらのコマンドをコマンドシェルに入力します。たとえば、Windows コマンドプロンプトや WindowsPowerShell、または Bash や Z シェルなどを使用できます。これらのコマンドシェルの多くには、生産性を向上させるために設計された機能が含まれています。ただし、この機能はシークレットを侵害するために使用される可能性があります。たとえば、ほとんどのシェルでは、上矢印キーを使用して、最後に入力されたコマンドを表示できます。コマンド履歴機能は、セキュリティ保護されていないセッションにアクセスされた場合に、悪用される可能性があります。また、バックグラウンドで動作する他のユーティリティは、タスクをより効率的に実行できるようにする目的でコマンドパラメータにアクセスできます。このようなリスクを軽減するには、次の手順を実行します。

• コンソールから離れるときは、常にコンピュータをロックします。• 要らないまたは使用しなくなったコンソールユーティリティをアンインストールするか無効にします。• シェルまたはリモートアクセスプログラムを使用している場合は、入力したコマンドのログを記録しな

いようにします｡• シェルのコマンド履歴によってキャプチャされないようにパラメータを渡す方法を使用します。次の例

は、シークレットテキストをテキストファイルに入力し、AWS Secrets Manager コマンドに渡してすぐにそのファイルを破棄する方法を示しています。これは、典型的なシェル履歴がシークレットテキストをキャプチャしないことを意味します。

次の例は、典型的な Linux コマンドを示しています (シェルには多少異なるコマンドが必要な場合があります)。

$ touch secret.txt # Creates an empty text file$ chmod go-rx secret.txt # Restricts access to the file to only the user$ cat > secret.txt # Redirects standard input (STDIN) to the text fileThisIsMyTopSecretPassword^Z # Everything the user types from this point up to the CTRL-D (^D) is saved in the file$ aws secretsmanager create-secret --name TestSecret --secret-string file://secret.txt # The Secrets Manager command takes the --secret-string parameter from the contents of the file

30

AWS Secrets Manager ユーザーガイドクロスアカウントアクセス – ユーザー/ロール

またはアカウントを指定する必要がありますか｡

$ shred -u secret.txt # The file is destroyed so it can no longer be accessed.

これらのコマンドを実行した後、上下の矢印を使用してコマンド履歴をスクロールし、シークレットテキストがどの行にも表示されないようにする必要があります。

Important

デフォルトでは、コマンドヒストリバッファのサイズを最初に [1] に減らさないかぎり、Windows で同様のテクニックを実行することはできません。

Windows コマンドプロンプトで 1 コマンドのコマンド履歴バッファのみを使用するように設定するには

1. 管理者コマンドプロンプトを開きます ([Run as administrator (管理者として実行)])。2. 左上にあるアイコンを選択し、[プロパティ] を選択します。3. [オプション] タブで､[バッファサイズ] と [Number of Buffers (バッファ数)] の両方を 1 に設定し、[OK]

を選択します。4. 履歴に入れたくないコマンドを入力する必要がある場合は、直後に次のようなコマンドを 1 つ続けま

す。

echo.

これにより、機密性の高いコマンドがフラッシュされます。

Windows Command Prompt シェルでは､SysInternals SDelete ツールをダウンロードして、次のようなコマンドを使用することができます。

C:\> echo. 2> secret.txt # Creates an empty fileC:\> icacls secret.txt /remove "BUILTIN\Administrators" "NT AUTHORITY/SYSTEM" /inheritance:r # Restricts access to the file to only the ownerC:\> copy con secret.txt /y # Redirects the keyboard to text file, suppressing prompt to overwriteTHIS IS MY TOP SECRET PASSWORD^Z # Everything the user types from this point up to the CTRL-Z (^Z) is saved in the fileC:\> aws secretsmanager create-secret --name TestSecret --secret-string file://secret.txt # The Secrets Manager command takes the --secret-string parameter from the contents of the fileC:\> sdelete secret.txt # The file is destroyed so it can no longer be accessed.

クロスアカウントアクセス – ユーザー/ロールまたはアカウントを指定する必要がありますか｡

シークレットに添付されているリソースベースのポリシーを使用して、別の AWS アカウントの IAM プリンシパルへのアクセスを許可する場合は、次の 2 つのオプションがあります。

• 他のアカウント ID のみを指定する – ステートメントの Principal 要素で、「外部」アカウントルートの Amazon リソースネーム (ARN) を指定します。これにより、外部アカウントの管理者は、外部アカウントの役割へのアクセスを委任できるようになります。管理者は、シークレットへのアクセスを必要とするロールに IAM アクセス許可ポリシーを割り当てる必要があります。

31

https://docs.microsoft.com/en-us/sysinternals/downloads/sdelete

AWS Secrets Manager ユーザーガイドVPC ですべてを実行する

"Principal": {"AWS": arn:aws:iam::AccountId:root}

• 他のアカウントの正確なユーザーまたはロールを指定する – シークレットベースのポリシーのPrincipal として、正確なユーザーまたはロールの ARN を指定します。ARN を他のアカウントの管理者から取得します。アカウント内の特定の単一のユーザーまたはロールのみがリソースにアクセスできます。

"Principal": [ {"AWS": "arn:aws:iam::AccountId:role/MyCrossAccountRole"}, {"AWS": "arn:aws:iam::AccountId:user/MyUserName"}]

ベストプラクティスとして、シークレットベースのポリシーでは、次の理由からアカウントのみを指定することをお勧めします。

• いずれの場合も、他のアカウントの管理者を信頼します。最初のケースでは、管理者が、認可された個人のみが IAM ユーザーにアクセスできる、または指定されたロールを継承できるようにするよう信頼します。これにより、本質的にアカウント ID のみを指定するのと同じレベルの信頼が構築されます。アカウントと管理者を信頼します。アカウント ID のみを指定すると、管理者はユーザーを適切に管理できるようになります。

• 正確なロールを指定すると、IAM は内部的に、ロールをロールに固有の「プリンシパル ID」に変換します。ロールを削除して同じ名前でロールを再作成すると、ロールは新しいプリンシパル ID を取得します。つまり、新しいロールは自動的にリソースへのアクセスを取得しません。IAM は、セキュリティ上の理由からこの機能を提供しますが、誤って削除して復元すると、アクセスが「壊れた」ことになります。

アカウントのルートのみにアクセス許可を与えると、そのアクセス許可により、そのアカウントの管理者がユーザーとロールに委任できるオプションが制限されることになります。管理者は、アカウントにアクセス許可が付与されなかったリソースへのアクセス許可を付与することはできません。

Important

ロールを使用せずにシークレットにクロスアカウントアクセス許可を直接に付与する場合は、カスタム AWS KMS カスタマーマスターキー (CMK) を使用してシークレットを暗号化する必要があります。別のアカウントのプリンシパルには、シークレットとカスタム AWS KMS CMK の両方のアクセス許可が付与されている必要があります。

VPC ですべてを実行する可能な限り、パブリックインターネットからアクセスできないプライベートネットワーク上で、インフラストラクチャの多くを実行する必要があります。これを行うには、Amazon VPC が提供する VirtualPrivate Cloud (VPC) でサーバーとサービスをホストします。AWS は、アカウント内のリソースのみがアクセスできる仮想化されたプライベートネットワークを提供しています。パブリックインターネットは、明示的にアクセス権を設定しないかぎり、表示またはアクセスできません。たとえば、NAT ゲートウェイを追加できます。Amazon VPC の詳細については、「Amazon VPC ユーザーガイド」を参照してください。

VPC 環境内でシークレットローテーションを有効にするには、次のステップを実行します。

1. Lambda ローテーション関数を、そのシークレットがローテーションされているデータベースサーバーまたはサービスと同じ VPC 内で実行するように設定します。詳細については、『AWS Lambda

32

https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/

AWS Secrets Manager ユーザーガイドシークレットにタグ付けする

Developer Guide』の「Amazon VPC 内のリソースにアクセスできるように Lambda 関数を構成する」を参照してください。

2. VPC 内から実行中の Lambda ローテーション関数は、Secrets Manager サービスエンドポイントにアクセスできる必要があります。VPC に直接インターネット接続がない場合は、VPC のすべてのリソースからアクセスできるプライベート Secrets Manager エンドポイントで VPC を設定できます。詳細については、「シークレットの更新をサポートするネットワークの設定 (p. 77)」を参照してください。

シークレットにタグ付けするいくつかの AWS サービスでは、リソースにタグを追加でき、Secrets Manager では、シークレットにタグを付けることができます。Secrets Manager では、タグは、お客様定義のキーとオプションの値で構成される単純なラベルとして定義されます。タグを使用すると、AWS アカウントでリソースの管理、検索、およびフィルタリングを行うことができます。シークレットにタグ付けする場合は、次のガイドラインに従ってください。

• すべてのリソースに標準化された命名規則を使用すること。タグでは大文字と小文字が区別されます。• 以下のことを実行できるようにするタグセットを作成します。

• セキュリティ/アクセスコントロール – シークレットにアタッチされているタグをチェックすることにより、シークレットへのアクセスを許可または拒否できます。

• コストの配分と追跡 – AWS 請求は、タグを使用して、グループ化および分類することができます。詳細については、AWS Billing and Cost Management ユーザーガイドの「コスト配分タグの使用」を参照してください。

• オートメーション – タグを使用して、オートメーションアクティビティのリソースをフィルタリングすることができます。たとえば、一部のお客様は、営業時間外に開発環境をオフにする自動開始/停止スクリプトを実行してコストを削減します。特定の Amazon EC2 インスタンスをシャットダウンの対象に含めるかどうかを示すタグを作成して、このタグをチェックすることができます。

• AWS 管理コンソール – 一部の AWS サービスコンソールでは、表示されているリソースをタグに従って整理したり、タグでソートしてフィルタリングしたりできます。また、AWS には、タグに基づき、リソースを統合して整理するカスタムコンソールを作成するためのリソースグループツールもあります。詳細については、『AWS マネジメントコンソール入門ガイド』の「リソースグループの使用」を参照してください。

タグは、シークレットを管理するために、独自のニーズに合わせて自由に使用できます。ただし、シークレットの機密情報をタグに保存しないようにしてください。

シークレットへのタグ付けは、作成時 (p. 55)または編集時 (p. 59)に行うことができます。

詳細については、『AWS Answers』ウェブサイトの「AWS タグ付け戦略」を参照してください。

33

https://docs.aws.amazon.com/lambda/latest/dg/vpc.html

https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html

https://docs.aws.amazon.com/

https://aws.amazon.com/answers/account-management/aws-tagging-strategies/

AWS Secrets Manager ユーザーガイド概要

AWS Secrets Manager に対する認証とアクセスコントロール

AWS Secrets Manager へのアクセスには、AWS 認証情報が必要です。これらの認証情報には、SecretsManager のシークレットなど、アクセスする AWS リソースにアクセスするためのアクセス許可が含まれている必要があります。次のセクションでは、AWS Identity and Access Management (IAM) ポリシーを使用して、シークレットに安全にアクセスし、アクセスして管理できるユーザーを制御する方法について詳しく説明します。

シークレットには非常に機密性の高い情報が含まれているため、シークレットへのアクセスは厳密に制御する必要があります。AWS および IAM アクセス許可ポリシーのアクセス許可機能を使用すると、シークレットにアクセスできるユーザーまたはサービスを管理できます。承認済みのシークレットでユーザーが実行できる API、CLI、およびコンソールオペレーションを指定できます。IAM ポリシー言語の細分化されたアクセス機能を利用することで、タグをフィルターして使用して、ユーザーをシークレット—のサブセットのみに制限することも、個別のシークレット—に制限することもできます。また、フィルターとしてステージングラベルを使用することで、特定のバージョンのシークレットにユーザーを制限することもできます。

また、シークレットを管理できるユーザーを決定することもできます。シークレットおよび関連するメタデータを更新または変更するユーザーを指定します。AWS Secrets Manager サービスに対する管理者アクセス権限がある場合は、他のユーザーにアクセス許可を付与することで、 Secrets Manager タスクへのアクセスを委任できます。

ユーザー、グループ、ロールにアクセス許可ポリシーをアタッチし、アタッチされた ID がアクセスできるシークレットを指定できます。Secrets Manager では、このプロセスはアイデンティティベースのポリシーと呼ばれています。または、アクセス許可ポリシーをシークレットに直接アタッチして、それに対するアクセスを指定することもできます。Secrets Manager では、このプロセスはリソースベースのポリシーと呼ばれています。どちらの方法でも、これらのポリシーは、各プリンシパルがシークレットに対して実行できるアクションを指定します。

IAM アクセス許可ポリシーに関する一般的な情報については、『IAM ユーザーガイド』の「IAM ポリシーの概要」を参照してください。

AWS Secrets Manager で専用に使用できるアクセス許可については、「AWS Secrets Manager のIAM ポリシー、またはシークレットポリシーで使用できるアクション、リソースおよびコンテキストキー。 (p. 162)」を参照してください。

以下のセクションでは、AWS Secrets Manager のアクセス許可を管理する方法について説明します。最初に概要のセクションを読むことをお勧めします。

• Secrets Manager シークレットへのアクセス許可の管理の概要 (p. 34)• Secrets Manager でアイデンティティベースのポリシー (IAM ポリシー) を使用する (p. 43)• Secrets Manager のリソースベースのポリシーを使用する (p. 49)

Secrets Manager シークレットへのアクセス許可の管理の概要

AWS アカウントは、AWS Secrets Manager に保存するシークレットを含むすべての AWS リソースを所有します。AWS にはリソースを作成またはアクセスするためのアクセス許可ポリシーが含まれています。

34

https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html

AWS Secrets Manager ユーザーガイド認証

アカウント管理者は、リソースやシークレット、またはリソースにアクセスする必要がある IAM アイデンティティ、ユーザー、グループ、ロールにアクセス許可ポリシーを直接アタッチすることによって、AWSリソースへのアクセスを制御できます。

Note

管理者、または管理者ユーザーは、管理者のアクセス許可を持つユーザーです。これは、通常、サービスのすべてのリソースに対してすべてのオペレーションを実行するアクセス許可を持つことを意味します。詳細については、『IAM ユーザーガイド』の「IAM ベストプラクティス」を参照してください。

Secrets Manager のアカウントの管理者は、管理者のアクセス許可を他の IAM ユーザーまたはアカウント内のロールに委任するなどの管理タスクを実行できます。そのためには、IAM ユーザー、グループ、またはロールに IAM アクセス許可ポリシーをアタッチします。デフォルトでは、ユーザーにはアクセス許可がまったくありません。つまり、ユーザーは暗黙的に拒否されます。アタッチしたポリシーによって、暗黙的な拒否は、ユーザーが実行できるアクションや、アクションを実行できるリソースを指定する明示的な許可に上書きされます。このポリシーは、アカウント内のユーザー、グループ、およびロールにアタッチできます｡ロールにアクセス許可が付与されている場合は、組織内の他のアカウントのユーザーがそのロールを引き受けることができます。

トピック• 認証 (p. 35)• アクセスコントロール (認証) (p. 36)

認証AWS では、認証は、アクセスするサービスでユーザーを表すアイデンティティを確立するプロセスとして定義されます。通常、管理者がアイデンティティを割り当てます。ユーザーは、リクエストとともにユーザー名とパスワードなどの認証情報を提供するか、AWS アクセスキーを使用してリクエストを暗号化することによって、アイデンティティにアクセスします。

AWS は、次のタイプのアイデンティティをサポートしています。

• AWS アカウントのルートユーザー – AWS にサインアップするときに、AWS アカウントのメールアドレスとパスワードを入力します。AWS は、この情報をアカウントのルートユーザーの認証情報として使用し、すべての AWS リソースへの完全なアクセス権を提供します。

Important

セキュリティ上の理由から、ルートユーザーの認証情報は、管理者ユーザー (AWS アカウントへの完全なアクセス許可を持つ IAM ユーザー) を作成するためにのみ使用することをお勧めします。その後、この管理者ユーザーを使用して、制限されたジョブまたはロールに固有のアクセス許可を持つ他の IAM ユーザーとロールを作成できます。詳細については、『IAM ユーザーガイド』の「個別の IAM ユーザーの作成 (IAM のベストプラクティス)」および「管理者のユーザーおよびグループの作成」を参照してください。

• IAM ユーザー – IAM ユーザーは、特定のアクセス許可 (Secrets Manager シークレットにアクセスするなど) を持つ、AWS アカウント内のアイデンティティです。IAM のユーザー名とパスワードを使用して、AWS マネジメントコンソール、AWS ディスカッションフォーラム、AWS サポートセンターなどのセキュリティ保護された AWS ウェブページにサインインできます。

ユーザー名とパスワードに加えて、アクセスキーを各ユーザーに作成し、ユーザーが AWS SDK のいずれかまたはコマンドラインツールを通じて、AWS サービスにプログラムでアクセスするようにできます。SDK やコマンドラインツールは、アクセスキーを使って API リクエストに暗号により署名します。AWS ツールを使用しない場合は、API リクエストを自分で署名する必要があります。AWS KMS では、署名バージョン 4 がサポートされています。これは API リクエストを認証するための AWS プロトコルです。API リクエストの認証の詳細については、AWS 全般的なリファレンスの「署名バージョン 4署名プロセス」を参照してください。

35

https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#create-iam-users

https://docs.aws.amazon.com/IAM/latest/UserGuide/getting-started_create-admin-group.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/getting-started_create-admin-group.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html

https://console.aws.amazon.com/

https://forums.aws.amazon.com/

https://console.aws.amazon.com/support/home#/

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html



https://aws.amazon.com/tools/#cli

https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html


AWS Secrets Manager ユーザーガイドアクセスコントロール (認証)

• IAM ロール – 特定のアクセス許可を持つアカウントで IAM ロールを作成できます。IAM ユーザーと同様に、IAM ロールは特定のユーザーに関連付けられません。IAM ロールでは、AWS サービスおよびリソースにプログラムでアクセスする一時的なアクセスキーを取得することができます。AWS ロールは、次のような状況で役立ちます。• フェデレーティッドユーザーアクセス – IAM ユーザーを作成するのではなく、AWS Directory

Service、エンタープライズユーザーディレクトリ、またはウェブアイデンティティプロバイダー(IdP) の既存のユーザーアイデンティティを使用することもできます。このようなユーザーはフェデレーティッドユーザーと呼ばれます。ID プロバイダーは、IAM ロールをフェデレーティッドユーザーに関連付けます。フェデレーティッドユーザーの詳細については、『IAM ユーザーガイド』の「フェデレーティッドユーザーとロール」を参照してください。

• クロスアカウントアクセス – AWS アカウントで IAM ロールを使って、アカウントのリソースへのアクセス許可を別の AWS アカウントに許可できます。この例については、IAM ユーザーガイドの「チュートリアル: AWS アカウント間の IAM ロールを使用したアクセスの委任」を参照してください。

• AWS サービスのアクセス – アカウントで IAM ロールを使用して、アカウントのリソースにアクセスするための AWS サービスのアクセス許可を付与できます。たとえば、Amazon Redshift がお客様に代わって S3 バケットにアクセスし、S3 バケットに保存されたデータを Amazon Redshift クラスターにロードすることを許可するロールを作成できます。詳細については、「IAM ユーザーガイド」の「AWS サービスにアクセス権限を委任するロールの作成」を参照してください。

• EC2 インスタンスで実行されるアプリケーション – インスタンスで実行し、AWS API リクエストを送信するアプリケーションで使用するためのアクセスキーを EC2 インスタンスに保存する代わりに、IAM ロールを使用して、これらのアプリケーション用の一時アクセスキーを提供できます。EC2インスタンスに IAM ロールを割り当てるには、インスタンスプロファイルを作成し、インスタンスを起動するときにプロファイルをアタッチします。インスタンスプロファイルには IAM ロールが含まれ、EC2 インスタンスで実行されるアプリケーションは一時アクセスキーを取得することができます。詳細については、IAM ユーザーガイドの「Amazon EC2 上のアプリケーションに対するロールの使用」を参照してください。

アイデンティティを使用してサインインした後で、アクセス制御および認証を使用して、アイデンティティを通じて実行可能なタスクを確定します。

アクセスコントロール (認証)リクエストを認証する認証情報を持つ有効なアイデンティを持つことができますが、Secrets Manager リソースを作成、管理、または使用する Secrets Manager API リクエストを作成するアクセス許可も必要です。たとえば、シークレットを作成したり、シークレットを管理したり、シークレットを取得したりするなど、タスクの実行にはアクセス許可が必要です。次のセクションでは、Secrets Manager のアクセス許可の管理について説明します。

Secrets Manager ポリシー: リソースとアクションの組み合わせ本セクションでは、Secrets Manager の概念がいかに IAM の同等の概念に対応付けられるかについて説明します。

ポリシーSecrets Manager のアクセス許可は、ほとんどすべての AWS サービスと同様に、アクセス許可ポリシーを作成してアタッチすることによって付与されます。ポリシーには、次の 2 つの基本タイプがあります。

• アイデンティティベースのポリシー – ユーザー、グループ、ロールに直接アタッチされます。ポリシーは、アタッチされたアイデンティティに対して許可されるタスクを指定します。アタッチされたユーザーは、自動的かつ暗黙的にポリシーの Principal になります｡アイデンティティが実行できるActions と、アイデンティティがアクションを実行できる Resources を指定できます。ポリシーを使用すると、次のアクションを実行できます。• アイデンティティと共有する複数のリソースへのアクセスを許可する。

36

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html

https://aws.amazon.com/directoryservice/

https://aws.amazon.com/directoryservice/

http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_access-management.html#intro-access-roles

https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_access-management.html#intro-access-roles

http://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html

http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html

http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html

http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html


• さまざまな Create* オペレーションなど、存在しないリソースの API へのアクセスを制御する。• IAM グループにリソースへのアクセスを許可します｡

• リソースベースのポリシー – リソース (この場合はシークレット) に直接アタッチされます。ポリシーは、シークレットへのアクセスと、ユーザーがシークレットに対して実行するアクションを指定します。アタッチされたシークレットは、自動的かつ暗黙的にポリシーの Resource になります｡シークレットにアクセスする Principals を指定でき、プリンシパルが実行できる Actions を指定できます。ポリシーを使用すると、次のアクションを実行できます。• 複数のプリンシパル (ユーザーまたはロール) に単一のシークレットへのアクセスを許可します。リ

ソースベースのポリシーでは、IAM グループをプリンシパルとして指定することができないことに注意してください。プリンシパルになることができるのはユーザーとロールのみです。

• ポリシーステートメントの Principal 要素にアカウント ID を指定して、他の AWS アカウントのユーザーまたはロールへのアクセスを許可します。リソースベースのポリシーを使用する主な理由の1 つとして、シークレットへの「クロスアカウント」アクセスが必要な場合があります。

どのタイプを使用する必要がありますか｡どちらの機能もかなり重複していますが、どちらかを使用した方がもう一方を使用するよりも明らかに有利なケースがあり、どちらもセキュリティ戦略にうまく取り入れる必要があります。いずれかのポリシータイプが機能する場合は、組織のメンバーが出入りする際にポリシーのメンテナンスを簡略化できるタイプを選択します。

Important

1 つのアカウントの IAM プリンシパルが別のアカウントにあるシークレットにアクセスする場合、そのシークレットは、カスタム AWS KMS カスタマーマスターキー (CMK) を使用して暗号化されている必要があります。アカウントのデフォルトの Secrets Manager CMK で暗号化されたシークレットは、そのアカウント内のプリンシパルによってのみ復号することができます。別のアカウントのプリンシパルには、シークレットとカスタム AWS KMS CMK の両方のアクセス許可が付与されている必要があります。代わりに、ユーザーにクロスアカウントのアクセスを付与して、シークレットと同じアカウントの IAM ロールを引き受けることができます。ロールがシークレットと同じアカウントに存在するため、ロールはアカウントのデフォルトの AWS KMS キーで暗号化されたシークレットにアクセスできます。

リソース

Secrets Manager では、シークレットへのアクセスを制御します。

シークレットにはそれぞれ、一意の Amazon リソースネーム (ARN) が関連付けられています。シークレットへのアクセスは、IAM アクセス許可ポリシーの Resource 要素の ARN を指定することで制御できます。シークレットの ARN の形式は次のとおりです。

arn:aws:secretsmanager:<region>:<account-id>:secret:optional-path/secret-name-6-random-characters

リソース所有権について

AWS アカウントは、誰がリソースを作成したかにかかわらず、アカウントで作成されたリソースを所有します。具体的には、リソース所有者は、リソースの作成リクエストを認証する認証情報を持つルートユーザー、IAM ユーザー、IAM ロールの AWS アカウントです。以下の例では、このしくみを示しています。

• ルートユーザーアカウントとしてサインインしてシークレットを作成すると、AWS アカウントがリソースの所有者になります。

• アカウントで IAM ユーザーを作成し、そのユーザーにシークレットを作成するアクセス許可を付与すると、そのユーザーはシークレットを作成できます。ただし、ユーザーの AWS アカウントがシークレットを所有します。

37


• シークレットを作成するためのアクセス許可を持つ AWS アカウントに IAM ロールを作成する場合は、ロールを引き受けることのできるいずれのユーザーもシークレットを作成できます。シークレットは、ロールを引き受けたユーザーではなく、ロールの AWS アカウントが所有します。

API アクションとオペレーションSecrets Manager はシークレットを扱うための一連のオペレーション (API コールと CLI コマンド) を提供します。これらのオペレーションを使って、シークレットの作成、リスト、アクセス、変更、削除などのアクションを実行できます。これらのオペレーションは、そのオペレーションへのアクセスを許可または拒否するために使用できるポリシーのアクションに対応します。ほとんどの場合、API オペレーションとポリシーで割り当てられるアクションとの間には 1 対 1 の関係があります。オペレーションへのアクセスを制御するには、IAM ポリシーの Action 要素に対応するアクションを指定します。ポリシーで使用される、許可された Secrets Manager アクションのリストについては、「AWS Secrets Managerの IAM ポリシー、またはシークレットポリシーで使用できるアクション、リソースおよびコンテキストキー。 (p. 162)」を参照してください。

• アイデンティティベースのアクセス許可ポリシー Statement で Action 要素と Resource 要素の両方を組み合わせると、実行されたアクションとリソースの両方を制御できます。制限は、アタッチされたポリシーのユーザー、グループ、ロールに適用されます。

• リソースベースのアクセス許可ポリシー Statement で、Action 要素と Principal 要素を組み合わせると、実行可能なアクションと、それらのアクションを実行するユーザー、グループ、ロール (プリンシパル) の両方を制御できます。制限は、ポリシーがアタッチされているシークレットに適用されます。

新しいシークレットを作成するアクセス許可を付与する場合は､ユーザー、グループ、ロールにアタッチされたアイデンティベースのポリシーを使用します。この手法は、同様の方法で複数のシークレットをまとめて管理する場合にも役立ちます。

既存のシークレットにアクセスするアクセス許可を付与する場合は、シークレットにアタッチされているリソースベースのポリシーを使用できます。

ポリシーによるリソースへのアクセスの管理アクセス権限のポリシーでは、誰がどのアクションをどのリソースで実行できるかを記述します。以下のセクションでは、アクセス許可ポリシーの作成に使用できるオプションについて説明します。また、ポリシーを構成する要素と、Secrets Manager に作成できる 2 種類のポリシーについても簡単に説明します。

Note

このセクションでは、Secrets Manager のコンテキストでの IAM の使用について説明しますが、IAM サービスに関する詳細情報は提供しません。完全な IAM のドキュメントについては、「IAM ユーザーガイド」を参照してくださいIAM ポリシー構文の詳細および説明については、『IAM ユーザーガイド』の「AWS IAM ポリシーのリファレンス」を参照してください。

Secrets Manager では、シークレットベースまたはアイデンティティベースのアクセス許可ポリシーを使用することになります。Secrets Manager は、適用されたすべてのポリシーを 1 つにまとめ、大きなポリシーとして処理します。これらのポリシーがどのように相互作用するかは、次の基本的なルール構造によって制御されます。

明示的な拒否 >> 明示的な許可 >> 暗黙的な拒否 (デフォルト)

AWS リソースで AWS オペレーションを実行するリクエストには、次のルールが適用されます。

• 明示的な「拒否」が設定されたポリシーのステートメントが、リクエストアクションとリソースに一致する場合: 明示的な拒否は他のすべてを上書きし、指定されたリソースに対する指定されたアクションをブロックします。

38

https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies.html


• 明示的な「拒否」はないが、明示的な「許可」を持つステートメントがリクエストのアクションとリソースに一致する場合: 明示的な許可が適用され、そのステートメント内のアクションに、そのステートメント内のリソースへのアクセスが許可されます。

• 明示的な「拒否」を持つステートメントがなく、明示的な「許可」を持つステートメントがリクエストのアクションとリソースに一致しない場合: AWS はデフォルトで暗黙的にリクエストを拒否します。

暗黙的な拒否は、明示的な許可で上書きできることを理解することが重要です。明示的な拒否は､上書きできません。

複数のポリシーが適用される場合の有効なアクセス許可

ポリシー A ポリシー B 有効なアクセス許可

許可サイレントアクセスを許可

許可許可アクセスを許可

許可拒否アクセスが拒否される

サイレントサイレントアクセスが拒否される

サイレント許可アクセスを許可

サイレント拒否アクセスが拒否される

拒否サイレントアクセスが拒否される

拒否許可アクセスが拒否される

拒否拒否アクセスが拒否される

ポリシー A およびポリシー B は、ユーザーまたはロールにアタッチされた IAM アイデンティティベースのポリシー、またはそのシークレットにアタッチされたリソースベースのポリシーのいずれかのタイプにすることができます。最初の 2 つのポリシーの有効なアクセス許可 (結果) を取って新しいポリシー A のように扱い、3 つ目のポリシーの結果をポリシー B として追加し、適用される追加のポリシーごとにこれを繰り返すことで、追加のポリシーの効果を含めることができます。

トピック• AWS 管理ポリシー (p. 39)• ポリシーステートメント要素の指定 (p. 40)• アイデンティティベースのポリシー (p. 41)• リソースベースのポリシー (p. 42)

AWS 管理ポリシー

AWS は、AWS によって作成、管理されるスタンドアロンの IAM ポリシーを提供することにより、多くの一般的ユースケースに対応します。これらのマネージドポリシーでは、一般的なユースケースに必要なアクセス許可が付与されるため、必要なアクセス許可を調べる必要がなくなります。詳細については、『IAM ユーザーガイド』の「AWS 管理ポリシー」を参照してください。

Secrets Manager には特定の AWS マネージドポリシーがあり、アカウントのユーザーにアタッチできます。

• SecretsManagerReadWrite – このポリシーは、Secrets Manager を管理する IAM ユーザーとロールにアタッチできます。このポリシーは、Secrets Manager サービスへの完全なアクセス許可を付与し、AWS

39

https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies



KMS、Amazon CloudFront、AWS Serverless Application Repository、AWS Lambda など他のサービスへの制限されたアクセス許可を付与します。

このポリシーは AWS マネジメントコンソールで表示できます。Important

セキュリティ上の理由から、このマネージドポリシーにはローテーションを設定するのに必要な IAM アクセス許可は含まれません。これらのアクセス許可は、明示的に、個別に付与する必要があります。通常、IAMFullAccess 管理ポリシーを Secrets Manager 管理者にアタッチしてローテーションを設定できるようにします。

Secrets Manager チームは AWS マネージドポリシーを管理します。これは、AWS マネージドポリシーを使用する重要な利点となります。ローテーションプロセスが拡張されて追加のアクセス許可を必要とする新しい機能が追加されると、その時点で Secrets Manager はマネージドポリシーにそれらのアクセス許可を追加します。ローテーション関数は自動的に新しいアクセス許可を受け取り、中断することなく正常に動作し続けます。

ポリシーステートメント要素の指定次のセクションでは、Secrets Manager の観点から見た、IAM アクセス許可ポリシーの概要を簡単に説明します。IAM ポリシー構文の詳細については、『IAM ユーザーガイド』の「AWS IAM ポリシーの参照」を参照してください。

Secrets Manager は、何らかの方法でシークレットとやりとりしたり、シークレットを操作したりするための一連の API オペレーションを定義します。これらのオペレーションを実行するためのアクセス許可を付与するために、Secrets Manager は、ポリシーで指定できる、一連の対応するアクション (p. 162)を定義します。たとえば、Secrets Managerは､CreateSecret、GetSecretValue、ListSecrets、RotateSecret などのシークレットで動作するアクションを定義します。

ポリシードキュメントには Version 要素が必要です。使用可能な機能をすべて使用できるように、常に最新のバージョンを使用することをお勧めします。このガイドの執筆時点では、利用可能なバージョンは2012-10-17 (最新バージョン) のみです。

さらに、シークレットのポリシードキュメントには、配列内の 1 つ以上のステートメントを持つ 1 つのStatement 要素が必要です。各ステートメントには最大 6 つの要素があります。

• Sid – (オプション) ステートメント識別子として Sid を使用できます。これは、ステートメントを識別する任意の文字列です。

• Effect – (必須) このキーワードを使用して、ポリシー構文でリソースのアクションを許可するか拒否するかを指定します。リソースへのアクセスを明示的に許可していない場合、アクセスは暗黙的に拒否されます。リソースへのアクセスを明示的に拒否できます。別のポリシーによってアクセス許可が付与されていても、ユーザーが指定されたリソースに対して指定されたアクションを実行できないようにするため、これを行う場合があります。複数のステートメントが重複する場合、ステートメント内の明示的な拒否は、明示的に許可する他のステートメントよりも優先されます。明示的な許可ステートメントは、デフォルトで存在する暗黙的な拒否を上書きします。

• Action – (必須) このキーワードを使用して、許可または拒否するアクションを識別します。これらのアクションは、常にそうであるとは限りませんが、利用可能なオペレーションと 1 対 1 で対応します。たとえば、指定した Effect に応じて、secretsmanager:PutSecretValue では、Secrets Managerの PutSecretValue オペレーションを実行するユーザーのアクセス許可を付与または拒否します。

• Resource – (必須) ユーザー、グループ、またはロールにアタッチされたアイデンティティベースのポリシーでは、このキーワードを使用して、ポリシーステートメントが適用されるリソースの Amazon リソースネーム (ARN) を指定します。ステートメントが特定のリソースへのアクセスを制限しないようにするには、「*」を使用できます。結果のステートメントはアクションのみを制限します。シークレットにアタッチされたリソースベースのポリシーでは、リソースは常に「*」でなければなりません。

• Principal – (リソースベースのポリシーの場合のみ必須) シークレットに直接アタッチされているリソースベースのポリシーの場合は、アクセス許可を受け取るユーザー、ロール、アカウント、サービス、そ

40



https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies.html


の他のエンティティを指定します。この要素は、アイデンティティベースのポリシーでは有効ではありません。アイデンティティベースのポリシーでは、ポリシーがアタッチされたユーザーまたはロールが自動的かつ暗黙的にプリンシパルになります。

• 条件 – (オプション) このキーワードを使用して、ステートメントが「一致」し、適用する Effect に該当する必要がある追加条件を指定します。ポリシー要素の詳細については、「IAM JSON ポリシー要素:条件」を参照してください。

アイデンティティベースのポリシー

ポリシーを IAM アイデンティティにアタッチできます。たとえば、次の操作を実行できます。

• アカウントのユーザーまたはグループにアクセス許可ポリシーをアタッチする – ユーザーにシークレットを作成するためのアクセス許可を付与するには、アクセス許可ポリシーをユーザーまたはユーザーが所属するグループに直接アタッチできます (推奨)。

• ロールにアクセス許可ポリシーをアタッチする – アクセス許可ポリシーを IAM ロールにアタッチして、そのロールを引き受けたすべてのユーザーにシークレットへのアクセスを許可することができます。これには、次のシナリオのユーザーが含まれます。• フェデレーティッドユーザー – IAM 以外のアイデンティティシステムによって認証されたユーザーに

アクセス許可を与えることができます。たとえば、Amazon Cognito を使用してサインインするモバイルアプリユーザーに、IAM ロールを関連付けることができます。ロールは、ロールのアクセス許可ポリシーにあるアクセス許可を持つ、一時的な認証情報をアプリに付与します。これらのアクセス権限には、シークレットへのアクセスが含まれる場合があります。詳細については、『Amazon Cognito開発者ガイド』の「Amazon Cognito とは」を参照してください。

• EC2 インスタンスで実行されているアプリケーション – IAM ロールをインスタンスにアタッチすることで、Amazon EC2 インスタンスで実行されているアプリケーションにアクセス許可を付与できます。インスタンス内のアプリケーションが AWS API を呼び出す場合、インスタンスのメタデータから AWS の一時的な認証情報を取得できます。これらの一時的な認証情報はロールに関連付けられ､ロールのアクセス許可ポリシーによって制限されます。これらのアクセス権限には、シークレットへのアクセスが含まれる場合があります。

• クロスアカウントアクセス – アカウント A の管理者は、異なるアカウント B のユーザーにアクセス許可を付与するロールを作成できます。たとえば、次のようにします。1. アカウント A の管理者は、IAM ロールを作成して、ロールにアクセス許可ポリシーをアタッチしま

す。このポリシーは、アカウント A のシークレットへのアクセスを許可し、シークレットに対してユーザーが実行するアクションを指定します。

2. アカウント A の管理者は、Principal 要素のアカウント B のアカウント ID を識別するロールに信頼ポリシーをアタッチして、そのロールを引き受けるユーザーを指定します。

3. 次に、アカウント B の管理者は、アカウント B の任意のユーザーにアクセス許可を委任して、アカウント A のロールを継承できるようにします。これにより、アカウント B のユーザーは最初のアカウントのシークレットにアクセスできます。

IAM を使用したアクセス許可の委任の詳細については、『IAM ユーザーガイド』の「アクセス管理」を参照してください。

次のポリシー例は、ユーザー、グループ、ロールにアタッチできます。このポリシーにより、影響を受けるユーザーまたはロールが、名前が「TestEnv/」というパスで始まるシークレット上でのみ、アカウントで DescribeSecret および GetSecretValue オペレーションを実行できるようになります。また、このポリシーでは、ステージングラベル AWSCURRENT がアタッチされたシークレットのバージョンのみを取得するようにユーザーまたはロールを制限します。次の例の <region> と <account_id> プレースホルダーを実際の値で置き換えます。

{ "Version": "2012-10-17", "Statement": [ {

41

https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html

https://docs.aws.amazon.com/cognito/latest/developerguide/what-is-amazon-cognito.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/access.html


"Sid" : "Stmt1DescribeSecret", "Effect": "Allow", "Action": [ "secretsmanager:DescribeSecret" ], "Resource": "arn:aws:secretsmanager:<region>:<account_id>:secret:TestEnv/*" }, { "Sid" : "Stmt2GetSecretValue", "Effect": "Allow", "Action": [ "secretsmanager:GetSecretValue" ], "Resource": "arn:aws:secretsmanager:<region>:<account_id>:secret:TestEnv/*", "Condition" : { "ForAnyValue:StringLike" : { "secretsmanager:VersionStage" : "AWSCURRENT" } } } ]}

シークレットのバージョンには複数のステージングラベルを付けることができるので、ポリシーで IAM ポリシー言語のセット演算子を使用して比較する必要があります。前の例では、ForAnyValue:StringLike は、評価されるバージョンのシークレットにアタッチされたステージングラベルのいずれかが文字列「AWSCURRENT」と一致する場合、ステートメントが一致するとし、文字列Effect を適用します。

アイデンティティベースのポリシーの詳細な例については、「Secrets Manager でアイデンティティベースのポリシー (IAM ポリシー) を使用する (p. 43)」を参照してください。ユーザー、グループ、ロール、アクセス権限の詳細については、『IAM ユーザーガイド』の「アイデンティティ (ユーザー、グループ、ロール)」を参照してください。

リソースベースのポリシー

それぞれの Secrets Manager シークレットには、1 つのリソースベースのアクセス許可ポリシー (シークレットポリシー) をアタッチできます。IAM ロールでシークレットのポリシーを使用する代わりに、シークレットのポリシーを使用して、クロスアカウントのアクセス許可を付与できます。たとえば、IAM ロールを作成する代わりに、シークレットポリシーにアクセス許可を追加して、アカウント B のユーザーをPrincipal として識別することにより、アカウント B のユーザーにアカウント A のシークレットにアクセスするためのアクセス許可を付与できます。

次の例では、1 つのステートメントを含む Secrets Manager シークレットポリシーについて説明します。ステートメントでは、123456789012 アカウントの管理者は、そのアカウントのユーザーとロールにアクセス許可を委任できます。このポリシーでは、管理者が委任できるアクセス許可は、「prod/ServerA-a1b2c3」という名前の単一のシークレットの secretsmanager:GetSecretValue アクションに限定されます。この条件では、ユーザーは現在のバージョンのシークレットのみを取得できます。

{ "Version" : "2012-10-17", "Statement" : [ { "Effect": "Allow", "Principal": {"AWS": "arn:aws:iam::123456789012:root" }, "Action": "secretsmanager:GetSecretValue", "Resource": "arn:aws:secretsmanager:<region>:<account_id>:secret:prod/ServerA-a1b2c3", "Condition": { "ForAnyValue:StringEquals": { "secretsmanager:VersionStage" : "AWSCURRENT" } } } ]

42

https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_multi-value-conditions.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html

AWS Secrets Manager ユーザーガイドSecrets Manager でアイデンティティベースのポリシー (IAM ポリシー) を使用する

}

Important

1 つのアカウントの IAM プリンシパルが別のアカウントにあるシークレットにアクセスする場合、そのシークレットはカスタム AWS KMS CMK を使用して暗号化されている必要があります。アカウントのデフォルトの Secrets Manager CMK で暗号化されたシークレットは、そのアカウント内のプリンシパルによってのみ復号することができます。別のアカウントのプリンシパルには、シークレットとカスタム AWS KMS CMK の両方のアクセス許可が付与されている必要があります。代わりに、ユーザーにクロスアカウントのアクセス許可を付与して、シークレットと同じアカウントの IAM ロールを引き受けることができます。ロールがシークレットと同じアカウントに存在するため、ロールはアカウントのデフォルトの AWS KMS キーで暗号化されたシークレットにアクセスできます。

シークレットのバージョンには複数のステージングラベルを付けることができるので、ポリシーで IAM ポリシー言語のセット演算子を使用して比較する必要があります。前の例では、ForAnyValue:StringLike は、評価されるバージョンにアタッチされたラベルのいずれかが「AWSCURRENT」と一致する場合、ステートメントが一致するとし、Effect を適用します。

リソースベースのポリシーと Secrets Manager の詳細な例については、「Secrets Manager のリソースベースのポリシーを使用する (p. 49)」を参照してください。リソースベースのポリシーとは異なる IAMロール (アイデンティティベースのポリシー) の使用の詳細については、IAM ユーザーガイドの「IAM ロールとリソースベースのポリシーとの相違点」を参照してください。

Secrets Manager でアイデンティティベースのポリシー (IAM ポリシー) を使用する

アカウントの管理者として、ユーザー、グループ、ロールなどの IAM アイデンティティにアクセス許可ポリシーをアタッチすることで、アカウントの AWS リソースへのユーザーのアクセスをコントロールできます。アクセス許可を付与するときは、アクセス許可、リソース、それらのリソースに対して許可する特定のアクションを決定します。ロールにアクセス許可を付与した場合は、指定した他のアカウントのユーザーがそのロールを引き受けることができます。

デフォルトでは、ユーザーまたはロールには何もアクセス許可が与えられていません。ポリシーを使用してアクセス許可を明示的に付与する必要があります。明示的にアクセス許可を付与しない場合、アクセス許可は暗黙的に拒否されます。アクセス許可を明示的に拒否すると、許可する他のポリシーはすべて上書きされます。つまり、ユーザーは明示的に付与されたアクセス許可のみを持ち、明示的に拒否されません。

ポリシーの基本要素の概要については、「ポリシーによるリソースへのアクセスの管理 (p. 38)」を参照してください。

トピック• AWSSecrets Manager の管理ポリシー (p. 44)• 完全なシークレットマネージャー管理者アクセス権限をユーザーに付与する (p. 44)• 1 つのシークレットへの読み取りアクセスの付与 (p. 45)• 特定のアクションへのアクセスの制限 (p. 45)• 特定のシークレットへのアクセスの制限 (p. 45)• 特定のステージングラベルまたはタグを持つシークレットへのアクセスを制限する (p. 47)• 別のマスターシークレットへのアクセス権限をローテーション関数に付与する (p. 48)

43


http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_compare-resource-policies.html

http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_compare-resource-policies.html

AWS Secrets Manager ユーザーガイドAWSSecrets Manager の管理ポリシー

AWSSecrets Manager の管理ポリシーAWS Secrets Manager では、アクセス許可を付与しやすいように、次の AWS マネージドポリシーを用意しています。リンクを選択して、IAM コンソールにポリシーを表示します。

• SecretsManagerReadWrite – このポリシーでは、Secrets Manager を管理するために必要なアクセス権が付与されます。ただし、ロールを作成して、ポリシーをそれらのロールにアタッチするために必要なIAM アクセス許可は含まれません。このようなアクセス許可が必要な場合は、IAMFullAccess 管理ポリシーをアタッチします。詳細については、次のセクション「完全なシークレットマネージャー管理者アクセス権限をユーザーに付与する (p. 44)」を参照してください。

完全なシークレットマネージャー管理者アクセス権限をユーザーに付与するSecrets Manager 管理者になるには、いくつかのサービスでアクセス許可を持っている必要があります。ユーザーがシークレットを作成および管理できるようにするエンドユーザーサービスとして SecretsManager を有効にしないことをお勧めします。ローテーションを有効にするために必要なアクセス許可では、標準ユーザーが持つべきではない、かなりのアクセス許可が付与されます。代わりに、信頼できる管理者が Secrets Manager サービスを管理します。エンドユーザーが認証情報を直接処理したり、コードに埋め込んだりすることはなくなりました。

Warning

ローテーションを有効にすると、Secrets Manager は Lambda 関数を作成し、その関数に IAMロールをアタッチします。これには、信頼されたユーザーのみに付与される複数の IAM アクセス許可が必要です。したがって、Secrets Manager の管理ポリシーには、これらの IAM アクセス許可は含まれていません。その代わりに、完全な Secrets Manager 管理者を作成するSecretsManagerReadWrite 管理ポリシーに加えて、IAMFullAccess 管理ポリシーの割り当てを明示的に選択する必要があります。SecretsManagerReadWrite ポリシーのみを持つアクセス権を付与すると、IAM ユーザーはシークレットを作成および管理できますが、そのユーザーはローテーションを有効にするために必要な Lambda ローテーション関数を作成および設定することはできません。

完全な Secrets Manager 管理者アクセス許可をアカウントの IAM ユーザー､グループ､またはロールに付与するには、以下のステップを実行します。この例では、新しいポリシーを作成しません。代わりに、アクセス許可を使用して事前設定された AWS マネージドポリシーをアタッチします。

完全な管理者のアクセス許可を IAM ユーザー、グループ、またはロールに追加するには

1. IAM ポリシーを他の IAM ユーザーにアタッチするアクセス許可を持つユーザーとして、https://console.aws.amazon.com/iam/ の Identity and Access Management (IAM) コンソールにサインインします。

IAM コンソールで [ポリシー] に移動します。2. [Filter Policies: Policy type (ポリシーのフィルタリング : ポリシータイプ)] で、[AWS 管理ポリシー] を

選択し、[検索] ボックスで、ポリシーがリストに表示されるまで SecretsManagerReadWrite と入力します。

3. SecretsManagerReadWrite ポリシー名を選択します。4. [ポリシーアクション] を選択して、[アタッチ] を選択します。5. Secrets Manager 管理者にするユーザー、グループ、ロールの横にあるチェックボックスをオンにし

ます。6. [Attach policy] を選択します。7. ステップ 1～6 を繰り返して IAMFullAccess ポリシーもアタッチします。

44



https://console.aws.amazon.com/iam/


AWS Secrets Manager ユーザーガイド1 つのシークレットへの読み取りアクセスの付与

選択したユーザー、グループ、ロールはすぐに Secrets Manager でタスクの実行を開始できます。

1 つのシークレットへの読み取りアクセスの付与Secrets Manager を使用してシークレットを取得し、使用するアプリケーションを記述する場合、そのアプリケーションには、非常に限られたアクセス許可のセットのみを付与する必要があります。SecretsManager では、認証情報で暗号化されたシークレット値を取得することを許可するアクションのアクセス許可のみが必要です。シークレットの Amazon リソースネーム (ARN) を指定して、アクセスを 1 つのシークレットのみに制限します。

IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。

[ポリシーの作成] を選択し、次のコードを追加します。

{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "secretsmanager:GetSecretValue", "Resource": "<arn-of-the-secret-the-app-needs-to-access>" }}

IAM ポリシーで割り当てることができるすべてのアクセス許可のリストについては、「AWS SecretsManager の IAM ポリシー、またはシークレットポリシーで使用できるアクション、リソースおよびコンテキストキー。 (p. 162)」を参照してください。

特定のアクションへのアクセスの制限完全なアクセス許可ではなく制限されたアクセス許可を付与する場合は、IAM アクセス許可ポリシーのAction 要素で許可する個々のアクセス許可をリストするポリシーを作成できます。次の例に示すように、ワイルドカード文字 (*) を使用して Describe*、Get*、List* のアクセス許可のみを付与することができます。これは、基本的にシークレットに読み取り専用アクセスを提供します。



{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": [ "secretsmanager:Describe*", "secretsmanager:Get*", "secretsmanager:List*" ], "Resource": "*" }}

IAM ポリシーで割り当てることができるすべてのアクセス許可のリストについては、「AWS SecretsManager の IAM ポリシー、またはシークレットポリシーで使用できるアクション、リソースおよびコンテキストキー。 (p. 162)」を参照してください。

特定のシークレットへのアクセスの制限特定のアクションへのアクセスの制限に加えて、アカウントの特定のシークレットへのアクセスを制限することもできます。前の例の Resource 要素は、すべてワイルドカード文字 (*) を指定しています。つま

45



AWS Secrets Manager ユーザーガイド特定のシークレットへのアクセスの制限

り、「このアクションがやりとりできる任意のリソース」を意味します。代わりに、「*」をアクセスを許可する特定のシークレットの ARN で置き換えることができます。

Example 例: 名前により単一のシークレットにアクセス許可を付与する

次のポリシーの最初のステートメントは、アカウントのすべてのシークレットに関するメタデータへの読み取りアクセス許可をユーザーに付与します。ただし、2 番目のステートメントでは、ユーザーに、名前、またはちょうど 6 文字に続く「another_secret_name-」文字列で始まるシークレットのいずれかで指定された単一のシークレットの Secrets Manager アクションの実行を許可します。



{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "secretsmanager:DescribeSecret", "secretsmanager:List*" ], "Resource": "*" }, { "Effect": "Allow", "Action": "secretsmanager:*", "Resource": [ "arn:aws:secretsmanager:<region>:<account-id-number>:secret:a_specific_secret_name-a1b2c3", "arn:aws:secretsmanager:<region>:<account-id-number>:secret:another_secret_name-??????" ] } ]}

Secrets Manager によって割り当てられた 6 つのランダムな文字に一致するように「??????」をワイルドカードとして使用すると、「*」ワイルドカードを使用した場合に発生する問題を回避できます。「another_secret_name-*」構文を使用した場合、Secrets Manager は、意図した 6 つのランダムの文字があるシークレットだけでなく、「another_secret_name-<anything-here>a1b2c3」もマッチします。「??????」構文を使用すると、まだ存在していないシークレットに安全にアクセス許可を付与できます。これは、ARN の 6 つのランダムな文字以外のすべての部分を予測できるためです。ただし、シークレットを削除して同じ名前で再作成すると、6 つの文字が変更されたにもかかわらず、ユーザーが自動的に新しいシークレットへのアクセス許可を受け取ることに注意してください。

Secrets Manager コンソール (シークレットについては [詳細] ページ)、または List* API を呼び出すことによって､シークレットの ARN を取得します。このポリシーを適用するユーザーまたはグループは、この例の ARN で識別される 2 つのシークレットに対してのみ任意のアクション ("secretsmanager:*") を実行できます。

リージョン、またはシークレットを所有するアカウントを区別しない場合は、フィールドを空にするのではなく、リージョンおよび ARN のアカウント ID 番号フィールドに、ワイルドカード文字 * を指定する必要があります。

さまざまなリソースの ARN の詳細については、「IAM ポリシーまたはシークレットポリシーで参照可能なリソース (p. 165)」を参照してください。

46


AWS Secrets Manager ユーザーガイド特定のステージングラベルまたはタグを

持つシークレットへのアクセスを制限する

特定のステージングラベルまたはタグを持つシークレットへのアクセスを制限する前の例では、名前または ARN だけで､明示的にアクション、リソース、プリンシパルを呼び出しました。特定のタグキーと値、または特定のラベルを持つシークレットを含むメタデータを持つシークレットのみを含めるように、アクセスを絞り込むこともできます。

例: 特定のタグキーと値を持つメタデータを含むシークレットにアクセス許可を付与する

次のポリシーでは、ユーザー、グループ、またはロールにアタッチされた場合、ユーザーは、メタデータにキー「ServerName」と値「ServerABC」を持つタグが含まれている現在のアカウントのシークレットで、DescribeSecret を実行できます。



{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "secretsmanager:DescribeSecret", "Resource": "*", "Condition": { "StringEquals": { "secretsmanager:ResourceTag/ServerName": "ServerABC" } } } ]}

例: 特定のステージングラベルを持つシークレットのバージョンにアクセス許可を付与する

次のポリシーでは、ユーザー、グループ、またはロールにアタッチされた場合、ユーザーは、Prod で始まる名前のシークレットに対して GetSecretValue を使用できます。AWSCURRENTというステージングラベルがアタッチされたバージョンのみが対象です。



{ "Policy": { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "secretsmanager:GetSecret", "Resource": "arn:aws:secretsmanager:*:*:secret:Prod*", "Condition": { "ForAnyValue:StringEquals": { "secretsmanager:VersionStage": "AWSCURRENT" } } } ] }}

シークレットのバージョンには複数のステージングラベルをアタッチできるため、IAM ポリシー言語のセット演算子を使用して比較する必要があります。前の例では、ForAnyValue:StringLike は、評価されるバージョンにアタッチされたステージングラベルのいずれかが文字列 AWSCURRENT と一致する場合、ステートメントが一致するとし、Effect を適用します。

47





AWS Secrets Manager ユーザーガイド別のマスターシークレットへのアクセ

ス権限をローテーション関数に付与する

別のマスターシークレットへのアクセス権限をローテーション関数に付与するコンソールまたは AWS CLI コマンドを使用して、提供された AWS Serverless Application Repository テンプレートで Lambda ローテーション関数を作成した場合、関数のロールにアタッチされたデフォルトのポリシーが関数のアクションを制御します。デフォルトでは、このポリシーは、シークレットのローテーション関数として設定されたこの Lambda 関数を持つシークレットのみにアクセス許可を付与します。

シークレット内の認証情報で、セキュリティで保護されたデータベースまたはサービスでパスワードを変更するアクセス許可がユーザーに付与されていない場合、ローテーション中にこのシークレット認証情報を変更するには、昇格したアクセス許可 (スーパーユーザー) を持つ別の認証情報セットを使用する必要があります。Secrets Manager は、スーパーユーザーの認証情報を別の「マスター」シークレットに保存します。次に、シークレットを更新するときに、Lambda ローテーション関数はマスター認証情報でデータベースまたはサービスにサインインし、シークレットの認証情報を変更または更新します。この戦略を実装することを選択した場合、メインのシークレットに加えて、このマスターシークレットへのアクセス権を付与する、関数にアタッチされたロールポリシーにステートメントを追加する必要があります。

コンソールを使用して、マスターシークレットを使用する戦略でローテーションを設定する場合、シークレットのローテーションを設定するときに、マスターシークレットを選択することができます。

Important

コンソールでマスターシークレットがこれを選択できるようにするには、GetSecretValue アクセス許可が必要です。

コンソールでローテーションの設定を完了したら、次のステップを手動で実行して、マスターシークレットへのアクセス権を Lambda 関数に付与します。

Lambda ローテーション関数にマスターシークレットへのアクセス権を付与するには

以下のいずれかのタブのステップに従ってください。

Using the console

1. ローテーションを有効にしてシークレットの作成を終了するか、シークレットを編集してローテーションを有効にすると、コンソールには以下のようなメッセージが表示されます。

Your secret MyNewSecret has been successfully stored [and secret rotation is enabled].To finish configuring rotation, you need to grant the role MyLambdaFunctionRole permission to retrieve the secret <ARN of master secret>.

2. メッセージのマスターシークレットの ARN をクリップボードにコピーします。これは、後のステップで使用します。

3. 前のメッセージのロール名は、IAM コンソールへのリンクであり、そのロールに直接移動できます。このリンクを選択します。

4. [アクセス許可] タブに、1 つまたは 2 つのインラインポリシーがあります。Secrets Managerは 1 つに SecretsManager<Name of Template>0 と名前を付けます。テンプレートには、ローテーション関数と保護されたサービスの両方が VPC で実行されていて、インターネットから直接アクセスできない場合に必要となる EC2 関連のアクセス許可が含まれています。SecretsManager<Name of Template>1 と呼ばれるもう 1 つのテンプレートは、ローテーション関数に Secrets Manager オペレーションの呼び出しを許可するアクセス許可が含まれています。ポリシーの左にある矢印を選択してそのアクセス許可を調べ、ポリシー (「1」で終わるポリシー) を開きます。

5. [ポリシーの編集] を選択し、次のいずれかのタブのステップを実行します。

48

AWS Secrets Manager ユーザーガイドSecrets Manager のリソースベースのポリシーを使用する

Using the IAM Visual Editor

[ビジュアルエディタ] タブで、[さらにアクセス許可を追加する] を選択し、以下の値を設定します。• [Service] (サービス) で、[Secrets Manager] (シークレットマネージャー) を選択します。• [Actions] (アクション) で、[GetSecretValue] を選択します。• [Resources (リソース)] で、[secret (シークレット)] リソースタイプエントリの横に、[Add

ARN (ARN の追加)] を選択します。• [Add ARN(s) (ARN の追加)] ダイアログボックスで、以前にコピーしたマスターシークレット

の ARN を貼り付けます。Using the JSON editor

[JSON] タブで、スクリプトの先頭を調べます。行 3 ("Statement": [) と行 4 ( { ) の間に、次の行を入力します。

{ "Action": "secretsmanager:GetSecretValue", "Resource": "arn:aws:secretsmanager:region:123456789012:secret:MyDatabaseMasterSecret", "Effect": "Allow" },

6. ポリシーの編集が終了したら、[ポリシーの確認] を選択し、[変更の保存] を選択します。7. これで IAM コンソールを閉じ、Secrets Manager コンソールに戻ることができます。

Secrets Manager のリソースベースのポリシーを使用する

AWS Secrets Manager のシークレットへのアクセスは、シークレットリソースベースのポリシーを使用して制御します。AWS は、Secrets Manager のリソースとしてシークレットを定義します。アカウント管理者は、AWS サービス内のリソースへのアクセスを制御します。アクセス許可は、シークレットにアタッチされたポリシーに追加できます。Secrets Manager は、リソースベースのポリシーとしてシークレットに直接アタッチされているアクセス許可ポリシーを参照します。リソースベースのポリシーを使用して、シークレットアクセスおよび管理アクセス許可を管理できます。

アイデンティティベースのポリシーよりもリソースベースのポリシーが優れている点は、リソースベースのポリシーでは、別のアカウントからプリンシパルへのアクセスを許可できることです。次のセクションの 2 番目の例を参照してください。

ポリシーの基本要素の概要については、「ポリシーによるリソースへのアクセスの管理 (p. 38)」を参照してください。

アイデンティティベースのアクセス許可ポリシーに代わる方法の詳細については、「Secrets Manager でアイデンティティベースのポリシー (IAM ポリシー) を使用する (p. 43)」を参照してください。

トピック• プリンシパルのシークレットへのアクセスの制御 (p. 49)• ロールへの読み取り専用アクセスの付与 (p. 50)

プリンシパルのシークレットへのアクセスの制御シークレットに直接 Secrets Manager がアタッチされたリソースベースのポリシーを使用すると、Resource は自動的かつ暗黙的に、そのポリシーがアタッチされたシークレットになります。これ

49

AWS Secrets Manager ユーザーガイドロールへの読み取り専用アクセスの付与

で、Principal 要素を指定できるようになりました。Principal 要素により、どの IAM ユーザー、グループ、ロール、アカウント、または AWS サービスプリンシパルがこのシークレットにアクセスできるか、およびこのシークレットに対して実行できるアクションを指定できます。Principal を指定するさまざまな方法の詳細については、『IAM ユーザーガイド』の「プリンシパル」を参照してください。

例: 同じアカウントのユーザーにシークレットとしてアクセス許可を付与する

次のポリシーは、(メタデータの一部として) シークレットに直接アタッチされている場合、そのシークレットに対して Secrets Manager オペレーションを実行する Anaya のアクセス許可をユーザーに付与します。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "secretsmanager:*", "Principal": {"AWS": "arn:aws:iam::123456789012:user/anaya"}, "Resource": "*" } ]}

例: 別のアカウントの承認済ユーザーにアクセス許可を付与する

次のポリシーは、メタデータの一部としてシークレットに直接アタッチされると、特定のシークレットの任意のバージョンを読み取るためのアクセス許可をアカウント 123456789012 の IAM ユーザー Mateo に付与します。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": {"AWS": "arn:aws:iam::123456789012:user/mateo" }, "Action": "secretsmanager:GetSecretValue", "Resource": "*" } ]}

ロールへの読み取り専用アクセスの付与一般的な Secrets Manager のシナリオは、Amazon EC2 インスタンスで実行されているアプリケーションで、必要なタスクを実行するためにデータベースにアクセスする必要がある場合です。アプリケーションは､Secrets Manager からデータベースの認証情報を取得する必要があります。他の AWS サービスと同様に、Secrets Manager にリクエストを送信するには、リクエストを実行するためのアクセス許可を持つAWS 認証情報が必要です。これを実現するには、EC2 インスタンスプロファイルにアタッチされた IAMロールを作成します。詳細については、Linux インスタンス用 Amazon EC2 ユーザーガイドの「AmazonEC2 の IAM ロール」、特に「インスタンスメタデータからセキュリティ認証情報を取得する」のセクションを参照してください。

次の例のリソースベースのポリシーをシークレットにアタッチすると、リクエスタがそのロールに関連付けられた認証情報を使用していて、リクエストの対象がシークレットの現在のバージョンのみである場合に限り、シークレットの検索リクエストが機能します。

{ "Version" : "2012-10-17",

50

https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#Principal

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#instance-metadata-security-credentials

AWS Secrets Manager ユーザーガイドシークレットへのアクセスを判断する

"Statement" : [ { "Effect": "Allow", "Principal": {"AWS": "arn:aws:iam::123456789012:role/EC2RoleToAccessSecrets"}, "Action": "secretsmanager:GetSecretValue", "Resource": "*", "Condition": { "ForAnyValue:StringEquals": { "secretsmanager:VersionStage" : "AWSCURRENT" } } } ]}

シークレットへのアクセスを判断するAWS Secrets Manager のシークレットへアクセスできるユーザーの全範囲を明らかにするには、シークレットのポリシー (存在する場合)、および IAM ユーザーとそのグループ、または IAM ロールのいずれかにアタッチされているすべての AWS Identity and Access Management (IAM) ポリシーの両方を確認する必要があります。これらを確認することで、潜在的なシークレットの使用範囲を明らかにしたり、コンプライアンスや監査の要件を満たしたりできます。次のトピックは、現在シークレットにアクセスできる AWSプリンシパルおよびアイデンティティの完全なリストを作成するのに役立ちます。

トピック• ポリシーの評価について (p. 51)• リソースポリシーの確認 (p. 52)• IAM ポリシーの確認 (p. 53)

ポリシーの評価についてシークレットへのアクセスを許可するとき、Secrets Manager はシークレットにアタッチされたシークレットポリシー、およびリクエストを行っている IAM ユーザーまたはリクエストを送信するロールにアタッチされたすべての IAM ポリシーを評価します。これを行うために、Secrets Manager は IAM ユーザーガイドの「アカウント内でのリクエストの許可または拒否の決定」で説明されたものと類似したプロセスを使用します。

たとえば、同じ AWS アカウントに 2 つのシークレットと 3 人のユーザーがあるとします。シークレットとユーザーには次のポリシーがあります。

• シークレット 1 にはシークレットポリシーがありません。• シークレット 2 には、ユーザープリンシパル Ana と Carlos へのアクセスを許可するシークレットポリ

シーがあります。• Ana には Secret 1 または Secret 2 を参照する IAM ポリシーがありません。• Bob の IAM ポリシーでは、すべてのシークレットに対してすべての Secrets Manager アクションが許可

されます。• Carlos の IAM ポリシーでは、すべてのシークレットに対してすべての Secrets Manager アクションが

拒否されます。

Secrets Manager は、次のアクセスを決定します。

• Ana は、シークレット 2 にのみアクセスできます。彼女のユーザーにアタッチするポリシーはありませんが、シークレット 2 は彼女に明示的にアクセス権を付与します。

51

https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html#policy-eval-denyallow

AWS Secrets Manager ユーザーガイドリソースポリシーの確認

• Bob はアカウント内のすべてのシークレットにアクセスを許可する IAM ポリシーを持っているためにシークレット 1 とシークレット 2 両方へアクセスでき、それを上書きする明示的な「拒否」はありません。

• Carlos はIAM ポリシーのすべてのアクションが Secrets Manager によって拒否されているため、シークレット 1 またはシークレット 2 にアクセスできません。Carlos の IAM ポリシーでの明示的な拒否は、シークレット 2 にアタッチされたシークレットポリシーの明示的な「許可」に優先されます。

Secrets Manager は、アクセスを「許可」するシークレットまたはアイデンティティからのすべてのポリシーステートメントを追加します。すべての明示的な拒否は、重複するアクションとリソースへの許可を上書きします。

リソースポリシーの確認シークレットにアタッチされたポリシードキュメントのシークレットは、GetResourcePolicy オペレーションを使用して、ResourcePolicy レスポンス要素を調べることで表示できます｡

リソースポリシードキュメントを確認し、各ポリシーステートメントの Principal 要素で指定されているすべてのプリンシパルを記録します。Principal 要素の IAM ユーザー、IAM ロール、AWS アカウントは、すべてこのシークレットにアクセスできます。

ポリシーステートメント 1 の例

{ "Sid": "Allow users or roles in account 123456789012 who are delegated access by that account's administrator to have read access to the secret", "Effect": "Allow", "Principal": {"AWS": "arn:aws:iam::123456789012:root"}, "Action": [ "secretsmanager:List*", "secretsmanager:Describe*", "secretsmanager:Get*" ], "Resource": "*"}

前述のポリシーステートメントでは、arn:aws:iam::111122223333:root は AWS アカウント111122223333 を指し、そのアカウントの管理者はそのアカウントのすべてのユーザーまたはロールへのアクセスを許可できます。

プリンシパルとしてリストされたすべての AWS アカウントのすべての IAM のポリシーを確認することで、シークレットにアクセスできるかどうかを判断します。


{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "secretsmanager:*", "Principal": {"AWS": "arn:aws:iam::123456789012:user/anaya"}, "Resource": "*" } ]}

前述のポリシーのステートメントでは、arn:aws:iam::111122223333:user/anaya は、AWS アカウント 111122223333 の Anaya という名前の IAM ユーザーを表します。このユーザーはすべての SecretsManager アクションを実行できます。

52

https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetResourcePolicy.html

https://docs.aws.amazon.com/kms/latest/developerguide/determining-access.html#determining-access-iam-policies

AWS Secrets Manager ユーザーガイドIAM ポリシーの確認


{ "Sid": "Allow an app associated with an &IAM; role to only read the current version of a secret", "Effect": "Allow", "Principal": {"AWS": "arn:aws:iam::123456789012:role/EncryptionApp" }, "Action": ["secretsmanager:GetSecretValue"], "Condition": { "ForAnyValue:StringEquals": {"secretsmanager:VersionStage": "AWSCURRENT" } }, "Resource": "*"}

前述のポリシーステートメントでは、arn:aws:iam::123456789012:role/EncryptionAppは、AWS アカウント 123456789012 の EncryptionApp という名前の IAM ロールを表します。このロールを引き受けるプリンシパルは、ポリシーステートメントに示されている 1 つのアクションを実行できます。このアクションは、現在のバージョンのシークレットの詳細を取得します。

シークレットポリシードキュメントでプリンシパルを指定するさまざまな方法を学習するには、IAM ユーザーガイドの「ポリシーでのプリンシパルの指定」を参照してください。

Secrets Manager シークレットポリシーの詳細については、「リソースベースのポリシー (p. 42)」を参照してください。

IAM ポリシーの確認シークレットポリシーに加え、シークレットポリシーと組み合わせた IAM ポリシーを使用して、シークレットへのアクセスを許可することもできます。IAM ポリシーとシークレットポリシーの動作の詳細については、「ポリシーの評価について (p. 51)」を参照してください。

IAM のポリシーからシークレットに現在アクセスできるアイデンティティを明らかにするには、ブラウザベースの IAM Policy Simulator ツールを使用するか、または IAM Policy Simulator API へのリクエストを送信できます。

ポリシーの効果の確認


Using the web-based Policy Simulator

IAM Policy Simulator を使用して、IAM ポリシーからシークレットにアクセスできるプリンシパルを容易に確認できます。

1. AWS マネジメントコンソールにサインインし、IAM Policy Simulator (https://policysim.aws.amazon.com/) を開きます。

2. [Users, Groups, and Roles (ユーザー、グループ、およびロール)] ペインで、ポリシーをシミュレートするユーザー、グループ、またはロールを選択します。

3. (オプション) シミュレーションから除外するポリシーの横にあるチェックボックスをオフにします。すべてのポリシーをシミュレートする場合は、すべてのポリシーが選択された状態にします。

4. [Policy Simulator] ペインで、以下の操作を行います。a. [サービスの選択] で、「AWS Secrets Manager」を選択します。b. 特定の Secrets Manager アクションをシミュレートするには、[Select actions] でシミュレートす

るアクションを選択します。すべての Secrets Manager アクションをシミュレートする場合は、[Select All] を選択します。

5. (オプション) Policy Simulator は、デフォルトですべてのシークレットにアクセスします。特定のシークレットへのアクセスをシミュレートするには、[Simulation Settings (シミュレーションの設

53

https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#Principal_specifying

https://policysim.aws.amazon.com/



AWS Secrets Manager ユーザーガイドIAM ポリシーの確認

定)] を選択した後、シミュレートするシークレットの Amazon リソースネーム (ARN) を入力します。

6. [Run Simulation] を選択します。

シミュレーションの結果は、[Results] セクションに表示されます。AWS アカウントのすべての IAMユーザー、グループ、ロールについて、ステップ 2 ～ 6 を繰り返します。

Using the Policy Simulator CLI or SDK operations

IAM API を使用すると、IAM のポリシーをプログラムで確認できます。次のステップは、API でユーザーベースのポリシーを確認する方法の概要を示します。

1. シークレットポリシーにプリンシパルとしてリストされた AWS アカウント ("Principal":{"AWS": "arn:aws:iam::accountnumber:root"} の形式でリストされている各ルートユーザーアカウント) については、IAM API の ListUsers および ListRoles オペレーションを使用して、アカウントの各 IAM ユーザーおよびロールのリストを取得します。

2. リスト内の各 IAM ユーザーとロールについて、IAM API の SimulatePrincipalPolicy オペレーションを使用して以下のパラメータを送信します。• PolicySourceArn について、リストのユーザーやロールから ARN を指定します。各SimulatePrincipalPolicy API リクエストで指定できる PolicySourceArn は 1 つだけです。そのため、API を複数回呼び出す必要があります (リストの各 IAM ユーザーとロールで 1 回ずつ)。

• ActionNames のリストについて、シミュレートするすべての Secrets Manager API アクションを指定します。すべての Secrets Manager API アクションをシミュレートするには、secretsmanager:* を使用します。Secrets Manager API アクションを個別にテストするには、各 API アクションを「例: secretsmanager: —secretsmanager:ListSecrets」で実行します。すべての Secrets Manager API アクションの完全なリストについては、『AWS KeyManagement Service API リファレンス』の「アクション」を参照してください。

• (オプション) IAM ユーザーやロールが特定のシークレットにアクセスできるかどうかを判断するために、ResourceArns パラメータを使用してシークレットの (ARN) のリストを指定します。IAM ユーザーやロールがシークレットにアクセスできるかどうかを判断するためにResourceArns パラメータを使用しないでください。

IAM は、各 SimulatePrincipalPolicy API リクエストに評価決定としてallowed、explicitDeny、または implicitDeny を返します。allowed の評価決定を含む各レスポンスには、許可された特定の Secrets Manager API アクションの名前と、評価に使用されたシークレットの ARN が含まれます (該当する場合)。

54

https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListUsers.html

https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListRoles.html

https://docs.aws.amazon.com/IAM/latest/APIReference/API_SimulatePrincipalPolicy.html

https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_Operations.html

AWS Secrets Manager ユーザーガイド基本的なシークレットを作成する

AWS Secrets Manager によるシークレットの作成と管理

このセクションでは、AWS Secrets Manager を使用してシークレットを作成、更新、検索する方法を説明します。

トピック• 基本的なシークレットを作成する (p. 55)• シークレットの変更 (p. 59)• シークレット値の取得 (p. 64)• シークレットの削除と復元 (p. 66)• シークレットのリソースベースのポリシーを管理する (p. 70)

基本的なシークレットを作成するAWS Secrets Manager を使用すると、最小限の労力で基本的なシークレットを保存することができます。基本的なシークレットは、最低限のメタデータと 1 つの暗号化されたシークレット値で構成されます。Secrets Manager ではシークレットを保存し、AWSCURRENT を使用してそのシークレットに自動的にラベルを付けます。

基本的なシークレットを作成する


Using the Secrets Manager console

最小限必要なアクセス権限

コンソールでシークレットを作成するには次のアクセス許可が必要です。

• [SecretsManagerReadWrite] AWS マネージドポリシーによって付与されるアクセス許可。• [IAMFullAccess] AWS マネージドポリシーによって付与されたアクセス許可 – シークレッ

トのローテーションを有効にする必要がある場合のみ。• kms:CreateKey – Secrets Manager にカスタム AWS KMS カスタマーマスターキー

(CMK) の作成を依頼する必要がある場合のみ。• kms:Encrypt – アカウントのデフォルトの Secrets Manager CMK の代わりにカスタム

AWS KMS キーを使用してシークレットを暗号化する場合のみ。Secrets Manager にアカウントのデフォルトの AWS マネージド CMK を使用する場合、このアクセス許可は必要ありません。

• kms:Decrypt – アカウントのデフォルトの Secrets Manager CMK の代わりにカスタムAWS KMS キーを使用してシークレットを暗号化する場合のみ。Secrets Manager にアカウントのデフォルトの AWS マネージド CMK を使用する場合、このアクセス許可は必要ありません。

• kms:GenerateDataKey – アカウントのデフォルトの Secrets Manager CMK の代わりにカスタム AWS KMS キーを使用してシークレットを暗号化する場合のみ。SecretsManager にアカウントのデフォルトの AWS マネージド CMK を使用する場合、このアクセス許可は必要ありません。

55



2. [新しいシークレットの保存] を選択します｡3. [シークレットタイプの選択] セクションで、次のいずれかのオプションを選択して、作成するシー

クレットのタイプを指定します。次に、必要な情報を入力します。4. [シークレット名] に､オプションのパスと名前 (例: production/MyAwesomeAppSecret または

development/TestSecret) を入力します｡スラッシュ文字を使用すると、デプロイ環境別にグループ化するなど、シークレットを階層に構造化できます。これは、シークレットを大規模に整理および管理する場合に便利な場合があります。オプションで説明を追加して、このシークレットを思い出すのに役立てることもできます。

シークレット名に使用できるのは、ASCII 文字、数字、または次の記号のみです: /_+=.@-

Note

Systems Manager パラメータストアにシークレットを追加する場合は、ディレクトリ構造にスラッシュを追加する必要があります。詳細については、AWS Systems Manager ドキュメントの「パラメータを階層に編成」を参照してください。

5. (オプション) [タグ] セクションで、1 つ以上のタグをシークレットに追加することができます。タグは、お客様が定義するキーと値で構成されます。タグは、AWS リソースの管理に役立ちます。リソースを組織の構造に関連付けるタグ (例: Key="Department"、Value="Accounting") を作成できます。これは、コストの配分と追跡に役立ちます。タグは、タグを使用するアプリケーションごとに、グループリソースにまとめて割り当てることができます (Key="AppName" および Value="HRDatabase)。タグを作成する用途は問いません。シークレットのように、各リソースには複数のタグを付けることができます。詳細については、『AWS Answers』ウェブサイトの「AWS タグ付け戦略」を参照してください。

Important

シークレットに関する機密情報はタグに保存しないでください。機密情報は、情報が暗号化によって保護されているシークレットのシークレット値 (SecretString フィールドまたは SecretBinary フィールド) にのみ保存します。

6. [名前]、[説明]、[タグ] を指定したら、[次へ] を選択します。7. (オプション) この時点で、シークレットのローテーションを設定することができます。ここで

はローテーションのない「基本的」なシークレットが作成されたため、オプションを [Disableautomatic rotation (自動ローテーションを無効化)] のままにして [Next (次へ)] を選択します。

新規または既存のシークレットでのローテーションの設定については、「AWS Secrets Managerシークレットの更新 (p. 74)」を参照してください。

8. 設定を確認し、次に [Store secret (シークレットの保存)] を選択して入力した内容すべてを SecretsManager の新しいシークレットとして保存します。

Amazon RDS

このタイプのシークレットは、サポートされているデータベースサービス (p. 4)の 1 つに対して使用します。これらのサービスに対し、Secrets Manager は、事前設定済みの Lambda ローテーション関数を使用してフルローテーションをサポートします。Secrets Manager は、データベースインスタンスを照会することによって他のパラメータを決定するため、認証情報のみを指定します。

1. データベースへのアクセスを許可するユーザーの名前とパスワードを入力します。このシークレットにアクセスするお客様が必要とするアクセス許可のみを持つユーザーを選択します。

2. シークレット内の保護されたテキストを暗号化するために使用する AWS KMS 暗号化キーを選択します。選択しない場合、Secrets Manager はアカウントのデフォルトキーが存在するかどうかを確認し、存在する場合はそのデフォルトキーを使用します。デフォルトのキーが存在しない場合は、Secrets Manager が自動的に作成します。また、[Add new key(新しいキーの追加)] を選択し

56


https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-paramstore-su-organize.html

https://aws.amazon.com/answers/account-management/aws-tagging-strategies/


て､このシークレット専用のカスタム CMK を作成します。独自の AWS KMS CMK を作成するには、アカウントに CMK を作成するためのアクセス許可が必要です。

3. リストからデータベースインスタンスを選択します。Secrets Manager は、選択したインスタンスを照会することによって、データベースに関する接続の詳細を取得します。

Amazon Redshift

Amazon Redshift クラスターには、このタイプのシークレットを使用します。Secrets Manager は、データベースインスタンスを照会することによって他のパラメータを決定するため、認証情報のみを指定します。

1. データベースへのアクセスを許可するユーザーの名前とパスワードを入力します。2. シークレット内の保護されたテキストを暗号化するために使用する AWS KMS 暗号化キーを選択

します。選択しない場合、Secrets Manager はアカウントのデフォルトキーが存在するかどうかを確認し、存在する場合はそのデフォルトキーを使用します。デフォルトのキーが存在しない場合は、Secrets Manager が自動的に作成します。また、[Add new key(新しいキーの追加)] を選択して､このシークレット専用のカスタム CMK を作成します。独自の AWS KMS CMK を作成するには、アカウントに CMK を作成するためのアクセス許可が必要です。

3. 正しいデータベースエンジンを選択します。4. データベースサーバーの IP アドレス、データベース名、および TCP ポート番号を入力して、接続

の詳細を指定します。

DocumentDB database

DocumentDB データベースには、このタイプのシークレットを使用します。Secrets Manager は、データベースインスタンスを照会することによって他のパラメータを決定するため、認証情報のみを指定します。


します。選択しない場合、Secrets Manager は、アカウントのデフォルトキーが存在するかどうかを調べ、存在する場合はそれを使用します。デフォルトのキーが存在しない場合は、SecretsManager が自動的に作成します。また、[Add new key(新しいキーの追加)] を選択して､このシークレット専用のカスタム CMK を作成します。独自の AWS KMS CMK を作成するには、アカウントに CMK を作成するためのアクセス許可が必要です。

3. 正しいデータベースエンジンを選択します。4. データベースサーバーの IP アドレス、データベース名、および TCP ポート番号を入力して、接続


Other databases

Secrets Manager は他のタイプのデータベースをサポートし、これらのタイプにこのシークレットを使用します。ただし、データベースに関する追加情報を提供する必要があります。このシークレットを更新するには、シークレットを解析してサービスとやり取りして、シークレットを更新するカスタム Lambda ローテーション関数を記述する必要があります。


します。選択しない場合、Secrets Manager は、アカウントのデフォルトキーが存在するかどうかを調べ、存在する場合はそれを使用します。デフォルトのキーが存在しない場合は、SecretsManager が自動的に作成します。また、[Add new key(新しいキーの追加)] を選択して､このシーク

57


レット専用のカスタム CMK を作成します。独自の AWS KMS CMK を作成するには、アカウントに CMK を作成するためのアクセス許可が必要です。

3. データベースを実行するデータベースエンジンのタイプを選択します。4. データベースサーバーの IP アドレス、データベース名、および TCP ポート番号を入力して、接続


Other type of secret

Secrets Manager は、他のデータベースまたはサービス用に設定し、それらにこのシークレットを使用できます。シークレットの構造と詳細を指定する必要があります。このシークレットを更新するには、シークレットを解析してサービスとやり取りし、ユーザーに代わってシークレットを更新するカスタム Lambda ローテーション関数を記述する必要があります。

1. カスタムシークレットの詳細を [キー] と [値] のペアの形式で指定します。たとえば、キーとしてUserName を指定し、その値として適切なユーザー名を指定できます。パスワードの名前とパスワードのテキストを値として持つ 2 番目のキーを追加します。また、Database name、Serveraddress、TCP port などのエントリを追加することもできます。必要な情報を格納するのに必要な数だけペアを追加できます。

または、[プレーンテキスト] タブを選択して、任意の形式でシークレット値を入力することもできます。

2. シークレット内の保護されたテキストを暗号化するために使用する AWS KMS 暗号化キーを選択します。選択しない場合、Secrets Manager は、アカウントのデフォルトキーが存在するかどうかを調べ、存在する場合はそれを使用します。デフォルトのキーが存在しない場合は、SecretsManager が自動的に作成します。また、[Add new key(新しいキーの追加)] を選択して､このシークレット専用のカスタム CMK を作成します。独自の AWS KMS CMK を作成するには、アカウントに CMK を作成するためのアクセス許可が必要です。

Using the AWS CLI or AWS SDK operations

以下のコマンドを使用して、Secrets Manager に基本的なシークレットを作成します。

• API/SDK: CreateSecret• AWS CLI: create-secret

Example

コンソールベースのシークレット設定と同等の AWS CLI コマンドを実行する例。このコマンドでは、この例の JSON テキスト構造 {"username":"anika","password":"aDM4N3*!8TT"} などのシークレットを、mycreds.json という名前のファイルに配置したことを前提にしています。

$ aws secretsmanager create-secret --name production/MyAwesomeAppSecret --secret-string file://mycreds.json{ "SecretARN": "arn:aws:secretsmanager:region:accountid:secret:production/MyAwesomeAppSecret-AbCdEf", "SecretName": "production/MyAwesomeAppSecret", "SecretVersionId": "EXAMPLE1-90ab-cdef-fedc-ba987EXAMPLE"}

Important

基本的なシークレットは、SecretString の任意の形式を使用して作成できます。たとえば、単純な JSON のキーと値のペア、つまり {"username":"someuser",

58

https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_CreateSecret.html

https://docs.aws.amazon.com/cli/latest/reference/secretsmanager/create-secret.html

AWS Secrets Manager ユーザーガイドシークレットの変更

"password":"securepassword"} を使用できます。ただし、後でこのシークレットのローテーションを有効にする場合は、このシークレットで使用するローテーション関数によって予期される特定の構造を使用する必要があります。シークレット値を操作するために各ローテーション関数で必要となるものの詳細については、Lambda ローテーション関数の作成に使用できる AWS テンプレート (p. 153) の該当するローテーション関数の「想定される SecretString 値」のエントリを参照してください。

Secrets Manager は ClientRequestToken パラメータを必要としません。ここで使用する AWS CLIによってパラメータが自動的に生成され、指定されるためです。アカウントにデフォルトの SecretsManager CMK を使用する場合、 KmsKeyId パラメータは必要ありません。Secrets Manager コンソールと SecretString を使用する場合、SecretBinary は使用できません。Secrets Manager では、コンソールが使用する SecretType を予約します。

シークレットを使用してデータベースにアクセスするアプリケーションを顧客が使用する作業環境では、アプリケーションがシークレットにアクセスするために使用する IAM ユーザーまたはロールにアクセス許可を付与する必要が生じることがあります。これを行うには、リソースベースのポリシーをシークレットに直接アタッチして、ユーザーまたはロールを Principal エレメントにリストすることで実行できます。または、Resource 要素でシークレットを識別するポリシーをユーザーまたはロールにアタッチすることができます。

シークレットの変更シークレットの作成後、シークレットのいくつかの要素を変更することができます。コンソールでは、説明を編集したり、新しいリソースベースのポリシーを編集またはアタッチしてシークレットのアクセス許可を変更したり、保護されたシークレット情報を暗号化および復号するのに使用する AWS KMS カスタマーマスターキー (CMK) を変更したり、タグを編集､追加､または削除できます。

暗号化されたシークレット情報の値を変更することもできます。ただし、ローテーションを使用して認証情報を含むシークレット値を更新することをお勧めします。ローテーションはシークレットを更新するだけではありません。ローテーションは、保護されたデータベースまたはサービスの認証情報をシークレットの認証情報と一致するように変更します。これによりシークレットが自動的に同期されるため、クライアントがシークレット値をリクエストすると常に有効な認証情報が取得できます。

このセクションには、シークレットの以下の要素を変更する方法を説明する手順とコマンドが含まれています。

• 暗号化されたシークレット値 (p. 59)• 説明 (p. 61)• AWS KMS 暗号化キー (p. 62)• タグ (p. 63)• アクセス許可ポリシー (p. 70)

シークレットに格納されている暗号化されたシークレット値の変更


Important

• この方法でシークレットを更新しても、保護されたサーバーの認証情報は変更されません。サーバーの認証情報をシークレット値に格納されている認証情報と同期させる場合は、ローテーションを有効にすることをお勧めします。AWS Lambda 関数は、サーバー上の認証情報とシークレット内の認証情報の両方を一致させ、更新された認証情報が機能するかどうかをテストします。詳細については、「AWS Secrets Manager シークレットの更新 (p. 74)」を参照してください。

59


• 基本シークレットは、SecretString に必要な形式で作成できます。たとえば、シンプルな JSON キー値ペアを使用できます。たとえば、{"username":"someuser","password":"securepassword"} などです。後でこのシークレットのローテーションを有効にする場合は、シークレット特定の構造を使用する必要があります。Secrets Manager は、このシークレットで使用するローテーション関数によって正確な形式を決定します。シークレット値のために各ローテーション関数で必要となる項目の詳細については、他のデータベースやサービスのローテーションと AWS Secrets Manager のシークレットの該当するローテーション値のエントリで「予測される SecretString 値」を参照してください。


シークレットの暗号化されたシークレット値を更新すると、シークレットの新しいバージョンが作成されます。新しいバージョンでは、ステージングラベル AWSCURRENT が自動的に受信されます。ステージングラベル AWSPREVIOUS を照会することによって、まだ古いバージョンにアクセスできます。CLI から get-version-ids コマンドまたは API GETVERSIONIDS を使用して、変更されたシークレットと元のシークレットを比較します。

2 つのコマンドの出力には、Secrets Manager が変更されたシークレットの新しいバージョンを作成するため、CreatedDate フィールド (有効なパラメータ) が表示されます。

Note

ステージングラベル AWSCURRENT が、あるバージョンから別のバージョンに移動するたびに、Secrets Manager はステージングラベル AWSPREVIOUS を以前に AWSCURRENT というラベルが付けられたバージョンに自動的に移動します｡

1. Secrets Manager コンソール (https://console.aws.amazon.com/secretsmanager/) を開きます。2. シークレットのリストから、シークレット値を変更する必要があるシークレットの名前を選択しま

す。3. [シークレット値] セクションで、[Retrieve secret value(シークレット値の取得)] を選択します。4. シークレット値が表示されたら、Edit を選択します。5. 必要に応じて値を更新し、[保存] を選択します。


次のコマンドを使用して、シークレットに格納されている暗号化されたシークレット値を更新できます。シークレットの暗号化されたシークレット値を更新すると、シークレットの新しいバージョンが作成されます。

Important

基本シークレットは、SecretString に必要な形式を使って更新できます。たとえば、シンプルな JSON キー値ペアを使用できます。たとえば、{"username":"someuser","password":"securepassword"} などです。ただし、後でこのシークレットにローテーションを有効化する場合には、このシークレットで使用するローテーション関数によって予期される特定の構造を使用する必要があります。シークレット値のために各ローテーション関数で必要となる項目の詳細については、他のデータベースやサービスのローテーションとAWS Secrets Manager のシークレットの該当するローテーション値のエントリで「予測される SecretString 値」を参照してください。Note

UpdateSecret は､ステージングラベル AWSCURRENT を新しいバージョンのシークレットに自動的に移動します。PutSecretValue はステージングラベルに自動的に移動されません。ただし、このコマンドが最初のバージョンのシークレットを作成した場合、コマンドが AWSCURRENT を追加しま

60

secretsmanager/latest/userguide/reference_available-rotation-templates.html





す。それ以外の場合、コマンドは VersionStages パラメータを使用して明示的にリクエストするラベルのみをアタッチまたは移動します。ステージングラベル AWSCURRENT が、あるバージョンから別のバージョンに移動するたびに、Secrets Manager はステージングラベル AWSPREVIOUS をバージョン AWSCURRENT に移動し、ステージングラベル AWSPREVIOUS を削除します。

• API/SDK: UpdateSecret、PutSecretValue

• AWS CLI: update-secret, put-secret-value

Example

次の AWS CLI コマンドの例では、シークレットのシークレット値が変更されます。これにより、新しいバージョンが作成されます。AWSCURRENT ステージングラベルは Secrets Manager によって自動的に新しいバージョンに移動されます。また、Secrets Manager が、AWSPREVIOUS ステージングラベルを AWSCURRENT ステージングラベルの古いバージョンに自動的に移動します。

$ aws secretsmanager update-secret --secret-id production/MyAwesomeAppSecret --secret-string '{"username":"anika","password":"a different password"}'{ "SecretARN": "arn:aws:secretsmanager:us-west-2:123456789012:secret:production/MyAwesomeAppSecret-AbCdEf", "SecretName": "production/MyAwesomeAppSecret", "VersionId": "EXAMPLE1-90ab-cdef-fedc-ba987EXAMPLE"}

出力の VersionId には、新しいバージョンのシークレットの一意のシークレットバージョン ID が含まれます。ClientRequestToken パラメータを使用して、手動で値を指定できます。値を指定しない場合、SDK または AWS CLI によってランダムな UUID 値が生成されます。

シークレットの説明の変更


Using the console

1. Secrets Manager コンソール (https://console.aws.amazon.com/secretsmanager/) を開きます。2. シークレットのリストから、変更するシークレットの名前を選択します。3. [Secrets details(シークレットの詳細)] セクションで、[アクション] を選択し、[説明の編集] を選択

します。4. 新しい説明を入力するか、既存のテキストを編集して、[保存] を選択します。


次のコマンドを使用して、AWS Secrets Manager 内のシークレットの説明を変更できます。

• API/SDK: UpdateSecret• AWS CLI: update-secret

Example

次の AWS CLI コマンドの例では、説明に --description パラメータで指定されたものを追加するか､それで置き換えます。

61

https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_UpdateSecret.html

https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_PutSecretValue.html

https://docs.aws.amazon.com/cli/latest/reference/secretsmanager/update-secret.html

https://docs.aws.amazon.com/cli/latest/reference/secretsmanager/put-secret-value.html





$ aws secretsmanager update-secret --secret-id production/MyAwesomeAppSecret --description 'This is the description I want to attach to the secret.'{ "ARN": "arn:aws:secretsmanager:region:accountid:secret:production/MyAwesomeAppSecret-AbCdEf", "Name": "production/MyAwesomeAppSecret", "VersionId": "EXAMPLE1-90ab-cdef-fedc-ba987EXAMPLE"}

Example

シークレットに対する変更を表示するには、次のコマンド describe-secret を使用します。

aws secretsmanager describe-secret --secret-id production/MyAwesomAppSecret { "ARN": "arn:aws:secretsmanager:region:accountid:secret:production/MyAwesomeAppSecret-AbCdEf", "Name": "production/MyAwesomeAppSecret", "Description": "This is the description I want to attach to the secret", "LastChangedDate": 1579542853.77, "LastAccessedDate": 1579478400.0,

シークレットで使用される AWS KMS 暗号化キーの変更



Important

シークレットで使用される暗号化キーを変更する場合は、最初の CMK を無効にするか削除する前に、シークレット値を UpdateSecret または PutSecretValue で少なくとも 1 回更新する必要があります。シークレット値を更新すると、古い CMK を使用してシークレットが復号され、新しい CMK でシークレットが再暗号化されます。この更新の前に最初のCMK を無効にしたり削除したりすると、Secrets Manager そのキーを復号できず、CMK を再有効化できない限りシークレットの内容が失われます。

1. Secrets Manager コンソール (https://console.aws.amazon.com/secretsmanager/) を開きます。2. シークレットのリストで、変更するシークレットの名前を選択します。3. [Secrets details(シークレットの詳細)] セクションで、[アクション] を選択し、[Edit encryption

key(暗号化キーの編集)] を選択します。4. シークレットの新しいバージョンを暗号化および復号化する AWS KMS 暗号化キーを選択します。

次に、[Save ] を選択します。


Important

シークレットで使用される暗号化キーを変更する場合は、最初の CMK を無効にするか削除する前に、シークレット値を UpdateSecret または PutSecretValue で少なくとも 1 回更新する必要があります。シークレット値を更新すると、古い CMK を使用してシークレットが復号され、新しい CMK でシークレットが再暗号化されます。この更新の前に最初の

62



CMK を無効にしたり削除したりすると、Secrets Manager そのキーを復号できず、CMK を再有効化できない限りシークレットの内容が失われます。

次のコマンドを使用して、シークレットが使用する AWS KMS 暗号化キーを変更できます。Amazonリソースネーム (ARN) で CMK を指定する必要があります。

• API/SDK: UpdateSecret• AWS CLI: update-secret

Example

次の AWS CLI コマンド例では、このシークレットのすべての暗号化および復号オペレーションに使用された AWS KMS CMK をこの時点から追加するか、置き換えています。

$ aws secretsmanager update-secret --secret-id production/MyAwesomeAppSecret --kms-key-id arn:aws:kms:region:123456789012:key/EXAMPLE1-90ab-cdef-fedc-ba987EXAMPLE

シークレットにアタッチされたタグの変更


Using the console

タグキーの名前と値は大文字と小文字が区別されます。シークレットの 1 つのタグだけが、指定されたキー名を持つことができます。

1. Secrets Manager コンソール (https://console.aws.amazon.com/secretsmanager/) を開きます。2. シークレットのリストで、変更するシークレットの名前を選択します。3. [タグ] セクションで [編集] を選択します。4. Secrets Manager には、既存のタグが表示されます。キー名や値はいずれも上書きできます。5. [タグの削除] を選択すると、既存の行を削除できます。6. 別のキーと値のペアを追加する必要がある場合は、[タグの追加] を選択し、新しいキー名と対応す

る値を入力します。7. 変更が完了したら、[保存] を選択します。


次のコマンドを使用して、Secrets Manager のシークレットにアタッチされたタグを追加または削除できます。キーの名前と値は大文字と小文字が区別されます。シークレットの 1 つのタグだけが、指定されたキー名を持つことができます。既存のタグを編集するには、キー名は同じだが、値が異なるタグを追加します。新しいキーと値のペアは追加されません。代わりに、Secrets Manager により既存のペア値が更新されます。キー名を変更するには、最初のキーを削除し、2 番目のキーを新しい名前で追加する必要があります。

• API/SDK: TagResource, UntagResource• AWS CLI: tag-resource、untag-resource

Example

次の AWS CLI コマンドの例では、タグに --tags パラメータで指定されたものを追加するか､または置き換えます。パラメータは Key および Value 要素の JSON 配列であると想定されています。

63




https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_TagResource.html

https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_UntagResource.html

https://docs.aws.amazon.com/cli/latest/reference/secretsmanager/tag-resource.html

https://docs.aws.amazon.com/cli/latest/reference/secretsmanager/untag-resource.html

AWS Secrets Manager ユーザーガイドシークレット値の取得

$ aws secretsmanager tag-resource --secret-id MySecret2 --tags '[{"Key":"costcenter","Value":"12345"},{"Key":"environment","Value":"production"}]'

tag-resource コマンドは出力を返しません。

Example

次の AWS CLI コマンドの例では、指定されたシークレットからキー「environment」を持つタグが削除されます。

$ aws secretsmanager untag-resource --secret-id MySecret2 --tag-keys 'environment'

tag-resource コマンドは出力を返しません。

シークレット値の取得Secrets Manager を使用すると、カスタムアプリケーションでシークレットをプログラムで安全に取得できます。ただし、コンソールまたは CLI ツールを使用してシークレットを取得することもできます。

このセクションでは、シークレットのシークレット値を取得する方法とそのコマンドについて説明します。

シークレット値の取得




コンソールでシークレットを取得するには次のアクセス許可が必要です。

• secretsmanager:ListSecrets – 取得するシークレットに移動するために使用します。• secretsmanager:DescribeSecret — シークレットの暗号化されていない部分を取得

するために使用します。• secretsmanager:GetSecretValue – シークレットの暗号化されているパートを取得す

るために使用します。• kms:Decrypt – カスタム AWS KMS カスタマーマスターキー (CMK) を使用してシーク

レットを暗号化した場合にのみ必要です。

1. Secrets Manager コンソール (https://console.aws.amazon.com/secretsmanager/) を開きます。2. アカウントのシークレットの一覧から、表示するシークレットの名前を選択します。

[シークレットの詳細] ページが表示されます。このページには暗号化されたシークレットテキスト以外の、選択されているシークレットの構成の詳細がすべて表示されます。

3. [シークレット値] セクションで、[Retrieve secret value(シークレット値の取得)] を選択します。4. [シークレットキー/値] を選択して、個別のキーと値として解析された認証情報を確認します。[プ

レーンテキスト] を選択して､暗号化されて保存されている JSON テキスト文字列を確認します。


アプリケーションのコードからシークレットを取得する方法の詳細については、「シークレット値の取得 (p. 64)」を参照してください。

64


AWS Secrets Manager ユーザーガイドAWS が開発したオープンソースのクライアント側キャッシングコンポーネントの使用

以下のコマンドを使用して、AWS Secrets Manager に保存されているシークレットを取得します。

• API/SDK: GetSecretValue• AWS CLI: get-secret-value

シークレットはフレンドリ名または Amazon リソースネーム (ARN) で識別し、シークレットのバージョンを指定する必要があります。バージョンを指定しない場合、Secrets Manager はデフォルトにより、ステージングラベル AWSCURRENT を持つバージョンになります。Secrets Manager は、シークレットテキストの内容をレスポンスパラメータ PlaintextString に返します。シークレットにバイナリデータを格納した場合は、バイト配列を返す Plaintext に返されます。

Example

次の AWS CLI コマンドの例では、暗号化されたシークレット情報を「MyTestDatabase」という名前のシークレットのデフォルトバージョンから復号して取得します。Secrets Manager では、CreatedDate 出力の最終更新日が使用されます。

$ aws secretsmanager get-secret-value --secret-id development/MyTestDatabase{ "ARN": "arn:aws:secretsmanager:region:accountid:secret:development/MyTestDatabase-AbCdEf", "Name": "development/MyTestDatabase", "VersionId": "EXAMPLE1-90ab-cdef-fedc-ba987EXAMPLE", "SecretString": "{\"ServerName\":\"MyDBServer\",\"UserName\":\"Anaya\",\"Password\":\"MyT0pSecretP@ssw0rd\"}", "SecretVersionStages": [ "AWSCURRENT" ], "CreatedDate": 1510089380.309}

AWS が開発したオープンソースのクライアント側キャッシングコンポーネントの使用シークレットを効率的に使用するために、使用するたびにシークレットの値を取得しないでください。また、次のオペレーションを実行するコードを含めてください。

• アプリケーションは、取得後にシークレットをキャッシュします。次に、必要になるたびにネットワーク経由で Secrets Manager からシークレットを取得するのではなく、キャッシュされた値を使用します。

• コードでネットワークエラーまたは AWS サービスエラーが発生した場合は、エクスポネンシャルバックオフを実装するアルゴリズムを使用してリクエストを再試行し、ジッターを使用して再度お試しください。詳細については、『AWS アーキテクチャブログ』の「エクスポネンシャルバックオフおよびジッター」を参照してください。

このようなタスクを実行するためのコードを書くことで、次のような利点があります。

• コストの削減 – 頻繁に使用するシークレットについては、キャッシュからそれらを取得すると、アプリケーションが Secrets Manager に対して行う API コールの数が減ります。Secrets Manager は API コールごとに料金がかかるため、これによってコストを大幅に節約することができます。

• パフォーマンス向上 – インターネット経由で Secrets Manager にリクエストを送信せずに、メモリからシークレットを取得すると、アプリケーションのパフォーマンスは大幅に向上します。

• 可用性の向上 – キャッシュからシークレット情報を検索する際の一時的なネットワークエラーは、はるかに少なくなります。

65

https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetSecretValue.html

https://docs.aws.amazon.com/cli/latest/reference/secretsmanager/get-secret-value.html

http://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/


AWS Secrets Manager ユーザーガイドシークレットの削除と復元

Secrets Manager は、これらのベストプラクティスを実装し、AWS Secrets Manager に格納されているシークレットにアクセスするためのコードを簡単に作成するためのクライアント側のコンポーネントを作成しました。クライアントをインストールしてシークレットを呼び出し、コードで使用するシークレットの識別子を指定します。Secrets Manager では、Secrets Manager を呼び出すために使用する AWS 認証情報に、シークレットに対する secretsmanager:GetSecretValue アクセス許可とsecretsmanager:DescribeSecret アクセス許可が含まれていることも要求します。これらの認証情報は通常、IAM ロールに関連付けられます。SAML フェデレーションまたはウェブ ID (OIDC) フェデレーションを使用している場合は、サインオン時にそのロールが割り当てられる可能性があります。アプリケーションが Amazon EC2 インスタンスで実行されている場合、管理者は、インスタンスプロファイルを作成して、IAM ロールを割り当てることができます。

コンポーネントは以下の形式になります。

• お客様がシークレットとやりとりする Java、Python、Go、.NET のクライアント側ライブラリ(GetSecretValue オペレーションの直接呼び出しの代わり)。

• Java Database Connectivity (JDBC) と互換性があるデータベースドライバーコンポーネント。このコンポーネントは、上記に示す機能を加えた真の JDBC ドライバのラッパーです。

ダウンロード手順については、以下のいずれかのリンクを使用してください。

• Java ベースのキャッシュクライアントコンポーネント• JDBC 互換のデータベースコネクタコンポーネント• Python キャッシュクライアント• .NET キャッシュクライアント• Go キャッシュクライアント

シークレットの削除と復元シークレットは性質上重要であるため、AWS Secrets Manager は意図的にシークレットの削除を困難にします。Secrets Manager はシークレットをすぐに削除しません。その代わり、Secrets Manager はすぐにシークレットをアクセス不可にし、最短で 7 日間の復旧期間が経過した後に削除されるようにスケジュール設定します。復旧期間が終了するまで、以前に削除したシークレットを復旧することができます。CLIを使用すると、復旧期間なしでシークレットを削除できます。

また、シークレットのバージョンを直接削除することはできません。代わりに、シークレットからすべてのステージングラベルを削除します。これにより、シークレットは廃止とマークされ、Secrets Managerはバックグラウンドでバージョンを自動的に削除できるようになります。

このセクションでは、シークレットの削除と削除されたシークレットの復元を説明する手順とコマンドについて説明します。

• シークレットとすべてのバージョンを削除する (p. 66)• 削除予定のシークレットを復元する (p. 68)• シークレットのバージョンを削除する (p. 69)

シークレットとすべてのバージョンを削除する



シークレットを削除すると、Secrets Manager はそれをすぐに非推奨にします。ただし、SecretsManager は、復旧期間で指定した日数が経過するまで、シークレットを実際に削除しません。非推奨

66

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_saml.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_oidc.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_oidc.html

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html

https://github.com/aws/aws-secretsmanager-caching-java

https://github.com/aws/aws-secretsmanager-jdbc

https://github.com/aws/aws-secretsmanager-caching-python

https://github.com/aws/aws-secretsmanager-caching-net

https://github.com/aws/aws-secretsmanager-caching-go


のシークレットにアクセスすることはできません。削除予定のシークレットにアクセスする必要がある場合は、まずそのシークレットを復元する必要があります。その後、シークレットと暗号化されたシークレット情報にアクセスすることができます。

AWS CLI または AWS SDK を使用すると、復旧期間なしでシークレットを削除できます。しかし、これを Secrets Manager コンソールで実行することはできません。


コンソールでシークレットを削除するには、次のアクセス許可が必要です。

• secretsmanager:ListSecrets – 削除するシークレットに移動します｡• secretsmanager:DeleteSecret – シークレットを廃止し、完全削除のスケジュールを

設定します｡

1. Secrets Manager コンソール (https://console.aws.amazon.com/secretsmanager/) を開きます。2. Secrets Manager で現在管理しているシークレットのリストに移動し、削除するシークレットの名

前を選択します。3. [シークレットの詳細] セクションで、[シークレットの削除] をクリックします。4. [Schedule secret deletion(シークレットの削除をスケジュールする)] ダイアログボックスで、復

旧期間の日数を指定します。これは、永続的に削除されるまで待機する日数を表します。SecretsManager は DeletionDate というフィールドをアタッチし、このフィールドを、現在の日付と時刻に復旧期間に指定した日数を加えたものに設定します。

5. [Schedule deletion] を選択します。6. 削除された項目を表示するオプションがコンソールで有効になっている場合、シークレットは引き

続き表示されます。必要に応じて、リスト内の [Deleted date (削除日付)] フィールドを表示することもできます。a. 右上隅の [設定] アイコン (歯車 ) を選択します。b. [Show secrets scheduled for deletion] (削除が予定されているシークレットを表示) を選択しま

す。c. [Deleted on] (削除日) のスイッチを有効にします。d. [Save] を選択します。

これで、削除されたシークレットはそれぞれ削除された日付とともにリストに表示されます。



• API/SDK: DeleteSecret• AWS CLI: delete-secret

SecretId フィールドで、フレンドリ名または Amazon リソースネーム (ARN) で削除するシークレットを特定する必要があります。

Example

次の AWS CLI コマンドの例では、「MyTestDatabase」という名前のシークレットを非推奨にし、14日間の復旧期間後に削除するようにスケジュールを設定します。

$ aws secretsmanager delete-secret --secret-id development/MyTestDatabase --recovery-window-in-days 14

67


https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_DeleteSecret.html

https://docs.aws.amazon.com/cli/latest/reference/secretsmanager/delete-secret.html


{ "ARN": "arn:aws:secretsmanager:region:accountid:secret:development/MyTestDatabase-AbCdEf", "Name": "development/MyTestDatabase", "DeletionDate": 1510089380.309}

DeletionDate フィールドに指定された任意の日時に、AWS Secrets Manager はシークレットを完全に削除します。

待機時間なしでシークレットをすぐに削除することもできます。

Important

ForceDeleteWithoutRecovery パラメータで削除されたシークレットは、RestoreSecret オペレーションを使用して復元することはできません。

Example

次の AWS CLI コマンドの例では、復旧期間なしでシークレットを直ちに削除します。DeletionDate レスポンスフィールドには、将来の時刻ではなく現在の日付と時刻が表示されます。

$ aws secretsmanager delete-secret --secret-id development/MyTestDatabase --force-delete-without-recovery{ "ARN": "arn:aws:secretsmanager:region:accountid:secret:development/MyTestDatabase-AbCdEf", "Name": "development/MyTestDatabase", "DeletionDate": 1508750180.309}

役立つヒント

アプリケーションでシークレットがまだ使用されているかどうかわからない場合は、復旧期間中にシークレットにアクセスしようとしたときに警告する Amazon CloudWatch アラームを作成できます。詳細については、「削除予定のシークレットバージョンの監視 (p. 137)」を参照してください。

削除予定のシークレットの復元



Secrets Manager は、削除が予定されているシークレットを、非推奨、また直接アクセスされなくなったと見なします。復旧期間が終了すると、Secrets Manager はシークレットを完全に削除します。Secrets Manager がシークレットを削除すると、復元することはできません。復旧期間が終了する前に、シークレットを復元して再度アクセス可能にすることができます。これにより、スケジュールされた完全削除をキャンセルする DeletionDate フィールドが削除されます。


コンソールでシークレットとそのメタデータを復元するには、次のアクセス許可が必要です。

• secretsmanager:ListSecrets – 復元するシークレットに移動します｡

68


• secretsmanager:RestoreSecret – まだシークレットに関連付けられているすべてのバージョンを削除します。

1. Secrets Manager コンソール (https://console.aws.amazon.com/secretsmanager/) を開きます。2. Secrets Manager で現在管理しているシークレットのリストに移動します。3. 削除されたシークレットを表示するには、コンソールでこの機能を有効にする必要があります。こ

の機能を有効にしていない場合は、次の手順を実行します。4. a. 右上隅の [設定] アイコン (歯車 ) を選択します。

b. [Show secrets scheduled for deletion] (削除が予定されているシークレットを表示) を選択します。

c. [Deleted on] (削除日) のスイッチを有効にします。d. [Save] を選択します。

これで、削除されたシークレットはそれぞれが削除された日付と共にリストに表示されます。5. 復元する削除済みシークレットの名前を選択します。6. [シークレットの詳細] セクションで、[Cancel deletion(削除のキャンセル)] をクリックします。7. [Cancel secret deletion(シークレットの削除をキャンセル)] 確認ダイアログボックスで、[Cancel

deletion(削除のキャンセル)] を選択します。

AWS Secrets Manager は、シークレットから DeletionDate フィールドを削除します。これにより、スケジュールされた削除がキャンセルされ、シークレットへのアクセスが復元されます。



• API/SDK: RestoreSecret• AWS CLI: restore-secret

SecretId フィールドで、フレンドリ名または ARN で復元するシークレットを特定する必要があります。

Example

次の AWS CLI コマンドの例では、以前に削除された「MyTestDatabase」という名前のシークレットを復元します。これにより、スケジュールされた削除がキャンセルされ、シークレットへのアクセスが復元されます。

$ aws secretsmanager restore-secret --secret-id development/MyTestDatabase{ "ARN": "arn:aws:secretsmanager:region:accountid:secret:development/MyTestDatabase-AbCdEf", "Name": "development/MyTestDatabase"}

シークレットの 1 つのバージョンの削除



69


https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_RestoreSecret.html

https://docs.aws.amazon.com/cli/latest/reference/secretsmanager/restore-secret.html

AWS Secrets Manager ユーザーガイドシークレットのリソースベースのポリシーを管理する

Secrets Manager コンソールを使用して、シークレットの 1 つのバージョンを削除することはできません。AWS CLI または AWS API を使用する必要があります｡

シークレットのバージョンを直接削除することはできません。その代わりに、ステージングラベルをすべて削除して、シークレットを実質的に非推奨としてマークします。その後で、Secrets Managerは､シークレットのバージョンをバックグラウンドで削除できます。

次のコマンドを使用して、AWS Secrets Manager に保存されているシークレットのバージョンを非推奨にすることができます。

• API/SDK: UpdateSecretVersionStage• AWS CLI: update-secret-version-stage

シークレットは、フレンドリ名または ARN で識別する必要があります。追加、移動、削除するステージングラベルも指定します。

FromSecretVersionId と MoveToSecretId を次の組み合わせで指定できます。

• FromSecretVersionId のみ: 指定されたバージョンからステージングラベルを完全に削除します。

• MoveToVersionId のみ: 指定されたバージョンにステージングラベルが追加されます。他のバージョンにステージングラベルがすでにアタッチされている場合、Secrets Manager はそれらのバージョンからラベルを自動的に削除します。

• MoveToVersionId と RemoveFromVersionId: これらはラベルを明示的に移動します。ステージングラベルはシークレットの RemoveFromVersionId バージョンに存在している必要があり、それ以外の場合はエラーが発生します。

Example

次の AWS CLI コマンドの例では、「MyTestDatabase」という名前のシークレットのバージョンからAWSPREVIOUS ステージングラベルを削除します。ListSecretVersionIds コマンドを使用して、削除するバージョンのバージョン ID を取得できます。

$ aws secretsmanager update-secret-version-stage \ --secret-id development/MyTestDatabase \ --remove-from-version-id EXAMPLE1-90ab-cdef-fedc-ba987EXAMPLE --version-stage AWSPREVIOUS{ "ARN": "arn:aws:secretsmanager:region:accountid:secret:development/MyTestDatabase-AbCdEf", "Name": "development/MyTestDatabase"}

シークレットのリソースベースのポリシーを管理する

このセクションでは、シークレットからリソースベースのポリシーをアタッチ、取得、および削除する方法について説明します。

トピック• リソースベースのポリシーをシークレットにアタッチする (p. 71)• リソースベースのポリシーをシークレットから取得する (p. 71)

70

https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_UpdateSecretVersionStage.html

https://docs.aws.amazon.com/cli/latest/reference/secretsmanager/update-secret-version-stage.html

AWS Secrets Manager API ??????API_ListSecretVersionIds.html

AWS Secrets Manager ユーザーガイドリソースベースのポリシーをシークレットにアタッチする

• リソースベースのポリシーをシークレットから削除する (p. 72)

AWS Secrets Manager では、シークレットの認証戦略の一環として、アクセス許可ポリシーをシークレットに直接アタッチできます。Secrets Manager は、シークレットへのアクセスを必要とするユーザー、グループ、またはロールにアタッチするポリシーからのアクセスに加えて、アタッチする機能も提供します。リソースベースのポリシーを取得して、後でそのポリシーを確認することができ、そのポリシーが不要になったときには削除できます。

Important

シークレットポリシーを管理できるのは、CLI または API からだけです。Secrets Manager コンソールでは、この機能は提供されません。

リソースベースのポリシーをシークレットにアタッチするアクセス許可ポリシーをシークレットにアタッチする

リソースベースのポリシーの作成の詳細については、「Secrets Manager シークレットへのアクセス許可の管理の概要 (p. 34)」および「Secrets Manager のリソースベースのポリシーを使用する (p. 49)」を参照してください。

ポリシーをシークレットにアタッチするには、次のステップを実行します。


指定されたシークレットへのアクセスを許可または拒否するポリシードキュメントをアタッチまたは変更するには、次のコマンドを使用します。ポリシードキュメントは、JSON 構造化テキストとしてフォーマットする必要があります。詳細については、「Secrets Manager のリソースベースのポリシーを使用する (p. 49)」を参照してください。ポリシードキュメントをテキストファイルとして保存し、コマンドのパラメータでそのファイルを参照することをお勧めします。

• API/SDK: PutResourcePolicy• CLI: put-resource-policy

Example

次の CLI コマンドの例では、現在シークレットにアタッチされているリソースベースのアクセス許可ポリシーをアタッチまたは置き換えます。Secrets Manager は、secretpolicy.json ファイルからポリシードキュメントを取得します。

$ aws secretsmanager put-resource-policy --secret-id production/MyAwesomeAppSecret --resource-policy file://secretpolicy.json{ "ARN": "arn:aws:secretsmanager:us-west-2:123456789012:secret:production/MyAwesomeAppSecret-a1b2c3", "Name": "MyAwesomeAppSecret"}

リソースベースのポリシーをシークレットから取得するシークレットにアタッチされたアクセス許可ポリシーを取得する

71

https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_PutResourcePolicy.html

https://docs.aws.amazon.com/cli/latest/reference/secretsmanager/put-resource-policy.html

AWS Secrets Manager ユーザーガイドリソースベースのポリシーをシークレットから削除する

シークレットにアタッチされているリソースベースのポリシーのテキストを取得するには、以下のステップを使用します。


次のコマンドを使用すると、指定されたシークレットに現在アタッチされているポリシードキュメントを取得できます。

• API/SDK: GetResourcePolicy• CLI: get-resource-policy

Example

次の CLI コマンドの例では、現在シークレットにアタッチされているリソースベースのアクセス許可ポリシーのテキストを取得します。

$ aws secretsmanager get-resource-policy --secret-id production/MyAwesomeAppSecret{ "ARN": "arn:aws:secretsmanager:us-west-2:123456789012:secret:production/MyAwesomeAppSecret-a1b2c3", "Name": "MyAwesomeAppSecret", "ResourcePolicy": "{\"Version\":\"2012-10-17\",\"Statement\":{\"Effect\":\"Allow\",\"Principal\":{\"AWS\":\"arn:aws:iam::111122223333:root\",\"arn:aws:iam::444455556666:root\"},\"Action\":[\"secretsmanager:GetSecret\",\"secretsmanager:GetSecretValue\"],\"Resource\":\"*\"}}"}

リソースベースのポリシーをシークレットから削除するシークレットにアタッチされたアクセス許可ポリシーを削除する

指定されたシークレットに現在アタッチされているリソースベースのポリシーを削除するには、以下のステップを使用します。


次のコマンドを使用すると、指定したシークレットに現在アタッチされているリソースベースのポリシーを削除できます。

• API/SDK: DeleteResourcePolicy• CLI: delete-resource-policy

Example

次の CLI コマンドの例では、現在シークレットにアタッチされているリソースベースのアクセス許可ポリシーを削除します。

$ aws secretsmanager delete-resource-policy --secret-id production/MyAwesomeAppSecret{ "ARN": "arn:aws:secretsmanager:us-west-2:123456789012:secret:production/MyAwesomeAppSecret-a1b2c3", "Name": "production/MyAwesomeAppSecret"

72


https://docs.aws.amazon.com/cli/latest/reference/secretsmanager/get-resource-policy.html

https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_DeleteResourcePolicy.html

https://docs.aws.amazon.com/cli/latest/reference/secretsmanager/delete-resource-policy.html

AWS Secrets Manager ユーザーガイドリソースベースのポリシーをシークレットから削除する

}

73

AWS Secrets Manager ユーザーガイドシークレットを自動的に更新するために必要なアクセス許可

AWS Secrets Manager シークレットの更新

保護されたサービスまたはデータベースのシークレットを自動的に更新するよう､AWS Secrets Managerを構成できます。Secrets Manager は､サポートされている Amazon RDS データベース (p. 4)のシークレットを更新する方法をネイティブで理解しています。ただし、Secrets Manager では、他のデータベースまたはサードパーティーのサービスでシークレットを更新することもできます。各サービスまたはデータベースにはシークレットを構成する独自の方法があるため、Secrets Manager は､選択したデータベースまたはサービスと連携するようカスタマイズできる Lambda 関数を使用します。Lambda 関数をカスタマイズして、シークレットをローテーションする方法に関するサービス固有の詳細を実装します。

[RDS データベースの認証情報]、[Credentials for Redshift cluster (Redshift クラスターの認証情報)]、または [Credentials for DocumentDB database (DocumentDB データベースの認証情報)] シークレットタイプを使用してシークレットのローテーションを有効にすると、Secrets Manager が Lambda ローテーション関数を提供し、関数にシークレット内の Amazon リソースネーム (ARN) を自動的に入力します。これが機能するためには、いくつかの詳細を入力する以外に詳細を指定します。たとえば、認証情報をローテーションするアクセス許可を持つシークレットと、どのくらいの頻度でシークレットをローテーションするかを指定します。

[Credentials for other database(他のデータベースの認証情報)] または [他の種類のシークレット] のローテーションを有効にするときは、Lambda 関数でコードを提供する必要があります。コードには、認証情報を更新または追加するために保護されたサービスとやりとりするために必要なコマンドが含まれています。

トピック• シークレットを自動的に更新するために必要なアクセス許可 (p. 74)• シークレットの更新をサポートするネットワークの設定 (p. 77)• サポートされている Amazon RDS データベースのシークレットの更新 (p. 78)• Amazon Redshift シークレットのローテーション (p. 87)• Amazon DocumentDB シークレットのローテーション (p. 95)• 他のデータベースやサービスのローテーションと AWS Secrets Manager のシークレット (p. 103)• Lambda ローテーション関数の理解とカスタマイズ (p. 108)• 使用されていない Lambda ローテーション関数の削除 (p. 122)

シークレットを自動的に更新するために必要なアクセス許可

AWS Secrets Manager コンソールを使用して、完全にサポートされているデータベース (p. 4)のいずれかのシークレットにローテーションを設定すると、コンソールによってほとんどすべてのパラメータが設定されます。しかし、関数を作成した場合、または他の理由で手動で何かを行う場合は、ローテーションのその部分のアクセス許可を手動設定する必要もあります。

ローテーションを設定するユーザーとローテーションをトリガーするユーザーのアクセス許可Secrets Manager では、シークレットローテーションを使用したユーザーオペレーションに 2 つの個別のアクセス許可のセットが必要です。

74

AWS Secrets Manager ユーザーガイドLambda ローテーション関数に関連付けられたアクセス許可

• ローテーションを設定するために必要なアクセス許可 – Secrets Manager は、信頼されているユーザーに、シークレットローテーションを設定するためのアクセス許可を割り当てます。詳細については、「完全な Secrets Manager 管理者アクセス許可をユーザーに付与する」を参照してください。

• シークレットを更新するために必要なアクセス許可 – 設定した後、ローテーションをトリガーするために IAM ユーザーに必要なアクセス許可は、secretsmanager:RotateSecret のみです。ローテーションの開始後、Lambda ローテーション関数はアタッチされた IAM ロールおよびそのアクセス許可を引き継いで使用し、必要とされる AWS KMS オペレーションを含む、ローテーション中に実行されるオペレーションを承認します。

このトピックの残りの部分では、Lambda ローテーション関数が正常にシークレットを更新するためのアクセス許可について説明します。

Lambda ローテーション関数に関連付けられたアクセス許可AWS Secrets Manager は、Lambda 関数を使用してコードを実装し、シークレット内で認証情報を更新します。

Secrets Manager サービスは Lambda 関数を呼び出します。これは、Lambda 関数にアタッチされた IAMロールを呼び出すことによって行われます。Secrets Manager には、このための次の 2 つのアクションがあります。

• ロールを引き受けるユーザーを指定する信頼ポリシー。このポリシーを設定して、サービスプリンシパル secretsmanager.amazonaws.com によって識別されるロールを Secrets Manager が引き受けられるようにする必要があります。このポリシーは、[Designer (デザイナー)] セクションのキーアイコンをクリックすることで、Lambda コンソールの関数の詳細ページで表示できます。詳細が [ Function policy(関数ポリシー)] セクションに表示されます。このポリシーは次の例のようになります。

{ "Version": "2012-10-17", "Id": "default", "Statement": [ { "Sid": "EXAMPLE1-90ab-cdef-fedc-ba987EXAMPLE", "Effect": "Allow", "Principal": { "Service": "secretsmanager.amazonaws.com" }, "Action": "lambda:InvokeFunction", "Resource": "<arn of the Lambda function that this trust policy is attached to - must match exactly>" } ]}

セキュリティ上の理由から、Secrets Manager で作成された信頼ポリシーには Resource エレメントが含まれ、Lambda 関数の Amazon リソースネーム (ARN) が含まれます。ロールを引き受けるユーザーは、ロールに関連付けられている Lambda 関数のみを呼び出すことができます。

• 引き受け人のロールを指定するロールのアクセス許可ポリシーこのポリシーを設定して、関数を呼び出してロールを引き受けるときに Secrets Manager が使用できるアクセス許可を指定する必要があります。Secrets Manager には、実装するローテーション戦略に応じて、2 つの異なるポリシーが用意されています。• 単一ユーザーのローテーション: 次の例は、シークレットに格納されている認証情報でサインインし、

パスワードを変更することでシークレットを更新する関数を示しています。

{

75

https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access_identity-based-policies.html#permissions_grant-admin-actions

AWS Secrets Manager ユーザーガイドLambda ローテーション関数に関連付けられたアクセス許可

"Statement": [ { "Effect": "Allow", "Action": [ "secretsmanager:DescribeSecret", "secretsmanager:GetSecretValue", "secretsmanager:PutSecretValue", "secretsmanager:UpdateSecretVersionStage" ], "Resource": "*", "Condition": { "StringEquals": { "secretsmanager:resource/AllowRotationLambdaArn": "<lambda_arn>" } } }, { "Effect": "Allow", "Action": [ "secretsmanager:GetRandomPassword" ], "Resource": "*" }, { "Action": [ "ec2:CreateNetworkInterface", "ec2:DeleteNetworkInterface", "ec2:DescribeNetworkInterfaces" ], "Resource": "*", "Effect": "Allow" } ]}

単一ユーザーの例の最初のステートメントは、関数が Secrets Manager オペレーションを実行するアクセス許可を付与します。ただし、Condition 要素により、このアクセス許可は、シークレットのローテーションの Lambda 関数としてこの Lambda 関数の ARN で設定されたシークレットのみに制限されます。

2 番目のステートメントで、条件を必要としない Secrets Manager オペレーションを 1 つ追加できます。

3 番目のステートメントにより、Lambda は VPC でデータベースまたはサービスの実行を指定するときに必要な設定をセットアップできるようになります。詳細については、『AWS Lambda DeveloperGuide』の「Amazon VPC 内のリソースにアクセスできるように Lambda 関数を構成する」を参照してください。

• マスターユーザーのローテーション: 次の例は、昇格されたアクセス許可を持つ認証情報で別のマスターシークレットを使用してサインインすることでシークレットを更新する関数を示しています。2人のユーザー間でどちらかのローテーション戦略を交互に使用する場合、Secrets Manager ではこの関数が必要になります。

{ "Statement": [ { "Effect": "Allow", "Action": [ "secretsmanager:DescribeSecret", "secretsmanager:GetSecretValue", "secretsmanager:PutSecretValue", "secretsmanager:UpdateSecretVersionStage" ],

76

https://docs.aws.amazon.com/lambda/latest/dg/vpc.html

AWS Secrets Manager ユーザーガイドシークレットの更新をサポートするネットワークの設定

"Resource": "*", "Condition": { "StringEquals": { "secretsmanager:resource/AllowRotationLambdaArn": "<lambda_arn>" } } }, { "Effect": "Allow", "Action": [ "secretsmanager:GetRandomPassword" ], "Resource": "*" }, { "Action": [ "ec2:CreateNetworkInterface", "ec2:DeleteNetworkInterface", "ec2:DescribeNetworkInterfaces" ], "Resource": "*", "Effect": "Allow" }, { "Effect": "Allow", "Action": [ "secretsmanager:GetSecretValue" ], "Resource": "<master_arn>" } ]}

以前の単一ユーザーポリシーと同じ 3 つのステートメントに加えて、このポリシーは 4 番目のステートメントを追加します。4 番目のステートメントは、関数がマスターシークレット内の認証情報を取得できるようにします。Secrets Manager は、マスターシークレットの認証情報を使用して、セキュリティで保護されたデータベースにサインインし、更新されたシークレットの認証情報を更新します。

シークレットの更新をサポートするネットワークの設定

シークレットを正常に変更するには、Lambda ローテーション関数が保護されたデータベースまたはサービス、および AWS Secrets Manager サービスの両方と通信できる必要があります。ローテーション関数は、新しい値でユーザーパスワードを更新するリクエストをデータベースまたは他のサービスに送信します。また、この関数は Secrets Manager API オペレーションを呼び出して、ローテーションプロセスに関係するシークレットを取得して更新します。ユーザーの Amazon RDS インスタンスまたは他のシークレットで保護されたサービスが Amazon VPC から提供されている Virtual Private Cloud (VPC) で実行されている場合、必要な接続を有効にするために以下のステップを実行する必要があります。

• Lambda ローテーション関数を設定して、関数とデータベースインスタンス間の通信を有効にします。Secrets Manager で完全にサポートされているデータベースサービス (p. 4)のいずれかを使用する場合、関数を作成する AWS CloudFormation テンプレートによって、データベースインスタンスのパブリックアクセシビリティが決まります。• 保護されたサービスが VPC で実行されており、パブリックにアクセス可能でない場合、AWS

CloudFormation テンプレートは Lambda ローテーション関数が同じ VPC 内で実行されるように設定します。このシナリオでは、ローテーション関数は保護されたサービスと VPC 内で直接通信できます。

77

AWS Secrets Manager ユーザーガイドAmazon RDS シークレットの更新

• 保護されたサービスをパブリックにアクセス可能なリソースとして実行した場合、VPC 内にあるかどうかに関係なく、AWS CloudFormation テンプレートは Lambda ローテーション関数が同じ VPC内で実行されないよう設定します。このシナリオでは、Lambda ローテーション関数は、保護されたサービスとパブリックにアクセス可能な接続ポイントを介して通信します。

手動でローテーション関数を設定して VPC に追加する場合、関数の [詳細] ページで [ネットワーキング]セクションまでスクロールし、一覧から適切な VPC を選択します。

• VPC 内で実行されている Lambda ローテーション関数と Secrets Manager サービスエンドポイント間で通信できるように VPC を設定します。デフォルトでは、Secrets Manager エンドポイントはパブリックインターネット上にあります。Lambda ローテーション関数および、保護されたデータベースまたはサービスの両方を VPC で実行している場合、次のいずれかのステップを実行する必要があります。• NAT ゲートウェイをユーザーの VPC に追加することで、Lambda 関数はパブリック Secrets

Manager エンドポイントにアクセスできるようになります。これにより、VPC を送信元とするトラフィックはパブリック Secrets Manager エンドポイントに到達できるようになります。これにより、VPC はある程度のリスクにさらされることになります。パブリックインターネットから攻撃可能なゲートウェイ用 IP アドレスがあるためです。

• VPC 内で、Secrets Manager サービスエンドポイントを直接設定できます。これにより、VPC は、パブリックリージョンエンドポイントにアドレス指定されたすべてのリクエストをインターセプトし、VPC を VPC 内で実行されているプライベートサービスエンドポイントにリダイレクトするよう設定されます。詳細については、「VPC エンドポイント経由で Secrets Manager に接続する」を参照してください。

サポートされている Amazon RDS データベースのシークレットの更新

Amazon RDS データベースのシークレットを自動的に更新するように、AWS Secrets Manager を設定できます。Secrets Manager は、Secrets Manager が提供する Lambda 関数を使用します。

サポートされている Amazon RDS データベース

Secrets Manager の Amazon RDS オプションでは、サポートされているデータベースとは、ローテーションを有効にすると、Secrets Manager がそのデータベース用に設計された完全ですぐに実行できるLambda ローテーション関数を提供することを意味しています。サポートされているデータベースの詳細な一覧については、「the section called “完全に設定された即時使用ローテーションをサポートするデータベース” (p. 4)」を参照してください。他のタイプのデータベースの場合でも、シークレットを更新することができます。ただし、他のデータベースのワークフローを使用する必要があります。これらの手順については、「他のデータベースやサービスのローテーションと AWS Secrets Manager のシークレット (p. 103)」を参照してください。

シークレットのタイプとして [Credentials for RDS database (RDS データベースの認証情報)] を持つシークレットのローテーションを有効にすると、Secrets Manager は Lambda ローテーション関数を自動的に作成して設定します。その後、Secrets Manager は、関数の Amazon リソースネーム (ARN) があるシークレットを保持します。Secrets Manager は、関数に関連付けられている IAM ロールを作成し、必要なすべてのアクセス許可があるロールを設定します。あるいは、別のシークレットでローテーション戦略を使用し、新しいシークレットで同じローテーションを使用する場合は、既存の関数の ARN を指定して両方のシークレットに使用できます。

Amazon VPC が提供する VPC で Amazon RDS DB インスタンスを実行し、VPC にパブリックインターネットアクセスがない場合、Secrets Manager はその VPC 内で実行するように Lambda 関数の設定も行います。Secrets Manager では、Lambda ローテーション関数が Secrets Manager サービスエンドポイントにアクセスして、必要な API オペレーションを呼び出すことができる必要もあります。VPC の 1 つ以上のリソースがインターネットと通信する必要がある場合は、Lambda ローテーション関数が公共の SecretsManager サービスエンドポイントにクエリできるように、NAT ゲートウェイを使用して VPC を設定する

78

https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-nat.html

vpc-endpoint-overview.html#vpc-endpoint

AWS Secrets Manager ユーザーガイドAmazon RDS シークレットの更新

ことができます。インターネットと通信できるようにする必要がない場合は、VPC 内からアクセスできるプライベート Secrets Manager サービスエンドポイントを使用する VPC を設定 (p. 77)できます。

それ以外の場合、通常必要なのは、Lambda 関数の作成に使用するテンプレートを決定するためにいくつかの詳細情報を入力することだけです。

• シークレットを更新するアクセス許可を持つ認証情報を使用してシークレットを指定します: ユーザーが自分のパスワードを変更できることがあります。またある時は、ユーザーのアクセス許可が非常に制限されているため、自分のパスワードを変更することはできません。代わりに、ユーザーの認証情報を変更するには、別の管理者または「スーパー」ユーザーの認証情報を使用する必要があります。

ローテーション関数が保護されたデータベースの認証情報を更新するために使用するシークレットを指定する必要があります。• [このシークレットを使用]: 現在のシークレットの認証情報に、データベース内でパスワードを変更す

るアクセス許可がある場合は、このオプションを使用します。このオプションを選択すると、SecretsManager は、各ローテーションで 1 人のユーザーのパスワードを変更するローテーション戦略を使用して Lambda 関数を実装します。このローテーション戦略の詳細については、「1 つのパスワードを使用してシングルユーザーの AWS Secrets Manager シークレットを更新する (p. 112)」を参照してください。

考慮事項

Secrets Manager は、これを「低可用性」オプションとして提供します。ログインの失敗は、ローテーションによって古いパスワードが削除されてから、更新されたパスワードがシークレットの新しいバージョンとしてアクセス可能になるまでの間に発生する可能性があります。この時間枠は通常非常に短く、1 秒以下です。このオプションを選択した場合は、クライアントアプリケーションが､コード内で適切な「バックオフとジッターで再試行」戦略を実装していることを確認してください。サインインが長時間にわたって何度か失敗した場合にのみ、アプリケーションがエラーを生成します。

• [以前 AWS Secrets Manager に保存したシークレットを使用する]: 現在のシークレットの認証情報に、制限的なアクセス許可があり、セキュリティで保護されたサービスの認証情報の更新に使用できない場合は、このオプションを選択します。または、シークレットの高可用性が必要な場合、これを選択します。このオプションを選択するには、保護されたサービスの認証情報を作成および更新するアクセス許可を持つ認証情報を持つ別の「マスター」シークレットを作成します。次に､リストからそのマスターシークレットを選択します。このオプションを選択すると、Secrets Manager が Lambda関数を実装します。この Lambda 関数には、シークレットで見つかった最初のユーザーのクローンを作成するローテーション戦略があります。次に、ローテーションごとに 2 人のユーザーを交互に切り替え、アクティブになるユーザーのパスワードを更新します。このローテーション戦略の詳細については、「既存の 2 人のユーザーを切り替えることで AWS Secrets Manager シークレットを更新する (p. 116)」を参照してください。

考慮事項

Secrets Manager は、このオプションを「高可用性」オプションとして提供します。これは、新しいバージョンの準備とテスト中に、古いバージョンのシークレットが引き続き動作し、サービスリクエストを処理するためです。Secrets Manager は、クライアントが新しいバージョンに切り替えるまで古いバージョンを非推奨にしません。このため、バージョン間の変更中にダウンタイムが発生しません。このオプションを使用するには、Lambda 関数を使用して、元のユーザーのアクセス許可を複製し、新しいユーザーに適用する必要があります。すると、この関数は、ローテーションごとに二人のユーザーを交互に切り替えます。ユーザーに付与されたアクセス許可を変更する必要がある場合は、両方のユーザーのアクセス許可を変更するようにしてください。

• この関数をカスタマイズします: 組織の要件を満たすために Secrets Manager が提供する Lambdaローテーション関数をカスタマイズすることができます。たとえば、関数のフェーズであるtestSecret (p. 111) を拡張し、アプリケーション固有のチェックを使用して、新しいバージョンをテストし、新しいシークレットが想定通りに機能するかを確認することができます。手順については、

79



AWS Secrets Manager ユーザーガイドAmazon RDS データベースシーク

レットのローテーションを有効にする

「Secrets Manager が提供する Lambda ローテーション関数のカスタマイズ (p. 86)」を参照してください。

トピック• Amazon RDS データベースシークレットのローテーションを有効にする (p. 80)• Secrets Manager が提供する Lambda ローテーション関数のカスタマイズ (p. 86)

Amazon RDS データベースシークレットのローテーションを有効にするAWS Secrets Manager コンソール (p. 80)、AWS CLI、またはまたはいずれかの AWS SDK を使用して、サポートされるAmazon RDSデータベース (p. 4)の認証情報があるシークレットのローテーションを有効にすることができます。

Warning

ローテーションを有効にした場合は、シークレットを保存するとすぐにシークレットが一度ローテーションされます。ローテーションを有効にする前に、このシークレット認証情報を使用してすべてのアプリケーションを更新し、Secrets Manager からシークレットを取得してください。初期ローテーション後は、元の認証情報は使用できない場合があります。更新に失敗したアプリケーションは、古い認証情報が無効になるとすぐに中断されます。

前提条件: ローテーションを有効にするためのネットワーク要件

ローテーションを有効にするには、ネットワーク環境を正しく設定する必要があります。

• Lambda 関数は、データベースと通信できる必要があります。 VPC で、RDS データベースインスタンスを実行している場合、同じ VPC で Lambda 関数を実行することをお勧めします。これにより、ローテーション関数とサービス間の直接接続が有効になります。これを設定するには、Lambda 関数の詳細ページで、[ネットワーク] セクションまで下にスクロールし、実行しているインスタンスと一致する[VPC] をドロップダウンリストから選択します。また、インスタンスにアタッチされた EC2 セキュリティグループが、インスタンスと Lambda 間での通信を有効化することを確認する必要があります。

• Lambda 関数は、Secrets Manager サービスエンドポイントと通信できる必要があります。 Lambdaローテーション関数を VPC 内で実行するように設定していないか、またはアタッチされた NAT ゲートウェイが VPC にあるために関数がインターネットにアクセスできる場合、Secrets Manager のいずれかのパブリックエンドポイントを使用できます。あるいは、インターネットに接続されていない VPC で実行されるように Lambda 関数が設定されている場合は、プライベート Secrets Manager サービスエンドポイントを使用して VPC を設定 (p. 77)できます。

サポートされている Amazon RDS データベースシークレットのローテーションを有効化、設定する


AWS マネジメントコンソールの使用


コンソールでローテーションを有効にして設定するには、次の管理ポリシーで提供されるアクセス権限が必要です。

• SecretsManagerReadWrite – Secrets Manager、Lambda、および AWSCloudFormation のすべてのアクセス許可を付与します。

• IAMFullAccess – ロールを作成し、そのロールにアクセス権限ポリシーをアタッチするために必要な IAM アクセス権限を提供します。

80

https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Introduction.html



https://docs.aws.amazon.com/general/latest/gr/rande.html#asm_region





2. ローテーションを有効化するシークレットの名前を選択します。3. [Configure automatic rotation(自動ローテーションの設定)] セクションで､[Enable automatic

rotation(自動ローテーションを有効化する)] を選択します｡これにより、このセクションの他のコントロールが有効になります。

4. [Select rotation period (保持期間の選択)] で、事前定義された値 — の 1 つを選択するか、[カスタム] を選択してから、ローテーション間の日数を入力します。コンプライアンス要件を満たすためにシークレットを更新する場合、この値をコンプライアンスに義務付けられた間隔から 1 日を引いた値に設定することをお勧めします。

前のローテーションが完了すると、Secrets Manager は次のローテーションをスケジュールします。Secrets Manager は、最後のローテーションの実際の日付にローテーションの間隔 (日数) を追加して、日付をスケジュールします。サービスは、その 24 時間の日付の枠内で時間をランダムに選択します。分も若干ランダムに選択されますが、正時に向かって重み付けされ、負荷を分散させるのに役立つさまざまな要素に影響されます。

Note

Secrets Manager で提供される Lambda 関数を使用して 2 人のユーザーを交互に使用する場合、次のステップで 2 番目の「master secret」オプションを選択した場合、コンソールはこのテンプレートを使用します。ローテーション期間をコンプライアンス指定の最小間隔の半分に設定する必要があります。Secrets Manager は、アクティブに使用されていない場合、古い認証情報を 1 回のローテーションサイクルで利用可能な状態に保持します。Secrets Manager は、2 回目のローテーション後に新しいパスワードでユーザーを更新した後に古い認証情報を無効にします。ローテーション関数を変更し、新しいシークレットがアクティブになったら直ちに古い認証情報を無効にする場合は、コンプライアンスで義務付けられた最小値までローテーション間隔を延長できます。AWSPREVIOUS ステージングラベルを使用し、1 つの追加のサイクルについて古い認証情報をアクティブなままにすると、高速復旧に使用できる最後の既知の正常な認証情報のセットが提供されます。エラーが発生して現在の認証情報が中断された場合、AWSCURRENT ステージングラベルを AWSPREVIOUS ラベルがあるバージョンに簡単に移動できます。これで、顧客は再度リソースにアクセスできます。詳細については、「既存の 2 人のユーザーを切り替えることで AWS Secrets Manager シークレットを更新する (p. 116)」を参照してください。

5. 次のいずれかのオプションを選択します。• 新しい Lambda ローテーション関数を作成する

a. [新しい Lambda 関数を作成してローテーションを実行する] を選択します。b. [Lambda 関数の名前] に、Secrets Manager によって作成される Lambda 関数に割り当てる名

前を入力します。c. このローテーション関数で使用できる認証情報を使用してシークレットを指定します。認証情

報には、保護されたデータベースでユーザー名とパスワードを更新するためのアクセス許可が含まれている必要があります。• [次のシークレットを使用]: このシークレットの認証情報にデータベース内でパスワードを

変更するアクセス許可がある場合は、このオプションを選択します。このオプションを選択すると、Secrets Manager は 1 人のユーザーでシークレットをローテーションし、ローテーションごとにパスワードを変更する Lambda 関数を作成します。

考慮事項

Secrets Manager は、このオプションを「低可用性」オプションとして提供します。ログインの失敗は、ローテーションによって古いパスワードが削除されてから、更新されたパスワードがシークレットの新しいバージョンとしてアクセス可能になるまでの間に発生する可能性があります。この時間枠は通常非常に短く、1 秒以下です。このオプションを選択した場合は、クライアントアプリケーションが､コード内で適切な「バックオフとジッターで再試行」戦略を実装していることを確

81





認してください。サインインが長時間にわたって何度か失敗した場合にのみ、アプリケーションがエラーを生成します。

• [AWS Secrets Manager で以前に保存したシークレットを使用]: 現在のシークレットの認証情報に認証情報を更新するアクセス許可がない場合、またはシークレットの高可用性が必要な場合は、このオプションを選択します。このオプションを選択するには、このシークレットの認証情報を更新するアクセス許可を持つ認証情報がある別のマスターシークレットを作成する必要があります。次に､リストからマスターシークレットを選択します。

このオプションを選択すると、Secrets Manager は、ローテーションごとに新しいユーザーとパスワードを作成し、古いユーザーを非推奨にすることによってシークレットを更新するLambda 関数を作成します。

考慮事項

Secrets Manager は、このオプションを「高可用性」オプションとして提供します。これは、新しいバージョンの準備とテスト中に、古いバージョンのシークレットが引き続き動作し、サービスリクエストを処理するためです。Secrets Managerは、クライアントが新しいバージョンに切り替えるまで古いバージョンを非推奨にしません。このため、バージョン間の変更中にダウンタイムが発生しません。このオプションを使用するには、Lambda 関数を使用して、元のユーザーのアクセス許可を複製し、新しいユーザーに適用する必要があります。すると、この関数は、ローテーションごとに二人のユーザーを交互に切り替えます。ユーザーに付与されたアクセス許可を変更する必要がある場合は、両方のユーザーのアクセス許可を変更するようにしてください。

• 別のシークレット用にすでに作成済みの Lambda 関数を使用するa. [既存の Lambda 関数を使用してローテーションを実行する] を選択します。b. ドロップダウンリストから Lambda 関数を選択します。c. ローテーション関数のタイプを指定します。

• シングルユーザーローテーション: パスワードを変更するアクセス許可があるユーザーの認証情報を保存するシークレットのローテーション関数。Secrets Manager では、関数の作成時に [このシークレットを使用する] オプションを選択すると、このタイプの関数が作成されます。

• マルチユーザーのローテーション: パスワードを変更できないユーザーの認証情報を保存するシークレットで使用するローテーション関数。関数には、このシークレットユーザーの認証情報を変更する権限を持つユーザーの認証情報を保存する別のマスターシークレットが必要です。Secrets Manager は、[AWS Secrets Manager で以前に保存したシークレットを使用する] オプションを選択すると、このタイプの関数を作成します。

d. 2 番目の「マスターシークレット」オプションを指定した場合は、マスターユーザーの認証情報を提供するシークレットも選択する必要があります。マスターシークレットの認証情報には、このシークレットに保存されている認証情報を更新するアクセス許可が必要です。

6. [保存] を選択して、変更を保存するシークレットキーの初回の更新がトリガーされるようにします。

7. 別のマスターシークレットによるシークレットのローテーションを選択した場合は、マスターシークレットにアクセスするためのアクセス許可を手動で Lambda ローテーション関数に付与する必要があります。以下の手順に従います。a. ローテーション設定が完了すると、次のメッセージがページの上部に表示される場合がありま

す。

シークレット <シシシシシシシ> が正常に保存され、シークレットのローテーションが有効になりました。ローテーションの設定を終了するには、<シシシシシシシシシシシ Amazon シシシシシシシ (ARN)> のシークレットの値にアクセスするロールのアクセス許可を付与する必要があります。

メッセージが表示された場合は、ロールのポリシーを手動で変更し、マスターシークレットにアクセスするためのアクセス許可を、ローテーション関数 secretsmanager:GetSecretValueに付与する必要があります。セキュリティ上の理由から、Secrets Manager ではこの操作を実行

82



することはできません。ローテーションがマスターシークレットにアクセスできない場合は、以下のステップが完了するまで、シークレットのローテーションは失敗します。

b. Amazon リソースネーム (ARN) をメッセージからクリップボードにコピーします。c. メッセージで、「role」という単語のリンクを選択します。これにより、Secrets Manager が作

成した Lambda ローテーション関数にアタッチされたロールの詳細ページが IAM コンソールで開きます。

d. [Permissions] (アクセス許可) タブで、[Add inline policy] (インラインポリシーの追加) を選択し、以下の値を設定します。• [Service] (サービス) で、[Secrets Manager] (シークレットマネージャー) を選択します。• [Actions] (アクション) で、[GetSecretValue] を選択します。• [Resources (リソース)] で、[secret (シークレット)] リソースタイプエントリの横に、[Add

ARN (ARN の追加)] を選択します。• [Add ARN(s) (ARN の追加)] ダイアログボックスで、以前にコピーしたマスターシークレット

の ARN を貼り付けます。e. [Review policy] (ポリシーの確認) を選択してから、[Create policy] (ポリシーの作成) を選択しま

す。Note

前のステップで説明しているようにビジュアルエディタを使用する代わりに、以下のステートメントを既存または新規のポリシーに貼り付けることができます。

{ "Effect": "Allow", "Action": "secretsmanager:GetSecretValue", "Resource": "<ARN of the master secret>" }

f. AWS Secrets Manager コンソールに戻ります。

シークレットに割り当てられた Lambda 関数の ARN がない場合、Secrets Manager では関数を作成し、必要なすべてのアクセス許可を割り当て、その関数がデータベースで動作するように設定します。Secrets Manager は、ローテーションの間隔で指定された日数をカウントダウンします。その間隔がゼロに達すると、Secrets Manager はシークレットを再びローテーションし、次のサイクルの間隔をリセットします。このローテーションを無効にするまで継続されます。

AWS CLI または SDK オペレーションの使用最小限必要なアクセス権限

コンソールでローテーションを有効にして設定するには、次の管理ポリシーで提供されるアクセス権限を持っている必要があります。



次の Secrets Manager コマンドを使用して、サポートされている Amazon RDS データベースの既存のシークレットのローテーションを設定できます。

• API/SDK: RotateSecret• AWS CLI: RotateSecret

また、AWS CloudFormation と AWS Lambda のコマンドも使用する必要があります。次のコマンドの詳細については、各サービスのドキュメントを参照してください。

83

https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_RotateSecret.html

https://docs.aws.amazon.com/cli/latest/reference/secretsmanager/rotate-secret.html



Important

ローテーション関数は、このシークレットを使用して回転関数によってシークレットで使用されるシークレット値の正確な形式を決定します。各ローテーション関数で必要となるシークレット値の詳細については、Lambda ローテーション関数の作成に使用できる AWS テンプレート (p. 153) の該当するローテーション値のエントリで「予測される SecretString 値」を参照してください。

AWS Serverless Application Repository テンプレートを使用した Lambda ローテーション関数の作成

下記は、[AWS マネジメントコンソールの使用] タブで説明されているコンソールベースのローテーション設定と同等のものを実行する AWS CLI セッションの例です。AWS CloudFormation 変更セットを使用して関数を作成します。次に、作成される関数を必要なアクセス許可で設定します。最後に、完成した関数の ARN でシークレットを設定し、1 回更新してテストします。

次の例では汎用テンプレートを使用するため、テンプレートは先に示した最後の ARN を使用します。

最初のコマンドは、Secrets Manager から提供されたテンプレートに基づいて設定された AWSCloudFormation 変更セットをセットアップします。

データベースまたはサービスが Amazon VPC で提供される VPC に存在する場合、その VPC と通信するように関数を設定する、次の 4 番目のコマンドを含める必要があります。VPC がない場合は、コマンドをスキップできます。

また、VPC にパブリックインターネットへのアクセスがない場合、Secrets Manager のプライベートサービスエンドポイントを使用して VPC を設定する必要があります。次のコマンドの 5 番目がそれを行います。

使用するテンプレートを指定するには、--application-id パラメータを使用します。この値は、テンプレートの ARN です。AWS とその ARN で提供されるテンプレートのリストについては、「Lambda ローテーション関数の作成に使用できる AWS テンプレート (p. 153)」を参照してください。

また、このテンプレートには、次に示す例のように、--parameter-overrides で指定される追加のパラメータも必要です。ローテーションテンプレートには、ローテーション関数の作成に影響するテンプレートに、名前と値のペアとして 2 つの情報を送信するパラメータが必要です。

• エンドポイント – ローテーション関数でクエリを実行するサービスエンドポイントの URL。通常、この名前は https://secretsmanager.region.amazonaws.com です。

• functionname – このプロセスによって作成され、完成した Lambda ローテーション関数の名前。

$ aws serverlessrepo create-cloud-formation-change-set \ --application-id arn:aws:serverlessrepo:us-east-1:297356227824:applications/SecretsManagerRotationTemplate \ --parameter-overrides '[{"Name":"endpoint","Value":"https://secretsmanager.region.amazonaws.com"},{"Name":"functionName","Value":"MyLambdaRotationFunction"}]' \ --stack-name MyLambdaCreationStack{ "ApplicationId": "arn:aws:serverlessrepo:us-west-2:297356227824:applications/SecretsManagerRDSMySQLRotationSingleUser", "ChangeSetId": "arn:aws:cloudformation:us-west-2:123456789012:changeSet/EXAMPLE1-90ab-cdef-fedc-ba987EXAMPLE/EXAMPLE2-90ab-cdef-fedc-ba987EXAMPLE", "StackId": "arn:aws:cloudformation:us-west-2:123456789012:stack/aws-serverless-repository-MyLambdaCreationStack/EXAMPLE3-90ab-cdef-fedc-ba987EXAMPLE"}

次のコマンドは、先ほど作成した変更セットを実行します。change-set-name パラメータは、前のコマンドの ChangeSetId 出力から得られます。このコマンドでは何も出力されません。

84



$ aws cloudformation execute-change-set --change-set-name arn:aws:cloudformation:us-west-2:123456789012:changeSet/EXAMPLE1-90ab-cdef-fedc-ba987EXAMPLE/EXAMPLE2-90ab-cdef-fedc-ba987EXAMPLE

次のコマンドは、関数を呼び出すアクセス許可を Secrets Manager サービスに付与します。出力は、ロールの信頼ポリシーに追加されたアクセス許可を示します。

$ aws lambda add-permission \ --function-name MyLambdaRotationFunction \ --principal secretsmanager.amazonaws.com \ --action lambda:InvokeFunction \ --statement-id SecretsManagerAccess{ "Statement": "{\"Sid\":\"SecretsManagerAccess\",\"Effect\":\"Allow\",\"Principal\":{\"Service\":\"secretsmanager.amazonaws.com\"},\"Action\":\"lambda:InvokeFunction\",\"Resource\":\"arn:aws:lambda:us-west-2:123456789012:function:MyLambdaRotationFunction\"}"}

Secrets Manager では、VPC でデータベースを実行する場合に次のコマンドが必要です。VPC でデータベースを実行しない場合は、このコマンドをスキップします。Amazon RDS コンソールまたは awsrds describe-instances CLI コマンドのいずれかを使用して、Amazon RDS DB インスタンスのVPC 情報を調べます。続いて、次のコマンドに情報を追加して実行します。

$ aws lambda update-function-configuration \ --function-name arn:aws:lambda:us-west-2:123456789012:function:MyLambdaRotationFunction \ --vpc-config SubnetIds=<COMMA SEPARATED LIST OF VPC SUBNET IDS>,SecurityGroupIds=<COMMA SEPARATED LIST OF SECURITY GROUP IDs>

データベースインスタンスを持つ VPC および Lambda ローテーション関数がインターネットアクセスを持たない場合、Secrets Manager のプライベートサービスエンドポイントを持つ VPC を設定する必要があります。これにより、ローテーション関数は VPC 内のエンドポイントで Secrets Managerにアクセスできます。

$ aws ec2 create-vpc-endpoint --vpc-id <VPC ID> / --vpc-endpoint-type Interface / --service-name com.amazonaws.<region>.secretsmanager / --subnet-ids <COMMA SEPARATED LIST OF VPC SUBNET IDS> / --security-group-ids <COMMA SEPARATED LIST OF SECURITY GROUP IDs> / --private-dns-enabled

マスターシークレットを必要とするテンプレートを使用して関数を作成した場合は、次のステートメントを関数のロールポリシーに追加する必要があります。これによりマスターシークレットのシークレット値を取得するローテーション関数にアクセス許可を付与します。詳細な手順については、「別のマスターシークレットへのアクセス権限をローテーション関数に付与する (p. 48)」を参照してください。


最後に、シークレットにローテーション設定を適用し、最初のローテーションを実行します。

85

AWS Secrets Manager ユーザーガイドSecrets Manager が提供する Lambdaローテーション関数のカスタマイズ

$ aws secretsmanager rotate-secret \ --secret-id production/MyAwesomeAppSecret \ --rotation-lambda-arn arn:aws:lambda:us-west-2:123456789012:function:aws-serverless-repository-SecretsManagerRDSMySQLRo-10WGBDAXQ6ZEH \ --rotation-rules AutomaticallyAfterDays=7

サポートされている Amazon RDS データベースの Lambda ローテーション関数を独自に作成する場合、SecretsManagerRotationTemplate AWS CloudFormation テンプレートを使用する前述のステップに従うことをお勧めします。ほとんどのアクセス許可と構成設定は、Secrets Manager によって行われます。

Secrets Manager が提供する Lambda ローテーション関数のカスタマイズ組織の固有のセキュリティ要件を満たすよう Lambda ローテーション関数をカスタマイズすることができます。このような要件には以下が含まれます。

• 新しいバージョンのシークレットのテストを追加します。新しい認証情報にアクセス許可が正しく関連付けられていることを確認する必要があります。

• Secrets Manager が提供する Lambda 関数とは異なる戦略でシークレットをローテートしたいとします。

関数をカスタマイズするには、まず Secrets Manager が作成した関数を見つける必要があります。SecretsManager コンソールに関数の ARN が表示されない場合、AWS CLI または同等の AWS SDK オペレーションを使用して関数の ARN を取得できます。

$ aws secretsmanager describe-secret --secret-id MyDatabaseSecret

レスポンス内で RotationLambdaARN 値を探します。

Lambda ローテーション関数を編集するには



1. シークレットの Lambda ローテーション関数の名前を決定します。a. シークレットのリストから、ローテーションを変更するシークレットの名前を選択します。b. [Rotation configuration] (ローテーション設定) セクションで、ローテーション ARN を調べま

す。:function: に続く ARN の部分は、関数の名前です。2. AWS Lambda コンソール (https://console.aws.amazon.com/lambda/) を開きます。3. 変更する Lambda ローテーション関数の名前を選択します。4. 関数に必要な変更を行います。


1. シークレットの Lambda ローテーション関数の名前を決定します。これを行うには、次のコマンドを実行し、:function: に続く RotationLambdaARN のパートを調べます。

$ describe-secret --secret-id MySecret{

86

https://console.aws.amazon.com/lambda/

AWS Secrets Manager ユーザーガイドAmazon Redshift シークレットのローテーション

"ARN": "arn:aws:secretsmanager:us-west-2:123456789012:secret:MySecret-abc123", "Name": "MySecret", "RotationLambdaARN": "arn:aws:lambda:us-west-2:123456789012:function:name_of_rotation_lambda_function", "LastChangedDate": 1519940941.014, "SecretVersionsToStages": { "5eae5e4a-a683-469e-96e7-af9a8180fba5": [ "AWSCURRENT" ] }}

2. RotationLambdaARN レスポンスの値を調べます。これは Lambda ローテーション関数の ARNで、最後の部分は関数の名前を定義します。

3. AWS マネジメントコンソールにサインインし、https://console.aws.amazon.com/lambda/ にあるAWS Lambda コンソールを開きます。

4. 特定した Lambda 関数の名前を選択し、関数の詳細を表示します。5. [関数コート] セクションで、関数のソースコードを編集することができます。Secrets Manager

専用の Lambda 関数のコーディングの詳細については、「Lambda ローテーション関数の概要 (p. 109)」を参照してください。AWS Lambda Developer Guide の場合提供された Lambda 関数は、Python 2.7 環境をサポートしています。

Lambda 関数およびコーディング技術の詳細については、「AWS Lambda Developer Guide」を参照してください。

独自の Secrets Manager ローテーション関数のコーディングの詳細については、「Lambda ローテーション関数の理解とカスタマイズ (p. 108)」を参照してください。

Amazon Redshift シークレットのローテーションAmazon Redshift のシークレットを自動的にローテーションするよう、AWS Secrets Manager を設定できます。Secrets Manager では、Secrets Manager 提供の Lambda 関数を使用します。

Amazon Redshift データベースがサポートされている Secrets Manager

Secrets Manager では Amazon Redshift がサポートされています。つまり、ローテーションを有効にすると、Secrets Manager では、完全で、実行可能な設定済み Lambda ローテーション関数が提供されます。

[Credentials for Redshift (Redshift の認証情報)] シークレットタイプを使用してシークレットのローテーションを有効にすると、Secrets Manager では、Lambda ローテーション関数が自動的に作成され、設定されます。次に、Secrets Manager では、シークレットにその関数の Amazon リソースネーム (ARN) が追加されます。Secrets Manager では、関数に関連付けられた IAM ロールが作成され、必要なすべてのアクセス許可が設定されます。あるいは、新しいシークレットと同じローテーション戦略を使用する別のシークレットがすでにある場合は、既存の関数の ARN を指定して、そのローテーション戦略を両方のシークレットに使用できます。

Amazon Redshift クラスターが Amazon VPC 提供の VPC で実行されており、その VPC にパブリックインターネットアクセスがない場合、Secrets Manager ではさらに、その VPC 内で実行されるようにLambda 関数が設定されます。また、Lambda ローテーション関数が、必要な API オペレーションを呼び出すために、Secrets Manager サービスエンドポイントにアクセスできる必要があります。VPC の 1 つ以上のリソースがインターネットと通信する必要がある場合は、NAT ゲートウェイを使用して VPC を設定し、Lambda ローテーション関数がパブリック Secrets Manager サービスエンドポイントにクエリを実行できるようにすることができます。インターネットと通信する必要がない場合は、VPC 内からアクセスできるプライベート Secrets Manager サービスエンドポイントを使用して VPC を設定 (p. 77)できます。

それ以外の場合、通常必要なのは、Lambda 関数の作成に使用するテンプレートを決定するための詳細情報をいくつか入力することだけです。

87


https://docs.aws.amazon.com/lambda/latest/dg/


AWS Secrets Manager ユーザーガイドAmazon Redshift シークレットのローテーション

• シークレットを更新するアクセス許可を含む認証情報を使用してシークレットを指定します: ユーザーが自分のパスワードを変更できることがあります。その他の場合、ユーザーのアクセス許可は非常に制限されており、自分のパスワードを変更することはできません。代わりに、ユーザーの認証情報を変更するには、別の管理者または「スーパー」ユーザーの認証情報を使用する必要があります。

ローテーション関数によって認証情報のローテーションに使用されるシークレットを指定する必要があります。• [次のシークレットを使用]: 現在のシークレット内の認証情報にそれらのパスワードを変更するた

めのアクセス許可が含まれている場合は、このオプションを選択します。このオプションを選択すると、Secrets Manager は、各ローテーションで 1 人のユーザーのパスワードを変更するローテーション戦略を使用して Lambda 関数を実装します。このローテーション戦略の詳細については、「1 つのパスワードを使用してシングルユーザーの AWS Secrets Manager シークレットを更新する (p. 112)」を参照してください。

考慮事項

Secrets Manager は、このオプションを「低可用性」オプションとして提供します。ログインの失敗は、ローテーションによって古いパスワードが削除されてから、更新されたパスワードがシークレットの新しいバージョンとしてアクセス可能になるまでの間に発生する可能性があります。この時間枠は通常非常に短く、1 秒以下です。このオプションを選択した場合は、クライアントアプリケーションが､コード内で適切な「バックオフとジッターで再試行」戦略を実装していることを確認してください。サインインが長時間にわたって何度か失敗した場合にのみ、アプリケーションがエラーを生成します。

• [AWS Secrets Manager に以前に保存したシークレットを使用する]: 現在のシークレットの認証情報がより制限的なアクセス許可を持ち、保護されたサービスの認証情報の更新に使用できない場合、またはシークレットの高可用性が必要な場合は、このオプションを選択します。または、シークレットの高可用性が必要な場合、これを選択します。このオプションを選択するには、保護されたサービスの認証情報を作成および更新するアクセス許可を持つ認証情報を持つ別のマスターシークレットを作成します。次に､リストからそのマスターシークレットを選択します。このオプションを選択すると、Secrets Manager が Lambda 関数を実装します。この Lambda 関数には、シークレットで見つかった最初のユーザーのクローンを作成するローテーション戦略があります。次に、各ローテーションで 2 人のユーザーを交互に切り替え、アクティブになるユーザーのパスワードを更新します。このローテーション戦略の詳細については、「既存の 2 人のユーザーを切り替えることで AWS SecretsManager シークレットを更新する (p. 116)」を参照してください。

考慮事項

Secrets Manager は、このオプションを「高可用性」オプションとして提供します。これは、新しいバージョンの準備とテスト中に、古いバージョンのシークレットが引き続き動作し、サービスリクエストを処理するためです。Secrets Manager は、クライアントが新しいバージョンに切り替えるまで古いバージョンを非推奨にしません。このため、バージョン間の変更中にダウンタイムが発生しません。このオプションを使用するには、Lambda 関数を使用して、元のユーザーのアクセス許可を複製し、新しいユーザーに適用する必要があります。すると、この関数は、ローテーションごとに二人のユーザーを交互に切り替えます。ユーザーに付与されたアクセス許可を変更する必要がある場合は、両方のユーザーのアクセス許可を変更するようにしてください。

• この関数をカスタマイズすることができます: 組織の要件を満たすために Secrets Manager が提供するLambda ローテーション関数をカスタマイズすることができます。たとえば、関数のフェーズであるtestSecret (p. 111) を拡張し、アプリケーション固有のチェックを使用して、新しいバージョンをテストし、新しいシークレットが想定通りに機能するかを確認することができます。手順については、「Secrets Manager が提供する Lambda ローテーション関数のカスタマイズ (p. 86)」を参照してください。

トピック• Amazon Redshift シークレットのローテーションを有効にする (p. 89)

88



AWS Secrets Manager ユーザーガイドAmazon Redshift シークレットのローテーションを有効にする

Amazon Redshift シークレットのローテーションを有効にするAWS Secrets Manager コンソール (p. 89)、AWS CLI、または AWS SDK のどれかを使用して、Amazon Redshift サービスの認証情報を含むシークレットのローテーションを有効にすることができます。

Warning

ローテーションを有効にした場合は、シークレットを保存するとすぐにシークレットが一度ローテーションされます。ローテーションを有効にする前に、Secrets Manager からシークレットを取得するためにこのシークレットの認証情報を使用するすべてのアプリケーションを更新してください。初期ローテーション後は、元の認証情報は使用できない場合があります。アプリケーションを更新しなかった場合、古い認証情報が無効になるとアプリケーションはすぐに失敗します。


ローテーションを有効にするには、ネットワーク環境が正しく設定されている必要があります。

• Lambda 関数は Amazon Redshift サービスと通信できる必要があります。 Amazon Redshift クラスターを VPC で実行している場合は、その同じ VPC で Lambda 関数が実行されるように設定することをお勧めします。これにより、ローテーション関数とサービス間の直接接続が有効になります。これを設定するには、Lambda 関数の詳細ページで、[Network (ネットワーク)] セクションまでスクロールして、実行しているインスタンスと一致する [VPC] をドロップダウンリストから選択します。クラスターにアタッチされている EC2 セキュリティグループで、クラスターと Lambda 間の通信が有効になっていることも確認する必要があります。

• Lambda 関数は、Secrets Manager サービスエンドポイントと通信できる必要があります。 Lambdaローテーション関数を VPC 内で実行するように設定していない、または VPC にアタッチされた NATゲートウェイがあるために、関数がインターネットにアクセスできる場合、Secrets Manager の利用可能なパブリックエンドポイントを使用できます。あるいは、インターネットに接続されていない VPC で実行されるように Lambda 関数が設定されている場合は、プライベート Secrets Manager サービスエンドポイントを使用して VPC を設定 (p. 77)できます。

サポートされている Amazon Redshift クラスターシークレットのローテーションを有効化、設定する








2. ローテーションを有効化するシークレットの名前を選択します。

89








3. [Configure automatic rotation(自動ローテーションの設定)] セクションで､[Enable automaticrotation(自動ローテーションを有効化する)] を選択します｡これにより、このセクションの他のコントロールが有効になります。

4. [Select rotation period (保持期間の選択)] で、事前定義された値 — の 1 つを選択するか、[カスタム] を選択してから、ローテーション間の日数を入力します。コンプライアンス要件を満たすためにシークレットをローテーションする場合、この値をコンプライアンスに義務付けられた間隔から1 日を引いた値に設定することをお勧めします。


Note

Secrets Manager で提供される Lambda 関数を使用して 2 人のユーザーを交互に使用する場合、次のステップで 2 番目の「master secret」オプションを選択すると、コンソールはこのテンプレートを使用します。次に、ローテーション期間をコンプライアンス指定の最小間隔の半分に設定する必要があります。Secrets Manager は、アクティブに使用されていない場合は古い認証情報を 1 回の追加ローテーションサイクルで保持し、2 回目のローテーション後に新しいパスワードでユーザーを更新した後にのみ古い認証情報を無効にします。ローテーション関数を変更し、新しいシークレットがアクティブになったら直ちに古い認証情報を無効にする場合は、コンプライアンスで義務付けられた最小値までローテーション間隔を延長できます。AWSPREVIOUS ステージングラベルを使用し、1 つの追加のサイクルについて古い認証情報をアクティブなままにすると、高速復旧に使用できる「最後の既知の正常な」認証情報のセットが提供されます。エラーが発生して現在の認証情報が中断された場合、AWSCURRENT ステージングラベルを AWSPREVIOUS ラベルがあるバージョンに簡単に移動できます。これで、顧客は再度リソースにアクセスできます。詳細については、「既存の 2 人のユーザーを切り替えることで AWS Secrets Manager シークレットを更新する (p. 116)」を参照してください。


a. [新しい Lambda 関数を作成してローテーションを実行する] を選択します。b. [Lambda function name (Lambda 関数名)] に、Secrets Manager によって作成される Lambda

関数に割り当てる名前を入力します。c. このローテーション関数で使用できる認証情報を使用してシークレットを指定します。保護さ

れたサービスでユーザー名とパスワードを更新するためのアクセス許可が必要です。• [次のシークレットを使用]: このシークレット内の認証情報に、サービスでそれらのパスワー

ドを変更するためのアクセス許可が含まれている場合は、このオプションを選択します。このオプションを選択すると、Secrets Manager は、ローテーションごとにパスワードを変更した後に単一のユーザーでシークレットをローテーションする Lambda 関数が作成されます。

Note


90



• [AWS Secrets Manager で以前に保存したシークレットを使用]: 現在のシークレットの認証情報に認証情報を更新するアクセス許可がない場合、またはシークレットの高可用性が必要な場合は、このオプションを選択します。このオプションを選択するには、このシークレットの認証情報を更新するアクセス許可を持つ認証情報を持つ別の「マスター」シークレットを作成する必要があります。次に､リストからマスターシークレットを選択します。このオプションを選択すると、Secrets Manager は、ローテーションごとに新しいユーザーとパスワードを作成し、古いユーザーを非推奨にすることによってシークレットを更新するLambda 関数を作成します。

Note

Secrets Manager は、このオプションを「高可用性」オプションとして提供します。これは、新しいバージョンの準備とテスト中に、古いバージョンのシークレットが引き続き動作し、サービスリクエストを処理するためです。Secrets Managerは、クライアントが新しいバージョンに切り替えるまで古いバージョンを非推奨にしません。このため、バージョン間の変更中にダウンタイムが発生しません。このオプションを使用するには、Lambda 関数を使用して、元のユーザーのアクセス許可を複製し、新しいユーザーに適用する必要があります。すると、この関数は、ローテーションごとに二人のユーザーを交互に切り替えます。ユーザーに付与されたアクセス許可を変更する必要がある場合は、両方のユーザーのアクセス許可を変更するようにしてください。

• 別のシークレット用にすでに作成済みの Lambda 関数を使用するa. [既存の Lambda 関数を使用してローテーションを実行する] を選択します。b. ドロップダウンリストから Lambda 関数を選択します。c. 選択したローテーション関数のタイプを指定します。

• シングルユーザーローテーション: パスワードを変更するアクセス許可を持つユーザーの認証情報を格納するシークレットのローテーション関数。Secrets Manager では、関数の作成時に [このシークレットを使用する] オプションを選択すると、このタイプの関数が作成されます。

• マルチユーザーのローテーション: 自分のパスワードを変更するアクセス許可を持たないユーザーの認証情報を保存するシークレットのローテーション関数。この関数には、このシークレットのユーザーの認証情報を変更するアクセス許可を持つユーザーの認証情報を格納する別のマスターシークレットが必要です。

• Secrets Manager は、[AWS Secrets Manager で以前に保存したシークレットを使用] オプションを選択すると、このタイプの関数を作成します。

d. 2 番目の「マスターシークレット」オプションを指定した場合は、マスターユーザーの認証情報を提供するシークレットも選択する必要があります。マスターシークレットの認証情報には、このシークレットに保存されている認証情報を更新するアクセス許可が必要です。



す。


メッセージが表示された場合は、ロールのポリシーを手動で変更し、マスターシークレットにアクセスするためのアクセス許可を、ローテーション関数 secretsmanager:GetSecretValueに付与する必要があります。セキュリティ上の理由から、Secrets Manager ではこの操作を実行することはできません。マスターシークレットにアクセスできない場合は、以下のステップが完了するまで、シークレットのローテーションは失敗します。

91


b. Amazon リソースネーム (ARN) をメッセージからクリップボードにコピーします。c. メッセージで、「role」という単語のリンクを選択します。これにより、Secrets Manager が自

動的に作成した、Lambda ローテーション関数にアタッチされたロールの詳細ページが IAM コンソールで開きます。

d. [Permissions] (アクセス許可) タブで、[Add inline policy] (インラインポリシーの追加) を選択し、以下の値を設定します。• [Service] (サービス) で、[Secrets Manager] (シークレットマネージャー) を選択します。• [Actions] (アクション) で、[GetSecretValue] を選択します。• [Resources (リソース)] で、[secret (シークレット)] リソースタイプエントリの横に、[Add

ARN (ARN の追加)] を選択します。• [Add ARN(s)] (ARN の追加) ダイアログボックスで、以前にコピーしたマスターシークレット

の ARN を貼り付けます。e. [Review policy] (ポリシーの確認) を選択してから、[Create policy] (ポリシーの作成) を選択しま

す。

Note




シークレットに割り当てられた Lambda 関数の ARN がまだ存在しない場合、Secrets Manager はその関数を作成し、必要なすべてのアクセス許可を割り当て、その関数がサービスで動作するように設定します。Secrets Manager は、ローテーションの間隔で指定された日数をカウントダウンします。ローテーションの間隔がゼロに達すると、Secrets Manager はシークレットを再びローテーションし、次のサイクルの間隔をリセットします。このローテーションを無効にするまで継続されます。

AWS CLI または SDK オペレーションの使用


コンソールでローテーションを有効にして設定するには、次の管理ポリシーで提供されるアクセス許可が付与されている必要があります。


• IAMFullAccess – ロールを作成し、そのロールにアクセス許可ポリシーをアタッチするために必要な IAM アクセス許可を付与します。

以下の Secrets Manager コマンドを使用して、Amazon Redshift の既存のシークレットのローテーションを設定できます。


また、AWS CloudFormation と AWS Lambda のコマンドも使用する必要があります。次のコマンドの詳細については、各サービスのドキュメントを参照してください。

92




Important

シークレットで使用するローテーション関数によって、シークレットで使用する必要があるシークレット値の正確な形式が決まります。各ローテーション関数で必要となるシークレット値の詳細については、「Lambda ローテーション関数の作成に使用できる AWS テンプレート (p. 153)」の該当するローテーション値の「予測される SecretString 値」エントリを参照してください。

AWS Serverless Application Repository テンプレートを使用して、Lambda ローテーション関数を作成するには

ここでは、[AWS マネジメントコンソールの使用] タブで説明されているコンソールベースのローテーション設定と同等のものを実行する AWS CLI セッションの例を示します。AWS CloudFormation 変更セットを使用して関数を作成します。次に、作成される関数を必要なアクセス許可で設定します。最後に、完成した関数の ARN でシークレットを設定し、1 回更新してテストします。

次の例では汎用テンプレートを使用するため、テンプレートは先に示した最後の ARN を使用します。

最初のコマンドは、Secrets Manager から提供されたテンプレートに基づいて AWS CloudFormation変更セットをセットアップします。

サービスが Amazon VPC 提供の VPC に存在する場合、その VPC と通信するように関数を設定する、以下の 4 番目のコマンドを含める必要があります。VPC が関連しない場合、このコマンドはスキップしてかまいません。

VPC にパブリックインターネットへのアクセスがない場合、Secrets Manager のプライベートサービスエンドポイントを使用して VPC を設定する必要があります。次のコマンドの 5 番目がそれを行います。

使用するテンプレートを指定するには、--application-id パラメータを使用します。この値は、テンプレートの ARN です。AWS とその ARN で提供されるテンプレートのリストについては、「Lambda ローテーション関数の作成に使用できる AWS テンプレート (p. 153)」を参照してください。

また、このテンプレートには、次に示す例のように、--parameter-overrides で指定される追加のパラメータも必要です。Secrets Manager では、このパラメータは、名前と値のペアをテンプレートに送信してローテーション関数の作成に影響を与えるため、2つの情報を送信する必要があります。




93




次のコマンドは、Secrets Manager サービスに、お客様の代わりに関数を呼び出すアクセス許可を付与します。出力は、ロールの信頼ポリシーに追加されたアクセス許可を示します。

$ aws lambda add-permission \ --function-name MyLambdaRotationFunction \ --principal secretsmanager.amazonaws.com \ --action lambda:InvokeFunction \ --statement-id SecretsManagerAccess{ "Statement": "{\"Sid\":\"SecretsManagerAccess\",\"Effect\":\"Allow\",\"Principal\":{\"Service\":\"secretsmanager.amazonaws.com\"},\"Action\":\"lambda:InvokeFunction\",\"Resource\":\"arn:aws:lambda:us-west-2:123456789012:function:MyLambdaRotationFunction\"}"}

Secrets Manager では、VPC でサービスを実行する場合、次のコマンドが必要です。それ以外の場合は、このコマンドをスキップします。Amazon RDS コンソールまたは aws rds describe-instances CLI コマンドのいずれかを使用して、Amazon Redshift クラスターの VPC 情報を調べます。続いて、次のコマンドにその情報を指定して実行します。


サービスインスタンスを持つ VPC および Lambda ローテーション関数がインターネットアクセスを持たない場合、Secrets Manager のプライベートサービスエンドポイントを持つ VPC を設定する必要があります。これにより、ローテーション関数は VPC 内のエンドポイントで Secrets Manager にアクセスできます。



{ "Action": "secretsmanager:GetSecretValue", "Resource": "arn:aws:secretsmanager:region:123456789012:secret:MyDatabaseMasterSecret",

94

AWS Secrets Manager ユーザーガイドAmazon DocumentDB シークレットのローテーション

"Effect": "Allow" },



独自の Lambda ローテーション関数を Amazon Redshift 用に作成する場合でも、SecretsManagerRotationTemplate AWS CloudFormation テンプレートを使用する前述のステップに従うことをお勧めします。テンプレートを使用すると、ほとんどのアクセス許可と構成設定のセットアップが Secrets Manager によって行われるようになります。

Amazon DocumentDB シークレットのローテーション

Amazon DocumentDB のシークレットを自動的にローテーションするように、AWS Secrets Manager を設定できます。Secrets Manager では、Secrets Manager 提供の Lambda 関数を使用します。

サポートされているサービスとしての Amazon DocumentDB

Secrets Manager は、Amazon DocumentDB をサポートし、Amazon DocumentDB に対して設計された完全で、実行可能な Lambda ローテーション関数を提供します。

[Credentials for DocumentDB (DocumentDB の認証情報)] シークレットタイプを使用してシークレットのローテーションを有効にすると、Secrets Manager では、Lambda ローテーション関数が自動的に作成され、設定されます。その後、Secrets Manager は、関数の Amazon リソースネーム (ARN) があるシークレットを保持します。Secrets Manager は、関数に関連付けられている IAM ロールを作成し、必要なすべてのアクセス許可があるロールを設定します。あるいは、新しいシークレットと同じローテーション戦略を使用する別のシークレットがすでにある場合は、既存の関数の ARN を指定して両方のシークレットに使用できます。

Amazon DocumentDB インスタンスが Amazon VPC 提供の VPC で実行されていて、その VPC に公共インターネットへのアクセスがない場合、Secrets Manager は、Lambda 関数をその VPC 内で実行できるように設定します。必要な API オペレーションを呼び出すため、Lambda ローテーション関数は、SecretsManager サービスエンドポイントにアクセスできなければなりません。VPC の 1 つ以上のリソースがインターネットと通信する必要がある場合は、Lambda ローテーション関数が公共の Secrets Managerサービスエンドポイントにクエリできるように、NAT ゲートウェイを使用して VPC を設定することができます。他にインターネットと通信する必要性がない場合は、VPC 内からアクセスできるプライベートSecrets Manager サービスエンドポイント (p. 77)を使用して VPC を設定します。

それ以外の場合、Lambda 関数の作成にどのテンプレートを使用するかなど、いくつかの詳細情報を入力するだけで十分です。

• 認証情報およびアクセス許可でシークレットを指定してシークレットをローテーションする: スーパーユーザーのみが自分のパスワードを変更できます。他のユーザーはアクセス許可が制限されているため、自分のパスワードを変更できません。ユーザーの認証情報を変更するには、別の管理者またはスーパーユーザーの認証情報を使用する必要があります。

ローテーション関数が保護されたデータベースの認証情報を更新するために使用できるシークレットを指定する必要があります。

95

AWS Secrets Manager ユーザーガイドAmazon DocumentDB シークレットのローテーションを有効にする

• [次のシークレットを使用]: 現在のシークレットにスーパーユーザーの認証情報がある場合は、このオプションを選択します。このオプションを選択すると、Secrets Manager は、各ローテーションで 1人のユーザーのパスワードを変更するローテーション戦略を使用して Lambda 関数を実装します。このローテーション戦略の詳細については、「1 つのパスワードを使用してシングルユーザーの AWSSecrets Manager シークレットを更新する (p. 112)」を参照してください。

考慮事項


• [AWS Secrets Managerで以前に保存したシークレットを使用]: シークレットの高可用性が必要な場合は、これを選択します。このオプションを選択するには、セキュリティで保護されたサービスの認証情報を作成および更新するアクセス許可がある認証情報を持つ別の「マスター」シークレットを作成する必要があります。次に､リストからマスターシークレットを選択します。このオプションを選択すると、Secrets Manager が Lambda 関数を実装します。この Lambda 関数には、シークレットで見つかった最初のユーザーのクローンを作成するローテーション戦略があります。Secrets Manager は、各ローテーションで 2 人のユーザーを交互に切り替え、アクティブになるユーザーのパスワードを更新します。このローテーション戦略の詳細については、「既存の 2 人のユーザーを切り替えることでAWS Secrets Manager シークレットを更新する (p. 116)」を参照してください。

Note

Secrets Manager は、このオプションを「高可用性」オプションとして提供します。これは、新しいバージョンの準備とテスト中に、古いバージョンのシークレットが引き続き動作し、サービスリクエストを処理するためです。Secrets Manager は、次のローテーションまで古いバージョンを非推奨にしません。このため、バージョン間の変更中にダウンタイムが発生しません。このオプションを使用するには、Lambda 関数を使用して、元のユーザーのアクセス許可を複製し、新しいユーザーに適用する必要があります。すると、この関数は、ローテーションごとに二人のユーザーを交互に切り替えます。ユーザーに付与されたアクセス許可を変更する必要がある場合は、両方のユーザーのアクセス許可を変更するようにしてください。

• 関数をカスタマイズすることができます: 組織のセキュリティ要件を満たすため、Lambda が提供したSecrets Manager ローテーション関数をカスタマイズすることができます。たとえば、関数のフェーズである testSecret (p. 111) を拡張し、アプリケーション固有のチェックを使用して、新しいバージョンをテストし、新しいシークレットが想定通りに機能するかを確認することができます。手順については、「Secrets Manager が提供する Lambda ローテーション関数のカスタマイズ (p. 86)」を参照してください。

トピック• Amazon DocumentDB シークレットのローテーションを有効にする (p. 96)

Amazon DocumentDB シークレットのローテーションを有効にするAWS Secrets Manager コンソール (p. 97)、AWS CLI、またはいずれかの AWS SDK を使用して、Amazon DocumentDB データベースの認証情報を含むシークレットのローテーションを有効にすることができます。

96



Warning

ローテーションを有効にした場合は、シークレットを保存するとすぐにシークレットが一度ローテーションされます。ローテーションを有効にする前に、シークレットの認証情報を使用するすべてのアプリケーションが Secrets Manager からシークレットを取得するように更新されていることを確認してください。初期ローテーション後は、元の認証情報は使用できない場合があります。すべてのアプリケーションを更新しないと、古い認証情報が無効になるためにエラーが発生する可能性があります。


ローテーションを正常に有効にするには、ネットワーク環境を正しく設定します。

• Lambda 関数は、データベースと通信できる必要があります。 VPC で、DocumentDB データベースインスタンスを実行している場合、同じ VPC で Lambda 関数を実行することをお勧めします。これにより、ローテーション関数とサービス間の直接接続が有効になります。これを設定するには、Lambda 関数の詳細ページで、[ネットワーク] セクションまで下にスクロールし、実行しているインスタンスと一致する [VPC] をドロップダウンリストから選択します。また、インスタンスにアタッチされた EC2 セキュリティグループが、インスタンスと Lambda 間での通信を有効化することを確認する必要があります。

• Lambda 関数は、Secrets Manager サービスエンドポイントと通信できる必要があります。 Lambdaローテーション関数を VPC 内で実行するように設定していないか、またはアタッチされた NAT ゲートウェイが VPC にあるために関数がインターネットにアクセスできる場合、Secrets Manager の利用可能なパブリックエンドポイントのいずれかを使用できます。あるいは、インターネットに接続されていない VPC で実行されるように Lambda 関数が設定されている場合は、プライベート Secrets Managerサービスエンドポイントのある VPC を設定 (p. 77)できます。

Amazon DocumentDB シークレットのローテーションの有効化と設定










4. [Select rotation period (保持期間の選択)] で、事前定義された値 — の 1 つを選択するか、[カスタム] を選択してから、ローテーション間の日数を入力します。コンプライアンス要件を満たすためにシークレットをローテーションする場合、この値をコンプライアンスに義務付けられた間隔から1 日を引いた値に設定することをお勧めします。

97









Note

Secrets Manager で提供される Lambda 関数を使用して 2 人のユーザーを交互に使用する場合、次のステップで 2 番目の master secret オプションを選択した場合、コンソールはこのテンプレートを使用します。ローテーション期間をコンプライアンス指定の最小間隔の半分に設定する必要があります。Secrets Manager は、アクティブに使用されていない場合、古い認証情報を 1 回のローテーションサイクルで保持します。次に、SecretsManager が 2 回目のローテーション後に新しいパスワードでユーザーを更新した後、古い認証情報を無効にします。ローテーション関数を変更し、新しいシークレットがアクティブになったら直ちに古い認証情報を無効にする場合は、コンプライアンスで義務付けられた最小値までローテーション間隔を延長できます。AWSPREVIOUS ステージングラベルを使用し、1 つの追加のサイクルについて古い認証情報をアクティブなままにすると、高速復旧に使用できる最後の既知の正常な認証情報のセットが提供されます。エラーが発生して現在の認証情報が中断された場合、AWSCURRENT ステージングラベルを AWSPREVIOUS ラベルがあるバージョンに簡単に移動できます。その後、リソースに再びアクセスできるようになります。詳細については、「既存の 2 人のユーザーを切り替えることで AWS Secrets Manager シークレットを更新する (p. 116)」を参照してください。


a. [新しい Lambda 関数を作成してローテーションを実行する] を選択します。b. [Lambda function name (Lambda 関数名)] に、Secrets Manager によって作成される Lambda

関数に割り当てる名前を入力します。c. このローテーション関数で使用できる認証情報を使用してシークレットを指定します。保護さ

れたデータベースでユーザー名とパスワードを更新するためのアクセス許可が必要です。• [次のシークレットを使用]: このシークレットの認証情報にデータベース内でパスワードを変

更するアクセス許可がある場合、このオプションを選択します。このオプションを選択すると、Secrets Manager は、ローテーションごとにパスワードが変更される単一のユーザーでシークレットをローテーションする Lambda 関数が作成されます。

Note

Secrets Manager は、このオプションを低可用性オプションとして提供します。ログインの失敗は、ローテーションによって古いパスワードが削除されてから、更新されたパスワードがシークレットの新しいバージョンとしてアクセス可能になるまでの間に発生する可能性があります。この時間枠は通常非常に短く、1 秒以下です。このオプションを選択した場合は、クライアントアプリケーションが､コード内で適切な「バックオフとジッターで再試行」戦略を実装していることを確認してください。サインインが長時間にわたって何度か失敗した場合にのみ、アプリケーションがエラーを生成します。

• [AWS Secrets Manager で以前に保存したシークレットを使用]: 現在のシークレットの認証情報でアクセス許可の更新ができない場合、またはシークレットの高可用性が必要な場合は、このオプションを選択します。このオプションを選択するには、このシークレットの認証情報を更新する認証情報およびアクセス許可を持つ別の「マスター」シークレットを作成する必要があります。次に､リストからマスターシークレットを選択します。このオプションを選択すると、Secrets Manager は、ローテーションごとに新しいユーザーとパスワードを作成し、古いユーザーを非推奨にすることによってシークレットを更新する Lambda 関数を作成します。

98



Note

Secrets Manager は、このオプションを高可用性オプションとして提供します。これは、新しいバージョンの準備とテスト中に、古いバージョンのシークレットが引き続き動作し、サービスリクエストを処理するためです。Secrets Manager は、次のローテーションまで古いバージョンを非推奨にしません。このため、バージョン間の変更中にダウンタイムが発生しません。このオプションを使用するには、Lambda 関数を使用して、元のユーザーのアクセス許可を複製し、新しいユーザーに適用する必要があります。すると、この関数は、ローテーションごとに二人のユーザーを交互に切り替えます。ユーザーに付与されたアクセス許可を変更する必要がある場合は、両方のユーザーのアクセス許可を変更するようにしてください。

• 別のシークレット用にすでに作成済みの Lambda 関数を使用するa. [既存の Lambda 関数を使用してローテーションを実行する] を選択します。b. ドロップダウンリストから Lambda 関数を選択します。c. ローテーション関数のタイプを指定します。

• 単一ユーザーのローテーション: パスワードを変更するアクセス許可があるユーザーの認証情報を保存するシークレットで使用するローテーション関数。このタイプの関数は、関数の作成時に [次のシークレットを使用] オプションを選択した場合に作成します。

• マルチユーザーのローテーション: パスワードを変更できないユーザーの認証情報を保存するシークレットで使用するローテーション関数。この関数には、このシークレットのユーザーの認証情報を変更するアクセス許可を持つユーザーの認証情報を格納する別のマスターシークレットが必要です。このタイプの関数は、[AWS Secrets Manager で以前に保存したシークレットを使用] オプションを選択した場合に作成します。

d. 2 番目の「マスターシークレット」オプションを指定した場合は、マスターユーザー認証情報を指定できるシークレットも選択する必要があります。マスターシークレットの認証情報には、このシークレットに保存されている認証情報を更新するアクセス許可が必要です。



す。


メッセージが表示された場合は、ロールのポリシーを手動で変更し、マスターシークレットにアクセスするためのアクセス許可を、ローテーション関数 secretsmanager:GetSecretValueに付与する必要があります。セキュリティ上の理由から、Secrets Manager ではこの操作を実行することはできません。Secrets Manager がマスターシークレットにアクセスできない場合、以下のステップが完了するまで、シークレットのローテーションは失敗します。

b. Amazon リソースネーム (ARN) をメッセージからクリップボードにコピーします。c. メッセージで、「role」という単語のリンクを選択します。これにより、Secrets Manager が作

成した Lambda ローテーション関数にアタッチされたロールの詳細ページが IAM コンソールで開きます。

d. [Permissions] (アクセス許可) タブで、[Add inline policy] (インラインポリシーの追加) を選択し、以下の値を設定します。• [Service] (サービス) で、[Secrets Manager] (シークレットマネージャー) を選択します。• [Actions] (アクション) で、[GetSecretValue] を選択します。

99


• [Resources (リソース)] で、[secret (シークレット)] リソースタイプエントリの横に、[AddARN (ARN の追加)] を選択します。

• [Add ARN(s) (ARN の追加)] ダイアログボックスで、以前にコピーしたマスターシークレットの ARN を貼り付けます。

e. [Review policy] (ポリシーの確認) を選択してから、[Create policy] (ポリシーの作成) を選択します。

Note




シークレットに割り当てられた Lambda 関数に ARN がない場合、Secrets Manager では関数を作成し、必要なすべてのアクセス許可を割り当て、その関数がデータベースで動作するように設定します。Secrets Manager は、ローテーションの間隔で指定された日数をカウントダウンします。カウントがゼロに達すると、Secrets Manager はシークレットを再びローテーションし、次のサイクルの間隔をリセットします。このローテーションを無効にするまで継続されます。

AWS CLI または SDK オペレーションの使用最小限必要なアクセス権限




次の Secrets Manager コマンドを使用して、サポートされている Amazon RDS データベースの既存のシークレットのローテーションを設定できます。


また、AWS CloudFormation と AWS Lambda のコマンドも使用する必要があります。以下で使用されているコマンドの詳細については、それらのサービスのドキュメントを参照してください。

Important

ローテーション関数は、シークレットで使用する必要があるシークレット値の正確な形式を決定します。シークレット値に関する各ローテーション関数の要件の詳細については、Lambda ローテーション関数の作成に使用できる AWS テンプレート (p. 153) の該当するローテーション値のエントリで「予測される SecretString 値」を参照してください。

AWS Serverless Application Repository テンプレートを使用した Lambda ローテーション関数の作成

下記は、[AWS マネジメントコンソールの使用] タブで説明されているコンソールベースのローテーション設定と同等なものを実行する AWS CLI セッションの例です。AWS CloudFormation 変更セット

100




を使用して関数を作成します。次に、作成される関数を必要なアクセス許可で設定します。最後に、完成した関数の ARN でシークレットを設定し、1 回更新してテストします。

次の例では汎用テンプレートを使用するため、先ほど示した最後の ARN を使用します。

最初のコマンドは、Secrets Manager から提供されたテンプレートに基づいて AWS CloudFormation変更セットをセットアップします。

データベースまたはサービスが Amazon VPC で提供される VPC に存在する場合、その VPC と通信するように関数を設定する、次の 4 番目のコマンドを含める必要があります。VPC がない場合は、コマンドをスキップできます。

また、VPC にパブリックインターネットへのアクセスがない場合、Secrets Manager のプライベートサービスエンドポイントを使用して VPC を設定する必要があります。次のコマンドの 5 番目がそれを行います。

また、このテンプレートには、次に示す例のように、--parameter-overrides で指定される追加のパラメータも必要です。このパラメータでは、ローテーション関数の作成に影響を与える名前と値のペアの 2 つの情報をテンプレートに送信するために Secrets Manager が必要です。






次のコマンドは、Secrets Manager サービスに、お客様に代わって関数を呼び出すアクセス許可を付与します。出力は、ロールの信頼ポリシーに追加されたアクセス許可を示します。

$ aws lambda add-permission \ --function-name MyLambdaRotationFunction \ --principal secretsmanager.amazonaws.com \ --action lambda:InvokeFunction \ --statement-id SecretsManagerAccess{ "Statement": "{\"Sid\":\"SecretsManagerAccess\",\"Effect\":\"Allow\",\"Principal\":{\"Service\":\"secretsmanager.amazonaws.com\"},

101


\"Action\":\"lambda:InvokeFunction\",\"Resource\":\"arn:aws:lambda:us-west-2:123456789012:function:MyLambdaRotationFunction\"}"}

VPC でデータベースを実行する場合、Secrets Manager に次のコマンドが必要となります。そうでない場合は、このコマンドをスキップします。Amazon RDS コンソールまたは aws rds describe-instances CLI コマンドのいずれかを使用して、Amazon RDS DB インスタンスの VPC 情報を見つけます。続いて、次のコマンドに情報を追加して実行します。


データベースインスタンスを持つ VPC および Lambda ローテーション関数がインターネットアクセスを持たない場合、Secrets Manager のプライベートサービスエンドポイントを持つ VPC を設定する必要があります。これにより、ローテーション関数は VPC 内のエンドポイントで Secrets Managerにアクセスできます。






独自の Lambda ローテーション関数を作成する場合、SecretsManagerRotationTemplateAWSCloudFormation テンプレートを使用する前述のステップに従う必要があります。ほとんどのアクセス許可と構成設定は、Secrets Manager によって行われます。

102

AWS Secrets Manager ユーザーガイド他のシークレットの更新

他のデータベースやサービスのローテーションとAWS Secrets Manager のシークレット

保護されたサービスまたはデータベースのシークレットを自動的に更新するように､AWS SecretsManager を構成できます。Secrets Manager は､Amazon RDS データベースのシークレットを更新する (p. 78)方法をネイティブで理解しています。ただし、Secrets Manager では、他のデータベースまたはサードパーティーのサービスでシークレットを更新することもできます。各サービスまたはデータベースにはシークレットを構成する独自の方法があるため、Secrets Manager は､選択したデータベースまたはサービスと連携するように記述した Lambda 関数を使用します。Lambda 関数をカスタマイズして、シークレットを更新する方法のサービス固有の詳細を実装します。

別のデータベースまたは他のタイプのサービスのシークレットのローテーションを有効にする場合は、Lambda 関数を作成して構成し、コードを記述する必要があります。

他のデータベースやサービスのローテーションを有効にする前に、Lambda ローテーション関数を作成する必要があります。AWS は、最初のステップとして使用できる汎用的なテンプレートの Lambda ローテーション関数を提供しています。次の手順では、このテンプレートに基づいて、新しい Lambda 関数を作成する方法について説明しています。それから、ローテーションを有効に (p. 106)すると、後は、完成した関数の Amazon リソースネーム (ARN) をシークレットに追加するだけです。

トピック• 他のデータベースやサービスのローテーションと AWS Secrets Manager のシークレット (p. 103)• 別のデータベースまたはサービスのシークレットのローテーションを有効にする (p. 106)

他のデータベースやサービスのローテーションとAWS Secrets Manager のシークレットサポートされている Amazon RDS データベース以外に別のアプリケーションのシークレットを作成する場合、AWS Secrets Manager は Lambda ローテーション関数を作成しません。関数を作成して設定する必要があります。次に、完成したシークレット関数の Amazon リソースネーム (ARN) をシークレットに指定します。Secrets Manager コンソールを使用してこれを行うには、AWS CLI、または AWS SDK のいずれかを使用します。

このトピックでは、作成して実行した AWS CloudFormation 変更セットを使用して Lambda 関数を作成する方法について説明します。次に、アクセス許可をアタッチします。この時点で、コードを編集してローテーション関数を望みどおりに機能させることができます。最後に、完成した関数をシークレットと関連付けて、ローテーションがトリガーされるたびに、Secrets Manager がこの関数を呼び出すようにします。

完全に実装する必要がある「汎用」テンプレートを指定できます。または、特定のデータベースまたはサービスにローテーション戦略を完全に実装し、ニーズに合わせて関数をカスタマイズするための開始点としてそれを使用するテンプレートのいずれかを選択できます。


ローテーションを有効化および設定するコマンドを実行するには、次の権限が必要です。

• serverlessrepo:CreateCloudFormationChangeSet – Lambda ローテーション関数を設定および作成する AWS CloudFormation 変更セットを作成する

• cloudformation:ExecuteChangeSet – Lambda ローテーション関数を作成および設定するAWS CloudFormation 変更セットを実行する

• lambda:AddPermission – Lambda ローテーション関数の作成後に必要なアクセス許可を追加する

103


• lambda:InvokeFunction – シークレットにローテーション関数をアタッチする• lambda:UpdateFunctionConfiguration – コンソールが Lambda 関数の VPC 設定を更新

して VPC 内に存在するデータベースまたはサービスと通信できるようにする• secretsmanager:RotateSecret – 初回ローテーションを設定およびトリガーする

IAM ユーザーまたはロールにこれらのすべてのアクセス許可を付与するには、AWS 管理ポリシーに SecretsManagerReadWrite をアタッチします。

次のコマンドは、汎用的な SecretsManagerRotationTemplate を Lambda 関数に適用します。このテンプレートは AWS Serverless Application Repository からのもので、AWS CloudFormation で使用され、ほとんどのステップを自動化します。テンプレートの完全なセット、および指定する必要がある ARNについては、「Lambda ローテーション関数の作成に使用できる AWS テンプレート (p. 153)」を参照してください。

汎用テンプレートの ARN を使用し、ここに示されているとおりに入力します。

arn:aws:serverlessrepo:us-east-1:297356227824:applications/SecretsManagerRotationTemplate

認証情報を使用するデータベースまたはサービスが、Amazon VPC から提供される VPC に存在する場合は、コマンドをステップ 5 で含める必要があります。このコマンドはその VPC と通信するように関数を設定します。VPC がない場合は、コマンドをスキップできます。

カスタマイズ用汎用テンプレートとしての Lambda ローテーション関数の作成

1. 最初のコマンドは、Secrets Manager から提供されたテンプレートに基づいて AWS CloudFormation変更セットをセットアップします。テンプレートには、Secrets Manager エンドポイント URL と、テンプレートによって生成される Lambda ローテーション関数の名前の 2 つのパラメータを指定します。

$ aws serverlessrepo create-cloud-formation-change-set \ --application-id arn:aws:serverlessrepo:us-east-1:297356227824:applications/SecretsManagerRotationTemplate \ --stack-name MyLambdaCreationStack \ --parameter-overrides '[{"Name":"endpoint","Value":"https://secretsmanager.region.amazonaws.com"},{"Name":"functionName","Value":"MySecretsManagerRotationFunction"}]'{ "ApplicationId": "arn:aws:serverlessrepo:us-east-1:297356227824:applications/SecretsManagerRDSMySQLRotationSingleUser", "ChangeSetId": "arn:aws:cloudformation:region:123456789012:changeSet/EXAMPLE1-90ab-cdef-fedc-ba987EXAMPLE/EXAMPLE2-90ab-cdef-fedc-ba987EXAMPLE", "StackId": "arn:aws:cloudformation:region:123456789012:stack/aws-serverless-repository-MyLambdaCreationStack/EXAMPLE3-90ab-cdef-fedc-ba987EXAMPLE"}

2. 次のコマンドは、先ほど作成した変更セットを実行します。change-set-name パラメータは、前のコマンドの ChangeSetId 出力から得られます。このコマンドは出力を生成しません。

$ aws cloudformation execute-change-set --change-set-name arn:aws:cloudformation:region:123456789012:changeSet/EXAMPLE1-90ab-cdef-fedc-ba987EXAMPLE/EXAMPLE2-90ab-cdef-fedc-ba987EXAMPLE

3. 次に、前のコマンドが作成した Lambda 関数の名前を見つける必要があります。

$ aws lambda list-functions { ... "FunctionName": "MySecretsManagerRotationFunction",

104

https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/SecretsManagerReadWrite


"FunctionArn": "arn:aws:lambda:us-west-2:123456789012:function:MySecretsManagerRotationFunction", ... }

4. 次のコマンドは、関数を呼び出すアクセス許可を Secrets Manager に付与します。

$ aws lambda add-permission \ --function-name MySecretsManagerRotationFunction \ --principal secretsmanager.amazonaws.com \ --action lambda:InvokeFunction \ --statement-id SecretsManagerAccess{ "Statement": "{\"Sid\":\"SecretsManagerAccess\",\"Effect\":\"Allow\",\"Principal\":{\"Service\":\"secretsmanager.amazonaws.com\"},\"Action\":\"lambda:InvokeFunction\",\"Resource\":\"arn:aws:lambda:us-west-2:123456789012:function:aws-serverless-repository-SecretsManagerRDSMySQLRo-10WGBDAXQ6ZEH\"}"}

5. VPC でデータベースを実行する場合は、次のコマンドが必要です。VPC がない場合は、このコマンドをスキップします。このコマンドは、Amazon RDS DB インスタンスを実行している VPC で実行するように Lambda ローテーション関数を設定します。Amazon RDS コンソールまたは aws rdsdescribe-instances CLI コマンドを使用して、 Amazon RDS DB インスタンスの VPC 情報を検索します。続いて、次のコマンドに情報を追加して実行します。

$ aws lambda update-function-configuration \ --function-name arn:aws:lambda:us-west-2:123456789012:function:MySecretsManagerRotationFunction \ --vpc-config SubnetIds=<COMMA SEPARATED LIST OF VPC SUBNET IDS>,SecurityGroupIds=<COMMA SEPARATED LIST OF SECURITY GROUP IDs> \

6. データベースインスタンスを含む VPC および Lambda ローテーション関数がインターネットアクセスなしで機能する場合、Secrets Manager のプライベートサービスエンドポイントを持つ VPC を設定する必要があります。これにより、ローテーション関数は VPC 内のエンドポイントで SecretsManager にアクセスできます。

$ aws ec2 create-vpc-endpoint --vpc-id <VPC ID> \ --vpc-endpoint-type Interface \ --service-name com.amazonaws.<region>.secretsmanager \ --subnet-ids <COMMA SEPARATED LIST OF VPC SUBNET IDS> \ --security-group-ids <COMMA SEPARATED LIST OF SECURITY GROUP IDs> \ --private-dns-enabled

7. この時点で、Lambda ローテーション関数にコードを入力できます。

AWS Lambda コンソール (https://console.aws.amazon.com/lambda/) を開きます。8. 選択したローテーションシナリオを実装するようコードをカスタマイズします。詳細については、

「Lambda ローテーション関数の理解とカスタマイズ (p. 108)」を参照してください。9. 最後に、シークレットにローテーション設定を適用し、最初のローテーションを実行しま

す。--rotation-rules パラメータで連続するローテーションの間隔を日数で指定します。AutomaticallyAfterDays で必要な日数を設定します。

$ aws secretsmanager rotate-secret \ --secret-id production/MyAwesomeAppSecret \ --rotation-lambda-arn arn:aws:lambda:us-west-2:123456789012:function:MySecretsManagerRotationFunction \ --rotation-rules AutomaticallyAfterDays=7

105


AWS Secrets Manager ユーザーガイド別のデータベースまたはサービスのシークレットのローテーションを有効にする

シークレットはすぐに 1 度ローテーションし、指定した頻度でローテーションし始めます。

別のデータベースまたはサービスのシークレットのローテーションを有効にするサポートされている RDS データベース以外のデータベース、またはその他のサービスのシークレットのローテーションを設定するには、他のいくつかのステップを手動で実行する必要があります。主に、Lambda ローテーション関数のコードを作成して提供する必要があります。

Warning

ローテーションを設定した場合は、シークレットを保存するとすぐにシークレットが一度更新されます｡これを行う前に、シークレットに保存されている認証情報を使用するすべてのアプリケーションが AWS Secrets Manager からシークレットを検索するように更新されていることを確認する必要があります。初期ローテーション後は、古い認証情報は使用できない場合があります。古い認証情報が有効ではなくなると、すぐに更新に失敗したアプリケーションはすべて中断されます。

Lambda ローテーション関数を作成しておく必要があります。まだ関数を作成していない場合は、他のデータベースやサービスのローテーションと AWS Secrets Manager のシークレット (p. 103) のステップを実行します。関数が作成され、シークレットに関連付ける準備ができたら、この手順に戻ります。


ローテーションを有効にするには、ネットワーク環境が正しく設定されている必要があります。

• Lambda 関数は、データベースまたはサービスと通信できる必要があります。 VPC で、Amazon EC2インスタンスでデータベースまたはサービスを実行している場合、同じ VPC で Lambda 関数を実行することをお勧めします。これにより、ローテーション関数とサービス間の直接接続が有効になります。これを設定するには、Lambda 関数の詳細ページで、[Network (ネットワーク)] セクションまで下にスクロールして、ドロップダウンリストからサービスを実行しているインスタンスと一致する [VPC] を選択します。また、インスタンスにアタッチされた EC2 セキュリティグループが、インスタンスと Lambda間での通信が有効かを確認する必要があります。

• Lambda 関数は、Secrets Manager サービスエンドポイントと通信できる必要があります。 Lambdaローテーション関数を VPC 内で実行するように設定していない、またはアタッチされた NAT ゲートウェイが VPC にあるために、関数がインターネットにアクセスできる場合、Secrets Manager のいずれかのパブリックエンドポイントを使用できます。または、Lambda 関数がインターネットへのアクセスが一切ない VPC 内で実行するように設定されている場合、プライベート Secrets Manager サービスエンドポイントを使用して VPC を設定できます (p. 77)。

別のデータベースまたはサービスのシークレットのローテーションを有効にして設定するには




コンソールでローテーションを有効化して設定するには、次のアクセス許可が必要です。

• secretsmanager:ListSecrets – コンソールでシークレットのリストを表示するために必要です。

• secretsmanager:DescribeSecrets – 選択したシークレットの詳細ページにアクセスします｡

• secretsmanager:RotateSecret – ローテーションを設定するかトリガーします｡

106






AWS Secrets Manager ユーザーガイド別のデータベースまたはサービスのシークレットのローテーションを有効にする

1. https://console.aws.amazon.com/secretsmanager/ で Secrets Manager コンソールにサインインします。



4. [Select rotation period (保持期間の選択)] で、事前定義された値 — の 1 つを選択するか、[カスタム]を選択してから、ローテーション間の日数を入力します。


5. [AWS Lambda 関数の選択] で、ドロップダウンリストからローテーション関数を選択します。まだ関数を作成していない場合は、他のデータベースやサービスのローテーションと AWS SecretsManager のシークレット (p. 103) のステップを実行します。関数が作成され、シークレットに関連付ける準備ができたら、このステップに戻り実行します。

Using the AWS CLI or AWS SDKs


コンソールを使用して Lambda 関数を作成するには、次のアクセス許可が必要です。

• lambda:CreateFunction – AWS Lambda で関数を作成する。• lambda:InvokeFunction – シークレットキーにローテーション関数をアタッチする。• secretsmanager:DescribeSecrets – シークレットの詳細ページにアクセスする｡• secretsmanager:RotateSecret – シークレットにローテーション関数をアタッチす

る、またはローテーションをトリガーする｡

次のコマンドを使用して、Secrets Manager でローテーションを有効化して設定することができます。

• API/SDK: RotateSecret• AWS CLI: rotate-secret

Example

以下に、[AWS マネジメントコンソールの使用] タブのコンソールベースのシークレット作成と同等の処理を実行する CLI コマンドの例を示します。ローテーション間隔を 30 日間に設定し、データベース上でこのシークレットの認証情報を変更するアクセス許可を持つ 2 番目のシークレットの Amazonリソースネーム (ARN) を指定します。

$ aws secretsmanager rotate-secret --secret-id production/MyAwesomeAppSecret --automatically-rotate-after-days 30 --rotation-lambda-arn arn:aws:secretsmanager:region:accountid:secret:production/MasterSecret-AbCdEf{ "ARN": "arn:aws:secretsmanager:region:accountid:secret:production/MyAwesomeAppSecret-AbCdEf", "Name": "production/MyAwesomeAppSecret", "VersionId": "EXAMPLE1-90ab-cdef-fedc-ba987EXAMPLE"}

107




AWS Secrets Manager ユーザーガイドLambda ローテーション関数の理解とカスタマイズ

AWS CLI によってパラメータは自動的に生成され提供されるため、ClientRequestToken パラメータは不要です。出力には、最初のローテーション時に作成された新しいバージョンのシークレットバージョン ID が含まれます。ローテーションが完了すると、この新しいバージョンにはステージングラベル AWSCURRENT が付けられ、以前のバージョンにはステージングラベル AWSPREVIOUS が付けられます。

Lambda ローテーション関数の理解とカスタマイズLambda ローテーション関数の詳細については、「Lambda ローテーション関数の概要 (p. 109)」を参照してください。

シークレットタイプ用にサポートされたデータベース (p. 4)のいずれかを選択すると、AWS SecretsManager は Lambda ローテーション関数を作成して設定します。Amazon RDS データベースシークレットのローテーションを有効にする (p. 80) のステップに従うことによって、それらのデータベースにローテーションを有効化できます。ただし、別のサービス用にカスタム Lambda ローテーション関数を作成する場合は、別のデータベースまたはサービスのシークレットのローテーションを有効にする (p. 106)のステップに従う必要があります。

このセクションでは、Lambda 関数の実行方法とシークレットを正常に更新するための設定方法を詳細に説明します。

Important

関数を呼び出す Lambda 関数と Secrets Manager シークレットの両方が､同じ AWS リージョンに存在する必要があります。それらが異なるリージョンにある場合、シークレットのメタデータに関数の Amazon リソースネーム (ARN) を追加しようとすると、「Lambda が存在しません」というエラーメッセージが表示されます。

以下は、ローテーション用に独自の Lambda 関数を作成する際に考慮すべきシナリオです。適用するシナリオは、セキュリティ保護されたリソースを保護する認証システムによってサポートされている機能と、セキュリティ上の懸念事項に基づいて決まります。

• 1 人のユーザーのパスワードのみを変更できます。これは、サービスにアクセスするユーザー以外のユーザーが所有するサービスの一般的なシナリオです。サービスの所有者は、顧客が 1 つのユーザーアカウントを作成できるようにします。ユーザーアカウントには、ユーザー名としての E メールアドレス、または少なくとも一意のキーなどを使用することがよくあります。このシナリオでは、通常、ユーザーは必要に応じて頻繁にパスワードを変更できます。ただし、ユーザーが追加のユーザーを作成することはできず、多くの場合、多くの場合ユーザー名を変更することもできません。

通常、ユーザーは自分のパスワードを変更することが可能で、パスワード変更を行うために管理者権限を持つ別個のユーザーは必要としません。ただし、1 人のアクティブなユーザーのパスワードを変更するので、このユーザーでサービスにアクセスするクライアントは、パスワード変更の処理中に一時的にサインインに失敗することがあります。

パスワードを変更した時点から、クライアントが新しいバージョンのパスワードを使用するよう通知されるまでの間､ダウンタイムが生じる可能性があります。通常これは数秒ほどにすぎず、シークレットを使用するアプリケーションコードでこの時間が考慮されている必要があります。ローテーション中のこの短期間の停止に耐久性を持つよう、必ず間に多少の時間を置いた再試行を有効化してください。

• 相互間で交代できる 2 人のユーザーを作成できます。このシナリオでは、ローテーションプロセスがクローンする 1 人のユーザーを作成して、保護されたリソースに同等のアクセス権限を持つ 2 人のユーザーを作成することができます。ローテーションプロセスは、ユーザーが「アクティブ」シークレットの認証情報を使用してデータベースやサービスに引き続きアクセスしているうちに Secrets Manager がパスワードを変更して「非アクティブ」なユーザーをテストし、2 人のユーザーを切り替えます。

クライアントが 1 つのユーザー名を使用して保護されたリソースにアクセスしている (デフォルトのステージングラベル AWSCURRENT がアタッチされているバージョンをクエリしている) 間に、ローテーション関数は非アクティブの 2 番目のユーザーのパスワードを変更します。ローテーション関数は、ス

108



AWS Secrets Manager ユーザーガイドLambda ローテーション関数の概要

テージングラベル AWSCURRENT を持つシークレットの新しいバージョンに、更新されたパスワードを保存します。テストの後、ステージングラベル AWSCURRENT を代替ユーザーおよび新しいパスワードを指す新しいバージョンに移動します。すべてのクライアントは、代替ユーザーおよび更新されたパスワードを使用して、保護されたリソースへのアクセスをすぐに開始します。

次回のローテーションが始まると、アイドル状態の元のユーザーアカウントのパスワードが変更されます。別のシークレットの新しいバージョンが作成され、サイクルが繰り返されます。

このシナリオでは、両方のユーザーのパスワードを変更するアクセス許可を持つ管理者またはスーパーユーザーを指す 2 番目のシークレットが必要です。

• 1 人のユーザーの新しい認証情報を作成することができます。いくつかのシステムでは、複数のアクセス認証情報を持つ 1 人のユーザーを作成できます。各アクセス認証情報は認証情報の完全なセットを提供し、他のアクセスキーとは独立して動作します。Secrets Manager が 2 つ目のアクセス認証情報を使用している間に、最初のアクセス認証情報を削除して再作成できます。次に、新しい最初のアクセス認証情報に、すべてのクライアントを切り替えることができます。次回更新するときに、クライアントが2 番目のアクセス認証情報を引き続き使用している間に､2 番目のアクセスキーを削除して再作成します。

詳細および各シナリオの設定方法については、次のトピックを参照してください。

• Lambda ローテーション関数の概要 (p. 109)• 1 つのパスワードを使用してシングルユーザーの AWS Secrets Manager シークレットを更新す

る (p. 112)• 既存の 2 人のユーザーを切り替えることで AWS Secrets Manager シークレットを更新する (p. 116)• 複数の認証情報をサポートするシングルユーザーのための AWS Secrets Manager シークレットのロー

テーション (p. 119)

Lambda ローテーション関数の概要AWS Secrets Manager は AWS Lambda 関数を使用してシークレットの実際のローテーションを実行します。がサポートする Amazon RDS データベース (p. 4) の 1 つにシークレットを使用する場合、SecretsManager が、Lambda 関数を提供します。また、Secrets Manager は、指定したデータベースの要件を満たすため、自動的に関数をカスタマイズします。別のサービス用のシークレットを使用する場合は、Lambda 関数のコードを自分で提供しなければなりません。

設定されたローテーションスケジュールまたは手動でローテーションをトリガーすると、SecretsManager は毎回異なるパラメータを使用して Lambda 関数を数回呼び出します。この Lambda 関数は、シークレットをローテーションさせるプロセス全体でいくつかのタスクを実行します。各リクエストに対して実行されるタスクは、リクエストの Step パラメータで指定されます。

Secrets Manager は、次の JSON リクエスト構造のパラメータを使用して Lambda 関数を呼び出します。

{ "Step" : "request.type", "SecretId" : "string", "ClientRequestToken" : "string"}

次に、リクエストのパラメータについて説明します。

• ステップ – ローテーション関数の動作のどの部分を呼び出すかを指定します。それぞれの異なる値が、ローテーションプロセスのステップを識別します。各ステップの詳細は、以下のセクション「Lambdaローテーション関数のステップ (p. 110)」で説明します。個々で起動されるステップに区別することで、AWS Secrets Manager チームは、ステップ間で発生する可能性のある追加機能を追加することができます。

109


• secretId – ローテーションするシークレットの ID または Amazon リソースネーム (ARN)。シークレットを最初に作成した際に、Secrets Manager が、各シークレットに、ARN を割り当てます。バージョンのローテーションは、自動的に AWSCURRENT というラベルが付いたデフォルトバージョンとなります。

• clientRequestToken – Secrets Manager が、Lambda 関数に提供する文字列。Lambda 関数から呼び出すすべての Secrets Manager API に文字列を渡す必要があります。Secrets Manager は、このトークンを使い、個々の呼び出しの失敗に起因する要求された再試行中のリクエストの冪等性を保証します。この値は UUID-type 値で、指定されたシークレット内の一意性を保証します。この値は、新しいバージョンのシークレットの SecretVersionId になります。

同じ secretId および clientTokenRequest が各ステップを呼び出します。各呼び出しで Step パラメータのみが変更されます。これにより、ステップ間のステータスを保存しなくなります。パラメータは、必要なすべての情報を提供するか、AWSPENDING または AWSCURRENT ラベルでアクセスされるバージョンの情報の一部として提供します。

さまざまなローテーション戦略のために各ステップで実行すべき特定のタスクの説明については、次のトピックを参照してください。

• 1 つのパスワードを使用してシングルユーザーの AWS Secrets Manager シークレットを更新する (p. 112)

• 既存の 2 人のユーザーを切り替えることで AWS Secrets Manager シークレットを更新する (p. 116)• 複数の認証情報をサポートするシングルユーザーのための AWS Secrets Manager シークレットのロー

テーション (p. 119)

Lambda ローテーション関数のステップLambda ローテーション関数に組み込まれている機能は、個別のステップに分かれています。Step パラメータは、パラメータ値の 1 つを使用して関数を呼び出すことによって、各ステップを呼び出します。

Secrets Manager のリリースでは、Secrets Manager は、順番に自動で、ステップを呼び出します。1 つのステップが終了すると、Secrets Manager は直ちに Lambda 関数を呼び出して次のステップを呼び出します。

サポートされている Amazon RDS データベースの 1 つにシークレットを指定すると、Secrets Manager は標準 Lambda 関数を使用してシークレットをローテーションします。Secrets Manager は Lambda 関数を提供しますが、Lambda 関数を変更すると、組織固有のローテーション要件を満たすことができます。

createSecret ステップ

このステップでは、Lambda 関数がシークレットの新しいバージョンを生成します｡シナリオに応じて、これは新しいパスワードを生成するだけで簡単です。または、セキュリティで保護されたリソースに適したユーザー名とパスワードを含む、まったく新しい認証情報の一式に対して値を生成することもできます。Secrets Manager は、これら値を、新規バージョンのシークレットとして保存します。SecretsManager は、接続の詳細などのシークレット内の他の値を、既存のシークレットのバージョンからクローンします。Secrets Manager は、シークレットの新しいバージョン AWSPENDING にステージングラベルを付け、シークレットのプロセス中のバージョンとしてマークします。

110

https://wikipedia.org/wiki/Universally_unique_identifier


setSecret ステップ

このステップでは、ローテーション関数は、前のステップで作成したばかりの Secrets Manager からAWSPENDING というラベルが付いたシークレットのバージョンを取得します。次に、ローテーション関数は、データベースまたはサービスのアイデンティティサービスを呼び出し、既存のパスワードを変更するか、シークレットの新しい認証情報と一致する新しい認証情報を作成します。新しいユーザーが作成された場合、この関数は以前のユーザーからアクセス許可をクローンする必要があります。これにより、必要に応じて新しいユーザーがカスタムアプリケーション内で引き続き、実行することができます。

パスワードを変更したり、データベースまたはサービス認証システムで新しい認証情報を作成したりするには、Lambda 関数でこれらのタスクを実行できるようにする必要があります。管理タスクを考慮すると、タスクには通常、ユーザーに与えないアクセス許可が必要です。ローテーション戦略に従い、アクセス許可がある 2 つ目の認証情報一式を使用し、パスワードを変更したり、メインシークレット用の新規ユーザーを作成することをお勧めします。これらの認証情報は、マスターシークレットと呼ばれ、SecretsManager では、メインのシークレットとは別のシークレットとして保存されます。ローテーション関数により、ローテーション関数で使用できるようにメインシークレットにこのマスターシークレットの ARNが保存されます。エンドユーザーのカスタムアプリケーションは、マスターシークレットにアクセスするべきではありません。Lambda ローテーション関数のみがメインシークレットにアクセスでき、ローテーションが実行された際に、データベースで新規認証情報を更新または作成します。

testSecret ステップ

この Lambda 関数の手順では、カスタムアプリケーションがセキュリティで保護されたリソースにアクセスするのと同じ方法で、セキュリティで保護されたリソースにアクセスするために、シークレットのAWSPENDING バージョンを確認します。アプリケーションがデータベースへの読み取り専用アクセスを必要とする場合、関数はテスト読み込みが成功したことを検証する必要があります。アプリケーションがデータベースに書き込むことができる必要がある場合、関数はアクセスのレベルを確認するために何らかのテスト書き込みを実行する必要があります。

111

AWS Secrets Manager ユーザーガイドシークレットの更新 - シングルユーザー､1 つのパスワード

finishSecret ステップこのステップでは、シークレットのこのバージョンでリソース固有のファイナライズを実行します。完了したら、最後のステップとして、Lambda 関数が現在のバージョンからこの新しいバージョンにラベルAWSCURRENT を移動させ、クライアントが使用開始できるようにします。AWSPENDING ラベルを削除することもできますが、技術的に必要です。この時点で、基本的なローテーションが完了します。すべてのクライアントは、新しいバージョンのシークレットを使用します。古いバージョンは、AWSPREVIOUS ステージングラベルを取得し、必要であれば復元用に、最後の正常なシークレットのバージョンとして使用することができます。AWSPREVIOUS ステージングラベルがある古いバージョンは、ステージングラベルを保持しなくなるため、Secrets Manager は、古いバージョンを非推奨そして削除対象とみなします。

1 つのパスワードを使用してシングルユーザーのAWS Secrets Manager シークレットを更新する保護されたリソースのシークレットを自動的に更新するように､AWS Secrets Manager を構成できます。このトピックでは、1 つのパスワードを使用してシングルユーザーを作成できるシステムのローテーションの設定について説明します。必要に応じて、そのユーザーのパスワードを変更することができます。このシナリオはシンプルですが、最も可用性の高いソリューションは提供されません。パスワード変更中でも、クライアントは保護されたリソースにアクセスし続けることができるためです。これにより「アクセスが拒否されました」状態になる可能性があります。

実際のパスワードの変更と、使用するパスワードをクライアントに知らせるシークレットでの変更との間に生じる可能性のあるタイムラグには、リスクが伴います。このリスクは、保護されたリソースを「サーバーファーム」でホストしている場合、パスワードを変更しすべてのメンバーサーバーに伝播するのに時間がかかるため、さらに増大する可能性があります。ただし、適切な再試行戦略を使用すると、このリスクを大幅に軽減できます。

これは、サービスにアクセスするユーザー以外のユーザーが所有するサービスの一般的なシナリオです。サービスの所有者は、顧客が 1 つのユーザーアカウントを作成できるようにします。多くの場合、ユー

112



ザーアカウントは、E メールアドレスなどの情報をユーザー名として、または少なくとも一意性キーとして作成されます。通常ユーザーは必要な頻度でパスワードを変更できます。しかし、このサービスでは、ユーザーが追加のユーザーを作成することはできず、ユーザー名を変更することもできません｡

ローテーションでラベルを使用してパスワードを変更してシングルユーザーを管理する方法以下で、このシナリオについて詳しく説明します。

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

b. その後、シークレットのローテーションプロセスは、新しいバージョン「B」のシークレットを作成します (新しいシークレットではなく、同じシークレットの新しいバージョン)。このシークレットのバージョン B は、ローテーションプロセスでアタッチされたステージングラベル AWSPENDING を最初から持っています。シークレットのバージョン B は新しく生成されたパスワードを取得します｡SecretsManager によりシークレットが正常に保存されるとすぐに、ローテーションプロセスはデータベースの認証システム内のユーザーのパスワードを変更します。この時点で、データベースのパスワードを変更してラベルをシークレットの新しいバージョンに移動する間に、ステップ 4 でクライアントによるサインオンが失敗する可能性があります。このリスクのため、ローテーションプロセスがすぐに次のステップに進むことが重要となります｡

c. ライブパスワードはシークレットのバージョン B になり、ローテーションプロセスは AWSCURRENTステージングラベルをバージョン A から新しいバージョン B のシークレットに移動します。これにより、AWSPREVIOUS ステージングラベルが、以前に AWSCURRENT ステージングラベルでラベル付けされていたバージョンに自動的に移動されます。これは、復元が必要になった場合に、「最後の既知の正常な設定」として使用されます。

113


d. カスタムアプリからの次のリクエストでは、B に AWSCURRENT というラベルがあるため、バージョンB のシークレットが取得されます｡この時点で、カスタマーアプリケーションは、新しいバージョンのシークレットに依存します。

ローテーションを設定してパスワードのみを変更する1 人のユーザーしか持てない認証システムのローテーションメカニズムを設定するには、次の手順に従います。

パスワードのみを更新するローテーションの設定

1. 保護されたリソースを保護する認証システムでシングルユーザーを作成します。パスワードを書き留めます。

2. 前の手順で作成した認証情報の詳細を保存する Secrets Manager シークレットを作成します。

a. https://console.aws.amazon.com/secretsmanager/ で Secrets Manager コンソールにサインインします。

b. [New secret(新しいシークレット)] を選択します。c. [シークレットタイプの選択] で、サービスに最適なオプションを選択します。ユーザー名と初期

パスワードを含むデータベースまたはサービスの詳細を設定します。d. [AWS KMS 暗号化キー] で、このシークレットの暗号化に使用するカスタマーマスターキー

(CMK) を選択するか、アカウントの [DefaultMasterKey] をデフォルトの設定のままにします。デフォルトのキーを使用するには、シークレットにアクセスする認証情報が、シークレットを所有するアカウントと同じアカウントからのものである必要があります。ユーザーの認証情報が異なるアカウントのものである場合は、カスタム CMK の Amazon リソースネーム (ARN) を作成して指定する必要があります。

e. [Select rotation period(保持期間の選択)] に、ローテーション間の日数を選択するか入力します。

Note

Secrets Manager コンソールを使用してローテーションを設定すると、Secrets Managerによりデフォルトで有効期限が自動的に有効になり、ローテーションサイクルの日数が+ 7 に設定されます。

f. [What credentials can rotate this secret? (このシークレットを更新できる認証情報)] で、[Use thesame credentials (同じ認証情報を使用する)] を選択します。

114



Note

この例のシナリオでは、ユーザーがパスワードを変更できることと、最初のユーザーのパスワードを変更するアクセス許可を持つ第 2 のユーザーを使用できないことが前提です。

g. [Next step] を選択します。h. [シークレット名] とオプションの [説明] に入力します。タグを追加することもできます。i. [Store secret(シークレットの保存)] を選択します。

3. 新しいシークレットを調べて、Lambda ローテーション関数の ARN を取得します。

a. [シークレット] リストページで、ステップ 2 で作成したシークレットの名前を選択します。b. [Secret details / Secret rotation (シークレットの詳細/シークレットのローテーション)] セクション

で、ローテーション関数の ARN を選択して Lambda で開きます。c. ローテーション関数をカスタマイズして､特定の要件を満たします。関数を記述するための基礎と

して、各ステップで以下の要件を使用することができます。

• createSecret ステップ:• GetSecretValue オペレーションを使用して、シークレットの AWSCURRENT バージョンを

取得します｡• SecretString フィールドから保護されたシークレットテキストを抽出し、構造体に保存し

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

成するアルゴリズムを使用して、新しいパスワードを生成します。• 構造の password フィールドを前のステップで生成した新しいもので上書きしま

す。username や接続の詳細など、他のすべての詳細は同じにしておきます。• シークレット構造の修正されたコピーを保存するには、PutSecretValue への呼び出しでSecretString パラメータとして渡します。Secrets Manager は、シークレットの新しいバージョンにAWSPENDING のラベルを付けます。

• setSecret ステップ:• GetSecretValue オペレーションを使用して、シークレットの AWSPENDING バージョンを

取得します｡• 保護されたリソースの認証システムにコマンドを発行して、既存のユーザーのパスワードを

新しい AWSPENDING バージョンのシークレットに保存されているパスワードに変更します。• testSecret ステップ:

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

• 保護されたリソースにコマンドを発行して、シークレットの認証情報を使用してアクセスを試みます｡

• finishSecret ステップ:• ラベル AWSCURRENT を AWSPENDING というラベルの付いたバージョンに移動します。ま

た、これにより、ステージングラベル AWSPREVIOUS は AWSCURRENT が削除されたシークレットに自動的に移動されます。

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

Important

このシナリオでは、新しいバージョンを作成して確認している間は、古いバージョンでユーザーがオペレーションを続けることはできません。したがって、パスワードを変更するときの setSecret フェーズの時間と、AWSCURRENT ラベルを新しいバージョンに移動するときのfinishSecret フェーズの時間の間に、クライアントが間違った認証情報を使用してアクセス拒

115

AWS Secrets Manager ユーザーガイドシークレットの更新 - 既存のユーザーを切り替える

否エラーを取得する可能性があります。このリスクを軽減するために、クライアントアプリに合理的な再試行機能を組み込んでください。

既存の 2 人のユーザーを切り替えることで AWSSecrets Manager シークレットを更新する保護されたリソースのシークレットを自動的に更新するように､AWS Secrets Manager を構成できます。

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

管理者が最初の 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 つのユーザーアカウントが逆になります。

基本的なシナリオの例

116




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

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

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

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

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

117


2 人のユーザー間のローテーションを設定するサポートされている Amazon RDS データベース (p. 4)のいずれにシークレットを使用する場合は、Amazon RDS データベースシークレットのローテーションを有効にする (p. 80) の手順に従ってください。

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

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

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

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

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

• createSecret フェーズ:• GetSecretValue オペレーションを使用して、シークレットの AWSCURRENT バージョンを取得しま

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

ることができます。• username フィールドを調べて、代替ユーザー名を決定します。• 代替ユーザー名を持つユーザーがデータベースに存在するかどうかを確認します。存在しない場合、

初回のローテーションプロセスであるはずです。現在のユーザーとアクセス許可をクローンします。• シークレット構造のコピーの username エントリを別のユーザー名に設定します。• 保護されたリソースでサポートされている最大の長さと複雑さの要件を持つ新しいパスワードを生成

します。• シークレット構造のコピーの password エントリを新しいパスワードに設定します。• シークレット構造の修正されたコピーをシークレットに保存するには、PutSecretValue への呼

び出しで SecretString パラメータとして渡します。Secrets Manager は、シークレットの新しいバージョンに AWSPENDING としてラベルを付けます。

• setSecret フェーズ:• GetSecretValue オペレーションを使用して、シークレットの AWSPENDING バージョンを取得しま

す｡• SecretString フィールドから､ユーザー名とパスワードを抽出します。• 保護されたリソース認証システムにコマンドを発行して、指定されたユーザーパスワードをその値に

変更します。• testSecret フェーズ:

118

AWS Secrets Manager ユーザーガイドシークレットの更新 - パスワードのみ

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

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

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

Note

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

複数の認証情報をサポートするシングルユーザーのための AWS Secrets Manager シークレットのローテーション保護されたリソースのシークレットを自動的に更新するように､AWS Secrets Manager を構成できます。このトピックでは、シングルユーザーで少なくとも 2 つの認証情報セットを作成できる認証システムのローテーションを設定する方法について説明します。

ベストプラクティスとして、メインユーザーの認証情報を削除および作成するアクセス許可を持つ別のユーザーの認証情報を保存するために、第 2 の「マスター」シークレットを設定することをお勧めします。これにより、メインユーザーに付与されるアクセス許可をアプリケーションで必要なアクセス許可のみに制限できます。こうすることで、エンドユーザーがアクセスできない 2 番目のユーザーに管理タスクをオフロードできます。2 番目のユーザーは、メインシークレットのローテーション関数によってのみアクセスされ、古いアクセスキーを削除して新しいアクセスキーを作成します。

ローテーションでラベルを使用して複数の認証情報を持つシングルユーザーを管理する方法以下の例では、このシナリオについて詳しく説明します。ここでは、サービスによって生成され、ローテーション関数によって生成される必要がない、2 つの個別の「API キー」をユーザーが持つことを可能にするサービスの例を使用します。

a. このシナリオは、単一のバージョン「A」を持つシークレットに保存されている API キーの 1 つを使用して保護されたリソース (データベース) にアクセスするアプリケーションから始まります。このシークレットの A バージョンには、AWSCURRENT というステージングラベルがアタッチされています。アプリケーションは、AWSCURRENT というステージングラベルの付いたバージョンを要求してシークレットを取得します (ステップ 1 と 2)。次に、アプリケーションはそのバージョンのシークレットの API キーを使用してデータベースにアクセスし (ステップ 3)、必要なデータを取得します (ステップ 4)。

119


b. シークレットのローテーション関数は、シークレットのバージョン「A」によって現在参照されていない API キーを削除し、同じユーザーのための新しい API キーを作成します。その後、ローテーション関数は、新しい「B」バージョンのシークレットを作成します (新しいシークレットではなく、同じシークレットの新しいバージョン)。ローテーション関数は、API キーの詳細を新しく作成した API キーに置き換えることを除いて、詳細を「A」バージョンから複製します。このシークレットのバージョン「B」は、ローテーションプロセスでアタッチされたステージングラベル AWSPENDING を最初から持っています。カスタムアプリケーションは常に AWSCURRENT ラベルを要求するようにプログラムされており、そのラベルは移動されていないため、API キーが保護されたリソースにアクセスするために、アプリケーションは引き続き元のバージョンのシークレットを取得して使用します。

c. シークレットの「B」バージョンが動作することをテストした後で、ローテーションプロセスはバージョン「A」から AWSCURRENT ラベルを移動し、このラベルをシークレットの新しいバージョン「B」にアタッチします。これにより、AWSPENDING ステージングラベルがステージングラベルAWSCURRENT のあるバージョンに自動的に移動します。これは、復元が必要になった場合に、「最後の既知の正常な設定」として使用されます。

d. カスタムアプリケーションからの次のリクエストでは、「B」に AWSCURRENT ラベルがあるため、バージョン「B」のシークレットが取得されます｡この時点で、顧客のアプリケーションはシークレットの新しいバージョンで API キーを使用します。次のローテーションサイクルが発生すると、シークレットの「B」バージョンが「A」バージョンになり、上記のステップ a. でもう一度開始します。

120


ユーザーの代替認証情報へのローテーションの設定1 人のユーザーしか持てない認証システムのローテーションメカニズムを設定するには、次の手順に従います。

2 つの認証情報セットを持つユーザーのローテーションを設定するには

1. 保護されたリソースを保護する認証システムでユーザーを作成します。設定するユーザー名と認証情報をメモしておきます。ここでは説明のために、Creds1 と Creds2 とします。

2. 前の手順で作成した認証情報の詳細を保存する 1 つの Secrets Manager シークレットを作成します。このシークレットは、最初にユーザーに対して Creds1 を保持します。

a. https://console.aws.amazon.com/secretsmanager/ で Secrets Manager コンソールにサインインします。

b. [New secret(新しいシークレット)] を選択します。c. [シークレットタイプの選択] で、ユーザー名と最初の認証情報を含む [他の種類のシークレット]

を選択します。たとえば、保護されたシークレットテキストに 2 つのキーと値のペアを入力します。ペアは、例と似ているものにすることができます。

キー値

UserName <シシシシシ>

APIKey <シシシシ API シシ>

APIKeyId <シシシシシシシシシシシシシシシ 2 シシ API シシシシシシシ>

d. [AWS KMS Encryption Key (暗号化キー)] で、このシークレットの暗号化に使用するキーを選択するか、アカウントの [DefaultMasterKey] のデフォルト設定のままにします。デフォルトのキーを使用するには、シークレットにアクセスする認証情報が、シークレットを所有するアカウントと同じアカウントからのものである必要があります。ユーザーの認証情報が異なるアカウントのものである場合は、カスタムのカスタマーマスターキー (CMK) を作成して指定する必要があります。

e. [Select rotation period(保持期間の選択)] に、ローテーション間の日数を選択するか入力します。Note

Secrets Manager コンソールを使用してローテーションを設定すると、Secrets Managerによりデフォルトで有効期限が自動的に有効になり、ローテーション間の日数が + 7 に設定されます。

f. [Select the Lambda rotation function(Lambda ローテーション関数の選択)] で､[関数の作成] を選択します。

g. [Next step] を選択します。h. [シークレット名] とオプションの [説明] に入力します。必要に応じて、タグを追加できます。

121


AWS Secrets Manager ユーザーガイドローテーション関数の削除

i. [Store secret(シークレットの保存)] を選択します。3. 新しいシークレットを調べて、Lambda ローテーション関数の Amazon リソースネーム (ARN) を取得

します。

a. [シークレット] リストページで、ステップ 2 で作成したシークレットの名前を選択します。b. [Secret details / Secret rotation (シークレットの詳細/シークレットのローテーション)] セクション

で、ローテーション関数の ARN を選択して Lambda で開きます。c. ローテーション関数を記述するための基礎として、次のロジックを使用します。

• createSecret ステップ:• GetSecretValue オペレーションを使用して、シークレットの AWSCURRENT バージョンを

取得します｡• シークレットキーから SecretString 値を抽出し、変更できる構造に保存します。• 非アクティブな API キー (シークレットの AWSCURRENT バージョンで参照されていないも

の) を特定します。• 前のステップで指定した非アクティブな API キーを削除するコマンドをサービスに発行しま

す。• 同じユーザーの新しいアクセスキーを作成するコマンドをサービスに発行します。• シークレットの構造のコピーにある API キーと識別子を、作成したばかりの新しい API キー

の値で上書きします。他のすべての詳細は同じままにします。• 保護されたシークレットテキストの修正されたコピーを保存するには、PutSecretValue

への呼び出しで SecretString パラメータとして渡します。Secrets Manager は、シークレットの新しいバージョンにAWSPENDING のラベルを付けます。

• setSecret ステップ:• このシナリオの setSecret ステップでは何も起こりません。API キーは createSecret ス

テップで作成しました。これは、シークレットに保存するための API キーと ID が必要となるためです。他のほとんどのシナリオとは異なり、独自のキーは生成しません。

• testSecret ステップ:• GetSecretValue オペレーションを使用して、シークレットの AWSPENDING バージョンを

取得します｡• 保護されたリソースにコマンドを発行して、このバージョンのシークレットの API キーを使

用してアクセスを試みます｡• finishSecret ステップ:

• ラベル AWSCURRENT を AWSPENDING というラベルの付いたバージョンに移動します。また、これにより、ステージングラベル AWSPREVIOUS は AWSCURRENT が削除されたシークレットに自動的に移動されます。

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

使用されていない Lambda ローテーション関数の削除

シークレットのローテーション関数を作成した後、ある時点で、シークレットのローテーションが不要になったと判断する場合があります。不要になったローテーションを削除 (p. 66)すれば済むことですが、ただし、シークレットを更新する Lambda ローテーション関数の削除を検討することもできます。複数のシークレット間でローテーション関数を共有している場合、関数でローテーションされる最後のシークレットを削除するまで、関数を削除しない方が賢明です。

このガイドで説明しているようにローテーション関数を使用して関数を作成する場合は、単純に AWSServerless Application Repository テンプレートを削除しない方がよいでしょう。これは、SecretsManager が、関数を AWS CloudFormation スタックの一部として作成しているためです。スタックを削除

122


すると、スタックが作成したすべてのものが削除されます。この場合、Secrets Manager は Lambda 関数と、関数にアクセス許可を付与する IAM ロールの両方を削除します。すべてのものを手際よく削除するには、以下のステップを実行する必要があります。

AWS Serverless Application Repository テンプレートで作成したローテーション関数の削除




AWS Serverless Application Repository テンプレートのいずれかを使用して作成した Lambdaローテーション関数を削除するには、スタックに移動し、作成されたすべてのコンポーネントを削除するのに必要なアクセス許可を持っている必要があります。

• cloudformation:ListStacks• cloudformation:DescribeStack• cloudformation:ListStackResources• cloudformation:DeleteStack• lambda:ListFunctions• lambda:GetFunction• lambda:DeleteFunction• iam:ListRoles• iam:DetachRolePolicy• iam:DeleteRolePolicy• iam:DeleteRole• cloudformation:DeleteStack

これらはすべて、以下の AWS 管理ポリシーをアタッチすることで付与できます。

• SecretsManagerReadWrite• IAMFullAccess

1. AWS Lambda コンソール (https://console.aws.amazon.com/lambda/) を開きます。2. 関数のリストに移動して、削除する関数の名前を選択します。3. 関数の詳細ページの上部にあるバナーには、[This function belongs to the CloudFormation

stackaws-serverless-repository-SecretsManager<rotation_template_name><unique_guid>]と表示されます。このスタックを管理するには、CloudFormation コンソールにアクセスしてください。)] と書かれています。

[Stack Details (スタックの詳細)] ページの [CloudFormation コンソール] リンクを選択して、AWSCloudFormation コンソールを開きます。

4. 既存のインラインポリシーを編集する代わりに IAM にインラインアクセス許可ポリシーを追加した場合、または追加のマネージドポリシーをアタッチした場合は、AWS CloudFormation がスタックを削除する前にそれらのポリシーを削除またはデタッチする必要があります。a. スタックの [Resources (リソース)] セクションを展開し、[タイプ] が [AWS::IAM::Role] に設定さ

れている行の [Physical ID (物理 ID)] 値を選択します。これにより、別のタブで IAM コンソールが開きます。

b. [Inline policy (インラインポリシー)] が [Policy type (ポリシータイプ)] である行を調べます。AWS 管理機能がアタッチされた AWSLambdaBasicExecutionRole が表示されます。[SecretsManager<template name>Policy0] および [SecretsManager<templatename>Policy1] という名前の 1 つか 2 つのインラインポリシーも表示されます。これら以外のポ

123


https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/IAMFullAccess



リシーが表示された場合、Secrets Manager がスタックの一部として作成したポリシーではありません。ポリシーは、スタックが作成された後に手動で追加されています。これらは手動で削除またはデタッチする必要があります。そうしない場合、次の手順でスタックを削除するリクエストが失敗する可能性があります。

c. AWS CloudFormation コンソールの [Stack Detail (スタックの詳細)] ページに戻ります。5. [Other Actions (その他のアクション)] を選択して、[Delete Stack (スタックの削除)] を選択します。6. [Delete Stack (スタックの削除)] 確認ダイアログボックスで、[Yes, Delete (はい、削除します)] を選

択します。

[ステータス] が [DELETE_IN_PROGRESS] に変わります。削除が成功すると、[ステータス] は最終的に [DELETE_COMPLETE] に変わります。

7. スタックのリストに戻ると、削除されたスタックは表示されなくなります。



AWS Serverless Application Repository テンプレートのいずれかを使用して作成した Lambdaローテーション関数を削除するには、各 AWS CLI、または次のステップにリストされている同等の API オペレーションを実行するのに必要なアクセス許可を持っている必要があります。これらはすべて、以下の 2 つの AWS 管理ポリシーをアタッチすることで付与できます。

• SecretsManagerReadWrite• IAMFullAccess

1. コマンドプロンプトを開き、AWS CLI コマンドを実行します。2. 特定の関数がどの AWS CloudFormation スタックに含まれているか確認するには、--physical-

resource-id パラメータとして渡される関数名を使用して次のコマンドを実行します。これにより、特定の関数を所有するスタックに関連付けられたリソースのリストが表示されます。

$ aws cloudformation describe-stack-resources --physical-resource-id MyLambdaRotationFunction{{ "StackResources": [ { "StackName": "aws-serverless-repository-MyLambdaCreationStack", "StackId": "arn:aws:cloudformation:us-east-1:123456789012:stack/aws-serverless-repository-MyLambdaCreationStack/EXAMPLE2-90ab-cdef-fedc-ba987EXAMPLE", "LogicalResourceId": "SecretsManagerRotationTemplate", "PhysicalResourceId": "MySecretsManagerRotationFunction", "ResourceType": "AWS::Lambda::Function", "Timestamp": "2018-04-27T18:03:05.490Z", "ResourceStatus": "CREATE_COMPLETE" }, { "StackName": "aws-serverless-repository-MyLambdaCreationStack", "StackId": "arn:aws:cloudformation:us-east-1:123456789012:stack/aws-serverless-repository-MyLambdaCreationStack/EXAMPLE2-90ab-cdef-fedc-ba987EXAMPLE", "LogicalResourceId": "SecretsManagerRotationTemplateRole", "PhysicalResourceId": "aws-serverless-repository-SecretsManagerRotationTe-<random-chars>", "ResourceType": "AWS::IAM::Role", "Timestamp": "2018-04-27T18:03:00.623Z", "ResourceStatus": "CREATE_COMPLETE" } ]}

124


https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/IAMFullAccess


3. 関数を呼び出す権限を持つ IAM ロールの名前である "ResourceType" :"AWS::IAM::Role" に関連付けられている StackId およびの PhysicalResourceId 応答値を探します。既存のインラインポリシーを編集する代わりに IAM にインラインアクセス許可ポリシーを追加した場合、または追加のマネージドポリシーをアタッチした場合は、AWS CloudFormation がスタックを削除する前にそれらのポリシーを削除またはデタッチする必要があります。

埋め込みインラインポリシーがあるかどうかを確認するには、次のコマンドを実行します。

$ aws iam list-role-policies --role-name <role-name-from-PhysicalResourceId-on-previous-command>{ "PolicyNames": [ "SecretsManagerRotationTemplateRolePolicy0", "SecretsManagerRotationTemplateRolePolicy1" ]}

以下に示すような名前のインラインポリシーは想定内のため、特に操作は必要ありません。4. これらの 2 つ以外のポリシーが表示される場合は、続行する前にロールから削除する必要がありま

す。

$ aws iam delete-role-policy --role-name <role-name-from-PhysicalResourceId-on-previous-command> / --policy-name <policy-name-from-previous-command>

5. ここで、ロールにアタッチされたマネージドポリシーがあるかどうかを確認します。

$ aws iam list-attached-role-policies --role-name <role-name-from-PhysicalResourceId-on-previous-command>

6. 前のコマンドの出力にリストされたいずれかのポリシーがある場合、この最終的な準備コマンドを実行してロールからデタッチします。

$ aws iam detach-role-policy --role-name <role-name-from-PhysicalResourceId-on-previous-command> / --policy-arn <ARN-of-policy-discovered-in-previous-command>

7. これで、スタックを削除できるようになりました。削除すると、関連するすべてのリソースが削除されます。ステップ 2 で取得したスタックの名前を --stack-name として渡します。

$ aws cloudformation delete-stack --stack-name aws-serverless-repository-MyLambdaCreationStack

このコマンドの実行後すぐに、AWS CloudFormation により IAM ロールと Lambda ローテーション関数が削除されます。

125

AWS Secrets Manager ユーザーガイドVPC エンドポイントを介した Secrets Manager への接続

VPC エンドポイントで SecretsManager を使用する

以下のセクションでは、これらのタスクについて説明します。

• Secrets Manager と VPC エンドポイントを接続する。• Secrets Manager VPC エンドポイントを作成する。• Secrets Manager のエンドポイントのエンドポイントポリシーを作成する

VPC エンドポイントの詳細については、VPC サービスドキュメントの「VPC エンドポイント」を参照してください。

トピック• VPC エンドポイントを介した Secrets Manager への接続 (p. 126)• Secrets Manager VPC プライベートエンドポイントの作成 (p. 127)• Secrets Manager VPC プライベートエンドポイントへの接続 (p. 129)• ポリシーステートメントでの VPC プライベートエンドポイントの使用 (p. 130)• Secrets Manager VPC エンドポイントのエンドポイントポリシーを作成する (p. 132)• Secrets Manager VPC エンドポイントの使用の監査 (p. 133)

VPC エンドポイントを介した Secrets Manager への接続

VPC をインターネットに接続するのではなく、VPC 内で設定したプライベートエンドポイントを通して直接 Secrets Manager に接続することができます。VPC サービスエンドポイントを使用すると、VPC とSecrets Manager 間の通信はすべて AWS ネットワーク内で発生し、パブリックインターネットアクセスをまったく必要としません。

Secrets Manager では、AWS PrivateLink による Amazon VPC インターフェイスエンドポイントがサポートされています。1 つ以上の各 VPC エンドポイントは、VPC サブネット内の 1 つ以上の Elastic NetworkInterface とプライベート IP アドレスで表されます。

VPC インターフェイスエンドポイントは VPC を Secrets Manager に直接接続します。その際、NAT デバイス、VPN 接続、または AWS Direct Connect 接続を使用しません。VPC のインスタンスは、パブリックIP アドレスがなくても Secrets Manager と通信できます。

Lambda ローテーション関数がプライベートエンドポイントを見つけられるように、次のいずれかのステップを実行します。

• VPC エンドポイントは、Secrets Manager API オペレーションおよび AWS CLI コマンドで手動で指定できます。たとえば、次のコマンドは、endpoint-url パラメータを使用して、Secrets Manager へのAWS CLI コマンドで VPC エンドポイントを指定しています。

$ aws secretsmanager list-secrets --endpoint-url https://vpce-1234a5678b9012c-12345678.secretsmanager.us-west-2.vpce.amazonaws.com

126

https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-endpoints.html

https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Introduction.html#what-is-privatelink

https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpce-interface.html

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html


https://docs.aws.amazon.com/cli/latest/reference/secretsmanager/index.html

AWS Secrets Manager ユーザーガイドSecrets Manager VPC プライベートエンドポイントの作成

• VPC プライベートエンドポイントのプライベート DNS ホスト名を有効にした場合は、エンドポイントURL を指定する必要はありません。Secrets Manager CLI および SDK がデフォルトで使用する標準のSecrets Manager DNS ホスト名 (https://secretsmanager.<region>.amazonaws.com) は、自動的に VPC エンドポイントに解決されます。

AWS CloudTrail ログを使用して、VPC エンドポイントを介したシークレットの使用を監査することもできます。また、IAM およびシークレットのリソースベースポリシーの条件を使用すると、指定された VPCまたは VPC エンドポイントからではないリクエストすべてに対するアクセスを拒否できます。

Note

VPC エンドポイントに基づいて IAM およびキーポリシーを作成するときは注意が必要です。ポリシーステートメントによって、特定の VPC または VPC エンドポイントからリクエストが送信されるように要求されている場合は、ユーザーに代わってシークレットとやりとりする他のAWS サービスからのリクエストが失敗する可能性があります。ヘルプについては、「ポリシーでSecrets Manager アクセス許可とともに VPC エンドポイント条件を使用する (p. 168)」を参照してください。

リージョン

Secrets Manager では、Amazon VPC と Secrets Manager の両方が使用可能なすべての AWS リージョンの VPC エンドポイントがサポートされます。

Secrets Manager VPC プライベートエンドポイントの作成

Secrets Manager VPC プライベートエンドポイントを作成するには



1. Amazon VPC コンソール (https://console.aws.amazon.com/vpc/) を開きます。2. ナビゲーションバーで、リージョンセレクターを使用して、リージョンを選択します。3. ナビゲーションペインで、[Endpoints] を選択します。メインペインで、[Create Endpoint (エンド

ポイントの作成)] を選択します。4. [Service category] で、[AWS services] を選択します。5. [Service Name (サービス名)] リストで、リージョンの Secrets Manager インターフェイスエンド

ポイントのエントリを選択します。たとえば、米国東部 (バージニア北部) リージョンでは、エントリ名は com.amazonaws.us-east-1.secretsmanager です。

6. [VPC] で、ユーザーの VPC を選択します。7. [Subnets (サブネット)] で、追加するサブネットを各アベイラビリティーゾーンから選択します。

VPC エンドポイントは、複数のアベイラビリティーゾーンにまたがることができます。VPC エンドポイントの Elastic Network Interface が、選択した各サブネットで作成されます。各ネットワークインターフェースには DNS ホスト名とプライベート IP アドレスがあります。

8. デフォルトでは、[Enable Private DNS Name (プライベート DNS 名を有効にする)] オプションが有効になっており、標準の Secrets Manager DNS ホスト名 (https://secretsmanager.<region>.amazonaws.com) は自動的に VPC エンドポイントに解決されます。このオプションにより VPC エンドポイントが使いやすくなります。Secrets Manager CLI および SDK はデフォルトで標準の DNS ホスト名を使用するため、アプリケーションおよびコマンドで VPC エンドポイント URL を指定する必要はありません。

127

https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpce-interface.html#vpce-private-dns

https://docs.aws.amazon.com/general/latest/gr/rande.html#vpc_region


https://console.aws.amazon.com/vpc/

AWS Secrets Manager ユーザーガイドSecrets Manager VPC プライベートエンドポイントの作成

この機能は、VPC の属性 enableDnsHostnames と属性 enableDnsSupport 属性を true (デフォルト値) に設定した場合にのみ機能します。この属性を設定するには、VPC の DNS サポートを更新してください。

9. [Security groups] で、セキュリティグループを選択または作成します。

セキュリティグループを使用すると、エンドポイントへのアクセスをコントロールできます。これは、ファイアウォールを使用するのに似ています。

10. [Create endpoint] を選択します。

結果として VPC エンドポイントが表示されます。これには、VPC エンドポイントへの接続に使用する VPC エンドポイント ID と DNS 名が含まれます。

Amazon VPC ツールを使用して、エンドポイントを表示および管理することもできます。これには、エンドポイントの通知の作成、エンドポイントのプロパティの変更、エンドポイントの削除が含まれます。手順については、「インターフェイス VPC エンドポイント」を参照してください。


AWS CLI で create-vpc-endpoint コマンドを使用して、Secrets Manager に接続する VPC エンドポイントを作成できます。

VPC エンドポイントタイプには必ず interface を使用してください。また、secretsmanager、および VPC が配置されているリージョンが含まれるサービス名の値を使用します。

このコマンドには、PrivateDnsNames パラメータは含まれません。VPC はデフォルトで true の値になるためです。オプションを無効にするには、値が false のパラメータを指定します。プライベート DNS 名は、VPC の enableDnsHostnames 属性と enableDnsSupport 属性が true に設定されている場合にのみ使用できます。この属性を設定するには、ModifyVpcAttribute API を使用します。

コマンドの一般的な構文を次の図に示します。

aws ec2 create-vpc-endpoint --vpc-id <vpc id> \ --vpc-endpoint-type Interface \ --service-name com.amazonaws.<region>.secretsmanager \ --subnet-ids <subnet id> \ --security-group-id <security group id>

たとえば、以下のコマンドは、VPC ID が vpc-1a2b3c4d で、リージョンが us-west-2 の VPC エンドポイントを VPC に作成します。ここではアベイラビリティーゾーンを表すサブネット ID が 1 つしか指定されていませんが、これは多数指定することができます。VPC エンドポイントにはセキュリティグループ ID が必要です。

出力には、新しい VPC エンドポイントへの接続に使用可能な VPC エンドポイント ID と DNS 名が含まれます。

$ aws ec2 create-vpc-endpoint --vpc-id vpc-1a2b3c4d \ --vpc-endpoint-type Interface \ --service-name com.amazonaws.us-west-2.secretsmanager \ --subnet-ids subnet-e5f6a7b8c9 \ --security-group-id sg-1a2b3c4d{ "VpcEndpoint": { "PolicyDocument": "{\n \"Statement\": [\n {\n \"Action\": \"*\", \n \"Effect\": \"Allow\", \n \"Principal\": \"*\", \n \"Resource\": \"*\"\n }\n ]\n}", "VpcId": "vpc-1a2b3c4d", "NetworkInterfaceIds": [ "eni-abcdef12"

128

https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-dns.html#vpc-dns-updating

https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-dns.html#vpc-dns-updating

https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_SecurityGroups.html

https://docs.aws.amazon.com/kms/latest/developerguide/kms-vpc-endpoint.html#connecting-vpc-endpoint

https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpce-interface.html

https://docs.aws.amazon.com/cli/latest/reference/ec2/create-vpc-endpoint.html

https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyVpcAttribute.html

AWS Secrets Manager ユーザーガイドSecrets Manager VPC プライベートエンドポイントへの接続

], "SubnetIds": [ "subnet-e5f6a7b8c9" ], "PrivateDnsEnabled": true, "State": "pending", "ServiceName": "com.amazonaws.us-west-2.secretsmanager", "RouteTableIds": [], "Groups": [ { "GroupName": "default", "GroupId": "sg-1a2b3c4d" } ], "VpcEndpointId": "vpce-1234a5678b9012c", "VpcEndpointType": "Interface", "CreationTimestamp": "2018-06-12T20:14:41.240Z", "DnsEntries": [ { "HostedZoneId": "Z7HUB22UULQXV", "DnsName": "vpce-1234a5678b9012c-12345678.secretsmanager.us-west-2.vpce.amazonaws.com" }, { "HostedZoneId": "Z7HUB22UULQXV", "DnsName": "vpce-1234a5678b9012c-12345678-us-west-2a.secretsmanager.us-west-2.vpce.amazonaws.com" }, { "HostedZoneId": "Z1K56Z6FNPJRR", "DnsName": "secretsmanager.us-west-2.amazonaws.com" } ] }}

Secrets Manager VPC プライベートエンドポイントへの接続

VPC プライベートエンドポイントを作成する際、VPC はデフォルトで自動的にプライベート DNS 名を有効にします。そのため、リージョン向けの標準のエンドポイント DNS 名を使用するほかは、操作を行う必要はありません。エンドポイント DNS 名は、自動的に VPC 内の正しいエンドポイントに解決されます。

https://secretsmanager.<region>.amazonaws.com

AWS CLI と SDK はデフォルトでこのホスト名を使用します。これにより、スクリプトとアプリケーションを変更せずに VPC エンドポイントを使用し始めることができます。

プライベート DNS 名を有効にしなくても、完全な DNS 名を使用してエンドポイントに接続できます。

たとえば、次の list-secrets コマンドは、endpoint-url パラメータを使用して VPC プライベートエンドポイントを指定します。こうしたコマンドを使用するには、サンプルの VPC プライベートエンドポイントID を、ご自身のアカウントのものに置き換えてください。

aws secretsmanager list-secrets --endpoint-url https://vpce-1234a5678b9012c-12345678.secretsmanager.us-west-2.vpce.amazonaws.com

129

https://docs.aws.amazon.com/cli/latest/reference/secretsmanager/list-secrets.html

AWS Secrets Manager ユーザーガイドポリシーステートメントでの VPC プ

ライベートエンドポイントの使用

ポリシーステートメントでの VPC プライベートエンドポイントの使用

IAM ポリシーおよび Secrets Manager シークレットポリシーを使用して、シークレットへのアクセスを制御できます。また、グローバル条件キーを使って、リクエストの VPC エンドポイントまたは VPC に基づいて、このようなポリシーを制限することもできます。

• aws:sourceVpce 条件キーを使用して、VPC エンドポイントに基づいてシークレットへのアクセスを許可または制限します。

• aws:sourceVpc 条件キーを使用して、プライベートエンドポイントをホストする VPC に基づいてシークレットへのアクセスを許可または制限します。

Note

VPC エンドポイントに基づいて IAM およびシークレットポリシーを作成するときは注意が必要です。ポリシーステートメントによって、特定の VPC または VPC エンドポイントからリクエストが送信されるように要求されている場合は、ユーザーに代わってシークレットにアクセスする他の AWS サービスからのリクエストが失敗する可能性があります。詳細については、「ポリシーで Secrets Manager アクセス許可とともに VPC エンドポイント条件を使用する (p. 168)」を参照してください。また、リクエストが Amazon VPC エンドポイントから送信されている場合、aws:sourceIP 条件キーは無効です。リクエストを VPC エンドポイントに制限するには、aws:sourceVpce または aws:sourceVpc 条件キーを使用します。詳細については、『Amazon VPC ユーザーガイド』の「VPC エンドポイント - エンドポイントの使用の管理」を参照してください。

たとえば、次のサンプルシークレットポリシーでは、指定された VPC エンドポイントからリクエストが送信されている場合にのみ、ユーザーが Secrets Manager オペレーションを実行できます。

ユーザーが Secrets Manager へのリクエストを行うと、Secrets Manager によって、リクエストの VPCエンドポイント ID が、ポリシーの aws:sourceVpce 条件キーの値と比較されます。一致しない場合、Secrets Manager はそのリクエストを拒否します。

このようなポリシーを使用するには、AWS アカウント ID と VPC エンドポイント ID のプレースホルダーを、ご自身の有効な値で置き換えます。

{ "Id": "example-policy-1", "Version": "2012-10-17", "Statement": [ { "Sid": "Enable Secrets Manager permissions to principals in account 123456789012", "Effect": "Allow", "Principal": {"AWS":["123456789012"]}, "Action": ["secretsmanager:*"], "Resource": "*" }, { "Sid": "Restrict GetSecretValue operation to only my VPC endpoint", "Effect": "Deny", "Principal": "*", "Action": ["secretsmanager:GetSecretValue"], "Resource": "*", "Condition": { "StringNotEquals": { "aws:sourceVpce": "vpce-1234a5678b9012c"

130

https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#AvailableKeys

https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-endpoints.html#vpc-endpoints-iam-access

AWS Secrets Manager ユーザーガイドポリシーステートメントでの VPC プ

ライベートエンドポイントの使用

} } }

]}

また、aws:sourceVpc 条件キーを使用して、VPC エンドポイントが存在する VPC に基づいて、シークレットへのアクセスを制限することもできます。

次のサンプルシークレットポリシーでは、シークレットを作成および管理するコマンドが許可されるのは、そのコマンドが vpc-12345678 から送信されている場合だけです。また、このポリシーでは、リクエストが vpc-2b2b2b2b から届いた場合にのみ、シークレットの暗号化された値へのアクセスを使用するオペレーションを許可します。1 つの VPC でアプリケーションを実行する場合は、このようなポリシーを使用できますが、管理機能には 2 番目の切り離された VPC を使用します。

このようなポリシーを使用するには、AWS アカウント ID と VPC エンドポイント ID のプレースホルダーを、ご自身の有効な値で置き換えます。

{ "Id": "example-policy-2", "Version": "2012-10-17", "Statement": [ { "Sid": "Allow administrative actions from ONLY vpc-12345678", "Effect": "Allow", "Principal": {"AWS": "123456789012"}, "Action": [ "secretsmanager:Create*", "secretsmanager:Put*", "secretsmanager:Update*", "secretsmanager:Delete*","secretsmanager:Restore*", "secretsmanager:RotateSecret","secretsmanager:CancelRotate*", "secretsmanager:TagResource","secretsmanager:UntagResource" ], "Resource": "*", "Condition": { "StringEquals": { "aws:sourceVpc": "vpc-12345678" } } }, { "Sid": "Allow secret value access from ONLY vpc-2b2b2b2b", "Effect": "Allow", "Principal": {"AWS": "111122223333"}, "Action": ["secretsmanager:GetSecretValue"], "Resource": "*", "Condition": { "StringEquals": { "aws:sourceVpc": "vpc-2b2b2b2b" } } }, { "Sid": "Allow read actions from everywhere", "Effect": "Allow", "Principal": {"AWS": "111122223333"}, "Action": [ "secretsmanager:Describe*","secretsmanager:List*","kms:GetRandomPassword" ], "Resource": "*", }

131

AWS Secrets Manager ユーザーガイドSecrets Manager VPC エンドポイントのエンドポイントポリシーを作成する

]}

Secrets Manager VPC エンドポイントのエンドポイントポリシーを作成する

Secrets Manager VPC エンドポイントを作成したら、エンドポイントポリシーをアタッチして、エンドポイントでのシークレット関連のアクティビティを制御できます。たとえば、エンドポイントポリシーをアタッチして、実行される Secrets Manager アクション、シークレットで実行されるアクション、これらのアクションを実行する IAM ユーザーまたはロール、VPC エンドポイント経由でアクセスされるアカウントを定義できます。エンドポイントポリシーをサポートする AWS のサービスのリストなど、エンドポイントポリシーの詳細については、「VPC エンドポイントポリシーの使用」を参照してください。

Note

AWS は AWS サービス間で VPC エンドポイントを共有しません。Secrets Manager と S3 など、複数の AWS サービスに VPC エンドポイントを使用する場合は、各エンドポイントに異なるポリシーをアタッチする必要があります。

例: 特定のアカウントの Secrets Manager エンドポイントへのアクセスを有効にする

次の例では、アカウント 123456789012 のすべてのユーザーとロールにアクセス権を付与します。

{ "Statement": [ { "Sid": "Access for a specific account", "Principal": {"AWS": "123456789012"}, "Action": "secretsmanager:*", "Effect": "Allow", "Resource": "*" } ] }

例: Secrets Manager エンドポイントで単一のシークレットへのアクセスを有効にする

次の例では、指定されたシークレットにのみアクセスを制限します。

{ "Statement": [ { "Principal": "*", "Action": "secretsmanager:*", "Effect": "Allow", "Resource": [ "arn:aws:secretsmanager:us-west:123456789012:secret:a_specific_secret_name-a1b2c3" ] } ] }

132

https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-endpoints-access.html#vpc-endpoints-policies

AWS Secrets Manager ユーザーガイドSecrets Manager VPC エンドポイントの使用の監査

Secrets Manager VPC エンドポイントの使用の監査

Secrets Manager へのリクエストで VPC エンドポイントが使用されている場合、VPC エンドポイント IDは、そのリクエストが記録されている AWS CloudTrail ログ (p. 134)のエントリに表示されます。このエンドポイント ID を使用して、Secrets Manager VPC エンドポイントの使用状況を監査できます。

たとえば、次のサンプルログエントリには、VPC エンドポイントを使用した GenerateDataKey リクエストが記録されます。この例では、vpcEndpointId フィールドはログエントリの最後に表示されます。わかりやすくするために、この例のうち関連性の低い多くの部分が省略されています。

{ "eventVersion":"1.05", "userIdentity": { "type": "IAMUser", "arn": "arn:aws:iam::123456789012:user/Anika", "accountId": "123456789012", "userName": "Anika" }, "eventTime":"2018-01-16T05:46:57Z", "eventSource":"secretsmanager.amazonaws.com", "eventName":"GetSecretValue", "awsRegion":"us-west-2", "sourceIPAddress":"172.01.01.001", "userAgent":"aws-cli/1.14.23 Python/2.7.12 Linux/4.9.75-25.55.amzn1.x86_64 botocore/1.8.27", "requestID":"EXAMPLE1-90ab-cdef-fedc-ba987EXAMPLE", "eventID":"EXAMPLE2-90ab-cdef-fedc-ba987EXAMPLE", "readOnly":true, "eventType":"AwsApiCall", "recipientAccountId":"123456789012", "vpcEndpointId": "vpce-1234a5678b9012c" }

133

AWS Secrets Manager ユーザーガイドAWS CloudTrail を使用した AWS

Secrets Manager API コールのログ作成

AWS Secrets Manager シークレットの使用を監視する

ベストプラクティスとして、シークレットを監視して、シークレットの使用とその変更が確実に記録されるようにする必要があります。これにより、予期しない使用または変更を調査することができ、不要な変更をロールバックできます。現在 AWS Secrets Manager では、組織および組織内で発生するアクティビティを監視することができる 2 つの AWS のサービスをサポートしています。

トピック• AWS CloudTrail を使用した AWS Secrets Manager API コールのログ作成 (p. 134)• Amazon CloudWatch Events (p. 137)

AWS CloudTrail を使用した AWS Secrets ManagerAPI コールのログ作成

AWS Secrets Manager は、AWS CloudTrail と統合されています。このサービスは、Secrets Manager内でユーザーやロール、または AWS のサービスによって実行されたアクションを記録するサービスです。CloudTrail は、Secrets Manager コンソールからのコールや、Secrets Manager API へのコード呼び出しを含む、Secrets Manager のすべての API コールをイベントとしてキャプチャします。証跡を作成する場合は、Secrets Manager のイベントなど、Amazon S3 バケットへの CloudTrail イベントの継続的な配信を有効にすることができます。証跡を設定しない場合でも、CloudTrail コンソールの [Event history (イベント履歴)] で最新のイベントを表示できます。CloudTrail によって収集された情報を使用して、SecretsManager に送信されたリクエスト、リクエストの IP アドレス、リクエストの送信者、リクエストの日時などの詳細を判断できます。

CloudTrail の詳細については、「AWS CloudTrail User Guide」を参照してください。

CloudTrail 内の Secrets Manager 情報AWS アカウントを作成すると、AWS によって CloudTrail が有効になります。Secrets Manager でアクティビティが発生すると、CloudTrail はそのアクティビティを [Event history (イベント履歴)] の AWS の他のサービスのイベントとともに CloudTrail イベントに記録します。最近のイベントは、AWS アカウントで表示、検索、ダウンロードできます。詳細については、「CloudTrail イベント履歴でのイベントの表示」を参照してください。

Secrets Manager のイベントなど、AWS アカウントのイベントの継続的な記録については、証跡を作成します。証跡により、CloudTrail はログファイルを Amazon S3 バケットに配信できます。デフォルトでは、コンソールで証跡を作成するときに、証跡がすべてのリージョンに適用されます。証跡では、AWS パーティションのすべてのリージョンからのイベントがログに記録され、指定した Amazon S3 バケットにログファイルが配信されます。さらに、より詳細な分析と CloudTrail ログで収集されたデータに基づいた行動のためにその他の AWS サービスを設定できます。詳細については、以下のトピックを参照してください。

• 証跡を作成するための概要• CloudTrail でサポートされるサービスと統合• CloudTrail の Amazon SNS 通知の設定• 「複数のリージョンから CloudTrail ログファイルを受け取る」と「複数のアカウントから CloudTrail ロ

グファイルを受け取る」

134

https://docs.aws.amazon.com/awscloudtrail/latest/userguide/

https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html

https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html

https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html

https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-aws-service-specific-topics.html#cloudtrail-aws-service-specific-topics-integrations

https://docs.aws.amazon.com/awscloudtrail/latest/userguide/getting_notifications_top_level.html

https://docs.aws.amazon.com/awscloudtrail/latest/userguide/receive-cloudtrail-log-files-from-multiple-regions.html

https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-receive-logs-from-multiple-accounts.html


AWS Secrets Manager ユーザーガイドSecrets Manager ログファイルエントリの取得

CloudTrail は、すべての Secrets Manager アクションのログを記録し、そのアクションを AWS SecretsManager API リファレンスに記録します。たとえば、[CreateSecret]、[GetSecretValue]、[RotateSecret] セクションの呼び出しは、CloudTrail ログファイルにエントリを生成します。

各イベントまたはログエントリには、リクエストの生成者に関する情報が含まれます。この ID 情報は以下のことを確認するのに役立ちます。

• ルートまたは IAM ユーザー認証情報によってリクエストが生成されたかどうか。• ロールまたはフェデレーティッドユーザーの一時的なセキュリティ認証情報によってリクエストが生成

されたかどうか。• 別の AWS サービスによってリクエストが生成されたかどうか。

ログファイルの送信の通知については、Amazon SNS の通知を発行するよう CloudTrail を設定できます。詳細については、「CloudTrail の Amazon SNS 通知の設定」を参照してください。

また、複数 AWS リージョンと複数の AWS アカウントからの AWS Secrets Manager ログファイルを、1つの Amazon S3 バケットに集約することもできます。

詳細は、「CloudTrailログファイルを複数のリージョンから受け取る」と「複数のアカウントからCloudTrail ログファイルを受け取る」を参照してください。

Secrets Manager ログファイルエントリの取得次のいずれかの手法を使用して、CloudTrail から個々のイベントを取得できます。

CloudTrail ログから Secrets Manager イベントを取得するには


CloudTrail コンソールで過去 90 日以内に発生したイベントを表示できます。

1. https://console.aws.amazon.com/cloudtrail/ にある CloudTrail コンソールを開きます。2. コンソールが、イベントの発生したリージョンを参照していることを確認します。コンソールに

は、選択したリージョンで発生したイベントのみが表示されます。コンソールの右上のドロップダウンリストから正しいリージョンを選択してください。

3. 左のナビゲーションペインで [Event history (イベント履歴)] を選択します。4. [Filter (フィルター)] 条件、および [Time range (時間範囲)] (またはその両方) を選択すると探して

いるイベントを見つけるのに役立ちます。たとえば、すべての Secrets Manager イベントを表示するには、[Select attribute (属性の選択)] で、[Event source (イベントソース)] を選択します。[Enter event source (イベントソースの入力)] で、secretsmanager.amazonaws.com を選択します。

5. 追加の詳細を表示するには、イベントの横の拡張矢印を選択します。利用可能なすべての情報を表示するには、[View event (イベントの表示)] を選択します。


1. コマンドウィンドウを開いて AWS CLI コマンドを実行します。2. 次の例のようなコマンドを実行します。ここでは読みやすいように出力を改行していますが、実

際の出力では改行されません。

$ aws cloudtrail lookup-events --region us-east-1 --lookup-attributes AttributeKey=EventSource,AttributeValue=secretsmanager.amazonaws.com{ "Events": [ {

135



https://docs.aws.amazon.com/awscloudtrail/latest/userguide/getting_notifications_top_level.html




https://console.aws.amazon.com/cloudtrail/

AWS Secrets Manager ユーザーガイドSecrets Manager ログファイルエントリの概要

"EventId": "EXAMPLE1-90ab-cdef-fedc-ba987EXAMPLE", "EventName": "CreateSecret", "EventTime": 1525106994.0, "Username": "Administrator", "Resources": [], "CloudTrailEvent": "{\"eventVersion\":\"1.05\",\"userIdentity\":{\"type\":\"IAMUser\",\"principalId\":\"AKIAIOSFODNN7EXAMPLE\", \"arn\":\"arn:aws:iam::123456789012:user/Administrator\",\"accountId\":\"123456789012\",\"accessKeyId\":\"AKIAIOSFODNN7EXAMPLE\", \"userName\":\"Administrator\"},\"eventTime\":\"2018-04-30T16:49:54Z\",\"eventSource\":\"secretsmanager.amazonaws.com\", \"eventName\":\"CreateSecret\",\"awsRegion\":\"us-east-1\",\"sourceIPAddress\":\"192.168.100.101\", \"userAgent\":\"<useragent string>\",\"requestParameters\":{\"name\":\"MyTestSecret\", \"clientRequestToken\":\"EXAMPLE2-90ab-cdef-fedc-ba987EXAMPLE\"},\"responseElements\":null, \"requestID\":\"EXAMPLE3-90ab-cdef-fedc-ba987EXAMPLE\",\"eventID\":\"EXAMPLE4-90ab-cdef-fedc-ba987EXAMPLE\", \"eventType\":\"AwsApiCall\",\"recipientAccountId\":\"123456789012\"}" } ]}

Secrets Manager ログファイルエントリの概要証跡を使用すると、指定された Amazon S3 バケットにイベントをログファイルとして配信できるようになります。CloudTrail ログファイルには、1 つ以上のログエントリが含まれます。イベントは任意のソースからの 1 つのリクエストを表し、リクエストされたアクション、アクションの日時、リクエストのパラメータなどに関する情報が含まれます。CloudTrail ログファイルは、パブリック API コールの順序付けられたスタックトレースを収集しないため、特定の順序では表示されません。

サンプルの CreateSecret 呼び出しの CloudTrail ログエントリの例を以下に示します。

{ "eventVersion": "1.05", "userIdentity": { "type": "Root", "principalId": "123456789012", "arn": "arn:aws:iam::123456789012:root", "accountId": "123456789012", "accessKeyId": "AKIAIOSFODNN7EXAMPLE", "userName": "myusername", "sessionContext": {"attributes": { "mfaAuthenticated": "false", "creationDate": "2018-04-03T17:43:50Z" }} }, "eventTime": "2018-04-03T17:50:55Z", "eventSource": "secretsmanager.amazonaws.com", "eventName": "CreateSecret", "awsRegion": "us-west-2", "requestParameters": { "name": "MyDatabaseSecret", "clientRequestToken": "EXAMPLE1-90ab-cdef-fedc-ba987EXAMPLE" }, "responseElements": null, "requestID": "EXAMPLE2-90ab-cdef-fedc-ba987EXAMPLE", "eventID": "EXAMPLE3-90ab-cdef-fedc-ba987EXAMPLE", "eventType": "AwsApiCall", "recipientAccountId": "123456789012"

136

AWS Secrets Manager ユーザーガイドAmazon CloudWatch Events

}

サンプルの DeleteSecret 呼び出しの CloudTrail ログエントリの例を以下に示します。

{ "eventVersion": "1.05", "userIdentity": { "type": "Root", "principalId": "123456789012", "arn": "arn:aws:iam::123456789012:root", "accountId": "123456789012", "accessKeyId": "AKIAIOSFODNN7EXAMPLE", "userName": "myusername", "sessionContext": {"attributes": { "mfaAuthenticated": "false", "creationDate": "2018-04-03T17:43:50Z" }} }, "eventTime": "2018-04-03T17:51:02Z", "eventSource": "secretsmanager.amazonaws.com", "eventName": "DeleteSecret", "awsRegion": "us-west-2", "requestParameters": { "recoveryWindowInDays": 30, "secretId": "MyDatabaseSecret" }, "responseElements": { "name": "MyDatabaseSecret", "deletionDate": "May 3, 2018 5:51:02 PM", "aRN": "arn:aws:secretsmanager:us-west-2:123456789012:secret:MyDatabaseSecret-a1b2c3" }, "requestID": "EXAMPLE2-90ab-cdef-fedc-ba987EXAMPLE", "eventID": "EXAMPLE3-90ab-cdef-fedc-ba987EXAMPLE", "eventType": "AwsApiCall", "recipientAccountId": "123456789012"}

Amazon CloudWatch EventsSecrets Manager では、管理者が指定したオペレーションが組織内で発生した場合に、CloudWatch イベントを使用してアラートを発生させることができます。たとえば、そのようなオペレーションの機密性のため、管理者は、削除されたシークレットまたはシークレットローテーションの警告を受けたいことがあります。誰かがシークレットのバージョンを待っている間に削除しようとした場合に、アラートが必要になることがあります。これらのオペレーションを探す CloudWatch イベントルールを設定し、生成されたイベントを管理者が定義した「ターゲット」に送信できます。ターゲットは、E メールまたはテキストメッセージのサブスクライバーである Amazon SNS トピックにすることができます。また、イベントでトリガーされる簡単な AWS Lambda 関数を作成し、後で確認するためにオペレーションの詳細をログに記録することもできます。

CloudWatch イベントの詳細（設定して有効にする方法など）については、『Amazon CloudWatchEvents ユーザーガイド』を参照してください。

削除予定のシークレットバージョンの監視AWS CloudTrail、Amazon CloudWatch Logs、Amazon Simple Notification Service (Amazon SNS) の組み合わせを使用すると、削除が保留中のシークレットのバージョンにアクセスしようとするときに通知するアラームを作成できます。アラームから通知を受け取ると、削除が本当に必要かどうかを時間をかけて判断するために、シークレットの削除をキャンセルしなければならない場合があります。調査の結果、シー

137

https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/


AWS Secrets Manager ユーザーガイド削除予定のシークレットバージョンの監視

クレットが実際にまだ必要であるため、シークレットが保存されたままになる可能性があります。または、使用する新しいシークレットの詳細を使用して、ユーザーを更新する必要がある場合があります。

次の手順は、特定のエラーメッセージを生成する GetSecretValue オペレーションのリクエストがCloudTrail ログファイルに書き込まれた場合に､通知を受け取る方法を説明します。他の API オペレーションは、アラームをトリガーせずにシークレットのバージョンで実行できます。この CloudWatch アラームは、古い認証情報を使用しているユーザーまたはアプリケーションを示す可能性のある使用を検出します。

これらの手順を開始する前に、AWS リージョンと AWS Secrets Manager API リクエストをモニタリングするアカウントで、CloudTrail をオンにする必要があります。手順については、AWS CloudTrail ユーザーガイドの「初めての証跡の作成」を参照してください。

ステップ• パート 1: CloudTrail Logs への CloudWatch ログファイル配信の設定 (p. 138)• パート 2: CloudWatch アラームを作成する (p. 138)• パート 3: CloudWatch での削除済みシークレットのモニタリング (p. 139)

パート 1: CloudTrail Logs への CloudWatch ログファイル配信の設定CloudTrail ログファイルを CloudWatch Logs に送信するように設定する必要があります。これを行うことで、CloudWatch Logs は削除が保留中のシークレットのバージョンを取得する Secrets Manager API リクエストをモニタリングできます。

CloudWatch Logs への CloudTrail ログファイル配信を設定するには

1. CloudTrail コンソール（https://console.aws.amazon.com/cloudtrail/）を開きます。2. 上部のナビゲーションバーで、シークレットを監視する AWS リージョンを選択します。3. 左のナビゲーションペインで [Trails (証跡)] を選択し、CloudWatch に設定する証跡の名前を選択しま

す。4. [Trails Configuration (証跡の設定)] ページで、[CloudWatch Logs] のセクションまで下にスクロール

し、編集アイコン ( ) を選択します。5. [New or existing log group (新規または既存のロググループ)] にロググループの名前 (CloudTrail/

MyCloudWatchLogGroup) を入力します。6. [IAM ロール] で、[CloudTrail_CloudWatchLogs_Role] という名前のデフォルトのロールを使用するこ

ともできます。このロールには、CloudTrail イベントをロググループに配信するために必要なアクセス許可を持つ、デフォルトロールポリシーがあります。

7. [続行] を選択して設定を保存します。8. [AWS CloudTrail がアカウントの API アクティビティに関連付けられた CloudTrail イベントを

CloudWatch Logs ロググループに配信する] ページで、[許可] を選択します。

パート 2: CloudWatch アラームを作成するSecrets Manager GetSecretValue API オペレーションリクエストが保留中のシークレットのバージョンにアクセスした場合に通知を受け取るには、CloudWatch アラームを作成し、通知を設定する必要があります。

削除が保留中のシークレットのバージョンを使用しようとする試みをモニタリングするCloudWatch アラームを作成する

1. https://console.aws.amazon.com/cloudwatch/ で CloudWatch コンソールにサインインします。

138

https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-a-trail-using-the-console-first-time.html

https://console.aws.amazon.com/cloudtrail/

https://console.aws.amazon.com/cloudwatch/

AWS Secrets Manager ユーザーガイド削除予定のシークレットバージョンの監視

2. 上部のナビゲーションバーで、シークレットを監視する AWS リージョンを選択します。3. 左のナビゲーションペインで [Logs] を選択します。4. [ロググループ] のリストで、以前の手順で作成したロググループ ([CloudTrail/

MyCloudWatchLogGroup] など) の横にあるチェックボックスを選択します。その後、[Create MetricFilter] を選択します。

5. [Filter Pattern] に、以下を入力するか貼り付けます。

{ $.eventName = "GetSecretValue" && $.errorMessage = "*secret because it was marked for deletion*" }

[Assign Metric] を選択します。6. [Create Metric Filter and Assign a Metric] ページで、次の操作を実行します。

a. [メトリクス名前空間] に「CloudTrailLogMetrics」と入力します。b. [メトリクス名] に「AttemptsToAccessDeletedSecrets」と入力します。c. [Show advanced metric settings (メトリクスの詳細設定の表示)] を選択した後、必要に応じて

[Metric Value (メトリクス値)] に「1」と入力します。d. [Create Filter] を選択します。

7. フィルタボックスで、[Create Alarm] を選択します。8. [Create Alarm] ウィンドウで、以下の操作を行います。

a. [Name] に、「AttemptsToAccessDeletedSecretsAlarm」と入力します。b. [次の時:] の [が] で [>=] を選択し、「1」と入力します。c. [Send notification to:] の横で、次のいずれかを実行します。

• 新しい Amazon SNS トピックを作成して使用するには、[New list (新しいリスト)] を選択して新しいトピック名を入力します。[Email list:] に、E メールアドレスを少なくとも 1 つ入力します。カンマで区切って、複数の E メールアドレスを入力できます。

• 既存の Amazon SNS トピックを使用するには、使用するトピックの名前を選択します。リストが存在しない場合は、[リストを選択] を選択します。

d. [Create Alarm] を選択します。

パート 3: CloudWatch での削除済みシークレットのモニタリングアラームを作成しました。これをテストするには、シークレットのバージョンを作成し、それを削除用にスケジュールします。次に、シークレット値の取得を試みます｡アラームで設定したアドレスに間もなく Eメールが届きます。これは、削除予定のシークレットバージョンの使用について警告します。

139

AWS Secrets Manager ユーザーガイドAWS CloudFormation でシークレットの作成を自動化する

AWS サービスと AWS SecretsManager の統合

AWS Secrets Manager は、他の AWS サービスと連携し、ビジネスの課題の追加のソリューションを提供します。このトピックでは、機能を追加するために Secrets Manager を使用するサービス、またはタスクを実行するために Secrets Manager を使用するサービスについて説明します。

トピック

• AWS CloudFormation でシークレットの作成を自動化する (p. 140)• AWS Identity and Access Management (IAM) を使用したシークレットの保護 (p. 140)• AWS CloudTrail と Amazon CloudWatch を使用してシークレットをモニタリングする (p. 141)• AWS KMS を使用したシークレットの暗号化 (p. 141)• パラメータストア API を使用してシークレットを取得する (p. 141)

AWS CloudFormation でシークレットの作成を自動化する

Secrets Manager は AWS CloudFormation をサポートしており、スタックテンプレート内からシークレットを定義および参照できます。Secrets Manager では、シークレットを作成し、それを認証情報が格納されているサービスまたはデータベースに関連付けることができるようにする、いくつかの AWSCloudFormation リソースタイプを定義します。テンプレートの他の部分からシークレット内の要素を参照できます。たとえば、新しいデータベースでマスターユーザーとパスワードを定義するときに、シークレットからユーザー名とパスワードを取得します。リソースベースのポリシーを作成してシークレットにアタッチすることができます。テンプレートで Lambda 関数を定義し、その関数を新しいシークレットにローテーション Lambda 関数として関連付けることで、ローテーションを設定することもできます。詳細と包括的な例については、「AWS CloudFormation のシークレット作成を自動化する (p. 142)」を参照してください。

AWS Identity and Access Management (IAM) を使用したシークレットの保護

Secrets Manager ではシークレットに安全にアクセスするために IAM を使用します。IAM には次の機能があります。

• 認証 – 個々の要求の ID を確認します。Secrets Manager は、パスワード、アクセスキー、および多要素認証 (MFA) トークンを使用したサインインプロセスを使用して、ユーザーの識別を証明します。

• 認可 – シークレットなどの AWS リソースで、承認された個人のみがオペレーションを実行できるようにします。これにより、1 人のユーザーに特定のシークレットに対する書き込みアクセスを許可しながら、別のユーザーに別のシークレットに対する読み取り専用アクセス許可を付与することができます。

IAM を使用してシークレットへのアクセスを保護する方法の詳細については、このガイドの AWS SecretsManager に対する認証とアクセスコントロール (p. 34) を参照してください。IAM の詳細については、「IAM ユーザーガイド」を参照してください。

140

https://docs.aws.amazon.com/IAM/latest/UserGuide/

AWS Secrets Manager ユーザーガイドAWS CloudTrail と Amazon CloudWatch を使用してシークレットをモニタリングする

AWS CloudTrail と Amazon CloudWatch を使用してシークレットをモニタリングする

CloudTrail および CloudWatch を使用してシークレットに関連するアクティビティをモニタリングできます。CloudTrail は、すべての AWS サービスによる AWS リソースへの API アクティビティをキャプチャして、Amazon S3 バケットのログファイルにそのアクティビティを書き込みます。CloudWatch を使用すると、それらのログファイルをモニタリングするルールを作成し、関心のあるアクティビティが発生したときにアクションをトリガーします。たとえば、誰かが新しいシークレットが作成したときに、または、シークレットが正常にローテーションされたときに警告するテキストメッセージを表示できるようにします。クライアントが現在のバージョンの代わりに、廃止されたバージョンのシークレットを使用しようとしたときに、アラートを作成することもできます。これは、トラブルシューティングに役立ちます。

詳細については、このガイドの「AWS Secrets Manager シークレットの使用を監視する (p. 134)」を参照してください。CloudWatch の詳細については、「Amazon CloudWatch ユーザーガイド」を参照してください。CloudWatch イベントの詳細については、「Amazon CloudWatch Events ユーザーガイド」を参照してください。

AWS KMS を使用したシークレットの暗号化Secrets Manager は、信頼された業界標準のアドバンスト暗号化標準 (AES) 暗号化アルゴリズム (FIPS197) を使用して、シークレットを暗号化します。Secrets Manager はまた、AWS Key ManagementService (AWS KMS) によって提供される暗号化キーを使用して、シークレット値のエンベロープ暗号化を実行します。シークレットの新しいバージョンを作成すると、Secrets Manager は指定された AWS KMSカスタマーマスターキー (CMK) を使用して、新しいデータキーを生成します。データキーは 256 ビット対称の AES キーで構成されます。Secrets Manager は、データキーのプレーンテキストと暗号化されたコピーの両方を受け取ります。Secrets Manager はプレーンテキストのデータキーを使用してシークレット値を暗号化し、暗号化されたデータキーを秘密バージョンのメタデータに保存します。Secrets Managerにシークレット値を取得するためのリクエストを後で送信すると、Secrets Manager はまずメタデータから暗号化されたデータキーを取得し、それから AWS KMS に関連付けられた CMK を使用してデータキーの復号化をリクエストします。AWS KMS は、復号化されたデータキーを使用してシークレット値を復号化し、暗号化されていない状態のキーを保存することはなく、不要になったときはすぐにメモリからキーを削除します。

詳細については、『AWS Key Management Service Developer Guide』の「AWS Secrets Manager でAWS KMS を使用する方法」を参照してください。

パラメータストア API を使用してシークレットを取得する

AWS Systems Manager パラメータストアは､設定データ管理と機密管理のための安全な階層型ストレージを提供します。パスワード、データベース文字列、ライセンスコードなどのデータをパラメータ値として保存することができます。ただし、パラメータストアは保存されるシークレットの自動ローテーションサービスを提供していません。代わりに、パラメータストアで、Secrets Manager にシークレットを保存することができ、パラメータストアのパラメータとしてそのシークレットを参照できます。

Secrets Manager を使用してパラメータストアを設定する場合、secret-id パラメータストアでは、名前文字列の前にスラッシュ (/) が必要です。

詳細については、『AWS Systems Manager ユーザーガイド』の「パラメータストアのパラメータからAWS Secrets Manager Secrets を参照する」を参照してください。

141

https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/


https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.197.pdf

https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.197.pdf


https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#data-keys

https://docs.aws.amazon.com/kms/latest/developerguide/services-secrets-manager.html


https://docs.aws.amazon.com/systems-manager/latest/userguide/integration-ps-secretsmanager.html

https://docs.aws.amazon.com/systems-manager/latest/userguide/integration-ps-secretsmanager.html

AWS Secrets Manager ユーザーガイドAWS CloudFormation のシークレット作成を自動化する

AWS CloudFormation のシークレット作成を自動化する

AWS CloudFormation テンプレートを使用することで、AWS クラウドインフラストラクチャ内のデータベースまたはサービスリソース用のシークレットの作成を自動化できます。

AWS CloudFormation を使用して、クラウドインフラストラクチャの作成を自動化できます。JSON または YAML でテンプレートを作成し、プロジェクトに必要なリソースを定義します。AWS CloudFormationはテンプレートを処理し、定義されたリソースを構築します。これにより、必要に応じてインフラストラクチャの新しいコピーを簡単に再作成できるようになります。たとえば、テストインフラストラクチャを複製して、パブリックバージョンを作成できます。また、インフラストラクチャをシンプルなテキストファイルとして簡単に共有できます。これにより、他のユーザーが手動による介入なしにリソースを複製できるようになります。

CloudFormer を使用して、既存のリソースセットのすべての詳細を AWS CloudFormation テンプレートにキャプチャすることができます。

Secrets Manager には、AWS CloudFormation テンプレートの一部として作成できる次のリソースタイプがあります。AWS CloudFormation テンプレートでそれぞれを設定する方法の詳細については、AWSCloudFormation ユーザーガイドへのリンクのリソースタイプ名を選択します。

• AWS::SecretsManager::Secret – シークレットを作成し、Secrets Manager に保存します。パスワードは、ユーザーが指定するか、Secrets Manager に生成させることができます。空のシークレットを作成し、後でパラメータ SecretString. を更新することもできます。

• AWS::SecretsManager::ResourcePolicy – リソースベースのポリシーを作成し、指定されたシークレットにアタッチします。リソースベースのポリシーは、シークレットに対してアクションを実行できるユーザーを制御します。

• AWS::SecretsManager::RotationSchedule – 指定した Lambda ローテーション関数を使用して、定期的な自動ローテーションを実行するようにシークレットを設定します。

• AWS:: SecretsManager:: SecretTargetAttachment – シークレットを作成後、サービスまたはデータベースの作成時にそれを参照して認証情報にアクセスすると、このリソースタイプはシークレットに戻ってその設定を完了します。Secrets Manager は、ローテーションが機能するために必要なサービスまたはデータベースの詳細をシークレットに設定します。たとえば、Amazon RDS DB インスタンスでは、Secrets Manager は、接続の詳細とデータベースエンジンのタイプをシークレットのSecureString プロパティのエントリとして追加します。

例次のテンプレートの例では、シークレットと、そのシークレット内の認証情報をマスターユーザーおよびパスワードとして使用する Amazon RDS MySQL DB インスタンスを作成します。シークレットには、シークレットへのアクセスを指定するリソースベースのポリシーがアタッチされています。また、このテンプレートでは、Lambda ローテーション関数を作成し、このシークレットが 30 日ごとに自動的に更新されるように設定します。

Note

JSON 仕様ではコメントはサポートされていません。コメントについては、このページ後半のYAML バージョンを参照してください。

JSON{ "MyRDSInstanceRotationSecret": { "Type": "AWS::SecretsManager::Secret",

142

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-using-cloudformer.html

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-secretsmanager-secret.html

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-secretsmanager-resourcepolicy.html

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-secretsmanager-rotationschedule.html

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-secretsmanager-secrettargetattachment.html

https://json.org/

http://yaml.org/spec/1.2/spec.html

AWS Secrets Manager ユーザーガイド例

"Properties": { "Description": "A Secrets Manager secret for my RDS DB instance", "GenerateSecretString": { "SecretStringTemplate": "{\"username\": \"admin\"}", "GenerateStringKey": "password", "PasswordLength": 16, "ExcludeCharacters": "\"@/\\" } } }, "SecretRDSInstanceAttachment": { "Type": "AWS::SecretsManager::SecretTargetAttachment", "Properties": { "SecretId": {"Ref": "MyRDSInstanceRotationSecret"}, "TargetId": {"Ref": "MyDBInstance"}, "TargetType": "AWS::RDS::DBInstance" } }, "MyDBInstance": { "Type": "AWS::RDS::DBInstance", "Properties": { "AllocatedStorage": 20, "DBInstanceClass": "db.t2.micro", "Engine": "mysql", "MasterUsername": {"Fn::Join": [ "", ["{{resolve:secretsmanager:", {"Ref": "MyRDSInstanceRotationSecret"}, "::username}}"] ]}, "MasterUserPassword": {"Fn::Join": [ "", ["{{resolve:secretsmanager:", {"Ref": "MyRDSInstanceRotationSecret"}, "::password}}"] ]}, "BackupRetentionPeriod": 0, "DBInstanceIdentifier": "rotation-instance" } }, "MySecretRotationSchedule": { "Type": "AWS::SecretsManager::RotationSchedule", "DependsOn": "SecretRDSInstanceAttachment", "Properties": { "SecretId": {"Ref": "MyRDSInstanceRotationSecret"}, "RotationLambdaARN": {"Fn::GetAtt": ["MyRotationLambda","Arn"]}, "RotationRules": { "AutomaticallyAfterDays": 30 } } }, "MySecretResourcePolicy": { "Type": "AWS::SecretsManager::ResourcePolicy", "Properties": { "SecretId": {"Ref": "MyRDSInstanceRotationSecret"}, "ResourcePolicy": { "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Principal": {"AWS": {"Fn::Sub": "arn:aws:iam::${AWS::AccountId}:root"}}, "Action": "secretsmanager:DeleteSecret", "Resource": "*" } ] } } },

143


"LambdaInvokePermission": { "Type": "AWS::Lambda::Permission", "DependsOn": "MyRotationLambda", "Properties": { "FunctionName": "cfn-rotation-lambda", "Action": "lambda:InvokeFunction", "Principal": "secretsmanager.amazonaws.com" } }, "MyLambdaExecutionRole": { "Type": "AWS::IAM::Role", "Properties": { "RoleName": "cfn-rotation-lambda-role", "AssumeRolePolicyDocument": { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": {"Service": ["lambda.amazonaws.com"]}, "Action": ["sts:AssumeRole"] } ] }, "Policies": [ { "PolicyName": "AWSSecretsManagerRotationPolicy", "PolicyDocument": { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "secretsmanager:DescribeSecret", "secretsmanager:GetSecretValue", "secretsmanager:PutSecretValue", "secretsmanager:UpdateSecretVersionStage" ], "Resource": {"Fn::Sub": "arn:${AWS::Partition}:secretsmanager:${AWS::Region}:${AWS::AccountId}:secret:*"}, "Condition": { "StringEquals": { "secretsmanager:resource/AllowRotationLambdaArn": {"Fn::Sub": "arn:${AWS::Partition}:lambda:${AWS::Region}:${AWS::AccountId}:function:cfn-rotation-lambda"} } } }, { "Effect": "Allow", "Action": ["secretsmanager:GetRandomPassword"], "Resource": "*" }, { "Effect": "Allow", "Action": [ "logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents" ], "Resource": "arn:aws:logs:*:*:*" }, { "Effect": "Allow", "Action": [ "kms:Decrypt", "kms:DescribeKey", "kms:GenerateDataKey"

144


], "Resource": "*" } ] } } ] } }, "MyRotationLambda": { "Type": "AWS::Lambda::Function", "Properties": { "Runtime": "python2.7", "Role": {"Fn::GetAtt": ["MyLambdaExecutionRole","Arn"]}, "Handler": "lambda_function.lambda_handler", "Description": "This is a Secrets Manager rotation function for a MySQL RDS DB instance", "FunctionName": "cfn-rotation-lambda", "Environment": { "Variables": { "SECRETS_MANAGER_ENDPOINT": {"Fn::Sub": "https://secretsmanager.${AWS::Region}.amazonaws.com"} } }, "Code": { "S3Bucket": "<% replace-this-with-name-of-s3-bucket-that-contains-lambda-function-code %>", "S3Key": "<% replace-this-with-path-and-filename-of-zip-file-that-contains-lambda-function-code %>", "S3ObjectVersion": "<% replace-this-with-lambda-zip-file-version-if-s3-bucket-versioning-is-enabled %>" } } }}

YAML---Description: "This is an example template to demonstrate CloudFormation resources for Secrets Manager"Resources:

#This is a Secret resource with a randomly generated password in its SecretString JSON. MyRDSInstanceRotationSecret: Type: AWS::SecretsManager::Secret Properties: Description: 'This is my rds instance secret' GenerateSecretString: SecretStringTemplate: '{"username": "admin"}' GenerateStringKey: 'password' PasswordLength: 16 ExcludeCharacters: '"@/\' Tags: - Key: AppName Value: MyApp

#This is a RDS instance resource. Its master username and password use dynamic references to resolve values from #SecretsManager. The dynamic reference guarantees that CloudFormation will not log or persist the resolved value #We use a ref to the Secret resource logical id in order to construct the dynamic reference, since the Secret name is being

145


#generated by CloudFormation MyDBInstance: Type: AWS::RDS::DBInstance Properties: AllocatedStorage: 20 DBInstanceClass: db.t2.micro Engine: mysql MasterUsername: !Join ['', ['{{resolve:secretsmanager:', !Ref MyRDSInstanceRotationSecret, ':SecretString:username}}' ]] MasterUserPassword: !Join ['', ['{{resolve:secretsmanager:', !Ref MyRDSInstanceRotationSecret, ':SecretString:password}}' ]] BackupRetentionPeriod: 0 DBInstanceIdentifier: 'rotation-instance'

#This is a SecretTargetAttachment resource which updates the referenced Secret resource with properties about #the referenced RDS instance SecretRDSInstanceAttachment: Type: AWS::SecretsManager::SecretTargetAttachment Properties: SecretId: !Ref MyRDSInstanceRotationSecret TargetId: !Ref MyDBInstance TargetType: AWS::RDS::DBInstance

#This is a RotationSchedule resource. It configures rotation of password for the referenced secret using a rotation lambda #The first rotation happens at resource creation time, with subsequent rotations scheduled according to the rotation rules #We explicitly depend on the SecretTargetAttachment resource being created to ensure that the secret contains all the #information necessary for rotation to succeed MySecretRotationSchedule: Type: AWS::SecretsManager::RotationSchedule DependsOn: SecretRDSInstanceAttachment Properties: SecretId: !Ref MyRDSInstanceRotationSecret RotationLambdaARN: !GetAtt MyRotationLambda.Arn RotationRules: AutomaticallyAfterDays: 30

#This is ResourcePolicy resource which can be used to attach a resource policy to the referenced secret. #The resource policy in this example denies the DeleteSecret action to all principals within the current account MySecretResourcePolicy: Type: AWS::SecretsManager::ResourcePolicy Properties: SecretId: !Ref MyRDSInstanceRotationSecret ResourcePolicy: !Sub '{ "Version" : "2012-10-17", "Statement" : [ { "Effect": "Deny", "Principal": {"AWS":"arn:aws:iam::${AWS::AccountId}:root"}, "Action": "secretsmanager:DeleteSecret", "Resource": "*" } ] }'

#This is a lambda Function resource. We will use this lambda to rotate secrets #For details about rotation lambdas, see https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets.html #The below example assumes that the lambda code has been uploaded to a S3 bucket, and that it will rotate a mysql database password MyRotationLambda:

146


Type: AWS::Lambda::Function Properties: Runtime: python2.7 Role: !GetAtt MyLambdaExecutionRole.Arn Handler: lambda_function.lambda_handler Description: 'This is a lambda to rotate MySql user passwd' FunctionName: 'cfn-rotation-lambda' Environment: Variables: SECRETS_MANAGER_ENDPOINT: !Sub 'https://secretsmanager.${AWS::Region}.amazonaws.com' Code: S3Bucket: <% name-of-s3-bucket-that-contains-lambda-function-code %> S3Key: <% path-and-filename-of-zip-file-that-contains-lambda-function-code %> S3ObjectVersion: <% lambda-zip-file-version-if-s3-bucket-versioning-is-enabled %>

#This is a lambda Permission resource which grants Secrets Manager permission to invoke the rotation lambda function LambdaInvokePermission: Type: AWS::Lambda::Permission DependsOn: MyRotationLambda Properties: FunctionName: 'cfn-rotation-lambda' Action: 'lambda:InvokeFunction' Principal: secretsmanager.amazonaws.com

#This is the IAM Role resource for the rotation lambda, it grants permissions to the lambda to get and update the secret as part of the #rotation process. This includes required KMS permissions. It also includes permissions needed for logging to CloudWatch. MyLambdaExecutionRole: Type: AWS::IAM::Role Properties: RoleName: 'cfn-rotation-lambda-role' AssumeRolePolicyDocument: Version: "2012-10-17" Statement: - Effect: "Allow" Principal: Service: - "lambda.amazonaws.com" Action: - "sts:AssumeRole" Policies: - PolicyName: "AWSSecretsManagerRotationPolicy" PolicyDocument: Version: "2012-10-17" Statement: - Effect: "Allow" Action: - "secretsmanager:DescribeSecret" - "secretsmanager:GetSecretValue" - "secretsmanager:PutSecretValue" - "secretsmanager:UpdateSecretVersionStage" Resource: !Sub 'arn:${AWS::Partition}:secretsmanager:${AWS::Region}:${AWS::AccountId}:secret:*' Condition: StringEquals: secretsmanager:resource/AllowRotationLambdaArn: !Sub 'arn:${AWS::Partition}:lambda:${AWS::Region}:${AWS::AccountId}:function:cfn-rotation-lambda' - Effect: "Allow" Action:

147


- "secretsmanager:GetRandomPassword" Resource: "*" - Effect: "Allow" Action: - "logs:CreateLogGroup" - "logs:CreateLogStream" - "logs:PutLogEvents" Resource: "arn:aws:logs:*:*:*" - Effect: "Allow" Action: - "kms:Decrypt" - "kms:DescribeKey" - "kms:GenerateDataKey" Resource: "*"

148

AWS Secrets Manager ユーザーガイドAWS Secrets Manager でのデータ保護

AWS Secrets Manager でのセキュリティ

AWS では、セキュリティが最優先事項です。AWS のお客様は、セキュリティを最も重視する組織の要件を満たすよう構築されたデータセンターとネットワークアーキテクチャを利用できます。

お客様と AWS では、セキュリティの責任を共有します。責任共有モデルでは、これをクラウドのセキュリティおよびクラウド内のセキュリティとして説明しています。

• クラウドのセキュリティ – AWS は、AWS クラウドで AWS のサービスを実行するインフラストラクチャを保護する責任を担います。また、AWS には安全に使用できるサービスも用意されています。AWS コンプライアンスプログラムの一環として、サードパーティーの監査人によって定期的にセキュリティの有効性がテストおよび検証されています。 AWS Secrets Manager に適用されるコンプライアンスプログラムの詳細については、「コンプライアンスプログラムによる AWS 対象範囲内のサービス」を参照してください。

• クラウド内のセキュリティ – お客様の責任は、お客様の AWS のサービスによって決まります。また、お客様は、お客様のデータの機密性、企業の要件、および適用可能な法律および規制などの他の要因についても責任を担います。

トピック• AWS Secrets Manager でのデータ保護 (p. 149)• AWS Secrets Manager でのインフラストラクチャセキュリティ (p. 150)• AWS Secrets Manager での回復性 (p. 151)• AWS Secrets Manager のコンプライアンス検証 (p. 151)

AWS Secrets Manager でのデータ保護AWS Secrets Manager は、データ保護の規制やガイドラインを含む AWS 責任共有モデルに準拠しています。AWS は、AWS のすべてのサービスを実行するグローバルなインフラストラクチャを保護する責任を担います。また、AWS は、カスタマーコンテンツおよび個人データを取り扱うためのセキュリティ構成の統制など、このインフラストラクチャ上でホストされるデータ管理を維持します。データコントローラーまたはデータプロセッサとして機能する AWS のお客様および APN パートナーは、AWS クラウドに保存された個人データに対する責任を担います。

データ保護目的の場合、AWS アカウント認証情報を保護して AWS Identity and Access Management(IAM) で個々のユーザーアカウントを設定し、そのユーザーに各自の職務を果たすために必要なアクセス許可のみが付与されるようにすることをお勧めします。

保管時の暗号化Secrets Manager は、AWS Key Management Service (KMS) 経由の暗号化を使用して、保管中のデータの機密性を保護します。AWS KMS は、多くの AWS のサービスで使用されるキーストレージおよび暗号化サービスを提供します。AWS Secrets Manager では、すべてのシークレットを AWS KMS カスタマーマスターキー (CMK) に関連付けます。関連付けられた CMK は、アカウントのデフォルトの SecretsManager CMK になることも、独自の CMK を作成することもできます。CMK の作成の詳細については、「AWS Secrets Manager で AWS KMS を使用する方法」を参照してください。

149

https://aws.amazon.com/compliance/shared-responsibility-model/

https://aws.amazon.com/compliance/programs/

https://aws.amazon.com/compliance/services-in-scope/

https://aws.amazon.com/compliance/services-in-scope/

http://aws.amazon.com/compliance/shared-responsibility-model/

https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#master_keys

https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#master_keys


AWS Secrets Manager ユーザーガイド転送中の暗号化

転送中の暗号化Secrets Manager では、転送中のデータを暗号化するための安全なプライベートエンドポイントを提供します。安全なプライベートエンドポイントにより、AWS では、Secrets Manager への API リクエストの整合性を保護できます。AWS では、X.509 証明書や AWS Secrets Manager シークレットアクセスキーを使用して、発信者が API コールに署名する必要があります。この要件は、署名バージョン 4 署名プロセス(Sigv4) に記載されています。

AWS コマンドラインインターフェイス (CLI) またはいずれかの AWS SDK を使用して AWS を呼び出す場合、これらのツールは指定されたアクセスキーを自動的に使用してリクエストに署名します。CLI または任意の AWS SDK を設定する場合は、使用するアクセスキーを指定します。

暗号化キーの管理Secrets Manager で保護されたシークレットデータの新しいバージョンを暗号化する必要があるたびに、Secrets Manager では指定された CMK から新しいデータキーを作成するよう AWS KMS に要求します。Secrets Manager では、このデータキーをエンベロープ暗号化に使用します。Secrets Manager は、暗号化されたデータキーを、暗号化されたシークレットを使用して保存します。シークレットを復号化する必要がある場合、Secrets Manager は AWS KMS にデータキーの復号化を要求します。その後 SecretsManager は、復号化されたデータキーを使用して、暗号化された秘密を解読します。Secrets Manager では、データキーを暗号化されていない形式で保存することはなく、メモリからキーをできるだけ早く削除します。

暗号化および復号のプロセスの詳細、および Secrets Manager で AWS KMS を使用する方法についての詳細な説明は、「AWS Secrets Manager で AWS KMS を使用する方法」を参照してください。

ネットワーク内のトラフィックプライバシーAWS には、既知のネットワークルートとプライベートネットワークルートを経由してトラフィックをルーティングする際にプライバシーを維持するためのオプションが用意されています。

サービスとオンプレミスのクライアントおよびアプリケーションとの間のトラフィックプライベートネットワークと AWS Secrets Manager との間には 2 つの接続オプションがあります。

• AWS サイト間 VPN 接続。詳細については、「AWS Site-to-Site VPN とは」を参照してください。• AWS Direct Connect 接続。詳細については、「AWS Direct Connect とは」を参照してください。

同じリージョン内の AWS リソース間のトラフィックAWS で Secrets Manager と API クライアント間のトラフィックを保護する場合、AWS PrivateLink を設定して、Secrets Manager API エンドポイントにプライベートにアクセスするようにします。

AWS Secrets Manager でのインフラストラクチャセキュリティ

マネージド型サービスとして、AWS Secrets Manager は、ホワイトペーパー「Amazon Web Services: セキュリティプロセスの概要」に記載されている AWS グローバルネットワークセキュリティの手順で保護されています。

150




https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html

https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html

https://aws.amazon.com/privatelink/

https://d0.awsstatic.com/whitepapers/Security/AWS_Security_Whitepaper.pdf

https://d0.awsstatic.com/whitepapers/Security/AWS_Security_Whitepaper.pdf

AWS Secrets Manager ユーザーガイド弾力

AWS が公開している API コールを使用して、ネットワーク経由で Secrets Manager にアクセスします。クライアントで Transport Layer Security (TLS) 1.1 以降がサポートされている必要があります。TLS1.2 以降が推奨されています。また、Ephemeral Diffie-Hellman (DHE) や Elliptic Curve Ephemeral Diffie-Hellman (ECDHE) などの Perfect Forward Secrecy (PFS) を使用した暗号スイートもクライアントでサポートされている必要があります。これらのモードは、Java 7 以降など、最近のほとんどのシステムでサポートされています。

また、リクエストは、アクセスキー ID と、IAM プリンシパルに関連付けられているシークレットアクセスキーを使用して署名する必要があります。または、AWS Security Token Service (AWS STS) を使用して、一時的なセキュリティ認証情報を生成し、リクエストに署名することもできます。

AWS Secrets Manager での回復性AWS では、グローバルインフラストラクチャは AWS のリージョンとアベイラビリティーゾーンを中心として構築されます。AWS リージョンには、低レイテンシー、高いスループット、そして高度の冗長ネットワークで接続されている複数の物理的に独立、隔離されたアベイラビリティーゾーンがあります。アベイラビリティーゾーンでは、ゾーン間で中断することなく自動的にフェイルオーバーするアプリケーションとデータベースを設計および運用することができます。アベイラビリティーゾーンは、従来の単一または複数のデータセンターインフラストラクチャよりも優れた可用性、耐障害性、および拡張性をもたらします。

AWS リージョンとアベイラビリティーゾーンの詳細については、「AWS グローバルインフラストラクチャ」を参照してください。

AWS Secrets Manager のコンプライアンス検証サードパーティーの監査者は、複数の AWS コンプライアンスプログラムの一環として AWS SecretsManager のセキュリティとコンプライアンスを評価します。このプログラムには、SOC、PCI、HIPAA などがあります。

特定のコンプライアンスプログラムの対象となる AWS サービスのリストについては、「コンプライアンスプログラムによる AWS 対象範囲内のサービス」を参照してください。一般的な情報については、「AWS コンプライアンスプログラム」を参照してください。

サードパーティーの監査レポートをダウンロードするには、AWS Artifact を使用します。詳細については、「AWS Artifact でレポートをダウンロードする」を参照してください。

Secrets Manager を使用する際のお客様のコンプライアンス責任は、データの機密性、企業のコンプライアンス目的、適用法規や規制によって決まります。AWS ではコンプライアンスに役立つ以下のリソースを用意しています。

• セキュリティおよびコンプライアンスのクイックスタートガイド – これらのデプロイガイドでは、アーキテクチャ上の考慮事項について説明し、セキュリティとコンプライアンスに重点を置いたベースライン環境を AWS でデプロイするための手順を説明します。

• HIPAA のセキュリティとコンプライアンスに関するホワイトペーパーを作成する – このホワイトペーパーでは、企業が AWS を使用して HIPAA 準拠のアプリケーションを作成する方法について説明します。

• AWS コンプライアンスのリソース – このワークブックおよびガイドのコレクションは、お客様の業界や場所に適用される場合があります。

• AWS Config 開発者ガイドの「ルールでのリソースの評価」– AWS Config サービスでは、リソース設定が社内のプラクティス、業界のガイドライン、規制にどの程度適合しているかを評価します。

• AWS Security Hub – この AWS サービスでは、AWS 内のセキュリティ状態を包括的に表示しており、セキュリティ業界の標準およびベストプラクティスへの準拠を確認するのに役立ちます。

151

https://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html

http://aws.amazon.com/about-aws/global-infrastructure/

http://aws.amazon.com/about-aws/global-infrastructure/

http://aws.amazon.com/compliance/services-in-scope/

http://aws.amazon.com/compliance/services-in-scope/

http://aws.amazon.com/compliance/programs/

https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html

http://aws.amazon.com/quickstart/?awsf.quickstart-homepage-filter=categories%23security-identity-compliance

https://d0.awsstatic.com/whitepapers/compliance/AWS_HIPAA_Compliance_Whitepaper.pdf

http://aws.amazon.com/compliance/resources/

https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html

https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html

AWS Secrets Manager ユーザーガイドAWS Secrets Manager のクォータ

AWS Secrets Managerリファレンスこのセクションのトピックを使用して、AWS Secrets Manager のさまざまな側面に関する詳細な参考資料を検索します。

トピック• AWS Secrets Manager のクォータ (p. 152)• Lambda ローテーション関数の作成に使用できる AWS テンプレート (p. 153)• AWS 管理ポリシーを AWS Secrets Manager で使用可能 (p. 161)• AWS Secrets Manager の IAM ポリシー、またはシークレットポリシーで使用できるアクション、リ

ソースおよびコンテキストキー。 (p. 162)

AWS Secrets Manager のクォータこのセクションでは、AWS Secrets Manager のクォータを指定します。

名前の制限AWS Secrets Manager には、シークレットの名前を含め、作成する名前に関する次の制限があります。

• シークレット名は、Unicode 文字を使用する必要があります。• シークレット名は、256 文字文字を超えることはできません。

最大クォータAWS Secrets Manager のエンティティのデフォルトの最大クォータを次に示します。

エンティティ値

AWS アカウントのシークレット

40,000

シークレットのバージョン

~100

シークレットのすべてのバージョンにアタッチされたラベル

20

ラベルに同時にアタッチされたバージョン

1

シークレットの長さ 65,536 バイト

リソースベースポリシーの長さ - JSON テキスト

20,480 文字

152

AWS Secrets Manager ユーザーガイドレートクォータ

レートクォータこれらのパラメータには、AWS Secrets Manager の次のレートクォータがあります。

リクエストタイプ許可されているオペレーションの 1 秒あたりの数

アカウントの全体的なAPI クォータ

2,000

DescribeSecret

GetSecretValue

2,000

PutResourcePolicy

GetResourcePolicy

DeleteResourcePolicy

CreateSecret

UpdateSecret

UpdateSecretVersionStage

PutSecretValue

DeleteSecret

RestoreSecret

RotateSecret

CancelRotateSecret

AssociateSecretLabels

DisassociateSecretLabels

GetRandomPassword

40

TagResource

UntagResource

ListSecrets

ListSecretVersionIds

20

Lambda ローテーション関数の作成に使用できるAWS テンプレート

このセクションでは、AWS Secrets Manager のシークレットのための Lambda ローテーション関数を作成するために使用できる AWS マネージドテンプレートを示します。これらのテンプレートは AWSServerless Application Repository に関連付けられます。このリポジトリは AWS CloudFormation を使用し

153

AWS Secrets Manager ユーザーガイドAmazon RDS データベースのテンプレート

て、事前設定されたリソースの「スタック」を作成します。この場合、テンプレートによって、Lambda関数および IAM ロールで構成されるスタックが作成されます。Secrets Manager では、ローテーションが発生したときにこのスタックを使用して、関数を呼び出します。

次のいずれかのテンプレートを使用して Lambda ローテーション関数を作成するには、指定したテンプレートの ARN をコピーして、「他のデータベースやサービスのローテーションと AWS Secrets Managerのシークレット (p. 103)」のトピックに記載されている CLI コマンドに貼り付けます。

次の各テンプレートは、データベースとローテーション戦略の異なる組み合わせに対して Lambda ローテーション関数を作成します。それぞれの下の最初の箇条書きは、関数によってサポートされているデータベースまたはサービスを示しています。2 番目の箇条書きでは、関数によって実装されるローテーション戦略について説明します。3 番目の箇条書きは、更新されたシークレットの SecretString 値でローテーション関数が見つけると予想される JSON 構造体を示します。

RDS データベース

• RDS MariaDB シングルユーザー (p. 154)• RDS MariaDB マスターユーザー (p. 155)• RDS MySQL シングルユーザー (p. 155)• RDS MySQL マスターユーザー (p. 156)• RDS Oracle シングルユーザー (p. 156)• RDS Oracle マスターユーザー (p. 157)• RDS PostgreSQL シングルユーザー (p. 157)• RDS PostgreSQL マスターユーザー (p. 158)• RDS Microsoft SQLServer シングルユーザー (p. 158)• RDS Microsoft SQLServer マスターユーザー (p. 159)

その他のデータベースおよびサービス

• MongoDB シングルユーザー (p. 159)• MongoDB マスターユーザー (p. 160)• Amazon Redshift シングルユーザー (p. 160)• Amazon Redshift マスターユーザー (p. 161)• 汎用ローテーション関数テンプレート (p. 161)

Amazon RDS データベースのテンプレートRDS MariaDB シングルユーザー

arn:aws:serverlessrepo:us-east-1:1234456789012:applications/SecretsManagerRDSMariaDBRotationSingleUser

• 名前: SecretsManagerRDSMariaDBRotationSingleUser• サポートされているデータベースまたはサービス: Amazon Relational Database Service(Amazon RDS)

データベースインスタンスでホストされている MariaDB データベース。• ローテーション戦略: これは、更新されたシークレットに保存されている認証情報を持つユーザーのパス

ワードを変更します。この戦略の詳細については、「1 つのパスワードを使用してシングルユーザーのAWS Secrets Manager シークレットを更新する (p. 112)」を参照してください。

• 予想されるSecretString構造体:

154


{ "engine": "mariadb", "host": "<required: instance host name/resolvable DNS name>", "username": "<required: username>", "password": "<required: password>", "dbname": "<optional: database name. If not specified, defaults to None>", "port": "<optional: TCP port number. If not specified, defaults to 3306>"}

• ソースコード

RDS MariaDB マスターユーザー

arn:aws:serverlessrepo:us-east-1:123456789012:applications/SecretsManagerRDSMariaDBRotationMultiUser

• 名前: SecretsManagerRDSMariaDBRotationMultiUser• サポートされているデータベースまたはサービス: Amazon RDS データベースインスタンスでホストさ

れている MariaDB データベース。• ローテーション戦略: ローテーション中に 2 人のユーザーが、別のシークレットに保存されている別の

マスターユーザーの認証情報を使用して入れ替わります。Secrets Manager は、非アクティブユーザーがアクティブユーザーになる前に、非アクティブユーザーのパスワードを変更します。この戦略の詳細については、「既存の 2 人のユーザーを切り替えることで AWS Secrets Manager シークレットを更新する (p. 116)」を参照してください。


{ "engine": "mariadb", "host": "<required: instance host name/resolvable DNS name>", "username": "<required: username>", "password": "<required: password>", "dbname": "<optional: database name. If not specified, defaults to None>", "port": "<optional: TCP port number. If not specified, defaults to 3306>", "masterarn": "<required: the ARN of the master secret used to create 2nd user and change passwords>"}


RDS MySQL シングルユーザー

arn:aws:serverlessrepo:us-east-1:123456789012:applications/SecretsManagerRDSMySQLRotationSingleUser

• 名前: SecretsManagerRDSMySQLRotationSingleUser• サポートされているデータベースまたはサービス: Amazon Relational Database Service (Amazon RDS)

データベースインスタンスでホストされている MySQL データベース。• ローテーション戦略: これは、更新されたシークレットに保存されている認証情報を持つユーザーのパス



{

155

https://github.com/aws-samples/aws-secrets-manager-rotation-lambdas/tree/master/SecretsManagerRDSMariaDBRotationSingleUser/lambda_function.py

https://github.com/aws-samples/aws-secrets-manager-rotation-lambdas/tree/master/SecretsManagerRDSMariaDBRotationMultiUser/lambda_function.py


"engine": "mysql", "host": "<required: instance host name/resolvable DNS name>", "username": "<required: username>", "password": "<required: password>", "dbname": "<optional: database name. If not specified, defaults to None>", "port": "<optional: TCP port number. If not specified, defaults to 3306>"}


RDS MySQL マスターユーザー

arn:aws:serverlessrepo:us-east-1:123456789012:applications/SecretsManagerRDSMySQLRotationMultiUser

• 名前: SecretsManagerRDSMySQLRotationMultiUser• サポートされているデータベースまたはサービス: Amazon RDS データベースインスタンスでホストさ

れている MySQL データベース。• ローテーション戦略: ローテーション中に 2 人のユーザーが、別のシークレットに保存されている別の



{ "engine": "mysql", "host": "<required: instance host name/resolvable DNS name>", "username": "<required: username>", "password": "<required: password>", "dbname": "<optional: database name. If not specified, defaults to None>", "port": "<optional: TCP port number. If not specified, defaults to 3306>", "masterarn": "<required: the ARN of the master secret used to create 2nd user and change passwords>"}


RDS Oracle シングルユーザー

arn:aws:serverlessrepo:us-east-1:123456789012:applications/SecretsManagerRDSOracleRotationSingleUser

• 名前: SecretsManagerRDSOracleRotationSingleUser• サポートされているデータベースまたはサービス: Amazon Relational Database Service (Amazon RDS)

データベースインスタンスでホストされている Oracle データベース。• ローテーション戦略: これは、更新されたシークレットに保存されている認証情報を持つユーザーのパス



{ "engine": "oracle", "host": "<required: instance host name/resolvable DNS name>",

156

https://github.com/aws-samples/aws-secrets-manager-rotation-lambdas/tree/master/SecretsManagerRDSMySQLRotationSingleUser/lambda_function.py

https://github.com/aws-samples/aws-secrets-manager-rotation-lambdas/tree/master/SecretsManagerRDSMySQLRotationMultiUser/lambda_function.py


"username": "<required: username>", "password": "<required: password>", "dbname": "<required: database name>", "port": "<optional: TCP port number. If not specified, defaults to 1521>"}


RDS Oracle マスターユーザー

arn:aws:serverlessrepo:us-east-1:123456789012:applications/SecretsManagerRDSOracleRotationMultiUser

• 名前: SecretsManagerRDSOracleRotationMultiUser• サポートされているデータベースまたはサービス: Amazon RDS データベースインスタンスでホストさ

れている Oracle データベース。• ローテーション戦略: ローテーション中に 2 人のユーザーが、別のシークレットに保存されている別の



{ "engine": "oracle", "host": "<required: instance host name/resolvable DNS name>", "username": "<required: username>", "password": "<required: password>", "dbname": "<required: database name>", "port": "<optional: TCP port number. If not specified, defaults to 1521>", "masterarn": "<required: the ARN of the master secret used to create 2nd user and change passwords>"}


RDS PostgreSQL シングルユーザー

arn:aws:serverlessrepo:us-east-1:123456789012:applications/SecretsManagerRDSPostgreSQLRotationSingleUser

• 名前: SecretsManagerRDSPostgreSQLRotationSingleUser• サポートされているデータベースまたはサービス: Amazon RDS データベースインスタンスでホストさ

れている PostgreSQL データベース。• ローテーション戦略: これは、更新されたシークレットに保存されている認証情報を持つユーザーのパス



{ "engine": "postgres", "host": "<required: instance host name/resolvable DNS name>", "username": "<required: username>", "password": "<required: password>",

157

https://github.com/aws-samples/aws-secrets-manager-rotation-lambdas/tree/master/SecretsManagerRDSOracleRotationSIngleUser/lambda_function.py

https://github.com/aws-samples/aws-secrets-manager-rotation-lambdas/tree/master/SecretsManagerRDSOracleRotationMultiUser/lambda_function.py


"dbname": "<optional: database name. If not specified, defaults to 'postgres'>", "port": "<optional: TCP port number. If not specified, defaults to 5432>"}


RDS PostgreSQL マスターユーザー

arn:aws:serverlessrepo:us-east-1:123456789012:applications/SecretsManagerRDSPostgreSQLRotationMultiUser

• 名前: SecretsManagerRDSPostgreSQLRotationMultiUser• サポートされているデータベースまたはサービス: Amazon RDS データベースインスタンスでホストさ

れている PostgreSQL データベース。• ローテーション戦略: ローテーション中に 2 人のユーザーが、別のシークレットに保存されている別の



{ "engine": "postgres", "host": "<required: instance host name/resolvable DNS name>", "username": "<required: username>", "password": "<required: password>", "dbname": "<optional: database name. If not specified, defaults to 'postgres'>", "port": "<optional: TCP port number. If not specified, defaults to 5432>", "masterarn": "<required: the ARN of the master secret used to create 2nd user and change passwords>"}


RDS Microsoft SQLServer シングルユーザー

arn:aws:serverlessrepo:us-east-1:123456789012:applications/SecretsManagerRDSSQLServerRotationSingleUser

• 名前: SecretsManagerRDSSQLServerRotationSingleUser• サポートされているデータベースまたはサービス: Amazon RDS データベースインスタンスでホストさ

れている Microsoft SQLServer データベース。• ローテーション戦略: これは、更新されたシークレットに保存されている認証情報を持つユーザーのパス



{ "engine": "sqlserver", "host": "<required: instance host name/resolvable DNS name>", "username": "<required: username>", "password": "<required: password>", "dbname": "<optional: database name. If not specified, defaults to 'master'>", "port": "<optional: TCP port number. If not specified, defaults to 1433>"

158

https://github.com/aws-samples/aws-secrets-manager-rotation-lambdas/tree/master/SecretsManagerRDSPostgreSQLRotationSingleUser/lambda_function.py

https://github.com/aws-samples/aws-secrets-manager-rotation-lambdas/tree/master/SecretsManagerRDSPostgreSQLRotationMultiUser/lambda_function.py

AWS Secrets Manager ユーザーガイド他のデータベースのテンプレート

}


RDS Microsoft SQLServer マスターユーザー

arn:aws:serverlessrepo:us-east-1:123456789012:applications/SecretsManagerRDSSQLServerRotationMultiUser

• 名前: SecretsManagerRDSSQLServerRotationMultiUser• サポートされているデータベースまたはサービス: Amazon RDS データベースインスタンスでホストさ

れている Microsoft SQLServer データベース。• ローテーション戦略: ローテーション中に 2 人のユーザーが、別のシークレットに保存されている別の



{ "engine": "sqlserver", "host": "<required: instance host name/resolvable DNS name>", "username": "<required: username>", "password": "<required: password>", "dbname": "<optional: database name. If not specified, defaults to 'master'>", "port": "<optional: TCP port number. If not specified, defaults to 1433>", "masterarn": "<required: the ARN of the master secret used to create 2nd user and change passwords>"}


他のデータベースのテンプレートMongoDB シングルユーザー

arn:aws:serverlessrepo:us-east-1:123456789012:applications/SecretsManagerMongoDBRotationSingleUser

• 名前: SecretsManagerMongoDBRotationSingleUser• サポートされているデータベースまたはサービス: MongoDB データベースのバージョン 3.2 または

3.4。• ローテーション戦略: これは、更新されたシークレットに保存されている認証情報を持つユーザーのパス



{ "engine": "mongo", "host": "<required: instance host name/resolvable DNS name>", "username": "<required: username>", "password": "<required: password>", "dbname": "<optional: database name. If not specified, defaults to None>",

159

https://github.com/aws-samples/aws-secrets-manager-rotation-lambdas/tree/master/SecretsManagerRDSSQLServerRotationSingleUser/lambda_function.py

https://github.com/aws-samples/aws-secrets-manager-rotation-lambdas/tree/master/SecretsManagerRDSSQLServerRotationMultiUser/lambda_function.py

AWS Secrets Manager ユーザーガイド他のデータベースのテンプレート

"port": "<optional: TCP port number. If not specified, defaults to 27017>"}

• ソースコード: ソースコード

MongoDB マスターユーザー

arn:aws:serverlessrepo:us-east-1:123456789012:applications/SecretsManagerMongoDBRotationMultiUser

• 名前: SecretsManagerMongoDBRotationMultiUser• サポートされるデータベースまたはサービス: MongoDB データベースのバージョン 3.2 または 3.4。• ローテーション戦略: ローテーション中に 2 人のユーザーが、別のシークレットに保存されている別の

マスターユーザーの認証情報を使用して交互に入れ替わります。Secrets Manager は、非アクティブユーザーがアクティブユーザーになる前に、非アクティブユーザーのパスワードを変更します。この戦略の詳細については、「既存の 2 人のユーザーを切り替えることで AWS Secrets Manager シークレットを更新する (p. 116)」を参照してください。


{ "engine": "mongo", "host": "<required: instance host name/resolvable DNS name>", "username": "<required: username>", "password": "<required: password>", "dbname": "<optional: database name. If not specified, defaults to None>", "port": "<optional: TCP port number. If not specified, defaults to 27017>", "masterarn": "<required: the ARN of the master secret used to create 2nd user and change passwords>"}


Amazon Redshift シングルユーザー

arn:aws:serverlessrepo:us-east-1:123456789012:applications/SecretsManagerRedShiftRotationSingleUser

• 名前: SecretsManagerRedShiftRotationSingleUser• サポートされているデータベースまたはサービス: Amazon Redshift• ローテーション戦略: これは、更新されたシークレットに保存されている認証情報を持つユーザーのパス



{ "engine": "redshift", "host": "<required: instance host name/resolvable DNS name>", "username": "<required: username>", "password": "<required: password>", "dbname": "<optional: database name. If not specified, defaults to None>", "port": "<optional: TCP port number. If not specified, defaults to 5439>"}


160

https://github.com/aws-samples/aws-secrets-manager-rotation-lambdas/tree/master/SecretsManagerMongoDBRotationSingleUser/lambda_function.py

https://github.com/aws-samples/aws-secrets-manager-rotation-lambdas/tree/master/SecretsManagerMongoDBRotationMultiUser/lambda_function.py

https://github.com/aws-samples/aws-secrets-manager-rotation-lambdas/tree/master/SecretsManagerRedshiftRotationSingleUser/lambda_function.py

AWS Secrets Manager ユーザーガイド他のサービスのテンプレート

Amazon Redshift マスターユーザー

arn:aws:serverlessrepo:us-east-1:123456789012:applications/SecretsManagerRedShiftRotationMultiUser

• 名前: SecretsManagerRedShiftRotationMultiUser• サポートされているデータベースまたはサービス: Amazon Redshift• ローテーション戦略: ローテーション中に 2 人のユーザーが、別のシークレットに保存されている別の

マスターユーザーの認証情報を使用して交互に入れ替わります。Secrets Manager は、非アクティブユーザーがアクティブユーザーになる前に、非アクティブユーザーのパスワードを変更します。この戦略の詳細については、「既存の 2 人のユーザーを切り替えることで AWS Secrets Manager シークレットを更新する (p. 116)」を参照してください。


{ "engine": "redshift", "host": "<required: instance host name/resolvable DNS name>", "username": "<required: username>", "password": "<required: password>", "dbname": "<optional: database name. If not specified, defaults to None>", "port": "<optional: TCP port number. If not specified, defaults to ?????>", "masterarn": "<required: the ARN of the master secret used to create 2nd user and change passwords>"}


他のサービスのテンプレート汎用ローテーション関数テンプレート

arn:aws:serverlessrepo:us-east-1:123456789012:applications/SecretsManagerRotationTemplate

• 名前: SecretsManagerRotationTemplate• サポートされているデータベースまたはサービス: なし。必要なサービスを操作するためにコードを指定

します。• ローテーション戦略: なし。必要なローテーション戦略を実装するためのコードを提供します。独自の関

数のカスタマイズの詳細については、「Lambda ローテーション関数の理解とカスタマイズ (p. 108)」を参照してください。

• 予想される SecretString 構造体: これは、記述するコードの一部として定義します。• ソースコード: ソースコード

AWS 管理ポリシーを AWS Secrets Manager で使用可能

このセクションでは、シークレットへのアクセスを管理するのに使用できる AWS 管理ポリシーを特定します。AWS 管理ポリシーを変更または削除することはできませんが、必要に応じてアカウント内のエンティティにアタッチまたはデタッチすることができます。

161

https://github.com/aws-samples/aws-secrets-manager-rotation-lambdas/tree/master/SecretsManagerRedshiftRotationMultiUser/lambda_function.py

https://github.com/aws-samples/aws-secrets-manager-rotation-lambdas/tree/master/SecretsManagerRotationTemplate/lambda_function.py

AWS Secrets Manager ユーザーガイドアクション、リソース、およびコンテキストキー

ポリシー名説明 ARN

SecretsManagerReadWriteほとんどの Secrets Manager オペレーションへのアクセスを提供します。ローテーションにはロールを作成するための IAMアクセス許可が必要であるため、このポリシーではローテーションの設定は有効になりません。他のユーザーが Lambda ローテーション関数を設定してローテーションを有効にする必要があり、ユーザーがIAMFullAccess 管理ポリシーを割り当てることも必要です。

arn:aws:iam::aws:policy/SecretsManagerReadWrite

AWS Secrets Manager の IAM ポリシー、またはシークレットポリシーで使用できるアクション、リソースおよびコンテキストキー。

IAM ポリシーまたはシークレットポリシーで参照可能なアクション次の表は、IAM ポリシーで指定できるアクセス許可やシークレットへのアクセスを管理するシークレットポリシーを一覧表示しています。アクションへの各アクセス許可は、アクションの動作を指定するリソースと関連付けることができます。

ポリシー内の Resource 要素と一致する Amazon リソースネーム (ARN) を持つシークレットにのみに、いくつかのアクションを使用するよう制限することができます。このトピックの後半のセクション「IAMポリシーまたはシークレットポリシーで参照可能なリソース (p. 165)」を参照してください。

最後の列に表示されている AWS Secrets Manager 固有のコンテキストキーに加えて、AWS グローバル条件コンテキストキーも使用します。

表の右上隅に矢印 (↗) が表示された場合、その表は新しいウィンドウで開くことができます。ウィンドウを閉じるには、右下隅にある閉じるボタン (X) を選択します。

「Action」要素のアクセス許可

このアクションによって有効化された API オペレーション

このアクションで「リソース」として使用されるリソース ARN

このアクションで使用される SecretsManager コンテキストキー

secretsmanager:CancelRotateSecretCancelRotateSecret シークレット (p. 165)

secretsmanager:SecretId (p. 166)

secretsmanager:AllowRotationLambdaArn (p. 166)

secretsmanager:ResourceTag/<tagname> (p. 166)

secretsmanager:CreateSecret CreateSecret secretsmanager:Name (p. 166)

secretsmanager:Description (p. 166)

secretsmanager:KmsKeyId (p. 166)

162



https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html


https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_CancelRotateSecret.html

https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_CreateSecret.html

AWS Secrets Manager ユーザーガイドアクション





secretsmanager:DeleteResourcePolicyDeleteResourcePolicy シークレット (p. 165)




secretsmanager:DeleteSecret DeleteSecret シークレット (p. 165)




secretsmanager:DescribeSecretDescribeSecret シークレット (p. 165)



secretsmanager:RecoveryWindowInDays (p. 166)

secretsmanager:ForceDeleteWithoutRecovery (p. 166)


secretsmanager:GetRandomPasswordGetRandomPassword

secretsmanager:GetResourcePolicyGetResourcePolicy シークレット (p. 165)




secretsmanager:GetSecretValueGetSecretValue シークレット (p. 165)


secretsmanager:VersionId (p. 167)

secretsmanager:VersionStage (p. 167)



secretsmanager:ListSecrets ListSecrets

secretsmanager:ListSecretVersionIdsListSecretVersionIds シークレット (p. 165)




163

https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_DeleteResourcePolicy.html

https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_DeleteSecret.html

https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_DescribeSecret.html

https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetRandomPassword.html


https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetSecretValue.html

https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_ListSecrets.html

https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_ListSecretVersionIds.html

AWS Secrets Manager ユーザーガイドアクション





secretsmanager:PutResourcePolicyPutResourcePolicy シークレット (p. 165)




secretsmanager:PutSecretValuePutSecretValue シークレット (p. 165)


secretsmanager:RestoreSecretRestoreSecret シークレット (p. 165)




secretsmanager:RotateSecret RotateSecret シークレット (p. 165)


secretsmanager:RotationLambdaArn (p. 166)



secretsmanager:TagResource TagResource シークレット (p. 165)




secretsmanager:UntagResourceUntagResource シークレット (p. 165)




secretsmanager:UpdateSecretUpdateSecret シークレット (p. 165)


secretsmanager:Description (p. 166)

secretsmanager:KmsKeyId (p. 166)



164

https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_PutResourcePolicy.html

https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_PutSecretValue.html

https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_RestoreSecret.html


https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_TagResource.html

https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_UntagResource.html


AWS Secrets Manager ユーザーガイドリソース





secretsmanager:UpdateSecretVersionStageUpdateSecretVersionStageシークレット (p. 165)


secretsmanager:VersionStage (p. 167)



IAM ポリシーまたはシークレットポリシーで参照可能なリソース次の表は、AWS Secrets Manager の IAM ポリシーでサポートされている ARN 形式を表しています。それぞれのエンティティ ID は、Secrets Manager コンソールの各シークレットの [Secret details (シークレットの詳細)] ページで確認できます。

表の右上隅に矢印 (↗) が表示された場合、その表は新しいウィンドウで開くことができます。ウィンドウを閉じるには、右下隅にある閉じるボタン (X) を選択します。

リソースタイプ ARN 形式

シークレット arn:aws:secretsmanager:<Region>:<AccountId>:secret:OptionalPath/SecretName-6RandomCharacters

Secrets Manager は、シークレットの名前の最後にダッシュと 6 つのランダムな英数字を加えることで、ARN の最後の部分を構成します。シークレットを削除してから同じ名前の別のシークレットを作成した場合、Secrets Manager が 6 つのランダムな文字を生成するため、元のシークレットのアクセス許可を持つユーザーは、新しいシークレットに自動でアクセスしなくなるため、この形式が役に立ちます。

IAM ポリシーまたはシークレットポリシーで参照可能なコンテキストキーAWS Secrets Manager のコンテキストキーは、通常、API コールのリクエストパラメータに対応します。これにより、パラメータ値に基づいてリクエストを許可またはブロックできます。

各コンテキストキーは、条件演算子を使用して指定した値と比較することができます。使用するコンテキストキーは、選択したアクションによって異なります。このトピックの冒頭にある「アクション (p. 162)」セクションの「コンテキストキー」の列を参照してください。

たとえば、次に類似する Condition 要素を使用して、シークレット値の AWSCURRENT バージョンのみを取得することを誰かに許可することができます。

"Condition": {"ForAnyValue:StringEquals" : {"secretsmanager:VersionStage" : "AWSCURRENT"}}

次の表は、アクションへのアクセスをより細かく制御する IAM アクセス許可ポリシーの Condition 要素で指定できる Secrets Manager 固有のコンテキストキーを示しています｡以下のキーに加えて、AWS グローバル条件コンテキストキーも使用できます。

165

https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_UpdateSecretVersionStage.html



AWS Secrets Manager ユーザーガイドコンテキストキー

「Condition」要素のコンテキストキー説明

secretsmanager:Resource/AllowRotationLambdaArn

リクエストが対象にしているリソースに添付された Lambda ローテーション関数の ARN に基づいてリクエストをフィルターします。これにより、この値に一致するローテーション Lambda ARN があるシークレットのみにアクセスを制限できます。ローテーションが有効になっていないシークレットまたは、異なるローテーション Lambda ARN があるシークレットは一致しません。

secretsmanager:Description

リクエストの Description パラメータに基づいてリクエストをフィルターします。

secretsmanager:ForceDeleteWithoutRecovery

削除に復旧期間を指定しないかどうかに基づいてリクエストをフィルターします。これにより、実質的にこの機能は無効になります。

secretsmanager:KmsKeyId

リクエストの KmsKeyId パラメータに基づいてリクエストをフィルターします。これにより、リクエストで使用できるキーを制限できます。

secretsmanager:Name

リクエストの Name パラメータ値に基づいてリクエストをフィルターします。これにより、シークレットの名前をこの値に一致するものだけに制限できます。

secretsmanager:RecoveryWindowInDays

復旧期間が指定されているリクエストをフィルタリングします。承認された日数で復旧期間が発生するように強制できます。

secretsmanager:ResourceTag/<tagname>

シークレットにアタッチされたタグに基づいてリクエストをフィルターします。<tagname> を実際のタグ名に置き換えます。その後、条件演算子を使用してタグが存在することを確認し、要求された値を含めます。

secretsmanager:RotationLambdaArn

RotationLambdaARN パラメータに基づいてリクエストをフィルタリングします。これにより、シークレットで利用できる Lambda ローテーション関数を制限できます。キーは、CreateSecret と既存のシークレットを変更する操作の両方で使用できます。

secretsmanager:SecretId

SecretId パラメータで指定されたシークレットの一意の識別子に基づいてリクエストをフィルターします。この値は、シークレットのフレンドリーネームまたは ARN のいずれかです。これにより、

166


「Condition」要素のコンテキストキー説明リクエストでアクセスできるシークレットを制限できます。

secretsmanager:VersionId

リクエストの VersionId パラメータに基づいてリクエストをフィルターします。これにより、アクセスできるシークレットのバージョンを制限できます。

secretsmanager:VersionStage

リクエストの VersionStage パラメータで特定したステージングラベルに基づいてリクエストをフィルターします。この文字列配列パラメータの値のいずれかと一致するステージングラベルを持つシークレットバージョンだけにアクセスできるよう制限できます。これはキーが複数の値の文字列配列を使用することから、この値と文字列を比較するために、いずれかの集合演算子を使用しなければなりません。

AWS グローバル条件キーAWSは、グローバル条件キー、アクセスコントロール用に IAM を使用するすべての AWS サービスに対して事前に定義された条件キーの一式を提供します。たとえば、aws:PrincipalType 条件キーを使用すると、リクエストのプリンシパルに指定したタイプが含まれている場合のみアクセスを許可します。

Secrets Manager では、リクエストのリソースタグに基づき、アクセスを管理する aws:TagKeys やaws:RequestTag 条件キーなど、すべてのグローバル条件キーをサポートしています。すべてではなく、一部の AWS のサービスのみがこれらの条件キーをサポートしています。

トピック• ポリシーで Secrets Manager アクセス権限とともに IP アドレス条件を使用する (p. 167)• ポリシーで Secrets Manager アクセス許可とともに VPC エンドポイント条件を使用する (p. 168)

ポリシーで Secrets Manager アクセス権限とともに IP アドレス条件を使用するSecrets Manager を使用して、データベースまたはサービスの認証情報を保護できます。ただし、同じポリシーステートメントで、Secrets Manager へのアクセスを許可または拒否する IP アドレス条件の演算子または aws:SourceIp 条件キーを指定するときは注意が必要です。たとえば、「AWS: 送信元 IP に基づいて AWS へのアクセスを拒否する」に示されているポリシーでは、AWS アクションが、指定された IP範囲からのリクエストに制限されます。

シークレットにも同様のポリシーを添付すると、社内ネットワークの IP アドレス範囲からのみシークレットにアクセスできるようになり、社内ネットワークから IAM ユーザーとして呼び出すリクエストが想定通りに機能します。ただし、Lambda 関数でのローテーションを有効にするなど、ユーザーの代わりに他のサービスがシークレットにアクセスできるようにすると、この関数は AWS 内部のアドレス空間からSecrets Manager オペレーションを呼び出します。IP アドレスのフィルターがあるポリシーによって影響されたリクエストは失敗します。

また、リクエストが Amazon VPC エンドポイントから送信されている場合、aws:sourceIP 条件キーは、効果的ではなくなります。リクエストを Secrets Manager VPC エンドポイントなどの特定の VPC エンドポイントに制限するには、aws:sourceVpce または aws:sourceVpc 条件キーを使用します。詳細については、Amazon VPC ユーザーガイドの「VPC エンドポイント - エンドポイントの使用の管理」を参照してください。

167





https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html#Conditions_IPAddress

https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html#Conditions_IPAddress

https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_aws_deny-ip.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_aws_deny-ip.html

https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-endpoints.html

https://docs.aws.amazon.com/kms/latest/developerguide/kms-vpc-endpoint.html

https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-endpoints.html#vpc-endpoints-iam-access


ポリシーで Secrets Manager アクセス許可とともに VPC エンドポイント条件を使用する

Secrets Manager は、AWS PrivateLink が提供したAmazon VPCエンドポイント (p. 126)をサポートします。IAM ポリシー、またはリソースベースのポリシー (p. 49)のグローバル条件キーを使用して、特定のVPC または VPC エンドポイントからのリクエストを許可または拒否できます。

• aws:SourceVpc は、指定した VPC からのリクエストにアクセスを制限します。• aws:SourceVpce は、指定した VPC エンドポイントからのリクエストにアクセスを制限します。

これらの条件キーをシークレットポリシーステートメントで使用して、Secrets Manager シークレットへのアクセスを許可または拒否すると、ユーザーに代わってシークレットへのアクセスに Secrets Managerを使用するサービスへのアクセスを意図せず拒否してしまうことがあります。VPC 内で、一部の AWSサービスのみがエンドポイントで実行できます。シークレットのリクエストを VPC または VPC エンドポイントに制限すると、サービスに設定されていないサービスからの Secrets Manager への呼び出しは失敗します。

168

https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Introduction.html#what-is-privatelink


AWS Secrets Manager ユーザーガイド一般的な問題のトラブルシューティング

AWS Secrets Manager のトラブルシューティング

AWS Secrets Manager の操作中に問題が発生した場合は、このセクションのトピックを参照してください。

トピック• 一般的な問題のトラブルシューティング (p. 169)• シークレットの AWS Secrets Manager ローテーションのトラブルシューティング (p. 170)

一般的な問題のトラブルシューティングこの情報を使用して、アクセス拒否された問題や、AWS Secrets Manager を操作するときに発生する可能性のある他の一般的な問題の診断や修復を行います。

トピック• AWS Secrets Manager にリクエストを送信すると、「アクセスが拒否されました」というメッセージ

が表示される。 (p. 169)• 一時的なセキュリティ認証情報を使用してリクエストを送信すると「アクセスが拒否されました」と

いうメッセージが表示される。 (p. 169)• 変更がすぐに表示されない。 (p. 170)• シークレットを作成するときに「非対称 CMK でデータキーを生成できません」というメッセージが表

示される。 (p. 170)

AWS Secrets Manager にリクエストを送信すると、「アクセスが拒否されました」というメッセージが表示される。• 要求したオペレーションとリソースを呼び出す権限を持っているかを確認します。管理者は、IAM ユー

ザーまたは自分がメンバーとして所属しているグループに IAM ポリシーをアタッチしてアクセス許可を付与する必要があります。ポリシーが時間帯や IP アドレス制限などの条件を含む権限を付与する記述をしている場合は、リクエストを送信する際にそれらの条件を満たす必要もあります。IAM ユーザー、グループ、ロールのポリシーの表示や修正の詳細については、IAM ユーザーガイドのポリシーの使用を参照してください。

• 手動で API リクエストに署名する (AWS SDK を使用しない) 場合は、正確にリクエストに署名していることを確認します。

一時的なセキュリティ認証情報を使用してリクエストを送信すると「アクセスが拒否されました」というメッセージが表示される。• リクエストの作成に使用している IAM ユーザーまたはロールに適切なアクセス許可があることを確認し

ます。一時的なセキュリティ認証情報のアクセス許可は IAM ユーザーまたはロールから取得されます。

169

https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage.html

http://aws.amazon.com/tools/

https://docs.aws.amazon.com/general/latest/gr/signing_aws_api_requests.html

AWS Secrets Manager ユーザーガイド変更がすぐに表示されない。

つまり、アクセス許可は IAM ユーザーまたはロールに付与されたものに限定されます。一時的なセキュリティ認証情報のアクセス許可がどのように決定されるかについては、『IAM ユーザーガイド』の一時的なセキュリティ認証情報のアクセス許可を制御するを参照してください。

• リクエストが正しく署名されており、そのリクエストの形式が整っていることを確認します。詳細については、選択した SDK のツールキットドキュメントか、『IAM ユーザーガイド』の「一時的なセキュリティ認証情報を使用して AWS リソースへのアクセスをリクエストする」を参照してください。

• 一時的な認証情報が失効していないことを確認します。詳細については、『IAM ユーザーガイド』の「一時的セキュリティ認証情報のリクエスト」を参照してください。

変更がすぐに表示されない。世界中のデータセンター内のコンピュータを介してアクセスされるサービスとして、AWS SecretsManager は、結果整合性と呼ばれる分散コンピューティングモデルを採用しています。SecretsManager（または他の AWS サービス）で行った変更は、すべての可能なエンドポイントから認識されるまでに時間がかかります。この遅延は、サーバー間、レプリケーションゾーン間、世界中のリージョン間でのデータ送信にかかる時間から発生している場合もあります。Secrets Manager ではパフォーマンス向上のためにキャッシュも使用しているため、これが原因で遅延が発生することがあります。変更は、以前にキャッシュされたデータがタイムアウトになるまで反映されない場合があります。

発生する可能性のあるこれらの遅延を考慮して、グローバルなアプリケーションを設計します。また、ある場所で行われた変更が他の場所で直ちに表示されない場合でも、期待どおりに機能するようにしてください。

AWS の他のいくつかのサービスがこの遅延からどのような影響を受けるかの詳細については、以下のリソースを参照してください。

• 『Amazon Redshift Database Developer Guide』の「データの整合性の管理」• 『Amazon Simple Storage Service 開発者ガイド』の「Amazon S3 のデータ整合性モデル」• AWS ビッグデータブログの「ETL ワークフローに Amazon S3 および Amazon Elastic MapReduce を使

用する場合の整合性の確保」• 『Amazon EC2 API Reference』の「EC2 の結果整合性」•

シークレットを作成するときに「非対称 CMK でデータキーを生成できません」というメッセージが表示される。非対称 CMK ではなく、対称カスタマーマスターキー (CMK) を使用していることを確認します。SecretsManager は、シークレットに関連付けられた対称カスタマーマスターキー (CMK) を使用して、シークレット値ごとにデータキーを生成します。また、Secrets Manager は、暗号化されたシークレット値を復号する必要がある場合に、CMK を使用してそのデータキーを復号します。AWS CloudTrail イベント、Amazon CloudWatch Logs、および監査証跡でリクエストとレスポンスを追跡できます。現時点では、非対称 CMK は使用できません。

シークレットの AWS Secrets Manager ローテーションのトラブルシューティング

この情報を使用して、Secrets Manager シークレットを更新するときに発生する可能性がある一般的なエラーの診断や修復を行います。

170

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_control-access.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_control-access.html


https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_request.html

https://wikipedia.org/wiki/Eventual_consistency

https://docs.aws.amazon.com/redshift/latest/dg/managing-data-consistency.html

https://docs.aws.amazon.com/AmazonS3/latest/dev/Introduction.html#ConsistencyModel

http://aws.amazon.com/blogs/big-data/ensuring-consistency-when-using-amazon-s3-and-amazon-elastic-mapreduce-for-etl-workflows/

http://aws.amazon.com/blogs/big-data/ensuring-consistency-when-using-amazon-s3-and-amazon-elastic-mapreduce-for-etl-workflows/

https://docs.aws.amazon.com/AWSEC2/latest/APIReference/query-api-troubleshooting.html#eventual-consistency

AWS Secrets Manager ユーザーガイドLambda ローテーション関数の診断ログを確認する方法

AWS Secrets Manager のシークレットの更新では、シークレットを所有するデータベースまたはサービスとやりとりする方法を定義する Lambda 関数を使用する必要があります。

一般的なローテーションエラー• Lambda ローテーション関数の診断ログを確認する方法 (p. 171)• ローテーションが開始される時を予測できません (p. 171)• シークレットのローテーションを設定しようとすると「アクセス拒否」が発生する (p. 171)• ローテーションを有効にすると最初のローテーションに失敗する (p. 172)• シークレット値はローテーション関数が予期する形式ではないため、ローテーションが失敗しま

す。 (p. 172)• Secrets Manager は、ローテーションを正常に設定したが、パスワードはローテーションしていな

い (p. 173)• ローテーションがエラーメッセージ「内部エラー」で失敗する (p. 173)• CloudTrail がローテーション中にアクセス拒否エラーを表示する (p. 173)

Lambda ローテーション関数の診断ログを確認する方法ローテーション関数が期待どおりに動作していない場合、最初に CloudWatch ログを確認する必要があります。Secrets Manager では、Lambda ローテーション関数用テンプレートコードを提供し、このコードが CloudWatch ログにエラーメッセージを書き込みます。

Lambda 関数の CloudWatch ログを表示するには

1. AWS Lambda コンソール (https://console.aws.amazon.com/lambda/) を開きます。2. 関数のリストから、シークレットに関連付けられている Lambda 関数の名前を選択します。3. [Monitoring] タブを選択します。4. [呼び出しエラー] セクションで、[Jump to Logs] (ログにジャンプ) を選択します。

CloudWatch コンソールが開き、関数のログを表示します。

ローテーションが開始される時を予測できません次のローテーションの日付のみを予測できます。時間は予測できません。


シークレットのローテーションを設定しようとすると「アクセス拒否」が発生するLambda ローテーション関数の Amazon リソースネーム (ARN) をシークレットに追加すると、SecretsManager は、関数のアクセス許可をチェックします。関数のロールポリシーは、Secrets Manager サービスプリンシパル secretsmanager.amazonaws.com に、関数 (lambda:InvokeFunction) を呼び出すアクセス許可を付与する必要があります。

このアクセス許可を追加するには、次の AWS CLI コマンドを実行します。

171


AWS Secrets Manager ユーザーガイドローテーションを有効にすると

最初のローテーションに失敗する

aws lambda add-permission --function-name ARN_of_lambda_function --principal secretsmanager.amazonaws.com --action lambda:InvokeFunction --statement-id SecretsManagerAccess

ローテーションを有効にすると最初のローテーションに失敗する「マスター」シークレットを使用して保護されたサービスで認証情報を変更するシークレットのローテーションを有効にすると、Secrets Manager は、ローテーションに必要なほとんどの要素を自動的に設定します。ただし、Secrets Manager は、Lambda 関数にマスターシークレットを読み取るためのアクセス許可を自動的に付与することはできません。このアクセス許可を明示的に付与する必要があります。具体的には、Lambda ローテーション関数にアタッチされた IAM ロールにアタッチされているポリシーにアクセス許可を追加して、アクセス許可を付与します。このポリシーには、次のステートメントが含まれている必要があります (これは、ステートメントのみで、ポリシー全体ではありません)。ポリシー全体については、セクション CloudTrail がローテーション中にアクセス拒否エラーを表示する (p. 173) の 2 番目のサンプルポリシーを参照してください。

{ "Sid": "AllowAccessToMasterSecret", "Effect": "Allow", "Action": "secretsmanager:GetSecretValue", "Resource": "ARN_of_master_secret"}

これにより、ローテーション関数は、マスターシークレットから認証情報を取得することができます。次に、マスターシークレットの認証情報を使用して、ローテーションされるシークレットの認証情報を変更することができます。

シークレット値はローテーション関数が予期する形式ではないため、ローテーションが失敗します。また、シークレット値はローテーション関数が予期する JSON 構造形式ではないため、ローテーションが失敗する可能性があります。使用するローテーション関数によって、使用する形式が決まります。各ローテーション関数で必要となるシークレット値の詳細については、Lambda ローテーション関数の作成に使用できる AWS テンプレート (p. 153) の該当するローテーション値のエントリで「予測されるSecretString 値」を参照してください。

たとえば、MySQL 単一ユーザーローテーション関数を使用する場合、SecretString テキスト構造は次のようになる必要があります。

{ "engine": "mysql", "host": "<required: instance host name/resolvable DNS name>", "username": "<required: username>", "password": "<required: password>", "dbname": "<optional: database name. If not specified, defaults to None>", "port": "<optional: TCP port number. If not specified, defaults to 3306>"}

172

AWS Secrets Manager ユーザーガイドSecrets Manager は、ローテーションを正常に設

定したが、パスワードはローテーションしていない

Secrets Manager は、ローテーションを正常に設定したが、パスワードはローテーションしていないこれは、Lambda 関数がセキュリティ保護されたデータベース/サービス、またはパブリックインターネットの Secrets Manager サービスエンドポイントと通信できないようなネットワーク設定の問題がある場合に発生することがあります。VPC でデータベースまたはサービスを実行する場合は、設定に 2 つのオプションのいずれかを使用します。

• VPC 内のデータベースを Amazon EC2 Elastic IP アドレスでパブリックにアクセス可能にします。• データベース/サービスと同じ VPC で操作するように Lambda ローテーション関数を設定します。• VPC がパブリックインターネットにアクセスできない場合、たとえば、アクセス用に NAT ゲートウェ

イを使用して VPC を設定していない場合、VPC 内からアクセスできる Secrets Manager 用のプライベートサービスエンドポイントを持つ VPC を設定 (p. 77)する必要があります。

このタイプの設定の問題がローテーションの失敗の原因であるかどうかを判断するには、以下の手順を実行します。

ローテーション関数とデータベース、または Secrets Manager との間の接続の問題を診断するには

1. 手順 Lambda ローテーション関数の診断ログを確認する方法 (p. 171) に従って、ログを開きます。2. ログファイルを調べ、Lambda 関数と AWS Secrets Manager サービスの間、または Lambda 関数と

セキュリティで保護されたデータベースまたはサービスとの間にタイムアウトが発生していることを示していないかを確認します。

3. VPC 環境内で相互運用するためにサービスと Lambda 関数を設定する方法については、「 AmazonVirtual Private Cloud ドキュメント」と「AWS Lambda Developer Guide」を参照してください。

ローテーションがエラーメッセージ「内部エラー」で失敗するローテーション関数で新しいパスワードを生成し、それを新しい認証情報としてデータベースに保管する場合は、指定されたデータベースに有効な文字のみパスワードに含まれていることを確認する必要があります。パスワードにデータベースエンジンで受け入れられない文字が含まれていると、ユーザーのパスワードの設定は失敗します。このエラーは、「内部エラー」として表示されます。使用できる文字のリストについては、データベースのドキュメントを参照してください。次に、GetRandomPassword API コールの ExcludeCharacters パラメータを使用して、その他すべてを除外します。

CloudTrail がローテーション中にアクセス拒否エラーを表示するローテーションを設定するときに、Secrets Manager にローテーション関数を作成させると、SecretsManager により、適切なアクセス許可を付与する関数の IAM ロールにアタッチされたポリシーが自動的に提供されます。カスタム関数を作成する場合、関数にアタッチされているロールに、次のアクセス許可を付与する必要があります。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [

173



https://aws.amazon.com/documentation/vpc/

https://aws.amazon.com/documentation/vpc/


https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetRandomPassword.html#SecretsManager-GetRandomPassword-request-ExcludeCharacters

AWS Secrets Manager ユーザーガイドCloudTrail がローテーション中

にアクセス拒否エラーを表示する

"secretsmanager:DescribeSecret", "secretsmanager:GetRandomPassword", "secretsmanager:GetSecretValue", "secretsmanager:PutSecretValue", "secretsmanager:UpdateSecretVersionStage", ], "Resource": "*" } ]}

また、ローテーションで、別個のマスターシークレットの認証情報を使用してこのシークレットをローテーションする場合は、マスターシークレットからシークレット値を取得する権限を付与する必要があります。詳細については、「ローテーションを有効にすると最初のローテーションに失敗する (p. 172)」を参照してください。結合されたポリシーは次のようになります。

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowAccessToSecretsManagerAPIs", "Effect": "Allow", "Action": [ "secretsmanager:DescribeSecret", "secretsmanager:GetRandomPassword", "secretsmanager:GetSecretValue", "secretsmanager:PutSecretValue", "secretsmanager:UpdateSecretVersionStage", ], "Resource": "*" }, { "Sid": "AllowAccessToMasterSecret", "Effect": "Allow", "Action": "secretsmanager:GetSecretValue", "Resource": "<arn_of_master_secret>" } ]}

174

AWS Secrets Manager ユーザーガイドエンドポイント

HTTP クエリリクエストの送信による API の呼び出し

このセクションは、AWS Secrets Manager に対して Query API を使用する場合についての一般的な情報を提供します。API オペレーションとエラーの詳細については、AWS Secrets Manager API リファレンスを参照してください。

Note

AWS Secrets Manager Query API に直接呼び出しを送信する代わりに、いずれかの AWS SDKを使用することができます。AWS SDK は、様々なプログラム言語およびプラットフォームのライブラリやサンプルコード (Java、Ruby、.NET、iOS、Android など) から成ります。SDKは、Secrets Manager や AWS へのプログラムによるアクセス権限を作成する際に役立ちます。例えば、SDK は要求への暗号を使用した署名、エラーの管理、要求の自動的な再試行などのタスクを実行します。AWS SDK のダウンロードやインストールなどの詳細については、「AWS での構築ツール」を参照してください。

AWS Secrets Manager 用クエリ API により、サービスオペレーションを呼び出すことができます。QueryAPI リクエストは、HTTPS リクエストであり、実行するべき操作を示す Action パラメータを含める必要があります。AWS Secrets Manager は、すべての操作の GET リクエストおよび POST リクエストをサポートしています。この API では、あるオペレーションに対しては GET を、他のアクションに対してはPOST をといった使い分けを必要としません。しかしながら、GET リクエストは URL のサイズに制限があります。この制限はブラウザによって異なりますが、一般的な制限は 2048 バイトです。したがって、大きなサイズを必要とする Query API リクエストにおいては、POST リクエストを使用する必要があります。

API は XML ドキュメントでレスポンスを返します。応答の詳細については、「AWS Organizations API リファレンス」の個別の API 説明ページを参照してください。

トピック• エンドポイント (p. 175)• HTTPS の必要性 (p. 175)• Secrets Manager の API リクエストへの署名 (p. 176)

エンドポイントAWS Secrets Manager のエンドポイントはほとんどの AWS リージョンでご利用いただけます。詳細なリストについては、『AWS General Reference』の AWS Secrets Manager のエンドポイントのリストを参照してください。

すべてのサービスの AWS エンドポイントとリージョンの詳細については、『AWS General Reference』の「リージョンとエンドポイント」を参照してください。

HTTPS の必要性Query API は、セキュリティ認証情報などの機密情報を返すため、必ず HTTPS を使用してすべての APIリクエストを暗号化する必要があります。

175




https://docs.aws.amazon.com/organizations/latest/APIReference/

https://docs.aws.amazon.com/organizations/latest/APIReference/


https://docs.aws.amazon.com/general/latest/gr/index.html?rande.html

AWS Secrets Manager ユーザーガイドSecrets Manager の API リクエストへの署名

Secrets Manager の API リクエストへの署名API リクエストに、アクセスキー ID およびシークレットアクセスキーを使用して署名する必要があります。Secrets Manager での日々の作業には、AWS アカウントのルートユーザーの認証情報を使用しないよう強くお勧めします。代わりに、IAM ユーザーの認証情報、または IAM ロールで使用するような一時的な認証情報を使用できます。

API リクエストに署名するには、AWS 署名バージョン 4 を使用する必要があります。署名バージョン 4の使用については、AWS 全般のリファレンスの署名バージョン 4 の署名プロセスを参照してください。

詳細については、以下を参照してください。

• AWS セキュリティ認証情報。AWS へのアクセスに使用できる認証情報の種類について、一般的な情報を説明します。

• IAM のベストプラクティス。Secrets Manager に含まれるリソースなど、AWS リソースの保護に役立つIAM の使用に関するアドバイスを説明します。

• 一時認証情報。一時的な認証情報の作成方法と使用方法を説明します。

176


https://docs.aws.amazon.com/general/latest/gr/aws-security-credentials.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html


AWS Secrets Manager のドキュメント履歴

次の表は、AWS Secrets Manager のドキュメントの主な更新をまとめたものです。

• API バージョン: 2017-10-17

update-history-change update-history-description update-history-date

CloudFormation テンプレートは、短くて使いやすいテンプレートに置き換えられました。 (p. 177)

テンプレートでは、CloudFormation の設定を作成するのに 60 行のコードしか使用されません。

November 20, 2019

エンドポイントポリシーのドキュメントを追加しました

エンドポイントポリシーを使用して、Secrets Manager VPC エンドポイントでシークレット関連のアクティビティを制御できるようになりました。Secrets ManagerVPC エンドポイントのエンドポイントポリシーを作成するためのセクションを追加しました。また、すべての VPC エンドポイントコンテンツの個別のリファレンス記事を作成しました。

July 25, 2019

Python、Go、.NET のキャッシュクライアントを追加

Python、Go、.NET のキャッシュクライアントを取得する GitHubへのリンクを追加しました。

May 9, 2019

Redshift と DocumentDB に対応するシークレットのタイプを追加

Redshift および DocumentDBデータベースをシークレットタイプに追加しました。

March 7, 2019

サポートされているデータベースを更新

ローテーションに対応するためにAmazon RDS でサポートされているデータベース (Microsoft SQLServer、Oracle など) の全リストを追加しました。

December 2, 2018

PCI および ISO コンプライアンス

コンプライアンス規格のセクションに PCI および ISO 規格を含めました。

December 1, 2018

既存の Lambda ローテーション関数とシークレットを使用する

Secrets Manager コンソールでシークレットのローテーションを有効にすると、新しい関数を作成できるだけでなく、既存のLambda 関数を選択できるようになりました。

November 15, 2018

177

https://docs.aws.amazon.com/secretsmanager/latest/userguide/vpc-endpoint-overview.html#vpc-endpoint-policy

https://docs.aws.amazon.com/secretsmanager/latest/userguide/vpc-endpoint-overview.html#vpc-endpoint-policy

https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_retrieve-secret.html#use-client-side-caching-components

https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_retrieve-secret.html#use-client-side-caching-components

https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_create-basic-secret.html



https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html#full-rotation-support

https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html#full-rotation-support

https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html#asm_compliance


https://docs.aws.amazon.com/secretsmanager/latest/userguide/enable-rotation-rds.html

https://docs.aws.amazon.com/secretsmanager/latest/userguide/enable-rotation-rds.html


Secrets Manager コンソールを使用してシークレットにタグ付けする

Secrets Manager コンソールを使用してシークレットを作成および変更する際にタグを含められるようになりました。

November 15, 2018

CloudFormation を使用してプログラムでシークレットを作成する

CloudFormation テンプレートでシークレットを定義して、作成できるようになりました。シークレットが完全にサポートされているデータベースのいずれかに関連付けられている場合はさらに、テンプレートの処理中に動的に認証情報を生成でき、それらの認証情報を使用するように、また自動的にローテーションされるシークレットに保存するように、データベースを設定できます。

November 12, 2018

復旧期間なしでシークレットを削除する

復旧期間なしでシークレットを削除できるようになりました。これにより、最低 7 日間待機しなくても不要なシークレットを「クリーンアップ」できます。

August 9, 2018

プライベート VPC サービスエンドポイント

VPC 内で、Secrets Manager のプライベートサービスエンドポイントを設定できるようになりました。これにより、パブリックインターネット接続を必要とせずに、VPC 内で Secrets ManagerAPI オペレーションを呼び出すことができます。

July 11, 2018

リソースベースのポリシーシークレットにアクセスできるユーザーを決定する IAM アクセス許可ポリシーを、シークレットに直接アタッチできるようになりました。また、これにより、リソースベースのポリシーのPrincipal 要素で AWS を指定できるため、クロスアカウントアクセスを有効にできます。

June 26, 2018

HIPAA への準拠 Secrets Manager が HIPAA 対象サービスとして利用可能になりました。

June 4, 2018

サービスの初回リリース AWS Secrets Manager の初期リリースのドキュメントが提供されています。

April 4, 2018

178

https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_update-secret.html#proc-tags



https://docs.aws.amazon.com/secretsmanager/latest/userguide/integrating_cloudformation.html



https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_delete-restore-secret.html

https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_delete-restore-secret.html

https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotation-network-rqmts.html

https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotation-network-rqmts.html

https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access_resource-based-policies.html


https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html


AWS の用語集最新の AWS の用語については、『AWS General Reference』の「AWS の用語集」を参照してください。

179

https://docs.aws.amazon.com/general/latest/gr/glos-chap.html

aws secrets manager - ユーザーガイド...secrets manager...

Documents