▪️目的
AWSでシステムを構築すると、データベースのパスワードやAPIキーなど、外部に漏れてはいけない情報を扱うことがあります。
例えば、アプリケーションからRDSに接続する場合、データベースのユーザー名やパスワードが必要です。
では、このような機密情報をどこに保存すればよいのでしょうか？
アプリケーションのソースコードに直接書いたり、設定ファイルにそのまま保存したりすると、情報漏えいにつながる可能性があります。
そこで利用できるのが、AWS Secrets Managerです。
Secrets Managerは、データベースの認証情報やAPIキーなどの機密情報を安全に保存・管理・取得できるAWSのサービスです。
この記事では、AWS初心者向けに以下の内容を解説します。
- Secrets Managerとは何か
- なぜ機密情報を管理する必要があるのか
- Secrets Managerの仕組み
- KMSとの関係
- シークレットのローテーション
- IAMによるアクセス制御
- Systems Manager Parameter Storeとの違い
- 実際のAWS構成での利用例
AWSでシステムを構築・運用するうえで重要なサービスなので、仕組みから理解していきましょう。
目次
- AWS Secrets Managerとは？
- なぜ機密情報の管理が必要なのか
- Secrets Managerで管理できる情報
- Secrets Managerの仕組み
- KMSとの関係
- シークレットのローテーション
- IAMによるアクセス制御
- RDSとSecrets Managerの連携
- Secrets ManagerとParameter Storeの違い
- Secrets Managerを利用するときの注意点
- まとめ
▪️AWS Secrets Managerとは？
AWS Secrets Managerは、システムで利用する機密情報を安全に管理するためのサービスです。
Secrets Managerで管理する機密情報は、AWSでは「シークレット（Secret）」と呼ばれます。
例えば、以下のような情報です。
- データベースのユーザー名・パスワード
- 外部サービスのAPIキー
- アプリケーションの認証情報
- OAuthトークンなどの認証用情報
これらの情報は、システムを動かすために必要ですが、第三者に漏れると不正アクセスにつながる可能性があります。
Secrets Managerを利用すると、機密情報をアプリケーションのソースコードなどに直接記述せず、必要なときにAWSのサービスから取得する構成にできます。
例えば、次のようなイメージです。
アプリケーション
|
| 機密情報を取得
v
Secrets Manager
|
v
データベースの認証情報
このように、アプリケーションと機密情報を分離して管理できます。
Secrets Managerは機密情報の保存だけでなく、アクセス制御やローテーションなどにも対応しています。
▪️なぜ機密情報の管理が必要なのか
Secrets Managerの役割を理解するために、まず機密情報を適切に管理しない場合の問題を考えてみましょう。
♦︎ソースコードに直接記述する場合
例えば、アプリケーションからRDSに接続するために、ソースコードへパスワードを直接記述したとします。
DB_HOST = "example-db"
DB_USER = "app_user"
DB_PASSWORD = "password123"
このような書き方では、ソースコードを閲覧できる人がパスワードまで確認できてしまう可能性があります。
また、ソースコードをGitなどのバージョン管理システムに登録した場合、機密情報までリポジトリに含まれてしまう危険性があります。
一度コミットした機密情報は、ファイルから削除しただけでは履歴に残ることもあります。
♦︎Secrets Managerを利用する場合
Secrets Managerを利用すると、機密情報をソースコードとは別に管理できます。
アプリケーション
|
| Secrets Managerから取得
v
Secrets Manager
|
v
データベースの認証情報
アプリケーションには、機密情報そのものではなく、Secrets Managerから取得するための処理を実装します。
これにより、ソースコードにパスワードを直接記述するリスクを減らせます。
ただし、Secrets Managerを利用すれば自動的に安全になるわけではありません。誰がシークレットを取得できるのか、取得した情報をどこに保存するのか、といった点も考慮する必要があります。
▪️Secrets Managerで管理できる情報
Secrets Managerでは、さまざまな機密情報を管理できます。
| 情報 | 利用例 |
|---|---|
| データベースの認証情報 | RDSへの接続 |
| APIキー | 外部サービスとの連携 |
| アプリケーションの認証情報 | 外部システムへの接続 |
| OAuthトークン | APIの認証 |
| その他の機密情報 | システム固有の認証情報 |
例えば、Webアプリケーションが外部の決済サービスを利用する場合、APIキーが必要になることがあります。
このAPIキーをソースコードに直接記述するのではなく、Secrets Managerで管理し、必要なときに取得する構成にできます。
また、RDSの認証情報をSecrets Managerで管理すれば、データベースのパスワード変更をアプリケーションのコード変更と切り離して管理しやすくなります。
このように、Secrets ManagerはAWS上のシステムだけでなく、外部サービスと連携するアプリケーションでも利用できます。
▪️Secrets Managerの仕組み
Secrets Managerの基本的な仕組みを整理しましょう。
大きく分けると、次のような流れになります。
① 機密情報を登録
|
v
② Secrets Managerで管理
|
v
③ アプリケーションが取得
|
v
④ 取得した情報を使って処理
例えば、RDSのパスワードを管理する場合は、以下のようになります。
- Secrets Managerにデータベースの認証情報を登録する
- アプリケーションに必要なIAM権限を設定する
- アプリケーションがSecrets Managerから認証情報を取得する
- 取得した認証情報を使ってRDSに接続する
ここで重要なのは、Secrets Managerに保存されている情報を、誰でも自由に取得できるわけではないという点です。
シークレットを取得するには、IAMポリシーなどによるアクセス許可が必要になります。
また、取得した認証情報をアプリケーションがどのように扱うかも重要です。
例えば、パスワードをログに出力したり、不要な場所に保存したりすると、情報漏えいにつながる可能性があります。
▪️KMSとの関係
Secrets Managerを理解するうえで重要なのが、前の記事で解説したAWS KMSとの関係です。
KMSは、暗号化キーを管理するためのサービスでした。
一方、Secrets Managerは、データベースのパスワードやAPIキーなどの機密情報を管理するサービスです。
つまり、両者は役割が異なります。
Secrets Manager
|
| 機密情報を管理
v
シークレット
|
| 暗号化にKMSを利用
v
KMS
Secrets Managerでは、シークレットの値を暗号化して保護します。KMSは、その暗号化に利用するキーを管理します。
より正確には、Secrets ManagerはKMSからデータキーを取得し、そのデータキーでシークレットの値を暗号化します。KMSキーでシークレットの値そのものを直接暗号化するわけではありません。
このような仕組みを「エンベロープ暗号化」と呼びます。
初心者の段階では、まず以下のように整理しておきましょう。
| サービス | 主な役割 |
|---|---|
| Secrets Manager | パスワードやAPIキーなどの機密情報を管理する |
| KMS | 暗号化キーを管理する |
| IAM | AWSリソースや操作に対するアクセス権限を管理する |
Secrets Managerでは、AWS管理キー aws/secretsmanager を利用することも、カスタマーマネージドキーを指定することもできます。
カスタマーマネージドキーを利用すると、キーのアクセス制御などを要件に合わせて設計できます。一方、キーの管理や料金も考慮する必要があります。
▪️シークレットのローテーション
Secrets Managerの大きな特徴のひとつが、シークレットのローテーションです。
ローテーションとは、パスワードなどの機密情報を定期的に更新することです。
例えば、データベースのパスワードを長期間変更せずに使い続けると、そのパスワードが漏えいした場合に、不正利用されるリスクが高まります。
定期的にパスワードを変更することで、こうしたリスクを低減できます。
♦︎ローテーションのイメージ
① 現在のパスワード
|
v
② 新しいパスワードを生成・設定
|
v
③ Secrets Managerの情報を更新
|
v
④ アプリケーションが新しい情報を取得
ただし、実際のローテーションでは、Secrets Managerに保存された情報だけを変更すればよいわけではありません。
データベースや外部サービス側の認証情報も更新する必要があります。
Secrets Managerは、対象や方式に応じて自動ローテーションを設定できます。
一部の対応サービスでは、AWSが管理するローテーション機能を利用できます。それ以外の一般的なローテーション方式では、Lambda関数を利用して認証情報を更新する構成があります。
そのため、ローテーションを設定する際には、対象サービスが対応している方式を確認することが重要です。
また、パスワードを変更した直後に、アプリケーションが古いパスワードを使い続けると、接続エラーが発生する可能性があります。
ローテーションを導入する場合は、認証情報の取得タイミングやキャッシュ、接続プールなども考慮しましょう。
▪️IAMによるアクセス制御
Secrets Managerでは、シークレットへのアクセスを適切に制御する必要があります。
例えば、アプリケーションからRDSに接続するためのパスワードを管理しているとします。
このパスワードは、必要なアプリケーションだけが取得できるようにするべきです。
アプリケーションのIAM Role
|
| 許可されたシークレットを取得
v
Secrets Manager
|
v
DBの認証情報
EC2やLambdaなどのAWSサービスからシークレットを取得する場合、IAMロールを利用して必要な権限を付与する構成が一般的です。
例えば、シークレットの取得には secretsmanager:GetSecretValue というAPI操作に対する許可が関係します。
カスタマーマネージドKMSキーを利用している場合は、KMSキーに対する必要な権限も確認する必要があります。
ここで大切なのは、必要なシークレットだけを取得できるように、最小限の権限を付与することです。
アプリケーションに、すべてのシークレットを取得できる権限を与える必要はありません。
また、AWS上で動作するアプリケーションには、アクセスキーをソースコードに埋め込むのではなく、適切なIAMロールを利用することが推奨されます。
▪️RDSとSecrets Managerの連携
ここまでの内容を、実際のAWS構成に当てはめてみましょう。
例えば、EC2上で動作するWebアプリケーションからRDSに接続するシステムを考えます。
Internet
|
v
ALB
|
v
EC2
|
| 認証情報を取得
v
Secrets Manager
|
| 暗号化に利用
v
KMS
EC2
|
| 認証情報を使用
v
RDS
この構成では、次のような役割分担になります。
- EC2：Webアプリケーションを実行する
- Secrets Manager：RDSの認証情報を管理する
- KMS：シークレットの暗号化に利用するキーを管理する
- RDS：データベースを提供する
- IAMロール：EC2上のアプリケーションがシークレットを取得するための権限を与える
アプリケーションは、Secrets Managerから認証情報を取得し、その情報を使ってRDSに接続します。
このように構成することで、データベースのパスワードをソースコードに直接記述せずに済みます。
なお、Secrets Managerから認証情報を取得する処理と、RDSへ接続する処理は別です。Secrets Managerから情報を取得できても、ネットワークやRDS側の認証設定が正しくなければ、データベースには接続できません。
また、Secrets ManagerとRDSの組み合わせでは、RDSのマスターユーザー認証情報をSecrets Managerで管理する方法もあります。ただし、アプリケーションには、可能な限り必要な操作だけを許可した専用のデータベースユーザーを利用する設計が望ましいです。
▪️Secrets ManagerとParameter Storeの違い
AWSで設定値や機密情報を管理するサービスとして、AWS Systems Manager Parameter Storeもあります。
どちらも値を保存・取得できますが、用途や機能には違いがあります。
| 比較項目 | Secrets Manager | Systems Manager Parameter Store |
|---|---|---|
| 主な用途 | パスワードやAPIキーなどの機密情報 | アプリケーション設定値や各種パラメータ |
| 暗号化 | KMSを利用 | SecureStringでKMSを利用可能 |
| 自動ローテーション | 対応 | Secrets Managerのような汎用の組み込みローテーション機能はない |
| 主な特徴 | シークレットのライフサイクル管理 | 設定値を階層的に管理できる |
| 料金 | シークレット数やAPI利用などに応じて料金が発生 | パラメータの種類や利用条件によって無料枠・料金が異なる |
例えば、次のように使い分けられます。
Secrets Managerが向いている例
- RDSのパスワードを管理する
- APIキーなどの機密情報を管理する
- 対応する認証情報の自動ローテーションを利用する
Parameter Storeが向いている例
- アプリケーションの設定値を管理する
- 環境ごとの設定値を整理する
- 暗号化が必要な値をSecureStringとして管理する
ただし、どちらを使うかは情報の重要度や更新頻度、ローテーション要件、料金などによって変わります。
「機密情報なら必ずSecrets Manager」という単純なルールではなく、必要な機能を基準に選択しましょう。
▪️Secrets Managerを利用するときの注意点
Secrets Managerを利用する際には、いくつか注意すべきポイントがあります。
① IAM権限を最小限にする
シークレットを取得できる主体を必要なアプリケーションや運用担当者に限定します。
② 取得した機密情報を安全に扱う
Secrets Managerから取得したパスワードをログへ出力したり、不要なファイルに保存したりしないようにします。
③ ローテーションの影響を確認する
認証情報の変更によって、アプリケーションの接続が失敗しないかを確認します。キャッシュや接続プールを利用している場合は特に注意が必要です。
④ KMSの権限も確認する
カスタマーマネージドキーを利用している場合は、Secrets Managerからの取得に必要なKMS権限やキーポリシーも確認します。
⑤ 料金を考慮する
Secrets Managerは、シークレットの保管数やAPIリクエストなどに応じて料金が発生します。自動ローテーションの方式によっては、Lambdaの利用料金なども発生するため、料金体系を確認しておきましょう。
⑥ シークレットを削除するときは慎重に判断する
アプリケーションが利用しているシークレットを削除すると、認証情報を取得できなくなり、システムに影響する可能性があります。削除する前に、利用状況や依存関係を確認しましょう。
▪️まとめ
今回はAWS Secrets Managerについて解説しました。
Secrets Managerを一言で表すと、
「パスワードやAPIキーなどの機密情報を安全に管理するサービス」
です。
重要なポイントを整理すると、以下のようになります。
- Secrets Managerは、データベースの認証情報やAPIキーなどを管理する
- ソースコードに機密情報を直接記述するリスクを減らせる
- KMSを利用してシークレットを暗号化できる
- IAMによってシークレットへのアクセスを制御できる
- 対応する認証情報では自動ローテーションを利用できる
- Parameter Storeとは用途や機能、料金を比較して使い分ける
特に重要なのは、Secrets Manager・KMS・IAMの役割の違いです。
Secrets Manager
└─ 機密情報を管理
KMS
└─ 暗号化キーを管理
IAM
└─ アクセス権限を管理
これらを組み合わせることで、AWS上のシステムで機密情報をより安全に扱えるようになります。
AWSを学ぶ際には、サービス単体の機能だけでなく、実際のシステムの中で各サービスがどのように連携するのかを理解することが大切です。
まずは、RDSの認証情報をSecrets Managerで管理し、EC2などのアプリケーションから取得する構成をイメージできるようにしておきましょう。
次は、AWSのデータベースサービスであるAmazon DynamoDBについて学ぶと、RDSとの違いを通じて、AWSにおけるデータの保存方法をさらに理解できます。
＊「Amazon DynamoDB」の記事はこちら
→「https://lovelabengineer.com/2026/10/09/awsのdynamodbとは？nosqlデータベースの仕組みを初心者向け/」
No responses yet